از سفارش بازارگاه تا حسابداری؛ راهنمای کنترل فروش، موجودی و تسویه

یک سفارش آنلاین در واقع پنج دفتر عملیاتی دارد

برای حسابداری سفارش بازارگاه، نخست باید واژه «سفارش» را از چند رویداد جدا کنیم. سفارش پذیرفته‌شده یک تعهد عملیاتی است؛ رزرو یا خروج کالا رویداد انبار است؛ تحویل یا تحقق شرایط فروش مبنای ثبت درآمد طبق رویه شرکت است؛ صورت‌وضعیت بازارگاه یک مطالبه یا بدهی متقابل می‌سازد؛ و واریز بانکی فقط تسویه نقدی آن مانده است. GS1 فرایند سفارش تا وصول را زنجیره‌ای از سفارش‌دهی، تحویل و پرداخت می‌بیند. اگر همه این مراحل در یک وضعیت خلاصه شوند، تیم نمی‌تواند بفهمد اختلاف از لغو، کسری انبار، کارمزد یا بانک آمده است. ^[۱]

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

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

وضعیت بازارگاه را به سیاست شناسایی درآمد ترجمه کنید، نه به سند خودکار

برچسب‌هایی مانند «جدید»، «آماده‌سازی»، «ارسال شد»، «تحویل شد»، «لغو» و «بسته شد» معنای حسابداری جهان‌شمول ندارند. قرارداد با بازارگاه، کنترل کالا، شرایط تحویل، امکان رد مشتری، مدل فروشندگی و رویه مصوب شرکت تعیین می‌کنند چه زمانی فروش ثبت شود. بنابراین یک جدول نگاشت نسخه‌دار بسازید: وضعیت کانال، شاهد لازم، اثر انبار، اثر فروش، اثر مالیات و اقدام در خطا. تغییر متن یا منطق یک وضعیت در API نباید بدون تأیید مالی به تغییر خودکار ثبت‌ها منجر شود. ^[۱]

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

سند خودکار باید پشت یک دروازه کنترل باشد: شناسه سفارش تکراری نباشد، جمع اقلام با جمع سفارش و صورت‌وضعیت سازگار باشد، وضعیت مجاز تحقق ثبت شده باشد، شناسه کالا و مرکز فروش نگاشت معتبر داشته باشند و دوره مالی باز باشد. رکورد ناقص به صف استثنا برود، نه اینکه با حساب «سایر» یا کالای پیش‌فرض ثبت شود. سرعت واقعی از حذف کار دوباره می‌آید؛ ثبت سریعِ بی‌هویت فقط مغایرت را به پایان ماه منتقل می‌کند. ^{[۱] [۳]}

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

رزرو، خروج و بازگشت موجودی را سه رویداد جدا نگه دارید

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

اصل کنترل فیزیکی در مستندات Shopify نیز روشن است: دریافت موجودی باید در زمان دریافت واقعی و با ثبت جزئیات انجام شود تا سابقه قابل ممیزی و تطبیق باقی بماند. این مستندات نسخه تجویزی برای ایران نیست، اما یک هشدار عملی دارد: پیام دیجیتال «رسید» یا «مرجوع شد» جای مشاهده وضعیت کالای برگشتی را نمی‌گیرد. کالا ممکن است سالم و قابل‌فروش، نیازمند بازبسته‌بندی، معیوب، منقضی یا متعلق به فروشنده دیگری باشد؛ هر نتیجه مقصد انبار و اثر بهای تمام‌شده متفاوتی دارد. ^[۶]

کنترل روزانه انبار باید از سفارش به حرکت کالا و از حرکت کالا به سفارش برگردد. سفارش تحویل‌شده بدون خروج، خروج بدون سفارش معتبر، مرجوعی تأییدشده بدون ورود یا اسقاط، و کالای رزروشده قدیمی چهار صف اصلی‌اند. برای کالای وزنی، جایگزین‌شده یا دارای بچ و تاریخ مصرف، مقدار اولیه و مقدار نهایی را جدا نگه دارید. هیچ الگوریتمی نباید اختلاف فیزیکی را با تغییر بی‌ردپای تعداد سفارش «حل» کند؛ اصلاح باید علت، تأییدکننده و سند مستقل داشته باشد. ^{[۲] [۶]}

آبشار تسویه را از فروش ناخالص تا واریز بانک باز کنید

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

فرمول کنترل را نمادین نگه دارید: مانده اول دوره مطالبات از بازارگاه، به‌علاوه فروش و سایر مبالغ قابل‌دریافت، منهای بازپرداخت‌ها و کسورات معتبر، منهای واریزها، باید با مانده پایان صورت‌وضعیت برابر شود. گزارش تطبیق پرداخت Stripe نیز پرداخت دسته‌ای را به تراکنش‌های زیرین وصل می‌کند و فیلدهای مبلغ ناخالص، کارمزد، خالص، بازپرداخت و شناسه را برای ردیابی پیشنهاد می‌دهد. مفهوم برای هر بازارگاه مفید است، حتی اگر قالب فایل و قرارداد آن کاملاً متفاوت باشد. ^{[۴] [۳]}

صورت‌وضعیت را به سه سطح بشکنید: سربرگ دوره و حساب تسویه، ردیف‌های مالی قابل نگاشت، و ارتباط هر ردیف با سفارش یا دلیل تعدیل. ردیف بدون سفارش الزاماً خطا نیست—ممکن است هزینه اشتراک یا اصلاح تجمیعی باشد—اما باید نوع، قرارداد و تأیید داشته باشد. اگر بازارگاه فقط جمع کل می‌دهد، از آن به‌عنوان محدودیت کنترل یاد کنید و نمونه تفصیلی یا گزارش پشتیبان بخواهید. «جمع برابر شد» کافی نیست؛ دو خطای هم‌اندازه می‌توانند همدیگر را پنهان کنند. ^{[۴] [۳]}

کارمزد، تخفیف و ارسال را با مالک اقتصادی‌شان ثبت کنید

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

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

ملاحظات مالیاتی و نوع مدرک هر کسری را با مشاور مالیاتی و آخرین مقررات ایران تعیین کنید. این مقاله نرخ، اعتبار یا نحوه صدور صورتحساب برای قرارداد مشخصی را تجویز نمی‌کند، زیرا نقش حقوقی بازارگاه و فروشنده، نوع خدمت و مفاد قرارداد متفاوت است. کنترل قابل تعمیم این است: هیچ کسری بدون کد، مالک، مدرک، دوره و حساب نماند و تیم بتواند از ردیف هزینه به بند قرارداد و از بند قرارداد به مجموعه سفارش‌های مشمول برگردد. ^{[۷] [۳]}

مرجوعی کالا، بازپرداخت پول و اصلاح فروش یک چیز نیستند

مستندات Shopify میان بازگشت کالا، بازپرداخت وجه و بازگرداندن کالا به موجودی تمایز می‌گذارد و امکان بازپرداخت جزئی را نیز جدا نشان می‌دهد. این تفکیک برای طراحی فرایند مهم است: مشتری ممکن است پول بگیرد ولی کالا هنوز نرسیده باشد؛ کالا ممکن است برگردد ولی قابل‌فروش نباشد؛ و بازارگاه ممکن است بازپرداخت را از تسویه دوره بعد کم کند. ثبت یک وضعیت «مرجوع شد» نمی‌تواند هم‌زمان این سه واقعیت را اثبات کند. ^[۵]

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

از منظر دفتر، چهار کنترل جدا لازم است: اصلاح درآمد یا بدهی بازپرداخت، اثر بهای تمام‌شده، ورود یا اسقاط موجودی و اثر صورت‌وضعیت بازارگاه. برگشت کامل و جزئی مسیر یکسانی ندارند. اگر کالا جایگزین می‌شود، سفارش جایگزین را به اصل وصل کنید و حمل دوم را پنهان نکنید. اگر کارمزد در مرجوعی مسترد نمی‌شود، آن را با مفاد قرارداد و ردیف تسویه تطبیق دهید. هدف این نیست که هر مرجوعی فوراً بسته شود؛ هدف آن است که وضعیت باز و مالک اقدام همیشه معلوم باشد. ^{[۵] [۸]}

مغایرت‌گیری پنج‌طرفه را روزانه و دوره‌ای اجرا کنید

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

هر اختلاف یک «پرونده مغایرت» است: نوع اختلاف، مبلغ یا تعداد، منبع کشف، شناسه‌های مرتبط، مالک، مهلت داخلی، مدرک، اقدام و نتیجه. وضعیت‌های پیشنهادی می‌تواند جدید، در بررسی، منتظر بازارگاه، اصلاح عملیاتی، اصلاح مالی و بسته باشد. حذف یا صفرکردن اختلاف بدون ثبت نتیجه ممنوع باشد. برای جلوگیری از انباشت، سن اقلام باز را گزارش کنید و اختلاف‌های تکرارشونده را بر اساس علت ریشه‌ای گروه‌بندی کنید؛ اصلاح نگاشت یا قرارداد از بستن دستی صدها ردیف مؤثرتر است. ^{[۱] [۳]}

سه عدد مدیریتی کمک می‌کند: درصد سفارش‌هایی که بدون مداخله تا تسویه تطبیق شده‌اند، ارزش و سن مغایرت باز، و فاصله زمانی میان تحویل تا شناسایی و تا وصول. این‌ها را به‌عنوان ابزار بهبود ببینید، نه هدف نمایشی. افزایش نرخ تطبیق خودکار وقتی خوب است که آستانه‌ها شل نشده باشند. یک نمونه سفارش را هر ماه از فایل خام تا بانک و دفتر کل بازاجرا کنید تا مطمئن شوید داشبورد از منبع درست تغذیه می‌شود. ^{[۴] [۱] [۳]}

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

پیاده‌سازی را با فایل نمونه آغاز کنید و مرز محصول را شفاف بمانید

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

در دموی هر نرم‌افزار، یک سفارش موفق کافی نیست. لغو پیش از ارسال، کسری یک قلم، جایگزینی کالا، مرجوعی جزئی، بازپرداخت در دوره بعد، کارمزد متفاوت و واریز تجمیعی را اجرا کنید. سپس از گزارش تسویه تا سند و از سند تا سفارش کاوش کنید. بپرسید اتصال API چگونه خطای شبکه، تکرار پیام، تغییر نسخه و برگشت داده را مدیریت می‌کند و چه کسی صف خطا را می‌بیند. ادعای «یکپارچه» بدون سناریوی برگشت و مغایرت، هنوز شاهد کنترل نیست. ^{[۵] [۴]}

مرز ژرف‌بان در تاریخ ۷ شهریور ۱۴۰۵ روشن است: این مقاله هیچ اتصال فعال یا تأییدشده‌ای به اسنپ‌مارکت، نرم‌افزار دشت یا بازارگاه مشخصی معرفی نمی‌کند. حوزه همگام‌سازی فروشگاه اینترنتی و بازارگاه در نقشه راه محصول با وضعیت در حال ساخت نمایش داده شده است؛ وضعیت واقعی، دامنه داده و تاریخ دسترسی باید در همان صفحه و یک دموی تکرارپذیر بررسی شود. قابلیت‌های فعال مالی و انبار نیز جای اثبات اتصال کانال نیستند. تا ارائه شاهد فنی، این راهنما چارچوب خرید و کنترل بی‌طرف است. ^{[۲] [۵] [۴]}