০৪ মে, ২০২৫·8 মিনিট পড়তে

অনুমোদন ও PO-র জন্য ক্রয় অনুরোধ অ্যাপ ব্লুপ্রিন্ট

Q: What should be the first milestone for a procurement request app?

Start with **request to PO**. It forces clear approvals, budget checks, and traceability without dragging you into invoice matching and receiving right away. You can add downstream steps after the team trusts the first milestone.

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

একটি অভ্যন্তরীণ ক্রয় অনুরোধ অ্যাপে কোন সমস্যাগুলো সমাধান করা উচিত

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

একটি রিকোয়েস্ট অ্যাপকে যে কোনো মুহূর্তে স্ট্যাটাস স্পষ্ট করে দেখাতে হবে। আপনি একটি অনুরোধ খুললে সঙ্গে সঙ্গে দেখতে পারা উচিত কে এটি সাবমিট করেছে, তারা কী কিনতে চায়, আনুমানিক খরচ কত এবং পরের ধাপ কী হবে। এর পাশাপাশি একটি পরিষ্কার ইতিহাস থাকা প্রয়োজন: কে অনুমোদন বা প্রত্যাখ্যান করেছে, কখন করেছে এবং পরবর্তীতে কী পরিবর্তিত হয়েছে।

তথ্য খুঁটিয়ে দেখার ছাড়াই প্রতি অনুরোধের ন্যূনতমভাবে এই প্রশ্নগুলোর উত্তর থাকা উচিত:

পরবর্তী ধাপের মালিক কে?
কী মুলতুবি আছে (অনুমোদন, বাজেট চেক, সরবরাহকারীর কোট, PO তৈরি)?
কী অনুমোদিত হয়েছে (পরিমাণ, সরবরাহকারী, পরিধি), এবং তা পরিবর্তিত হয়েছে কি?
কখন এটি প্রয়োজন, এবং কেন?
অডিট ট্রেইল কী যাতে ফাইন্যান্স বিশ্বাস করতে পারে?

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

প্রথম ভার্সনটি সাদাসিধে রাখুন। এক টিম, এক অনুমোদন পাথ এবং “সম্পূর্ণ” এর একটি পরিষ্কার সংজ্ঞা দিয়ে শুরু করুন। উদাহরণস্বরূপ, IT অনুরোধগুলো যার মূল্য $1,000-এর কম তাদের কেবল ম্যানেজারের অনুমোদন লাগতে পারে, যেখানে বড় কেনাকাটা ফাইন্যান্সের কাছে যাবে।

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

ব্যবহারকারী, ভূমিকা এবং অ্যাক্সেস নিয়ম

একটি ক্রয় অনুরোধ অ্যাপ অনুমতি দ্বারা জীবনযাত্রা নির্ধারণ করে। যদি ভুল ব্যক্তি অনুমোদনের পর অনুরোধ পরিবর্তন করতে পারে, বা টিমগুলো তাদের প্রয়োজনীয় জিনিস দেখতে না পারে, প্রক্রিয়াটি ধীর এবং ঝুঁকিপূর্ণ হয়ে যায়।

প্রথমে পরিষ্কার ভূমিকা নামকরণ করে শুরু করুন। টাইটেলগুলো কোম্পানিভিত্তিকভাবে ভিন্ন হতে পারে, কিন্তু বেশিরভাগ অ্যাপে স্থিতিশীল দায়িত্ব দরকার: requesters (অনুরোধ তৈরি করে এবং প্রশ্নের উত্তর দেয়), managers (চাহিদা ও সময় নিশ্চিত করে), procurement (সরবরাহকারী যাচাই করে এবং PO তৈরি করে), finance (বাজেট ও নীতি নিশ্চিত করে), এবং এক বা একাধিক approvers (স্বীকৃতি অনুমোদনকারী)। কিছু ওয়ার্কফ্লোতে সীমিত-অ্যাক্সেস vendor contact থাকে বাহ্যিক-বিষয় শেয়ার করার জন্য।

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

দৃশ্যমানতার নিয়মগুলোও একইভাবে স্পষ্ট হওয়া উচিত। রিকোয়েস্টাররা তাদের নিজস্ব অনুরোধ এবং স্ট্যাটাস দেখতে পারবে। ম্যানেজাররা তাদের সরাসরি রিপোর্টের অনুরোধ দেখতে পারবে। procurement এবং finance সাধারণত ক্রস-ডিপার্টমেন্ট দৃশ্যমানতা প্রয়োজন। vendor contacts কখনই অভ্যন্তরীণ নোট, বাজেট ডেটা বা অন্য সরবরাহকারীদের দেখবে না।

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

ক্রস-ডিপার্টমেন্ট অনুরোধ সাধারণ (উদাহরণ: IT Marketing-এর জন্য সফটওয়্যার কিনছে)। “রিকোয়েস্টার টিম” কে আলাদা রাখুন “কস্ট সেন্টার অনার” থেকে। কস্ট সেন্টার অনারকে অনুমোদনের জন্য রুট করুন, এবং রেকর্ডে উভয়কে দেখান যাতে স্পষ্ট হয় কে অনুরোধ করেছে এবং কে পরিশোধ করে।

AppMaster-এ আপনি ডেটা মডেল এবং বিজনেস প্রসেসে ভূমিকা, রেকর্ড মালিকানা, এবং স্টেজ-ভিত্তিক অ্যাকশন মডেল করতে পারেন, যাতে একই নিয়ম ওয়েব এবং মোবাইল উভয় স্ক্রিনে প্রযোজ্য হয়।

ডেটা মডেল: কোর এনটিটি ও ফিল্ডগুলো

একটি ভাল ক্রয় অনুরোধ অ্যাপ পরিষ্কার ডেটা মডেল দিয়ে শুরু হয়। যদি আপনার টেবিলগুলো পরিষ্কার থাকে, অনুমোদন, বাজেট চেক, এবং PO-কে অটোমেট ও রিপোর্ট করা সহজ হয়।

অন্তর্ভুক্ত করার জন্য কোর এনটিটিগুলো

অধিকাংশ টিম সামান্য সংখ্যক এনটিটি দিয়ে অনেক কেস কভার করে:

অনুরোধ (Requests): প্রতি ক্রয় অনুরোধের জন্য একটি রেকর্ড (হেডার)।
অনুরোধ আইটেম (RequestItems): লাইন আইটেম, পরিমাণ, এবং আনুমানিক ইউনিট দাম।
সরবরাহকারী (Vendors): রিকোয়েস্ট ও PO-তে পুনরায় ব্যবহারযোগ্য সাপ্লায়ার মাস্টার ডেটা।
বাজেট (Budgets): কস্ট সেন্টার, প্রজেক্ট, ডিপার্টমেন্ট বা সময় ইউনিট অনুযায়ী উপলব্ধ ব্যয়।
ক্রয় অর্ডার (PurchaseOrders): অনুমোদিত অনুরোধ থেকে তৈরি আনুষ্ঠানিক অর্ডার।
অনুমোদন (Approvals): প্রতিটি অনুমোদন ধাপ, সিদ্ধান্ত, ও মন্তব্য।

পরবর্তী সময়ে কাজে লাগার মতো ফিল্ডগুলো

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

স্ট্যাটাস তখনই ভাল কাজ করে যখন সেগুলো স্পষ্ট এবং টাইমস্ট্যাম্প দ্বারা সমর্থিত। Requests-এ একটি স্ট্যাটাস ফিল্ড রাখুন (Draft, Submitted, Approved, Rejected, Ordered, Closed), এবং গুরুত্বপূর্ণ তারিখগুলো সংরক্ষণ করুন যেমন submitted_at, approved_at, rejected_at, ordered_at, closed_at। এটি রিপোর্টিং (সাইকেল টাইম, এজিং, বটলনেক) সহজ করে দেয় লোগ থেকে অনুমান না করে।

PurchaseOrders-এর জন্য PO হেডার (নাম্বর, ভেন্ডর, ship-to, bill-to, পেমেন্ট টার্ম) আলাদা রাখুন PO লাইন আইটেম থেকে, এবং মূল অনুরোধ ও আইটেমগুলোর সাথে লিংক রাখুন। যখন দাম পরিবর্তিত হয় তখন সেই ট্রেসেবিলিটি গুরুত্বপূর্ণ।

অডিট ট্রেইল ডিজাইন

অনুমোদনগুলো আপনার অডিট ট্রেইল, কিন্তু আপনি সাধারণত শুধু “approved/rejected” ছাড়াও আরও কিছু প্রয়োজন। কে কাজ করেছে, কখন করেছে, সিদ্ধান্ত কী ছিল, এবং কেন তা সংরক্ষণ করুন।

একটি হালকা-ওজন পদ্ধতি হল একটি Activity/Audit টেবিল যাতে actor_user_id, entity_type, entity_id, action, old_value, new_value, এবং created_at থাকে। AppMaster-এ এটি Data Designer-এ সরাসরি মানায় এবং বিজনেস প্রসেস থেকে স্বয়ংক্রিয়ভাবে পূরণ করা যায় যাতে প্রতিটি পরিবর্তন ট্রেসেবল হয়।

সরবরাহকারী রেকর্ড ও যোগাযোগ ট্র্যাকিং

একটি procurement request অ্যাপ তখনই কাজ করে যখন সবাই একই সরবরাহকারী তথ্য ব্যবহার করে। আপনার ভেন্ডর টেবিলকে সিঙ্গল সোর্স অফ ট্রুথ হিসাবে বিবেচনা করুন, প্রতিটি অনুরোধে মানুষ রিটারাইপ না করে। যখন ভেন্ডার ডিটেইল এক জায়গায় থাকে, অনুমোদন দ্রুত হয়ে যায় এবং ফাইন্যান্স কম অপ্রত্যাশিত দেখে।

ভেন্ডার রেকর্ডে এমন বেসিক তথ্য রাখুন যা আপনি পুনরায় ব্যবহার করবেন: লিগ্যাল নাম, ডিসপ্লে নাম, ট্যাক্স আইডি (যদি ব্যবহার করেন), ডিফল্ট কারেন্সি, বিলিং ঠিকানা, এবং পেমেন্ট টার্ম। প্রধান accounts payable ইমেইল রাখুন, এবং একাধিক কন্টাক্টের অনুমতি দিন যাতে কোটের জন্য ও ইনভয়েসের জন্য সঠিক ব্যক্তি ব্যবহার করা যায়।

ভেন্ডার স্ট্যাটাস যোগ করুন যাতে অ্যাপ ঝুঁকিপূর্ণ কেনাকাটা ব্লক করতে পারে সঙ্গতিপূর্ণভাবে: Active (নির্বাচনযোগ্য), Pending review (অনুমতি দিলে অতিরিক্ত যাচাই), এবং Blocked (রিভিউ ছাড়া ব্যবহার করা যাবে না)।

যোগাযোগ ট্র্যাকিং "তাঁরা শেষবার কার কাছে ইমেইল দিয়েছিল?" সমস্যাটি রোধ করে। Vendor এবং সম্ভব হলে নির্দিষ্ট Request, Quote, বা Purchase Order-এ লিঙ্ক করা একটি Communication (বা VendorInteraction) এনটিটি তৈরি করুন। প্রতিটি রেকর্ডে চ্যানেল (ইমেইল, কল, মিটিং), দিক (outbound/inbound), টাইমস্ট্যাম্প, মালিক, এবং সংক্ষিপ্ত সারসংক্ষেপ ধারণ করুন। যদি আপনি কোট সংগ্রহ করেন, সেগুলোকে স্ট্রাকচার্ড রেকর্ড হিসেবে স্টোর করুন (পরিমাণ, কারেন্সি, বৈধতার তারিখ) এবং প্রয়োজন অনুযায়ী ফাইল অ্যাটাচ করুন।

কয়েকটি নিয়ম সাধারণত ভেন্ডার ডেটা পরিষ্কার রাখে:

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

AppMaster-এ আপনি Vendor, VendorContact, এবং VendorCommunication Data Designer-এ মডেল করতে পারেন এবং রিকোয়েস্ট ও PO স্ক্রিনে একটি টাইমলাইন দেখাতে পারেন যাতে সম্পূর্ণ ইতিহাস এক ক্লিকে পাওয়া যায়।

বাজেট চেক: অনুমোদনের আগে ব্যয় কীভাবে যাচাই করবেন

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

স্পষ্ট স্ট্যাটাস, দায়িত্ব এবং অডিট ট্রেইলসহ request-to-PO ওয়ার্কফ্লো তৈরি করুন।

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

একটি বাজেট চেক একটি সহজ প্রশ্নের উত্তর দেয়: এই অনুরোধের জন্য আমাদের কাছে এই মুহূর্তে পর্যাপ্ত অনুমোদিত টাকা আছে কি? শুরুতেই সিদ্ধান্ত নিন আপনার কোম্পানি বাজেটে কঠোর বাধা (যা এগোতে দেবে না) হিসেবে দেখবে নাকি একটি সতর্কবার্তা (এটি চালিয়ে যেতে পারবে, তবে অতিরিক্ত অনুমোদন দরকার) হিসেবে দেখবে। সেই এক সিদ্ধান্ত পুরো অভিজ্ঞতাটাই বদলে দেয়।

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

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

একটি সহজ ক্যালকুলেশন চেকলিস্ট যা বেশিরভাগ টিম ব্যবহার করে: লাইনের মোট (qty x unit price), ছাড়, ট্যাক্স, শিপিং ও হ্যান্ডলিং, এবং কারেন্সি কনভারশন (রেট ও রেটের তারিখ সংরক্ষণ করুন)। তারপর প্রত্যাশিত ব্যয়কে উপলব্ধ বাজেটের সাথে তুলনা করুন (বাজেট মাইনাস ইতিমধ্যে কমিট করা পরিমাণ)। যদি আপনি কমিটমেন্ট ট্র্যাক করেন,PENDING_REQUESTS এবং ওপেন PO-ও অন্তর্ভুক্ত করুন, শুধুমাত্র পরিশোধিত ইনভয়েস নয়।

যখন বাজেট নেই, রিকোয়েস্টারকে কল্পনা করতে বাধ্য করবেন না। একটি পথ বেছে নিন এবং ওয়ার্কফ্লোতে এনকোড করুন: বাজেট অনিয়ন্ত্রিত হলে কস্ট সেন্টার মালিককে রুট করুন, এক-বারের ওভাররাইডের জন্য ফাইন্যান্স অনুমোদন অনুমতি দিন, “বাজেট ডিটেইল” টাস্ক সহ অনুরোধ ফিরিয়ে দিন, বা সবসময় বাজেট প্রয়োজন এমন ক্যাটাগরিকে অটো-রিজেক্ট করুন।

উদাহরণ: একটি টিম নতুন ল্যাপটপ বান্ডেল অনুরোধ করে। অ্যাপ আইটেম খরচ প্লাস ট্যাক্স ও শিপিং গণনা করে, বিভাগের কারেন্সিতে রূপান্তর করে, এবং দেখায় যে $1,150 অনুরোধের বিরুদ্ধে কেবল $900 উপলব্ধ। যদি আপনি এটিকে সতর্কবার্তা হিসেবে ধরেন, এটি ম্যানেজারের কাছে যেতে পারে, কিন্তু ফাইন্যান্স অনুমোদন বাধ্যতামূলক হয়ে যায়।

AppMaster-এ আপনি Budget উৎসগুলো Data Designer-এ মডেল করতে পারেন এবং প্রথম অনুমোদনের সিদ্ধান্ত নেওয়ার আগে একটি Business Process ধাপে চেক চালাতে পারেন।

অনুমোদন ও রাউটিং নিয়ম

অনুমোদনই সেই জায়গা যেখানে একটি রিকোয়েস্ট অ্যাপ সময় বাঁচায় না হলে এটি ধীর ইনবক্স রিলে হয়ে যায়। ডিফল্ট পাথটি সাদাসিধে রাখুন, তারপর শুধুমাত্র সেই নিয়মগুলো যোগ করুন যা প্রকৃত ঝুঁকি রোধ করে।

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

রাউটিং নিয়মগুলো পূর্বানুমানযোগ্য হওয়া উচিত। মানুষকে সাবমিট করা আগে আন্দাজ করতে পারা উচিত পরবর্তী ধাপ কী হবে। সাধারণ রাউটিং ফ্যাক্টরগুলো: পরিমাণ থ্রেশহোল্ড, ক্যাটাগরি-ভিত্তিক রাউটিং (সফটওয়্যার হলে security-তে, কনট্র্যাক্ট হলে legal-এ), ভেন্ডার ঝুঁকি স্তর, ডিপার্টমেন্ট বা কস্ট সেন্টার নিয়ম, এবং ক্রয় প্রকার (CapEx বনাম OpEx, subscription বনাম one-time)।

যেখানে অর্ডার গুরুত্বপূর্ণ সেখানে সিকোয়েনশিয়াল অনুমোদন ব্যবহার করুন। উদাহরণস্বরূপ, ফাইন্যান্স একটি অনুরোধকে ব্লক করতে পারে যদি কস্ট সেন্টার অনুপস্থিত থাকে, তাই procurement-কে সময় নষ্ট করার আগে সেটি ধরাই ভাল। যেখানে দলগুলো স্বতন্ত্রভাবে রিভিউ করতে পারে, সেখানে প্যারালাল অনুমোদন ব্যবহার করুন, যেমন security এবং legal একই সময়ে একটি SaaS কেনাকাটা রিভিউ করে যখন ফাইন্যান্স বাজেট চেক করে।

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

উদাহরণ: $12,000 SaaS টুল ম্যানেজার ও ফাইন্যান্সকে প্রথমে যায়। উভয় অনুমোদনের পরে security ও procurement প্যারালেলে চলে। যদি security কোনো ডেটা প্রসেসিং তথ্য অনুপস্থিত বলে ফ্ল্যাগ করে, এটি রিকোয়েস্টারে ফিরে যায়, রিকোয়েস্টার তথ্য যোগ করে পুনরায় জমা দেয়, এবং একই ধাপে ইতিহাস অক্ষুণ্ন থাকে।

AppMaster-এ ওয়ার্কফ্লো স্টেট ও ট্রানজিশনগুলো Business Process-এ মডেল করুন যাতে রাউটিং দৃশ্যমান থাকে এবং নীতির সঙ্গে তাল মিলিয়ে সহজে সামঞ্জস্য করা যায়।

ধাপে ধাপে: অনুরোধ থেকে ক্রয় অর্ডার পর্যন্ত

ব্লুপ্রিন্টকে অ্যাপে পরিণত করুন

Requests, Vendors, Budgets এবং POs এক জায়গায় মডেল করুন, তারপর অ্যাপ জেনারেট করুন।

বিল্ড করা শুরু করুন

একটি ভাল ফ্লো অনুরোধগুলোকে এগোতে রাখে কিন্তু বিবরণ ভাসিয়ে দেয় না। পর্যাপ্ত তথ্য শুরুতেই ধরুন, তারপর রিভিউ শুরু হলে গুরুত্বপূর্ণ ক্ষেত্রগুলো ফ্রিজ করুন।

অধিকাংশ টিমের জন্য একটি ব্যবহারিক সিকোয়েন্স:

ড্রাফট অনুরোধ: লাইন আইটেম, পরিমাণ, টার্গেট দাম, প্রিফার্ড ভেন্ডর (বা ভেন্ডর TBD), বিজনেস রিজন, কস্ট সেন্টার, এবং প্রয়োজনের তারিখ যুক্ত করুন। কোট বা প্রেক্ষাপট অ্যাটাচ করুন যাতে অনুমোদকরা চেস করতে না হয়।
সাবমিট করে কি ফিল্ড লক করুন: রিকোয়েস্টার যখন Submit করে, ভেন্ডর, কারেন্সি, কস্ট সেন্টার, এবং মোট আনুমানিক মূল্য লক করুন। একটি ছোট মন্তব্য এলাকা সম্পাদনাযোগ্য রাখুন যাতে রিভিউয়াররা প্রশ্ন করতে পারে ছাড়াও রেকর্ড বদলানো না হয়।
বাজেট চেক চালান ও রুটিং করুন: মানুষ অনুমোদন করার আগে ব্যয় যাচাই করুন। যদি অনুরোধ থ্রেশহোল্ড ছাড়ায়, কোট অনুপস্থিত, বা একটি সীমাবদ্ধ ক্যাটাগরির সঙ্গে বাঁধা থাকে, সঠিক গ্রুপে রুট করুন। যদি বাজেট অনুপস্থিত থাকে, নির্দিষ্ট কারণ সহ ফিরিয়ে দিন।
চূড়ান্ত অনুমোদনের পরে PO তৈরি করুন: অনুমোদিত অনুরোধ থেকে PO জেনারেট করুন এবং অনুমোদিত লাইন আইটেমগুলো কপি করুন। PO ভেন্ডর-ফেসিং সংখ্যাগুলোর জন্য সত্যের উৎস হয়।
PO পাঠান এবং কনফার্মেশন ট্র্যাক করুন: কখন PO পাঠানো হয়, ভেন্ডারের স্বীকৃতি, ডেলিভারি তারিখ, এবং কোনো আংশিক ডেলিভারি রেকর্ড করুন। যদি ভেন্ডার পরিবর্তন প্রস্তাব করে, সেগুলোকে একটি সংস্করণ হিসেবে ধরুন।

উদাহরণ: একটি সাপোর্ট টিম 10টি হেডসেট চায়। তারা কোট অ্যাটাচ করে, IT Supplies ক্যাটাগরি নির্বাচন করে, এবং সাবমিট করে। অ্যাপ IT বাজেট চেক করে, টিম লিডকে রুট করে (ইতিমধ্যে $1,000-এর নিচে) এবং $500-এ বেশি হলে ফাইন্যান্সকেও দরকার হয়। অনুমোদনের পরে PO জেনারেট হয় ও পাঠানো হয়, এবং ক্রয়কারী কনফার্মেশন ও ডেলিভারি তারিখ লগ করে।

নো-কোড টুল যেমন AppMaster-এ এটি সাধারণত কয়েকটি স্ক্রিন (Draft, Review, PO) এবং একটি Business Process হয় যা ফিল্ড লক করে, বাজেট লজিক চালায়, এবং স্বয়ংক্রিয়ভাবে PO রেকর্ড তৈরি করে।

ক্রয় অর্ডার: নম্বরিং, লাইন আইটেম, এবং পরিবর্তন নিয়ন্ত্রণ

ওয়েব ও মোবাইল সাপোর্ট করুন

একই মডেল থেকে রিকোয়েস্টার এবং অনুমোদকদের জন্য web এবং native mobile ইন্টারফেস তৈরি করুন।

স্ক্রিন তৈরি করুন

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

PO নম্বরিং: কখন জেনারেট করবেন

PO নম্বর তখনই জেনারেট করুন যখন PO আনুষ্ঠানিকভাবে ভেন্ডারের কাছে ইস্যু করা হয়, কেউ যখন খসড়া তৈরি শুরু করে তখন নয়। খসড়া মুছে ফেলা, পুনরায় শুরু করা, এবং মার্জ হওয়া হয়—এইভাবেই গ্যাপ এবং ডুপ্লিকেট হয়।

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

PO স্ট্রাকচার: হেডার, লাইন, এবং টোটাল

PO-কে হেডার ও লাইন আইটেমে ভাগ করুন। হেডার প্রসঙ্গ রাখে; লাইনগুলো যা আপনি কিনছেন তা ধরে।

হেডারটি ফোকাস করুন: ভেন্ডর ও কন্টাক্ট, ship-to ও bill-to ডিটেইল, কারেন্সি, পেমেন্ট টার্ম, প্রত্যাশিত ডেলিভারি তারিখ, স্ট্যাটাস (Draft, Issued, Acknowledged, Closed), এবং কোট রেফারেন্স।

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

পরিবর্তন নিয়ন্ত্রণ: সংস্করণ বনাম বাতিল ও পুনঃইস্যু

আগে থেকেই ঠিক করুন কখন একটি সংস্করণ অনুমোদনযোগ্য। ছোট পরিবর্তন যেমন ডেলিভারি তারিখ বা নোট সংস্করণ হিসেবে করা যেতে পারে (উদাহরণ: PO-1042 v2) এবং “supersedes v1” লিঙ্ক স্পষ্ট থাকবে। বড় পরিবর্তন যেমন ভেন্ডার, কারেন্সি, বা মোটের একটি গুরুত্বপূর্ণ পরিবর্তন সাধারণত “বাতিল ও পুনরায় ইস্যু” দাবি করে যাতে কেউ ভুল ডকুমেন্ট বাইরে পাঠায় না।

উদাহরণ: একটি অনুরোধ 10 ল্যাপটপের জন্য অনুমোদিত, কিন্তু ভেন্ডারের কোট ডেলিভারি 2 সপ্তাহ থেকে 8 সপ্তাহে পরিবর্তিত হয়েছে। আপডেট ডেলিভারি তারিখ সহ একটি সংস্করণ তৈরি করুন এবং মূল কোটের ডিটেইল সংযুক্ত রাখুন যাতে PO সবসময় যা চুক্তি হয়েছে তা ম্যাচ করে।

AppMaster-এ PO হেডার, লাইন আইটেম, এবং PO ভার্সন আলাদা এনটিটি হিসেবে মডেল করুন যাতে সংস্করণগুলো পরিষ্কার ও অডিটেবল থাকে।

নোটিফিকেশন ও ভেন্ডার যোগাযোগ ওয়ার্কফ্লো

নোটিফিকেশন নির্ধারণ করে একটি অভ্যন্তরীণ ক্রয় ওয়ার্কফ্লো মসৃণ মনে হবে নাকি থ্রেড-হান্টে ভুগবে। মেসেজগুলোকে প্রক্রিয়ার অংশ হিসেবে নিন এবং সেগুলোকে একটি স্ট্যাটাস পরিবর্তন বা স্পষ্ট পরবর্তী অ্যাকশনের সঙ্গে যুক্ত রাখুন।

প্রথমে একটি ছোট সেটের ইন্টারনাল আপডেট রাখুন যাতে মানুষ তাদের অযথা নোটিফিকেশন বন্ধ না করে: approved/rejected, বাজেট চেক ব্যর্থ বা পরিষ্কারীকরণ প্রয়োজন, PO তৈরি ও পাঠানোর জন্য প্রস্তুত, অনুমোদন অদক্ষ বা ডেলিভারি দেরি, এবং PO পরিবর্তন বা বাতিল।

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

ভেন্ডার যোগাযোগও স্ট্রাকচার্ড হওয়া উচিত। ভেন্ডাররা সাধারণত PO পাঠানো, PO পরিবর্তন, বাতিল, এবং ডেলিভারি প্রশ্ন জানতে চায়। প্রতিটি আউটবাউন্ড ও ইনবাউন্ড মেসেজ সেই PO বা রিকোয়েস্টের ভেন্ডার থ্রেডে সংরক্ষণ করুন। আউটকামগুলো ট্র্যাক করুন সহজ ফিল্ড দিয়ে যেমন স্ট্যাটাস (draft, sent, delivered, failed), vendor_response (none, replied, bounced), follow_up_needed (yes/no), এবং follow_up_date।

উদাহরণ: একটি ল্যাপটপ অনুরোধ অনুমোদিত হয়, PO পাঠানো হয়, এবং ভেন্ডার জানায় যে মডেল ব্যাকঅর্ডার। অ্যাপ রিপ্লাই লগ করে, follow_up_needed-কে yes করে দেয়, এবং রিকোয়েস্টারকে বিকল্প বাছাই করার জন্য নোটিফাই করে। AppMaster-এ আপনি স্ট্যাটাস পরিবর্তনকে ইমেইল/SMS/Telegram স্টেপের সঙ্গে সংযুক্ত করতে পারেন এবং মেসেজ আউটকাম PO-এর পাশে সংরক্ষণ করতে পারেন।

সাধারণ ভুল এবং ফাঁদ যা এড়ানো উচিত

অনুমোদনগুলো অটোমেট করুন

পরিমাণ, ক্যাটাগরি এবং সরবরাহকারী ঝুঁকির ভিত্তিতে রুটিং নিয়ম সেট করুন যাতে অনুমোদন পূর্বানুমানযোগ্য থাকে।

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

বড় ঝুঁকি হ'ল ফিচার না থাকা নয়—এটি ভুল নিয়ম তৈরি করা এবং কোম্পানিকে সেগুলোকে ওয়ার্কঅ্যারাউন্ড করতে শেখানো।

একটি সাধারণ ব্যর্থতা হলো অনুরোধকে স্ট্যাটাসের জঞ্জালে পরিণত করা। যদি মানুষ বুঝতে না পারে “Pending validation” বনাম “Under review” মানে কী, তারা আপডেট করা বন্ধ করে দেয় এবং আপনার ডেটা শব্দে পরিণত হয়। স্ট্যাটাসগুলোকে পরিষ্কার অ্যাকশন ও মালিকের সাথে যুক্ত রাখুন। প্রতিটি স্ট্যাটাস একটি প্রশ্নের উত্তর দেওয়া উচিত: “পরের ধাপে কী হবে এবং কে করবে?”

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

এই ভুলগুলো সবচেয়ে বেশি রিয়ার্ক তৈরি করে:

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

অনুমোদনের পর এডিটগুলো বিশেষ নজর যোগ্য কারণ ছোট “নির্দোষ” পরিবর্তনগুলো প্রায়শই ঝুঁকি বাড়ায়। কেউ যদি 10 ল্যাপটপ $900 প্রতিটি হিসেবে অনুমোদন পান, পরে একটি উচ্চ-মডেল বা পরিমাণ বাড়িয়ে দেয়, তাহলে আপনার হাতে এমন অনুমোদন থাকতে পারে যা বাস্তবে কেনা হওয়া সামগ্রীর সঙ্গে মেলে না।

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

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

দ্রুত চেকলিস্ট, উদাহরণ পরিস্থিতি, এবং পরবর্তী ধাপ

লঞ্চের আগে মৌলিক বিষয়গুলো লিখে রাখুন। বেশিরভাগ "অনুমোদন বিশৃঙ্খলা" হয় কারণ একটি ছোট নিয়ম বা অনিবার্য ক্ষেত্র অনুপস্থিত।

একটি সহজ লঞ্চ চেকলিস্ট:

ভূমিকা ও অনুমতি (requester, approver, finance, procurement, admin)
অনুমোদন নিয়ম (পরিমাণ, ডিপার্টমেন্ট, ক্যাটাগরি, লোকেশন)
স্ট্যাটাস ও মালিকানার সংজ্ঞা (Draft, Submitted, Needs info, Approved, PO created, Closed)
আবশ্যক ক্ষেত্র (ভেন্ডর, কস্ট সেন্টার, ডেলিভারি তারিখ, বিজনেস রিজন)
আবশ্যক সংযুক্তি (কোট, কনট্রাক্ট, security review, স্পেস শিট)

একবার নিয়মগুলো থাকলে, রিকোয়েস্ট সামনে বাড়ার আগে কিছু দ্রুত ভ্যালিডেশন যোগ করুন: ভেন্ডার সিলেকশন (বা একটি পরিষ্কার নতুন-ভেন্ডর পাথ), সঠিক পিরিয়ডের জন্য বাজেট কভারেজ, মূল্য প্রমাণ, সম্পূর্ণ শিপিং/বিলিং ডিটেইল, এবং বাস্তব বিজনেস রিজন।

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

পরবর্তী ধাপ: আপনার ডেটা মডেল ও ওয়ার্কফ্লো নিয়মগুলো প্রোটোটাইপ করুন, তারপর একটি ছোট পাইলট টিম ও এক বা দুইটি ক্রয় ক্যাটাগরির সঙ্গে পরীক্ষা চালান। AppMaster-এ আপনি Data Designer-এ টেবিলগুলো তৈরি করে Business Process Editor-এ রাউটিং লজিক ম্যাপ করতে পারেন। সংক্ষিপ্ত পাইলট চালান, দেখুন কোথায় অনুরোধ আটকে যায়, আবশ্যক ক্ষেত্র শক্ত করুন, এবং তারপর বৃহত্তর রোলআউট করুন। যদি আপনি দেখতে চান কিভাবে এই পদ্ধতি প্রকৃত অ্যাপ বিল্ডে অনুবাদ হয়, AppMaster (appmaster.io) পূর্ণ অভ্যন্তরীণ টুল তৈরির জন্য ডিজাইন করা হয়েছে যা অনুমোদন লজিক, API, এবং একই মডেল থেকে ওয়েব ও নেটিভ মোবাইল ইন্টারফেস উভয়ই জেনারেট করে।

প্রশ্নোত্তর

Start with request to PO. It forces clear approvals, budget checks, and traceability without dragging you into invoice matching and receiving right away. You can add downstream steps after the team trusts the first milestone.

Use a small, explicit set like Draft, Submitted, Approved, Rejected, Ordered, and Closed. Each status should clearly indicate who owns the next step and what action is expected, so nobody has to interpret vague labels.

Lock key fields at submission and require a formal change that triggers re-approval for anything that affects risk or spend, such as vendor, currency, quantity, unit price, cost center, or total. Allow only clarifications like notes, attachments, or delivery details without restarting the whole process.

Define roles first, then define what each role can do at each stage. A simple default is: requesters see and edit their own drafts, managers see direct reports, and finance/procurement have cross-department visibility, while vendor contacts never see internal notes or budget data.

Make delegation a built-in feature, not an exception. Delegation should transfer approval rights for a time window, but it should not allow the delegate to rewrite the request content, so accountability stays intact.

Separate who requested the purchase from who pays for it. Route approvals to the cost center owner even if the requester is from another team, and store both parties on the record so it’s always clear who initiated and who is accountable for budget.

Calculate expected spend the same way finance will later, including tax, shipping, discounts, and currency conversion with a stored rate and date. Decide upfront whether insufficient budget blocks the workflow or allows escalation with an extra approval step.

Keep a vendor master table as the single source of truth, and select vendors from a list rather than free text. Add a vendor status like Active, Pending review, and Blocked so risky vendors are consistently routed or prevented without relying on memory.

Generate the PO number only when the PO is officially issued, not when someone starts drafting. Assign it in a single controlled step to avoid duplicates, and keep the PO header and line items structured so totals are calculated rather than manually typed.

Yes, if you need a fast build without writing code. With AppMaster, you can model the data, define stage-based permissions and approval routing, and generate production-ready web and native mobile apps from the same model, which helps keep the workflow consistent across devices.