|
||
Axapta/Microsoft Dynamics AX short overview. Navision Axapta was designed by Navision Software, shortly before its acquisition by Microsoft Great Plains Business Solutions. Navision Software had tremendous success in Europe and partially in North America with Navision Attain. Some IT commentators believe that Microsoft purchased Navision Software because it had European clientele and Microsoft with its mid-market ERP Microsoft Great Plains was present in USA, Latin America, Canada, UK, South Africa, Australia and New Zealand only. If this is true – Axapta was kind of in the position to still proof itself – Navision Axapta was targeted to upper mid-market and probably in the time (2001/2002) Microsoft was not yet ready openly compete with high-end ERP brands, such as Oracle Financials, Oracle Applications, PeopleSoft, JDEdwards, SAP R/3. However since 2005 Axapta sees very high interest both in Western Europe/UK and USA among the Microsoft Business Solutions VARs. Plus – on emerging markets, such as Brazil, Russia, East Europe – Axapta has very good positions and “competes” with Navision – in the good meaning of this word – number of Axapta implementations in East Europe is comparable with the number of Navision implementations
• Modern Design. Axapta was designed by Navision Software at the very end of 20th and the beginning of 21st centuries. Regardless of how nice it could sound – Axapta has the most recent design among MBS ERP systems: Microsoft Dynamics GP/Great Plains Software Dynamics (beginning of 1990th – Great Plains Dexterity platform), Microsoft Navision – Navision Attain – Microsoft Dynamics Navision (middle of 1990th with C/SIDE, C/ODBC and other proprietary technologies)
• Object Oriented Design. This word itself might be slightly outdated – we should probably talk about multi-tiered functional application logic and the way to modify/customize it. Axapta designers analyzed and took into consideration a lot of issues they formerly had with Attain as well as general ERP/MRP development trends and directions. This is why Axapta/Dynamics AX has tremendous potential
• Localization. Here we are switching to Brazilian thematic. Brazilian localization has two sides: Brazilian tax code and Brazilian Portuguese language translation. Tax Engine localization was subcontracted to India and the beta testing was done by Brazilian Microsoft VARs: XPTA and Alba Spectrum. Screen translation was minor issue and should be considered as successful. Regarding Brazilian tax code localization details we would like you to read bright articles, written by Roberto Kowas, who demonstrated Axapta tax localization in Sao Paulo to MBS partners in December 2005.
• Customization, Integration, Reporting. MorphX with X++ programming language. From the integration and report writing standpoints we could expect Microsoft move with Visual Studio.net and Microsoft SQL Server Reporting Services. You probably know that currently Microsoft is implementing so-called Project Green, now Microsoft Dynamics project, aiming in synchronization and possible future modulation of all Microsoft ERP/CRM products: Microsoft Dynamics GP, Microsoft Dynamics NAV, Microsoft Dynamics AX, Microsoft Dynamics SL, Microsoft Dynamics CRM
The table design/architecture of Microsoft Dynamics GP, as we write the current version is Microsoft Great Plains 9.0, was done back in 1990th by Great Plains Software and what we are discussing here is applicable to the majority of Great Plains Dynamics / eEnterprise versions for MS SQL Server: 5.0, 5.5, 6.0, 7.0, 7.5, 8.0 and now 9.0. With so-called ‘Project Green' Microsoft is enabling Microsoft Dynamics GP objects for Visual Studio C# or VB.Net developer via web services interface, while the middle-level set of stored procedures is known as eConnect. However you can still use old-good-way of creating your own set of stored procedures to feed in or pull data from Microsoft Great Plains 9.0 databases. If you are new to the subject – please be aware that you are not allowed to make a change to existing Great Plains tables – the reason is – Great Plains Dexterity (now referred as Microsoft Dexterity) uses DYNAMICS.DIC as metadictionary, where all the tables are described and if you make a change to the table – it will conflict with what table is known in DYNAMICS.DIC.
• SOP, Sales Order Processing module. This is usually where all eCommerce developers start – you need to move the order from your e-Commerce application to Microsoft Dynamics GP SOP tables. Here the advice is – if you can't afford eConnect – create Sales Order and Quote only (do not create Invoice). These documents do not require GL account distribution. Here are your tables: SOP10100 – SOP Header and SOP10200 – SOP work table. Another advice is – have your Great Plains guru setup special SOP Order type, where it doesn't allocate inventory items on the fly. This second advice is not relevant if you are selling services and they are not tracked in inventory module.
• Inventory Control. If you deal with so-called inventoried items (sales items, where you track quantities on-hand/allocated/committed by inventory site and across the company). Inventory tables are IV00101 – Item master and IV00102 – item QTY master table. Usually you have to deal with these two tables only, however in complex cases you can go deeper – our recommendation to purchase eConnect licenses if your logic in Inventory module is more complex
• Receivables Management. From this module you just need customer record: RM00101 – Customer master and RM00102 – Customer Address Master
• Payable Management. This usually goes beyond eCommerce sales process. In some cases you want to trigger purchasing side of it. If you know Vendor/Item association, take Vendor Master file: PM00200 and then if needed – but this is too complicated without eConnect – work with Purchase Order Processing module
• Distribution Analyzing technique. Ask your GP operators to enter typical transaction and watch how it is distributed in SOP tables.
• Posting process. This is usually the duty of the GP end user and in order to do posting – you have to go over the borders of eConnect limitations – eConnect creates Work documents as a rule