Using eConnect from Dexterity - Part 3

I forgot I promised a sequel for this series regarding transactions.

I've done many of these and most include quite a bit of logic.  Some have intense logic sequences, depending on the data source.  I'll explain.

Transactions usually involve some sort of "Document Number".  This could be a JE #, a PO #, a SO #, or some other similar thing.  What's important is this is usually a unique identifier and cannot be repeated.

I mentioned in Part 2 that there are "next number" connection points in eConnect, and these might not be documented in the SDK (but can be found as "ta" stored procedures in a GP company database.)  You can use those to obtain a next number, which is typically the first step required in adding a transaction (after the batch, that is.)

The next steps will depend on the fact that most transactions in GP involve detail lines and related headers.  Sometimes, as certain modules require, there may be multiple types of details required.  The obvious example here is if you want to supply your own GL distribution instead of the defaults from GP.

This points out another nice feature of eConnect.  It will default supporting details for your transaction just like GP would if a user was doing the entry.  So if you want GP to default the GL distribution you typically don't need to take any extra steps.  Contrast that with going direct to tables and eConnect wins every time!

But if you do want to override the defaults and provide your own data you typically need to flag the header to NOT default the details you want (and may have already) provided.  I have found these clearly indicated in the SDK for the header, if applicable.

The sequence following getting the next number will involve creating all the supporting detail records first, then creating the header.  This typically involves WHILE loops and keys that support the ordering of transactions so you can insert the details, and when some key field changes, insert the header and get the next number.

I will admit sometimes the logic required to get the steps right in Dex can be involved.  And it's important to step into it and proceed with suitable test data.

And furthermore I would suggest testing your inserts from Query Analyzer in SQL Server.  (You are using a test server, right?)  This will tell you that your handling of the eConnect calls work before you start with Dexterity.

There's another reason I like using Dexterity for this: Because I don't like to use cursors in SQL Server.  Actually I despise them, so doing the work programmatically in Dex is better for my soul!  I have also found that this process happens FAST so user wait times are negligible.

And there is no way you can start on this if you don't understand what the UI requires, and what the back-end involves.  So you will need to obtain plenty of sample transactions to process, run these through the GP UI, and observe the results in the tables when saved before you even start coding.  Then you will be able to approach your integration with the understanding of where you are heading.

I hope I've laid the ground-work for a simple transaction example, which I'll do as the next installment in this series.

And again your comments will encourage me to keep up with this so let's hear it!