तीन-तरफ़ा मैच स्वचालन: AP होल्ड के लिए तालिकाएँ और वर्कफ़्लो

तीन-तरफ़ा मैच वास्तव में किस समस्या को हल करता है

तीन-तरफ़ा मैच स्वचालन सादा है: आप तब ही एक इनवॉइस का भुगतान करते हैं जब वह वही दिखता है जो आपने ऑर्डर किया था और जो वास्तविक में प्राप्त हुआ। तीन दस्तावेज़ हैं: खरीद आदेश (PO), प्राप्ति रिकॉर्ड (receipt), और सप्लायर इनवॉइस।

इस जाँच के बिना, अकाउंट्स पेयेबल एक ही दस्तावेज़ के आधार पर भुगतान कर सकता है जो गलत या अधूरा हो। कोई सप्लायर जितनी यूनिट्स भेजी उससे अधिक बिल कर सकता है, सहमति की गई कीमत से अलग कीमत लगा सकता है, या एक डुप्लिकेट इनवॉइस भेज सकता है जो ईमेल थ्रेड में नया दिखता है।

ये गलतियाँ पहले दिन पर शानदार नहीं लगतीं। वे छोटे रिसाव के रूप में दिखती हैं: एक लाइन आइटम दो बार बिल हुआ, एक शिपमेंट कुछ यूनिट कम था, कीमत बिना मंज़ूरी बढ़ा दी गई, या फ्रीट जोड़ा गया जब नहीं होना चाहिए था। समय के साथ वे छोटे-छोटे दोष असली नुकसान में बदल जाते हैं।

मुद्दा इनवॉइस “मंज़ूर” करने का नहीं है। मुद्दा यह है कि आप भुगतान को तब तक रोकें जब तक चुते हुए मुख्य फ़ील्ड (आम तौर पर मात्रा, यूनिट प्राइस, और टोटल्स) PO, रिसीट और इनवॉइस में मेल न खा लें। जब वे मेल नहीं खाते, तब इनवॉइस ईमेल में खो नहीं जाना चाहिए। उसे एक अपवाद क्यू में जाना चाहिए एक स्पष्ट कारण कोड और सही भिन्न फ़ील्ड के साथ।

तीन-तरफ़ा मैच टीमों के बीच एक स्पष्ट सीमा भी खींचता है। Procurement वही नियंत्रित करता है जो ऑर्डर किया गया (शर्तें और मूल्य)। Receiving पुष्टि करता है कि क्या आया (मात्राएँ और तारीखें)। Finance नियंत्रित करता है कि क्या भुगतान किया जाए (इनवॉइस समीक्षा और रिलीज)।

शुरू में अपेक्षाएँ सेट करें: यह एक प्रक्रिया और डेटा की समस्या है, न कि केवल एक अप्रूवल बटन। अगर PO लाइनें अस्पष्ट हैं, रिसीट रिकॉर्ड नहीं होते, या इनवॉइस किसी PO लाइन से जुड़ नहीं पाते, तो स्वचालन आपको नहीं बचा पाएगा।

दस्तावेज़ और भूमिकाएँ: PO, रिसीट, इनवॉइस, और किसका क्या मालिक है

तीन-तरफ़ा मैच तभी काम करता है जब प्रत्येक दस्तावेज़ का स्पष्ट मालिक हो। अगर "कौन क्या अपडेट करता है" अस्पष्ट है, सिस्टम या तो सही भुगतान ब्लॉक कर देगा या गलत भुगतान निकल जाने देगा।

एक व्यावहारिक मालिकाना मॉडल यह है:

• अनुरोधकर्ता (Requester) खरीद अनुरोध बनाता है और आवश्यकता की पुष्टि करता है।
• Procurement PO बनाता और बनाये रखता है (सप्लायर, मूल्य, शर्तें)।
• वेयरहाउस/रिसीवर (या सर्विस मालिक) रिसीट या स्वीकृति पोस्ट करता है।
• AP/Finance इनवॉइस रिकॉर्ड करता है और भुगतान को नियंत्रित करता है।

प्रत्येक दस्तावेज़ में कम-से-कम फ़ील्ड होने चाहिए ताकि मैचिंग अनुमान न बने।

PO (purchase order) को supplier ID, PO नंबर, लाइन आइटम (SKU या सर्विस), ऑर्डर की गई मात्रा, यूनिट प्राइस, मुद्रा, कर नियम और भुगतान शर्तें चाहिए।

Receipt को PO संदर्भ, रिसीट तारीख, PO लाइन के अनुसार प्राप्त मात्राएँ, और किसने प्राप्त किया यह चाहिए। सेवाओं के लिए, इसे स्वीकृति मानें और अनुमोदक रिकॉर्ड करें।

Invoice को सप्लायर इनवॉइस नंबर, इनवॉइस तारीख, PO संदर्भ (या PO खोजने का सुरक्षित तरीका), लाइन डिटेल्स (qty, unit price), टैक्स/शिपिंग, और टोटल चाहिए।

यह भी तय करें कि मैच कब चलता है। यह एक बार की घटना नहीं होनी चाहिए। इसे तब ट्रिगर करें जब भी वास्तविकता बदलती हो:

1. जब इनवॉइस पकड़ी जाती है (ताकि आप तुरंत भुगतान बनाम होल्ड तय कर सकें)।
2. जब रिसीट पोस्ट होता है (ताकि होल्ड पर पड़ा इनवॉइस भुगतान योग्य बन सके)।
3. जब PO बदला जाता है (ताकि खुले इनवॉइस फिर से जाँचे जा सकें)।

आंशिक रिसीट और कई इनवॉइस सामान्य हैं। एक PO लाइन तीन शिपमेंट में आ सकती है और दो इनवॉइस में बिल हो सकती है। आपकी लॉजिक को प्रति PO लाइन समेकित प्राप्त बनाम समेकित इनवॉइस की तुलना करनी चाहिए, न कि केवल एक दस्तावेज़ के साथ।

निर्णय लेने योग्य नियम जो आप बनाते समय तय करें

तालिकाएँ या वर्कफ़्लो स्टेप्स छूने से पहले, उन नियमों पर सहमति बनाएं जो पूरे सिस्टम को चलाएंगे। अस्पष्ट नियम predictable फेलियर पैदा करते हैं: या तो सिस्टम बहुत ज़्यादा ब्लॉक करेगा (तो लोग इसे बायपास कर देंगे), या बहुत कम ब्लॉक करेगा (तो गलत इनवॉइस चुकता हो जाएंगे)।

मैचिंग स्तर चुनें। सिर्फ हेडर-लेवल मिलान दस्तावेज़ स्तर पर टोटल्स चेक करता है। यह आसान लगता है, पर आंशिक डिलिवरी, बैकऑर्डर, फ्रीट लाइन्स या मिश्रित कर दरों के साथ जल्दी टूट जाता है। लाइन-लेवल मिलान सेटअप में अधिक समय लेता है, पर यह सुरक्षित डिफ़ॉल्ट है क्योंकि आप वही चीज़ तुलना करते हैं: विशिष्ट लाइन, उसकी मात्रा, और यूनिट प्राइस।

हार्ड ब्लॉक बनाम वार्निंग पर निर्णय लें। हार्ड ब्लॉक का अर्थ है कि समस्या हल होने तक भुगतान आगे नहीं बढ़ेगा। वार्निंग का अर्थ है कि इनवॉइस आगे बढ़ सकता है पर किसी को जोखिम स्वीकार करना होगा।

सामान्य प्रारंभिक बिंदु:

• हार्ड ब्लॉक: इनवॉइस की गई मात्रा प्राप्त मात्रा से ज़्यादा है (सामान के लिए)।
• हार्ड ब्लॉक: यूनिट प्राइस PO प्राइस से सहनशीलता से अधिक है।
• वार्निंग: छोटे राउंडिंग अंतर।
• वार्निंग: कर या शिपिंग अंतर जो अपेक्षित हैं और अलग से कोड किए गए हैं।

सहनशीलता नियम स्पष्ट रखें। विधि (प्रतिशत, परिमाण, या दोनों में से बड़े) और उसका मालिक कौन है यह परिभाषित करें। उदाहरण: प्रति लाइन +/- 1% या +/- $5 की अनुमति, और फ़ाइनेंस को सहनशीलता बदलने पर एक ऑडिट नोट के साथ अनुमति हो।

एक छोटा, साझा स्टेटस सेट रखें। हर टीम के लिए कस्टम स्टेटस से बचें। एक साफ सेट सामान्यतः पर्याप्त है: Matched, Hold, Exception, Approved. "Hold" का अर्थ है भुगतान ब्लॉक है। "Exception" का अर्थ है कि एक मानव समीक्षा करे। "Approved" का अर्थ है कि किसी नामित व्यक्ति ने मिसमैच स्वीकार किया और कारण रिकॉर्ड किया।

डेटा मॉडल: ज़रूरी तालिकाएँ (और क्यों)

तीन-तरफ़ा मैच स्वचालन तभी काम करता है जब आपका डेटा मॉडल एक PO लाइन, जो मिला, और जो इनवॉइस किया गया उसे लाइन-लेवल पर मिलाकर रख सके। हर इनवॉइस लाइन को एक विशिष्ट PO लाइन से मैचेबल होना चाहिए (या स्पष्ट रूप से नॉन-PO के रूप में चिह्नित), और हर रिसीट लाइन को उस PO लाइन पर शेष मात्रा कम करनी चाहिए।

कोर पर्चेसिंग तालिकाओं से शुरू करें:

• Vendors: प्रत्येक सप्लायर के लिए एक पंक्ति (नाम, शर्तें, टैक्स जानकारी)।
• ItemsServices: वैकल्पिक, पर सुसंगतता में मदद करता है (SKU, विवरण, यूनिट ऑफ मेज़र)।
• PurchaseOrders: PO हेडर (vendor_id, currency, requested_by, status)।
• PO_Lines: मैचिंग का एंकर (po_id, item_id/description, ordered_qty, unit_price)।

Receiving के अपने रिकॉर्ड होने चाहिए, भले ही एक "receipt" सिर्फ एक कन्फर्मेशन हो। रिसीट्स को इनवॉइसेस से अलग रखें ताकि आप साबित कर सकें क्या कब आया:

• Receipts: रिसीट हेडर (vendor_id, received_date, location, status)।
• Receipt_Lines: हर लाइन PO लाइन को संदर्भित करती है (receipt_id, po_line_id, received_qty, notes)।

Invoicing receiving को मिरर करता है। जो सप्लायर ने बिल किया उसे लाइन-लेवल पर स्टोर करें और उसे उस PO लाइन से जोड़ें जो उसे कवर करती है:

• Invoices: इनवॉइस हेडर (vendor_id, invoice_number, invoice_date, due_date, status)।
• Invoice_Lines: (invoice_id, po_line_id जब लागू हो, invoiced_qty, unit_price, tax, line_total)।

अंत में, एक पेमेंट-फेसिंग रिकॉर्ड बनाएं जिसे आपका वर्कफ़्लो ब्लॉक कर सके। कुछ टीमें इसे बिल, पेमेंट अनुरोध, या पे रन आइटम कहती हैं:

• PaymentRequests (या Bills): invoice_id से जुड़ा और इसमें payment_hold (true/false) और hold_reason शामिल हो।

ऑडिट और साफ़ अपवाद हैंडलिंग के लिए, हेडर्स पर सामान्य लाइफ़साइकिल फ़ील्ड जोड़ें (POs, receipts, invoices, payments): status, created_at/created_by, approved_at/approved_by, posted_at, और (वैकल्पिक) source_document_id इम्पोर्ट्स के लिए।

बेहतर मैचिंग के लिए प्रमुख फ़ील्ड और रिश्ते

मैचिंग सबसे अच्छा तभी काम करती है जब हर दस्तावेज़ वही लाइन आइटम ट्रेस करे। इसका मतलब स्थिर IDs, साफ़ लिंक, और लाइन से रीकैल्कुलेट करने वाले टोटल्स।

यह सुनिश्चित करें कि प्रत्येक तालिका में आंतरिक स्थिर ID और वह बाहरी नंबर हो जिसे लोग खोजते हैं:

• PO हेडर: po_id, po_number, vendor_id, currency, status, po_date
• PO लाइनें: po_line_id, po_id, item_id या description, ordered_qty, unit_price, tax_rate, line_total
• रिसीट्स: receipt_id, receipt_number, vendor_id, received_date; receipt_line_id, receipt_id, po_line_id, received_qty
• इनवॉइस: invoice_id, vendor_id, vendor_invoice_number, invoice_date, currency, subtotal, tax_total, total; invoice_line_id, invoice_id, po_line_id, qty, unit_price, tax_amount, line_total
• Vendors और items: vendor_id, payment_terms, default_currency; item_id, uom, tax_code

सबसे महत्वपूर्ण लिंक लाइन-लेवल हैं:

• invoice_line.po_line_id को PO लाइन की ओर इशारा करना चाहिए।
• receipt_line.po_line_id को उसी PO लाइन की ओर इशारा करना चाहिए।

यही आपको मात्रा और कीमत बिना अनुमान के तुलना करने देता है।

आंशिकता संभालने के लिए, PO लाइन के लिए रनिंग टोटल्स कैलकुलेट करें: received_qty (receipt lines का योग) और invoiced_qty (invoice lines का योग)। फिर remaining_qty = ordered_qty - received_qty और open_to_invoice_qty = received_qty - invoiced_qty निकालें। ये मान स्पष्ट कर देते हैं कि कोई इनवॉइस जल्दी है, लेट है, या ओवरबिलिंग है।

जब PO बदले तो इतिहास को ओवरराइट न करें। PO रिवीजन नंबर रखें और या तो पुराने PO लाइनें रखें (एक एक्टिव फ़्लैग के साथ) या चेंज लॉग लिखें (किसने क्या बदला, कब, पुराना मान, नया मान)।

डुप्लिकेट और गलत जॉइंस रोकने के लिए बेसिक गार्डरेल्स जोड़ें:

• Unique (vendor_id, vendor_invoice_number)
• Unique receipt_number और po_number
• currency, quantities, और unit_price पर Not null
• चेक constraints जैसे qty >= 0 और unit_price >= 0
• invoice_line और receipt_line से po_line पर foreign keys

स्टेप-बाय-स्टेप वर्कफ़्लो: इनवॉइस इनटेक से लेकर भुगतान होल्ड तक

तीन-तरफ़ा मैच स्वचालन आमतौर पर तीन एंट्री प्वाइंट्स होते हैं: एक इनवॉइस आती है (ईमेल, अपलोड, EDI), एक रिसीट पोस्ट होता है, या एक PO बदला जाता है (मूल्य, मात्रा, स्टेटस)। वर्कफ़्लो को इन सभी पर प्रतिक्रिया करनी चाहिए ताकि जैसे ही गायब हिस्सा आए, इनवॉइस होल्ड से बाहर आ सके।

1) पहले इनवॉइस बेसिक्स को वैलिडेट करें। पुष्टि करें कि विक्रेता सक्रिय है, PO मौजूद है, मुद्रा PO से मेल खाती है, और टोटल्स आंतरिक रूप से संगत हैं (लाइन टोटल्स जोड़कर कुल मिलता है, टैक्स वाजिब है, नकारात्मक मात्राएँ नहीं हैं सिवाय क्रेडिट्स के सपोर्ट के)। अगर यह विफल होता है, इनवॉइस को सीधे Hold पर भेजें और स्पष्ट कारण दें।

2) हेडर नहीं—प्रति लाइन मैच करें। हर इनवॉइस लाइन के लिए संबंधित PO लाइन और अभी तक के रिसीट टोटल खोजें। तुलना करें:

• इनवॉइस की गई मात्रा बनाम प्राप्त मात्रा (या प्राप्त - पहले से इनवॉइस की गई)
• इनवॉइस का यूनिट प्राइस बनाम PO पर यूनिट प्राइस
• सहनशीलता नियम
• क्या PO लाइन अभी भी इनवॉइस के लिए खुली है

3) स्टेटस सेट करें और ब्लॉकिंग लागू करें। एक सामान्य पैटर्न:

• Matched: सभी लाइनें चेक पास करती हैं, कोई खुला अपवाद नहीं।
• Hold: कम से कम एक लाइन फेल करती है, या आवश्यक डेटा गायब है।

जब Hold सेट हो, तो एक भुगतान होल्ड रेकॉर्ड बनाएं जिसे पेमेंट रन को आदर करना होगा। होल्ड्स को इनवॉइस से अलग रखें ताकि होल्ड जोड़ना, रिलीज़ करना, या बदलना इनवॉइस इतिहास को फिर से लिखे बिना हो सके।

4) भरोसेमंद कारण कोड रिकॉर्ड करें। केवल फ्री-टेक्स्ट होल्ड से बचें। PRICE_OVER_TOLERANCE, QTY_NOT_RECEIVED, PO_CLOSED, VENDOR_MISMATCH, या CURRENCY_MISMATCH जैसे कोड उपयोग करें, साथ में एक छोटा नोट।

वित्त के लिए अपवाद क्यू डिज़ाइन (क्या स्टोर करें और क्या दिखाएं)

एक अपवाद क्यू वह जगह है जहाँ मैचिंग उपयोगी बनती है, सिर्फ़ सख़्ती नहीं। फ़ाइनेंस को केवल वे इनवॉइस दिखने चाहिए जिन्हें निर्णय चाहिए, इतना संदर्भ के साथ कि वे जल्दी निर्णय ले सकें और एक साफ़ ऑडिट ट्रेल छोड़ सकें।

एक सामान्य दृष्टिकोण एक समर्पित तालिका की तरह है जैसे ExceptionCases। हर रो एक ब्लॉक इनवॉइस (या इनवॉइस लाइन) को दर्शाती है और इनवॉइस, PO, और रिसीट रेकॉर्ड की ओर इशारा करती है। मैचिंग इंजन यहाँ रीड-ओनली रखें। क्यू निर्णय और दस्तावेज़ के लिए हो।

ExceptionCases में क्या स्टोर करें

क्या गलत है, उसकी मात्रा कितनी है, इसका मालिक कौन है, और आगे क्या होगा ये स्टोर करें:

• Type (missing receipt, price variance, quantity variance, PO not found, duplicate invoice)
• Severity (info, warning, block) साथ में उपयोगकर्ता-अनुकूल कारण
• Owner (व्यक्ति या टीम) और status (open, waiting on vendor, waiting on warehouse, resolved, overridden)
• Variance snapshot जैसे sortable numbers (invoice amount, matched amount, price delta, quantity delta)
• SLA फ़ील्ड्स (due date, escalation flag, reassigned_at, reassignment_reason)

सहयोग और ऑडिट डेटा भी स्टोर करें: टिप्पणियाँ (लेखक, टाइमस्टैम्प) और अटैचमेंट मेटाडेटा (फाइल नाम, प्रकार, uploaded_by, uploaded_at). भले ही फाइलें कहीं और हों, मेटाडेटा केस में होना चाहिए ताकि इतिहास पूरा रहे।

फ़ाइनेंस को क्या दिखाना चाहिए (और क्या करना चाहिए)

क्यू व्यू एक तंग वर्कलिस्ट होनी चाहिए: विक्रेता, इनवॉइस नंबर, अपवाद प्रकार, गंभीरता, राशि, ड्यू डेट, मालिक, और एक स्पष्ट "क्यों ब्लॉक है" संदेश।

एक केस खोलने पर साइड-बाय-साइड सारांश दिखाएँ: PO लाइनें, रिसीट मात्राएँ, इनवॉइस लाइनें, और ठीक वही फ़ील्ड जो फेल हुए।

एक्शन्स सीमित और सुरक्षित रखें:

• रिसीट मांगें (receiving को रूट करे, status को waiting पर सेट करे)
• क्रेडिट मेमो अनुरोध करें (वेंडर को भेजें, अपेक्षित समायोजन रिकॉर्ड करें)
• ओवरराइड मंज़ूर करें (कारण आवश्यक, approver और टाइमस्टैम्प कैप्चर करें)
• पुनः असाइन करें (owner अपडेट करें, reassignment इतिहास रखें) -Resolved के रूप में बंद करें (केवल बदलावों के बाद जब मैच पास हो)

उदाहरण: एक इनवॉइस इसलिए ब्लॉक है क्योंकि 8 यूनिट मिलीं पर 10 बिल की गईं। फ़ाइनेंस रिसीट के लिए अनुरोध कर सकता है, या 8 प्राप्त यूनिट्स के लिए ओवरराइड मंज़ूर कर सकता है और बाकी 2 को होल्ड पर रख सकता है।

वास्तविक उदाहरण: आंशिक रिसीट और मिसमैच्ड इनवॉइस

एक खरीदार PO बनाता है 100 यूनिट आइटम A की $10.00 प्रति। PO टोटल $1,000 है। दो दिन बाद, वेयरहाउस 80 यूनिट के लिए रिसीट पोस्ट करता है।

फिर एक इनवॉइस आता है 100 यूनिट के लिए $10.00 प्रति। मैचिंग को इनवॉइस लाइन्स की तुलना प्राप्त की गई मात्रा से करनी चाहिए, न कि केवल ऑर्डर की गई मात्रा से।

उस लाइन पर:

• ऑर्डर्ड: 100 यूनिट
• प्राप्त: 80 यूनिट
• इनवॉइस्ड: 100 यूनिट
• मैच्ड मात्रा: min(Received, Invoiced) = 80 यूनिट
• अनमैच्ड मात्रा: Invoiced - Matched = 20 यूनिट

इनवॉइस "On hold" हो जाती है क्योंकि 20 यूनिट का कोई रिसीट नहीं है। फ़ाइनेंस को एक केस दिखेगा स्पष्ट कारण के साथ (Quantity variance: +20) और प्रमुख संख्याएँ साइड-बाय-साइड।

नोटिफिकेशन्स उन लोगों को जाएँ जो इसे सबसे तेज़ी से ठीक कर सकते हैं: आम तौर पर रिसीवर (यह पुष्टि करने के लिए कि कोई रिसीट गायब है) और खरीदार (यह फॉलो-अप करने के लिए कि शिपमेंट सच में कम था)।

जब बाकी 20 यूनिट्स आ जाएँ और वेयरहाउस दूसरा रिसीट पोस्ट करे, सिस्टम मैचिंग फिर से चलाता है: received 100 हो जाता है, unmatched 0 होता है, इनवॉइस Matched हो जाती है, और होल्ड रिलीज़ हो जाता है।

अब अगर कीमत भी भिन्न हो: सप्लायर 100 यूनिट $10.50 पर इनवॉइस करता है बजाय $10.00 के। मात्रा मिलती है पर कीमत नहीं। अपेक्षित परिणाम: इनवॉइस होल्ड पर रहे और एक कारण के साथ रूट हो जैसे "Price variance: +$0.50/unit (+$50 total)."

आम गलतियाँ जो तीन-तरफ़ा मैच वर्कफ़्लो तोड़ देती हैं

अधिकांश मैचिंग फेलियर गणित के बारे में नहीं होते। वे कमजोर डेटा लिंक और पोस्ट किए गए दस्तावेज़ों पर ढीली नियंत्रण से आते हैं।

सिर्फ़ इनवॉइस टोटल पर मिलान करना। हेडर ठीक लग सकता है जबकि एक लाइन की कीमत ज़्यादा या कम हो। लाइन-लेवल मैचिंग करें, और स्पष्ट करें क्या भिन्न हो सकता है (अक्सर फ्रीट) और क्या नहीं (प्राप्त मात्रा और यूनिट प्राइस)।

एक रिसीट और एक इनवॉइस मान लेना। असली खरीद में स्प्लिट शिपमेंट और आंशिक बिलिंग होती है। उसी PO लाइन के खिलाफ कई रिसीट और कई इनवॉइस का समर्थन करें, और लाइन-लेवल पर शेष खुली मात्रा ट्रैक करें।

पोस्ट किए गए रिसीट्स या इनवॉइस को बिना ट्रेल के एडिट करने देना। अगर कोई बाद में मात्रा चुपचाप बदल सकता है, मैचिंग प्रमाण नहीं रहती। पोस्ट किए गए रिकॉर्ड लॉक करें और समायोजन दस्तावेज़ के ज़रिये सुधार करें जो इतिहास बनाए रखें।

डुप्लिकेट रोकथाम का अभाव। वही विक्रेता इनवॉइस नंबर दो बार दर्ज हो सकता है, या कोई PDF किसी अन्य व्यक्ति द्वारा फिर से अपलोड किया जा सकता है। शुरुआत में यूनिकनेस जोड़ें (vendor + invoice number, और वैकल्पिक रूप से date/amount) और डुप्लिकेट मिलने पर स्पष्ट संदेश दिखाएं।

अपवाद कारण अस्पष्ट रखना। फ़ाइनेंस को अनुमान नहीं लगाना चाहिए। कारण कोड रखें जो साफ़ रूट करते हैं: price mismatch, quantity mismatch, missing receipt, duplicate suspected, PO not found, vendor mismatch।

भुगतान ब्लॉक चालू करने से पहले त्वरित चेकलिस्ट

भुगतान ब्लॉक वह जगह है जहाँ मैचिंग रिपोर्ट से नियंत्रण बन जाती है। अगर बुनियादी चीज़ें ठोस नहीं हैं, आप फ़ाइनेंस के लिए शोर पैदा करेंगे और विक्रेताओं के लिए देर से भुगतान होंगे।

कुछ अलग तरह की इनवॉइस पर छोटे सेट का परीक्षण करें: एक क्लीन मैच, एक आंशिक रिसीट, एक मूल्य परिवर्तन, और एक टैक्स अंतर। अगर किसी का मैच साफ़ नहीं हो पा रहा, पहले डेटा और नियम ठीक करें।

चेकलिस्ट:

• संदर्भ पूर्णता: हर इनवॉइस में एक विक्रेता और PO संदर्भ हो, और हर इनवॉइस लाइन को एक विशिष्ट PO लाइन से मैप किया जा सके (सिर्फ़ "PO टोटल" नहीं)। तय करें जब विक्रेता केवल PO हेडर नंबर भेजे तो क्या होता है।
• संगत गणित: मात्राएँ, यूनिट प्राइस और टोटल्स हर बार वही तरीके से रीकैल्कुलेट हों। टैक्स, फ्रीट, डिस्काउंट और राउंडिंग के बारे में स्पष्ट रहें (उदाहरण के लिए, लाइन पर राउंडिंग बनाम केवल इनवॉइस टोटल पर)।
• स्टेटस समय पर ब्लॉक करें: "on hold" तब सेट करें जब भी कोई पेमेंट अनुरोध या payout रिकॉर्ड बनता है उससे पहले।
• संरचित अपवाद: हर होल्ड एक कारण कोड और एक मालिक (AP, खरीदार, रिसीवर) स्टोर करे। ड्यू डेट जोड़ें ताकि होल्ड स्थायी न रहे।
• वास्तविक ऑडिट ट्रेल: ओवरराइड्स रिकॉर्ड करें किसने मंज़ूर किया, कब, और क्या मंज़ूर किया (मूल मान सहित)। अगर एडिट की अनुमति है, पहले और बाद के मान लॉग करें।

अगले कदम: प्रक्रिया का पायलट और विज़ुवल बिल्ड

तीन-तरफ़ा मैच स्वचालन को किसी नियंत्रण की तरह व्यवहार करें: इसे कम खर्च वाले हिस्से पर साबित करें, फिर रोल आउट करें।

एक पायलट से शुरू करें जिसे मॉनिटर करना आसान हो। एक बिज़नेस यूनिट चुनें, एक छोटा विक्रे़ता समूह जो साफ़ इनवॉइस भेजता है, या एक आइटम श्रेणी। शुरू में नियम सख़्त रखें (सटीक मात्रा और कीमत मैच) ताकि डेटा गुणवत्ता की समस्याएँ जल्दी दिखें।

सफलता मापें एक सरल फ़ाइनेंस व्यू से: प्रति सप्ताह होल्ड्स, शीर्ष कारण कोड, होल्ड से रिलीज़ तक का समय, कितने होल्ड सच्चे मिसमैच थे, और कौन से विक्रेता बार-बार अपवाद पैदा करते हैं।

अगर आप जल्दी प्रोटोटाइप करना चाहते हैं, तो नो-कोड प्लेटफ़ॉर्म मदद कर सकता है क्योंकि आप तालिकाएँ, मैचिंग नियम और रूटिंग बिना कोड लिखे मॉडल कर सकते हैं। उदाहरण के लिए, AppMaster (appmaster.io) में आप PO, रिसीट, इनवॉइस और अपवाद तालिकाएँ बना सकते हैं, फिर विज़ुअल बिज़नेस प्रोसेस में होल्ड लॉजिक जोड़ सकते हैं ताकि वही नियम हर ट्रिगर पर चले।

पायलट समूह से वास्तविक इनवॉइस के साथ परीक्षण करें, जिसमें आंशिक रिसीट और सामान्य विक्रेता गलतियाँ शामिल हों। पैटर्न देखने के बाद ही मैचिंग की किज़ और छोटी सहनशीलताएँ जोड़ें। जब होल्ड्स तर्कसंगत दिखने लगें और समाधान समय सुधरे, तो स्कोप बढ़ाएँ और समृद्ध नियम जोड़ें (टैक्स और फ्रीट हैंडलिंग, यूनिट-ऑफ-मेज़र रूपांतरण, स्प्लिट शिपमेंट) बिना मुख्य नियंत्रण खोए: भुगतान रिलीज़ तब तक नहीं जब तक मैच साफ़ न हो।