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