Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Great Plains AR Integration.

Status
Not open for further replies.

Smcmanus2001

Programmer
Jan 15, 2002
44
CA
Hello there
We are looking to integrate our system, to allow importing of transactions, to Great Plains. The problem is we do not have Great Plains, nor do we have the documentation. I have 2 questions 1)Can Fields be imported into Great Plains, 2)and if it , is there somewhere that Import Specs could be gotten from? Currently our Database is running on Pervasive SQL 2000i. But Output can be created as almost any format including XML.
 
When you say import fields, do you mean new fields in an existing table? You cannot modify the GP tables by adding new fields. You can use Dexterity to create your own tables or use the DUOS table which is very clumsy. Or, you can find existing fields to use.

There is some really good documentation on the GP tables. If you are associated with a GP customer or partner, you can get that from them. Otherwise, you should try contacting GP about becoming an ISV.

Integration into GP can come from many different file types so I don't think you have to worry there if you decide to just do an integration with Integration Manager instead of code.
 
Actually Creating a File of a particular format would be perfect, either CSV, or Flat File, or XML file. Would be great, but according to what I have been reading it will be only with Integration Manager? Is this true? this means our customers need to have this Add-On package? Or is this a Standard Option? Sorry for the many Questions, But I really am working blind with this. Thx In Advance. Steve McManus
 
Yes, this is an add-on module.

The other ways some may suggest is to directly update the SQL tables. I would not recommend this but I don't normally do things like that.

If you do go directly into tables, make sure you are updating ALL the necessary tables. It won't just be one. Also, going directly into the tables circumvents all the business logic. This could include things such as a customer on hold, exceeding credit limit, or even a non-existing customer.

Good luck with whateer you decide!
 
There is also a Table Import in GP where you can import files in 2 format: Comma or Tab. This is a good alternative to Integration Manager. You can see the field names and the type(String,Date,etc.).
 
Yes, that would be "direct into tables". There is just no business logic applied to that so it's somewhat risky.
 
I thought that was the case, (I was hoping otherwise). Thx, that means thats a NO GO in my opinion, because we won't be doing anything easy like customer import, it will be something like Customer Invoices, Driver Pay, etc. Which will be Heck(family Posting:) to try and figure out.
 
There is another option when importing to GP - the eConnect module(s). This will take something like an XML file and import it into Great Plains tables using the GP business logic, but without having to log in as a user and without the screenscraping slowness of Integration Manager. Usually when making the decision as to which tool to use eConnect wins for higher volumes of data or more frequent imports.
 
eConnect is a lot more expensive than Integration Manager isn't it? I hear it's supposed to come down in price so maybe I'll actually get an opportunity to use it. IM seems to work fine for my customers so they never purchase eConnect and I don't get to check it out. :(
 
thx Vick,
Unfortunately, we as well rely on the whims of our Customers wallets. And if Econnect is a significant jump in price I would have to say it won't be used. transactions won't be that high or time critical to warrant the cost I'm afraid.
 
eConnect is more expensive than Integration Manager, really depends on the modules you need, of course. However, the total price of implementation and administration may actually be less in the long run.

I was simply mentioning it as an option for situations where the volume of transactions is too high for Integration Manager. We usually find out what volume the customer expects to import today as well as in the future and some other factors including IT resources, administration, etc. and then decide which tool to recommend.
 
I have created Dexterity based importing solutions which can ready most text file based formats and still uses the business logic (unlike table import) but are also about 30 times faster than Integration Manager.

Econnect is excellent for a realtime, distributed integration, but methods such as Table Import, Integration Manager and Dexterity code can be easier and cheaper to implement.

David Musgrave
Senior Development Consultant
Asia Pacific Professional Services

Microsoft Business Solutions

mailto:dmusgrav@microsoft.com

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top