جلوگیری از کد تکراری کالا از توافق بر سر «یکسانبودن دو قلم» شروع میشود. دو نام متفاوت ممکن است به یک کالا اشاره کنند و دو نام یکسان ممکن است مشخصات متفاوتی داشته باشند. بنابراین پیش از ساخت کد تازه، باید مشخصات تعیینکننده، واحد، مرجع سازنده و شناسههای موجود بررسی شوند. هدف، داشتن یک شناسنامه قابل اتکا برای هر قلم است؛ شناسنامهای که خرید و انبار بتوانند به آن ارجاع دهند.
این راهنما برای زمانی است که فهرست کالا از چند فایل، واحد سازمانی یا نرمافزار قدیمی جمع شده و جستوجو در آن نتیجه روشنی نمیدهد. مثالها فرضیاند و قواعد پیشنهادی باید با تعریف آیتم و نیاز عملیاتی سازمان تطبیق داده شوند.
کد تکراری کالا دقیقاً چه مشکلی ایجاد میکند؟
فرض کنید یک شیر صنعتی با دو کد داخلی ثبت شده است. انبار روی کد اول موجودی دارد، اما درخواست خرید با کد دوم ثبت میشود. کارشناس با دیدن موجودی صفرِ کد دوم، ممکن است خرید تازهای پیشنهاد کند. در این وضعیت، مشکل فقط املای نام نیست؛ اطلاعات یک قلم میان چند شناسنامه پخش شده است.
در جهت مقابل، اگر دو شیر متفاوت را صرفاً بهدلیل نام مشابه یک کالا بدانیم، موجودی آنها بهاشتباه کنار هم قرار میگیرد. پس کیفیت داده دو هدف همزمان دارد: پیدا کردن شناسنامههای اضافی و حفظ تفاوتهای واقعی.
منظور از «کد تکراری» در این مقاله، چند شناسه داخلی برای یک قلم واحد است. تکرار خودِ رشته کد، مسئله دیگری است که باید با قاعده یکتایی در دامنه تعریفشده کنترل شود. یکتا بودن شمارهها، بهتنهایی جلوی ثبت دوباره یک کالا با شمارهای تازه را نمیگیرد.
نام کالا، شناسه داخلی و کد فروشنده را جدا نگه دارید
نام برای خواندن و جستوجوی انسان است؛ شناسه داخلی برای ارجاع پایدار به شناسنامه. کد فروشنده نیز در زمینه همان فروشنده معنا پیدا میکند. تغییر فروشنده یا تغییر شیوه نوشتن نام، لزوماً آیتم تازهای ایجاد نمیکند.
برای نمونه، یک قلم میتواند یک کد داخلی و چند مرجع تأییدشده در فهرست فروشندگان داشته باشد. برای هر مرجع، صاحب کد، خود کد و ارتباط آن با آیتم را ثبت کنید. وجود کد مشابه در دو فهرست مستقل، بدون شناخت صاحب آن کد، دلیل کافی برای یکسانبودن کالا نیست.
مستندات Microsoft Dynamics 365 نیز شماره محصول، نام و شناسههای خارجی مشتری یا فروشنده را جدا توضیح میدهد؛ در آن سامانه، نام محصول الزاماً یکتا نیست. این تفکیک، نمونهای از جداکردن هویت اصلی از نامها و مراجع جانبی است. منبع: انواع شناسه محصول در Microsoft Learn
اگر مرز کلاس، آیتم و نمونه فیزیکی هنوز روشن نیست، ابتدا راهنمای کدینگ کالا با مدل هویت سهلایه را بخوانید. تفاوت سریال یا بچ را نباید خودکار به تفاوت آیتم تبدیل کرد.
برای هر کلاس، مشخصات تعیینکننده هویت را بنویسید
پیش از پاکسازی اطلاعات کالا، مشخص کنید در هر خانواده کدام ویژگیها برای تشخیص قلم ضروریاند. برای یک خانواده فرضی از شیرهای صنعتی، ممکن است نوع شیر، اندازه اسمی، نوع اتصال، مشخصات بدنه و مدل سازنده در این تصمیم نقش داشته باشند. این فهرست، مشخصات کامل انتخاب مهندسی شیر نیست؛ فقط مثالی برای طراحی فرم شناسنامه است.
در این مقاله، «اثر انگشت مشخصات کالا» را بهعنوان نامی توضیحی برای مجموعه ویژگیهای انتخابشده به کار میبریم. این عبارت نام یک استاندارد رسمی یا تضمین تشخیص خودکار نیست. مجموعه ویژگیها باید برای همان کلاس تعریف شود و در صورت تغییر قواعد، نسخه آن قابل پیگیری باشد.
سه گروه داده را جدا کنید:
- ویژگی هویتی: تفاوت آن، طبق قواعد سازمان، میتواند آیتم دیگری بسازد.
- ویژگی توصیفی: به شناخت و جستوجو کمک میکند، اما بهتنهایی تعیینکننده هویت نیست.
- اطلاعات عملیات: مانند موجودی، جایگاه، قیمت خرید یا شماره رسید؛ این موارد معمولاً به وضعیت و رویداد مربوطاند.
اگر یک ویژگی ضروری خالی است، نتیجه را «نیازمند تکمیل اطلاعات» ثبت کنید. دو مقدار خالی، اثبات نمیکنند که دو کالا یکساناند.
یک مثال صنعتی: سه رکورد، دو نوع تصمیم
جدول زیر مربوط به یک مثال ساختگی است. مدل «وی۲۵» و نام سازنده صرفاً برای توضیح روش انتخاب شدهاند. فرض میکنیم قواعد این خانواده، نوع اتصال را یکی از ویژگیهای تعیینکننده آیتم میدانند.
| رکورد | اطلاعات موجود | نتیجه بررسی اولیه |
|---|---|---|
| الف | نام فارسی؛ مدل وی۲۵؛ اتصال رزوهای؛ سازنده الف | مبنای مقایسه |
| ب | نام انگلیسی؛ همان مدل، سازنده و مشخصات؛ اتصال رزوهای | نامزد ثبت تکراری |
| پ | نام فارسی مشابه؛ اتصال فلنجی؛ مدل ثبت نشده | تفاوت مشخصات و اطلاعات ناقص |
درباره الف و ب، تفاوت زبان نام مانع بررسی مشترک نیست. با این حال، پیش از تعیین یک شناسنامه مرجع باید مدارک و سایر ویژگیهای لازم نیز تأیید شوند. درباره پ، شباهت نام مجوز ادغام نمیدهد؛ هم تفاوت اتصال وجود دارد و هم بخشی از اطلاعات ناقص است.
حتی اگر دو قطعه در یک کاربرد جایگزین هم باشند، این موضوع لزوماً به معنی یکسانبودن هویت آنها نیست. «جایگزین مجاز» را میتوان بهصورت یک رابطه جدا، با شرایط و مرجع تأیید، نگه داشت.
پیش از مقایسه، دادهها را یکدست کنید
برای نامهای فارسی، تفاوت «ی» و «ي»، «ک» و «ك»، فاصلههای اضافی و شکل نوشتن اعداد میتواند جستوجو را دشوار کند. یک نسخه یکدست برای جستوجو و مقایسه بسازید و متن اصلی واردشده را نیز برای مراجعه نگه دارید.
این یکدستسازی نباید کورکورانه روی شماره مدل و کد سازنده اجرا شود. صفر ابتدایی، خط تیره یا پسوند ممکن است بخشی از شناسه باشد. برای این فیلدها فقط قواعدی را اعمال کنید که معنای کد را حفظ میکنند.
واحد اندازهگیری و واحد شمارش را هم روشن کنید. تبدیل مقدار تنها وقتی معتبر است که واحد مبدأ و ضریب تبدیل مشخص باشند. «یک بسته» بدون دانستن تعداد داخل آن، با «یک عدد» قابل مقایسه نیست؛ بستهبندی نیز ممکن است طبق قواعد سازمان هویت تجاری مستقلی داشته باشد.
در مستندات کیفیت داده Oracle، طبقهبندی، استانداردسازی و تطبیق سه فعالیت جدا هستند؛ برای نمونه، یکدستکردن شکل نوشتن واحدها از قواعد تشخیص رکورد مشابه تفکیک شده است. منبع: کیفیت داده کالا در Oracle
شباهت را پیشنهاد بررسی بدانید، نه حکم ادغام
فهرست نامزدهای مشابه باید دلیل داشته باشد: مدل مشترک، مرجع سازنده یکسان، تطابق ویژگیها یا شباهت نام. یک امتیاز کلی، بدون نمایش فیلدهای موافق، متفاوت و خالی، برای تصمیم مسئول داده کافی نیست.
در طراحی فرایند، برای هر نامزد یکی از این نتیجهها را ثبت کنید: «همان آیتم»، «آیتم متفاوت» یا «اطلاعات ناکافی». نتیجه باید همراه با دلیل، مدرک و نام بررسیکننده بماند تا بار بعد همان ابهام از نو بررسی نشود.
Oracle نیز در توضیح تطبیق اقلام، از نمایش موارد بالقوه تکراری و تصمیم آگاهانه کاربر درباره ایجاد یا استفاده از رکورد موجود صحبت میکند. این مثال نشان میدهد یافتن مشابهت و تأیید هویت، دو مرحله قابل تفکیکاند. منبع: روش تطبیق اقلام در Oracle
کدهای قدیمی را با حفظ سوابق تعیین تکلیف کنید
وقتی تکراریبودن دو شناسنامه تأیید شد، پیش از تغییر، وابستگیهای هر دو را فهرست کنید: موجودی به تفکیک محل، بچ و سریال، اسناد ورود و خروج، رزروها، سفارشهای باز و برچسبهای چاپشده.
برای اصلاح، یک شناسنامه مرجع تعیین کنید و نگاشت کد قدیمی به آن را نگه دارید. تاریخ اجرا و مسئول تصمیم مشخص باشد. بسته به امکانات سامانه، ممکن است کد قبلی برای ثبت عملیات تازه غیرفعال شود و همچنان در جستوجو و سوابق قابل شناسایی بماند. تغییر ارجاع اسناد باید از مسیر پشتیبانیشده و قابل ممیزی انجام شود.
موجودی دو کد را صرفاً با جمعکردن گزارشها اصلاح نکنید. ابتدا روشن کنید آیا هر دو عدد نماینده اقلام فیزیکی مستقلاند یا بخشی از موجودی دوبار ثبت شده است. واحد، وضعیت و اسناد باز نیز باید تطبیق داده شوند. ارتباط این موضوع با عملیات در راهنمای مدیریت موجودی انبار توضیح داده شده است.
نرمافزار باید چه چیزی را پاسخ دهد؟
برای ارزیابی نرمافزار کدینگ کالا، یک نمونه کوچک از داده واقعیِ بدون اطلاعات حساس آماده کنید: دو نام برای یک قلم، دو قلم با نام مشابه، یک مدل ناقص و یک کد قدیمی دارای سابقه. سپس این پرسشها را با همان نمونه بررسی کنید:
- آیا ویژگیهای ضروری هر کلاس قابل تعریف و کنترلاند؟
- آیا کاربر پیش از ثبت قلم تازه، نامها و مراجع موجود را پیدا میکند؟
- آیا دلیل پیشنهاد مشابهت و تفاوتهای واقعی قابل مشاهده است؟
- آیا تکمیل اطلاعات، تأیید تصمیم و سابقه تغییرات قابل پیگیری است؟
- آیا اصلاح کد، ارتباط موجودی، اسناد و شناسههای قبلی را حفظ میکند؟
اینها معیارهای نیازسنجیاند و وجود همه آنها در یک محصول از پیش فرض نشده است. برای شروع، یک کلاس پرکاربرد را انتخاب کنید، قواعد هویت آن را با انبار و خرید بنویسید و روش را روی چند نمونه آزمایش کنید. برای شناخت چارچوب محصول نیز معرفی ایدنتو را ببینید و همین سناریوها را مبنای ارزیابی قرار دهید.
پرسشهای متداول درباره جلوگیری از کد تکراری کالا
آیا نام یکسان یعنی دو رکورد تکراریاند؟
خیر. نام نقطه شروع جستوجو است. ویژگیهای تعیینکننده، مدل، مراجع و واحد باید مطابق قواعد همان خانواده بررسی شوند؛ دو قلم متفاوت میتوانند نام عمومی یکسان داشته باشند.
آیا تغییر فروشنده به کد کالای جدید نیاز دارد؟
لزوماً خیر. اگر هویت قلم تغییر نکرده باشد، کد فروشنده میتواند مرجعی مرتبط با همان آیتم باشد. تغییر واقعی مشخصات یا الزامات پذیرش باید جدا بررسی شود.
با کالای فاقد مشخصات کافی چه کنیم؟
آن را برای تکمیل اطلاعات نگه دارید و منبع لازم، مانند کاتالوگ، مدارک خرید یا بررسی فیزیکی، را مشخص کنید. خالیبودن فیلدها نباید دلیل تأیید یکسانبودن دو قلم شود.
آیا حذف رکورد تکراری برای پاکسازی کافی است؟
خیر. ممکن است کد قبلی در اسناد، موجودی یا برچسبها استفاده شده باشد. ابتدا وابستگیها، شناسنامه مرجع و نگاشت کدها را مشخص کنید و اصلاح را با حفظ سوابق انجام دهید.