WhatsApp फोटो से लाइव ऑर्डर बुक तक: डिस्ट्रीब्यूटर्स के लिए ERP और ऑफ़लाइन फ़ील्ड ऐप

हम जिन ज़्यादातर डिस्ट्रीब्यूटर्स से मिलते हैं, उनका काम तीन टूल पर चलता है: इनवॉइस के लिए Tally, स्टॉक और बकाया के लिए Excel, और बाक़ी सब कुछ के लिए WhatsApp। सेल्समैन दुकान में ऑर्डर शीट की फ़ोटो खींचकर ऑफ़िस भेजता है, अगली सुबह कोई उसे Tally में टाइप करता है, और तब जाकर किसी को पता चलता है कि उस दुकान पर पहले से ₹50,000 बकाया है और दो महीने से पेमेंट नहीं आया। स्टॉक "लगभग 20 केस" रहता है — उस दिन तक, जब वह होता ही नहीं।

हमने AIVCJ ERP यह दिखाने के लिए बनाया कि इस चक्कर की जगह क्या आ सकता है: एक फ़ील्ड ऐप जो बिना नेटवर्क के चलता है, एक ऑर्डर बुक जो माल निकलने से पहले क्रेडिट जाँचती है, बैच और एक्सपायरी के हिसाब से ट्रैक होता स्टॉक, एक क्लिक में GST इनवॉइस, और मालिक के लिए आसान अंग्रेज़ी में सवाल पूछने का तरीक़ा। यह एक सैंपल FMCG डिस्ट्रीब्यूटर पर चलता है — Northwind Distribution, जिसके 3 वेयरहाउस (Nagpur, Indore, Hubli), 396 रिटेलर, 8 फ़ील्ड सेल्समैन, 123 SKU और 100 दिनों का इतिहास है। हर विज़िटर को अपनी अलग कॉपी मिलती है।

ऑर्डर का सफ़र: दुकान से इनवॉइस तक

1. दुकान में — सेल्समैन Northwind Sales ऐप में दिन की बीट खोलता है, दुकान का क्रेडिट स्टेटस देखता है, केस जोड़ता है और ऑर्डर प्लेस करता है। नेटवर्क नहीं है? ऑर्डर फ़ोन में सेव हो जाता है और उस पर "नेटवर्क का इंतज़ार" लिखा आता है।
2. Sync — फ़ोन के ऑनलाइन आते ही कतार अपने-आप अपलोड हो जाती है। ERP हर लाइन की क़ीमत अपनी प्राइस लिस्ट से लगाता है और क्रेडिट जाँच कोड में चलाता है।
3. क्रेडिट होल्ड — अगर दुकान अपनी लिमिट से ऊपर है या कोई इनवॉइस अपनी शर्तों से पुराना हो गया है, तो ऑर्डर सटीक कारण के साथ होल्ड पर चला जाता है ("बकाया ₹49,917 + यह ऑर्डर ₹12,147 = ₹62,064, ₹50,000 की लिमिट से ऊपर; इनवॉइस NW/26-27/000993 74 दिन पुराना है")। मालिक कारण लिखकर उसे रिलीज़ करता है, या कैंसल कर देता है। सेल्समैन का ऐप अपने-आप अपडेट हो जाता है।
4. पिकिंग और इनवॉइस — वेयरहाउस बैच-वार "पहले एक्सपायरी, पहले बाहर" के हिसाब से माल निकालता है, 15 दिन के अंदर एक्सपायर होने वाला माल छोड़ देता है, और GST टैक्स इनवॉइस HSN कोड, बैच नंबर, CGST + SGST या IGST और शब्दों में रक़म के साथ बनता है।
5. दोबारा ऑर्डर — बिक्री की रफ़्तार × सप्लायर का लीड टाइम बताता है कि क्या ख़त्म होने वाला है, सप्लायर और वेयरहाउस के हिसाब से समूह बनाकर; एक क्लिक में परचेज़ ऑर्डर बनता है, और माल आने पर नए बैच स्टॉक में जुड़ जाते हैं।

पहले ऑफ़लाइन, और कभी दो बार नहीं

भारत में फ़ील्ड सेल्स गोदामों, बेसमेंट और छोटे क़स्बों में होती है। जिस ऐप को ऑर्डर सेव करने के लिए नेटवर्क चाहिए, वह ऑर्डर गँवाता है। इसलिए Northwind Sales ऐप (Expo / React Native से बना) हर ऑर्डर और वसूली पहले फ़ोन में लिखता है — Android पर SQLite — और बाद में अपलोड करता है।

ऑफ़लाइन का मुश्किल हिस्सा स्टोरेज नहीं है; असली मुश्किल है दोबारा कोशिश (retry)। सेल्समैन "ऑर्डर प्लेस करें" दबाता है, रिक्वेस्ट सर्वर तक पहुँच जाती है, जवाब किसी नो-नेटवर्क ज़ोन में खो जाता है, और फ़ोन फिर से कोशिश करता है। सावधानी न हो तो यह दो ऑर्डर बन जाते हैं। ऐप जो भी आइटम कतार में डालता है, उसकी अपनी id होती है, और ERP को जब कोई id दोबारा दिखती है तो वह पहले से मौजूद ऑर्डर ही लौटा देता है। फ़ोन पर दिखने वाली क़ीमत और क्रेडिट सिर्फ़ झलक हैं: ERP ऑर्डर पहुँचने पर सब कुछ दोबारा प्राइस करता है और दोबारा जाँचता है, इसलिए पुराना डेटा लिए बैठा फ़ोन कभी पुरानी क़ीमत पर या लिमिट से ऊपर नहीं बेच सकता।

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

क्रेडिट कंट्रोल कोड में, मॉडल में नहीं

क्रेडिट के फ़ैसले पैसे के फ़ैसले हैं, इसलिए इनमें कोई AI शामिल नहीं है। एक छोटा नियम-मॉड्यूल फ़ैसला करता है: कुल जोखिम = बकाया इनवॉइस + खुले ऑर्डर जिनका अभी इनवॉइस नहीं बना + यह ऑर्डर, जिसकी तुलना दुकान की लिमिट से होती है; और दुकान की शर्तों से पुराना कोई भी बिना-भुगतान इनवॉइस ऑर्डर को होल्ड पर डाल देता है। (खुले ऑर्डर वाली यह कमी हमें टेस्टिंग में मिली — उसी दुकान का दूसरा ऑर्डर, होल्ड पर पड़े पहले ऑर्डर को अनदेखा कर रहा था। यह ठीक कर दी गई है और अब इसका अपना यूनिट टेस्ट है।) होल्ड रिलीज़ करने के लिए हमेशा कारण चाहिए, और हर रिलीज़, लिमिट में बदलाव और स्टॉक एडजस्टमेंट ऑडिट लॉग में दर्ज होता है।

अपने डेटा से पूछिए — सुरक्षा के इंतज़ाम के साथ

AI हम सिर्फ़ एक जगह इस्तेमाल करते हैं — जब मालिक सवाल पूछता है: "Nagpur के कौन-से रिटेलर 60 दिन से ज़्यादा बकाया हैं?", "इस महीने कैटेगरी-वार ग्रॉस मार्जिन"। Claude Haiku 4.5 एक SQL query लिखता है; फिर ERP तय करता है कि उसे चलने दिया जाए या नहीं:

• query एक read-only ट्रांज़ैक्शन में चलती है, सिर्फ़ विज़िटर की अपनी कॉपी के 14 views पर (रक़म रुपये में, फ़ोन नंबर नहीं);
• कोड में एक गार्ड हर उस चीज़ को रिजेक्ट करता है जो एक अकेला SELECT नहीं है, या जो सिस्टम टेबल, सेटिंग्स या इन views से बाहर किसी चीज़ को छूती है — 28 allow और attack केस पर टेस्ट किया गया;
• 5 सेकंड का टाइमआउट, 200 पंक्तियों की सीमा, हर विज़िटर के लिए रोज़ 15 सवाल;
• हर जवाब के साथ ठीक वही query दिखाई जाती है, टेबल के रूप में, और जहाँ डेटा का ढाँचा ठीक बैठे वहाँ चार्ट के साथ।

जिन सवालों का जवाब डेटा में नहीं है — किसी प्रतिस्पर्धी की क़ीमत, अगले महीने की बिक्री, "सारे कैंसल ऑर्डर डिलीट कर दो" — उन पर एक छोटा जवाब आता है कि वह किन सवालों का जवाब दे सकता है। एक सवाल की लागत लगभग $0.002 है।

हमने क्या मापा

ईमानदारी पर दो बातें। पहली, जवाबों की जाँच कोड से होती है, किसी AI जज से नहीं: मॉडल की query और हाथ से लिखी सही query एक ही डेटा पर चलती हैं, और नतीजों की तुलना होती है (वही पंक्तियाँ, ±1% के अंदर वही आँकड़े)। दूसरी, blind सेट की तीनों चूकें असली थीं: एक लिस्ट 50 पंक्तियों पर कट गई, एक सीरीज़ नई-से-पुरानी क्रम में आई, और प्रतिस्पर्धी की क़ीमत वाला एक सवाल मना करने की बजाय हमारे अपने कैटलॉग में खोजा गया। पहली और तीसरी चूक हमने रन के बाद ठीक की; 17/20 वैसा ही रहता है जैसा मापा गया। पहले स्क्रिप्टेड रन ने हमारी रेफ़रेंस queries में भी चार ग़लतियाँ पकड़ीं — एक जैसे नाम वाली दुकानें आपस में मिल गई थीं — इसीलिए अब सैंपल डेटा में हर दुकान का नाम अलग है।

Tally से जोड़ने के लिए क्या चाहिए

ज़्यादातर डिस्ट्रीब्यूटर पहले ही दिन Tally नहीं हटाएँगे, और उन्हें ज़रूरत भी नहीं है। व्यावहारिक रास्ता है रात में या हर घंटे का sync: मास्टर (लेजर, स्टॉक आइटम, गोदाम) और बकाया बिल Tally के XML इंटरफ़ेस से आते हैं, इनवॉइस बनने के बाद सेल्स ऑर्डर वाउचर बनकर वापस जाते हैं, और ERP वह सब रखता है जो Tally नहीं रखता — बीट, फ़ील्ड ऑर्डर, बैच-वार स्टॉक, होल्ड और ऑडिट ट्रेल। डेमो Tally या GST पोर्टल को कॉल नहीं करता; ई-इनवॉइस (IRN) और ई-वे बिल के फ़ील्ड उस क़दम के लिए तैयार हैं।

आज़माकर देखिए: erp.demos.aivcj.com खोलिए, Sales ऐप में Shree Ganesh Kirana का ऑर्डर लीजिए, उसे क्रेडिट होल्ड पर जाते देखिए, रिलीज़ कीजिए, पिक कीजिए और इनवॉइस खोलिए। फिर ऐप को "नेटवर्क नहीं" पर डालिए और यही दोबारा कीजिए।