કસ્ટમ સૉફ્ટવેર માટે Tally ઇન્ટિગ્રેશન, યોગ્ય રીતે

ભારતીય વ્યવસાય માટે અમે જે પણ સિસ્ટમ બનાવીએ છીએ, તે લગભગ હંમેશાં એક જ જગ્યાએ પૂરી થાય છે: હિસાબ Tally માં છે, અને એકાઉન્ટન્ટ તે છોડવાના નથી. એ સામાન્ય રીતે સાચો નિર્ણય છે. Tally એ છે જે એકાઉન્ટન્ટ જાણે છે, જેની ઑડિટર અપેક્ષા રાખે છે, અને જ્યાં રિટર્ન તૈયાર થાય છે. કસ્ટમ સિસ્ટમનું કામ તેને સ્વચ્છ ડેટા આપવાનું છે, તેનું સ્થાન લેવાનું નહીં.

નવી સિસ્ટમ એકાઉન્ટન્ટનો સમય બચાવે છે કે તેમના માટે કામ વધારે છે, એ લગભગ સંપૂર્ણપણે એ જોડાણ કેવી રીતે ડિઝાઇન થયું છે તેના પર આધાર રાખે છે.

ડેટા Tally માં કેવી રીતે પહોંચે છે

1. HTTP પર XMLTallyPrime જે મશીન પર ઇન્સ્ટૉલ છે ત્યાં સર્વર તરીકે ચાલી શકે છે — ડિફૉલ્ટ રીતે પોર્ટ 9000 પર — અને માસ્ટર તથા વાઉચર બનાવતી કે રિપોર્ટ કાઢતી XML વિનંતીઓ સ્વીકારી શકે છે. આ સૌથી સીધો માર્ગ છે અને મોટાભાગનાં ઇન્ટિગ્રેશન આ જ વાપરે છે. તેના માટે Tally ચાલુ હોવું અને કંપની ખુલ્લી હોવી જરૂરી છે.
2. ફાઇલ ઇમ્પોર્ટવાઉચર અને માસ્ટર XML ફાઇલો તરીકે તૈયાર થાય છે અને એકાઉન્ટન્ટ તેને ઇમ્પોર્ટ કરે છે. ધીમું, પણ તેમાં વ્યક્તિ સામેલ રહે છે, અને તે ત્યાં પણ કામ કરે છે જ્યાં Tally મશીન સુધી પહોંચી જ શકાતું નથી.
3. ODBCTally પોતાનો ડેટા ODBC દ્વારા પણ ઉપલબ્ધ કરાવે છે, જે રિપોર્ટ બીજી સિસ્ટમમાં વાંચવા માટે અનુકૂળ છે. એ વાંચવાનો માર્ગ છે, એન્ટ્રી લખવાનો નહીં.
4. TDL કસ્ટમાઇઝેશનTally ની પોતાની ડેફિનિશન લેંગ્વેજ Tally ની અંદર ફીલ્ડ અને રિપોર્ટ ઉમેરી શકે છે. તે ઉપયોગી છે, પણ તે એવો કોડ છે જેને Tally ના દરેક નવા રિલીઝ સાથે સંભાળવો પડે છે, તેથી અમે તેને કામની જરૂર પૂરતો મર્યાદિત રાખીએ છીએ.

જ્યારે Tally ઑફિસના ડેસ્કટૉપ પર હોય

Tally સામાન્ય રીતે ઑફિસના કમ્પ્યુટર પર ચાલે છે, અને વેબ એપ્લિકેશન બીજે ક્યાંક કોઈ સર્વર પર. બંને સીધા એકબીજાને કૉલ કરી શકતા નથી, અને એવું કરાવવું પણ ન જોઈએ. ભરોસાપાત્ર રીત છે Tally મશીન પર એક નાનો કનેક્ટર, જે વેબ એપ્લિકેશન પાસેથી બાકી એન્ટ્રીઓ માંગે છે, તેને સ્થાનિક રીતે Tally માં પોસ્ટ કરે છે, અને શું થયું તે જણાવે છે. કનેક્શન ફક્ત બહારની દિશામાં જાય છે, તેથી ઑફિસનું કંઈ ખુલ્લું રહેતું નથી.

વાઉચર પહેલાં માસ્ટર

વાઉચર લેજર, સ્ટૉક આઇટમ, ગોડાઉન અને કૉસ્ટ સેન્ટરને નામથી દર્શાવે છે. જો કોઈ નામ Tally ના માસ્ટર સાથે બરાબર મેળ ન ખાય, તો ઇમ્પોર્ટ નિષ્ફળ જાય છે, અથવા એથી ખરાબ, ખોટા માસ્ટર સામે નોંધાય છે. તેથી ઇન્ટિગ્રેશન પાસે એક મૅપિંગ હોવું જોઈએ: નવી સિસ્ટમની દરેક પાર્ટી, આઇટમ અને લેજર Tally માં તેના માસ્ટર સાથે જોડાયેલાં.

નવા માસ્ટર માટે પણ નિયમ જોઈએ. કાં તો ઇન્ટિગ્રેશન તેમને નક્કી કરેલા નિયમો હેઠળ બનાવે, અથવા એન્ટ્રી રોકીને એકાઉન્ટન્ટને પૂછે. તેણે એવું ક્યારેય થવા ન દેવું જોઈએ કે જોડણીનો ફેરફાર — અંતે એક પૂર્ણવિરામ, બદલાયેલું ટૂંકું રૂપ — ચૂપચાપ એ જ પાર્ટીનું બીજું લેજર બનાવી દે.

ક્યારેય બે વાર પોસ્ટ ન કરો

ઇન્ટિગ્રેશનની સૌથી સામાન્ય નિષ્ફળતા ડુપ્લિકેટ વાઉચર છે. Tally એન્ટ્રી સ્વીકારી લે છે, જવાબ આવે તે પહેલાં નેટવર્ક તૂટી જાય છે, અને સિસ્ટમ તેને ફરી મોકલે છે. બંને નકલો ચોપડામાં છે, અને સરવાળા એવી રીતે ખોટા છે કે શોધવામાં આખી બપોર જાય.

1. દરેક એન્ટ્રીની સ્થિર ઓળખદરેક વાઉચર સ્રોત સિસ્ટમનો એક ઓળખકર્તા સાથે રાખે છે, અને ઇન્ટિગ્રેશન કંઈ પણ બનાવતાં પહેલાં તેને તપાસે છે. પછી એક જ એન્ટ્રી બે વાર મોકલવાથી તે બીજી ઉમેરવાને બદલે પહેલીને અપડેટ કરે છે અથવા છોડી દે છે.
2. પોસ્ટિંગ લૉગદરેક પ્રયાસ નોંધાયેલો, શું મોકલાયું અને Tally એ શું જવાબ આપ્યો, જેથી ખૂટતી કે બેવડી એન્ટ્રી ફરી ઘડવાને બદલે મિનિટોમાં શોધી શકાય.
3. મેળવણીબંને સિસ્ટમ વચ્ચે દિવસ અને લેજર પ્રમાણે સરવાળાની નિયમિત સરખામણી, જે એવા કિસ્સા પકડે છે જેના પર તે વખતે કોઈનું ધ્યાન ગયું નહોતું.
4. કાળજીથી ફરી પ્રયાસકનેક્શનની નિષ્ફળતા પર આપમેળે ફરી પ્રયાસ થાય છે. Tally એ જે નકાર્યું તે કારણ સાથે કોઈ વ્યક્તિ પાસે જાય છે, નહીં કે ક્યાંક ખોટી જગ્યાએ નોંધાય ત્યાં સુધી વારંવાર મોકલાય.

વિગત કે સારાંશ

દરેક વ્યવહાર Tally માં પોતાના અલગ વાઉચર તરીકે ન જવો જોઈએ. પસંદગી વ્યવહારના પ્રકાર પ્રમાણે છે, અને તે એકાઉન્ટન્ટ સાથે મળીને કરવી જોઈએ, તેમના વતી નહીં.

• વેચાણનાં ઇન્વૉઇસ સામાન્ય રીતે એક-એક કરીને જાય છે, કારણ કે જ્યાં રિટર્ન Tally માંથી તૈયાર થાય છે, ત્યાં ઇન્વૉઇસ સ્તરની વિગત હોવી જરૂરી છે.
• પેરોલ સામાન્ય રીતે મહિને એક સમીક્ષા કરેલા જર્નલ તરીકે જાય છે, કૉસ્ટ સેન્ટર પ્રમાણે વહેંચાયેલું, દરેક કર્મચારીનું અલગ વાઉચર નહીં.
• મોટા જથ્થાની કાઉન્ટર રસીદો ઘણીવાર ચુકવણીની રીત પ્રમાણે રોજના સારાંશ તરીકે જાય છે, અને વિગત સ્રોત સિસ્ટમમાં રહે છે.
• સ્ટૉકની હેરફેર એ પર આધાર રાખે છે કે સ્ટૉકનું મૂલ્યાંકન Tally માં થાય છે કે નહીં. જો ઇન્વેન્ટરી નવી સિસ્ટમ પાસે હોય, તો Tally ને ઘણીવાર ફક્ત તેની હિસાબી અસર જોઈએ.

GST ની એ વિગતો જે રિટર્ન બગાડે છે

• દરેક લાઇન પર GSTIN, પુરવઠાનું સ્થળ અને HSN કે SAC, જેથી દરેક વાઉચર Tally માં ફેરફાર કર્યા વગર રિટર્ન માટે પૂરું હોય.
• ટૅક્સ લેજર દર અને પ્રકાર પ્રમાણે મૅપ થયેલાં, CGST અને SGST સામે IGST, નહીં કે બધા માટે એક ટૅક્સ લેજર.
• બંને સિસ્ટમમાં રાઉન્ડિંગ એક જ રીતે. નહીં તો સરવાળા એક રૂપિયાથી જુદા પડે છે, અને પછી કોઈ કોઈના પર ભરોસો કરતું નથી.
• ક્રેડિટ નોટ એ જ ઇન્વૉઇસ સાથે જોડાયેલી જેને તે સુધારે છે, અલગ નકારાત્મક એન્ટ્રી તરીકે પોસ્ટ થયેલી નહીં.
• બંધ સમયગાળાની તારીખવાળું વાઉચર ઇન્ટિગ્રેશન નકારે, નહીં કે ચૂપચાપ એવા મહિનામાં પોસ્ટ થઈ જાય જે એકાઉન્ટન્ટ બંધ કરી ચૂક્યા છે.

Zoho Books અને બીજા લેજર

Zoho Books પાસે દસ્તાવેજીકૃત REST API છે, જે ઑફિસ-મશીનની સમસ્યા સંપૂર્ણપણે દૂર કરે છે. આ લેખની બાકીની દરેક વાત છતાં લાગુ પડે છે: માસ્ટરનું મૅપિંગ, દરેક એન્ટ્રીની સ્થિર ઓળખ, પોસ્ટિંગ લૉગ અને મેળવણી. આ જ કોઈ પણ લેજર સાથેના ઇન્ટિગ્રેશનને ભરોસાપાત્ર બનાવે છે, અને આ જ સૌથી વધુ છૂટી જાય છે.