تایید پیش فاکتور فروش یعنی چند گذر مشخص از وضعیت سند فقط با نظر نقش مجاز انجام شود، نه همهٔ پیشفاکتورها. چهار گذر اصلی این‌هاست: ارسال با قیمت یا تخفیف بیرون از قاعده، تغییر بعد از ارسال، شرط پرداخت غیرمعمول و تبدیل به فاکتور. بقیه را بدون تایید جلو ببرید.
این راهنما برای شرکت بازرگانی و تیم فروش کوچکی است که پیش‌فاکتور را در نرم‌افزار، اکسل یا پیام‌رسان می‌فرستد و هر از گاهی می‌فهمد قیمتی رفته که کسی تاییدش نکرده بود. اگر یک نفر هم قیمت می‌دهد و هم صاحب تصمیم است، گردش تایید جدا لازم ندارید. همان یک نفر مسئول است و مرحلهٔ اضافه فقط کار را کند میکند. مسئله از جایی شروع می‌شود که دو یا چند فروشنده قیمت می‌دهند و مدیر یا مالی بعداً باید جوابگو باشد.
مسیر کامل فرصت تا فاکتور در چرخهٔ فروش در ERP فارسی آمده است. این مقاله فقط روی یک حلقه از آن مسیر تمرکز دارد: لحظه‌هایی که پیش‌فاکتور نباید بدون تایید از یک وضعیت به وضعیت بعد برود.
پیش‌فاکتور چیست و چرا باید وضعیت داشته باشد؟
پیش‌فاکتور پیشنهاد کتبی فروش است: کالا، تعداد، قیمت، شرط پرداخت، مهلت اعتبار و زمان تحویل. در تعریف رایج، پیش‌فاکتور یا Pro forma invoice سند تعهد قطعی فروش نیست و مشتری بر اساس آن تصمیم می‌گیرد یا پیش‌پرداخت میکند. اما برای مشتری، عددی که روی آن نوشته‌اید قول شماست. اگر قیمت پایین‌تر از قاعده رفته باشد، پس گرفتنش هزینهٔ اعتبار دارد.
وضعیت سند یعنی همه بدانند پیش‌فاکتور الان کجاست. بدون وضعیت، فروشنده یک نسخه را در اکسل اصلاح میکند، نسخهٔ قبلی در واتساپ مشتری مانده و مدیر نمی‌داند کدام تایید شده است. وضعیت لازم نیست پیچیده باشد. برای بیشتر تیم‌های کوچک پنج وضعیت کافی است:
| وضعیت | معنی | چه کسی جلو می‌برد |
|---|---|---|
| پیش‌نویس | فروشنده هنوز در حال تکمیل اقلام و قیمت است | فروشنده |
| در انتظار تایید | سند از قاعدهٔ عادی بیرون است و منتظر نظر نقش مجاز | فروشنده می‌فرستد، تاییدکننده تصمیم می‌گیرد |
| ارسال‌شده | نسخه‌ای که مشتری دیده و مبنای مذاکره است | فروشنده |
| پذیرفته یا ردشده | جواب مشتری ثبت شده است | فروشنده |
| تبدیل‌شده یا منقضی | به سفارش یا فاکتور رسیده، یا مهلتش گذشته است | فروشنده یا مالی، طبق قاعده |
جدول بالا یک الگوی پیشنهادی است، نه استاندارد اجباری. ممکن است شما «ارسال‌شده» و «پذیرفته» را یکی کنید. نکتهٔ مهم این است که بین پیش‌نویس و ارسال‌شده، یک دروازه وجود داشته باشد که سند خارج از قاعده نتواند بی‌صدا از آن رد شود.
فرق تایید با ثبت
ثبت یعنی سند در سیستم هست. تایید یعنی کسی که اختیارش را دارد، گفته این عدد و این شرط درست است. خیلی از تیم‌ها همهٔ پیشفاکتورها را ثبت می‌کنند و فکر می‌کنند کنترل دارند. اما وقتی هر فروشنده میتواند سند خودش را بفرستد، ویرایش کند و به فاکتور تبدیل کند، ثبت فقط سابقه است؛ کنترل نیست.
ایدهٔ پشت این کار همان کنترل داخلی است: کسی که سند می‌سازد، همان کسی نباشد که ریسکش را می‌پذیرد. برای شرکت کوچک این اصل لازم نیست به چند لایه امضا تبدیل شود. یک تاییدکننده و یک قاعدهٔ روشن معمولاً کافی است.
کدام وضعیت‌های پیش‌فاکتور تایید لازم دارند؟
پیشفاکتوری که قیمت فهرست، شرط پرداخت معمول و کالای موجود دارد، تایید نمی‌خواهد. فروشنده باید بتواند آن را همان لحظه بفرستد. تایید را برای چهار گذر نگه دارید که در آن‌ها اشتباه گران تمام می‌شود.
۱. ارسال با قیمت یا تخفیف بیرون از قاعده
اگر قیمت ردیفی از فهرست پایین‌تر است یا جمع تخفیف از سقفی که تعیین کرده‌اید بیشتر شده، سند نباید مستقیم از پیش‌نویس به ارسال‌شده برود. باید به «در انتظار تایید» برود. سقف را عددی بنویسید، مثلاً درصد مشخصی از مبلغ ردیف یا مبلغ کل. جملهٔ «تخفیف معقول» برای هر فروشنده معنی دیگری دارد.
قاعدهٔ تخفیف و اینکه چه کسی تا چه سقفی اختیار دارد، موضوع مفصل‌تری است. اینجا فقط کافی است بدانید پیش‌فاکتور با تخفیف خارج از سقف، یکی از دروازه‌های تایید است.
۲. تغییر بعد از ارسال یا بعد از تایید
رایج‌ترین نشتی همین‌جاست. مدیر نسخهٔ اول را تایید میکند، مشتری چانه می‌زند و فروشنده همان سند را با قیمت تازه دوباره می‌فرستد. روی کاغذ، سند «تاییدشده» است؛ در واقعیت، عددی که مشتری دیده هیچ‌وقت تایید نشده است.
قاعدهٔ ساده: هر تغییری در مبلغ، تعداد، کالا، شرط پرداخت یا مهلت تحویل، پیش‌فاکتور را به پیش‌نویس برمی‌گرداند یا یک نسخهٔ تازه می‌سازد. نسخهٔ تازه دوباره همان قاعدهٔ تایید را طی میکند. اگر فقط نشانی یا یک غلط تایپی در توضیحات اصلاح شده، تایید دوباره لازم نیست. همین مرز را مکتوب کنید.
۳. شرط پرداخت یا اعتبار غیرمعمول
قیمت درست با شرط پرداخت غلط هم زیان می‌سازد. فروش نسیه به مشتری تازه، مهلت پرداخت طولانی‌تر از روال، یا تحویل کالا قبل از پیش‌پرداخت، همه تصمیم مالی‌اند. فروشنده معمولاً انگیزه دارد معامله را ببندد؛ مالی باید ببیند وصول پول چقدر قطعی است.
اگر شرط پرداخت از گزینه‌های معمول شما بیرون است، تایید را از مدیر فروش به مسئول مالی بدهید یا هر دو را لازم کنید. برای تیم خیلی کوچک، یک تاییدکننده که هر دو نگاه را دارد کافی است.
۴. تبدیل پیش‌فاکتور به فاکتور
فاکتور سند فروش قطعی است و حساب مشتری را بدهکار میکند. اگر پیش‌فاکتور هنوز تایید نشده یا نسخهٔ تاییدشده با نسخهٔ پذیرفته‌شده فرق دارد، تبدیل نباید ممکن باشد. این مرحله آخرین فرصت برای گرفتن خطاست؛ بعد از آن اصلاح یعنی سند برگشت یا ابطال، نه یک ویرایش ساده.
اثر انبار هم به همین مرحله وصل است. پیش‌فاکتور معمولاً موجودی را کم نمی‌کند و خروج کالا بعد از فاکتور با سند جدا ثبت می‌شود. جزئیات این بخش در حوالهٔ انبار از فاکتور تا کسر موجودی آمده است. اگر تیم شما با پیش‌فاکتور به مشتری قول تحویل می‌دهد، رزرو موجودی بحث جداگانه‌ای است و باید قاعدهٔ خودش را داشته باشد.
کدام وضعیت‌ها تایید نمی‌خواهند؟
لازم نیست برای هر حرکت سند تایید بگذارید. این گذرها معمولاً بدون تایید هم امن‌اند:
- ساختن و ذخیرهٔ پیش‌نویس
- ارسال پیش‌فاکتور با قیمت فهرست و شرط پرداخت معمول
- ثبت جواب مشتری، پذیرفته یا ردشده
- منقضی شدن سند بعد از گذشت مهلت اعتبار
- لغو پیشفاکتوری که هنوز به فاکتور نرسیده
هرچه فهرست تایید کوتاه‌تر باشد، احتمال اینکه تیم آن را واقعاً رعایت کند بیشتر است.
چه کسی تایید کند و گردش تایید در تیم کوچک چه شکلی است؟
تاییدکننده کسی است که پیامد تصمیم را می‌پذیرد. برای قیمت و تخفیف، معمولاً مدیر فروش. برای شرط پرداخت و اعتبار، معمولاً مالی. در شرکت پنج تا بیست نفره، اغلب یک مدیر هر دو نقش را دارد. اشکالی ندارد؛ مهم این است که فروشنده سند خودش را تایید نکند.
اصل تفکیک وظایف همین را می‌گوید: سازندهٔ سند و پذیرندهٔ ریسک یک نفر نباشند. این اصل در شرکت بزرگ با چند لایه اجرا می‌شود. در شرکت کوچک، یک جدول سادهٔ اختیار کافی است.
جدول اختیار تایید را بنویسید
| موقعیت پیش‌فاکتور | تایید لازم است؟ | تاییدکننده پیشنهادی |
|---|---|---|
| قیمت فهرست، شرط پرداخت معمول | نه | — |
| تخفیف تا سقف تعیین‌شده برای فروشنده | نه | — |
| تخفیف بالاتر از سقف فروشنده | بله | مدیر فروش |
| قیمت زیر حداقل تعیین‌شده | بله | مدیر فروش یا مدیرعامل |
| فروش نسیه یا مهلت پرداخت طولانی‌تر از روال | بله | مالی |
| تغییر مبلغ، تعداد یا کالا بعد از ارسال | بله | همان کسی که نسخهٔ قبل را تایید کرده |
| تبدیل نسخهٔ تاییدنشده به فاکتور | مجاز نیست | — |
عددها و نقش‌ها را خودتان پر کنید. یک تیم ممکن است سقف تخفیف فروشنده را صفر بگذارد و تیم دیگر اختیار بیشتری بدهد. چیزی که نباید بماند، خانهٔ خالی است: موقعیتی که هیچ‌کس نمی‌داند تایید می‌خواهد یا نه.
مسیر روزانه، قدم به قدم
- فروشنده پیش‌نویس را با اقلام، قیمت، شرط پرداخت و مهلت اعتبار کامل میکند.
- اگر همهٔ ردیف‌ها در قاعده‌اند، مستقیم ارسال میکند.
- اگر ردیفی بیرون از قاعده است، سند را به «در انتظار تایید» می‌فرستد و دلیلش را در خود سند می‌نویسد؛ مثلاً «مشتری قدیمی، خرید حجمی».
- تاییدکننده در همان سند تایید یا رد میکند و اگر رد کرد، علت را می‌نویسد.
- فقط نسخهٔ تاییدشده برای مشتری ارسال می‌شود.
- هر تغییر مهم بعد از ارسال، سند را به قدم اول برمی‌گرداند.
- وقتی مشتری پذیرفت، همان نسخه به فاکتور تبدیل می‌شود.
دلیل نوشتن در خود سند مهم است. تاییدی که در تماس تلفنی یا چت داده شده، سه هفته بعد قابل پیدا کردن نیست. اگر مجبور شدید تلفنی تایید بگیرید، همان روز آن را در سند ثبت کنید.
کی تاییدکننده گلوگاه می‌شود؟
اگر پیشفاکتورها ساعت‌ها در صف تایید می‌مانند، معمولاً یکی از این سه مشکل هست: سقف اختیار فروشنده خیلی پایین است، همهچیز به یک نفر وابسته است، یا تاییدکننده فقط از روی پیام خبردار می‌شود. سقف را با نگاه به سندهای ماه قبل تنظیم کنید؛ اگر بیشتر درخواست‌ها بی‌حرف تایید شده‌اند، احتمالاً سقف بیش از حد سخت‌گیر است. یک جانشین هم تعریف کنید تا مرخصی مدیر فروش را متوقف نکند.
نقش‌ها و دسترسی کاربران موضوع گسترده‌تری است: چه کسی چه سندی را ببیند، بسازد یا حذف کند. برای شروع، کافی است فروشنده بتواند پیش‌نویس بسازد و بفرستد، و تایید فقط از دست نقش مجاز بربیاید.
چه اشتباه‌هایی تایید پیش‌فاکتور را بی‌اثر میکند؟
تیم‌هایی که گردش تایید دارند و باز هم قیمت تاییدنشده به مشتری می‌رسد، معمولاً یکی از این اشتباه‌ها را دارند:
- ارسال از بیرون سیستم. فروشنده پیش‌فاکتور را در اکسل یا واتساپ برای مشتری می‌فرستد و بعداً در سیستم ثبت میکند. تایید روی سندی آمده که مشتری ندیده است.
- ویرایش سند تاییدشده. سند بعد از تایید باز است و هر کسی میتواند قیمت را عوض کند. برچسب «تاییدشده» دیگر معنی ندارد.
- تایید شفاهی. مدیر در راهرو می‌گوید «باشه، بفرست». هیچ ردی نمی‌ماند و آخر ماه هیچ‌کس یادش نیست چه کسی چه تخفیفی داده است.
- تایید همهچیز. وقتی همهٔ پیشفاکتورها تایید لازم دارند، مدیر بدون خواندن تایید میکند تا صف خالی شود. کنترلی که از سر عادت امضا شود، کنترل نیست.
- نبود مهلت اعتبار. پیش‌فاکتور سه ماه پیش با قیمت قدیم هنوز معتبر به نظر می‌رسد و مشتری همان را می‌خواهد. مهلت را با تاریخ شمسی روی سند بنویسید و سند منقضی را بدون تایید دوباره به فاکتور تبدیل نکنید.
- تبدیل به فاکتور بدون مقایسهٔ نسخه. نسخه‌ای که مشتری پذیرفته با نسخهٔ تاییدشده فرق دارد و کسی چک نکرده است.
چک‌لیست راه‌اندازی تایید پیش‌فاکتور
- [ ] وضعیت‌های پیش‌فاکتور مشخص و برای همه یکسان است
- [ ] سقف تخفیف و حداقل قیمت فروشنده عددی نوشته شده است
- [ ] شرط‌های پرداخت معمول فهرست شده‌اند و هر شرط دیگر تایید مالی می‌خواهد
- [ ] تاییدکننده و جانشین او برای هر نوع تایید معلوم است
- [ ] فروشنده نمی‌تواند سند خودش را تایید کند
- [ ] سند تاییدشده بدون برگشت به پیش‌نویس ویرایش نمی‌شود
- [ ] دلیل درخواست تایید و دلیل رد، در خود سند ثبت می‌شود
- [ ] هر پیش‌فاکتور مهلت اعتبار شمسی دارد
- [ ] فقط نسخهٔ تاییدشده به فاکتور تبدیل می‌شود
- [ ] هیچ پیشفاکتوری از بیرون سیستم برای مشتری ارسال نمی‌شود
اگر این چک‌لیست را در اکسل پیاده کنید، بخش زیادی از آن به حافظه و نظم افراد وابسته می‌ماند. اکسل نمی‌تواند ویرایش سند تاییدشده را ببندد یا جلوی تبدیل نسخهٔ تاییدنشده را بگیرد. اگر حجم پیش‌فاکتورهای شما کم است و یک نفر همه را می‌بیند، همان فایل مرتب با یک ستون وضعیت فعلاً کافی است و نرم‌افزار تازه لازم ندارید.
وقتی چند فروشنده دارید، روش ثبت داده هم مهم می‌شود. اگر کد کالا و واحد یکسان نیست، تاییدکننده نمی‌تواند قیمت را با فهرست مقایسه کند. پیش از راه‌اندازی تایید، یکی کردن کد کالا و واحد اندازه‌گیری را ببندید. برای مسیر کلی شروع با تیم کوچک هم راه‌اندازی ERP برای شرکت کوچک ایرانی را ببینید.
تینا در این مسیر چه کاری میکند؟
تینا فروش، انبار و مالی عملیاتی را در یک پنل فارسی راست‌به‌چپ با تقویم شمسی کنار هم می‌گذارد. نقش و گردش‌کار بخشی از همین پنل است؛ یعنی می‌شود فروشنده را به ساخت و ارسال پیش‌نویس محدود کرد و تایید را به نقش مجاز سپرد. پیش‌فاکتور و فاکتور هم با چاپ برند و سربرگ شما خارج می‌شوند. تنظیم دقیق سقف‌ها و وضعیت‌ها جزو استقرار است و روی سناریوی خود شما بسته می‌شود. ماژول‌ها را در ویژگی‌های تینا ERP ببینید.
اگر می‌خواهید همین گردش را روی دو یا سه پیش‌فاکتور واقعی خودتان امتحان کنید، دموی تینا را رزرو کنید یا با 09109874872 تماس بگیرید. اول قاعده را روی کاغذ بنویسید، بعد آن را در سیستم ببندید.