১৮ মে, ২০২৫·7 মিনিট পড়তে

ইনভেন্টরি সমন্বয় লগ: কারণ কোড ও অডিট ট্রেইল

Q: Why do I need both a reason code and a note?

Use a reason code to classify *why* stock changed so you can report and audit consistently. A note explains the specific situation you found, what you checked, and any references like a count sheet or incident number.

কারণ কোড, অনুমোদন এবং একটি পরিষ্কার অডিট ট্রেইল ব্যবহার করে একটি ইনভেন্টরি অ্যাডজাস্টমেন্ট লগ সেট আপ করুন যাতে প্রতিটি স্টক পরিবর্তন ব্যাখ্যা করা যায় এবং অডিট দ্রুত হয়।

কেন স্টক পরিবর্তনগুলো স্পষ্টভাবে ব্যাখ্যা করা উচিত

ইনভেন্টরি অ্যাডজাস্টমেন্ট হলো সিস্টেমে থাকা অন-হ্যান্ড পরিমাণে একটি ম্যানুয়াল পরিবর্তন। এখানে নতুন স্টক আসে না বা কোনও জিনিস পাঠানো হয় না। আপনি সংখ্যাটি সংশোধন করছেন কারণ বাস্তবতা এবং রেকর্ড মেলে না।

এটি শোনার পর সহজ মনে হতে পারে, কিন্তু এটি আপনার ডেটার উপর থেকে আস্থা দ্রুত কমাতে পারে। যদি নোটে কেবল লেখা থাকে “stock changed,” কেউ বলতে পারবে না পরিবর্তনটি রুটিন ছিল, ভুল ছিল, নাকি তদন্ত দরকার। অডিটের সময় “আমরা ঠিক করেছি” প্রমাণ নয়। ম্যানেজার এবং অডিটররা দেখতে চান কি ঘটল, কে করেছে, কখন করেছে এবং কেন এটি অনুমোদিত হয়েছিল।

অধিকাংশ অ্যাডজাস্টমেন্ট একই ধরনের বাস্তব ঘটনার কারণে হয়ে থাকে: আইটেম ক্ষতিগ্রস্ত হয় বা মেয়াদ উত্তীর্ণ হয়, কিছু হারিয়ে যায়, কাউন্ট বদলে যায়, সরবরাহকারী সংক্ষিপ্তভাবে পাঠায়, বা পরে পিকিং/প্যাকিং ত্রুটি পাওয়া যায়।

সুস্পষ্ট কারণ কোডগুলো “অপ্রত্যাশিত ক্ষতি” (যেমন ক্ষতি) কে “গ্রহণযোগ্য নয় এমন ক্ষতি” (যেমন চুরি) এবং “প্রক্রিয়াগত গোলযোগ” (যেমন পুনঃগণনা সংশোধন) থেকে আলাদা করতে সাহায্য করে। এতে প্যাটার্ন দেখা সহজ হয়, মূল কারণ খুঁজে বের করা যায়, এবং আপনার সংখ্যাগুলো রক্ষা করা সহজ হয়।

“স্থায়ী ইতিহাস” বলতে বোঝায় আপনি অতীত মুছেন না। প্রতিটি পরিবর্তন আলাদা রেকর্ড হিসেবে সেভ হয়, পূর্ব এবং পরবর্তী পরিমাণসহ এবং সিদ্ধান্তের পিছনের বিবরণসহ। যদি কেউ পরে একটি কারণ বা নোট সম্পাদনা করে, সেই সম্পাদনাও রেকর্ড করা উচিত। এটি গুরুত্বপূর্ণ কারণ ইনভেন্টরি আর্থিক ফলাফলের উপর প্রভাব ফেলে। যদি আপনি ট্রেইল দেখাতে না পারেন, তাহলে গণনা প্রমাণ করা যায় না।

অনেক টিম প্রথমে একটি স্প্রেডশীট দিয়ে শুরু করে। ভলিউম বড় হলে অনুমতি এবং অডিট ট্রেইলসহ একটি সিম্পল অন্তর্দক্ষ অ্যাপে লগটি স্থানান্তর করলে ইতিহাস একরকম থাকে এবং বাইপাস করা কঠিন হয়।

কারণ কোড এবং অডিট ট্রেইল: সহজ সংজ্ঞা

একটি ইনভেন্টরি অ্যাডজাস্টমেন্ট লগ তখনই কাজ করে যখন এটি প্রতিবার একটি প্রশ্নের উত্তর দেয়: স্টক কেন পরিবর্তিত হলো? দুটি টুল এইটি সম্ভব করে: কারণ কোড এবং একটি অডিট ট্রেইল।

কারণ কোড (এবং কেন এগুলো ফ্রি-টেক্সটকে হারায়)

একটি কারণ কোড হলো তালিকাভুক্ত ছোট, স্ট্যান্ডার্ড লেবেল, যেমন Damage, Theft, Recount correction, Expired, বা Supplier short-ship। এটি সম্মতি জোর করে যাতে রিপোর্টগুলো অনুমান ছাড়াই পরিবর্তনগুলোকে গ্রুপ করতে পারে।

ফ্রি-টেক্সট নোটগুলো এখনও গুরুত্বপূর্ণ, কিন্তু এগুলো বিকল্প নয়। নোটগুলো কি ঘটেছে এবং আপনি কী পরীক্ষা করেছেন তা ব্যাখ্যা করে। কারণ কোড ইভেন্টকে শ্রেণীবদ্ধ করে। যদি আপনি শুধু নোটের উপর নির্ভর করেন, আপনি একই ধারণার দশটা ভিন্ন রূপ পাবেন (“broken,” “damaged,” “cracked,” “fell”), এবং আপনার ডেটা তুলনাযোগ্য থাকা বন্ধ করে দেয়।

অডিট ট্রেইল (কেবল একটি অ্যাক্টিভিটি লগ নয়)

একটি অ্যাক্টিভিটি লগ বলতেই পারে “পরিমাণ 12 থেকে 9 বদলে গেছে।” একটি অডিট ট্রেইল ব্যাখ্যা করে কীভাবে তা হলো এবং তা কি আপনার নিয়মগুলো অনুসারে হয়েছে কি না।

একটি ভালো অডিট ট্রেইল কে পরিবর্তন করেছে এবং কখন করেছে, কী পরিবর্তিত হয়েছে (আইটেম, লোকেশন, আগে এবং পরে পরিমাণ), এবং কেন পরিবর্তন হয়েছে (কারণ কোড প্লাস একটি নোট) ধারণ করে।

অডিটের জন্য আপনি সহায়ক প্রমাণও চাইবেন। এটা হতে পারে ক্ষতিগ্রস্ত প্যাকেজের ছবি, কাউন্ট শিট, রিটার্ন পেপারওয়ার্ক, ডিসপোজাল রেকর্ড, সরবরাহকারীর ইনভয়েস রেফারেন্স, বা একটি টিকিট/ইনসিডেন্ট নম্বর। উদ্দেশ্য কেবল কাগজপত্র সংগ্রহ করা নয়; এটি বদলকে মাস পরেও রক্ষাযোগ্য করা।

অনুমোদনগুলো ট্রেসেবিলিটি শক্ত করে। যদি ম্যানেজার অনুমোদন করে, ট্রেইলে দেখানো উচিত কে অনুমোদন করেছে, কখন, এবং তারা কী অনুমোদন করেছেন (কোনো সম্পাদন সহ)। AppMaster-এ ওয়ার্কফ্লো নির্মাণ করলে আপনি কারণ কোড নির্বাচনের বাধ্যবাধকতা রাখতে এবং স্থায়ী ইতিহাস রাখতে পারেন যাতে সম্পাদনা মূল রেকর্ড মুছে না দেয়।

অ্যাডজাস্টমেন্টের জন্য ভূমিকা ও দায়িত্ব

কোন অ্যাডজাস্টমেন্টই কখনোই কেবল “একটা সংখ্যা বদল” হয়ে থাকা উচিত নয়। যদি মানুষ জানে না কে স্টক পরিবর্তন করতে পারে, কখন করতে পারে, এবং পরে কে তা চেক করবে, আপনার অ্যাডজাস্টমেন্ট লগ ভুল-ত্রুটি লুকানোর নীরব জায়গা হয়ে উঠবে।

প্রথমে নির্ধারণ করুন কে অ্যাডজাস্টমেন্ট তৈরি করতে পারবে। অনেক গুদামে সমস্যা খুঁজে পাওয়ার টিমই শুরু করে: রিসিভিং (সংক্ষিপ্ত শিপমেন্ট), রিটার্ন (ক্ষতিগ্রস্ত রিটার্ন), বা সাইকেল কাউন্টের সময় ফ্লোর স্টাফ। আলাদাভাবে নির্ধারণ করুন কে অনুমোদন করতে পারে, কে পোস্ট করবে, এবং কে প্যাটার্ন রিভিউ করবে।

অনুমোদনগুলোই সীমা নির্ধারণ করে “রুটিন” এবং “সংবেদনশীল” মধ্যে। ছোটখাটো ড্যামেজ রাইট-অফ স্বয়ংক্রিয়ভাবে অনুমোদিত হতে পারে, আর উচ্চ-মূল্যের, বারবার বা অস্বাভাবিক কিছু সময় দ্বিতীয় ব্যক্তির অনুমোদন দরকার। মান নিশ্চিত করতে মানদণ্ড ব্যবহার করুন (মান, পরিমাণ, SKU ধরন, বা কারণ কোড অনুযায়ী) যাতে নিয়ম প্রতিবার একই থাকে।

ট্রেন্ড রিভিউ অনুমোদন থেকে আলাদা কাজ। ফাইন্যান্স মূল্যায়ন প্রভাব দেখবে, অপারেশন প্রক্রিয়াগত সমস্যা, এবং লস প্রিভেনশন চুরি-প্যাটার্ন খুঁজবে। রিভিউ নিয়মিত (সাপ্তাহিক বা মাসিক) হওয়া উচিত, শুধুমাত্র ভুল ঘটলে নয়।

দুর্যোগ হ্রাসের জন্য দায়িত্ব আলাদা রাখুন যাতে এক ব্যক্তি তৈরি, অনুমোদন এবং লুপ বন্ধ করতে না পারে। সহজ রাখুন: ক্রিয়েটর ও অনুমোদনকারী ভিন্ন ব্যক্তি হওয়া উচিত, অনুমোদনকারীরা মূল বিবরণ সম্পাদনা করা উচিত নয় (শুধু অনুমোদন বা প্রত্যাখ্যান), এবং “অ্যাডমিন ওভাররাইড” অ্যাক্সেস সীমিত ও লগ করা উচিত।

পরে যদি আপনি AppMaster-এ ভূমিকা ও অনুমোদন অটোমেট করতে চান, আপনি কোড ছাড়াই পারমিশন নিয়ম এবং সাদামাটা অনুমোদন ফ্লো বানিয়ে প্রত্যেক কাজের স্থায়ী ইতিহাস রাখতে পারবেন—কে কি করেছে এবং কখন।

আপনার অ্যাডজাস্টমেন্ট লগে কি ফিল্ড থাকা উচিত

একটি ইনভেন্টরি অ্যাডজাস্টমেন্ট লগ তখনই ব্যবহারযোগ্য যখন পরে কেউ তা পড়ে বুঝতে পারে কি হয়েছে, কে করেছে, এবং কেন অনুমোদিত হয়েছিল। এটিকে ভাবুন প্রতিটি স্টক পরিবর্তনের জন্য একটি রসিদ হিসেবে।

প্রারম্ভে একটি সুসংগঠিত হেডার রাখুন: তারিখ ও সময়, লোকেশন (ওয়্যারহাউস, স্টোর, বিন জোন), এটি তৈরি করা ইউজার, এবং সোর্স (সাইকেল কাউন্ট, কাস্টমার রিটার্ন, ড্যামেজ রিপোর্ট, সিস্টেম সিঙ্ক ইত্যাদি)।

তারপর প্রতিটি আইটেমের লাইনের জন্য বিস্তারিত ধরুন। অডিট প্রায়ই ব্যর্থ হয় কারণ টিমগুলো কেবল নেট পরিবর্তন সংরক্ষণ করে, পুরো আগে-এবং-পরের চিত্র রাখে না।

লাইনে ধরুন SKU (এবং আপনি যদি লট/সিরিয়াল/মেয়াদ ব্যবহার করেন তবে সেগুলো), আগে পরিমাণ, পরিমাণ পরিবর্তন (+ বা -), পরে পরিমাণ, এবং ইউনিট অফ মেজার (each, case, kg) যাতে কনভার্সন গোপনে ডেটা নষ্ট না করে। কারণ কোড ও একটি সংক্ষিপ্ত নোট যোগ করুন। যদি প্রমাণ অন্যান্য জায়গায় থাকে, একটি এটাচমেন্ট রেফারেন্স (ছবি আইডি, টিকিট নম্বর, কাউন্ট শিট নম্বর) সংরক্ষণ করুন যাতে ট্রেইল সংযুক্ত থাকে।

অনুমোদন সংখ্যাগুলোর মতো গুরুত্বপূর্ণ। অনুমোদন স্ট্যাটাস, অনুমোদনকারী নাম বা রোল, এবং তৈরি, জমা, অনুমোদন, ও পোস্ট করণের টাইমস্ট্যাম্প ট্র্যাক করুন। যদি আপনি সম্পাদনার অনুমতি দেন, কে কখন সম্পাদনা করেছে তা রেকর্ড করুন এবং পূর্ব মান সংরক্ষণ করুন।

অবশেষে, প্রতিটি অ্যাডজাস্টমেন্টের জন্য একটি অনন্য অ্যাডজাস্টমেন্ট ID থাকা দরকার যা কখনো বদলানো যায় না। এটি সার্চযোগ্য হওয়া উচিত এবং সম্পর্কিত ডকুমেন্টে (কাউন্ট শিট, রিটার্ন কাগজপত্র) দেখা উচিত। একটি অভ্যন্তরীণ টুলে, ID স্বয়ংক্রিয়ভাবে জেনারেট করুন এবং পোস্ট করা অ্যাডজাস্টমেন্টগুলো লক করুন যাতে ইতিহাস পরিষ্কার থাকে।

এমন কারণ কোড ডিজাইন করুন যা মানুষ ব্যবহার করবে

অনুমোদন থ্রেশহোল্ড সেট আপ করুন

উচ্চ ঝুঁকির অ্যাডজাস্টমেন্ট ও রাইট-অফের জন্য ম্যানেজার সাইন-অফ নিয়ম যোগ করুন।

ওয়ার্কফ্লো তৈরি করুন

কারণ কোড তখনই কাজ করে যখন মানুষ সেগুলো কয়েক সেকেন্ডে সঠিকভাবে বেছে নিতে পারে। যদি তালিকাটি দীর্ঘ, অস্পষ্ট বা “অন্যান্য” দিয়ে ভরা হয়, আপনার অ্যাডজাস্টমেন্ট লগ পরীক্ষা-নিরীক্ষায় গণ্ডগোল হবে।

ছোট থেকে শুরু করুন। একটি ছোট সেট একটি নিখুঁত ট্যাক্সোনমির থেকে ভাল যা কেউ ব্যবহার করে না। নতুন কোড যোগ করুন কেবল তখনই যখন নোটে একই ব্যাখ্যা বারবার প্রদর্শিত হয়।

একটি ব্যবহারিক স্টার্টার সেট সাধারণত প্রধান শ্রেণিগুলো কভার করে: damage (মধ্যে expired), theft বা loss, recount বা cycle count correction, supplier issue (short shipped বা ভুল আইটেম), এবং returns।

যট সম্ভব, কোডগুলোকে পারস্পরিকভাবে একচেটিয়া রাখুন। উদাহরণস্বরূপ, “Recount correction” কোডটি তখন ব্যবহার করা উচিত নয় যখন পুনঃগণনার সময় ভেঙে যাওয়া আইটেম পাওয়া যায়। সেটি উচিত “Damage” হিসেবে চিহ্নিত করা। পুনঃগণনা কিভাবে আপনি আবিষ্কার করেছেন, সেটি কেন ঘটল না।

প্রতিটি কোড এমন তথ্য বহন করুক যা পরে দরকার হবে। কেবল “Damage” অস্পষ্ট। কোড অনুযায়ী কিছু অতিরিক্ত ফিল্ড বাধ্যতামূলক করুন, যেমন damage type (crushed, leaking, expired) এবং কোথায় ঘটেছে (receiving dock, pick/pack, transit)। “Supplier issue” এর ক্ষেত্রে PO নম্বর এবং সেটা short, wrong, না defective ছিল তা ধরুন।

গ্রহণযোগ্যতা বাড়ে যখন কোডগুলো সাধারণ ভাষায় থাকে, ওভারল্যাপ কম থাকে, “Other” সীমিত থাকে (এবং সবসময় একটি নোট প্রয়োজন), এবং ব্যবহার মাসিকভাবে রিভিউ করা হয় যাতে ডেড কোডগুলো রিটায়ার করা যায়।

চূড়ান্তভাবে, নির্ধারণ করুন কোন কোডগুলো অনুমোদন দাবি করে। চুরি, বড় রাইট-অফ এবং থ্রেশহোল্ডের উপরের যেকোনো অ্যাডজাস্টমেন্ট সাধারণত ম্যানেজার সিগ-অফ দাবি করে। ছোট পুনঃগণনা সংশোধন নাও করতে পারে।

ধাপে ধাপে: সঠিকভাবে একটি অ্যাডজাস্টমেন্ট কিভাবে রেকর্ড করবেন

একটি অ্যাডজাস্টমেন্ট কেবল "সংখ্যা ঠিক করে নাও" থেকে শুরু হওয়া উচিত নয়। এটা শুরু হয় একটি অসামঞ্জস্য খুঁজে পাওয়া দিয়ে, তারপর যা ঘটেছে তা যাচাই করা, এবং তারপরই স্টক পরিবর্তন করা।

অডিট সহকারী একটি সহজ ওয়ার্কফ্লো

প্রথমে অসামঞ্জস্য এবং তার প্রেক্ষাপট রেকর্ড করুন: কোথায় দেখা গেছে (ওয়্যারহাউস, বিন, SKU, ডকুমেন্ট) এবং কে পেয়েছে।

পরবর্তীতে পরিবর্তন করার আগে যাচাই করুন। একটি দ্রুত পুনঃগণনা করুন, পাশের বিনগুলো চেক করুন মিস-স্লটিং আছে কি না, রিসিভিং এবং শিপিং কাগজপত্র পর্যালোচনা করুন, এবং ইউনিট অফ মেজার নিশ্চিত করুন (case vs each সাধারণ ফাঁদ)। যদি অসামঞ্জস্য কোনো অর্ডারের সাথে জড়িত, অর্ডার নম্বর রেকর্ড করুন।

তারপর অ্যাডজাস্টমেন্টটি ধারাবাহিকভাবে ঢোকান: সঠিক আইটেম ও লোকেশন বেছে নিন (লট/সিরিয়াল ব্যবহার করলে সেগুলোও), সঠিক চিহ্নসহ পরিমাণ পরিবর্তন লিখুন, একটি কারণ কোড বেছে নিন, এবং আপনি কী পরীক্ষা করেছেন ও কী পেয়েছেন সে সম্পর্কে একটি সংক্ষিপ্ত নোট যোগ করুন। প্রমাণ রেফারেন্স (ছবি আইডি, কাউন্ট শিট নম্বর, RMA, ইনসিডেন্ট রিপোর্ট) যোগ করুন এবং নীতিগত প্রয়োজন হলে অনুমোদনের জন্য সাবমিট করুন।

পোস্ট করার পরে, নিশ্চিত করুন সিস্টেম মূল মান, নতুন মান, টাইমস্ট্যাম্প, এবং ইউজার সংরক্ষণ করে। যদি আপনি অনুমোদন ব্যবহার করেন, অনুমোদনকারী এবং অনুমোদনের সময়ও সংরক্ষণ করুন।

ফলো-আপ স্কিপ করবেন না

দৈনিক বা সাপ্তাহিক সমরূপে অ্যাডজাস্টমেন্ট সারসংক্ষেপ রিভিউ করুন। প্যাটার্ন দেখুন: এক অঞ্চলে বারবার ড্যামেজ, এক SKU-তে বারবার পুনঃগণনা সংশোধন, বা বহু “অনির্দিষ্ট” কারণ। AppMaster-এ ওয়ার্কফ্লো তৈরি করলে আপনি কারণ কোড বাধ্যতামূলক করতে পারেন, নির্দিষ্ট থ্রেশহোল্ডের উপরে অনুমোদন প্রয়োজনে করতে পারেন, এবং সুপারভাইজারদের জন্য একটি সহজ রিভিউ স্ক্রিন দিতে পারেন অতিরিক্ত কাজ ছাড়াই।

কিভাবে স্থায়ী পরিবর্তন ইতিহাস রাখবেন

অ্যাপেন্ড-ওনলি চেঞ্জ হিস্টরি যোগ করুন

পোস্ট করা এন্ট্রিগুলো অপরিবর্তনীয় রাখুন এবং প্রতিটি পরিবর্তন নতুন ঘটনায় রেকর্ড করুন।

AppMaster ব্যবহার করে দেখুন

স্থায়ী ইতিহাস মানে আপনি মাস পরেও তিনটি প্রশ্নের উত্তর দিতে পারবেন: কি পরিবর্তিত হয়েছে, কে করেছে, এবং কেন? সবচেয়ে সহজ উপায় হলো অ্যাডজাস্টমেন্টগুলোকে অ্যাকাউন্টিং এন্ট্রির মতো বিবেচনা করা। আপনি ইভেন্টগুলো রেকর্ড করেন। আপনি অতীত পুনঃলিখন করেন না।

পোস্ট করা এন্ট্রিগুলো অপরিবর্তনীয় করুন

একবার একটি অ্যাডজাস্টমেন্ট পোস্ট হয়ে গেলে, মূল মান রাখুন এবং প্রতিটি পরিবর্তনকে একটি নতুন রেকর্ড হিসেবে সংরক্ষণ করুন। পুরোনো লাইনে পরিমাণ সম্পাদনা করা এড়িয়ে চলুন, যদিও তা দ্রুত মনে হতে পারে। ওভাররাইট প্রসঙ্গ মুছে ফেলে এবং অডিটকে কষ্টকর করে।

প্রতিটি পোস্ট করা এন্ট্রিতে আগে এবং পরে পরিমাণ (শুধু পার্থক্য নয়), সেটা কে তৈরি করেছে এবং কে অনুমোদন করেছে (প্রয়োজন হলে), উভয় ক্রিয়ার টাইমস্ট্যাম্প, কারণ কোড ও নোট, এবং একটি অনন্য অ্যাডজাস্টমেন্ট ID থাকা উচিত।

পোস্ট করা অ্যাডজাস্টমেন্ট মুছে দেওয়ার অনুমতি দেবেন না। কেউ ভুল করলে, একটি রিভার্সাল ব্যবহার করুন: ভুলটি বাতিল করার জন্য একটি নতুন অ্যাডজাস্টমেন্ট তৈরি করুন, তারপর সঠিক সংখ্যা নিয়ে আরেকটি অ্যাডজাস্টমেন্ট পোস্ট করুন। এতে ট্রেইল অটুট থাকে এবং সংশোধন ইচ্ছাকৃত ছিল তা দেখা যায়।

যখন সংশোধন বারবার হয় (উদাহরণস্বরূপ, পুনঃগণনা প্রথম কাউন্টটি ভুল প্রমাণ করে), সংশোধনী অ্যাডজাস্টমেন্টকে মূল অ্যাডজাস্টমেন্টের সাথে একটি সাধারণ “related adjustment ID” ফিল্ড দিয়ে লিঙ্ক করুন।

রিটেনশন ও অ্যাক্সেস নিয়ম সেট করুন

নিবার্চন করুন কতদিন অ্যাডজাস্টমেন্ট ইতিহাস ও সহায়ক নোট রাখবেন। অনেক দল বছরগুলোর জন্য রাখে কারণ অডিট অনেক দূরে তাকাতে পারে।

কে পোস্ট, অনুমোদন বা রিভার্স করতে পারে তা সীমিত করুন এবং প্রতিটি পারমিশন পরিবর্তন লগ করুন। আপনি AppMaster বা যেকোন অভ্যন্তরীণ টুলে প্রক্রিয়া অটোমেট করলে “append-only” নিয়মকে কেবল অভ্যাস নয় বরং ওয়ার্কফ্লো নিয়ম বানান।

সাধারণ ভুলগুলো যা অডিটেবিলিটি নষ্ট করে

স্প্রেডশিট থেকে অগ্রসর হোন

স্প্রেডশিটের বদলে অনুমতি, অনুমোদন এবং স্থায়ী ইতিহাস ব্যবহার করুন।

AppMaster ব্যবহার করে দেখুন

অধিকাংশ ইনভেন্টরি সমস্যা এক বড় ভুল থেকে আসে না। ছোট শর্টকাটগুলো জমে যেতে থাকে, এবং তারপর কেউই ব্যাখ্যা করতে পারে না কী পরিবর্তিত হলো, কখন, এবং কেন।

একটি সাধারণ সমস্যা হল খুব বেশি কারণ কোড। যখন তালিকাটি দীর্ঘ বা বিভ্রান্তিকর হয়, মানুষ চিন্তা করা বন্ধ করে এবং কাছাকাছি যেটা পাওয়াতে সেটি বেছে নেয়। ডেটা সংগঠিত মনে হলেও কার্যত র্যান্ডম হয়ে যায় এবং ট্রেন্ড রিপোর্ট অপ্রচলিত হয়ে পড়ে।

আরেকটি ফাঁদ হলো শুধুমাত্র ফ্রি-টেক্সট নোট। নোট সাহায্য করে, কিন্তু যদি প্রতিটি অ্যাডজাস্টমেন্ট কেবল একটি বাক্য হয়, আপনি কারণগুলো সময়ের সাথে গ্রুপ, ফিল্টার বা তুলনা করতে পারবেন না। আপনাকে শত শত এন্ট্রি হাতে পড়তে হবে।

উচ্চ-প্রভাবের পরিবর্তনের জন্য অতিরিক্ত নিয়ন্ত্রণ দরকার। যদি কেউ 500 ইউনিট লিখ-অফ করতে পারে কোনো দ্বিতীয় চোখ ছাড়াই, আপনার কাছে অডিট ট্রেইল থাকতে পারে, কিন্তু তা বৈধতা প্রমাণ করে না।

কিছু ওয়ার্কফ্লো প্যাটার্ন বারবার অডিট ব্যথা দেয়: ব্যাচ এডিট যা একসাথে বহু আইটেম আপডেট করে কিন্তু লাইনের স্তরে কারণ এবং পরিমাণ দেয় না, লোকেশন বা lot/serial মতো গুরুত্বপূর্ণ বিবরণ অনুপস্থিত থাকা, এবং পুরোনো রেকর্ড “ক্লিন-আপ” করে সম্পাদনা করা পরিবর্তে নতুন সংশোধনী করা না।

সর্বশেষটি বিশেষভাবে গুরুত্বপূর্ণ। একটি অডিট ট্রেইল ইতিহাসের ব্যাপার, পারফেকশনের নয়। যদি কেউ -12 লিখে দেয় এবং হওয়া উচিত -2, সংশোধন হওয়া উচিত একটি নতুন অ্যাডজাস্টমেন্ট যা ভুলটি রিভার্স করে, তার কারণ কোড (উদাহরণস্বরূপ, “data entry correction”) এবং একটি সংক্ষিপ্ত নোট দিয়ে।

আপনার লগ পরীক্ষা করার দ্রুত উপায় হল 10 টি অ্যাডজাস্টমেন্ট স্যাম্পল করা এবং জিজ্ঞাসা করা: কি কেউ নতুন একজন প্রতিটি বোঝাতে পারবে প্রশ্ন ছাড়াই? যদি না পারে, বাধ্যতামূলক ফিল্ডগুলো শক্ত করুন, কারণ কোডগুলো কম ও স্পষ্ট করুন, এবং উচ্চ-ঝুঁকির পরিবর্তনের জন্য অনুমোদন যোগ করুন।

উদাহরণ পরিস্থিতি: পুনঃগণনার পরে আইটেম অনুপস্থিত

আলকাত সাইকেল কাউন্ট Aisle B-তে একটি সমস্যা চিহ্নিত করে: SKU “WIDGET-250”–এ 200 ইউনিট থাকা উচিত ছিল, কিন্তু কাউন্টার 188 পেয়েছেন। এটা 12 ইউনিট অনুপস্থিত, এবং আপনার অ্যাডজাস্টমেন্ট লগকে ব্যাখ্যা করতে হবে কেন স্টক পরিবর্তিত হলো, কেবল এটা নয় যে এটা বদলেছে।

প্রথমে কাউন্টার বেসিকগুলো পরীক্ষা করে: নিশ্চিত করুন বিন লেবেল SKU-র সাথে মেলে, আশে-পাশের ওভারফ্লো লোকেশন স্ক্যান করুন, এবং কোনো ওপেন পিক টোট আছে কি না চেক করুন। দ্বিতীয় ব্যক্তি পুনঃগণনা করে। পুনঃগণনা এখনও 188 দেখায়, তাই এটিই সহজ মিসকাউন্ট নয়।

এখন প্রমাণের উপর ভিত্তি করে কারণ কোড বেছে নিন। যদি ক্যামেরা ফুটেজ বা ভাঙ্গা সীল ক্ষতি নির্দেশ করে, “theft” মানায়। যদি শিপিং এরিয়া এমন একটি কমপ্লিটেড অর্ডার দেখায় যা প্যাক করা হয়েছে কিন্তু কখনো ডিডাকশন হয়নি, তাহলে সেটা পিক/ট্রানজ্যাকশন ত্রুটি নির্দেশ করে। যদি দেখা যায় বুক পরিমাণ পূর্বের একটি গণনা ভুলের কারণে ভুল ছিল, “recount correction” ব্যবহার করুন। নিয়মটি সহজ: আপনি যে কারণটি সমর্থন করতে পারবেন সেটিই বেছে নিন।

একটি শক্ত এন্ট্রি পরে সিদ্ধান্ত অনুসরণ করা সহজ করে দেয়। এতে SKU ও লোকেশন (এবং লট/সিরিয়াল যদি ব্যবহৃত হয়), আগে পরিমাণ (200) এবং পরে পরিমাণ (188), কারণ কোড এবং একটি সংক্ষিপ্ত নোট যা প্রমাণ (recount sheet 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-ব্যাকডেড ডেটা মডেল, বাধ্যতামূলক ফিল্ড, অনুমোদন ওয়ার্কফ্লো, এবং এপেন্ড-ওনলি ইতিহাস যা কে কখন কি করেছে তা রেকর্ড করে।

প্রশ্নোত্তর

An inventory adjustment is a manual correction to the on-hand quantity when the system record doesn’t match reality. It’s not a receipt, transfer, or shipment; it’s an explicit “we are changing the book quantity because we verified it’s wrong.”

Use a reason code to classify why stock changed so you can report and audit consistently. A note explains the specific situation you found, what you checked, and any references like a count sheet or incident number.

Start with a small set that covers your real situations and is easy to choose in a few seconds. Most teams do well with codes for damage/expired, theft or loss, recount or cycle count correction, supplier short-ship or wrong item, and returns, then add only when you see repeated notes that don’t fit.

“Other” is fine as a safety valve, but it should always require a clear note so it doesn’t become a dumping ground. If “Other” shows up often, that’s a signal to create one or two new codes that match what’s really happening.

An activity log might only show that a quantity changed. An audit trail also captures who made the change, when it happened, what exactly changed (including before and after), why it changed (reason code and note), and how it was approved if approvals are required.

Record enough to make the adjustment defensible later, not just believable today. Common proof is a count sheet ID, return paperwork reference, disposal record, supplier document reference, or a photo identifier for damage, so someone can trace the decision months later.

Require approvals for high-risk or unusual changes, like high-value write-offs, theft/loss reasons, big quantity swings, negative stock outcomes, or backdated adjustments. The key is to make the trigger predictable so staff don’t have to guess when manager sign-off is needed.

Separate duties so one person can’t create, approve, and quietly “fix” issues alone. A practical setup is that warehouse staff create adjustments, a manager approves, and a different role (often ops or finance) reviews trends on a schedule.

Don’t edit or delete posted adjustments; create a new entry that reverses the wrong one, then post the correct adjustment with a clear correction reason and note. This keeps the history intact and makes it obvious what happened and how it was fixed.

A spreadsheet works at low volume, but it’s easy to bypass and hard to keep consistent permissions and history. In an internal app built with AppMaster, you can require reason codes, enforce approvals, store before-and-after quantities, and keep an append-only change history so edits don’t overwrite the original record.