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