کالای جایگزین و کد تکراری ممکن است در نگاه اول شبیه باشند، چون هر دو باعث میشوند برای یک درخواست بیش از یک کد در برابر کاربر قرار بگیرد. اما معنای آنها متفاوت است: کد تکراری یعنی یک قلم واحد بیدلیل چند شناسنامه پیدا کرده؛ کالای جایگزین یعنی دو قلم مستقل، در یک کاربرد و تحت شرایط تعریفشده، میتوانند بهجای یکدیگر استفاده شوند.
اگر این دو مفهوم در نرمافزار یکی شوند، یا موجودی یک کالا میان چند کد پخش میشود، یا هویت اقلام مستقلی که فقط در شرایطی قابل جایگزینیاند از بین میرود. مدل داده باید هم امکان کشف رکوردهای تکراری را بدهد و هم رابطه جایگزینی را بدون ادغام شناسنامهها نگه دارد.
کد تکراری یعنی یک هویت، چند شناسنامه
فرض کنید یک بلبرینگ با سازنده، مدل، ابعاد و مشخصات هویتی یکسان، یک بار با عنوان فارسی و بار دیگر با عنوان انگلیسی ثبت شده است. اگر بررسی مدارک و قواعد سازمان نشان دهد هر دو رکورد همان قلم را معرفی میکنند، با دو آیتم مستقل روبهرو نیستیم؛ یک هویت بهاشتباه دو کد گرفته است.
پیامد فقط شلوغشدن فهرست نیست. بخشی از موجودی، خرید، مدارک و سابقه مصرف روی کد اول و بخشی روی کد دوم مینشیند. کاربر ممکن است روی یک کد کمبود ببیند، در حالی که کالای همان قلم زیر کد دیگر موجود است. راهنمای جلوگیری از کد تکراری معیارهای بررسی این وضعیت را با جزئیات بیشتری توضیح میدهد.
در اصلاح کد تکراری، هدف رسیدن به یک شناسنامه مرجع و حفظ ارجاع کدهای قدیمی است. حذف ساده یکی از رکوردها بدون انتقال کنترلشده روابط، میتواند سابقه اسناد را ناقص کند. نرمافزار باید مشخص کند کدام رکورد مرجع شده و درخواستهایی که با کد قدیمی میآیند به کجا هدایت شوند.
کالای جایگزین همچنان هویت مستقل دارد
دو بلبرینگ از دو سازنده ممکن است ابعاد نصب، ظرفیت و سایر مشخصات لازم برای یک کاربرد را داشته باشند و سازمان استفاده از یکی را بهجای دیگری تأیید کند. با این حال، هرکدام سازنده، مدل، گواهی، قیمت، موجودی و سابقه تأمین خودش را دارد. رابطه جایگزینی این تفاوتها را حذف نمیکند.
در مستندات Microsoft Business Central نیز جایگزین بهصورت رابطه میان آیتم اصلی و آیتم دیگری ثبت میشود؛ وجود این رابطه، جایگزینی خودکار در سفارش یا BOM را الزاماً انجام نمیدهد و سیستم میتواند فقط وجود گزینه را اعلام کند. این نمونه نشان میدهد «قابل جایگزینی بودن» با «یک رکورد بودن» یکی نیست. منبع: تعریف جایگزین کالا در Microsoft Learn
در مدل پیشنهادی این مقاله، هر قلم کد و شناسنامه مستقلش را حفظ میکند و رابطهای جدا توضیح میدهد در کدام کاربرد، با چه وضعیت تأیید و از چه تاریخی میتواند جایگزین قلم دیگر شود.
شباهت، تکراریبودن و جایگزینی سه نتیجه متفاوتاند
خروجی ابزار تطبیق یا جستوجوی مشابهت باید «نامزد بررسی» باشد، نه حکم نهایی. برابر بودن قطر داخلی دو بلبرینگ ثابت نمیکند تمام مشخصات هویتی آنها برابر است؛ همانطور که تفاوت سازنده لزوماً جایگزینی را رد یا تأیید نمیکند.
| نتیجه بررسی | معنای مدل | اقدام مناسب |
|---|---|---|
| رکوردهای تکراری | هر دو رکورد یک قلم را معرفی میکنند | انتخاب شناسنامه مرجع و حفظ نگاشت کد قدیمی |
| اقلام مشابه | چند ویژگی مشترک است، تصمیم هنوز کامل نیست | نمایش تفاوتها و ارجاع برای بررسی |
| اقلام جایگزین | دو قلم مستقل برای کاربرد مشخص قابل جانشینیاند | ثبت رابطه، دامنه، اولویت و وضعیت تأیید |
| اقلام نامتناسب | تفاوت مؤثر، استفاده جایگزین را رد میکند | حفظ شناسنامهها بدون رابطه جایگزینی |
برای رسیدن به این نتایج، نرمافزار باید مقایسه ویژگیهای ساختاریافته را پشتیبانی کند. عنوان آزاد بهتنهایی کافی نیست. مقاله شناسنامه فنی کالا توضیح میدهد چرا مقدار، واحد و تعریف ویژگی باید از نام جدا باشند.
مثال صنعتی: سه بلبرینگ برای یک موقعیت نصب
مثال زیر فرضی است. یک موقعیت نصب در مجموعه پمپ به بلبرینگی با مشخصات معین نیاز دارد. سه کد در فهرست اقلام دیده میشود:
| کد فرضی | وضعیت پس از بررسی | دلیل |
|---|---|---|
BRG-101 |
قلم مرجع | شناسنامه و مدارک تأییدشده |
BRG-101-A |
تکراریِ قلم مرجع | همان سازنده، همان مدل و همان مشخصات؛ فقط نامگذاری متفاوت |
BRG-205 |
جایگزین مشروط | سازنده و مدل متفاوت؛ برای همین موقعیت نصب تأیید شده |
در پاکسازی داده، BRG-101-A باید به شناسنامه مرجع نگاشت شود و ارجاع اسناد قبلی حفظ شود. اما BRG-205 نباید با BRG-101 ادغام شود. موجودی آن جداست و هنگام برداشت باید معلوم باشد کدام قلم واقعی تحویل شده است.
اگر جایگزین برای همه کاربردهای BRG-101 تأیید نشده باشد، رابطه باید به همان موقعیت نصب یا دامنه مصرف محدود شود. عبارت کلی «جایگزین است» بدون بیان دامنه، ممکن است مجوزی گستردهتر از تصمیم واقعی بسازد.
رابطه جایگزینی جهت، دامنه و اولویت میخواهد
گاهی جایگزینی دوطرفه است: قلم الف و ب میتوانند در شرایط یکسان جای یکدیگر قرار گیرند. گاهی یکطرفه است: قلم جدید میتواند جای قلم قدیمی استفاده شود، ولی بازگشت به قلم قدیمی مجاز یا مطلوب نیست. نرمافزار نباید دوطرفهبودن را از صرف وجود یک رابطه حدس بزند.
در برنامهریزی مواد Microsoft Dynamics 365، گروهی از اقلام میتوانند برای یک ماده در فرمول یا BOM بهعنوان جایگزین تعریف شوند و برای آنها اولویت گذاشته شود؛ برنامهریزی ابتدا قلم ترجیحی و سپس جایگزین موجود با اولویت بالاتر را بررسی میکند. این رفتار مربوط به همان محصول است، اما از نظر مفهومی نشان میدهد رابطه جایگزینی میتواند وابسته به کاربرد و دارای اولویت باشد. منبع: جایگزینی اقلام در فرمول و BOM در Microsoft Learn
برای مدل داخلی، حداقل این پرسشها را روشن کنید: رابطه در چه کاربردی معتبر است؟ یکطرفه است یا دوطرفه؟ قلم ترجیحی کدام است؟ چه کسی و بر اساس کدام مدرک آن را تأیید کرده؟ از چه تاریخی معتبر است و آیا تاریخ پایان دارد؟
مقدار مصرف و واحد را مستقل بررسی کنید
جایگزینی همیشه یکبهیک نیست. ممکن است برای یک واحد از قلم اصلی، مقدار دیگری از جایگزین لازم باشد یا واحد موجودی دو قلم متفاوت باشد. بنابراین نرمافزار نباید فقط کد را عوض کند و مقدار قبلی را بدون کنترل نگه دارد.
حتی در جایی که مقدار برابر است، باید واحد روشن باشد. «یک بسته» از دو قلم میتواند تعداد متفاوتی قطعه داشته باشد. راهنمای واحد سنجش و بستهبندی توضیح میدهد چرا واحد پایه، بستهبندی و ضریب تبدیل باید از هم قابل تشخیص باشند.
در مثال بلبرینگ فرضی ما، رابطه جایگزینی در سطح «عدد» و نسبت یکبهیک تأیید شده است. اگر بعداً نحوه بستهبندی تأمینکننده تغییر کند، این تغییر نباید نسبت مصرف فنی را خودکار عوض کند؛ بسته خرید و مقدار مصرف دو موضوع جدا هستند.
تاریخ اعتبار و علت رابطه را ثبت کنید
یک جایگزین ممکن است موقت باشد؛ مثلاً تا پایان کمبود قلم ترجیحی. ممکن است فقط برای سفارشهایی که بعد از یک تغییر طراحی ایجاد میشوند معتبر باشد. بدون تاریخ و وضعیت، رابطهای که زمانی درست بوده میتواند سالها بعد بدون بازبینی استفاده شود.
پیشنهاد مدل داده این است که رابطه جایگزینی وضعیتهایی مانند پیشنهادی، در انتظار بررسی، تأییدشده، تعلیقشده و پایانیافته داشته باشد. نام دقیق وضعیتها به گردش سازمان بستگی دارد، ولی مقدار پیشنهادی نباید با تأیید قطعی یکی دیده شود.
مرجع تصمیم نیز باید قابل پیگیری باشد: نقشه، مشخصات فنی، نامه سازنده، نتیجه آزمون یا تصمیم مسئول مجاز. ثبت نام فایل بهتنهایی کافی نیست؛ نسخه و ارتباط آن با قلم و کاربرد باید معلوم باشد. مقاله کیفیت داده کالا مرز میان داده موجود، معتبر و تأییدشده را توضیح میدهد.
مصرف واقعی باید قلم واقعی را نشان دهد
اگر درخواست برای قلم اصلی ثبت شده ولی جایگزین تحویل میشود، سابقه باید هر دو واقعیت را نگه دارد: چه قلمی درخواست شده و چه قلمی واقعاً تحویل یا نصب شده است. بازنویسی خط درخواست بهگونهای که انتخاب اولیه ناپدید شود، تحلیل تصمیم و مصرف را دشوار میکند.
این تفکیک برای نمونههای سریالدار اهمیت بیشتری دارد. باید معلوم باشد کدام آیتم جایگزین انتخاب شد و دقیقاً کدام سریال از آن آیتم نصب شد. رابطه جایگزینی میان آیتمها، هویت نمونه فیزیکی را ایجاد نمیکند. برای مرز آیتم و نمونه، مدل هویت سهلایه کالا را ببینید.
همچنین نباید موجودی دو قلم جایگزین در یک عدد ادغام شود. میتوان نمایی از مجموع ظرفیت قابل استفاده برای یک نیاز ساخت، اما ردیفهای موجودی، ارزش، بچ و سریال هر قلم باید قابل تفکیک بمانند.
نرمافزار را با سناریوی ادغام و جایگزینی بسنجید
برای ارزیابی نرمافزار، سه کد مثال را وارد کنید و این مسیر را آزمایش کنید:
- دو رکورد تکراری را مقایسه و یکی را مرجع کنید؛ کد قدیمی و اسنادش باید قابل بازیابی بمانند.
- قلم جایگزین را بدون ادغام شناسنامه به قلم مرجع مرتبط کنید.
- رابطه را فقط برای یک کاربرد و یک بازه زمانی فعال کنید.
- یک جایگزینی یکطرفه و یک رابطه دوطرفه بسازید؛ سیستم باید تفاوت را نشان دهد.
- هنگام درخواست قلم اصلی، گزینه جایگزین را ببینید ولی انتخاب واقعی و مسئول تصمیم ثبت شود.
- در سند خروج یا نصب، کد و در صورت نیاز سریال قلم تحویلشده حفظ شود.
اینها معیارهای پیشنهادی برای سنجش مدلاند و به معنی تأیید قابلیتهای فعلی ایدنتو نیستند. بخش قابلیتهای ایدنتو نگاه کلی محصول را معرفی میکند؛ قواعد جایگزینی هر سازمان باید با مسئولان فنی و داده همان سازمان تعریف شود.
پرسشهای متداول درباره کالای جایگزین و کد تکراری
آیا دو کالای جایگزین باید یک کد داشته باشند؟
خیر. اگر دو قلم مستقلاند، هرکدام شناسنامه و کد خود را دارند. امکان استفاده بهجای یکدیگر بهصورت رابطهای جدا و محدود به شرایط تأییدشده ثبت میشود.
آیا شباهت همه مشخصات یعنی دو رکورد تکراریاند؟
شباهت قوی، نامزد بررسی ایجاد میکند. تصمیم نهایی باید دامنه شناسایی، مدارک، سازنده و مدل و قواعد سازمان را در نظر بگیرد؛ ابزار تطبیق نباید خودکار حکم ادغام بدهد.
آیا جایگزین باید خودکار در سفارش انتخاب شود؟
نه همیشه. سازمان باید مشخص کند سیستم فقط گزینه را پیشنهاد دهد یا در یک فرایند معین با قواعد اولویت انتخاب کند. تصمیمهای حساس ممکن است به تأیید مسئول نیاز داشته باشند.
با پایان اعتبار جایگزین، سوابق قبلی چه میشوند؟
رابطه پایان مییابد، اما مصرفها و تصمیمهای گذشته باید با وضعیت معتبر همان زمان باقی بمانند. حذف رابطه یا بازنویسی تاریخچه، دلیل استفاده قبلی را از بین میبرد.