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