IM setup

[barbola]

I started thread632-1110565 asking about source files. I am about to start setting up my first integration with an outside software application, and I was wondering if anyone had some more advice for me or suggestions.

I can set up the source file and map it to Great Plains, no problem. It will be importing an inventory transaction and journal entry to accure inventory, and then a payables transaction (or two or three) that will reverse the accrual. We can't use Receivings transaction because the item inventory cost is a total of the costs paid to all the vendors of the product, freight provider, duty and other charges that may apply.

What do I do as far as setting up a procedure, or making sure that the proper data is being picked up and not missed or duplicated? What about backing up the source file? What about making sure a source file isn't overwritten before it's imported?

I'm intereted in knowing how other IM users handle this procedural stuff? I don't want to be a babysitter.

thanks

 

[jymm]

what I do is put the data into an 'audit' table in Sql. I then also put it into another table that is tied directly to the integration (do this from t-sql or similar). THEN I know what should go in this time and which went in last time. Seems to keep the auditors 'happy'. I was also able to use t-sql to eliminate records from outside sources that I knew I would NOT want. In actuality I run the integration daily - if the table is blank - nothing really happens (which is the case most days) but other days it takes in the file, processes it from the other product, inserts into the temp table. THEN the integration kicks in; then I append the temp table into my 'audit' table and blank out the temp table.

Problem now is that Dynamics 9 & IM do not like SQL 2005 when you are using datasources that are SQL tables (go figure). So I have had to change some processes temporaily to create text files and integrate from there.

This help at all?

 

[barbola]

I am hoping that the other software vendor can write an export for us that will cover all the data integrity stuff from that side. I'm not sure what to do on the Great Plains side. I don't have the expertise to do what you suggest... I'm just not that good, and I am the best we've got here.

Your ideas help, and while I was thinking more from a procedural standpoint, it would be nice to have some kind of set-up support from our GP vendor, but I know that would cost big $$$.

I know some VB and VBA. The data would not be in SQL, it will be a csv (txt didn't work for me). We have SQL2000 and GP 7.50....will be 9.0 by end of '06.

thanks.

 

[Jcfx]

Barbola,

We integrate our payables/receivables from a third party vendor. How they have it working is they take the export information and duplicate it to two tables for each type<GL,Payable,receivable>. One is a permanent table where the information can always be found at alater date, the other table is a temporary one. Basically we have a scheduled task that runs at midnight that takes the orders that have been closed for the day and copies their export information to the temporary tables. There is another scheduled task that preps them for GP <formating credits etc>

Then integration manager uses those temporary tables to pull the information into great plains.

We did add one additional step that runs a procedure after a successful integration that moves the files from the temp table to an archive table and flags them as 'integrated'. This is our back up in case the integration hiccups.

If your third party is willing to create the export, perhaps they will be willing to create the needed temp tables as well. If you know of other customers using that application that would also benifit from the changes they make for you, you could use that as leverage against monetary costs.

Julie
CR 9,10 CE10 Sql DB

 

[barbola]

Thanks for the ideas. That makes sense to do it that way. The software vendor uses Progress software and supposedly we can make an ODBC connection to the data, and hopefully they can archive the export info...otherwise I will have to do it in SQL somewhere.

thanks,
Barb