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 நாட்களுக்குள் காலாவதியாகும் எதையும் தவிர்க்கிறது; HSN குறியீடுகள், பேட்ச் எண்கள், CGST + SGST அல்லது IGST, எழுத்தில் தொகை ஆகியவற்றுடன் GST வரி இன்வாய்ஸ் உருவாகிறது.
5. மறு ஆர்டர் — விற்பனை வேகம் × சப்ளையர் லீட் டைம் கொண்டு எது தீரப்போகிறது என்பதை, சப்ளையர் மற்றும் கிடங்கு வாரியாகக் குழுவாக்கிக் காட்டுகிறது; ஒரே கிளிக்கில் பர்சேஸ் ஆர்டர் உருவாகிறது, சரக்கைப் பெற்றதும் புதிய பேட்ச்கள் ஸ்டாக்கில் சேர்கின்றன.

முதலில் ஆஃப்லைன், ஒருபோதும் இருமுறை இல்லை

இந்தியாவில் ஃபீல்ட் விற்பனை கிடங்குகளிலும், அடித்தளங்களிலும், சிறு நகரங்களிலும் நடக்கிறது. ஆர்டரைச் சேமிக்கச் சிக்னல் தேவைப்படும் ஆப் ஆர்டர்களை இழக்கும். அதனால் Northwind Sales ஆப் (Expo / React Native கொண்டு உருவாக்கப்பட்டது) ஒவ்வொரு ஆர்டரையும் வசூலையும் முதலில் போனிலேயே எழுதுகிறது — Android-இல் SQLite — பிறகு அப்லோட் செய்கிறது.

ஆஃப்லைனின் கடினமான பகுதி சேமிப்பு அல்ல; மறுமுயற்சி (retry)தான். பிரதிநிதி "ஆர்டர் போடு" என்று தட்டுகிறார், கோரிக்கை சர்வரை அடைகிறது, பதில் சிக்னல் இல்லாத இடத்தில் தொலைகிறது, போன் மீண்டும் முயல்கிறது. கவனம் இல்லையென்றால் அது இரண்டு ஆர்டர்கள். ஆப் வரிசையில் சேர்க்கும் ஒவ்வொரு உருப்படிக்கும் தனி id உண்டு; ஒரே id-ஐ இருமுறை பார்த்தால் ERP ஏற்கெனவே உள்ள ஆர்டரையே திருப்பித் தருகிறது. போனில் காட்டப்படும் விலையும் கிரெடிட்டும் ஒரு முன்னோட்டம் மட்டுமே: ஆர்டர் வந்ததும் ERP எல்லாவற்றையும் மீண்டும் விலையிட்டு மீண்டும் சரிபார்க்கிறது, அதனால் பழைய தகவலுடன் இருக்கும் போன் ஒருபோதும் பழைய விலையிலோ லிமிட்டைத் தாண்டியோ விற்க முடியாது.

பிரதிநிதி ஆர்டர் எடுக்கும்போது அல்ல, கிடங்கு சரக்கை எடுக்கும்போதுதான் ஸ்டாக் ஒதுக்கப்படுகிறது — இருவருக்கும் சிக்னல் இல்லாமலே இரண்டு பிரதிநிதிகள் ஒரே நேரத்தில் கடைசி 20 கேஸ்களை விற்கலாம். அப்போது இரண்டாவது பிக்கிங் தெளிவான பற்றாக்குறையுடன் நிறுத்தப்படுகிறது ("850 குறைவு"), உரிமையாளர் ஸ்டாக்கை மாற்றுகிறார் அல்லது PO போடுகிறார். எதுவும் அதிகமாக விற்கப்படுவதில்லை, எந்த பேட்சும் மைனஸுக்குப் போவதில்லை.

கிரெடிட் கட்டுப்பாடு கோடில், மாடலில் அல்ல

கிரெடிட் முடிவுகள் பண முடிவுகள், அதனால் இதில் AI இல்லை. ஒரு சிறிய விதி மாட்யூல் முடிவு செய்கிறது: மொத்த வெளிப்பாடு = நிலுவை இன்வாய்ஸ்கள் + இன்னும் இன்வாய்ஸ் ஆகாத திறந்த ஆர்டர்கள் + இந்த ஆர்டர், இது கடையின் லிமிட்டுடன் ஒப்பிடப்படுகிறது; கடையின் கால வரம்பை விடப் பழைய எந்தச் செலுத்தப்படாத இன்வாய்ஸும் ஆர்டரை ஹோல்டில் வைக்கும். (திறந்த ஆர்டர் இடைவெளியைச் சோதனையின்போது கண்டுபிடித்தோம் — அதே கடையின் இரண்டாவது ஆர்டர், ஹோல்டில் இருந்த முதல் ஆர்டரைக் கணக்கில் எடுக்கவில்லை. அது சரிசெய்யப்பட்டு, இப்போது அதற்கென்று தனி யூனிட் டெஸ்ட் உள்ளது.) ஹோல்டை விடுவிக்க எப்போதும் காரணம் தேவை; ஒவ்வொரு விடுவிப்பும், லிமிட் மாற்றமும், ஸ்டாக் சரிசெய்தலும் ஆடிட் லாகில் பதிவாகின்றன.

உங்கள் டேட்டாவிடம் கேளுங்கள் — பாதுகாப்பு வேலிகளுடன்

நாங்கள் AI-ஐப் பயன்படுத்தும் ஒரே இடம், உரிமையாளர் கேள்வி கேட்பதுதான்: "Nagpur-இல் எந்தச் சில்லறை வியாபாரிகள் 60 நாட்களுக்கு மேல் நிலுவை?", "இந்த மாதம் வகை வாரியாக மொத்த லாப வரம்பு". Claude Haiku 4.5 ஒரு SQL query எழுதுகிறது; அதை இயக்கலாமா என்பதை ERP முடிவு செய்கிறது:

• query ஒரு read-only பரிவர்த்தனையில் இயங்குகிறது, பார்வையாளரின் சொந்தப் பிரதியின் 14 view-களில் மட்டும் (தொகைகள் ரூபாயில், போன் எண்கள் இல்லை);
• ஒற்றை SELECT அல்லாத எதையும், அல்லது சிஸ்டம் டேபிள்கள், அமைப்புகள் அல்லது அந்த view-களுக்கு வெளியே உள்ள எதையும் தொடும் எதையும் கோடில் உள்ள ஒரு காவல் நிராகரிக்கிறது — 28 allow மற்றும் attack கேஸ்களில் சோதிக்கப்பட்டது;
• 5 விநாடி டைம்அவுட், 200 வரிசை வரம்பு, ஒரு பார்வையாளருக்கு நாளொன்றுக்கு 15 கேள்விகள்;
• ஒவ்வொரு பதிலுடனும் அதே query அப்படியே காட்டப்படுகிறது, டேபிளாக, டேட்டாவின் வடிவம் பொருந்தினால் சார்ட்டாகவும்.

டேட்டாவால் பதில் சொல்ல முடியாத கேள்விகளுக்கு — போட்டியாளரின் விலை, அடுத்த மாத விற்பனை, "ரத்தான எல்லா ஆர்டர்களையும் நீக்கு" — அதற்குப் பதிலாக எதற்குப் பதில் சொல்ல முடியும் என்று ஒரு சுருக்கமான பதில் வருகிறது. ஒரு கேள்விக்கு செலவு சுமார் $0.002.

நாங்கள் அளந்தவை

நேர்மை பற்றி இரண்டு குறிப்புகள். முதலாவது, பதில்கள் AI நடுவரால் அல்ல, கோடால் மதிப்பிடப்படுகின்றன: மாடலின் query-யும் கையால் எழுதப்பட்ட சரியான query-யும் ஒரே டேட்டாவில் இயக்கப்பட்டு, முடிவுகள் ஒப்பிடப்படுகின்றன (அதே வரிசைகள், ±1%-க்குள் அதே எண்கள்). இரண்டாவது, blind தொகுப்பின் மூன்று தவறுகளும் உண்மையானவை: ஒரு பட்டியல் 50 வரிசைகளில் வெட்டப்பட்டது, ஒரு தொடர் புதியது-முதலில் வரிசையில் வந்தது, போட்டியாளர் விலை பற்றிய ஒரு கேள்வி மறுக்கப்படுவதற்குப் பதிலாக எங்கள் சொந்தக் கேட்டலாகில் தேடப்பட்டது. முதலாவதையும் மூன்றாவதையும் ரன்னுக்குப் பிறகு சரிசெய்தோம்; 17/20 அளந்தபடியே இருக்கிறது. முதல் ஸ்கிரிப்ட் ரன் எங்கள் ரெஃபரன்ஸ் query-களிலும் நான்கு தவறுகளைப் பிடித்தது — ஒரே பெயருள்ள கடைகள் ஒன்றாக இணைந்துவிட்டன — அதனால்தான் இப்போது மாதிரி டேட்டாவில் ஒவ்வொரு கடைக்கும் தனிப் பெயர்.

Tally-யுடன் இணைக்க என்ன தேவை

பெரும்பாலான விநியோகஸ்தர்கள் முதல் நாளிலேயே Tally-ஐ மாற்ற மாட்டார்கள், அதற்கான தேவையும் இல்லை. நடைமுறை வழி இரவுநேர அல்லது மணிநேர sync: மாஸ்டர்கள் (லெட்ஜர்கள், ஸ்டாக் உருப்படிகள், கிடங்குகள்) மற்றும் நிலுவை பில்கள் Tally-யின் XML இடைமுகத்திலிருந்து வருகின்றன, இன்வாய்ஸ் ஆனதும் விற்பனை ஆர்டர்கள் வவுச்சர்களாகத் திரும்பிச் செல்கின்றன, Tally வைத்திருக்காதவற்றை ERP வைத்திருக்கிறது — பீட்கள், ஃபீல்ட் ஆர்டர்கள், பேட்ச் வாரி ஸ்டாக், ஹோல்ட்கள், ஆடிட் டிரெயில். டெமோ Tally-யையோ GST போர்ட்டலையோ அழைப்பதில்லை; இ-இன்வாய்ஸ் (IRN) மற்றும் இ-வே பில் புலங்கள் அந்தப் படிக்குத் தயாராக உள்ளன.

முயன்று பாருங்கள்: erp.demos.aivcj.com-ஐத் திறந்து, Sales ஆப்பில் Shree Ganesh Kirana-வுக்கு ஒரு ஆர்டர் எடுங்கள், அது கிரெடிட் ஹோல்டில் விழுவதைப் பாருங்கள், விடுவியுங்கள், பிக் செய்யுங்கள், இன்வாய்ஸைத் திறங்கள். பிறகு ஆப்பை "சிக்னல் இல்லை" நிலைக்கு மாற்றி மீண்டும் செய்யுங்கள்.