Odoo 17 سے Odoo 18 کی طرف ہجرت: کیا تبدیلیاں آتی ہیں، کیا ٹوٹتی ہے، اور تیاری کیسے کی جاتی ہے

Odoo ہر سال ایک بڑا ورژن جاری کرتا ہے، اور ہر اپ گریڈ نئی خصوصیات، کارکردگی میں بہتری، اور لامحالہ، بریکنگ تبدیلیاں لاتا ہے۔ Odoo 17 سے Odoo 18 میں منتقلی کے لیے محتاط منصوبہ بندی کی ضرورت ہے، خاص طور پر اگر آپ اپنی مرضی کے ماڈیول چلاتے ہیں یا کمیونٹی ایڈ آنز پر انحصار کرتے ہیں۔ یہ گائیڈ ہر چیز کا احاطہ کرتا ہے جو آپ کو Odoo 17 سے 18 کی منتقلی کے بارے میں جاننے کی ضرورت ہے: اہم تبدیلیاں، ممکنہ ٹوٹ پھوٹ، تیاری کے اقدامات، اور جانچ کی حکمت عملی۔

کیوں اوڈو 18 میں اپ گریڈ کریں؟

Odoo 18 پورے پلیٹ فارم میں نمایاں بہتری متعارف کراتا ہے:

• نئے OWL 3 اجزاء: بہتر کارکردگی اور ڈویلپر کے تجربے کے ساتھ دوبارہ لکھے گئے فرنٹ اینڈ اجزاء
• AI سے چلنے والی خصوصیات: پیشن گوئی لیڈ اسکورنگ، سمارٹ بینک مصالحتی تجاویز، اور AI کی مدد سے مواد کی تخلیق
• اسپریڈشیٹ میں بہتری: ریئل ٹائم Odoo ڈیٹا، پیوٹ ٹیبلز، اور باہمی تعاون کے ساتھ ترمیم کے ساتھ مقامی اسپریڈشیٹ انضمام
• مینوفیکچرنگ اپ گریڈ: بہتر پروڈکشن شیڈولنگ، سب کنٹریکٹنگ پورٹل، اور شاپ فلور ٹیبلٹ انٹرفیس
• کارکردگی: آپٹمائزڈ اثاثہ بنڈلنگ اور سست لوڈنگ کے ذریعے صفحہ 15-25% تیزی سے لوڈ ہوتا ہے
• ویب سائٹ بنانے والا: نئے ڈریگ اینڈ ڈراپ بلاکس، تھیم کی تخصیص کے اختیارات، اور بہتر موبائل ایڈیٹنگ

پرانے ورژنز پر رہنے کا مطلب ہے سیکیورٹی پیچ غائب ہونا، کمیونٹی ماڈیول اپ ڈیٹس تک رسائی کھو دینا، اور تکنیکی قرض جمع کرنا جو مستقبل کی منتقلی کو مشکل بناتا ہے۔

ٹائم لائن: اوڈو ہجرت میں کتنا وقت لگتا ہے؟

| پیچیدگی | اپنی مرضی کے ماڈیولز | تخمینی ٹائم لائن | |---|---|---| | معیاری (کوئی کسٹم کوڈ نہیں) | 0 | 1-2 ہفتے | | کم (کچھ حسب ضرورت فیلڈز/ویوز) | 1-5 | 2-4 ہفتے | | میڈیم (اپنی مرضی کے مطابق ورک فلوز) | 5-15 | 4-8 ہفتے | | اعلی (گہری تخصیصات) | 15+ | 8-16 ہفتے |

ان ٹائم لائنز میں تجزیہ، منتقلی، ٹیسٹنگ، اور گو لائیو شامل ہیں۔ سب سے بڑا متغیر کسٹم ماڈیول کی پیچیدگی ہے۔

اوڈو 18 میں بریکنگ تبدیلیاں

OWL فریم ورک میں تبدیلیاں

Odoo 18 OWL 3 میں منتقلی جاری رکھتا ہے۔ اگر آپ کے کسٹم ماڈیولز میں فرنٹ اینڈ جاوا اسکرپٹ کے اجزاء شامل ہیں، تو ان تبدیلیوں کی توقع کریں:

اہم OWL تبدیلیاں:

• جز کا لائف سائیکل: willStart اور willUpdateProps کو setup() اور onWillStart ہکس سے بدل دیا گیا ہے۔
• ٹیمپلیٹ کمپلیشن: QWeb ٹیمپلیٹس اب رن ٹائم کے بجائے بلڈ ٹائم پر آپٹمائزڈ جاوا اسکرپٹ پر مرتب کرتے ہیں۔
• سروس انجیکشن: خصوصی طور پر this.env.services پیٹرن کے ذریعے خدمات تک رسائی حاصل کریں۔ براہ راست درآمدات فرسودہ ہیں۔
• اثاثہ بنڈل: web.assets_backend بنڈل کا ڈھانچہ بدل گیا ہے۔ اپنے __manifest__.py اثاثوں کے اعلانات کو اپ ڈیٹ کریں۔

مثلا نقل مکانی:

// Odoo 17
class MyComponent extends Component {
    async willStart() {
        this.data = await this.rpc('/my/endpoint');
    }
}

// Odoo 18
class MyComponent extends Component {
    setup() {
        onWillStart(async () => {
            this.data = await this.env.services.rpc('/my/endpoint');
        });
    }
}

ازگر کے پس منظر میں تبدیلیاں

ماڈل اور فیلڈ تبدیلیاں:

• fields.Monetary کو اب currency_field کو واضح طور پر اعلان کرنے کی ضرورت ہے (اب currency_id پر ڈیفالٹ نہیں ہے)
• @api.multi ڈیکوریٹر کو مکمل طور پر ہٹا دیا گیا تھا (v13 سے فرسودہ، لیکن کچھ کمیونٹی ماڈیولز نے اسے اب بھی استعمال کیا ہے)
• sudo() رویے میں تبدیلی: sudo() بغیر دلائل کے اب واضح طور پر OdooBOT صارف کے بجائے SUPERUSER کا استعمال کرتا ہے
• search_count() اب کارکردگی کی اصلاح کے لیے ایک اختیاری limit پیرامیٹر قبول کرتا ہے۔

اپ ڈیٹ کرنے کے فرسودہ طریقے:

| فرسودہ (v17) | تبدیلی (v18) | |---|---| | fields.Many2one.search() | fields.Many2one کے ساتھ domain وصف | | _register_hook() | _post_init_hook مینی فیسٹ میں | | ماڈلز میں براہ راست SQL | self.env.cr.execute() مناسب پیرامیٹرائزیشن کے ساتھ | | website.published فیلڈ | website.is_published (نام تبدیل کر دیا گیا) |

دیکھیں اور ٹیمپلیٹ تبدیلیاں

• فارم ویو: sheet ریپر اب تمام فارم ویوز کے لیے لازمی ہے (پہلے اختیاری)
• فہرست کا منظر: tree ٹیگ کا نام باضابطہ طور پر list رکھ دیا گیا ہے (پیچھے کی طرف مطابقت پذیر عرف اب بھی کام کرتا ہے لیکن فرسودگی کی وارننگز کو متحرک کرتا ہے)
• کانبان منظر: QWeb t-esc اب پہلے سے طے شدہ ہے۔ t-raw کو سیکورٹی کے لیے واضح آپٹ ان کی ضرورت ہے۔
• رپورٹ QWeb: پی ڈی ایف رینڈرنگ انجن کو اپ ڈیٹ کیا گیا؛ لے آؤٹ تبدیلیوں کے لیے تمام پرنٹ شدہ رپورٹس کی جانچ کریں۔

ڈیٹا بیس اسکیما تبدیلیاں

Odoo 18 میں بنیادی جدولوں میں ساختی تبدیلیاں شامل ہیں:

• sale.order.line سبسکرپشن مینجمنٹ کے لیے نئے فیلڈز حاصل کرتا ہے۔
• account.move.line میں مفاہمت سے متعلق نئے کالم شامل ہیں۔
• stock.quant جدول کو بڑی انوینٹریوں کے ساتھ بہتر کارکردگی کے لیے دوبارہ ترتیب دیا گیا۔
• mail.message اور mail.activity جدولوں کو نئے اشاریہ جات کے ساتھ بہتر بنایا گیا ہے۔

یہ سکیما تبدیلیاں معیاری ماڈیولز کے لیے Odoo کے بلٹ ان مائیگریشن اسکرپٹس کے ذریعے ہینڈل کی جاتی ہیں، لیکن ان جدولوں کا حوالہ دینے والے حسب ضرورت ماڈیولز کو دستی اپ ڈیٹس کی ضرورت ہوتی ہے۔

ہجرت سے پہلے کی تیاری کی فہرست

1. اپنی موجودہ تنصیب کا آڈٹ کریں۔

شروع کرنے سے پہلے ہر چیز کو دستاویز کریں:

• [ ] تمام انسٹال کردہ ماڈیولز کی فہرست بنائیں (آفیشل، کمیونٹی، اور کسٹم)
• [ ] موجودہ اوڈو ورژن اور پیچ کی سطح کو ریکارڈ کریں۔
• [ ] تمام حسب ضرورت پیش رفتوں کو دستاویز کریں (فیلڈز، ماڈلز، آراء، رپورٹس، شیڈول کردہ اعمال)
• [ ] تمام بیرونی انضمام کی فہرست بنائیں (ادائیگی کے گیٹ ویز، شپنگ کیریئرز، تھرڈ پارٹی APIs)
• موجودہ رسائی کے حقوق اور ریکارڈ قوانین کی ترتیب کو برآمد کریں۔
• [ ] پروڈکشن ڈیٹا بیس اور فائل اسٹور کو مکمل طور پر بیک اپ کریں۔

2. کمیونٹی ماڈیول کی مطابقت کو چیک کریں۔

ہر کمیونٹی (او سی اے یا تھرڈ پارٹی) ماڈیول کے لیے:

• چیک کریں کہ آیا GitHub یا Odoo Apps اسٹور پر Odoo 18 کے موافق ورژن موجود ہے
• اگر کوئی مطابقت پذیر ورژن موجود نہیں ہے، تو فیصلہ کریں کہ ماڈیول کو خود پورٹ کرنا ہے، متبادل تلاش کرنا ہے، یا فعالیت کو ہٹانا ہے۔
• v18 بندرگاہوں پر ETA کے لیے ماڈیول مینٹینرز سے رابطہ کریں۔

3. کسٹم ماڈیول پورٹس تیار کریں۔

ہر حسب ضرورت ماڈیول کے لیے، منتقلی کی کوشش کا اندازہ لگائیں:

کم کوشش (1-3 دن فی ماڈیول):

• صرف نئے فیلڈز اور سادہ نظارے والے ماڈیولز
• جاوا اسکرپٹ/OWL اجزاء نہیں ہیں۔
• تبدیل شدہ بنیادی طریقوں کی کوئی اوور رائیڈ نہیں ہے۔

درمیانی کوشش (3-10 دن فی ماڈیول):

• OWL اجزاء کے ساتھ ماڈیولز جن میں اپ ڈیٹ کی ضرورت ہوتی ہے۔
• فرسودہ یا تبدیل شدہ بنیادی طریقوں کی اوور رائیڈز
• اپنی مرضی کے مطابق رپورٹس کو QWeb اپ ڈیٹس کی ضرورت ہے۔

زیادہ کوشش (10+ دن فی ماڈیول):

• تبدیل شدہ بنیادی ماڈیولز کے ساتھ گہرا انضمام (اکاؤنٹنگ، انوینٹری، ویب سائٹ)
• پیچیدہ OWL فرنٹ اینڈ ایپلی کیشنز
• بڑے پیمانے پر فرسودہ یا ہٹائے گئے APIs کا استعمال کرنے والے ماڈیولز

تجربہ کار اوڈو مائیگریشن ماہرین کے ساتھ کام کرنے سے حسب ضرورت ماڈیولز کو پورٹ کرنے کے وقت اور خطرے کو نمایاں طور پر کم کیا جاتا ہے۔

ہجرت کے عمل کے مراحل

مرحلہ 1: ہجرت کا ماحول ترتیب دیں۔

Production (v17) ──backup──> Test Database (v17)
                                    │
                              Upgrade to v18
                                    │
                              Test Database (v18)
                                    │
                              Validation & UAT
                                    │
                              Production (v18)

اس کے ساتھ الگ تھلگ ماحول بنائیں:

• ایک تازہ Odoo 18 سرور کی تنصیب
• آپ کے پروڈکشن ڈیٹا بیس کی ایک کاپی
• تمام کسٹم ماڈیولز v18 پر پورٹ کیے گئے۔

مرحلہ 2: ڈیٹا بیس اپ گریڈ کو چلائیں۔

Odoo انٹرپرائز کے لیے: upgrade.odoo.com پر Odoo کی آفیشل اپ گریڈ سروس استعمال کریں۔ اپنا ڈیٹا بیس اپ لوڈ کریں، اور Odoo SA تمام معیاری ماڈیولز کے لیے مائیگریشن اسکرپٹس چلاتا ہے۔

Odoo کمیونٹی کے لیے: OCA کے ذریعے openupgrade پروجیکٹ استعمال کریں۔ OpenUpgrade معیاری ماڈیولز کے لیے کمیونٹی کے زیر انتظام مائیگریشن اسکرپٹ فراہم کرتا ہے:

1. ہدف والے ورژن کے لیے اوپن اپ گریڈ انسٹال کریں۔
2. اپنے ٹیسٹ ڈیٹا بیس کے خلاف منتقلی چلائیں۔
3. غلطیوں اور انتباہات کے لیے مائیگریشن لاگ کا جائزہ لیں۔
4. کسی بھی مسئلے کو حل کریں اور صاف ہونے تک دوبارہ چلائیں۔

مرحلہ 3: پورٹ کسٹم ماڈیولز

ہر کسٹم ماڈیول کے لیے:

1. __manifest__.py ورژن کو 18.0.x.x.x میں اپ ڈیٹ کریں
2. Python کوڈ کو درست کریں (فرسودہ APIs، تبدیل شدہ طریقہ کے دستخط)
3. JavaScript/OWL اجزاء کو v3 پیٹرن میں اپ ڈیٹ کریں۔
4. XML ویوز کو درست کریں (درخت ٹو لسٹ، شیٹ ریپر، ٹیمپلیٹ تبدیلیاں)
5. ماڈیول کے ٹیسٹ سوٹ کو چلائیں اور ناکامیوں کو ٹھیک کریں۔
6. اسٹیجنگ ماحول میں دستی طور پر ٹیسٹ کریں۔

مرحلہ 4: ڈیٹا کی تصدیق

منتقلی کے بعد، ڈیٹا کی سالمیت کی تصدیق کریں:

• اکاؤنٹنگ: v17 اور v18 کے درمیان ٹرائل بیلنس کا موازنہ کریں۔ انہیں بالکل مماثل ہونا چاہئے۔
• انوینٹری: زیادہ قیمت والی مصنوعات کے نمونے کے لیے اسٹاک کی مقدار کی تصدیق کریں۔
• فروخت/خریداری: کھلے آرڈرز اور ان کے اسٹیٹس کو درست طریقے سے انجام دینے کی تصدیق کریں۔
• رابطے: چیک کریں کہ گاہک اور وینڈر کا ریکارڈ برقرار ہے، بشمول پتے اور بینک کی تفصیلات۔
• منسلکات: تصدیق کریں کہ دستاویزات، تصاویر اور فائل منسلکات قابل رسائی ہیں۔

جانچ کی حکمت عملی

لیول 1: خودکار ٹیسٹ

ہر نصب شدہ ماڈیول کے لیے مکمل ٹیسٹ سویٹ چلائیں۔ آگے بڑھنے سے پہلے تمام ناکامیوں کو درست کریں۔

لیول 2: فنکشنل ٹیسٹنگ

بنیادی کاروباری ورک فلو کی جانچ آخر سے آخر تک:

• ایک کوٹیشن بنائیں، اس کی تصدیق کریں، سامان فراہم کریں، انوائس بنائیں، ادائیگی رجسٹر کریں۔
• رسید اور وینڈر بل کے ذریعے خریداری کے آرڈر پر کارروائی کریں۔
• BOM سے تیار مصنوعات تک مینوفیکچرنگ آرڈر چلائیں۔
• ایک مکمل بینک مفاہمت کا دور مکمل کریں۔
• اہم مالیاتی رپورٹس بنائیں اور ان کی تصدیق کریں۔

سطح 3: صارف کی قبولیت کی جانچ (UAT)

ہر شعبہ کے حقیقی صارفین کو 5-10 کاروباری دنوں کے لیے اسٹیجنگ ماحول میں اپنے روزمرہ کے کام انجام دینے کو کہیں۔ مشترکہ اسپریڈشیٹ یا پروجیکٹ مینجمنٹ ٹول میں مسائل کو ٹریک کریں۔

سطح 4: کارکردگی کی جانچ

صفحہ لوڈ ہونے کے اوقات، رپورٹ جنریشن کی رفتار، اور v17 اور v18 کے درمیان پروڈکشن لیول ڈیٹا والیوم کے ساتھ تلاش کی کارکردگی کا موازنہ کریں۔

گو لائیو حکمت عملی

تجویز کردہ طریقہ: ویک اینڈ کی منتقلی

1. جمعہ کی شام: حتمی پروڈکشن بیک اپ لیں۔ تمام لین دین کو منجمد کریں۔
2. ہفتہ: پروڈکشن ڈیٹا بیس پر اپ گریڈ چلائیں۔ آخری منٹ کے کسی بھی ڈیٹا کو پورٹ کریں۔
3. اتوار: ڈیٹا کی مکمل تصدیق اور دھوئیں کی جانچ۔ پروڈکشن سرورز پر تعینات کریں۔
4. پیر کی صبح: لائیو جائیں۔ پہلے 48 گھنٹوں کے لیے قریب سے نگرانی کریں۔

ایک رول بیک پلان تیار رکھیں: v17 ڈیٹا بیس کا بیک اپ اور سرور کنفیگریشن دستیاب رکھیں تاکہ آپ چند گھنٹوں کے اندر اندر واپس جا سکیں اگر اہم مسائل سامنے آئیں۔

اکثر پوچھے گئے سوالات

س: کیا میں ورژن چھوڑ سکتا ہوں اور Odoo 16 سے Odoo 18 میں براہ راست منتقل ہو سکتا ہوں؟ ہاں، لیکن یہ زیادہ پیچیدہ ہے۔ ہر ورژن کی اپنی مائیگریشن اسکرپٹس ہوتی ہیں، اور ورژن کو چھوڑنا تبدیلیوں کو اکٹھا کرتا ہے۔ اوڈو کی اپ گریڈ سروس ملٹی ورژن جمپس کو ہینڈل کرتی ہے، لیکن کسٹم ماڈیول پورٹنگ کے لیے ہر چھوڑے گئے ورژن سے بریکنگ تبدیلیوں کو ایڈریس کرنے کی ضرورت ہوتی ہے۔ ملٹی ورژن کی منتقلی کے لیے بجٹ میں 50-100% زیادہ وقت۔

س: کیا ہجرت کے دوران میری حسب ضرورت رپورٹس ٹوٹ جائیں گی؟ ممکنہ طور پر۔ QWeb رپورٹ ٹیمپلیٹس اپ ڈیٹ شدہ ڈیٹا ڈھانچے اور رینڈرنگ انجن میں بہتری کی وجہ سے ورژن کے درمیان اکثر تبدیل ہوتے رہتے ہیں۔ منتقلی کے بعد ہر چھپی ہوئی رپورٹ (انوائسز، ڈلیوری سلپس، خریداری کے آرڈر) کی جانچ کریں اور ضرورت کے مطابق ٹیمپلیٹس کو ایڈجسٹ کریں۔

س: کیا مجھے ہجرت کرنی چاہیے یا نیا آغاز کرنا چاہیے؟ اگر آپ کے پاس سالوں کا تاریخی ڈیٹا، پیچیدہ کنفیگریشنز، اور تربیت یافتہ صارفین ہیں تو ہجرت کریں۔ اگر آپ کی موجودہ انسٹالیشن بہت زیادہ مرمت کے علاوہ اپنی مرضی کے مطابق بنائی گئی ہے، اس میں ڈیٹا کوالٹی کے اہم مسائل ہیں، یا اگر آپ کے کاروباری عمل اس قدر بدل گئے ہیں کہ دوبارہ ترتیب زیادہ تیز ہو جائے گی۔ زیادہ تر کاروبار اپنی آپریشنل تاریخ کو محفوظ رکھنے کے لیے ہجرت کا انتخاب کرتے ہیں۔ ایک Odoo کنسلٹنسی پارٹنر سے مشورہ کریں اس بات کا اندازہ کرنے کے لیے کہ کون سا نقطہ نظر آپ کے حالات کے مطابق ہے۔

پیشہ ورانہ مائیگریشن سپورٹ

Odoo ورژن کے درمیان منتقلی ایک تکنیکی منصوبہ ہے جو تجربہ کار ہاتھوں سے فائدہ اٹھاتا ہے۔ ECOSIRE کی Odoo مائیگریشن سروسز مکمل عمل کا احاطہ کرتی ہے: پری مائیگریشن آڈٹ، کسٹم ماڈیول پورٹنگ، ڈیٹا کی منتقلی، ٹیسٹنگ، اور گو لائیو سپورٹ۔

ہماری ٹیم سے رابطہ کریں آپ کی مخصوص Odoo تنصیب کی بنیاد پر منتقلی کی تشخیص اور ٹائم لائن تخمینہ کے لیے۔ ہم ایک درست دائرہ کار اور بجٹ فراہم کرنے کے لیے آپ کے ماڈیولز، تخصیصات، اور ڈیٹا کی پیچیدگی کا تجزیہ کریں گے۔