Dashboard က ၁၀၀၊ Export က ၉၇ — ဘယ်ဟာမှန်လဲ?

“ဒီနေ့ Order ၁၀၀ ရှိတယ်လို့ Dashboard မှာ ပြတယ်။ Export ချတော့ ၉၇ ခုပဲ ပါတယ်။ ဘယ်ဟာမှန်တာလဲ?”

လုပ်ငန်းသုံး Software မှာ အများကြီးကြားရနိုင်တဲ့မေးခွန်းတစ်ခုပါ။ Dashboard၊ Listing၊ Export နဲ့ Accounting Report တို့မှာ စုစုပေါင်းမတူရင် လူတွေက စနစ်ကို မယုံတော့တာ မြန်ပါတယ်။

ဒါပေမယ့် အရေအတွက်မတူတိုင်း Query တစ်ခု ပျက်နေတာလို့ပဲ မယူဆသင့်ပါဘူး။ အရာတစ်ခုတည်းကို တူညီတဲ့အချိန်၊ Status၊ Data scope နဲ့ တွက်နေကြသလား အရင်စစ်ဖို့လိုပါတယ်။

နမူနာ — “ဒီနေ့ Order” ဆိုတာ ဘာကိုဆိုလိုသလဲ?

ဆိုင်ခွဲများရှိတဲ့ လုပ်ငန်းတစ်ခုမှာ Dashboard က ဒီနေ့ Order ၁၀၀ လို့ ပြတယ်။ CSV Export မှာ ၉၇ ခု ပါတယ်ဆိုပါစို့။

စစ်ကြည့်တဲ့အခါ—

• Dashboard က ယနေ့ ဖန်တီးခဲ့တဲ့ Order အားလုံးကို ရေတွက်ထားတယ်။
• Export က Confirmed နဲ့ Completed ကိုပဲ ထည့်ထားတယ်။
• Pending Order ၂ ခုနဲ့ Cancelled Order ၁ ခု မပါဘူး။

ဒါဆို နှစ်ခုစလုံးက ကိုယ့်သတ်မှတ်ချက်အတွင်းမှာ မှန်နေနိုင်ပါတယ်။ ပြဿနာက “Order ၁၀၀” ဆိုတဲ့အမည်တစ်ခုတည်းအောက်မှာ သတ်မှတ်ချက်မတူတဲ့အရေအတွက်ကို ပြထားတာပါ။

စုစုပေါင်းမကိုက်စေတဲ့ အချက်များ

စစ်ရမယ့်အချက်	Dashboard နမူနာ	Export နမူနာ
Time range	ဒီနေ့ 00:00 မှ လက်ရှိအချိန်	နောက်ဆုံး ၂၄ နာရီ
Date field	Created date	Confirmed date
Status	Status အားလုံး	Confirmed/Completed သာ
Data scope	ဆိုင်ခွဲအားလုံး	မိမိဆိုင်ခွဲသာ
Refund/Cancel	မူလအရောင်းကို ဆက်ရေတွက်	Cancelled ကို ဖယ်ထား
Update timing	၅ မိနစ် Cache	လက်ရှိ Database
Counting unit	Order အရေအတွက်	Order item အရေအတွက်
Access rule	Manager scope	Export လုပ်သူရဲ့ scope

ဒီအချက်တစ်ခုခု မတူရင် စုစုပေါင်းတူဖို့ မမျှော်လင့်သင့်ပါဘူး။

Date တစ်ခုတည်းတောင် အဓိပ္ပာယ်အမျိုးမျိုးရှိတယ်

Order တစ်ခုမှာ Date မျိုးစုံရှိနိုင်ပါတယ်။

• ဖန်တီးခဲ့တဲ့အချိန်
• Confirm လုပ်ခဲ့တဲ့အချိန်
• ငွေလက်ခံခဲ့တဲ့အချိန်
• ပစ္စည်းပို့ခဲ့တဲ့အချိန်
• Completed ဖြစ်ခဲ့တဲ့အချိန်
• Cancel သို့မဟုတ် Refund လုပ်ခဲ့တဲ့အချိန်

“ဒီနေ့အရောင်း” ကို Order ဖန်တီးချိန်နဲ့ တွက်မလား၊ ငွေလက်ခံချိန်နဲ့ တွက်မလားဆိုတာ လုပ်ငန်းရဲ့မေးခွန်းပေါ် မူတည်ပါတယ်။

ည ၁၁:၅၅ မှာ Order ဖန်တီးပြီး နောက်နေ့ မနက် ၉ နာရီမှာ ငွေလက်ခံတယ်ဆိုပါစို့။ Order count အတွက် ပထမနေ့မှာ ပါနိုင်ပေမယ့် Cash received report မှာ ဒုတိယနေ့မှ ပါသင့်နိုင်ပါတယ်။

Report တစ်ခုရဲ့ Date filter က ဘယ် Date field ကို သုံးထားသလဲ မပြထားရင် “ဒီနေ့” ဆိုတာ မရှင်းပါဘူး။

Time zone နဲ့ Cut-off time

ဆိုင်ဖွင့်ချိန်က မနက် ၆ နာရီကနေ နောက်နေ့ မနက် ၂ နာရီအထိ ဖြစ်နိုင်ပါတယ်။ Calendar date ပြောင်းသွားပေမယ့် လုပ်ငန်းနေ့က မပြီးသေးနိုင်ပါဘူး။

အခြားတစ်ဖက်မှာ Server က UTC နဲ့ သိမ်းထားပြီး Report ကို Asia/Yangon နဲ့ ပြရနိုင်ပါတယ်။ Date range ကို ပြောင်းတဲ့အခါ Time zone မတူရင် နေ့အစနဲ့ နေ့အဆုံးမှာရှိတဲ့ Transaction တွေ ရက်မှားဝင်နိုင်ပါတယ်။

ဒါကြောင့် Report မှာ—

• သုံးထားတဲ့ Time zone
• From/To အချိန်
• End time ကို ထည့်တွက်သလား
• လုပ်ငန်းနေ့ Cut-off ရှိသလား

ဆိုတာ ရှင်းအောင် ပြထားသင့်ပါတယ်။

Order count နဲ့ Item count မရောပါနဲ့

Order ၁ စောင်မှာ ပစ္စည်း ၃ မျိုး ပါတယ်ဆိုပါစို့။

Database ကို Order နဲ့ Order Items ချိတ်ပြီး Listing ထုတ်တဲ့အခါ row ၃ ကြောင်း ဖြစ်လာနိုင်ပါတယ်။ Order ID ကို မခွဲဘဲ row အားလုံးရေတွက်ရင် Order တစ်စောင်ကို ၃ စောင်လို မှားရေတွက်နိုင်ပါတယ်။

ဆန့်ကျင်ဘက်အနေနဲ့ Export က Item အဆင့်လိုတာဖြစ်လို့ row ၃ ကြောင်းထွက်တာ မှန်နိုင်ပါတယ်။

Report ခေါင်းစဉ်မှာ—

• Orders
• Order lines
• Units sold
• Unique customers

တို့ကို တိတိကျကျ ခွဲရေးသင့်ပါတယ်။ “Total” တစ်လုံးတည်းနဲ့ မလုံလောက်ပါဘူး။

Amount တွေ ဘာကြောင့်မကိုက်တာလဲ?

အရေအတွက်တူပေမယ့် ငွေပမာဏမတူတာလည်း ရှိပါတယ်။ စစ်ရမယ့်အချက်တွေက—

• Discount ကို မထည့်ခင်လား၊ ထည့်ပြီးလား။
• Tax နဲ့ Service charge ပါသလား။
• Delivery fee ကို အရောင်းဝင်ငွေထဲ ထည့်ထားသလား။
• Cancelled Order ကို ဖယ်ထားသလား။
• Full refund နဲ့ Partial refund ကို ဘယ်လိုနုတ်ထားသလဲ။
• Pending Payment ကို ရောင်းအားထဲ ထည့်ထားသလား။
• တစ်ကြောင်းချင်း Round လုပ်တာလား၊ နောက်ဆုံးစုစုပေါင်းမှ Round လုပ်တာလား။

Gross sales၊ Net sales၊ Amount collected နဲ့ Outstanding amount တွေဟာ တန်ဖိုးတူဖို့ မလိုပါဘူး။ အမည်နဲ့ Formula ကို သိနိုင်ဖို့လိုပါတယ်။

ဥပမာ—

Net sales = Confirmed sales − Discounts − Approved returns

ဆိုတဲ့သတ်မှတ်ချက်ကို သုံးထားရင် Report နေရာတိုင်းမှာ တူညီတဲ့ Formula သို့မဟုတ် တူညီတဲ့ Business Rule ကို သုံးရပါမယ်။ လုပ်ငန်းရဲ့အဓိပ္ပာယ်အပေါ် မူတည်လို့ Formula ကို အဖွဲ့နဲ့ အရင်သဘောတူထားသင့်ပါတယ်။

Permission ကြောင့်လည်း မတူနိုင်တယ်

Head Office Manager က ဆိုင်ခွဲအားလုံးရဲ့ Dashboard ကို မြင်နိုင်တယ်။ ဒါပေမယ့် Export endpoint က မိမိတာဝန်ယူထားတဲ့ ဆိုင်ခွဲတစ်ခုတည်းကိုသာ ထုတ်ပေးနေတယ်ဆိုပါစို့။

ဒီအခြေအနေမှာ Report မှားတာထက် Data scope မတူတာ ဖြစ်နိုင်ပါတယ်။ သို့သော် အသုံးပြုသူက ဘယ် scope ကို ကြည့်နေတာလဲ မသိရင် စနစ်မှားတယ်လို့ ထင်မှာပါ။

Report ခေါင်းစဉ်အနီးမှာ—

• All branches
• Nay Pyi Taw Branch
• Assigned locations
• My team

လိုမျိုး လက်ရှိ Data scope ကို မြင်နိုင်အောင် ပြပေးပါ။ Export ဖိုင်ထဲမှာလည်း Filter နဲ့ Scope အချက်အလက်ကို ထည့်ပေးနိုင်ပါတယ်။

Cache က အမြန်ဖြစ်စေပေမယ့် အချိန်ကို ပြရမယ်

Dashboard အမြန်ပွင့်ဖို့ စုစုပေါင်းတန်ဖိုးကို ခဏသိမ်းထားတဲ့ Cache သုံးနိုင်ပါတယ်။ Listing နဲ့ Export ကတော့ လက်ရှိ Database ကို တိုက်ရိုက်ဖတ်နေနိုင်ပါတယ်။

ဒီလိုဆို အချိန်တိုအတွင်း ကွာဟမှုရှိတာ မမှားပါဘူး။ ဒါပေမယ့် Dashboard မှာ “Updated at 08:25” လို့ ပြထားရင် အသုံးပြုသူက ကွာခြားမှုကို နားလည်နိုင်ပါတယ်။ Refresh လုပ်နိုင်မယ့်နည်းနဲ့ Cache ဘယ်လောက်ကြာသလဲဆိုတာလည်း လုပ်ငန်းလိုအပ်ချက်အရ သတ်မှတ်ပါ။

နေ့ပိတ်စာရင်းလို အရေးကြီးတဲ့ Report ကို ခဏနောက်ကျနိုင်တဲ့ Dashboard number နဲ့ တိုက်ရိုက်မပိတ်သင့်ပါဘူး။ သတ်မှတ်ထားတဲ့ Reconciliation report သို့မဟုတ် အတည်ပြုထားတဲ့ Data source ကို သုံးသင့်ပါတယ်။

“Single Source of Truth” ဆိုတာ Table တစ်ခုတည်း မဟုတ်ပါဘူး

တခါတရံ “Table တစ်ခုတည်းကပဲ ဖတ်ရင် အကုန်တူမယ်” လို့ ထင်ကြပါတယ်။ ဒါပေမယ့် အဓိကလိုတာက Table တစ်ခုတည်းထက် Metric definition တစ်ခုတည်း ဖြစ်ပါတယ်။

ဥပမာ “Completed Orders Today” ဆိုတဲ့ Metric မှာ—

1. ဘယ် Status တွေ ပါမလဲ။
2. ဘယ် Date field ကို သုံးမလဲ။
3. ဘယ် Time zone နဲ့ Cut-off သုံးမလဲ။
4. Cancel နဲ့ Return ကို ဘယ်လိုကိုင်တွယ်မလဲ။
5. ဘယ် Location scope အတွက်လဲ။
6. Order count လား၊ item count လား။

ဆိုတာတွေ သတ်မှတ်ထားရပါမယ်။

Dashboard၊ API၊ Export နဲ့ Scheduled report တို့က ဒီသတ်မှတ်ချက်တူညီအောင် ရေးထားမှ ရလဒ်ကို တိုက်စစ်နိုင်ပါတယ်။

မကိုက်တဲ့အခါ Trace လိုက်နည်း

“မကိုက်ဘူး” လို့ စုစုပေါင်းနှစ်ခုကိုပဲ ကြည့်မနေဘဲ ကွာနေတဲ့ Record ကို ရှာပါ။

1. Dashboard နဲ့ Export နှစ်ခုစလုံးရဲ့ Time range၊ Time zone နဲ့ Scope ကို မှတ်ပါ။
2. Status နဲ့ အခြား Filter တွေကို တူအောင်ထားပါ။
3. Order ID လို Stable identifier နဲ့ နှစ်ဖက်စာရင်းကို နှိုင်းယှဉ်ပါ။
4. Dashboard မှာရှိပြီး Export မှာမရှိတဲ့ ID တွေကို ခွဲထုတ်ပါ။
5. အဲဒီ Record တွေရဲ့ Status နဲ့ Date history ကို စစ်ပါ။
6. Join ကြောင့် ID တစ်ခု အကြိမ်များစွာ ပါနေတာ ရှိ/မရှိ စစ်ပါ။
7. Cache နဲ့ Report ထုတ်ချိန်ကို တိုက်စစ်ပါ။

ကွာနေတဲ့ ၃ ခုကို ရှာတွေ့ရင် “၁၀၀ နဲ့ ၉၇ ဘာကြောင့်ကွာသလဲ” ဆိုတာ သက်သေနဲ့ရှင်းနိုင်ပါတယ်။

လက်ခံစမ်းသပ်ချိန်မှာ စစ်သင့်တဲ့အခြေအနေများ

သီးခြားစမ်းသပ်နေရာမှာ နမူနာဒေတာနဲ့—

1. ရက်မပြောင်းခင်နဲ့ ပြောင်းပြီး Transaction နှစ်ခု ဖန်တီးပါ။
2. Pending၊ Confirmed၊ Completed နဲ့ Cancelled တစ်ခုစီ ထားပါ။
3. Item အများအပြားပါတဲ့ Order တစ်စောင် ထည့်ပါ။
4. Partial refund တစ်ခု လုပ်ပါ။
5. ဆိုင်ခွဲနှစ်ခုနဲ့ မတူတဲ့ User scope နှစ်ခု သုံးပါ။
6. Dashboard၊ Listing၊ Export နဲ့ Print report တို့ကို တူညီတဲ့ Filter နဲ့ နှိုင်းယှဉ်ပါ။
7. စုစုပေါင်းမတူရင် ကွာနေတဲ့ Record ID နဲ့ အကြောင်းရင်းကို ပြန်ရှာနိုင်သလား စစ်ပါ။

ဒီနေ့လုပ်ကြည့်ရန် — လက်ရှိ Dashboard ထဲက ကိန်းဂဏန်းတစ်ခုကို ရွေးပြီး “ဒီအရေအတွက်မှာ ဘယ် Status၊ ဘယ် Date field၊ ဘယ် Location scope ပါသလဲ” လို့ မေးကြည့်ပါ။ Export ချပြီး Record ID အဆင့်အထိ တိုက်စစ်ကြည့်ပါ။

မိမိလုပ်ငန်းနဲ့ ချိတ်ဆက်ဆွေးနွေးရန်

လက်ရှိ POS၊ အော်ဒါ၊ Asset သို့မဟုတ် Booking စနစ်မှာ Dashboard၊ Listing နဲ့ Export စုစုပေါင်းတွေ မကိုက်လို့ Report ကို ယုံကြည်ရခက်နေပါက Report reconciliation အကြောင်း ဆက်သွယ်မေးမြန်းရန် ကနေ လုပ်ငန်းအမျိုးအစားနဲ့ မကိုက်တဲ့ Report အမည်ကို ပြောပြနိုင်ပါတယ်။ ဆွေးနွေးမှုစဖို့ တကယ့်ဖောက်သည်ဒေတာ၊ စကားဝှက်နဲ့ အရေးကြီးစာရင်းအပြည့်အစုံ ပေးပို့ဖို့ မလိုပါဘူး။