کنترل پیش‌پرداخت تأمین‌کننده؛ پیش از پرداخت بعدی چه چیزی را ببندیم؟

کنترل پیش‌پرداخت تأمین‌کننده کدام تصمیم را روشن می‌کند؟

هنگام امضای پرداخت بعدی، فقط نپرسید فاکتور تأیید شده است یا نه. بپرسید برای همین خرید قبلاً چقدر پول داده‌ایم، چه مقدار آن درست به تحویل و فاکتور وصل شده و امروز واقعاً چه مبلغی باید از بانک خارج شود. دامنه این راهنما، پیش‌پرداخت خرید کالا یا خدمت است؛ نه هزینه‌ای مانند بیمه که طی زمان مصرف می‌شود، نه ودیعه‌ای با شرط بازگشت جداگانه و نه پیش‌دریافت از مشتری.

در مستندات Microsoft برای Dynamics 365 Finance، مسیر سفارش دارای پیش‌پرداخت از ثبت و پرداخت آن شروع می‌شود، سپس مبلغ پرداخت‌شده به فاکتور عادی مرتبط تخصیص می‌یابد و باقیمانده پرداخت می‌شود. این توالی رفتار مستند همان محصول است. نتیجه مدیریتی برای ما این است که «قبلاً پول داده‌ایم» باید پیش از محاسبه دستور پرداخت تازه وارد پرونده شود، نه وقتی فروشنده بعداً صورت‌حساب مانده را می‌فرستد. ^[۱]

پیشنهاد اجرایی ژرف‌بان، یک پرونده تصمیم با سه خروجی است: پرداخت خالص پس از تخصیص معتبر؛ نگهداری بخش مبهم تا تکمیل شواهد؛ یا ارجاع مانده به پیگیری تحویل و بازیافت وجه. توقف داخلی به‌تنهایی تعهد قراردادی را از بین نمی‌برد. درباره مبلغ مورد اختلاف و مبلغ بدون اختلاف جدا تصمیم بگیرید و اختیار قراردادی هر اقدام را بررسی کنید؛ این متن حق عمومیِ نپرداختن یا تهاتر ایجاد نمی‌کند.

مانده باز پیش‌پرداخت را از کدام شناسنامه بسازیم؟

برای هر پیش‌پرداخت یک شناسه یکتا و ردیف مستقل نگه دارید: شرکت پرداخت‌کننده، هویت حقوقی فروشنده، قرارداد یا سفارش، ارز، مبلغ و تاریخ بانک، هدف پرداخت، تاریخ تحویل مورد انتظار، شرط کسر از صورتحساب و مسئول خرید. شماره سند حسابداری به‌تنهایی کافی نیست؛ بازبین باید بتواند از ردیف گزارش به اصل پرداخت و شرط تسویه برسد. چند پیش‌پرداخت یک قرارداد را نیز با تاریخ اولیه خودشان حفظ کنید.

راهنمای Advance Payment Entry در ERPNext ثبت طرف حساب، شرکت، حساب، ارز و مرجع پرداخت را توضیح می‌دهد. همچنین می‌گوید اتصال پیش‌پرداخت به سفارش ردیابی آن را آسان‌تر می‌کند و برای تخصیص، سازگاری طرف حساب و اسناد لازم است. این مستند هشدار می‌دهد که ثبت دستی در حساب نامرتبط الزاماً مبلغ قابل تخصیص در گردش استاندارد نمی‌سازد. بنابراین مانده دفتر کل و مانده قابل استفاده در زیرسیستم را جدا تطبیق دهید. ^[۲]

برای کنترل عملیاتی، مانده اول دوره را با پیش‌پرداخت‌های واقعاً انجام‌شده افزایش دهید، تخصیص‌های معتبر و استردادهای واقعاً دریافت‌شده را کم کنید و برگشت تخصیص قبلی را اضافه کنید. این پل را ابتدا در ارز همان قرارداد بسازید. تغییرات ناشی از تسعیر، طبقه‌بندی یا اصلاح ثبت را در ستون جدا توضیح دهید؛ جمع‌زدن مبالغ چند ارز یا استفاده از یک عدد تبدیل‌شده، منشأ اختلاف را پنهان می‌کند. نحوه حسابداری ارزی نیازمند مبنای گزارشگری شرکت است.

پیش‌پرداخت مصوب ولی هنوز پرداخت‌نشده را در این مانده نگذارید؛ آن تعهد نقدی آینده است. همچنین وجه پرداخت‌شده یک قرارداد را صرفاً چون نام فروشنده مشترک است به قرارداد دیگر منتقل نکنید. ابتدا مجوز و توافق قابل اتکا، تعلق حقوقی مبلغ و آثار ثبت را بررسی کنید. یک شرکت گروه نباید بدون مبنای روشن، پیش‌پرداخت شرکت دیگر را از بدهی خودش کم کند. هدف شناسنامه، حفظ رابطه پول با تعهد مشخص است.

کسر پیش‌پرداخت از فاکتور؛ سقف فنی با مجوز قراردادی فرق دارد

پیش از کسر، روشن کنید سند دریافتی مبلغ ناخالص خرید را نشان می‌دهد یا مبلغ خالص پس از پیش‌پرداخت را. اگر فروشنده خودش پیش‌پرداخت را در درخواست وجه کم کرده و شما دوباره همان کسر را انجام دهید، پرداخت کمتر از مقدار مورد توافق می‌شود. برعکس، پرداخت کل فاکتور بدون توجه به مانده قابل تخصیص، وجه بیشتری نزد فروشنده نگه می‌دارد. یک پل روشن از مبلغ ناخالص تا مبلغ پرداخت، جای ابهام عنوان سند را بگیرد.

Oracle Fusion Payables میان پیش‌پرداختی که در مبلغ فاکتور لحاظ شده و پیش‌پرداختی که هنگام تخصیص از مبلغ پرداختنی کم می‌شود تمایز می‌گذارد. مستند آن همچنین تصریح می‌کند که پیش‌پرداخت باید پرداخت شده باشد تا قابل اعمال شود و اعمال آن، مانده قابل استفاده پیش‌پرداخت را کاهش می‌دهد. این دو وضعیت را در آزمون نرم‌افزار خود جدا اجرا کنید؛ نام دکمه یا نمایش مانده صفر، اثبات محاسبه درست نیست. ^[۳]

در مستند فیلدهای رابط صورتحساب Oracle، مبلغ اعمال پیش‌پرداخت باید مثبت باشد و نمی‌تواند از مبلغ پرداخت‌نشده فاکتور یا پیش‌پرداخت در دسترس بیشتر شود. این شاهد، یک کنترل فنی مشخص در همان رابط است؛ نه مجوز قراردادی برای برداشت هر مانده‌ای. در طراحی پیشنهادی، سقف کسر را کوچک‌ترینِ مانده تخصیص‌نیافته معتبر، مبلغ قابل تسویه فاکتور و مقدار مجاز طبق شرط قرارداد قرار دهید. هر سه ورودی باید مبنا و شاهد داشته باشند. ^[۴]

در بعضی پرونده‌ها شرط کسر، مبلغ ثابت است؛ در نمونه‌ای دیگر درصدی از هر تحویل یا صورتحساب پذیرفته‌شده. روش را از قرارداد واقعی استخراج کنید، نه از پیش‌فرض نرم‌افزار یا عرف شفاهی تیم. کسور دیگر، مالیات، برگشت خرید و خسارت ادعایی را در همان ستون پیش‌پرداخت جمع نکنید. این راهنما نرخ مالیاتی یا حکم جاری سامانه مودیان ارائه نمی‌کند؛ نوع سند و آثار قانونی باید جداگانه با منبع رسمی و مسئول پرونده کنترل شوند.

مثال آموزشی: فاکتور ۵۰۰، کسر ۱۵۰ و پرداخت ۳۵۰

مثال زیر کاملاً فرضی است؛ همه مبالغ میلیون تومان و بدون مالیات، کارمزد، تغییر ارز یا سایر کسورند. ارزش سفارش ۱۰۰۰ است و ۳۰۰ پیش‌پرداخت واقعاً به فروشنده پرداخت شده است. قرارداد آموزشی ما می‌گوید از هر تحویل پذیرفته‌شده، ۳۰ درصد مبلغ صورتحساب بابت استهلاک پیش‌پرداخت کسر شود. اکنون تحویل و فاکتور معتبر ۵۰۰ داریم. این درصد، فرض مثال است و نرخ قانونی یا پیشنهاد عمومی برای قراردادها نیست.

مبلغ کسر این مرحله ۱۵۰، یعنی ۳۰ درصدِ ۵۰۰ است. از فاکتور ۵۰۰، پس از تخصیص ۱۵۰، فقط ۳۵۰ پرداخت تازه لازم است. مانده پیش‌پرداخت از ۳۰۰ به ۱۵۰ می‌رسد و مجموع خروج وجه تا این مرحله ۶۵۰ است: ۳۰۰ قبلی به‌علاوه ۳۵۰ جدید. این جمع شامل ۵۰۰ بابت خرید تسویه‌شده و ۱۵۰ پیش‌پرداخت باز برای ادامه سفارش است. تخصیص ۱۵۰، خروج دوباره پول نیست.

اگر خزانه بدون کسر، تمام ۵۰۰ را بپردازد، خروج تجمعی ۸۰۰ و مانده پیش‌پرداخت همچنان ۳۰۰ خواهد بود؛ ۱۵۰ بیشتر از برنامه توافق‌شده پول نزد فروشنده مانده است. اما اگر حسابدار همه ۳۰۰ را از همین فاکتور کم کند و ۲۰۰ بپردازد، مانده پیش‌پرداخت صفر می‌شود ولی شرط فرضیِ کسر تدریجی رعایت نشده است. پس نه کمترین پرداخت بانکی و نه سریع‌ترین صفرشدن مانده، به‌تنهایی نتیجه درست را تعیین می‌کند.

در تحویل دومِ ۵۰۰، با فرض تداوم همان شرایط، ۱۵۰ باقی‌مانده تخصیص می‌یابد و ۳۵۰ دیگر پرداخت می‌شود؛ جمع پرداخت‌ها ۱۰۰۰ و مانده پیش‌پرداخت صفر است. اگر تحویل دوم لغو شود، ۱۵۰ را به‌زور به هزینه یا فاکتور نامرتبط نبرید؛ پرونده درباره تعهد باقی‌مانده و استرداد احتمالی تصمیم تازه می‌خواهد. اگر درخواست وجه مرحله اول از ابتدا عدد خالص ۳۵۰ را نشان داده باشد نیز نباید دوباره ۱۵۰ از آن کم شود.

کدام مانده باید پرداخت بعدی را به بازبینی ببرد؟

هر مانده باز مشکل نیست. پیش‌پرداختی که هنوز در مهلت ساخت قرار دارد و برنامه تحویل معتبر دارد، با مانده سفارش لغوشده یا فروشنده بدون پاسخ یکسان نیست. صف را بر اساس وضعیت بسازید: در انتظار تحویل طبق برنامه؛ تحویل‌شده اما منتظر فاکتور یا تخصیص؛ دارای اختلاف مقدار یا کیفیت؛ و در مسیر لغو یا استرداد. تاریخ پرداخت اولیه و تاریخ تعهد تحویل را کنار هم نگه دارید؛ یکی سن پول را نشان می‌دهد، دیگری تأخیر عملکرد را.

برای پیش‌پرداخت تازه، پیشنهاد ما بازبینی مستقل در صورت عبور از موعد بی‌توضیح، اختلاف مانده با فروشنده، نبود مدرک پرداخت قبلی یا درخواست تغییر مقصد وجه است. بازبین باید بپرسد پول تازه کدام کار مشخص را ممکن می‌کند، چه شاهدی برای انجام آن داریم و اگر آن کار انجام نشود مواجهه باقی‌مانده چقدر می‌شود. درخواست خرید جدید نباید به‌تنهایی تاریخ و ریسک پیش‌پرداخت قدیمی را از گزارش حذف کند.

تصمیم دو سوی هزینه دارد. توقف نامتناسب می‌تواند تحویل لازم را عقب بیندازد؛ پرداخت تازه بدون حل علت نیز ممکن است فقط مبلغ بیشتری را گرفتار کند. گزینه‌های قابل بررسی شامل کوچک‌کردن مرحله، اتصال پرداخت به تحویل قابل احراز یا اصلاح برنامه با توافق مکتوب است. ارزش و قابلیت اتکای تضمین احتمالی را متخصص مسئول بررسی کند؛ وجود یک تصویر ضمانت‌نامه را معادل وجه بازیافت‌شده نگذارید. هیچ نسبت ثابتی برای همه تأمین‌کنندگان قابل توصیه نیست.

اگر فاکتور عادی بابت تحویل معتبر، طبق قرارداد سررسید شده ولی پیش‌پرداخت قرارداد دیگری محل اختلاف است، این دو را خودکار با هم متوقف یا تهاتر نکنید. ابتدا امکان تخصیص، حدود اختیار و ریسک قراردادی را روشن کنید. در راهنمای مرتبط «تطبیق سه‌طرفه خرید» کنترل سفارش، رسید و فاکتور را ببینید؛ اینجا یک لایه دیگر اضافه می‌کنیم: حتی فاکتور درست هم باید با پرداخت‌های قبلی همان پرونده سنجیده شود.

خودکارسازی تسویه پیش‌پرداخت خرید را چگونه بیازماییم؟

مستند Business Central توضیح می‌دهد که هنگام ثبت باقی فاکتور، مبلغ پیش‌پرداخت از مبلغ پرداختنی کسر می‌شود؛ همچنین برای افزایش پیش‌پرداخت، صورتحساب تازه می‌تواند فقط تفاوت مبلغ جدید و مبالغ قبلاً صورتحساب‌شده را پوشش دهد. این رفتار مستند همان محصول و جریان کاری است. برای سامانه خود، افزایش سفارش را یک آزمون مستقل بگذارید: آیا فقط افزایش مجاز پیشنهاد می‌شود یا تمام پیش‌پرداخت دوباره در صف پرداخت می‌نشیند؟ ^[۵]

در Dynamics 365 Finance، مستندات بین فاکتور ایجادشده دستی و فاکتور ایجادشده از مسیر data entity فرق می‌گذارند: سیاست اعمال خودکار پیش‌پرداخت برای دومی به همان شکل استفاده نمی‌شود و اعمال دستی لازم است. پس آزمون ورود دستی، شاهد کافی برای اتصال خرید یا بارگذاری فایل نیست. مسیر واقعی شرکت را با داده آزمایشی اجرا کنید و مقدار تخصیص‌یافته، مانده فاکتور و مبلغ دستور پرداخت را پس از هر مرحله ببینید. ^[۱]

آزمون باید شکست کنترل را هم آشکار کند. همان پیش‌پرداخت را هم‌زمان برای دو فاکتور پیشنهاد دهید و بررسی کنید مجموع استفاده از مانده فراتر نرود. سپس فاکتور قبلاً تسویه‌شده، شرکت متفاوت، ارز متفاوت، درخواست وجه خالص و لغو تخصیص را امتحان کنید. انتظار هر آزمون را پیشاپیش بنویسید. ناسازگاری ارز لزوماً به معنای ناممکن‌بودن معامله نیست، اما نباید با تغییر صوری ارز سند برای عبور از کنترل حل شود.

پس از برگشت تخصیص، فقط بازشدن پیش‌پرداخت را نگاه نکنید؛ آیا فاکتور دوباره پرداختنی شده و وارد پیشنهاد پرداخت بعدی می‌شود؟ Oracle امکان برداشتن تخصیص اشتباه و در دسترس قرارگرفتن دوباره پیش‌پرداخت را مستند کرده است. کنترل پیشنهادی ما این است که بازگشت، شناسه تصمیم اصلاحی و بازبینی صف پرداخت داشته باشد. لغو یک ارتباط دفتری، پولی را که قبلاً از بانک خارج شده برنمی‌گرداند. ^[۳]

برگه تصمیم پیش از ارسال دستور پرداخت

تهیه‌کننده حساب‌های پرداختنی، پل مبلغ را بسازد؛ مسئول خرید وضعیت تعهد و تحویل را تأیید کند؛ خزانه اصل پرداخت قبلی و وجه قابل پرداخت امروز را کنترل کند؛ و بازبین مجاز استثنا را بپذیرد یا باز نگه دارد. در تیم کوچک، نقش‌ها ممکن است در افراد کمتری جمع شوند، اما همان فرد نباید بدون بازبینی مستقل بتواند مانده را جابه‌جا کند و پرداخت تازه را آزاد سازد. امضا به نسخه معین پرونده وصل باشد.

حداقل خروجی، یک ردیف قابل بازسازی برای مبلغ ناخالص، سایر تعدیلات مجاز، کسر پیش‌پرداخت، پرداخت قبلی همان فاکتور، پرداخت تازه و مانده پیش‌پرداخت پس از اجراست. شرط محاسبه را روشن بنویسید تا یک کسر در دو ستون تکرار نشود. پس از تغییر مبلغ فاکتور، قرارداد یا تخصیص، پیشنهاد پرداخت را دوباره محاسبه و تأیید کنید. چک‌لیست زیر باید شاهد داشته باشد، نه صرفاً پاسخ بله یا خیر.

• هویت و دامنه: شرکت، فروشنده، سفارش، ارز و ردیف پیش‌پرداخت به یک پرونده مشخص تعلق دارند.
• اصل وجه: پرداخت قبلی در بانک احراز شده و پیش‌پرداخت مصوبِ پرداخت‌نشده به‌جای آن ننشسته است.
• مبنای کسر: مبلغ ناخالص و خالص تفکیک شده و شرط قرارداد، مانده در دسترس و سقف فاکتور بررسی شده‌اند.
• عدم تکرار: تخصیص در فاکتور دیگر، دستور پرداخت در جریان و برگشت‌های قبلی در محاسبه دیده شده‌اند.
• استثنا و اجرا: مبلغ مورد اختلاف، صاحب پیگیری، موعد پاسخ و مجوز پرداخت بخش باقی‌مانده مشخص‌اند.
• پس از اجرا: بانک، فاکتور، ریز پیش‌پرداخت و دفتر کل با نتیجه مصوب تطبیق دارند.

چه چیزی را رصد و چه زمانی پرونده را بازبینی کنیم؟

گزارش هفتگی را با مبلغ باز به تفکیک قرارداد و ارز، روزهای گذشته از موعد تحویل، مبلغ تحویل‌شده ولی تخصیص‌نیافته و استرداد وعده‌داده‌شده ولی وصول‌نشده شروع کنید. مبلغی که با تخصیص کم شده را از وجهی که واقعاً برگشته جدا نشان دهید؛ هیچ‌کدام را بی‌دلیل «صرفه‌جویی» ننامید. برای سنجش کیفیت کنترل، اصلاحات پس از تأیید و تأخیر پرداخت‌های سالم را هم بشمارید، نه فقط تعداد پرونده‌های بسته.

برنامه اولیه پیشنهادی، مرور پرتکرارِ پرونده‌های دارای پرداخت نزدیک و مرور هفتگی قدیمی‌ترین مانده‌هاست؛ تناوب را با ریسک و حجم کار تنظیم کنید. تمدید موعد باید تاریخ قبلی، علت، تأییدکننده و شاهد برنامه تازه را حفظ کند. تغییر تاریخ نباید سن واقعی پول را صفر کند. برای اثر بر پرداخت‌های آینده، راهنمای مرتبط «پیش‌بینی جریان نقد ۱۳ هفته‌ای» را به‌کار ببرید؛ وعده استرداد نامطمئن را مانند موجودی نقد امروز در نظر نگیرید.

منابع در ۱۰ مهر ۱۴۰۵ بررسی شدند. دو صفحه Oracle مربوط به نسخه 26B هستند و فراداده انتشارشان ۳۱ مارس ۲۰۲۶ را نشان می‌دهد. تاریخ نمایان بازبینی دو صفحه Microsoft به‌ترتیب ۴ اوت ۲۰۲۶ و ۱۳ اکتبر ۲۰۲۵ است. Frappe زمان نسبی به‌روزرسانی نشان می‌دهد؛ برای آن تاریخ دقیق حدس نزده‌ایم. این مستندات سازوکار محصولات خود را تأیید می‌کنند، نه حکم ایران یا قابلیت ژرف‌بان را؛ چارچوب کنترل و مثال، پیشنهاد تحریریه‌اند. ^{[۳] [۴] [۱] [۵] [۲]}