Share
ReportHello,
How does 1-2 doc/sec in integration manager compare to others? .txt file is 3000 docs with a pair of debits and credits only.
*This post is locked for comments
You’re offline. This is a read only version of the page.
Hello,
How does 1-2 doc/sec in integration manager compare to others? .txt file is 3000 docs with a pair of debits and credits only.
*This post is locked for comments
Thanks guys this gives me 3 options other than getting users out for 2 hours.
To Kevin, We have eConnect but it's not fully installed. I'm guessing at least the adapter is so I will look into that to at least try and solve this particular issue. A neighboring organization has purchased SmartConnect but that isn't installed and available to us yet and it's been 6 months or more since purchase and no installation so stuck on that one right now. I am hoping something like this thread and some other issues I will be posting later will help me get our organization set up with best performance. 20% of office is on GP while the other 80% is still using 1980s mainframe after 5 years of having GP with no future consideration to replace the mainframe as it is seen as superior.
To Richard, the file does not have jrnentry or sqncline. I have felt it is performance issues that i think you are pointing to. I am mounting a large challenge to our management and partner reccomendation that the terminal server is our problem that is 4 states away from us with nothing loaded to our quad-core pc's. This may help! I believe locally installed client on our machine would be a global solution to many problems.
If you've got the eConnect destination adapter installed, you may want to consider changing to that adapter. The eConnect destination adapter (Microsoft Dynamics GP eConnect) will appear in the Add Destination window when creating your integration if this adapter is installed. If you choose this adapter and then choose the Financial > GL Transaction Destination, you'll have a very similar mapping window to the GL Transaction destination mapping window. However, the eConnect destination adapter integrates the data right at the database level through stored procedures containing all of the business logic and is much quicker than the Microsoft Dynamics GP standard adapter destination.
The PK on the GL10001 table is JRNENTRY,SQNCLINE. So either you have two transactions with the same JRNENTRY number or one transaction where the SQNCLINE is duplicated. It sounds to me that IM is not incrementing properly. Have you tried this integration on another faster computer? The one with the most memory would be better. I assume your input file does not supply the JRNENTRY and SQNCLINE values? If it does not, then it is an IM problem, it is does then the finger points at the input file.
PS I can check the .txt for duplicates in Excel easily before import? But I won't have the JE#s numbers. This is the serial journal id that is the problem I believe and not the reference's if i understand what you are getting at. And duplicate references would be ok right if they happen even though I don't think the integration would have duplicates but guess theres a chance. I can check Monday. Are you thinking I have a duplicate reference way down in list and it's having trouble putting them together?
It must be losing track. I think I have 3 results when i see the error. One is it goes in correctly on this entry. In another instance it combined entries of another user's reference into the one I was integrating. The most common has been that it loses JE completely and has to be reconcilied to add those or just delete batch and start over.
The duplicate journal entry message is concerning. If you look in GP aftter the integration runs are they all in there or did some not make it? Can you dump these records into sql and check for any duplicates prior to the import. I am trying to determine if there really are duplicates or is IM losing track of the next journal entry number.
I will inquire with our partner on the Visual Studio and consider the Table import. I have used table import before. If either solves the JE# error and speeds this up, we will be solved on this particular issue and will start other threads on our set up that i think is killing the product.
PS. Let me correct 'the speed seems the same..." and state what I know while i can't test. 700, 1500, 3000 docs in the fomat described with a single debit and credit per doc go in at 1-2 docs/sec. 3000 docs takes 30 minutes I believe. I have a further error I would like to report but not sure it doesn't need a seperate thread which is "journal id already used please select another journal id". This can happen multiple times in a single integration.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,280
Super User 2024 Season 2
#2
Martin Dráb
230,235
Most Valuable Professional
#3
nmaenpaa
101,156
All responses (
Answers (