সীমা ও পরিষ্কার এক্সপোর্ট সহ প্রতিদিনের ভ্রমণ খরচ ট্র্যাকার

কেন per diem ট্র্যাকিং দ্রুত জটিল হয়ে যায়

Per diem হলো ভ্রমণ ব্যয়ের দৈনিক ভাতা। বেশিরভাগ কোম্পানি এটিকে খাবার এবং অনুচ্ছেদিক খরচ (যেমন টিপ বা লোকাল ট্রানজিট) জন্য ব্যবহার করে। কিছু নীতিতেই লজিং অন্তর্ভুক্ত থাকে, কিন্তু অনেক দল লজিং আলাদাভাবে ট্র্যাক করে কারণ গুলোর দাম অনেক ভেদাভেদ করে।

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

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

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

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

মূল কথা: হার, ট্রিপ, এবং কি সংরক্ষণ করা প্রয়োজন

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

ন্যূনতম হিসেবে আপনার লাগবে:

• Traveler: নাম, এমপ্লয়ি আইডি (বা কন্ট্রাক্টর), গৃহদেশ, ডিফল্ট মুদ্রা।
• Trip: ভ্রমণকারী, উদ্দেশ্য, শুরু/শেষ তারিখ, এবং কি কভার করা হচ্ছে।
• Location: শহর, দেশ, এবং টাইমজোন।
• Rate table: লোকেশন, per diem পরিমাণ, মুদ্রা, এবং কার্যকরতার তারিখের সীমা।
• Daily entry: লোকাল তারিখ, ঐ দিনের লোকেশন, পরিমাণ, পেমেন্ট টাইপ, এবং ক্যাটেগরি।

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

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

কিছু ফিল্ড পরে মাথাব্যথা কমায়: প্রতিটি রেট এবং এন্ট্রিতে মুদ্রা, ব্যবহৃত এক্সচেঞ্জ রেট (যদি আপনি রূপান্তর করেন), এবং একটি টাইমজোন যাতে “দিন ১” অশোচনীয় না হয়। যদি একজন ভ্রমণকারী লোকাল সময়ে ১১:৩০ pm নামে ল্যান্ড করে এবং ডিনারে ব্যয় করে, সেই এন্ট্রি লোকাল তারিখের অন্তর্ভুক্ত হওয়া উচিত, হোম অফিসের তারিখ নয়।

আপনার রেট মডেল নির্বাচন করা (শহর বা দেশ অনুযায়ী)

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

রেটগুলো কার্যকর তারিখসহ একটি টেবিলে সংরক্ষণ করুন যাতে পুরনো নিয়মগুলো ওভাররাইট না হয়:

• লোকেশন (দেশ কোড, সাথে ঐচ্ছিক শহর ও অঞ্চল/স্টেট)
• পরিমাণ
• মুদ্রা
• শুরু তারিখ (effective from)
• শেষ তারিখ (effective to, ঐচ্ছিক)

শহর বনাম দেশ: কিভাবে বাছাই করবেন

কর্মীরা যদি প্রায়ই কিছু ব্যয়বহুল হাব ভিজিট করে (London, New York, Zurich), শহরভিত্তিক হার ক্রমাগত এক্সসেপশন এড়ায়। যদি বেশিরভাগ ট্রিপ একটি দেশের মধ্যে হয় বা কোম্পানি পূর্বানুমানযোগ্য প্রতিপূরণ চাই, দেশহার প্রশাসনকে হালকা রাখে।

একটি ব্যবহারিক সংশ্লেষ হল “শহর থাকলে শহর, না থাকলে দেশ।” যখন কোন শহরের হার অনুপস্থিত থাকে, আপনার ট্র্যাকার ঐ তারিখের জন্য দেশহার ব্যাকআপ হিসেবে নেয়।

একটি ট্রিপে একাধিক শহর

প্রতিটি দিনের জন্য কোন লোকেশন প্রযোজ্য হবে সে সম্পর্কে এক স্পষ্ট নিয়ম লাগবে। সবচেয়ে পরিষ্কার বিকল্প হল দৈনিক লোকেশন: প্রতিটি ট্রিপের তারিখে একটি শহর/দেশ নির্ধারণ করা। আরেকটি অপশন হল সেগমেন্ট (প্রতিটি লোকেশনের জন্য শুরু ও শেষ তারিখ) যাতে সিস্টেম দিনগুলিতে প্রসারণ করে। যেকোনো পদ্ধতি কাজ করবে যদি কনসিস্টেন্ট থাকে।

বছরের মাঝখানে রেট পরিবর্তন হলে তা কার্যকর তারিখ দ্বারা পরিচালিত হয়। কেউ যদি মার্চ মাসের জন্য খরচ জমা দেয়, ট্র্যাকার মার্চেই সক্রিয় হওয়া রেট নির্বাচন করবে, যদিও নীতি জুলাইতে বদলানো হয়।

লোকেশন ফিল্ডগুলির জন্য শুরুর দিকে স্ট্যান্ডার্ডাইজ করুন: ISO country code (যেমন US), একটি নির্দিষ্ট শহরের নাম, এবং ঐচ্ছিক অঞ্চল/স্টেট (যেমন CA)। এতে "New York, USA" বনাম "NYC" ধরনের ডুপ্লিকেট এড়ানো যায়।

দৈনিক এন্ট্রি এমনভাবে ডিজাইন করুন যাতে পূরণ করা সহজ হয়

একটি দৈনিক এন্ট্রি এক মিনিটের মধ্যে হওয়া উচিত। যদি মানুষকে অতিরিক্ত নিয়ম মনে রাখতে হয় বা ফিল্ড খুঁজতে হয়, তারা অনুমান করবে, বর্জ্য করবে, বা সবকিছু এক লাইনে ঢেলে দেবে।

ফর্মটি শক্ত ও সুনির্দিষ্ট রাখুন:

• Date (সম্ভব হলে ট্রিপ থেকে অটো-ফিল)
• Location (আপনার রেট মডেল অনুযায়ী)
• Category (সাধারণত meals এবং incidentals; কখনো কখনো lodging)
• Amount (সংখ্যাগত, মুদ্রা স্পষ্টভাবে দেখান)
• Notes (সংক্ষিপ্ত, ঐচ্ছিক)

প্রমাণ রাখাও সহজ করা উচিত। অনেক টিম per diem-এর জন্য কঠোর রসিদ হ্যান্ডলিং প্রয়োজন করে না, কিন্তু যখন ফাইন্যান্স চাইবে তখন এখনও কাগজপত্র থাকা দরকার। প্রতিবারই আপলোড বাধ্য করা চেয়ে একটি “Receipt required?” ফ্ল্যাগ এবং রেফারেন্স ফিল্ড (রসিদ আইডি, ইমেইল রেফারেন্স, ফাইল নাম) প্রায়শই ভাল কাজ করে।

আংশিক দিনগুলিকে বিভ্রান্তি ছাড়া হ্যান্ডেল করা

একটি পদ্ধতি বাছাই করুন এবং সেটাই এন্ট্রি স্ক্রিনে বিল্ড করুন। সাধারণ অপশনগুলো হল শতাংশ নিয়ম (যেমন ট্রাভেল ডে-তে 75%) বা খাদ্য-ক্যাটাগরি অনুযায়ী কেটে দেওয়া (ব্রেকফাস্ট/লাঞ্চ/ডিনার সরবরাহ করা হলে)।

পছন্দটি স্পষ্ট করুন। একটি “Full day / Travel day” টগল গণনা করানোর চেয়ে সহজ। যদি আপনি কাস্টম ভ্যালু অনুমোদন করেন, সেগুলো সীমিত রাখুন (100%, 75%, 50%) যাতে এন্ট্রিগুলো কনসিস্টেন্ট থাকে।

এডিট এবং অনুমোদনের নিয়ম

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

ধাপে ধাপে: লিমিট চেক এবং ওয়ার্নিং যোগ করুন

লিমিট চেকগুলোই একটি স্প্রেডশিটকে এমন ট্র্যাকার বানায় যা মানুষ বিশ্বাস করে। লক্ষ্য শাস্তি করা নয়—এটি হলো ভ্রমণকারীর স্মৃতিতে থাকতে থাকার সময়ে অস্বাভাবিকতা ধরার কাজ।

প্রথমত, প্রতিটি দৈনিক এন্ট্রি সঠিক হার খুঁজে পাবে: শহর আছে কিনা মিলান, না থাকলে দেশের হার; যদি না থাকে, অনুমান করবেন না। দেখান rate missing যাতে কেউ হার যোগ করে বা লোকেশন সঠিক করে।

এরপর, দিনের জন্য (এবং যদি আপনার নীতি ক্যাটাগরি বিভক্ত করে তাহলে ক্যাটাগরি অনুযায়ী) কত বাকি আছে হিসাব করুন। একটি দৈনিক সারাংশ ব্যবহার করুন: ভাতা মাইনাস ইতিমধ্যে এন্ট্রি করা যা।

একটি ওয়ার্নিং ফ্লো যা বেশিরভাগ টিমে ভালো কাজ করে:

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

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

কেউ যদি ওভাররাইড করে, একটি সংক্ষিপ্ত ন্যায্যতা ধরুন। “Client dinner ran long, only option near venue” এর মত এক লাইন প্রায়শই অনেক অনুসন্ধান বাঁচায়।

এছাড়া এক্সসেপশনগুলো লাইন আইটেম নয়, বরং দিন স্তরে ফ্ল্যাগ করুন। অ্যাকাউন্টিং সাধারণত দিন টোটাল রিভিউ করে, তাই একটি তারিখে “needs review” ব্যাজ স্ক্যান করা সহজ করে।

মুদ্রা, এক্সচেঞ্জ রেট, এবং রাউন্ডিং হ্যান্ডলিং

আন্তর্জাতিক ভ্রমণ দ্রুত বিভ্রান্তিকর হয়ে যায় যদি না মুদ্রা প্রতিবার একইভাবে হ্যান্ডেল করা হয়।

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

এমন এক্সচেঞ্জ রেট বাছাই করুন যা কেউ সমর্থন করতে পারে

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

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

রাউন্ডিং এবং ছোট ওভারেজ

রাউন্ডিং হল যেখানে “লিমিট ওভার” বিতর্ক প্রায়শই শুরু হয়। একটি রূপান্তর যেমন 25.005 হয়ে রাউন্ড আপ করলে ওয়ার্নিং ট্রিগার করতে পারে।

শোরগোল কমাতে, লিমিট চেকের জন্য একটি সহনশীলতা সীমা সেট করুন, যেমন “রিপোর্টিং মুদ্রায় 0.50 এর বেশি হলে কেবল ওয়ার্নিং দিন” বা “দৈনিক ক্যাপের 1% এর বেশি হলে”। যোগ করার পরে রাউন্ডিং করুন, লাইনে নয় দিন পূর্ণ যোগফলের পরে।

কর এবং টিপ কীভাবে ধরা হবে তাও নির্ধারণ করুন। কিছু নীতিতে এগুলো per diem-এ অন্তর্ভুক্ত, অন্যগুলো আলাদা রাখে। আপনার ট্র্যাকার যদি নিয়মগুলিকে মিশিয়ে দেয়, তাহলে বিরোধ হবে। এক সহজ ফিক্স হল প্রতিটি এন্ট্রিতে একটি টগল যেমন Counts toward per diem: Yes/No যাতে বাদ দেয়া আইটেমগুলো ভুলক্রমে meals-এর ওপর চাপ না সৃষ্টি করে।

সাধারণ ভুল যা বিরোধ ও পুনরায় কাজ ঘটায়

শুধুমাত্র পরিমাণ নিয়ে প্রতিকূলতা হয় না; বেশিরভাগ প্রতিদ্বন্দ্বিতা অস্পষ্ট নিয়ম, অনুপস্থিত প্রসঙ্গ, বা যাচাই করা কঠিন একটি রিপোর্টের কারণে।

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

পুরনো রেটও ঢুকে যায় যখন আপনি কার্যকর তারিখ ট্র্যাক করেন না। যদি একটি শহরের হার ১ জুলাই পরিবর্তিত হয়, জুনের এন্ট্রিগুলো পুনরায় ক্যালকুলেট করা উচিৎ নয়। শুরু/শেষ তারিখ সংরক্ষণ করুন, এবং প্রতিটি দিনের জন্য ব্যবহৃত রেট (অথবা কার্যকরতার তারিখ) রেকর্ড করুন।

অনুমোদনের পরে এডিটগুলো অবৈশ্বিকতাও অবিশ্বাস্যতা তৈরি করে। কেউ ম্যানেজার অনুমোদনের পরে একটি দিন পরিবর্তন করতে পারলে, কি বদলেছে এবং কেন তা রেকর্ড করুন। অন্যমতো অ্যাকাউন্টিং মেলে না এমন টোটাল দেখবে এবং ইমেইল ও স্ক্রিনশট চাইবে।

এক্সপোর্টগুলো পুনরায় কাজ তৈরি করে যখন সেগুলো কাঁচা লাইনের মতো হয়। অ্যাকাউন্টিং সাধারণত গ্রুপিং এবং লেবেল চায় যা তাদের পোস্টিংয়ের সাথে মেলে।

বিরোধ কম রাখে এমন প্যাটার্নগুলো:

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

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

অ্যাকাউন্টিং-এ রিপোর্ট পাঠানোর আগে দ্রুত চেকলিস্ট

অ্যাকাউন্টিং কোনো গল্প চায় না। তারা দ্রুত মিলানো যায় এমন কিছু চায়: স্পষ্ট তারিখ, স্পষ্ট হার, এবং স্পষ্ট এক্সসেপশন।

রপ্তানি করার আগে চেক করুন:

• ট্রিপের বিবরণ সম্পূর্ণ (ভ্রমণকারী, তারিখ, উদ্দেশ্য, এবং একটি প্রাথমিক লোকেশন)।
• প্রতিটি ভ্রমণ দিনের জন্য একটি হার আছে। যদি হার অনুপস্থিত থাকে, তা স্পষ্টভাবে missing হিসেবে লেবেল করুন, শূন্য হিসেবে নয়।
• ওভার-লিমিট দিনগুলোর একটি সংক্ষিপ্ত কারণ এবং নামযুক্ত রিভিউয়ার/অনুমোদক আছে।
• দৈনিক টোটাল, ট্রিপ টোটাল এবং এক্সপোর্ট সারাংশের মধ্যে টোটালগুলো মিলে যায়।
• মুদ্রা কোডগুলো সঙ্গতিপূর্ণ (USD বনাম US$, EUR বনাম Euro)।

এরপর একটি দ্রুত স্পট চেক করুন: বড় দিনের একটি বেছে নিন, ক্যাটাগরিগুলো পুনরায় যোগ করুন, এবং নিশ্চিত করুন এটি দৈনিক মোটের সাথে মেলে।

উদাহরণ: কেউ Paris থেকে Lyon-এ মাঝপথে যায়। যদি পলিসি হয় “শহর অনুযায়ী per diem,” ট্র্যাকারটি সঠিক তারিখে রেট সোয়াপ করা উচিত। যদি না করে, টোটালগুলো সম্ভবত যুক্তিসঙ্গত দেখলেও নীতিগত ভিত্তি ভুল হবে এবং অ্যাকাউন্টিং সংশোধন চাইবে।

উদাহরণ: একাধিক শহরের ট্রিপ যেখানে একটি দিন ওভার-লিমিট

ভাবুন ৫ দিনের একটি ট্রিপ: প্রথম ৩ দিন Chicago, পরে ২ দিন New York। আপনার ট্র্যাকার শহর অনুযায়ী per diem রেট সংরক্ষণ করে প্রতিটি ক্যালেন্ডার দিনের জন্য প্রয়োগ করে, যেখানে ভ্রমণকারী সেই দিনে আছে।

এই উদাহরণের নীতি হলো দৈনিক খাবারের per diem (রসিদ প্রয়োজন নয় যদি ওভার না হয়): Chicago $75/দিন (দিন 1-3) এবং New York $95/দিন (দিন 4-5)।

দিন 4-এ New York-এ ভ্রমণকারী ব্রেকফাস্ট $18, লাঞ্চ $22, এবং ডিনার $70 লগ করেন। মোট $110, যা $95 সীমার থেকে $15 বেশি।

এটি নিঃশব্দে গড়িয়ে যাবে না। ভ্রমণকারী উচিত তাত্ক্ষণিক ওয়ার্নিং দেখা: “Over limit by $15.” ফর্মটি পরের ধাপ স্পষ্ট করা উচিত: টাইপো ঠিক করা, না হলে ওভারেজ ব্যক্তিগত হিসেবে চিহ্নিত করা/অনুমোদন প্রয়োজন ও একটি সংক্ষিপ্ত নোট যোগ করা।

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

অ্যাকাউন্টিং তারপর একটি পরিষ্কার প্যাকেট পায়: অনুমোদিত বনাম দাবিকৃত প্রতিদিন (এবং শহর অনুযায়ী টোটাল), প্লাস অডিটের জন্য লাইনে আইটেম।

ক্লিন এক্সপোর্ট — যাতে পরিষ্কার করে কোনো পরিবর্তন দরকার না হয়

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

বাস্তবে, ক্লিন এক্সপোর্টগুলো সাধারণত থাকে:

• একটি স্থিতিশীল সারি ফরম্যাট (একই কলাম, একই ক্রম)
• যাচাই করা সহজ টোটাল (দৈনিক ও ট্রিপ টোটাল)
• এক্সসেপশনগুলো স্পষ্টভাবে চিহ্নিত (ওভার-লিমিট দিনগুলো স্পষ্ট)
• প্রত্যাশিত মুদ্রা ও রাউন্ডিং নীতিসমূহ
• নোটগুলো যথার্থ এন্ট্রির সঙ্গে সংযুক্ত

প্রতিবারই থাকা থাকা দরকারি কলামগুলো: employee, trip ID, date, location, category, amount, limit, overage, এবং notes। যদিও নোট প্রায়ই ফাঁকা থাকে, কলামটি অ্যাকাউন্টিংকে ফাইল নির্ভরভাবে ইমপোর্ট করতে সাহায্য করে।

ফরম্যাট নির্ভর করে রিপোর্ট কিভাবে ব্যবহৃত হবে: CSV ইমপোর্টের জন্য, PDF ম্যানেজার রিভিউয়ের জন্য, এবং দ্রুত চেকের জন্য একটি সরল সামারি ভিউ।

একটি ছোট কিন্তু গুরুত্বপূর্ণ বিবরণ হলো প্রতিটি লাইনে সীমা এবং ওভারেজ উভয়ই দেখানো। যদি একটি ডিনার এন্ট্রি $78 এবং দৈনিক খাবারের সীমা $60 হয়, এক্সপোর্টে থাকা উচিত limit = 60, overage = 18, এবং কারণ।

এক্সপোর্টকে স্থিতিশীল রাখতে, এক্সপোর্টটিকে একটি টেমপ্লেট হিসেবে বিবেচনা করুন। ফিল্ড নাম ও কলাম অর্ডার লক করুন, এবং হেডারে একটি এক্সপোর্ট টেমপ্লেট ভার্শন (v1, v2) যোগ করুন। নীতির পরিবর্তন হলে পুরনো কলামগুলো এডিট করার বদলে একটি নতুন ভার্শন তৈরি করুন।

পরবর্তি ধাপ: ট্র্যাকারটিকে একটি সহজ অভ্যন্তরীণ অ্যাপে রূপান্তর করুন

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

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

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

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