[Jason Wilder]

We are running NAV 2016 and are in the midst of either purchasing an EDI solution or building it on our own.  I would never consider building the mess that comes with edi except that we have a company that does all the translating for us and “simply” sends us the same incoming xml file for every trading partner.  For the outgoing EDI documents they expect one XML file per document type (again the same for all trading partners).  So basically it is one import and 4 or 5 exports, which doesn’t sound too bad.  Also we already have holding tables and error handling in place for these types of imports and exports.

There are many reasons why we are considering this.  We currently have 4 add-ons (Columbus Foods, ChargeLogic, Avalara and Continia expense management) and “tons” of customization’s that we have done on our own.  The first three are very heavy in the sales side of things.  Our Sales Header table itself has been at the byte limit of 8000 for many years, to the point where I have a second table called Sales Header Extended to hold additional data.  Most of the EDI solutions we have seen have quite a few fields they want to add to the Sales Header as well which will have to be dealt with. (As an aside, one trick I have used is to reduce the field length of text and code fields we do not use to 1 to gain more space, which also allows the code to compile).

I have done all of our NAV upgrades for the past 13 years or so and I am becoming increasing concerned with my upgrade path as we add more add-on’s.  Each new add-on needs to be merged in separately and sometimes the add-on’s do not play nice with each other.  (Our last upgrade was delayed about 4 months because 2 of the add-on’s didn’t work with each other).  We have installed hotfixes for most of the add-on’s and base NAV hotfixes as well so it is becoming a very complex environment when it comes to merging even with the new tools.  One example is one add-on may include some base NAV hotfixes while others do not.

A quick word about our customization’s (that we do almost 100% in house).  These are generally pretty seamless when it comes to upgrading as most of the stuff is in new objects or uses events or is done in a way to minimize the upgrade path.

So with all of that said, if you were in our situation would you go for another add-on or would you considering doing the work on your own?  I know there isn’t a technical limit to add-ons (that I know of) but maybe there is a practical limit of add-on’s when they are based in the same area/module?

——————————
Jason Wilder
Senior Application Developer
Stonewall Kitchen
York ME
——————————

[Cynthia Priebe]

Jason,

Completely understand your concerns, however there are ISV solutions that have little or no touch of Base NAV objects. Since you are researching EDI, one such solution I am aware of is Anveo EDI. 

Of course, you will need to look at what you have already done and determine the best approach for you. Don’t assume that an ISV will add complexity to your solution or your upgrade process, it could do quite the opposite.

——————————
Cynthia Priebe, MCTS, DCP
Senior Business Analyst and Project Manager
Liberty Grove Software
——————————
——————————————-

[Tom Doran]

Hi Jason,

Always good to take a step back and review your strategy.  

If you have begun the journey of moving your modifications to events and the ISVs you are considering are using extensions; then I would not be too concerned with the number of ISVs you may add to your environment.  

The line of questioning we typically suggest asks that you consider whether the modification you are considering would “put you in the software business”.  A field here or there, a bit of custom logic, not a big deal.  If you would find yourself in a situation where you need to maintain versions, provide end user support, and the various other task that start to sound like a software author rather than software end user; we advise caution.

Best of good fortune with your upgrade!

——————————
Tom Doran
Customer Engagement Director
Innovia Consulting
South Bend IN
——————————
——————————————-

[Marije Brummel]

Hey Jason, have you looked at the Data Exchange Framework? This is what we use for most of our EDI. It’s easy to modify where required and it has some event subscribers in NAV 2018.

I can also strongly recomend starting to work with extensions as soon as you get the chance. Off course I am talking extensions V2.

We are also looking at moving some changes to ASP.Net Core where we just use NAV as a development platform for modifications that don’t even come close to standard NAV. The new API in NAV2018 allows you to read and write the most important data from NAV into C#.

——————————
Mark Brummel
MVP Microsoft Dynamics NAV
Brummel Dynamics Services B.V.
Olst
——————————
——————————————-

[Ryan Ketterling]

?Hello Jason,
My advice is going to go against what I would tell most people.  I think you should program your own import/export.  It is not a matter of how many ISVs  you have and normally I am for buying the “wheel” instead of reinventing it.

Based on your post here are my reasons;
1) You already have the error handling in place
2) You already have a partner in place that is doing the translation
3) You have the expertise in house

My guess is it will take you less time to do this yourself then it would take to merge the objects are run through testing all the areas where the new EDI touches your ISVs and customized objects.

Good Luck,

——————————
Ryan Ketterling
Business Automation Specialists of MN, Inc.
Minneapolis MN
——————————
——————————————-

[Justin Falconer]

Jason,

As you know we are using Lanham EDI.  Reading your post I feel this may not be the best option as Lanham EDI does modify a lot of objects in NAV.  While it is a great ISV it does not sound like it would meet your needs unless you wanted to move away from the EDI service that you are currently using and start doing EDI in-house.

I’m with Steve on this one, I think due to your knowledge and the how customized your system is it would make the most since for you to handle this in house and keep using the existing EDI services you have today.

If you want to poke around in a Database with Lanham EDI, Columbus Food, and Chargelogic installed just let me know.  This way you can get a feel for what Lanham modifies and how it would interact with what you have done with your NAV database.

——————————
Justin Falconer
IT Manager
Tender Corporation
Littleton NH
——————————
——————————————-

[Anthony Darden]

Jason, we are doing EXACTLY what you are doing with EDI and I couldn’t be happier.  We have tried two different EDI solutions with NAV integration and kept hitting walls.  We have over 200 trading partners and even came across a situation where modding the add-on was going to be more extensive than simply doing it ourselves going the master map path that you have done as well.  EDI has been a challenging part of the business for us and some of our trading partner testing requirements and new requests need to be addressed in a timely manner and if it requires ISV intervention or an update, we better have great support or a partner that can intervene if the ISV isn’t responsive or has a predefined upgrade path that doesn’t meet our immediate needs.  For us, EDI has been anything but a standard and we tried different solutions that proclaimed flexibility and have seen it all…..only to find out we are unique and will require extensive modifications.  

was spot on with his extensions comment with respect to ease of upgrading in the future, but it sounds like you have this well under control already.  To me, it’s all about the easiest upgrade path, so if NAV is building something into its product that I relied on an add-on before (we have 6 today), I am all for giving it a try.  More than once we have had challenges in going to a newer version of an add-on, yet our in-house custom mods required little-to-no effort.  But at the same time, there are many valuable ISVs out there that do a fantastic job and I will always support.  It’s a balancing act and as more ISVs move to extensions and your dev team embraces them, the act of upgrading NAV will be no different than an Office upgrade, regardless of how complex your environment is.

Tony 
???

——————————
Anthony Darden
Director of IT
Protective Industries, Inc.
Buffalo NY
——————————
——————————————-

[Michelle Berry]

?There is a great EDI tool which does little to no modification to core Dynamics NAV code; check out the Anveo EDI solution. There are several ‘large’ opportunities in North America leveraging this tool today and they use the large trading partners such as Costco, Walmart, Amazon.
The response time for EDI support from the NA Anveo team is the day you request support is the day the team works with you.

——————————
Michelle Berry
Anveo GmbH
Hamburg
——————————
——————————————-

[Jason Wilder]

Thanks everyone for your responses!

A couple of questions:
Mark B. what is the roadmap for getting on prem NAV to V2 Extensions and AL (or is there one)?

Anthony D. would you be willing to share your 2 failed EDI solutions?

——————————
Jason Wilder
Senior Application Developer
Stonewall Kitchen
York ME
——————————
——————————————-

[Joel Baines]

I would say build vs buy has an awful lot of dependencies when it comes to EDI.     What kind of EDI are you doing?    X-12, Edifact, XML … a combination of all 3?    Do you have exposure to off the wall standards like Tradicoms?     How many different documents are you going to expose?     Supplier Side or Vendor Side (or both)?     The more you have to cover…the more BUY is a significantly better option.    

If you are a retail supplier, you will need to have multiple VAN’s or do interconnects.    Some retailers demand 8+ documents to trade with them.     Your EDI solution has to produce labels.     [UCC-128]      Is there integration to your WHMS?     How about to your shipping partners like Fedex/UPS/etc?    

If you don’t know the answers to one or more of these, then you are really looking at buying expertise.    If there is a lot of variation…buy expertise.     If it is 1 standard, 3 documents, never varies, maybe build is OK.    

There are lots of companies you can turn to…Lanham, Data Masons, eBridge Software, True Commerce/Highpoint to name a few.    All have strengths.     What you are buying is their knowledge of what your EDI Partners are going to want you to do.  

Personally, I am big fan of buying expertise that I don’t have time to acquire.

One other thing…some of the above do not require a code merge and sit beside NAV/GP/AX …    

——————————
Joel Baines
Navision Business Analyst
Mississauga ON
——————————
——————————————-

[Anthony Darden]

– happy to discuss with you further.  Feel free to message me direct with a number to call you at.?

——————————
Anthony Darden [Designation]
Director of IT
Protective Industries, Inc.
Buffalo NY
——————————
——————————————-

[Holly Kutil]

Mr. Owl,

How many add on’s are too many?

Admit it!  No one really knows…..

Sorry could not resist! 
Have a great day!

——————————
Holly Kutil ~ NAVUG All-Star
American Ring/CIO
Solon, OH 44139
**Great Lakes Chapter**
?? Women In Dynamics ??
——————————
——————————————-

[Marije Brummel]

Personally I think that in 10 years nobody will talk anymore about this. Technology is moving into a different direction.

Extensions are a nice way to create small modifications to NAV/Business Central but we need to get away from the idea of ERP and everything in one monolothical plaform.

EDI should be either outside of NAV, or if done inside of NAV is should be done as an extension that does not take dependencies on Microsoft objects. What I mean with that is to try and avoid tableextensions as much as possible.

Currently we do EDI insdide of NAV, but as an isolated app. We are in the process of moving away and placing the pieces in microservices to managing will be easier.

In the next few weeks I will share more about this strategy and also how I think CDS and PowerApps is involved.

Welcome to a new world.

Using Business Central as Microservice

Mark Brummel Blog | Microsoft Dynamics NAV		remove preview
Using Business Central as Microservice Opinion, by Mark Brummel Upgrading software is hard. Not because merging software is hard. It’s hard because people are creatures of habits. Let me give you an example. We recently upgraded from NAV 2016 to NAV2018. This means big changes to the Customer Card. I’m fine with that. View this on Mark Brummel Blog | Microsoft Dynamics NAV >

——————————
Mark Brummel
NAVUG All-Star
MVP Microsoft Dynamics NAV
Brummel Dynamics Services B.V.
Olst
——————————
——————————————-