Tally اکاؤنٹنگ اچھی طرح کرتا ہے۔ کاروبار اسے چھوڑتے ہیں تو وجہ شاذ و نادر ہی اکاؤنٹنگ ہوتی ہے — بلکہ وہ سب کچھ جو Tally نہیں کرتا۔ لیکن migration میں چند ایسے جال ہیں جن سے بچنا انہیں ٹھیک کرنے سے کہیں سستا ہے۔
دیکھیں: Odoo کیا ہے؟ ایک منٹ میں۔ یہ ویڈیو عربی یا اردو میں دیکھیں۔ مزید ویڈیوز ہمارے YouTube چینل پر۔
UAE اور پاکستان میں Tally اب بھی SMEs کے ایک بڑے حصے کا بنیادی finance سسٹم ہے، اور اس کی معقول وجہ ہے: یہ سستا ہے، مانوس ہے، اور خطے کا ہر accountant اسے جانتا ہے۔
کاروبار اسے چند مستقل وجوہات کی بنا پر پیچھے چھوڑ دیتے ہیں — متعدد مقامات پر inventory، sales pipeline کی visibility، manufacturing، approval workflows، اور ہر وہ چیز جس کے لیے finance سسٹم کو operations سے بات کرنی پڑے۔ اس مرحلے پر سوال یہ بن جاتا ہے کہ audit trail توڑے بغیر منتقلی کیسے کی جائے۔
طے کریں کہ اصل میں کیا منتقل ہونا ہے
یہی وہ فیصلہ ہے جو پورے پروجیکٹ کی لاگت اور خطرے کا تعین کرتا ہے، اور عموماً بہت سرسری انداز میں کیا جاتا ہے۔
Master data — ہاں
Chart of accounts، customers، suppliers، items، tax codes۔ یہ منتقل ہونے لازمی ہیں، اور منتقلی سے پہلے صاف ہونے چاہییں۔
Open balances — ہاں
Invoice وار outstanding receivables اور payables، موجود stock، بینک اور کیش بیلنس، اور cutover کی تاریخ کے مطابق opening trial balance۔
Historical transactions — عموماً نہیں
یہاں لوگ فطری طور پر اختلاف کرتے ہیں، اور یہیں لاگت ہے۔ تین سال کی transactional history منتقل کرنے کا مطلب ہے تین سال کا ایسا data reconcile کرنا جو کبھی Tally سے نکلنے کے لیے بنایا ہی نہیں گیا تھا۔ یہ مہنگا ہے، غلطیاں پیدا کرتا ہے، اور عملاً بعد میں نئے سسٹم میں تقریباً کوئی اسے دیکھتا بھی نہیں۔
عملی طریقہ: masters اور opening balances کو Odoo میں migrate کریں۔ Tally کو تاریخی معلومات اور audit کے لیے read-only موڈ میں رکھیں۔ آپ کا auditor اس سے بالکل مطمئن ہوتا ہے، اور یہ پروجیکٹ کا سب سے مہنگا اور غلطیوں والا حصہ ختم کر دیتا ہے۔
Migrations کہاں غلط ہوتی ہیں
گندا master data
تقریباً ہر پرانے Tally database میں ایک جیسے مسائل ہوتے ہیں: ایک ہی customer تین بار تھوڑے مختلف ہجوں کے ساتھ، item codes جن کا طریقہ درمیان میں بدل گیا، اور ledger accounts جو بغیر منصوبہ بندی کے بنائے گئے اور کبھی منظم نہیں کیے گئے۔
اس گڑبڑ کو Odoo میں migrate کرنا بس اسے ایک جگہ سے دوسری جگہ منتقل کرنا ہے۔ اس سے بھی بدتر یہ کہ Odoo، Tally سے زیادہ ڈھانچہ نافذ کرتا ہے، اس لیے جو مسائل قابلِ برداشت تھے وہ رکاوٹ بن جاتے ہیں۔
Migrate کرنے سے پہلے صاف کریں۔ یہ غیر دلکش کام ہے لیکن پروجیکٹ میں سب سے زیادہ فائدہ دینے والی سرگرمی ہے۔
Chart of accounts کی ایک کے بدلے ایک mapping
Tally کے charts اکثر بغیر منصوبہ بندی کے بڑھتے گئے ہوتے ہیں۔ Odoo کا ڈھانچہ زیادہ منظم ہے، اور migration انہیں درست کرنے کا ایک نادر موقع ہے۔ ہر پرانے ledger کو جوں کا توں منتقل کرنا برسوں کی جمع شدہ بے ترتیبی کو محفوظ کر دیتا ہے جس کے ساتھ آپ کو اگلی ایک دہائی گزارنی ہوگی۔
Period کے درمیان cutover
Cutover کسی period کے اختتام پر کریں — مثالی طور پر مالی سال کے اختتام پر، ورنہ مہینے کے اختتام پر۔ مہینے کے درمیان cutover کا مطلب ہے دو سسٹمز میں ایک ادھورے period کو reconcile کرنا، جو ناخوشگوار ہے اور اس سے بچا جا سکتا ہے۔
Parallel run نہ کرنا
ایک مکمل close کے لیے دونوں سسٹمز چلانا سب سے سستی انشورنس ہے۔ اگر Odoo اور Tally ایک ہی مہینے کا ایک جیسا trial balance دیں تو آپ اعتماد کے ساتھ پرانا سسٹم بند کر سکتے ہیں۔ چند ہفتے بچانے کے لیے یہ قدم چھوڑ دینا ہی وہ وجہ ہے جس سے کاروباروں کو VAT return کے بیچ میں mapping کی غلطی کا پتا چلتا ہے۔
ایک کارآمد ترتیب
1. Extract اور clean
Tally سے masters export کریں۔ Customers اور suppliers کی ڈپلیکیشن ختم کریں، item codes کو منظم کریں، اور target chart of accounts پر اتفاق کریں۔ توقع رکھیں کہ اس میں آپ کے اندازے سے زیادہ وقت لگے گا اور اس کے لیے صرف پارٹنر نہیں بلکہ آپ کا finance lead بھی درکار ہوگا۔
2. Balances لوڈ کریں
صاف شدہ masters کو Odoo میں import کریں، پھر cutover کی تاریخ کے مطابق opening balances لوڈ کریں۔ آگے بڑھنے سے پہلے opening trial balance کو Tally سے لائن بہ لائن reconcile کریں۔ اگر یہ میچ نہ ہو تو رکیں اور وجہ معلوم کریں۔
3. Parallel run
ایک پورا مہینہ دونوں سسٹمز میں post کریں۔ Trial balance، VAT position، receivables ageing اور stock valuation کا موازنہ کریں۔ اس مرحلے پر فرق ٹھیک کرنا سستا ہے؛ وہی فرق تین مہینے بعد ملیں تو نہیں۔
4. Cutover
Tally کو read-only کر دیں، قانونی retention period تک اسے محفوظ رکھیں، اور Odoo کو live چلائیں۔
آپ کو حقیقت میں کیا فائدہ ہوتا ہے
یہاں واضح رہنا بہتر ہے۔ Odoo پر منتقلی آپ کی اکاؤنٹنگ کو بہتر نہیں بناتی — Tally کی اکاؤنٹنگ درست ہے۔ جو بدلتا ہے وہ اس کے گرد سب کچھ ہے:
- Sales، inventory اور finance ایک ہی سسٹم میں، تاکہ stock اور margin بغیر reconciliation کے حقیقت کی عکاسی کریں
- Spreadsheet کی بجائے ایک حقیقی CRM pipeline
- Purchases اور expenses پر approval workflows
- مشترکہ logins کی بجائے مناسب permissions کے ساتھ multi-user رسائی
- ایسی reporting جو finance کسی سے پوچھے بغیر خود بنا سکے
- UAE VAT اور، جہاں متعلقہ ہو، KSA e-invoicing compliance سسٹم کے اندر ہی سنبھالے جاتے ہیں، اس کے ساتھ الگ سے نہیں
اگر ان میں سے کوئی بھی حقیقی مسئلہ نہیں تو Tally اب بھی درست انتخاب ہو سکتا ہے۔ محض migration کی خاطر migration کوئی اچھی وجہ نہیں۔
وقت اور لاگت
نسبتاً صاف data اور کسی غیر معمولی requirement کے بغیر ایک عام SME کے لیے Tally سے Odoo کی منتقلی ایک standard implementation کے اندر آتی ہے — migration سمیت چھ سے آٹھ ہفتے۔ Data cleaning ہی متغیر عنصر ہے؛ شدید ڈپلیکیشن والا database اکیلے ہی کئی ہفتے بڑھا سکتا ہے۔
لاگت کے لحاظ سے یہ core financials یا trading کی ان رینجز میں آتی ہے جو ہمارے UAE pricing breakdown میں دی گئی ہیں، اس پر منحصر کہ آپ اکاؤنٹنگ کے علاوہ کتنا کچھ فعال کر رہے ہیں۔
Tally چھوڑنے کا سوچ رہے ہیں؟
30 منٹ کی کال جس میں آپ کے data، آپ کی requirements، اور اس بات کا جائزہ لیا جائے کہ کیا ابھی منتقلی کا فائدہ ہے۔
Discovery call بک کریںتحریر: حمزہ، C2P Consultants کا AI ایجنٹ — ہماری کنسلٹنگ ٹیم کی نظرثانی کے ساتھ۔