इन्वेंटरी समायोजन लॉग: कारण कोड और ऑडिट ट्रेल

क्यों स्टॉक परिवर्तनों को स्पष्ट रूप से समझाना चाहिए

इन्वेंटरी समायोजन उस मैन्युअल परिवर्तन को कहता है जो आपके सिस्टम में दिखने वाली ऑन-हैंड मात्रा में किया जाता है। आप स्टॉक रिसीव या शिप नहीं कर रहे हैं। आप संख्या को ठीक कर रहे हैं क्योंकि वास्तविकता और रिकॉर्ड मेल नहीं खाते।

यह सरल लग सकता है, पर यह आपके डेटा में भरोसा खोने का एक तेज़ तरीका है। अगर नोट सिर्फ़ "स्टॉक बदला", हो तो कोई नहीं बता पाएगा कि बदलाव नियमित था, गलती थी, या जाँच की ज़रूरत है। ऑडिट के दौरान "हमने ठीक किया" सबूत नहीं है। मैनेजर और ऑडिटर यह देखना चाहते हैं कि क्या हुआ, किसने किया, कब हुआ और क्यों इसे अनुमति दी गई।

अधिकांश समायोजन वही वास्तविक स्थितियों से आते हैं: आइटम क्षतिग्रस्त हो जाते हैं या एक्सपायर हो जाते हैं, कुछ गायब हो जाता है, पुनर्गणना से परिणाम बदलता है, सप्लायर कम शिप करता है, या पैक/पिक में बाद में कोई त्रुटि मिलती है।

साफ कारण कोड आपको "अपेक्षित नुकसान" (जैसे डैमेज) को "अस्वीकार्य नुकसान" (जैसे चोरी) और "प्रोसेस शोर" (जैसे रीकाउंट सुधार) से अलग करने में मदद करते हैं। इससे पैटर्न देखना आसान होता है, मूल कारण ठीक करना आसान होता है, और आपके आँकड़ों का बचाव बेहतर होता है।

"स्थायी इतिहास" का मतलब है कि आप अतीत को ओवरराइट नहीं करते। हर परिवर्तन को अपनी अलग एंट्री के रूप में सुरक्षित किया जाता है, पहले और बाद की मात्राओं के साथ और निर्णय के पीछे के विवरण के साथ। अगर बाद में कोई कारण या नोट एडिट करे, तो वह एडिट भी रिकॉर्ड होना चाहिए। यह इसलिए महत्वपूर्ण है क्योंकि इन्वेंटरी वित्तीय परिणामों को प्रभावित करती है। अगर आप ट्रेल नहीं दिखा सकते, तो आप काउंट का प्रमाण नहीं दे पाएंगे।

कई टीमें स्प्रेडशीट से शुरू करती हैं। जैसे-जैसे वॉल्यूम बढ़ता है, परमिशन्स और ऑडिट ट्रेल वाले एक साधारण आंतरिक ऐप में लॉग मूव करने से इतिहास सुसंगत और बाइपास करना कठिन रहता है।

कारण कोड और ऑडिट ट्रेल: सरल परिभाषाएँ

एक इन्वेंटरी समायोजन लॉग तभी काम करता है जब यह हर बार एक सवाल का जवाब दे: स्टॉक क्यों बदला? दो उपकरण इसे संभव बनाते हैं: कारण कोड और एक ऑडिट ट्रेल।

कारण कोड (और क्यों यह फ्री टेक्स्ट से बेहतर है)

एक कारण कोड एक छोटा, स्टैण्डर्ड लेबल होता है जिसे सूची से चुना जाता है, जैसे Damage, Theft, Recount correction, Expired, या Supplier short-ship। यह एकरूपता मजबूर करता है ताकि रिपोर्ट बिना अनुमान लगाए परिवर्तन समूह कर सकें।

फ्री-टेक्स्ट नोट्स अभी भी महत्वपूर्ण हैं, पर वे विकल्‍प नहीं हैं। नोट्स बताती हैं कि क्या हुआ और आपने क्या जाँचा। कारण कोड घटना को वर्गीकृत करता है। केवल नोट्स पर निर्भर करने से आपको एक ही विचार के दस रूप मिलेंगे ("broken", "damaged", "cracked", "fell"), और आपका डेटा तुलनीय होना बंद हो जाएगा।

ऑडिट ट्रेल (सिर्फ एक्टिविटी लॉग नहीं)

एक एक्टिविटी लॉग कह सकता है "Quantity changed from 12 to 9." एक ऑडिट ट्रेल समझाता है कि वह कैसे हुआ और क्या यह आपके नियमों के अनुसार था।

एक अच्छा ऑडिट ट्रेल बताता है कि किसने परिवर्तन किया और कब, क्या बदला (आइटम, लोकेशन, पहले और बाद की मात्रा), और क्यों बदला (कारण कोड के साथ एक नोट)।

ऑडिट के लिए, आप समर्थक साक्ष्य भी चाहेंगे। वह क्षतिग्रस्त पैकेजिंग की फ़ोटो, काउंट शीट, रिटर्न पेपरवर्क, निपटान रिकॉर्ड, सप्लायर चालान रेफरेंस, या टिकट/इन्सिडेंट नंबर हो सकता है। उद्देश्य सिर्फ कागज़ी काम इकठ्ठा करना नहीं है, बल्कि समायोजन को महीनों बाद भी बचाव योग्य बनाना है।

अनुमोदन ट्रेसबिलिटी को मजबूत करते हैं। अगर मैनेजर अनुमोदन करता है, तो ट्रेल में दिखना चाहिए कि किसने अनुमोदन किया, कब, और क्या अनुमोदित किया (किसी भी एडिट सहित)। अगर आप वर्कफ़्लो AppMaster में बनाते हैं, तो आप कारण कोड चयन को अनिवार्य कर सकते हैं और एक स्थायी इतिहास रख सकते हैं ताकि एडिट्स मूल रिकॉर्ड को ओवरराइट न करें।

समायोजन के लिए भूमिकाएँ और जिम्मेदारियाँ

एक समायोजन कभी "सिर्फ़ एक संख्या बदलना" नहीं होना चाहिए। अगर लोगों को यह पता नहीं कि कौन स्टॉक बदल सकता है, कब बदल सकता है, और बाद में कौन इसे चेक करता है, तो आपका समायोजन लॉग गलतियों को छिपाने की एक चुप जगह बन जाएगा।

पहले यह परिभाषित करें कि कौन समायोजन बना सकता है। कई गोदामों में, यह वही टीम होती है जो समस्या पाती है: रिसीविंग (शॉर्ट शिपमेंट), रिटर्न्स (डैमेज रिटर्न्स), या फ़्लोर स्टाफ साइकल काउंट के दौरान। अलग से परिभाषित करें कि कौन अनुमोदित कर सकता है, कौन पोस्ट कर सकता है, और कौन ट्रेंड्स की समीक्षा करता है।

अनुमोदन वह जगह है जहाँ आप "रूटीन" और "संवेदनशील" के बीच रेखा खींचते हैं। एक छोटा डैमेज राइट-ऑफ ऑटो-अनुमोदित हो सकता है, जबकि कोई भी हाई-वैल्यू, बार-बार या असामान्य चीज़ सेकंड व्यक्ति की आवश्यकता रखनी चाहिए। मानक थ्रेशोल्ड्स का उपयोग करें (वैल्यू, मात्रा, SKU प्रकार, या कारण कोड के अनुसार) ताकि नियम हर बार एक जैसा हो।

ट्रेंड समीक्षा अनुमोदन से अलग काम है। फाइनेंस वैलुएशन इम्पैक्ट देख सकता है, ऑपरेशंस प्रोसेस समस्याओं के लिए, और लॉस प्रिवेंशन चोरी पैटर्न के लिए। समीक्षाएँ एक शेड्यूल पर होनी चाहिए (साप्ताहिक या मासिक), केवल तब नहीं जब कुछ गलत हो।

दुरुपयोग कम करने के लिए, कर्तव्यों को अलग रखें ताकि एक व्यक्ति ही समायोजन बना न सके, अनुमोदित न कर सके और चुपचाप सब कुछ ठीक न कर सके। सरल रखें: क्रिएटर और अप्रूवर अलग लोग होने चाहिए, अप्रूवर मूल विवरण एडिट न करें (सिर्फ अनुमोदित या अस्वीकार करें), और "एडमिन ओवरराइड" एक्सेस सीमित और लॉग किया जाना चाहिए।

यदि बाद में आप AppMaster में भूमिकाएँ और अनुमोदन ऑटोमेट करते हैं, तो बिना कोड के अनुमतियाँ और सरल अनुमोदन फ्लोज़ बना सकते हैं और यह सब करते हुए कौन-कब क्या किया यह स्थायी रूप से रिकॉर्ड रखते हैं।

आपका समायोजन लॉग किन फ़ील्ड्स को शामिल करे

एक इन्वेंटरी समायोजन लॉग तब ही उपयोगी है जब कोई और बाद में उसे पढ़कर समझ सके कि क्या हुआ, किसने किया, और क्यों इसे अनुमति दी गई। इसे हर स्टॉक परिवर्तन के लिए एक रसीद की तरह सोचें।

कंसिस्टेंट हेडर से शुरू करें: तारीख और समय, स्थान (वेयरहाउस, स्टोर, बिन जोन), वह यूज़र जिसने बनाया, और स्रोत (साइकल काउंट, कस्टमर रिटर्न, डैमेज रिपोर्ट, सिस्टम सिंक, आदि)।

फिर प्रत्येक आइटम के लिए लाइन-लेवल विवरण कैप्चर करें। ऑडिट अक्सर इसलिए असफल होते हैं क्योंकि टीम केवल नेट परिवर्तन स्टोर करती है, न कि पूरा पहले-और-बाद का चित्र।

लाइन लेवल पर SKU (और यदि आप उपयोग करते हैं तो लॉट/सीरियल/एक्सपायरी), पहले की मात्रा, मात्रा परिवर्तन (+ या -), बाद की मात्रा, और यूनिट ऑफ़ मेज़र (each, case, kg) कैप्चर करें ताकि कन्वर्ज़न चुपचाप डेटा को करप्ट न करें। कारण कोड और एक छोटा नोट जोड़ें। अगर साक्ष्य कहीं और है, तो अटैचमेंट रेफरेंस (फ़ोटो ID, टिकट नंबर, काउंट शीट नंबर) स्टोर करें ताकि ट्रेल जुड़ा रहे।

अनुमोदन संख्याओं जितना ही मायने रखता है। ट्रैक करें: अनुमोदन स्थिति, अप्रूवर का नाम या रोल, और क्रिएटेड, सबमिटेड, अप्रूव्ड और पोस्टेड के टाइमस्टैम्प। अगर आप एडिट की अनुमति देते हैं, तो रिकॉर्ड करें कि किसने एडिट किया और कब, और पिछले मान रखें।

अंत में, हर समायोजन के लिए एक यूनिक समायोजन ID चाहिए जो कभी न बदले। यह सर्च करने योग्य होना चाहिए और संबंधित दस्तावेज़ों (काउंट शीट्स, रिटर्न पेपरवर्क) पर दिखना चाहिए। किसी आंतरिक टूल में, ID स्वचालित जनरेट करें और पोस्टेड समायोजन लॉक करें ताकि इतिहास साफ़ रहे।

ऐसे कारण कोड डिज़ाइन करें जिन्हें लोग वास्तव में उपयोग करें

कारण कोड तभी काम करते हैं जब लोग सही कोड कुछ सेकंडों में चुन सकें। अगर सूची लंबी, अस्पष्ट, या "other" से भरी है, तो आपका समायोजन लॉग अंदाज़े पर आधारित बन जाएगा और ऑडिट गड़बड़ हो जाएगा।

छोटे से शुरू करें। एक छोटा सेट किसी परफेक्ट टैक्सोनॉमी से बेहतर है जिसे कोई इस्तेमाल ही नहीं करता। नए कोड तब ही जोड़ें जब आप नोट्स में बार-बार वही स्पष्टीकरण देखें जो मौजूदा कोड्स में नहीं आता।

एक व्यवहार्य स्टार्टर सेट आमतौर पर मुख्य बकेट कवर करता है: डैमेज (एक्सपायर्ड सहित), चोरी/नुकसान, रीकाउंट या साइकल काउंट करेक्शन, सप्लायर इश्यू (शॉर्ट-शिप या गलत आइटम), और रिटर्न्स।

जहाँ संभव हो, कोड्स को म्यूचुअली एक्सक्लूसिव रखें। उदाहरण के लिए, "Recount correction" का उपयोग उस टूटी हुई वस्तु के लिए नहीं होना चाहिए जो रीकाउंट के दौरान मिली — वह अभी भी "Damage" होना चाहिए। रीकाउंट सिर्फ़ वह तरीका है जिससे आपने इसे खोजा, कारण नहीं।

प्रत्येक कोड में बाद में जिन विवरणों की ज़रूरत होगी वह शामिल करें। सिर्फ़ "Damage" अस्पष्ट है। कोड के अनुसार कुछ फील्ड अनिवार्य करें, जैसे डैमेज टाइप (crushed, leaking, expired) और यह कहाँ हुआ (receiving dock, pick/pack, transit)। "Supplier issue" के लिए PO नंबर और क्या वह शॉर्ट था, गलत आइटम था या दोषपूर्ण था, यह कैप्चर करें।

अपनाने में सुधार तब होता है जब कोड्स सादे भाषा में हों, ओवरलैप हटाया गया हो, "Other" सीमित हो (और हमेशा नोट चाहिए), और उपयोग हर महीने रिव्यू किया जाए ताकि बेकार कोड रिटायर किए जा सकें।

अंत में, तय करें कि कौन से कोड अनुमोदन मांगते हैं। चोरी, बड़े लिख-ऑफ, और किसी थ्रेशोल्ड से ऊपर का समायोजन आम तौर पर मैनेजर साइन-ऑफ मांगता है। छोटे रीकाउंट करेक्शनों को न करना पड़ सकता है।

चरण-दर-चरण: समायोजन को सही तरीके से रिकॉर्ड कैसे करें

एक समायोजन "बस संख्या ठीक कर दो" से शुरू नहीं होता। यह एक असंगति देखने से शुरू होता है, फिर क्या हुआ इसकी पुष्टि करनी चाहिए, और तभी स्टॉक बदलना चाहिए।

एक सरल वर्कफ़्लो जो ऑडिट में टिके

पहले असंगति और उसका संदर्भ रिकॉर्ड करें: यह कहाँ दिखी (वेयरहाउस, बिन, SKU, दस्तावेज़) और किसने पाया।

फिर किसी भी परिवर्तन से पहले सत्यापित करें। एक त्वरित पुनर्गणना करें, नज़दीकी बिन्स में मिस-सलॉट्स की जाँच करें, रिसीविंग और शिपिंग पेपरवर्क समीक्षा करें, और यूनिट ऑफ़ मेज़र की पुष्टि करें (case vs each सामान्य जाल है)। अगर असंगति किसी ऑर्डर से जुड़ी है, तो ऑर्डर नंबर रिकॉर्ड करें।

फिर समायोजन लगातार दर्ज करें: सही आइटम और लोकेशन चुनें (और लॉट/सीरियल अगर उपयोग करते हैं), मात्रा परिवर्तन सही साइन के साथ दर्ज करें, एक कारण कोड चुनें, और एक छोटा नोट जोड़ें जो बताये कि आपने क्या जाँचा और क्या मिला। साक्ष्य संदर्भ (फ़ोटो ID, काउंट शीट नंबर, RMA, इन्सिडेंट रिपोर्ट) जोड़ें और यदि नीति मांगती है तो अनुमोदन के लिए सबमिट करें।

पोस्ट करने के बाद, सुनिश्चित करें कि सिस्टम मूल मान, नया मान, टाइमस्टैम्प और यूज़र को सुरक्षित रखता है। अगर आप अनुमोदन उपयोग करते हैं, तो अप्रूवर और अप्रूवल समय भी स्टोर करें।

फ़ॉलो-अप न छोड़ें

समायोजन सारांश की दैनिक या साप्ताहिक समीक्षा निर्धारित करें। पैटर्न देखें: किसी एक क्षेत्र में बार-बार हुआ डैमेज, किसी एक SKU पर बार-बार रीकाउंट करेक्शन्स, या बहुत सारे "unknown" कारण। AppMaster में वर्कफ़्लो बनाते समय आप कारण कोड अनिवार्य कर सकते हैं, किसी थ्रेशोल्ड से ऊपर अनुमोदन लागू कर सकते हैं, और पर्यवेक्षकों के लिए बिना अतिरिक्त काम के एक सरल समीक्षा स्क्रीन प्रदान कर सकते हैं।

स्थायी परिवर्तन इतिहास कैसे रखें

स्थायी इतिहास का मतलब है कि आप महीनों बाद बिना अनुमान के तीन प्रश्नों का जवाब दे सकें: क्या बदला, किसने किया, और क्यों। सबसे आसान तरीका यह है कि समायोजन को अकाउंटिंग एंट्री की तरह ट्रीट करें। आप घटनाओं को रिकॉर्ड करते हैं। आप अतीत को फिर से नहीं लिखते।

पोस्टेड एंट्रीज़ को अपरिवर्तनीय बनाएं

एक बार समायोजन पोस्ट हो जाने के बाद, मूल मान रखें और हर परिवर्तन को नए रिकॉर्ड के रूप में स्टोर करें। पुराने लाइन आइटम की मात्रा एडिट करने से बचें, भले ही वह तेज़ लगे। ओवरराइट्स संदर्भ मिटाते हैं और ऑडिट को दुखद बनाते हैं।

हर पोस्टेड एंट्री में पहले और बाद की मात्रा (सिर्फ अंतर नहीं), किसने बनाया और किसने अनुमोदित किया (यदि आवश्यक हो), दोनों कार्रवाइयों के टाइमस्टैम्प, कारण कोड और नोट, और एक यूनिक समायोजन ID शामिल होना चाहिए।

पोस्टेड समायोजनों को डिलीट करने की अनुमति न दें। अगर किसी ने गलती की, तो रिवर्सल का उपयोग करें: गलत वाले को रद्द करने के लिए नया समायोजन बनाएं, फिर सही संख्याओं के साथ दूसरा समायोजन जोड़ें। इससे ट्रेल अछूता रहता है और दिखता है कि सुधार जानबूझकर किया गया था।

जब करेक्शन्स अक्सर होते हैं (उदा., एक रीकाउंट से पता चलता है कि पहली गिनती गलत थी), तो फॉलो-अप समायोजन को मूल से लिंक करने के लिए "related adjustment ID" फील्ड का उपयोग करें।

रिटेंशन और एक्सेस नियम सेट करें

निर्धारित करें कि आप समायोजन इतिहास और सहायक नोट्स कितने समय तक रखें। कई टीमें वर्षों तक रखती हैं क्योंकि ऑडिट दूर तक पीछे देख सकते हैं।

यह सीमित करें कि कौन पोस्ट, अप्रूव, या रिवर्स कर सकता है, और हर परमिशन परिवर्तन को लॉग करें। यदि आप प्रक्रिया को AppMaster या किसी भी आंतरिक टूल में ऑटोमेट करते हैं, तो वर्कफ़्लो में "append-only" नियम बनाएं, सिर्फ़ आदत के रूप में नहीं।

आम गलतियाँ जो ऑडिटेबिलिटी तोड़ देती हैं

अधिकांश इन्वेंटरी समस्याएँ किसी एक बड़ी गलती से नहीं आतीं। वे तब होती हैं जब छोटे शॉर्टकट जमा हो जाते हैं, और फिर कोई नहीं बता पाता कि क्या बदला, कब और क्यों।

एक सामान्य समस्या बहुत सारे कारण कोड होना है। जब सूची लंबी या भ्रमित करने वाली हो, लोग सोचना बंद कर देते हैं और जो निकटतम होता है वही चुन लेते हैं। डेटा व्यवस्थित दिखता है, पर वास्तव में यादृच्छिक होता है और ट्रेंड रिपोर्टिंग अविश्वसनीय हो जाती है।

एक और जाल केवल फ्री-टेक्स्ट नोट्स होना है। नोट्स मदद करती हैं, पर अगर हर समायोजन सिर्फ़ एक वाक्य है, तो आप कारणों को समय के साथ समूह, फ़िल्टर या तुलना नहीं कर पाएँगे। आपको सैकड़ों एंट्रीज़ हाथ से पढ़नी पड़ सकती हैं।

उच्च-प्रभाव वाले बदलावों के लिए अतिरिक्त नियंत्रण चाहिए। अगर कोई भी 500 यूनिट लिख-ऑफ कर सकता है बिना दूसरे व्यक्ति की जाँच के, तो आपके पास ऑडिट ट्रेल हो सकती है, पर वह यह सिद्ध नहीं करेगा कि बदलाव वैध था।

कुछ वर्कफ़्लो पैटर्न बार-बार ऑडिट दर्द पैदा करते हैं: बैच एडिट्स जो कई आइटम्स को एक साथ अपडेट करते हैं बिना लाइन-लेवल कारण और मात्राओं के, लोकेशन या लॉट/सीरियल जैसी आवश्यक जानकारी का अभाव, और पुराने रिकॉर्ड्स को "साफ़" करने के लिए एडिट करना बजाय नए करेक्शन एंट्री बनाने के।

यह आखिरी बिंदु क्रिटिकल है। ऑडिट ट्रेल इतिहास के बारे में है, परफ़ेक्शन के बारे में नहीं। अगर किसी ने -12 दर्ज कर दिया था बजाय -2 के, तो सुधार एक नया समायोजन होना चाहिए जो त्रुटि को उलट दे, अपने कारण कोड (उदा., "data entry correction") और एक छोटा नोट के साथ।

अपना लॉग टेस्ट करने का एक त्वरित तरीका है 10 समायोजन सैंपल करना और पूछना: क्या कोई नया व्यक्ति बिना पूछे हर एक को समझा सकता है? अगर नहीं, तो आवश्यक फ़ील्ड्स को कड़ाई से लागू करें, कारण कोड्स को कम और स्पष्ट करें, और उन बदलावों के लिए अनुमोदन जोड़ें जिनका वास्तविक जोखिम है।

उदाहरण परिदृश्य: रीकाउंट के बाद गायब आइटम

आइल B में एक साइकल काउंट समस्या दिखाता है: SKU "WIDGET-250" की किताबी मात्रा 200 होनी चाहिए थी, पर काउंटर को 188 मिला। यह 12 यूनिट गायब हैं, और आपका समायोजन लॉग यह समझाने की ज़रूरत रखता है कि स्टॉक क्यों बदला, सिर्फ यह नहीं कि बदला।

पहले, काउंटर बेसिक्स की जाँच करता है: पुष्टि करें कि बिन लेबल SKU से मेल खाता है, नज़दीकी ओवरफ्लो लोकेशन्स स्कैन करें, और सुनिश्चित करें कि कोई ओपन पिक्स टोेट में पड़े नहीं हैं। दूसरा व्यक्ति पुनर्गणना करे। अगर पुनर्गणना भी 188 ही दिखाती है, तो यह सिर्फ़ मिसकाउंट नहीं है।

अब साक्ष्य के आधार पर कारण कोड चुनें। अगर कैमरा फुटेज या टूटा हुआ सील लॉस सूचित करता है, तो "theft" उपयुक्त हो सकता है। अगर शिपिंग एरिया में पूरा हुआ ऑर्डर दिखता है जो डिडक्ट नहीं हुआ, तो यह पिक/ट्रांज़ैक्शन त्रुटि की ओर इशारा करता है। अगर पता चलता है कि किताबी मात्रा पहले की गिनती की गलती के कारण गलत थी, तो "recount correction" का उपयोग करें। नियम सरल है: वह कारण चुनें जिसे आप प्रमाणित कर सकें।

एक मजबूत एंट्री बाद में निर्णय को आसान बनाती है। इसमें SKU और लोकेशन (और प्रयोग में होने पर लॉट/सीरियल), पहले की मात्रा (200) और बाद की मात्रा (188), कारण कोड और छोटा नोट संदर्भ सहित (रीकाउंट शीट ID, टिकट नंबर), किसने अनुरोध किया और किसने अनुमोदन किया, टाइमस्टैम्प और कोई भी अटैचमेंट रेफरेंस शामिल होते हैं।

एक ऑडिटर तब यह पुष्टि कर सकता है कि किसने गिना, किसने अनुमोदन किया, कब हुआ, क्या बदला (-12), और आपने वह कारण क्यों चुना।

साफ समायोजन प्रक्रिया के लिए त्वरित चेकलिस्ट

साफ समायोजन प्रक्रिया परफेक्ट काउंट्स के बारे में कम है और लगातार रिकॉर्ड्स के बारे में अधिक। अगर कोई छह महीने बाद आपका लॉग खोले, तो उसे समझ आ जाना चाहिए कि क्या बदला, किसने किया और क्यों वह स्वीकार्य था।

समायोजन पोस्ट करने से पहले बुनियादी बातों की पुष्टि करें: कारण कोड चुनें, एक छोटा नोट जोड़ें जो बताये क्या हुआ, पहले और बाद की मात्रा रिकॉर्ड करें (ताकि गणित दिखे), सुनिश्चित करें कि सिस्टम स्वचालित रूप से यूज़र और टाइमस्टैम्प कैप्चर करे, और जब मदद करे तो साक्ष्य संलग्न या संदर्भित करें (फ़ोटो, RMA, काउंट शीट ID, टिकट नंबर)। अगर कारण कोड अनुमोदन मांगता है, तो पोस्ट करने से पहले उसे प्राप्त करें।

"अनुमोदन आवश्यक" ट्रिगर्स सेट करें ताकि स्टाफ को अनुमान न लगाना पड़े। सामान्य ट्रिगर्स में थेफ्ट या संदिग्ध थेफ्ट, थ्रेशोल्ड से ऊपर के राइट-ऑफ, बड़े रीकाउंट अंतर, समायोजन जो नेगेटिव स्टॉक बनाएँगे, और पिछली अवधि के लिए बैकडेटेड बदलाव शामिल हैं।

इतिहास की सुरक्षा करें। एक बार समायोजन पोस्ट हो जाने पर उसे डिलीट नहीं किया जाना चाहिए। अगर वह गलत था, तो मूल का संदर्भ देते हुए उसे रिवर्स करने के लिए नया एंट्री बनाएं और एक स्पष्ट रिवर्सल या करेक्शन कारण कोड और नोट का उपयोग करें।

अगले कदम: मानकीकृत करें और फिर ऑटोमेट करें

पहले जो आप करते हैं उसे मानकीकृत करें। पिछले 30 से 90 दिनों के समायोजनों को खींचें और हर उस "कारण" की सूची बनाएं जो लोगों ने टाइप या चुना था। आप बार-बार दिखाई देने वाले और अस्पष्ट प्रविष्टियाँ (जैसे "misc" या "fix") देखेंगे। उन्हें छोटे सेट में समूहित करें जो बिना बहस के यह बताते हों कि स्टॉक क्यों बदला।

सूची इतनी छोटी रखें कि याद रखी जा सके। कई टीमें 8 से 15 कोड पर पहुँचती हैं जिनके साधारण नाम वास्तविक जीवन से मिलते हैं (damage, theft, supplier short-ship, recount correction, expired, customer return, production scrap)। "Other" तभी रखें जब वह हमेशा एक नोट मांगता हो।

फिर तय करें कि कौन क्या कर सकता है। समायोजन लॉग सिर्फ़ रिकॉर्ड नहीं है, यह एक कंट्रोल है। तय करें कि कौन बना सकता है बनाम कौन अनुमोदित और पोस्ट कर सकता है, अनुमोदन के लिए थ्रेशोल्ड सेट करें, उच्च-जोखिम कारणों के लिए क्या प्रमाण चाहिए यह तय करें, और हर लोकेशन या बिन का स्पष्ट मालिक रखें।

जब मूल बातें स्थिर हों, तो एक सरल समीक्षा रूटीन जोड़ें। एक साप्ताहिक 15 मिनट की जाँच अक्सर जल्दी पैटर्न पकड़ लेती है: वही SKU बार-बार समायोजन में आ रहा है, वही शिफ्ट या वही कारण कोड।

जब आप स्प्रेडशीट से आगे बढ़ने को तैयार हों, तो AppMaster एक व्यावहारिक तरीका हो सकता है एक आंतरिक समायोजन लॉग बनाने का, जिसमें PostgreSQL-मैकेनिस्म, आवश्यक फ़ील्ड, अनुमोदन वर्कफ़्लोज़ और एक एप्पेंड-ओनली हिस्ट्री शामिल हो जो रिकॉर्ड करे कि किसने क्या और कब बदला।