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