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