हर बार जब आप प्लेट को काटते हैं या कॉइल को विभाजित करते हैं, तो आप एक ट्रेसेबिलिटी समस्या बनाते हैं। मूल mill cert पूरे heat को कवर करता है। काटे गए टुकड़े और अवशेष उस heat के अंश हैं — और प्रत्येक को मूल cert से एक traceable link की आवश्यकता है।
समाधान सीधा है। कार्यान्वयन के लिए एक जानबूझकर प्रक्रिया की आवश्यकता है, क्योंकि अधिकांश इन्वेंटरी सिस्टम का डिफ़ॉल्ट व्यवहार सक्रिय रूप से इसके विरुद्ध काम करता है।
कटाई के बाद Traceability को संभालने के लिए दो मॉडल
कटाई संचालन के बाद cert लिंक को बनाए रखने के लिए दो वैध दृष्टिकोण हैं। उनके बीच का विकल्प इस बात पर निर्भर करता है कि आपके ग्राहकों को क्या चाहिए।
मॉडल 1: Cert रिले। प्रत्येक काटा गया टुकड़ा मूल mill cert को संदर्भित करता है। Cert को कॉपी या डुप्लिकेट नहीं किया जाता है — इसे संदर्भित किया जाता है। टुकड़े की ID, lot रिकॉर्ड या शिपिंग दस्तावेज़ मूल cert नंबर और heat नंबर की ओर वापस इंगित करता है। ग्राहक को मूल MTC के साथ एक संदर्भ प्राप्त होता है जो दिखाता है कि कौन सा टुकड़ा किस heat से आया है।
मॉडल 2: Cert सप्लीमेंट। सर्विस सेंटर या डिस्ट्रिब्यूटर एक नया दस्तावेज़ — एक supplemental cert या test रिपोर्ट — जारी करता है जो मूल mill cert को संदर्भित करता है और टुकड़े के साथ इसके संबंध का वर्णन करता है। सप्लीमेंट पहचान करता है: मूल heat नंबर, मूल cert संदर्भ, टुकड़े के cutting आयाम, और processing संचालन की तारीख और प्रकृति।
दोनों वैध हैं। Cert रिले सरल है और पसंद किया जाता है जहां मूल cert ग्राहक की आवश्यकताओं को पूरा करने के लिए पर्याप्त है। Cert सप्लीमेंट का उपयोग तब किया जाता है जब ग्राहक को आपूर्तिकर्ता की lettzerhead पर जारी documentation की आवश्यकता होती है, या जब मूल cert फॉर्मेट ग्राहक के लिए आवश्यक piece-level विस्तार को accommodate नहीं कर सकता।
कहां Traceability कटाई के बाद टूटता है
विच्छेद बिंदु अनुमानित हैं।
ERP कट पर नया stock item बनाता है। जब plate को non-standard dimension में काटा जाता है, तो अधिकांश ERP सिस्टम परिणामी टुकड़े के लिए एक नया inventory रिकॉर्ड बनाते हैं। उस नए रिकॉर्ड के पास अपनी item संख्या, अपना location, अपना lot ID है — और default कॉन्फ़िगरेशन में, यह parent material के heat नंबर के किसी भी संदर्भ को नहीं ले जाता। Cert लिंक नए रिकॉर्ड के creation पर severed है।
Coil-to-strip कन्वर्जन। एक coil को 8 strips में slit किया जाता है। सभी 8 strips के पास same heat नंबर है — वे एक ही certified heat के fractions हैं। लेकिन slitting संचालन 8 नए inventory records बनाता है, और अधिकांश implementations में, केवल active orders को जाने वाले strips के लिए records में cert reference होता है। बाकी को "uncertified remnant" के रूप में filed किया जाता है और कुछ हफ्तों में अपना heat नंबर linkage खो देते हैं।
आंशिक pallet picks। Material को 20 pieces की pallet पर प्राप्त किया जाता है, सभी same heat से। Orders 3 pieces, फिर 5 pieces, फिर कई हफ्तों में 4 pieces को pick करते हैं। यदि system केवल पहली pick पर cert linkage को update करता है और subsequent picks को "same pallet" के रूप में treat करता है, तो बाद की picks में complete individual cert record नहीं हो सकता।
Slitting Case विस्तार से
Slitting metals service centers में highest-volume cert-traceability समस्या है। एक single coil दर्जनों विभिन्न ग्राहकों को जाने वाले दर्जनों strips generate कर सकता है। प्रत्येक strip एक अलग dimension, संभवतः एक अलग SKU, संभवतः अलग cert requirements वाले ग्राहक को जा रहा है।
सही दृष्टिकोण: मूल coil heat नंबर सभी operations के माध्यम से anchor है। जब coil slitting में जाता है, तो प्रत्येक resulting strip को एक ID assign किया जाता है जो coil के heat नंबर को parent reference के रूप से ले जाता है। Strip ID, heat नंबर और cert reference slitting के माध्यम से storage के माध्यम से shipping तक system के माध्यम से एक साथ travel करते हैं।
यह एक complex data model नहीं है। यह तीन fields वाला एक parent-child रिकॉर्ड है: strip ID, parent coil heat नंबर, parent cert reference। जो इसे operationally मुश्किल बनाता है वह यह है कि ERP सिस्टम आमतौर पर batch में parent references के बिना strip records बनाते हैं, और उन references को establish करने के लिए custom configuration या manual step की आवश्यकता होती है जिसे कई implementations छोड़ देते हैं।
व्यावहारिक समाधान
Heat नंबर को persistent anchor के रूप में उपयोग करें। हर cut, slit या split संचालन नए physical items बनाता है लेकिन new heat नहीं बनाता। मूल heat नंबर इससे derived every piece में propagate होता है, इस बात की परवाह किए बिना कि बीच में क्या processing संचालन हुए।
अपने inventory system को configure करें ताकि processing संचालन automatically parent heat नंबर को inherit करें। यदि आपका system बिना customization के ऐसा नहीं कर सकता, तो minimum viable वैकल्पिक एक processing log है जो हर output piece को उसके input heat पर map करता है — processing के समय maintained, बाद में reconstructed नहीं।