This document, and all our eConnect documentation, is available on the eConnect menu.
I am asked frequently what information a client needs to provide to work with eConnect. This will serve as sort of a primer to clear that up.
There are two basic methods that I use to get data to eConnect - a web service and a windows service.
Web Services
A web service is simply a web site - it can be internal or external - that we feed XML files to and it sends those files to Dynamics. More on XML in a minute. Web services must be called by a calling application - maybe a custom line of business app that the client is having developed. It allows immediate, real time data transfer. The calling application must deal with any errors that occur. Normally that would be emailing an operator to clean up and resubmit.
Windows Service
I use a 'service' instead of a regular aplication because I want the code to run 24/7, regardless of who is signed on to the machine... and I don't want two or three copies running. A service does the trick. Under the covers, each calls the same eConnect code. Windows Services usually run on some sort of a schedule, maybe once daily or once an hour or once every 5 minutes. The data transfer is not real time, but can be nearly so. There must be someone assigned locally to deal with errors. Normally there would be an email that notified an operator of an issue. That operator would look at the error and possibly the source file and clean up the issue, then the doc can be reattempted.
XML
Both methods use XML files to communicate. Consultants are generally more familiar with '.csv' or 'comma delimeted' files, but those have limitations that are beyond our scope here. It's rare to find a customer that cannot provide XML formatted data. If they can't, then we have to get what they have and turn it into XML for them - usually by building a process in front of the processing described above.
Below are links to the template documents that we use for transferring data. Although it is possible for one document to have more than one transaction in it, I'd prefer that we created one doc per transaction. That way we can handle errors atomicly. If one trans fails and another passes in a multi-transaction document, what would we do?
Download the documents that the client needs, and pass them along to them, they will need to supply data in this format. Required fields are clearly noted, most anything else can (and should) be deleted. Beware that some non-required fields become required if you supply another non-required field. For example, in a SOP transaction extended price is not required unless you supply a unit price. In PO entry, the 'ord' (line number) field is not required unless you specify the same items twice in the same PO (it happens more often than you think)
What if the client can't (or won't) supply all of the needed data?
We'll have to supply a custom interface that takes the data that they give us, in whatever format it is, and change it into the eConnect XML schema. That will take a fairly simple project and add quite a bit of time to it - double or triple - so the client should be encouraged to supply the data in the correct format.