စာရင်းမှားရင် Delete နှိပ်လိုက်ရုံနဲ့ ပြီးပြီလား?

“ဒီအော်ဒါမှားနေတယ်။ Delete လုပ်ပေးပါ။”

စာရင်းတစ်ခုမှားသွားတိုင်း Delete ခလုတ်ကို သတိရတာ သဘာဝကျပါတယ်။ ဒါပေမယ့် အော်ဒါကို အတည်ပြုပြီး Stock လျှော့ထားတာ၊ ငွေလက်ခံထားတာ၊ Invoice ထုတ်ထားတာတွေ ရှိနေပြီဆိုရင် မူလစာရင်းတစ်ကြောင်း ပျောက်သွားရုံနဲ့ အလုပ်မပြီးပါဘူး။

Draft ကိုဖျက်ခြင်း၊ အတည်ပြုပြီး Transaction ကို Cancel လုပ်ခြင်းနဲ့ ဖြစ်ပြီးသားသက်ရောက်မှုကို Reversal လုပ်ခြင်းတို့ဟာ အဓိပ္ပာယ်မတူပါဘူး။

နမူနာ — ပစ္စည်း ၅ ခု ရောင်းပြီးမှ အော်ဒါမှားကြောင်း သိရခြင်း

ပစ္စည်း ၅ ခုပါတဲ့ အော်ဒါတစ်ခုကို ဝန်ထမ်းက အတည်ပြုလိုက်တယ်ဆိုပါစို့။ စနစ်က—

အော်ဒါနံပါတ် ထုတ်ပေးတယ်။
Stock ၅ ခု လျှော့တယ်။
ဖောက်သည်ပေးချေမှုကို မှတ်တမ်းတင်တယ်။
Invoice ထုတ်ပေးတယ်။
နေ့စဉ်အရောင်း Report ထဲ ထည့်တယ်။

နောက်မှ အခြားဖောက်သည်အမည်နဲ့ မှားတင်ထားကြောင်း သိလာတယ်။ ဒီအချိန်မှာ Order row ကို တိုက်ရိုက် Delete လုပ်လိုက်ရင် Stock၊ Payment၊ Invoice နဲ့ Report တို့မှာ ဘာဖြစ်မလဲဆိုတာ မရှင်းတော့ပါဘူး။

Order ပျောက်သွားပေမယ့် Payment ကျန်နိုင်တယ်။ Stock မပြန်တိုးနိုင်ဘူး။ Invoice နံပါတ်အစဉ်မှာ အကြောင်းပြချက်မရှိတဲ့ ကွက်လပ် ဖြစ်နိုင်တယ်။ Report အဟောင်းနဲ့ အသစ် မကိုက်တော့တာလည်း ဖြစ်နိုင်ပါတယ်။

Delete၊ Cancel နဲ့ Reversal ကို ခွဲကြည့်မယ်

လုပ်ဆောင်ချက်	သင့်တော်နိုင်တဲ့အခြေအနေ	စနစ်မှာ မျှော်လင့်သင့်တာ
Delete	မအတည်ပြုရသေးတဲ့ Draft၊ မလိုအပ်တော့တဲ့ ယာယီစာရင်း	အခြား Transaction ကို မထိခိုက်ဘဲ ဖယ်ရှားနိုင်ခြင်း
Cancel / Void	အတည်ပြုပြီးပေမယ့် ဆက်မလုပ်တော့တဲ့ အော်ဒါ သို့မဟုတ် စာရွက်စာတမ်း	မူလစာရင်းကို မဖျောက်ဘဲ Status၊ အကြောင်းရင်း၊ လုပ်ဆောင်သူနဲ့အချိန်ကို မှတ်ထားခြင်း
Reversal	Stock၊ ငွေစာရင်း သို့မဟုတ် အခြားသက်ရောက်မှု ဖြစ်ပြီးသား	မူလ Transaction နဲ့ ချိတ်ထားတဲ့ ဆန့်ကျင်ဘက် Transaction အသစ်တစ်ခုနဲ့ ပြန်ညှိခြင်း
Correction	ခွင့်ပြုထားတဲ့အချက်တချို့ကို မှန်ကန်အောင်ပြင်ခြင်း	မူလတန်ဖိုး၊ ပြင်ပြီးတန်ဖိုးနဲ့ အကြောင်းရင်းကို ပြန်လိုက်နိုင်ခြင်း

ဒီဇယားက စနစ်တိုင်းအတွက် မပြောင်းလဲတဲ့ဥပဒေ မဟုတ်ပါဘူး။ လုပ်ငန်းစည်းမျဉ်း၊ စာရင်းကိုင်လိုအပ်ချက်နဲ့ သက်ဆိုင်ရာသတ်မှတ်ချက်တွေအရ အသေးစိတ်ကွာနိုင်ပါတယ်။ အရေးကြီးတာက ခလုတ်အမည်တစ်ခုချင်းရဲ့ အဓိပ္ပာယ်ကို ရှင်းထားဖို့ပါ။

Cancel လုပ်လိုက်ရင် Stock အလိုအလျောက်ပြန်တိုးရမလား?

အမြဲတမ်း မဟုတ်ပါဘူး။

အော်ဒါအတည်ပြုထားပေမယ့် ပစ္စည်းမထုတ်ရသေးရင် ချန်ထားတဲ့ Stock ကို ပြန်လွှတ်ပေးတာ လုံလောက်နိုင်ပါတယ်။ ပစ္စည်းကို ဂိုဒေါင်က ထုတ်ပြီးသားဆိုရင် ပစ္စည်းပြန်လက်ခံတဲ့လုပ်ငန်းစဉ် လိုလာပါတယ်။ ဖောက်သည်ထံရောက်ပြီးသားဆိုရင် Return စစ်ဆေးမှု၊ ပျက်စီးမှုနဲ့ ပြန်ရောင်းနိုင်မှုတို့ပါ ထည့်စဉ်းစားရနိုင်ပါတယ်။

ဒါကြောင့် Order Cancel ဖြစ်တာနဲ့ Stock ပြန်ဝင်တာဟာ Event တစ်ခုတည်း မဟုတ်နိုင်ပါဘူး။

လက်ရှိအခြေအနေ	ဆက်လုပ်ရနိုင်တဲ့အလုပ်
ပစ္စည်းမထုတ်ရသေး	Reserved Stock ကို ပြန်လွှတ်
ဂိုဒေါင်က ထုတ်ပြီး	ပစ္စည်းပြန်လက်ခံပြီးမှ Stock ကို ညှိ
ဖောက်သည်ဆီ ရောက်ပြီး	Return လက်ခံမှုနဲ့ ပစ္စည်းအခြေအနေ စစ်
ပစ္စည်းပျက်စီး/ပျောက်ဆုံး	ရိုးရိုး Available Stock ထဲ မပြန်ထည့်ဘဲ သီးခြားအခြေအနေထား

ခလုတ်တစ်ချက်နှိပ်တာနဲ့ အားလုံးကို တိတ်တိတ်ပြောင်းပေးမယ့်အစား ဘယ်အလုပ်ပြီးပြီ၊ ဘယ်အလုပ်ကျန်သေးတယ်ဆိုတာ မြင်နိုင်တာ ပိုအသုံးဝင်ပါတယ်။

ငွေလက်ခံပြီးသားဆိုရင် ဘာဖြစ်မလဲ?

Order ကို Cancel လုပ်ခြင်းနဲ့ ဖောက်သည်ဆီ ငွေတကယ်ပြန်ပေးပြီးခြင်းကလည်း မတူပါဘူး။

Refund လုပ်ရမယ်ဆိုရင်—

မူလ Payment က ဘာလဲ။
ဘယ်လောက်ပြန်အပ်မလဲ။
ဘယ်နည်းလမ်းနဲ့ ပြန်အပ်မလဲ။
ဘယ်သူအတည်ပြုခဲ့သလဲ။
ပြန်အပ်မှု အောင်မြင်ပြီးပြီလား၊ လုပ်ဆောင်ဆဲလား။
အပြည့်ပြန်အပ်တာလား၊ တစ်စိတ်တစ်ပိုင်းလား။

ဆိုတာတွေကို မူလ Transaction နဲ့ ချိတ်ထားဖို့ လိုပါတယ်။

Order မှာ “Cancelled” လို့ ပြပေမယ့် Refund က “Pending” ဖြစ်နေနိုင်ပါတယ်။ ဒီနှစ်ခုကို တစ်ခုတည်းလို ပြလိုက်ရင် ဖောက်သည်က ငွေမရသေးပေမယ့် ဝန်ထမ်းက အလုပ်ပြီးသွားပြီလို့ ထင်နိုင်ပါတယ်။

Status ပြောင်းရုံနဲ့ လုံလောက်သလား?

Status တစ်ခုတည်းထက် အောက်ကအချက်တွေပါ လိုလာနိုင်ပါတယ်။

ပယ်ဖျက်ရတဲ့ Reason
ပယ်ဖျက်ရန် တောင်းဆိုသူ
အတည်ပြုသူ
ပယ်ဖျက်ခဲ့တဲ့အချိန်
မူလစာရင်းနဲ့ Reversal/Refund စာရင်းရဲ့ ချိတ်ဆက်မှု
Stock၊ Payment၊ Delivery စတဲ့ နောက်ဆက်တွဲအလုပ်တွေရဲ့ လက်ရှိအခြေအနေ
စနစ်က အလိုအလျောက်လုပ်တာနဲ့ ဝန်ထမ်းက လုပ်တာကို ခွဲပြနိုင်မှု

အကြောင်းရင်းကို စာသားအလွတ်နဲ့သာ ရေးခိုင်းရင် Report ထုတ်ရခက်နိုင်ပါတယ်။ အသုံးများတဲ့ Reason များကို ရွေးချယ်စရာအဖြစ်ထားပြီး လိုအပ်ရင် Note ထပ်ရေးနိုင်အောင် လုပ်ထားနိုင်ပါတယ်။

ဘယ်သူမဆို Cancel လုပ်နိုင်သလား?

အော်ဒါတန်ဖိုး၊ လက်ရှိအဆင့်နဲ့ သက်ရောက်မှုအပေါ်မူတည်ပြီး Permission နဲ့ Approval ကွာနိုင်ပါတယ်။

ဥပမာ—

Draft ကို ဖန်တီးသူကိုယ်တိုင် ဖျက်နိုင်တယ်။
မအပ်ရသေးတဲ့ အော်ဒါကို Supervisor က Cancel လုပ်နိုင်တယ်။
ငွေလက်ခံပြီးသား အော်ဒါအတွက် Refund Approval လိုတယ်။
စာရင်းကာလပိတ်ပြီးသား Transaction ကို သာမန်ဝန်ထမ်းက နောက်ကြောင်းပြန်မပြင်နိုင်ဘူး။

Front-end မှာ ခလုတ်ဖျောက်ထားရုံနဲ့ မလုံလောက်ပါဘူး။ API ဘက်မှာလည်း တူညီတဲ့ Permission နဲ့ Business Rule ကို စစ်ရပါမယ်။

တစ်ပြိုင်တည်းလုပ်မိရင် ဘာဖြစ်မလဲ?

ဝန်ထမ်းနှစ်ယောက်က အော်ဒါတစ်ခုကို တစ်ချိန်တည်း Cancel လုပ်တယ်ဆိုပါစို့။ Stock နှစ်ကြိမ်ပြန်တိုးတာ၊ Refund နှစ်ကြိမ်လုပ်တာ မဖြစ်သင့်ပါဘူး။

စနစ်က—

လက်ရှိ Status ကို အရင်စစ်ခြင်း
တစ်ကြိမ်သာ အောင်မြင်ရမယ့် Operation ကို ထပ်လုပ်မိခြင်းမှ ကာကွယ်ခြင်း
ဆက်စပ် Transaction များကို တစ်စုတစ်စည်းတည်း မှန်ကန်စွာ သိမ်းခြင်း
မအောင်မြင်တဲ့အခါ တစ်ဝက်တစ်ပျက်အခြေအနေကို ပြန်စစ်နိုင်ခြင်း

တို့ကို ကိုင်တွယ်ထားဖို့ လိုပါတယ်။

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

သီးခြားစမ်းသပ်နေရာနဲ့ နမူနာဒေတာကို သုံးပြီး—

Draft တစ်ခုကို ဖျက်တဲ့အခါ Stock နဲ့ Payment မထိခိုက်ဘူးလား။
အတည်ပြုပြီး Order ကို Cancel လုပ်တဲ့အခါ မူလစာရင်းကို ပြန်ကြည့်နိုင်သလား။
ပစ္စည်းမထုတ်ရသေးတာနဲ့ ထုတ်ပြီးသားကို တူညီစွာ မကိုင်တွယ်ဘူးလား။
Payment ရှိတဲ့အခါ Refund အခြေအနေကို သီးခြားမြင်နိုင်သလား။
Cancel ကို နှစ်ကြိမ်နှိပ်ရင် Stock သို့မဟုတ် ငွေ နှစ်ကြိမ်မပြောင်းဘူးလား။
Permission မရှိသူက UI၊ API နဲ့ Import လမ်းကြောင်းတွေကနေ မလုပ်နိုင်ဘူးလား။
Detail၊ Print၊ Export နဲ့ Report တို့မှာ Cancelled စာရင်းရဲ့ အဓိပ္ပာယ် တူညီသလား။
အကြောင်းရင်း၊ လုပ်ဆောင်သူနဲ့ အချိန်ကို နောက်မှ ပြန်လိုက်နိုင်သလား။

ဒီနေ့လုပ်ကြည့်ရန် — လက်ရှိစနစ်ထဲက အရေးကြီးတဲ့ “Delete” ခလုတ်တစ်ခုကို ရွေးပါ။ အဲဒီစာရင်းမှာ ငွေ၊ Stock၊ Invoice၊ Delivery သို့မဟုတ် Report သက်ရောက်မှုရှိပြီးသားဆိုရင် Delete အစား Cancel သို့မဟုတ် Reversal လိုသလား စစ်ကြည့်ပါ။

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

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