Estimated reading time: 36 minutes
Again and again one reads about failed attempts to replace a mainframe system that has grown over decades with a "small" solution such as Navision or Business Central. There are many reasons for failure. And many are correct, all are unnecessary.
If you are in a hurry, please go directly to how to do it right
Why? Navision / Business Central is the "natural" successor to any SNI/Comet/AS400 solution.
-> Because Navision and Business Central follow the same principle of data-drivenness, which, in addition to the AS/400 with its DB2, also made Clipper & Dbase as well as Access a success model "back then".
Oh... by the way: Yes, Access is also a data-driven application. Navision or Business Central is the obvious natural replacement, even for old, established Access or FileMaker solutions that have become overwhelmed (because they are far too slow). Well, and with Excel as the “universal business solution... It should really just be a matter of “replace as quickly as possible, no matter what”.
Excursus: The visual relationship between Access and Navision is so great that the first design courses for the then brand new report generator from Navision were made under... Access 🙂 "Under the roof" Access can of course not hold a candle to Navision and certainly not to Business Central.
A simple reason for failure is e.g. simply the time pressure, owed to the need. Time pressure arises because, for example, there are no more parts for the AS400, nobody knows anymore "where this AS/400 actually is in the house" (Real! Experienced!), or/and the previous in-house AS/400 or Crossbasic/Netbasic (formerly Business Basic) specialist finally retires. Or, also popular for time pressure: Because he has already retired. At best. At worst, dead.
It then gets difficult for an Access or midrange replacement. They are looking for a partner who “makes the changeover quick, easy and cheap”. And then? The whole thing falls on your feet. Why is that? What do the old midrange and mainframe computers of a Lidl or a Liqui-Molly , a Haribo, a Otto or even a Deutsche Post do so much better or differently than a modern merchandise management system such as Navision / Business Central on more or less standardized hardware from the hardware store ?
Spoiler alert: It is NOT like an AS400 integrates graphical elements, mails or web shops. These solutions are usually immediately recognizable as "flanged on" or "put on" or "there's no other way" (but... they work!).
Shouldn't replacing a data-driven system platform with a new, data-driven solution like Navision (Business Central) be child's play? I can similarly easily replace a Mercedes van with a Ford van.
So where are the stumbling blocks that cause such AS400 or Access, Dbase, SNI Comet replacement projects to fail?
Early relations of AS400 & Navision Dynamics & Microsoft Business Central 365
In today's Business Central world, this is certainly no longer known. But the database server from Navision (at that time still Navision Dynamics) ran natively on the AS/400!
Around 2000, an AS/400 version of the Navision native database server was offered. This version of Navision was a revolution at the time, and not a small one! While the 2.01 and 3.01 SQL attempts by Navision at the time could rather be described as miserable (“torture” was also an obvious term), the AS/400 (AS400) gave the native database server from Navision (there was no Business Central at the time) an incredible performance boost. The native database server was always lightning fast, and Microsoft had to work hard to be able to gradually map the SIFT model (the technological core of the Flowfields) in the SQL server.
The native database from Navision (essentially still the 1993 version!) was very simply structured. Her only problem at the time: she could only table-lock. And through a - well, let's call it "somewhat unorthodox" - securing of the complete bookkeeping, each posting process started with a table lock on the item entries (Table 32) or financial accounting entry table (Table 17).
Translated into everyday life: As soon as someone in the house posted a financial accounting data entry, an item entry, a purchase order, or a sales invoice, every other posting process was doomed to wait for the end(!) of the previous posting process. And combined with large, small, and smallest programmer/design errors, everyone in sales noticed when financial accounting booked account statements again. It didn't have to be like that, but even then there were bad Navision programmers. 🙂
And then the version of the native Navision database server for AS400 came… which wasn't difficult at all, by the way. There had been a Unix server for a long time, so the step to the i5 or AS400 was very small. Nothing stood in the way of a replacement any longer.
And this server had it all. Previously, i.e. up to around the year 2000, 80-120 users on a Navision database were considered "quite feasible" (a paraphrase for "just about"), with the AS400 suddenly 150, 200, 250, most recently 400 users were released by Navision (until then Microsoft was "only" a strategic partner, not yet an eponym). Without a change in the Navision program code, the AS400 showed the established server hardware that it knows every trick in the book.
And the Microsoft SQL server could not hold a candle to this native database server on Windows, Unix, OS/2 (yep, there was one too!) or even remotely compete with the AS/400. Therefore, this branch was discontinued immediately when Microsoft bought Navision in 2002. And replaced by a clear focus on MS-SQL Server. Too bad.
Familiarity effects & loss aversions
As described above, it may simply be technically or organizationally necessary to replace an existing ERP system (regardless of whether it is an AS400, Siemens Nixdorf, Quattro, Dbase, Oracle, Baan, Sage KHK, Lexware...) with a modern ERP solution (Navision Financials Attain is no longer available as an option, so hopefully Microsoft Business Central 365 🙂 ). And: Maybe this is already clear to many employees and even more so to the management...
But: You and your employees have come to terms with the current solution. They know how they can (or must) deal with existing errors. Management in particular, but also employees who have been with the company for a long time, often shy away from relearning. In addition, there are all the stories of robbers that you have heard from other ERP implementations. Perhaps the experience with an already started, but then failed new implementation of a new ERP system also plays a negative role in the feelings (emotions).
You fear the extra effort, the change, another failure, extra expenses, overtime... maybe even fear the realization that you are currently riding a dead horse, and at great expense.
This brings us to…
The most important points for the success of the legacy systems
The old systems were neither better nor more magical than the techniques available today. The main advantage back then was the deep integration of the database/data storage in the languages available for programming, such as Cobol and RPG under the System36 or AS400 (today System i) on the IBM side and in the Business Basic on the Siemens Nixdorf Quattro Per page (with Comet merchandise management & financial accounting). This also applies to Access in a more modern way.
Whether modern merchandise management systems (such as VLEX Plus) and, in some cases, financial accounting on the AS/400 (e.g. Manhattan Associates Warehouse Management solution for IBM i (WMi), the BP-Warenwirtschaft from Baierl und Partner, the ERP software Frida from Command as well as Oxaion): They all benefit from the deep integration of DB2 or DB/400 into the overall AS400 solution (or the modern ISeries).
The developers on these systems never had to seriously worry about data management, data storage, and data queries: the data simply migrated to the data memory (DB2 on the AS400, files on the SNI Quattro Pro side). And they just appeared again with a command and that even in a predictable and predeterminable order. In the older systems from IBM and SNI with today very dusty screen masks, but quickly and reliably.
If you have already dealt with Navision or Business Central, this should look very familiar to you: Navision has exactly the same magic, especially in the blue ("Dos-Navision") and the legacy versions of Navision up to Navision Dynamics 2009R2 ...or the same technological lead that made the real Cobol & RPG programs visible to the operator on the AS400 and the Business Basic of the (predominantly) Comet applications so successful, reliable and (for the time) incredibly fast.
Exactly this relationship of the data-driven programming makes the detachment, a migration from a Comet or an AS400 so unexpectedly easy! Do you still know dBase and Clipper? The same data-driven approach also controls an AS400 and Navision / Business Central. In the case of Navision Financials Dynamics or Microsoft Business Central BC365, the WMS (Warehouse Management System) is already included in the ERP – the only thing missing is the comparatively simple connection to a conveyor system.
Created by computer scientists
This core technology, this data management or database (represented on the Siemens Nixdorf Quattro via calls in the file system), was developed by computer science thinkers such as Edgar Codd .
Since computing capacity and, above all, data access to long-term storage such as hard drives were not unlimited at the time, these database systems were trimmed to the maximum performance of the underlying, essentially non-modifiable hardware. Just like games from game consoles that are still designed today in a way to exhaust the maximum from the given hardware.
 |
With this, the system developers, i.e. the architects of System36, later AS400 or SNI, laid the foundations for developing efficient, data-driven programs. Everyone who built on this foundation could benefit from the highly complex preparatory work of the system architects... if they knew and observed the limitations of the systems.
Modified by professionals
The inventory management, financial accounting, and wage systems that were later built on these foundations were usually at least looked after by specialists in the respective areas of responsibility, if not even programmed by themselves.
Nothing has changed here from what I said in the 1990s: I'm more likely to make a good-enough programmer out of an accountant than a good-enough accountant out of a programmer. That was also the case back then, thanks to the preparatory work of the system developers.
The framework conditions in which the programs operated at that time were already specified by the database model of the SNI Quattro or AS400. A violation was not possible in certain areas, e.g. a query with or without filtering without an index (a sorting specification).
Of course, you could still select the wrong filter or an unsuitable index (sorting specification). However, this was then punished so radically quickly by the system with exorbitant response times that even the worst programmer quickly realized that he or she had screwed up.
This is still a reason for me to occasionally test developments on servers with very few cores and very little RAM. If the cache or the hardware first has to save what the programmer/developer has previously bent, the horse has already left the barn. If you notice this in time (but you have to have thrown a few basic rules out the window beforehand), you can at least grab the horse by its tail, which means: you can or should reconsider the development.
Trimmed for efficiency
The old systems, such as an IBM AS400, a System36 or even a SystemR, as well as a Siemens Nixdorf Quattro, 8860 or 8870 with the Comet inventory management system were coordinated with each other right from the start. Developers knew the basic conditions, the restrictions, but of course also the ingenious possibilities of the systems. Since these moved on narrow tracks, the training period for programmers was often surprisingly short and the quality of the written applications was often (of course not always) at a very high level.
Due to the specifications of the systems, there was also a very consistent operator guidance. Anachronistic from today's perspective, almost an insult to the eye and the index finger that is used to clicking the mouse. But consistently recognizable throughout the entire system. The following applied throughout Comet: F3 creates a new data record (order, customer, delivery condition), F4 deletes a data record. It doesn't matter where / in which program you were. If you are still familiar with "DOS-Navision" (the blue version) or the "old Navision" (Windows Navision from version 1.3, 20.1 to version 2009R2), this will certainly look familiar. 🙂
You will find even more information on this exciting topic here.
The most common errors in new systems
There are an incredible number of mistakes that can be made. However, common patterns of deadly sins crystallize when migrating/updating from an old inventory management system that needs to be replaced. This does not only apply to the good old AS400, System i or other programs based on Cobol, RPG or Business Basic. These deadly sins affect almost every migration of software. For obvious reasons, however, I will go directly into my experience in rescue operations from migrations to Navision or Business Central 365.
Because this is a fact: In my time as a self-employed (freelancer) Navision / Business Central consultant, trainer, programmer, assessor, I have never been called to a Navision / Business Central (BC) migration "on the green field". I was only ever searched and found when the horse had already left the barn and run away from the farm.
Only then, in my experience, are decision-makers willing to listen to my concepts. Often the result was a complete new beginning.
Using "industry solutions"
The deadly sin bad. For real. Since I have been in contact with Navision, and that has been the case since 1993, I have only experienced suffering with these so-called "industry solutions". That's why I write this term here only in quotation marks.
Why do I think so little of these "off-the-shelf solutions"? For this you need to know the following:
How are "industry solutions" being generated?
Navision / Business Central "out of the box" can do an incredible amount: order entry, inventory management in any number of warehouses, unlimited delivery addresses, stock transfers across hall boundaries ("business premises"), cost accounting, dimension accounting (cost centers & cost units? That's something for beginners like Datev, Diamond, H&S... Navision / Business Central has been able to handle any number of booking dimensions for decades! Not just 2. I could talk about that for a whole day... This is unrivaled in the financial accounting world!!), complicated price calculations (but actually in the Standard no surcharge invoice!), representative statements, evaluations, ABC analyzes (well... with minimal adjustments).
Navision / Business Central can print invoices "out of the box", email delivery notes, the new versions from the RTC can create PDFs and emails directly from the application (the old ones too, with a little extra help…).
The (from my point of view) best, simplest and most powerful financial accounting is always allows this on board.
So every single Navision salesman or Business Central consultant or even every system house can use this fund to thrive. It's always there anyway, and it always works! From the beginning. Just install it, and you can - in principle - first control a company according to GOB. Even the GdPDU logic is already prepared, UVA's could the system. Set it up a bit, maybe put in a real SKR03 or SKR04, and that's it. Electronic Tax Records Files (ETRF) Logic is already prepared, UVA's could use the system. Set it up a bit, maybe put in a real SKR03 or SKR04, and that's it.
And then a wood dealer, a car dealer, a butcher, a food producer, a building management company comes (or rather: came) to some kind of system house and said: "That's all well and good, but we still need the following function:"
And the system house said: OK, give us money for it, then we will adapt your Navision Dynamics or Microsoft Business Central exactly to your wishes, so that we can both be happy.
And the customer gave money. And the system house did as it was told. And both lived happily ever after until...
…Yes. This is where the misery begins. The system house thought: Wow, we have a lot of adjustments of the powerful kind. Can we turn them back into gold thalers? And the system house hangs a flag in front of the doublet and in the office: We have an "industry solution" for car dealers/butchery/wood/real estate trade...
But in most cases it was the case that the system house had no basic knowledge of this branch. From where? After all, you only implemented the adjustments that the customer requested in a more or less qualified manner in 2-20 weeks. And which the system house then implemented in a more or less qualified manner.
And then what has to happen happened: the next customer comes around the corner, reads the sign “branch solution”, and… buys!
The customer then notices quickly and painfully that the business processes that his predecessor (remember? The first specialist customer from the system house...) came up with do not suit him at all. That gives trouble and additional adjustments and thus additional costs. At some point it will all work out.
Now the system house has an even more distorted "industry solution" that has less and less to do with the elegant (Really!), fast (Really!) and error-free (Really!) Navision or Business Central, which Microsoft once burned onto the DVD .
But that doesn't bother the BC dealer! He smelled the morning air, or more precisely: money. And someone would say it again: money doesn't stink. And so another customer comes along, leaving behind an even more distorted system for the following customers.
In the meantime, the developers in the system house are changing, inexperienced programmers break even more, etc. etc.
It is precisely Like that "industry solutions" are created!
What is the issue with “industry solutions”?
They pretend to be able to map the problems of an entire industry in a single package. However, these packages have strayed far too far from the original Navision / Business Central and contain serious program errors under the surface (but also partly directly visible) that are being spread in more and more customer installations.
In addition, the market, the customer and the system house tend to overload customers. Perhaps the 20th car dealer just needs a tiny adjustment to the standard for exactly his procedures (processes). But he is served a warped, error-prone and error-ridden Navision or Business Central 365, and should now make friends with it.
Too much in too little time: It won't work!
By the way, this is a specialty of the Navision / Business Central market! In the past, industry solutions were created when qualified developers sat down with qualified consultants and selected customers, sounded out industry-specific details and then implemented them in a very targeted manner.
A software house usually only has sufficient capacity to map and support a single industry, e.g. hairdressers, car workshops, craftsmen or banks. In this way, enormous specialist knowledge of the respective industry was built up on the software provider side.
Experts from the respective industry often work or worked directly in the software house to mediate between customers and developers or to translate. Everything wasn't better before, for God's sake. Actually, if we're being honest, very little was better. Except maybe Sunday. It used to be Sunday, today is Monday. But this fact that the industry packages that you can write without " really fit the respective industry: THAT really was better.
Today - and especially in the Navision / Business Central environment - it has essentially become: "We have already served a customer or two from this industry". Even if none of the employees at that time are still employed in the system house. And the "industry-specific expertise" has been reduced to "there's a lot of money to be made".
Use of programmers instead of computer scientists
That's not really quibbling, that's a huge difference. The earlier basic systems (e.g. Navision / Business Central "out of the box", trampoline, aswaw400 (as/waw 400), Oxaion, Portolan, Perform, LFS400, Charisma, Assistent... on the AS400, Comet (did there even exist one Alternative?) on the Siemens Nixdorf Quattro Pro 8870, 8860 with Business Basic (or the derivatives Cross Basic, Surfbasic and NetBasic) or completely different systems such as Steeb, were and are being developed as a basic version in close cooperation between application specialists and computer scientists.
OK, at Microsoft it's cracked, you can tell by the quality and the (non-)sense of new functions.
Experience has shown that the basic versions of the respective merchandise management systems were (and actually are) very agile and stable.
These systems only become slower and more error-prone when they are modified by programmers who no longer know many of the basics of IT.
That was and is not a big problem in individual companies!
If the "white-haired computer god" makes a scratch in "his" merchandise management system or financial accounting (ERP) with a screwdriver, then he can (usually) understand very well what caused this and can immediately undo or correct his change.
But if a programmer who does not know the background of a change and who has not yet penetrated the basic application, e.g. Navision or Business Central, makes such a change... Oh dear!...
And then if this change has hidden errors and these are delivered to many customers…. Oh dear!...
And when this programmer then leaves the system house and an even less experienced successor continues to tinker with these already broken programs... Oh dear! Oh my! Oh dear!...
Use of salespeople instead of consultants
In the past, such systems were very often not sold by classic "iceboxes at the North Pole salesmen". Instead, a customer asked for a demonstration date and the first discussions have already been held with experts and technical advisers who knew their product well to very well. On the customer side, the expectations were immediately corrected to what was feasible and the (change) requirements were also corrected to what was sensible, affordable and feasible. In this way, the conclusion of the contract was able to make it clear to both sides what was to be delivered. And also: what not.
Unfortunately, the high contribution margins that were common in the 90s when selling software also attracted salespeople who didn't understand anything about the actual product, who also didn't understand the customer and weren't able to mediate between the customer and the developer. The customer was (and still is) promised the moon… and the developer is told: You'll do it. It has to leave scorched earth… and it often does.
It is not uncommon for customers to seek their salvation by hiring the hopelessly overwhelmed programmer themselves in order to save what can still be saved. And in the system house, a new, inexperienced, maybe a few euros cheaper programmer is hired, who (still) has no clue about Navision / Business Central... and also not about the "industry solution". Bingo!
It has to go back to how it used to be
The stubbornness (there is hardly any polite euphemism here, sometimes one even has to fall back on "stubbornness") of previous mainframe users, whether AS400 or Comet or Quattro Pro, is also legendary in such projects.
“Yes, of course we want to make everything very modern and really beautiful. Please advise us. But in the end everything has to be the same as it used to be, otherwise we can't work.” As you can see, I prefer to use open words instead of beating around the bush.
My own decisive experience was a handicraft paper factory in the Kassel area. After the invoice forms were set up in Navision, a few test invoices were written. Almost all with a deviation of one or a few cents. It was a long evening...
After several hours I finally found the error: The Siemens Nixdorf Quattro Pro, of course with Comet, calculated incorrectly! She had a previously undiscovered rounding error with group discounts. I was able to calculate this with a calculator and pen on the original invoices!
The managing director's comment: We've always done it this way, so it must continue to be expected. I threw the pen & the printouts in the corner and from that point on I implemented every sh... that the managing director wanted "just like before". And made no more suggestions for improvement.
With and for One should not waste any unnecessary time with and for such advice-resistant people. No thanks are given anyway and you can't change anything in such companies anyway. My observation is that this way of thinking always runs through the entire company.
Of course you can also successfully introduce Navision / Business Central in such companies. Especially the tools up to BC 14 make these products more suitable than any competition on the market. The project just described was also implemented and the error described is still installed in 2022 in the meanwhile 2013 Navision version. I have never experienced this “we've always done it this way” in such an inflexible concrete head thinking as among the users of the mainframe systems.
Here, as the client, you have to take a hard look at yourself and ask yourself the question: do you want everything to go back to the way it used to be? It will cost you additional euros, the changeover will be considerably longer, and your system will – just like in the past, just like “It was always like that” – become practically impossible to update. No matter what you have previously been promised or promised.
With Business Central 15, some of the things you have grown fond of about your old AS400 or Siemens Nixdorf Quattro Pro Comet will simply no longer be possible within the base application. Here, even small “must-haves” can result in incredible development effort. You can get a lot for money...
After all, as a consultant, I also have to be fair and see the whole thing from the perspective of the previous mainframe users: the workhorses in the basement have often been working for decades with minimal changes, “in exactly the same way as we have always done it”, and the whole company has arranged itself around them. This introduces working methods and workarounds and solidifies them in a way that is often foreign to Navision / Business Central developers.
In "our" world, we live on dynamics and change, not on "we've always done it this way". So when it comes to a mainframe replacement, real paradigm worlds collide. Here it is all the more important to address strengths and weaknesses in advance and also to point out impossibilities. Anything that is neglected in the run-up to the project will fall heavily on the shoulders of the project partners later on.
The CHANCE through a changeover, a new introduction
If you've made it this far, you've already thought about it anyway. Your customers want PDF invoices or EDIfact files right away. Your web store looks like home-made... and maybe it is. New employees take forever to learn useless number combinations, non-intuitive shortcuts, complicated workarounds for known errors. They may no longer be able to back up data because there is an eternal error lurking in the database. You cannot switch to PC technology or a modern operating system for technical reasons. You need new interfaces for reporting, or have to do various workarounds & evaluations in Excel or Word. Maybe you even have a management consultant in house, who has clearly described many of the bottlenecks of your current IT in words... Or you yourself have recognized exactly this during a change of perspective: Your IT is outdated, your company is suffering from it, your competitor is running away from you, snatching customers away from you through better service, better services. Or your employees need so much time to deal with IT inadequacies that you need new administrative staff for this reason alone. These analyses suggest that you should modernize your IT landscape and enterprise resource planning.
And so we ask ourselves...
How to do it right?
Actually, the summary is simple: some humility. A little humility in the face of the grown system that is to be replaced. But also in front of the new, replacing (to be used) system, e.g. (but not only) Navision or Microsoft Business Central 365. From this, the whole rest follows almost automatically. For example:
Respect for IT
Be sure to save yourself the support of your previous IT supervisor. Caution! This does not necessarily have to be the IT manager. Find out who really helps and can help if an order cannot be booked. Your employees usually know this. The emphasis is on:employees. Department-heads often no longer have enough connection to work. That is why they are called leaders and not workers. Here, too, the exception proves the rule.
When the IT manager is really up for the new merchandise management system
Lucky you!
This is (see next point) very rarely the case. Keep him in line! Give him project responsibility. Give him responsibility. Include it in every meeting. Send him to training. Under no circumstances should you try to "shoot him down" with the new merchandise management system just because your salesperson (see above) said that "you will no longer need IT in the future, it's all much cheaper in the cloud now.“
This promise is never kept. Never.
When the IT manager doesn't feel like using the new ERP at all
This is often the starting point. Possibly also influenced by the age of your IT manager. Such replacements of old solutions are often only triggered by the imminent departure of the previous IT manager. Sometimes afterwards too.
For decades, the maintenance and modernization of IT was put on the back burner and taken lightly. And then the message: "Hey boss, am I still invited to the next Christmas party?"
„Why?“
"Because I'm already retired. By the way… who should be my successor now?”.
And the hut is on fire. And now, very quickly, with all your might, install a successor system... But with a slow start. Until everything is too late. And then right. You know that...
And this employee then says: "Oh, I'm too old for this shit." Or "I don't need this anymore, I'll be gone next year." Or something like that.
And you are there, and are dependent on the know-how of your new "industry solution expert" - which often does not really exist. Oh dear, oh dear!...
Save the goodwill of your previous IT supervisor! Offer him a consulting contract. A 3 month trip to the Maldives when the new system is up and running. A company car for the first 2 years of retirement. No matter what: keep him in line, use his experience for your project. Let the newcomers, who in a few weeks will replace an ERP that has grown over decades, learn from him.
Every cent that you want to save at this point, you will pay tenfold to your system house in the course of the project.
There is also the situation (already experienced) that a company wants to use exactly this opportunity to free itself from the power of the previous IT manager. That works too. Then you just have to put enough energy into finding good clerks in-house.
Respect for employees
Your employees, especially those who actually work, have accumulated a lot of expertise about your processes over the years. They have often found workarounds that not even your IT manager knows about. Perhaps they have outsourced processes to Excel spreadsheets (“shadow IT”), which now urgently need to be included in the new merchandise management system. Integrate your top performers (you have to identify them first...) in the project process.
Respect for work processes
Programmers usually don't understand anything about your procedures / processes. They only read the job description from the salespeople (see above) and then program what they understood from it.
Did you like to play "Chinese whispers" as a child and then laugh yourself to death at the end of the game?
A department manager who does not live the processes explains to a salesperson who does not know the company how a task should be carried out. The salesperson, who knows neither your company nor Navision / Business Central, explains what he has to do to a programmer who hardly knows either. And that poor programmer is always the culprit in the end when the result doesn't have that much to do with reality.
Chinese whispers for adults and with money….
Respect for your own application
Especially as a "spring chicken" it's really itching to show the customer how great Navision Dynamics and Business Central is compared to the old Comet and AS400 applications.
"Of course we'll do it, it's really quick."
You get lost very quickly with it!
Practically every Navision developer who has worked for more than 2 companies has extended the item description field at some point. And for weeks, months or even years, some accounting sheets that had a problem with them fell at his feet.
Even the quite simple switching off of "Data per Company", e.g. for the accounts receivable table 18 or the G/L account table 15 or, if you prefer, the article table 27. And it was only during the course of the project that even the most enthusiastic developer realized what a huge mess he (or she) had actually instigated.
Fortunately, Microsoft has now put a big stop to this activity. Unfortunately with massive collateral damage, so that the (almost always necessary) display of Name 2 & Description 2 in dozens of pages is a day's work...and good finger exercise for the first extension steps.
Respect for the database server
I'll be bold: 90% of all people who make adjustments in Navision or Business Central have no idea how the database server collects the necessary data. Brave, because I think that 90% is still too low.
"Transactions": Those who do not know this word should not be surprised if even supposedly small changes to a flow field, a page, a key then slow down the entire ERP. And anyone who thinks that "transaction" is a bound data manipulation that may only be carried out completely or not at all is confusing the difference between database/hard disks/posting transactions.
Respect the golden rule
In principle, you can get 3 types of service quality on the market - in general, not only with AS/400 (as400), RPG, Cobol, Navision, Comet:
- Good
- Cheap
- Fast
You can - within certain limits - buy these combinations on the market:
- Good & Cheap. That's not FAST.
- Good & Fast. That's not CHEAP.
- Fast & Cheap. That's not GOOD.
- Good, Fast & Cheap. That's NOT POSSIBLE.
Critical questioning of your own application & previous processes
It is no coincidence and no arbitrariness that this point was listed last.
The quality of Navision / Business Central, 100% Microsoft compliant, is getting worse and worse.
Flowfields in lists, any sorting in any table, emulating keys without feedback to the developer: Yes, technically it's great that this works. But that's just not possible in a real company.
"The hardware is too weak" is often said.
No it is do not. The requirements are simply unrealistic.
Reservation?? What a moloch! How could it happen that a bad system was buried so deep in the system?
Stock regulationA construction site for 20 years. See also moving-cost-price-in-navision-business-central
Pro-forma invoice? It can always be more complicated, someone must have thought... and then made it even more complicated. The minimum actual taxation is not even included! For 98% of customers, an order confirmation is sufficient, on which the word “order confirmation” can be replaced with the words “pro forma invoice” if desired. Even for international deliveries.
Wages... An eternal construction site. A very, very serious piece of advice: do not do your wages in Navision. No. Not. Ever!
OCI & EDIfact? Does anyone actually still know the BizzTalk Server from Microsoft? Does it actually still exist? all garbage. Microsoft has never had a reasonable EDIfact solution. Others can do that better.
Despite all the enthusiasm for Navision Dynamics or Business Central, you simply have to be aware that even this great system has its limits. And it is best to know these limits.
But what is fantastic: This does not apply to the migration of AS/400 (as400) or Comet programs, whether from RPG, Cobol or BusinessBasic (NETbasic, CrossBasic)! Even ancient dBase and clipper programs! What these legacy systems could do, Navision and Business Central have been able to do for a long time!
And if not: Dynamics & Business Central were made to simply sew the "missing gold edges" very quickly and effectively to the super merchandise management and beautiful financial accounting.
Believe me.
(Featured image by MHMcCabe)
Estimated reading time: 36 minutes
English 
Deutsch 
Español