![]() |
#1 |
Участник
|
A question was asked recently, that in summary, went something like this:
Where is the "cut-off" between NAV (Microsoft Dynamics Navision) and AX (Microsoft Dynamics Axapta)? Why do business chose one over the other, and essentially, stripping away the Microsoft-speak, what are the differences between the two products? Whilst I could not answer the question directly posed in the forum (http://dynamicsuser.net/forums/p/218...55.aspx#106955) I felt I was at least in a unique position to comment. In June 2007 I left a NAV reseller after 8 years worth of NAV Implementation, support, development and anything else I got given experience, to move to a larger Dynamics reseller where my skills have been utilised to train on AX. This means from a functional perspective I can start to give some opinions on the differences. My implementation experience is not there with AX yet, but it is coming, and insights will be given here where appropriate. Because of the size of the question the first post started as a ramble. Again I will let it be known that these are my personal opinions and should not reflect on anyone else. All inaccuracies are mine and I am only too happy to be corrected. Additionally I am a blog virgin, so commence this blog, and to make the subsequent postings make sense, this opening blog references the starting point, and also contains the original post: Disclaimer first. For anyone who knows me or who I work for these are personal opinions based upon my last 8 years in the Dynamics channel, they do not reflect my current employer. Also some parts of what I say maybe outdated, or I may repeat something I have "heard" rather than have experience of, my apologies, I am not perfect, I will try and put down as much as I can, but feel free to correct me Background second I am Navision centric, have been for 8 years now. I am now a certified AX Solutions Professional, (They moved the goalposts on the NAV one so I have now dropped out of this but still have lots of exams!) but do not be fooled into thinking that as I have passed some exams I know the product in-depth, this can only come with experience, and I have 9 months of it with AX. I am a functional consultant, I deal with trade and logistics and manufacturing. Coming from the NAV world it will not surprise you to hear I have also done Finance as well as some basic development (report writing, data migration with dataports, development I should not have been doing etc) and I also worked first line support in the last company, so I have experience of that side as well. Starting with the sales side there is a 5% difference in the license fee between the two products as a guide, there are of course different ways to sell them, but that is my understanding, so even on a large budget the software element difference is small. You also get more for your money with AX, but I will come to that in the functional differences. The user count, whilst always argued, I honestly do not find that relevant. Whilst there will be exceptions I am aware of NAV sites of 200+ users and AX sites of less than 5. Historically the difference in the products was always defined glibly by users, "if it is 100+ you have to go AX" etc. What should be considered at greater depth is the size and scalability of the database, in today's market business can transact 1000's of entries an hour/day and it is the capability of these solutions to handle this requirement that is key. I have no experience on the retail side so I can give no comparison between the two, you will need to read the previous postings for some information there. Having worked in the NAV side and now the AX side the difference I see in the projects is simply size, it takes more man days per comparable project to implement an AX site than a NAV site. This is using the Sure Step implementation methodology of Microsoft, although even they have a fast track, which frankly AX cannot be used with in my opinion. To answer they questions of girish.joshi why do so many AX implementations fail, well first where is this source of information, do we have any figures comparing to NAV? I would guess not, it is very difficult to judge what is a failure and then where the balme lies. My experience in the NAV world has seen many implementations start and conclude, at the smaller end, without the customer having a project manager. This would not be the case with AX, the projects are bigger because more decisions are required, and I would say an AX implementation is far more likely to fail without one than a NAV project, but please customers, give yourself a chance and have a project manager, and if you are feeling generous even give them the time to do the task. So are there fewer skilled staff on AX than NAV, again difficult to comment worldwide, it depends where the need is, what I will say is in the UK there is a shortage of skilled staff across the entire Dynamics suite. This is being addresses, in part by Microsoft, but mainly by the partners who badly need the resource. I am aware of consultants being trained up from other software; Sage, SAP, Baan, etc, but this is a common aspect of the business we are in. I would though say the shortage is comparable on both sides and I do not see this as a factor of differentiation between the two. As for is the product crap, my simple answer is no. Okay, the functional stuff, try to remember I am NOT an expert, so all errors are my own! AX5 is due out later this year, so for this I am comparing AX4 to NAV4. User Interface The menu suites are the same to look at, slightly different to modify. I struggle with AX navigation, it seems a little clunky, however this could simply be personal experience bias. The AX screens are too large for standard resolutions at times, although you can hide the at the click of an arrow rather than through view. You can also open a new workspace, a new separate version of what you are running. Ultimately I find AX asthetically more messy than NAV, but it is a personal choice. The filtering in NAV is more slice and dice, it is quicker if you know what you are doing, but AX has the ability for you to save these filters and then you pick them again from the same screen. The designing and setup of the forms is per user and involves all fields in AX, not just the line sections for movement, it requires more development in NAV and it affects the form, not just the user. You can create a template in most places in AX, once activated you are prompted each time. NAV templates are a later invention, which take a lot more setup, arguably making them more flexible, but different. Not sure if the master templates came into NAV at 5 or 4. Function keys and lookups/drill downs work differently, which is a little annoying, but hey who uses both? One thing I will say is the products are becoming more and more alike from a user perspective. Overall AX has a series of layers where the objects are placed enabling different objects to be placed in different layers, with the lowest layer being the object taken. This is different from the object handling in NAV. I have a vague memory telling me that AX has an advantage in a global role out, different language sets can be used within the same database, or different localisations can, or something, which gave it an advantage over NAV in this area. I will put some details in the following areas later Подробнее... http://dynamicsuser.net/blogs/adamroue/arc...ics-part-i.aspx
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. |
|
![]() |
#2 |
Участник
|
Цитата:
Сообщение от Blog bot
![]() Where is the "cut-off" between NAV (Microsoft Dynamics Navision) and AX (Microsoft Dynamics Axapta)? Why do business chose one over the other, and essentially, stripping away the Microsoft-speak, what are the differences between the two products?
Whilst I could not answer the question directly posed in the forum (http://dynamicsuser.net/forums/p/218...55.aspx#106955) I felt I was at least in a unique position to comment. In June 2007 I left a NAV reseller after 8 years worth of NAV Implementation, support, development and anything else I got given experience, to move to a larger Dynamics reseller where my skills have been utilised to train on AX. Развяжем очередную Holy War ![]() Я могу оппонировать по Аксапте. Мое мнение: На самом деле, ни проще, ни сложнее. Это просто разные программы. С появлением правильной треуровневости в 6ом навике вообще будет вообще не различить... Насчет скорости внедрения - просто Навижин позиционируют на небольшие внедрения. Вот и получается, что ожидают от Навижина меньше, чем он может. С Аксаптой как раз наоборот, маркетингово позиционируют на "крутые" внедрения. От нее гораздо чаще ожидают то, что она просто не может такого сделать в принципе. Единственно, с чем согласен - SIFT это круто. Одной формулой получаем не только суммирование с фильтрами, но и drill-down. В других системах (в том числе и в Аксапте) для подобной функциональности надо прогать(!) три(!) блока - суммирование, возможность фильтрации для суммирования и дрилл-даун. |
|
![]() |
#3 |
Участник
|
Okay not my specialist area, I know more than enough not to be dangerous, but not enough to talk to accountants and gain respect J
The basics, they both have what you would expect: Chart of Accounts Dimensions Journals Bank Reconciliations (I will not go there!) Budgets Fixed Assets Financial Statements Tax/VAT Intercompany Consolidation Dunning/Collection Letters Chart of Accounts Chart of Accounts are pretty similar. AX has an addition in the validation part of the ledger account where you validate the posting type and user when a transaction hits an account, so you can say account "x" can only be posted to with transaction of the posting type "purchase freight" or by user "y". AX also has auto-allocation, so when a transaction hits an account it is automatically allocated across the defined accounts/dimensions as defined on the original account. There is also a system accounts concept, so there is a system account for the "penny difference" and if configured the system will post here. This takes many of the generic settings away from the posting groups etc. Financial Dimensions Okay, both have "financial" dimensions. I need to be careful here. AX has the concept of Financial and Inventory dimensions, the lot/serial/bin/warehouse is considered a "dimension". From a financial perspective there are three standard AX dimensions, essentially department, cost centre and purpose, although you can call them what you want. You can also purchase more. Prior to 4 (?) in NAV there was the Department and Project split, but with the advent of dimensions this was opened up to limitless possibilities, barring performance issues. NAV seems more flexible in its approach here. However within AX you have dimension sets and focuses, and these can be applied to the account schedule columns and rows. This leads to a quicker and more advance production of account schedules in a dimension environment. This is a difficult one to call really; it would depend upon the needs of the business. I feel that AX is designed better, but NAV is easier to use and can be extended with ease. Still don't take my word for it!! Bank Reconciliation From what I can see they are very similar, against the bank account you enter the statement details when it comes in, bring in the open transactions, enter any corrections and post the reconciliation. I know this has its issues in NAV with the US having something different I believe, and this is probably true around the globe, although I do not have the experience to make the any comment on AX. Budgets As far as I can see where NAV is better is the Excel integration, AX does not have it. However AX has more to it, AX has allocation keys, as it does in many areas, whereby you enter a total, apply the allocation and it spreads the value depending upon the allocation key. The realised GL accounts can also be transferred into the budgeting arena. Inventory budgeting can also take place, where a quantity and price can generate the budget. Fixed Assets Not much to say here, I am pretty sure you need to create the fixed asset as a stock item in AX first and then purchase it then transfer it to a fixed asset status, but I have done nothing here, although I expect AX to be more complex! Financial Statements On the face of it these seem pretty similar, you define rows and columns to produce the figures you require. Dimensions can be brought in, although in AX you can quickly apply the dimension focus to the financial statements. In AX you see everything in a tree structure (if you want) so it is like a graphical BOM display, this would seem to make it easier to construct than in NAV, but this is user preference. Tax/VAT Again a similar concept between the two systems on calculating Tax/VAT and I am sure this is the case for the localisations as well. In AX you have VAT codes within VAT groups with VAT groups assigned to businesses and items. Where the codes within the groups match this is the code used. In NAV it is the posting setup and the percent that is referenced from the VAT codes combining to the business and item codes. Intercompany & Consolidation Not enough exposure in either software to comment I am afraid, but on the face of it both systems have similar approaches to this concept. Dunning/Collection Letters Similar concepts in NAV and AX, the production of the letters, the ability to add interest, all for the chasing of debts. From the little I have seen on both sides they are very similar. Additional Areas as standard in AX that do not "really" exist as standard in NAV Cash Flow Management The cashflow forecasting in AX allows the expected cash receipts and disbursements to be analysed. Periods are defined for time between delivery and invoicing to assist in the cash flow time buckets, and budgets can be brought in and reduced with allocation keys. Relationships can be defined enabling the forecast in one account to produce expected activity in another, so tax can be calculated based upon sales etc. Balanced Scorecard This is an effective KPI analysis system. Scorecards are created with objectives, perspectives, measurements, elements and targets. Journals can be manually posted to update the actual figures. The system can also create elements based upon AX tables and automatically updated. The system can also point to external sources of data and bring in the figures to create KPI analysis. In marketing speak this area has emerged from a growing recognition that financial measures alone are not enough to manage a modern organisation. Commonly used retrospective financial analysis focuses exclusively on the final results, without consideration being given to the intangible assets that helped produce the result, such as:
Cost Accounting This is not cost accounting as I understand it. In AX it should be considered more cost allocation, enabling you to take costs and reallocate them across items, or bring in labour figures from production and apply them to the costs of items. However I am sure someone will find a use for it somewhere! Advanced Payments AX has the concept of "bridging accounts". When configured the payments go into a set account, once acknowledged the payment is moved from the bridging account to the bank account. From an electronic payment perspective AX has all the currently accepted file formats inbuilt. There is the concept of prepayments where they transaction goes to a different account and during payment of the final invoice the prepayments are reversed. Bill of exchange administration is available. This is where the vendors' liability lasts until the customer has paid the bank. Invoice Registering AX allows a purchase invoice to be logged in and sent to an unapproved pool, the actual invoice gets sent for approval and the user can mark the invoice as approved and then it can be posted. Effectively this is a controlled purchase order approval process. Journal Approval Carrying on from the workflow of the purchase invoice all journals can be setup as part of an approval process. If this is the case the end user cannot post the journal until the designated approver has approved the journal for posting. Free text Invoices NAV allows the entry of everything on an invoice, whilst AX only allows items. The free-text invoice in AX allows the entry of ledger accounts and free-text, but NOT items. Effectively there is a separation in AX that does not exist in NAV. Deposit Slips Deposit slips appear in AX as standard. This is a document used to deposit cheques, credit card notes and cash into the bank. Date Intervals Date intervals are fully configurable and used throughout financial statements and reports. These are user defined time periods. These enable the setting up of comparative periods, which can then be selected when running a report, for example "Prior Period". The system also calculates the current period and the next period based upon the configuration of the period. Any other areas within Finance you want me to venture into or specific functional differences or queries just ask away. Right – onto Inventory then, don't hold your breath!! Подробнее... http://dynamicsuser.net/blogs/adamroue/arc...ii-finance.aspx
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. |
|
![]() |
#4 |
Участник
|
Цитата:
Сообщение от Blog bot
![]() Chart of Accounts are pretty similar. AX has an addition in the validation part of the ledger account where you validate the posting type and user when a transaction hits an account, so you can say account "x" can only be posted to with transaction of the posting type "purchase freight" or by user "y".
Цитата:
![]() Цитата:
Но и у универсального в Аксапте есть свои тараканы. Но это отдельная пестня. И он не одинок в этом ощущении ![]() Цитата:
С деервом тут же возникают проблемы и на идеологическом, и на пользовательском (поиск, отбор) и на программистком уровне. Т.е. сделать можно. Но с такими затратами и побочными эффектаи.... http://axapta.mazzy.ru/lib/tree/ Для иереархии в 4ой Аксапте вводится еще один механизм... http://axapta.mazzy.ru/lib/dimension_hierarchy/ Это типичный случай, когда "проще - лучше". |
|
![]() |
#5 |
Участник
|
Цитата:
В Аксапте есть такое понятие как "ожидаемые проводки". Это такие проводки, которые рано или поздно должны совершиться, если ничего не изменится. Например, Факт - продали накладной. Значит рано или поздно мы должны заплатить налоги (настройки из налогового модуля), получить оплату (настройки платежей), а также возможно заплатить агентское вознаграждение (настройки комиссии). Это и есть "ожидаемые проводки". Аксапта засовывает их в специальную таблицу. Ожидаемые проводки по монетарным счетам дают "прогноз движения ДЕНЕЖНЫХ средств". Э-э-э.... Во-первых, пусть посмотрит на цену этого модуля (гранулы) - он продается отдельно ![]() Во-вторых, а в Analisys Services (и в новой инкарнации Performance Point) показатели намного лучше. ![]() Дык... И тут он не единственный ![]() Это нужно для Bank Reconcilation, который автор слегка пропустил ![]() bridging accounts - это 57 счет - деньги в пути. Суть метода в том, что платеж может делаться на основании платежки (Дт60, Кт57) А когда придет выписка из банка, то платежная проводка завершится датой выписки (Дт57, Кт51) Причем платеж может делать один пользователь, а выписками заниматься другой. Цитата:
А вообще - ![]() http://axapta.mazzy.ru/lib/names/ |
|