نحوه ارتقا erp مایکروسافت داینامیکس 2009 و 2012 به داینامیکس 365
در این مقاله به نحوه ارتقا erp مایکروسافت داینامیکس 2009 و 2012 به داینامیکس 365 به لحاظ نکات فنی میپردازیم .
چنانچه قصد ارتقاء ERP سازمان خود را دارید و نکات یا ابهاماتی در این زمینه دارید با ما تماس بگیرید.
مزایای ارتقا سیستم :
ارتقاء از Microsoft Dynamics AX2009 یا AX2012 به D365 Finance & Operation دارای مزایای زیادی میباشد. از قبیل :
- دسترسی بیشتر
- کاهش هزینه ها
- عملکردهای بیشتر
- انعطاف پذیری بهبود یافته
- گزارشات تحلیلی از پیش ساخته برای افزایش کارایی (Power BI)
- افزایش امنیت
- سازگاری
طبیعی است که همه نسخه های Microsoft Dynamics AX مثل هم نیستند .
اگر قصد دارید سیستم ERP خود را به Microsoft Dynamics 365 finance & operation ارتقاء دهید، فرآیندهای انتقال کد و داده ها نیز متفاوت خواهد بود.
برای ارتقاء از AX 2009 به Dynamics 365 سه گزینه وجود دارد:
1. پیاده سازی مجدد در D365 :
در این روش با استفاده از ابزارهای موجود در بازار، یک مهاجرت معمولی از AX 2009 به D365 انجام میشود. برای توضیح بیشتر میتوان گفت که: برنامه فعلی Dynamics AX 2009 شما احتمالاً دارای بسیاری از تغییرات قدیمی است .
تعداد زیادی ویژگی استاندارد در نسخه جدید(D365) اضافه شده است. به این دلیل اکثر تغییرات قدیمی شما که در AX 2009 اعمال کرده بودید، دیگر در Dynamics 365 مورد نیاز نیستند.
از طرف دیگر، احتمالاً کسب و کار شما در بیش از 10 سال گذشته دچار تغییرات زیادی در فرآیندهای تجاری اش شده است .
شاید شما با مدیریت راه حل های ISV شخص ثالث پشتیبانی نشده برای Dynamics AX مشکل دارید.
به همه این دلایل، رویکرد پیادهسازی مجدد Dynamics اغلب نقطه شروع طبیعی خواهد بود.
2. مهاجرت به D365
شرکت مایکروسافت، ابزاری تحت عنوان Dynamics AX 2009 Data migration tool (DMT) را برای انتقال داده ها از AX 2009 به D365 ارائه کرده است .
با استفاده از آن میتوان فقط داده ها را ابتدا با ساختار دیتابیسی جدید D365 شبیه سازی کرد .
سپس به داخل D365 نصب شده ایمپورت کرد. در این روش کدها انتقال داده نمیشود و فرض گرفته میشود که نیازی به کدهای قدیمی نیست.
این ابزار به شما کمک می کند تا در نحوه ارتقا erp مایکروسافت داینامیکس 2009 و 2012 به داینامیکس 365 شکاف های بین جداول AX 2009 و Dynamics 365 Finance & Operations را پیدا کرده و پر کنید.
ولی باید توجه داشته باشید که ابزارهای Dynamics AX 2009 DMT تراکنشهای دفتر کل AX 2009 یا تراکنشهای مشتری/فروشنده شما را مستقیماً منتقل نمیکنند و میتوان گفت انتقال فقط شامل جداول اطلاعات پایه (Master Data) میباشد.
دیتاهایی که میتوانید منتقل کنید شامل موارد زیر میباشد:
- پیکربندی و راه اندازی دفتر کل، گروه های مشتریان، گروه های فروشنده و غیره.
- اطلاعات پایه مشتریان، فروشندگان، پروژه ها، حساب ها و غیره.
- موجودی از دفتر کل، سهام، قیمت و غیره.
- مستندات باز مثل فاکتورهای باز یا معلق، سفارشات فروش و خرید و غیره.
- تنظیمات سیستم مثل توالی اعداد(Number sequence)، کاربران، گروه های کاربری، امنیت و غیره
- هر چیزی که به عنوان موجودیت نشان داده شود (denormalized views). فیلدها/جدول های سفارشی سازی شده
- موجودیتهایی که امکان برقراری ارتباط با محیط اطراف را فراهم میکنند.
در مجموع اگر میزان سفارشیسازیها، دادههای اصلی و فاکتورهای معلق شما در Ax 2009 زیاد است، معمولاً این مسیر به شما توصیه میشود.
به طور کلی میتوان گفت هیچ ابزار کامل و جامعی برای انتقال کدها و تمام داده ها از AX 2009 به D365 وجود ندارد.
3. ارتقاء دو مرحله ای به D365
در برخی از سناریوهای ارتقاء D365 و به صورت خیلی نادر، ممکن است بتوان رویکرد ارتقاء دوگانه Dynamics را برای Dynamics AX2009 – Microsoft Dynamics 365 در نظر گرفت.
اگر کسب و کار شما به کد و اطلاعات شما به طور کامل نیاز دارد، سازمان شما می تواند ارتقاء دو مرحله ای را در نظر بگیرد که عبارت است از ابتدا ارتقاء از AX 2009 به Ax 2012 R3 و سپس ارتقاء از AX 2012 R3 به D365. این رویکرد می تواند مجموعه بالقوه کامل تری از کد و داده را در اختیار شما قرار دهد.
نمودار زیر فرآیند ارتقاء از AX 2009 به D365 را به صورت شماتیک توضیح میدهد:
ارتقاء کد (Code Upgrade):
برای عملیات ارتقاء کد، مایکروسافت یک عملکرد جدید برای ارتقاء کد منبع AX2012 شما به کد منبع Dynamics 365 از طریق LCS با کمک فایل Model Store منتشر کرده است. ما همیشه باید از AX2009 به AX 2012 ارتقا دهیم زیرا LCS از فایل aod. که فایلهای Model Store در AX2009 هستند را پشتیبانی نمی کند بنابراین لازم است تا فایلهای .aod را به فایلهای .axmodelstore تبدیل کنیم.
در اینجا به دو نکته باید توجه شود:
اول اینکه اگر شما تعداد کدهای سفارشی سازی شده کم و یا با حجم مختصری دارید، میتوانید به جای انتقال، آنها را بازنویسی کنید.
خیلی چیزها در طول زمان تغییر کرده است. AX2009 با داشتن حدود 2700 جدول به یک برنامه بزرگ به نام AX2012 تبدیل شده است که تقریباً 8000 جدول دارد و بررسی های عملکردی و نقشه برداری فرآیندهای تجاری زیادی در آن انجام شده است. به عنوان مثال: Item به Products و Items تبدیل شده، warehousing به میان آمده ، Financial dimension هایی که تعدادشون محدود بود حالا به صورت بدون محدودیت قابل تعریف هستند، گزارشات MorphX به گزارشات SSRS تبدیل شده اند و چهارچوب آدرس تغییر پیدا کرده است.
بنابراین پیشنهاد ما به شما این است که در زمان ارتقاء از AX 2009 به AX2012، تک تک تغییرات فریم ورک را دوباره پیاده سازی کنید تا برای ارتقاء به D365 دچار مشکل نشوید.
ما در تجربیات قبلی خود،مستقیماً ارتقاء از AX2009 به Dynamics 365 را طی فرآیند دو مرحلهای و بدون اجرای مجدد تغییرات چارچوب در AX2012 انجام دادیم، بنابراین قبل از اینکه انتقال کد را شروع کنیم، به وضوح چیزهایی را که برای تکمیل یک انتقال کد موفق نیاز داشتیم، کشف کردیم که با شما در میان میگذاریم:
· محیط توسعه:
لطفاً یک محیط AX2009 را که یک کپی دقیق از محیط عملیاتی است نگه دارید تا توسعه دهندگان بتوانند مستقیماً عملکرد کد منبع را در محیط بررسی کنند.
· پوشش شکاف ها:
وقتی که شما مکانیزم OverLayering را به Extension در D365 تبدیل کنید، عملکردها هرگز همانطور که در AX2009 انتظار داشتید کار نمی کنند، چون بسیاری از مصنوعات و ویژگی های استاندارد تغییر کرده اند، بنابراین بهتر است عملکرد پایه را درک کرده و آن را مطابق با Dynamics365 توسعه دهید.
برای مثال، اگر شما یک سفارشی سازی در یکی از روش های استاندارد در AX2009 داشته باشید، گاهی اوقات ممکن است همان روش استاندارد را در D365 پیدا نکنید. دلایل مختلفی برای منسوخ شدن این روش استاندارد وجود داشته باشد، مثلا شاید در هیچ قسمتی از سیستم استفاده نشود یا شاید در متد دیگری پیاده سازی شده باشد.
در این سناریو ابتدا باید منطق کسب و کار را در AX2009 درک کنیم و سعی کنیم همان را در D365 با استفاده از مکانیزم Extension توسعه دهیم.
· ویژگی های منسوخ شده:
سعی کنید فرآیندهای جایگزین را برای ویژگی های منسوخ شده AX2009 شناسایی کنید. اگر این ویژگی های منسوخ شده خیلی برای کسب و کار شما حیاتی بوده اند، سعی کنید قبل از Go-Live شدن D365 با فرآیندهای جایگزین به خوبی کار کرده و به آنها عادت کنید.
شما میتوانید از امکان cross references در AX2009 برای یافتن مکانهای استفاده از یک artifact استفاده کنید و همزمان همان مکانها را در محیط D365 بررسی کنید تا بتوانید Artifact جایگزین را پیدا کنید.
· Extension framework:
مهاجرت از رویکرد Overlayering به Extension کار خیلی سخت و بزرگی نیست ولی نکاتی دارد که باید مورد توجه قرار گیرد:
- حل کردن تمام مشکلات و تناقضات:هنگامی که فرآیند دو مرحله ای را بدون اجرای مجدد تغییرات چارچوب در AX2012 دنبال می کنید، در اشیاء استاندارد با تضادهای زیادی روبرو خواهید شد.
لطفاً روند زیر را برای حل تضادها دنبال کنید:
- در پنل جستجو کلمه cf را تایپ کنید تا تمام تضادها یا conflict ها را شناسایی کنید:
- روی تضاد پیدا شده راست-کلیک کرده و گزینه Resolve Code Conflict را انتخاب کنید.
- سفارشی سازی مورد نیاز را از قسمت سمت راست انتخاب کنید و با قسمت پایین بررسی کنید تا کد استاندارد و سفارشی سازی به شیوه ای مناسب ادغام شوند و در نهایت روی گزینه پذیرش ادغام(Accept merge) همانطور که در تصویر برجسته شده است کلیک کنید.
- ایجاد پکیج مستقل:
هنگامی که شما از AX2012 به D365 ارتقا می دهید. تمام مصنوعات سفارشی از طریق مدل جدید در بسته Application Suite موجود است .
سفارشی سازی در مصنوعات(Artifact) استاندارد در مدل هایی مانند Application Platform، Directory، Application Suite نیز وجود خواهد داشت.
بنابراین، ممکن است ندانیم در حالی که یک ساخت کامل (Full Complie) را انجام میدهیم با چند خطا مواجه میشویم. بهتر است این کار را انجام دهیم و ساخت کامل را انجام دهیم تا بفهمیم با چه تعداد خطا در کل مدلها مواجه میشویم.
پس از یافتن خطاها، سعی کنید هر خطا را یکی یکی برطرف کنید . در نهایت هدف نهایی ما این است که همه مدل ها را با موفقیت کامپایل کنیم.
اکنون یک کامپایل موفقیتآمیز انجام شده است . حال میتوانیم یک بسته مستقل ایجاد کنیم که از Extension ها و مصنوعات(Artifact) سفارشی تشکیل شده است.
- ناسازگاری Model reference: تمام مصنوعات سفارشی را به مدل تازه ایجاد شده منتقل کنید و مدل را کامپایل کنید، به دلیل ارجاعات مدل با خطاهای زیادی مواجه خواهید شد. مدل جدید ایجاد شده خود را با پارامترهای مدل در منوی Dynamics 365 به روز کنید و مدل های مناسب را برای ارجاع انتخاب کنید.
اکنون با استفاده از رویکرد ترجیحی مایکروسافت، تمام Overlayering را به Extension تبدیل کرده و سعی کنید مدل را با موفقیت کامپایل کنید.