اگر برای حسابوکتاب فروشگاه، خروجی «صورتحسابهای قبلی» را کنار گزارش بخش مالی جدید دیجیکالا نگه میدارید، جمعزدن همه فایلها میتواند یک فروش یا پرداخت را چند بار وارد دفتر داخلی شما کند. راه درست، تعیین مرز بین گزارشهای تاریخی و جاری و تشخیص تفاوت «رویداد مالی» با «نمایش دوباره وضعیت همان رویداد» است. این مقاله روش کنترل فایلهای خود فروشنده را توضیح میدهد؛ ادعا نمیکند که دیجیکالا تراکنشی را دوبار ثبت کرده است.
چه چیزی در منبع رسمی تأیید شده است؟
اطلاعیه رسمی فروشندگان دیجیکالا درباره بخش مالی جدید، بررسیشده در ۲۳ اکتبر ۲۰۲۶، از مشاهده جزئیات تراکنشها، پیگیری مسیر ثبت تا تسویه و دسترسی به صورتحسابهای قبلی خبر میدهد. این خبر دلیل مناسبی برای بازبینی روش جمعکردن گزارشهای داخلی است؛ اما مشخص نمیکند فایلهای دانلودی هر حساب دقیقاً چه ستونهایی دارند یا مرز انتقال اطلاعات آن حساب چه تاریخی است. ستونها و دامنه هر فایل را باید از خروجی واقعی همان پنل بخوانید.
این نوشته نرخ کمیسیون، مالیات یا موعد تسویه اعلام نمیکند. همه اعداد زیر فرضی و به توماناند؛ کاربردشان آزمودن دفتر داخلی است، نه بازسازی صورتحساب یک فروشنده واقعی.
اول مشخص کنید هر فایل چه چیزی را نشان میدهد
برای هر فایل، نام گزارش، زمان دریافت، محدوده زمانی، واحد پول و مبنای تاریخ را ثبت کنید. «تاریخ ثبت سفارش»، «تاریخ رویداد مالی» و «تاریخ واریز بانکی» میتوانند سه تاریخ متفاوت باشند. دو فایل با برچسب یک ماه، الزاماً مجموعه یکسانی از رویدادها نیستند.
سپس بپرسید فایل فهرست رویدادهاست یا تصویر وضعیت حساب در یک لحظه؟ اگر امروز یک طلب را «در انتظار» و فردا همان طلب را «تسویهشده» میبینید، تغییر وضعیت بهتنهایی فروش تازه ایجاد نمیکند. در دفتر وضعیت، آخرین وضعیت معتبر همان ردیف جای قبلی مینشیند. در دفتر رویداد، فقط رویداد مستقل و مستند افزوده میشود. این دو دفتر را بدون تعریف روشن با هم جمع نزنید.
مثال: یک فروش، دو خروجی و یک واریز
فرض کنید یک فروش ۲٬۰۰۰٬۰۰۰ تومانی با مجموع کسورات مستند ۲۴۰٬۰۰۰ تومان دارید. طلب خالص مربوط به این فروش ۱٬۷۶۰٬۰۰۰ تومان است. در فایل روز اول، این طلب هنوز پرداخت نشده و در فایل روز دوم همان طلب به پرداخت مشخصی مرتبط شده است.
اگر دو فایل را زیر هم بچسبانید و ستون طلب خالص را جمع کنید، ۳٬۵۲۰٬۰۰۰ تومان به دست میآید؛ در حالی که در این مثال فقط یک طلب ۱٬۷۶۰٬۰۰۰ تومانی وجود دارد. اگر واریز بانک را هم «درآمد فروش» ثبت کنید، عدد باز هم بزرگتر میشود. واریز، تبدیل طلب به وجه نقد است و فروش دوم نیست.
در دفتر داخلی پیشنهادی، شناسه پایدار ردیف مالی ــ اگر در خروجی موجود باشد ــ مبنای تشخیص همان ردیف است. شناسه سفارش بهتنهایی همیشه کافی نیست؛ یک سفارش میتواند چند قلم یا چند رویداد داشته باشد. مبلغ مساوی نیز نشانه تکراریبودن نیست: دو سفارش مستقل ممکن است دقیقاً یک مبلغ داشته باشند. اگر شناسه کافی ندارید، ردیفهای مشکوک را جدا کنید و با سند بررسی کنید؛ حذف خودکار بر اساس مبلغ و تاریخ قابل اتکا نیست.
مرز گزارش قدیمی و جدید را چگونه ببندیم؟
یک نقطه برش مستند برای دفتر خود انتخاب کنید. برای مثال، مانده تأییدشده تا پایان یک تاریخ را از گزارش تاریخی بیاورید و فقط رویدادهای بعد از آن را به دفتر جاری اضافه کنید. این تاریخ را از روی حدس درباره زمان تغییر ظاهر پنل تعیین نکنید. باید بتوانید توضیح دهید هر ردیف در کدام طرف مرز قرار گرفته و چرا.
فرض دوم: مانده آغاز دفتر ۸٬۰۰۰٬۰۰۰ تومان است. پس از نقطه برش، ۱۲٬۰۰۰٬۰۰۰ تومان طلب خالص تازه و ۷۰۰٬۰۰۰ تومان اصلاح کاهنده مستند ثبت میشود. بانک هم ۹٬۰۰۰٬۰۰۰ تومان واریزی مرتبط نشان میدهد. مانده پایان محاسباتی برابر است با ۱۰٬۳۰۰٬۰۰۰ تومان: هشت میلیون، بهعلاوه دوازده میلیون، منهای هفتصد هزار و منهای نه میلیون.
اگر همین دفتر ۱۲٬۰۶۰٬۰۰۰ تومان نشان دهد، اختلاف ۱٬۷۶۰٬۰۰۰ تومانی ارزش بررسی دارد؛ ممکن است طلب مثال اول دوبار وارد شده باشد، اما برابر بودن عدد اثبات آن نیست. شناسهها و اسناد باید فرضیه را تأیید کنند. اختلاف را با ساختن ردیف «هزینه متفرقه» نبندید.
سه کنترل قبل از اتکا به گزارش
نخست، تعداد ردیفها را پیش و پس از حذف تکرار مقایسه کنید و فهرست ردیفهای کنارگذاشتهشده را نگه دارید. دوم، مجموع هر نوع رویداد را جدا ببینید: فروش، کسورات، اصلاحات و پرداخت. سوم، مانده پایان را با منبع مستقل در دسترس، مانند گزارش حساب و واریزیهای بانکی مرتبط، تطبیق دهید. یکسانشدن جمع کل بهتنهایی کافی نیست؛ دو خطا میتوانند اثر یکدیگر را خنثی کنند.
واحد ریال و تومان را در ابتدای پردازش مشخص کنید. نسخه اصلی فایل را تغییر ندهید و اصلاحات را در نسخه کاری با توضیح ثبت کنید. اگر سندی مبلغ را به ریال دارد، تبدیل به تومان تقسیم بر ده است؛ واحد را از بزرگی عدد حدس نزنید.
نتیجهای که باید بتوانید تحویل بدهید
دفتر قابل بررسی باید برای هر مانده، مسیر رسیدن به آن را نشان دهد: منبع تاریخی، رویدادهای جدید، اصلاحات و پرداختهای مرتبط. اختلاف باز نیز باید مبلغ، سند موردنیاز و مسئول پیگیری داشته باشد. بدون این مسیر، عدد بزرگ فروش میتواند تصمیم خرید موجودی را گمراه کند.
این کار با تصمیم درباره صرفه تسویه زودهنگام دیجیکالا متفاوت است: ابتدا طلب و وجه نقد را درست بشمارید، سپس درباره تأمین مالی تصمیم بگیرید. برای کنترلهای عمومیتر، گزارش فروش روزانه را ببینید.
در سودین، صفحه دیجیکالا مسیر بررسی نیاز و درخواست اتصال را توضیح میدهد؛ این مقاله وعده اتصال مالی آماده یا تطبیق خودکار حساب دیجیکالا نیست. تصویر همراه مقاله تولیدشده و مفهومی است و سند پنل یا حساب مشتری واقعی را نمایش نمیدهد.
