DynDeveloper.com

DynDeveloper.com

Sign Up Now! Log In

Archives

 

I have been struggling to figure out how to use the eConnect (version 9) assemblies to create a new invoice in our Dynamics GP 9 system.

However, when I send the XML to eConnect (using eConnect_EntryPoint), I get a System.Data.SqlClient.SqlException whose message is merely: "System Error". Not very helpful. The only other information it gives is the procedure name: taSopLineIvcInsert. It gives me the line number in the procedure, but I cannot open up the SP code because it is protected.

Here's the serialized XML I'm sending in via eConnect 9:

<?xml version="1.0" encoding="utf-16"?>
<eConnect xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOPTransactionType><eConnectProcessInfo xsi:nil="true" /><taUpdateCreateItemRcd xsi:nil="true" />
<taUpdateCreateCustomerRcd xsi:nil="true" />
<taCreateCustomerAddress_Items xsi:nil="true" />
<taSopSerial_Items xsi:nil="true" />
<taSopLotAuto_Items xsi:nil="true" />
<taSopLineIvcInsert_Items>
<taSopLineIvcInsert>
<SOPTYPE>3</SOPTYPE>
<SOPNUMBE>PCTTEST1</SOPNUMBE>
<CUSTNMBR>PETE0003</CUSTNMBR>
<DOCDATE>11/8/2007 9:46:26 AM</DOCDATE>
<ITEMNMBR>WIDGIT</ITEMNMBR>
<UNITPRCE>3.25</UNITPRCE>
<XTNDPRCE>42.25</XTNDPRCE>
<QUANTITY>13</QUANTITY>
<PRCLEVEL>RETAIL</PRCLEVEL>
<DOCID>TESTDOC01</DOCID>
<UOFM>EACH</UOFM>
</taSopLineIvcInsert>
</taSopLineIvcInsert_Items>
<taSopLineIvcInsertComponent_Items xsi:nil="true" />
<taSopTrackingNum_Items xsi:nil="true" />
<taSopCommissions_Items xsi:nil="true" />
<taSopLineIvcTaxInsert_Items xsi:nil="true" />
<taCreateSopPaymentInsertRecord_Items xsi:nil="true" />
<taSopUserDefined xsi:nil="true" />
<taSopDistribution_Items xsi:nil="true" />
<taSopMultiBin_Items xsi:nil="true" />
<taSopHdrIvcInsert>
<SOPTYPE>3</SOPTYPE>
<DOCID>TESTDOC01</DOCID>
<SOPNUMBE>PCTTEST1</SOPNUMBE>
<DOCDATE>11/8/2007 9:46:26 AM</DOCDATE>
<CUSTNMBR>PETE0003</CUSTNMBR>
<BACHNUMB />
<PRCLEVEL>RETAIL</PRCLEVEL>
</taSopHdrIvcInsert>
<taSopToPopLink xsi:nil="true" />
<taSopUpdateCreateProcessHold xsi:nil="true" />
<taCreateSOPTrackingInfo xsi:nil="true" />
<taMdaUpdate_Items xsi:nil="true" />
</SOPTransactionType>
</eConnect> 

Prior to this point, I was getting useful errors from eConnect about which specific fields I was or wasn't setting properly. However, once I resolved all those issues, I started getting the unhelpful System Error message.

Any ideas? I'm going crazy here.

Thanks in advance,

Peter


 

Has anyone ever used SmartConnect by eOne? Someone suggested it as an alternative to eConnect, but it doesn't look like it will meet our needs. We really need a synchronous API like eConnect so that we can generate invoices as needed. Is there a way to do this with SmartConnect?

Their website is not very helpful, so I was wondering if anyone had any experience with the product.

Thanks in advance.

Peter


 

The eConnect 9.0 libraries require the usage of Integrated Security with SQL Server. This means that every end user of my application (which uses eConnect to talk to GP) would need login rights to the GP SQL Server, no? That doesn't make any sense.

Is there a way that I can force them all to log into SQL Server with the same credentials. Would I have to do some tricks with impersonation in my application code? Has anyone attempted something like this before?

Thanks in advance.

Peter


 

 

 Hi ,

I am looking for Item Line distribution account setup for eConnect. But I can't find.

<taSopDistribution> is only for whole document. But for the sale line item distribution accounts, where is eConnect tag for this?

Cos I can't do posting without it . The error comes out as 'Line Accounts are missing or invalid'

 It's pathis as it is --->  In sale invoice, put cursor in line and press blue arrow -->to load Sale Item Detail Entry and then press distribution button.

Then you can see the accounts for setup, the first three is need. Inventory/cost of sales and sales

 If I added manually, that's ok for posting but how can I add these accounts through eConnect?

 

 

 

We are testing the intergration of a new Purchase Order and the error log is giving us the following error:

 

     11/08/2007 04:11:25 - SQL: Invalid object name 'PA10601'.

 

What is confusing is that the client does not have the Project Accounting module and we are not trying to pass an PA data on the line. Here's the sample PO doc we are testing with:

 

<eConnect xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <POPTransactionType>

    <taPoLine_Items>

      <taPoLine>

        <PONUMBER>TEST09</PONUMBER>

        <VENDORID>ACC</VENDORID>

        <LOCNCODE>FACTORY</LOCNCODE>

        <VNDITNUM>X0355-1010518</VNDITNUM>

        <ITEMNMBR>X0355-1010518</ITEMNMBR>

        <QUANTITY>1</QUANTITY>

        <UOFM>CS5X</UOFM>

      <NONINVEN>1</NONINVEN>

 

      </taPoLine>

    </taPoLine_Items>

    <taPoHdr>

      <POTYPE>1</POTYPE>

        <PONUMBER>TEST09</PONUMBER>

        <VENDORID>ACC</VENDORID>

        <DOCDATE>11/7/2007</DOCDATE>

    </taPoHdr>

  </POPTransactionType>

</eConnect>

 

 

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.