تبدیل واحد کالا؛ ضریب خرید و انبار را چه زمانی تغییر دهیم؟

تصمیم واقعی: تغییر ضریب، تعریف بسته تازه یا توقف ثبت؟

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

در مستند Business Central، واحد پایه مبنای نگهداری موجودی و تبدیل به واحدهای دیگر است؛ واحدهای جایگزین می‌توانند در خرید، تولید یا فروش استفاده شوند. این تمایز مهم است: «دو کارتن» یک مقدار همراه با واحد معاملاتی است و برای رسیدن به مقدار پایه به رابطه‌ای مشخص نیاز دارد. عدد بدون واحد یا واحد بدون مشخصات بسته، ورودی کامل حسابداری انبار نیست. ^[۱]

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

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

تبدیل واحد کالا را به یک قرارداد داده روشن تبدیل کنید

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

Oracle در راهنمای Inventory نسخه ۱۲٫۲، تبدیل عمومی، تبدیل مخصوص کالا در یک دسته سنجش و تبدیل بین دسته‌های سنجش را جدا می‌کند؛ همچنین تبدیل مخصوص بچ یا لات را توضیح می‌دهد. پس نسبت کیلوگرم به گرم را نباید با نسبت کارتن به عدد یکی دانست. اولی رابطه واحدهاست، اما دومی به محتویات همان بسته وابسته است. یک کد عمومی «کارتن» نباید بی‌بررسی، ضریب کالای دیگری را به ارث بدهد. ^[۳]

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

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

مثال آموزشی: کارتن دوازده‌تایی به ده‌تایی تبدیل شده است

فرض کنید شرکت، یک قطعه را با واحد پایه «عدد» نگه می‌دارد. بیست کارتن قدیمی، هرکدام دوازده عدد، در انبار دارد؛ یعنی ۲۴۰ عدد. سفارش تازه شامل ده کارتن با بسته‌بندی ده‌تایی است. قیمت هر کارتن تازه در این مثال ساختگی ۶۰۰ هزار ریال و کل خرید ۶ میلیون ریال است. موجودی ابتدای مثال، مقدار دریافتی و قیمت‌ها فقط برای آموزش محاسبه‌اند؛ مالیات، کرایه، تخفیف و گردش دیگر را کنار گذاشته‌ایم.

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

مسیر درست باید پس از دریافت، ۳۴۰ عدد موجودی نشان دهد: ۲۴۰ عدد قبلی به‌علاوه ۱۰۰ عدد تازه. اگر دریافت غلط اصلاح نشده باشد، عدد ظاهری ۳۶۰ خواهد بود. در مقابل، اگر گزارشگری موجودی قدیمی را صرفاً «بیست کارتن» ذخیره یا بازتفسیر کند و اکنون آن را در ضریب ده ضرب کند، گذشته به‌اشتباه ۲۰۰ عدد دیده می‌شود. این دو حالت، دو خطر متفاوت‌اند؛ رفتار واقعی نرم‌افزار را باید آزمود، نه اینکه یکی را برای همه سامانه‌ها فرض کرد.

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

بسته‌بندی تازه را با خطای گذشته مخلوط نکنید

در استاندارد مدیریت GTIN نسخه ۱٫۱، مصوب سپتامبر ۲۰۲۳، تغییر تعداد اقلام داخل کارتن یا تعداد کارتن در چیدمان ازپیش‌تعریف‌شده پالت، مستلزم GTIN تازه در سطح بسته‌بندی مربوط است. قاعده درباره سطوح بالاتر بسته‌بندی است و نباید به تغییر اجباری شناسه تک‌قلم در همه حالت‌ها تعبیر شود. این منبع نشان می‌دهد تفاوت بسته‌ها فقط یک شرح ظاهری نیست؛ شرکای زنجیره تأمین باید بتوانند آن‌ها را تشخیص دهند. ^[۴]

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

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

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

وقتی وزن متغیر است یا مقدار گرد می‌شود

برای برخی اقلام، تعداد بسته و وزن واقعی دو مشاهده‌اند، نه دو نمایش کاملاً معادل. مستند Microsoft درباره کالای وزن‌متغیر، نسبت اسمی، حدود وزن و زمان ثبت وزن واقعی را جدا تعریف می‌کند و نشان می‌دهد رفتار تعدیل به سیاست و فرایند وابسته است. از این مثال نرم‌افزاری نباید نتیجه گرفت که میانگین وزن همیشه جانشین اندازه‌گیری تحویل یا مبنای صورتحساب است. ^[۵]

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

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

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

چک‌لیست پذیرش: شاهد قبل از مجوز

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

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

تصویب محدود و رصد پس از اولین گردش واقعی

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

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

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

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