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