---
topicCode: PUR.REPLENISHMENT.TO_DRAFT_ORDER
workflowCode: PUR.REPLENISHMENT.TO_DRAFT_ORDER
type: WORKFLOW
title: "تبدیل پیشنهاد تأمین به سفارش خرید"
language: fa
productVersion: "2.1.0.2"
knowledgeBuildId: KB1-32B9894BF95B7C940EC71C5E
humanUrl: "https://help.melal.ir/help/fa/purchase/workflows/pur-replenishment-to_draft_order"
capability: "PURCHASE"
module: "PUR"
surfaces:
  - "ACCOUNTING"
  - "ADMIN"
audiences:
  - "مدیر خرید"
  - "مدیر مالی"
  - "مدیر شعب"
  - "اپراتور مجاز"
keywords:
  - "خرید"
  - "تبدیل پیشنهاد تأمین به سفارش خرید"
aiIntents:
  - "تبدیل پیشنهاد تأمین به سفارش خرید چگونه انجام می‌شود؟"
---

# تبدیل پیشنهاد تأمین به سفارش خرید

## هدف
پیشنهاد تأمین از موجودی/تأمین مجدد می‌آید و با کالای تأمین‌کننده و قواعد حداقل/ضریب سفارش به پیش‌نویس سفارش خرید تبدیل می‌شود؛ ایجاد پیش‌نویس باید شعبه-آگاه و تکرارپذیر ایمن باشد.

## مسیر اصلی
1. شعبه و رکورد واقعی عملیات تعیین و دسترسی همان شعبه بررسی می‌شود.
2. وضعیت، تأمین‌کننده، محصول/واحد، سال مالی و وابستگیهای لازم اعتبارسنجی می‌شوند.
3. عملیات داخل سرویس کاربردی رسمی و تراکنش مناسب اجرا می‌شود.
4. تکرارپذیری ایمن/هم‌زمانی قبل از اثر جانبی جدید بررسی می‌شود.
5. موجودی/حسابداری فقط از درگاه فنی/نگاشت رسمی و با منبع ردیابی ایجاد می‌شود.
6. نتیجه از خواندن مدل جاری خوانده می‌شود.

## تلاش مجدد و هم‌زمانی
اجرای مجدد با همان کلید و همان داده ارسالی باید همان نتیجه رسمی را برگرداند؛ کلید با داده ارسالی متفاوت تعارض است. نسخه سطر/سریال‌پذیر محافظ‌ها برای جلوگیری از دوگانه دریافت/فاکتور/برگشت/اعتبار/اثر جانبی استفاده می‌شوند.

## برگشت / ابطال
سند ثبت‌شده مستقیم ویرایش نمی‌شود. اگر پایین‌دستی وابستگی فعال باشد، ابتدا وابستگی رسمی برگشت/لغو تطبیق/تسویه می‌شود. برگشت باید تکرارپذیر ایمن، قابل ردیابی و بدون جزئی ثبت نهایی باشد.

## موارد ممنوع
- استفاده از شعبه انتخاب‌شده رابط کاربری به جای شعبه واقعی سند.
- تغییر مستقیم مانده موجودی/سند حسابداری برای اصلاح خرید.
- یکی‌گرفتن برگشت فیزیکی با اعلامیه بستانکاری.
- استفاده از `PurchaseInvoiceId` یا سایر شناسههای داخلی به‌عنوان شماره نمایشی.