Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.6K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 297 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
EDI Invoice
Rick11
Member Posts: 2
I wonder if anyone have a solution in navision for making an EDI invoice-file?
0
Comments
There is Lanhams EDI, but that is only supported in the US, and also I would guess you want EDIFACT which you can do with Lanhams, but its a lot of work. More importantly it modifies literally hundreds of objects, so integrating it with a Swedish version would really be our of the question.
The best option would be commerce gateway, take a look here or this EDI Integration thread Just be aware that it can be quite expensive to initially get Commerce Gatway/BizTalk/EDI working.
The converter can use a simple txt file as input, does all the tedious conversions and sends out the EDI Doc. It works also the other direction, of course if you have a lot of EDI Docs you should use something like Commerce Gateway with BizTalk.
Regards
Thomas
Not the best way to go, but just wanted to bring it up as a possible option.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
This is really interesting news. Previously they only supported the US and Canadian Databases, but now that they have released it on all these other databases, it opens up a lot of possibilities.
Do you know which versions it is now integrated with (I assume Swedish since thats the thread here, and logically W1 of course)? Also is Advanced Forecasting and Management also now translated or is it just the eShip/EDI package?
Thanks for this info.
RIS Plus, LLC
Yes integration of EDI would be a pretty simple task for most users, but since you are foreced to use eShip its very difficult. But if as marlyn says, eShip is now integrated with all Europen versions, then at least its an option.
Lanham has been adding versions as they deliver EDI in various countries. The same goes for all of their products, AFP included.
Also, EDI can be used by itself without E-Ship, although it is one product suite so that the E-Ship tabs show, but if it is not licensed, it does not have to be paid for or used. E-Ship is needed if ASNs (Adv Ship Notices) are required, because that requires itemizing in the packing process, or if UCC compliant labels are required because they are created with E-Ship. If you don't need any of that, then you can just use EDI for importing documents and matching them to a specific NAV document. Simple communications software is needed to provide a mailbox to drop documents going into NAV or pick up exiting documents. Cleo Lexicom is a cost effective solution, and they say they offer their products in Europe as well.
Yes we are all aware of that, but unfortunately its like saying that I need a bicycle carrier for my car, but your company sells Caravans that have a bike carrier on the back, but its no problem, since I can buy the caravan for the same price as a bike carrier, so long as I don't go inside the caravan. Of course there is no mention of the problems of parking my car nor the extra fuel used towing the caravan everywhere just so I can take my bike with me.
I have discussed this with Per before, and I am aware of WHY it is like this, I just wish there was an option to get EDI without eShip.
On the same topic, I have a client that is interested in APF, but we wont even consider it if it requires installing eShip objects.
The thing is... when a customer doesn't need ASN's, they don't need E-Ship, and they don't want to have to pay their solution center to maintain the hundreds of additional Eship objects you 'get for free'.
I just think it would benefit MANY customers (as well as Lanham's bank account
RIS Plus, LLC
I am sure there are EDI VANs out there that will offer EDI-to-CSV translation service and will only charge you on a per message basis. Even some 3P warehouses are set up to have this EDI capability so their customers don't have to invest thousands in these EDI expensive technologies.
From the technical viewpoint, whatever brand of solutions or integration approach you're using, the following steps must happen in a PO:
1. Send and receive EDIFACT or X12 messages to and from your trading partners.
2. Translate an EDIFACT/X12 file to a flat file for import into your ERP system (in this case NAV).
3. Pick and pack line items on EDI orders (scan-packing is a requirement if trading with major retailers in AU).
4. Export ASNs (csv to EDIFACT or X12) back into the translator.
5. Send ASNs to your retailer customers via a fee-based VAN or Internet.
Yes, it would be nice to have one tool or plafform that does it all. But the reality is even simple tasks like these are performed by different pieces of technology from different vendors. Some EDI translation tool makers would make you pay a few hundred bucks for a map specific to your ERP application, which they may have already developed for other customers using mainstream accounting packages in the past.
E-Ship as far as I understand is a NAV-based solution that eliminates the need for a standalone translation tool (step #2 and #4), which normally could set you back a few grands. Sending and receiving (step #1 and #5) are done within the same tool. Step #3 may be done in some warehouse management tool or ERP package w/ integrated warehouse management features. And don't forget you need to pay the VAN for the EDI mailbox to deliver these messages.
In our case, because we are using a 3rd party warehouse that already has EDI capability (they are receiving EDI orders on our behalf and send us EDI orders in CSV format by e-mail), we pay only AUD150.00 quarterly to this 3rd party warehouse and get all the CSV files we want for importing into NAV. It only took me a few hours to write up a dataport for that.
I understand if you're a MBS developer you may not get to question the integration approach because consulting hours mean income to your employer. However, bear in mind there is always a cheaper way of doing the same thing.
Anyway, that's just my 2 cents.
Scott
Personally I don;t even see ASN as a major issue. All you need for an ASN is a table that cross links a Sales line to a Package line. They could easily separate that one little piece of functionality to allow ASNs on EDI without eShip.
The real issue is their internal cost to maintain two separate systems.
I second the vote on the EDI and E-Ship. Seems an aweful lot of overhead for what most company needs.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
Alex, I seriously thought about that and spent months researching already. Have already got all the EDI mapping guidelines from all AU major retailers. However, the task is quite daunting.
For the part of using extra performance in SQL is every index added to base objects marked with a Key Group. If E-Ship in not used disable the SE-ESHIP (EDI is marked with SE-EDI). The total number of objects modified is precise 120 base objects in W1 5.00, Not much for an addon that support sending, receiving X12 and EDIFACT documents for Sales or Purchase documents. With a very hard cutting of features would only 40 objects be required. The list is below.
The solution is not intended for internal integration where a Biztalk solution sometimes deliver better integration, but for sure it is capable of doing it. But in most cases would it be like shooting bird with a cannon.
The idea about hte solution is also to allow the customer to map new EDI documents without big coding projects. This will make it very efficient adding partner later or upgrading between versions of EDI documents.
Another thing is is that Lanham will integrate all their addons with most versions of Navision (since 2.01 or 3.60/3.70.A for extended warehouse support) for a limited fixed fee including future upgrades for a fixed fee too.
Here is the list of essential objects to modify for a EDI solution not supporting feature combined with E-Ship (only 850 (Purchase Order), 810 (Invoice), 997 (functional Ackknowledgement) with simple partners would be fully supported integrated with Navision without E-Ship).
Object Type Object Number Object Name
Table 14 Location
Table 18 Customer
Table 36 Sales Header
Table 37 Sales Line
Table 38 Purchase Header
Table 39 Purchase Line
Table 110 Sales Shipment Header
Table 111 Sales Shipment Line
Table 112 Sales Invoice Header
Table 113 Sales Invoice Line
Table 114 Sales Cr.Memo Header
Table 115 Sales Cr.Memo Line
Table 122 Purch. Inv. Header
Table 222 Ship-to Address
Table 291 Shipping Agent
Table 311 Sales & Receivables Setup
Form 15 Location List
Form 21 Customer Card
Form 41 Sales Quote
Form 42 Sales Order
Form 44 Sales Credit Memo
Form 46 Sales Order Subform
Form 50 Purchase Order
Form 95 Sales Quote Subform
Form 130 Posted Sales Shipment
Form 131 Posted Sales Shpt. Subform
Form 132 Posted Sales Invoice
Form 134 Posted Sales Credit Memo
Form 300 Ship-to Address
Form 428 Shipping Agents
Form 459 Sales & Receivables Setup
Form 507 Blanket Sales Order
Form 508 Blanket Sales Order Subform
Form 5703 Location Card
Report 295 Combine Shipments
Codeunit 12 Gen. Jnl.-Post Line
Codeunit 80 Sales-Post
Codeunit 86 Sales-Quote to Order
Codeunit 87 Blanket Sales Order to Order
Codeunit 90 Purch.-Post