What started as a by the way project, in 2019 became one of the lifeline solutions for our business.
Like every other project, we want to ensure that we put in our A-game in everything we do. Along the way, we pick up so many lessons. Technology solutions are never short of fun and frustrations as on one end you have developers who, well in most cases, are seemingly breaking their backs to churn out sprints and on the other end, a screaming customer, who does not fully understand their requirements, but want a product out.
Well, our very first time of this integration wasn’t any different.
The Goal
A client, running Microsoft Navision 2009 R2 as their core invoicing system needed to integrate into ZRA ESD services. Simple right, well, so we thought as well but it turned out to have quite some twists and turns along the way.
Development Tools
Microsoft Visual Studio 2017 (.net core 2.1) – Navision integration and Web API services development. C#, Entity Framework, swagger and all those goodies were utilized. I will share in another post soon what tools we use to get the job done.
Angular has been our go-to frontend technology for some time, and we used it for some internal invoicing generation.
Estimated Development Time
Our team of experts estimated this to be 4 weeks of work :).
ZRA ESD Integration
The documentation on the ZRA side was scanty and not so helpful. We took about a week to get this going. We developed a console app that would be distributed as a DLL exposing primarily two services, one for sending invoice data as well as querying invoice data and another, for testing and “playing” with some of the services that ZRA had exposed. This included things like heartbeat monitoring and so on.
Key highlights on the ESD implementation included challenges with getting the #fiscalcode using some dll that was provided by ZRA. Setting up the fiscal device was also a challenge largely due to poor documentation.
Navision 2009 Integration
Now, this was a challenge. We thought we could just pick up invoice data from the database and we would be good. Turned out we need a NAV expert to be able to pull this one. Microsoft Dynamics NAV is generally characterized as an ERP System. ERP stands for Enterprise Resource Planning. An ERP system is a set of integrated application software components designed to track and coordinate a wide variety of business activities, especially those involving products, orders, production and finances.
We got to learn codeunits, C/AL, C/SIDE, xmlports and all those technologies. We ultimately created web services which we were able to consume in .Net Core and were able to successfully read and write back invoice data. We picked up a whole lot of lessons implementing this project.
The Project Life
One interesting thing is that whilst we were on this project, we went ahead and did three other integrations into the custom invoicing system which we completed in record time. One we did in two days and the most time we spend was about 10 days. One of the clients was a large enterprise that is into adult beverage distribution whilst the other two were, well, very small entities.
Back to our experiment project, it took another twist and the client requested a server-to-server implementation (EFD), which will be covered in another post.
All in all, we can safely say, you are in safe hands with us, regardless of the invoicing system use, should you require #ZRAInvoice #ESD #EFD #V-EFD integration.
Feedback
Are you a developer or a customer, what has been your experience with the ZRA ESD/EFD integration process? Kindly state your technologies/invoice system and timelines as well as challenges along the way.
