/requisition/requisition/pendingরিকুইজিশনটি APPROVED হয়ে Approved তালিকায় চলে আসে, দরপত্র প্রক্রিয়ার জন্য প্রস্তুত। এর পণ্যগুলো SUBMITTED অবস্থাতেই থাকে — আপনি সত্যিকারভাবে দরপত্রের অনুরোধ পাঠালে তবেই সেগুলো QUOTE_REQUESTED-এ যায়।
/requisition/approvedপ্রতি পণ্যের জন্য প্রতি ভেন্ডরকে আলাদা একটি অনুরোধ তৈরি হয় — তিনটি পণ্য ও চারজন ভেন্ডর মানে বারোটি অনুরোধ। প্রত্যেক আমন্ত্রিত ভেন্ডরকে নোটিফিকেশন ও ইমেইল পাঠানো হয়, এবং প্রতিটি পণ্য QUOTE_REQUESTED-এ যায়।
গোটা সিস্টেমে এই একটি জায়গাতেই ক্লায়েন্ট-ভেন্ডর দেয়ালটি সিস্টেমের নয়, আপনার উপর নির্ভর করে। ভেন্ডর যে নাম ও বর্ণনা দেখবে, সরবরাহকারী হুবহু সেটিই পড়বে। ইমেইলে কেবল পণ্য, পরিমাণ ও শেষ সময় যায় — কিন্তু বর্ণনার ভেতরে ক্লায়েন্টের নাম রেখে দিলে সেটি আপনিই ফাঁস করলেন। ক্লায়েন্টের লেখায় তাদের পরিচয় থাকলে সেটি বদলে দিন।
/quotation-selectএকটিমাত্র পদক্ষেপেই: নির্বাচনটি তৈরি হয়, বিজয়ী দরটি SELECT-এ যায়, ওই পণ্যের বাকি সব দর REJECT হয়ে যায়, এবং পণ্যটি চূড়ান্ত মূল্যসহ QUOTE_SELECTED-এ যায়। এরপর পণ্যটি Purchase Order পাতায় দেখা যাবে।
/purchase-orderঅর্ডারটি ISSUED অবস্থায় তৈরি হয়, ভেন্ডরকে নোটিফিকেশন ও ইমেইলে ক্রয়াদেশ পাঠানো হয়, এবং পণ্যগুলো PO_CREATED-এ যায়।
একটি অর্ডারের প্রতিটি নির্বাচনে একই ভেন্ডর, একই ক্লায়েন্ট ও একই ক্লায়েন্ট ইউনিট থাকতে হবে, এবং কোনোটি আগে থেকে অন্য অর্ডারে থাকা চলবে না। মিশ্র দল বাতিল হয়ে যায়।
/po-docsএটি না করা পর্যন্ত Finance আটকে থাকে। সংযুক্তি নেই এমন কোনো ক্রয়াদেশের বিপরীতে বিল তৈরি করা যায় না — সরাসরি বাতিল হয়ে যায়। এই পাতাটি ঐচ্ছিক কাগজপত্র নয়; এটি পেমেন্ট শৃঙ্খলের একটি ফটক, আর টাকার অপেক্ষায় থাকা সরবরাহকারী প্রায়ই এখানেই আটকে থাকেন।
/receiveপণ্যটি RECEIVED-এ যায়, একটি inventory movement লিপিবদ্ধ হয়, এবং গুদামের মজুদ বাড়ে। এরপর পণ্যটি Inventory পাতায় আসে, ক্লায়েন্টের কাছে পাঠানোর জন্য প্রস্তুত।
/inventoryচালান ও পণ্য দুটোই IN_TRANSIT-এ যায়। গন্তব্য ক্লায়েন্ট বা ইউনিটের সব ব্যবহারকারীকে Receive Items পাতার লিংকসহ নোটিফিকেশন পাঠানো হয়, যেখানে তাঁরা প্রাপ্তি নিশ্চিত করেন। তাঁদের এই নিশ্চিতকরণই Finance-কে সক্রিয় করে — তাঁরা নিশ্চিত না করা পর্যন্ত কোনো বিল তৈরি করা যায় না।