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