EDI without Add on

please suggest me how to integrated EDI with NAV with out using any add ons like lanham. anyone done this before?

Written it from the base to the specifications of the customer. Done that a few times.

But unless the customers requirements are absolute minimal, and that they are just working with one edi partner, then forget it. It always end up taking more time than you expected, and the customer always ends up with “just a few exceptions” we also need to handle. And then within 2-3 more document types, then you might as well just have started with “a real edi” add-on.

Thanks for your suggestions erik.

I’m happy to help Shyam - that’s what I’m here for! [;)]

EDI is a funny thing. When I started working with NAV in 1991, then EDI had just gotten started. And one of my first bigger projects was actually an EDI project we made for IBM Denmark (at that time NAV was called IBM-NAVIGATOR, as IBMI was the sole distributor in Denmark). And here it was using the EDI-standard EDIfact. Very complex to work with, not to say integrate into NAV in 1992.

Other “EDI-projects” are not really considered “EDI” by the client. How many times didn’t I hear: “It’s “just” a few files we import from our customers. Not real EDI! They all use the same format!” But 9 out of 10 times, as soon as we go into actual test, then it’s not all standard, and soon you have to code small special changes for each “edi-partner”, special validation and field mappings. And soon you’ve spent as design/development/test/implementation hours, as you would have if you had started with “a real edi add-on”. And you client is never really going to be happy, as he has to spent more development hours each time he wants to change just a little bit.

So whatever you would estimate the development of the functionality your self to take, then you should at least say estimate x 2. Depends on your development skills of course - but that’s what I would do. [:)]

Hi Shyamkumar, I think, complex EDI formats without any addons is quite a challange. Please have a look at our Anveo EDI Connect solution for Microsoft Dynamics NAV. We did several EDI solutions since 2002, so we have build a easy-to-use solution for Dynamics NAV.

We offer a 100% NAV solution - all mappings are easily set-up in NAV’s Windows Client/Development environment.

Please find some examples here: EDI for NAV.

Kind regards,


Completely Agree what Eric said, Integrating with EDI always ends up with a challenge. EDI too has many types like EDI 214, EDI 210 etc. I too did a Project couple of months before on this where Client was sending EDI file for ASN Integrations, I asked my Web Developer to handle it in from .NET as it was comparatively easier then NAV but was really challenging. He too used some XSLT too handle this. He just use to convert it in XMl and send back to me for NAV even applying single validation becomes a nightmare to him.

@Eric - You did worked on this in 1991, am still in a shock mode - was born in this year. :slight_smile: :slight_smile:

interesting posting about that topic:

@RockWithNav: maybe surprising for you, not all developers are in the 20s. :wink: i’ve developed my first professional software in 1981!

Yes [mention:0d5d5a12a38749cf82d5992cf1f92071:e9ed411860ed4f2ba0265705b8793d05] I’ve done this a few years now, started with NAV before it was NAV, before Navision, with PC Plus when I was in college in 1988 and fell in love right a way.
I’m not really that experienced when it comes to hardcore EDI implementations, with all the true edi-standards. I’ve not done any hands-on since 1995. Prefer to leave that to the “experts”, as this really requires it, in my opinion.

I would say ANY TIME there’s one of these EDI x standards involved, then it becomes much more complex than it should.

Today I mostly recommends my customers to look at some PDF conversion solution, before EDI, unless that’s really their requirement.