270
I have a customer using a 3rd party software to bring AP vouchers into GP. eConnect will not integrate a distribution row for the AP control account (PAY distribution type) using taPMDistribution when the Allow Account Entry field is not marked in Account Maintenance for that account. This customer does not want manual journal entries made into the AP control accounts, so they want this field to remain unmarked. Is there any way around this?
Thanks in advance!
*This post is locked for comments
This is a stored procedure I use in different companies that looks up the setup record for AP Control account and flips it to a 1 or a 0 depending on what you want to do.
I actually call this from .Net before creating the transaction and then after I receive back a success from the Payables Transaction.
You could call this inside the Pre and Post Stored procedures too. Or even take it apart and just make it a straight update statement to your company database because if you have to put this in the pre and post stored procedures for any company that you are integrating into (we have a lot of companies so we have to be dynamic and dynamic code like this can be called to execute against any company by passing in the database ID.
CREATE procedure [dbo].[usp_SetAPAccountForEntry_EcUT]
@YesNo int
,@CompanyID VarChar(8)
as
DECLARE @sSQL VarChar(500)
SET @sSQL =
'UPDATE '+@CompanyID+'..GL00100
SET ACCTENTR= '+Convert(VarChar(1),@YesNo)+'
WHERE ACTINDX = (SELECT ACTINDX FROM '+@CompanyID+'..SY01100 WHERE PTGACDSC = ''Accounts Payable'')'
EXEC (@sSQL)
GO
Hi Kevin,
We are having the same issue with GP 16.0. Are you able to share the Pre and Post script of the stored procedure to enable and disable the "Allow Account Entry" for us to temporary fix the issue?
Thanks
I had this issue using GP 10.0 for years and I just had a stored procedure I called that flipped it to "Allow" before making the transactions and then "Disallow" after.
I am now on GP 18.2 (never did the in between versions) and it looks like this is actually fixed in the Payables eConnect Node. I am testing right now and legitimately have the AP Account not allowing entry and creating distributions and it actually works now. I can't find any documentation on when it was fixed, but it really seems to be fixed now.
For the record, It also seems to be fixed on the RM Transaction using the AR Account when creating Distributions
However, it is still not working using SOP Invoices and Returns when I am building Distributions (it always just "worked" when I would use CREATEDIST = 1 meaning to let GP create the Distributions.)
So, anyways, that is what I am seeing. Now I can start removing unnecessary calls to flip the account in all my code.
Great idea! Thanks Lou.
I have borrowed some of the text from this thread to create a product suggestion on Microsoft Connect. Here is the link if you would like to vote for the fix:
Hi Steve,
I like that option because, as you said, you can easily see if something went wrong in the integration process because the account should always be zero. Thanks again for your suggestions. They were spot-on.
Have a great day,
Trish
Hi Trish,
That's an interesting alternative to import a different account and then change it. My only concern about that would be if the account update failed for some reason, it could leave you with an incorrect account in the distributions. But it would probably work okay, and you could use a dedicated 'fake' account to spot that issue in case it ever did happen.
Thanks, Steve, for your quick and thorough reply. I found a similar suggestion that called for passing the distribution to an account that does allow account entry, then use the "Post" procedure to change the account back. It's essentially the same thing you suggested. You have a good idea, though, to turn toggle the "Allow Account Entry field" on and off before and after the integration. The 3rd party company may want to go that route.
Hi Trish,
I just saw this question come up in the GPUG Open Forum, and I ran into it recently myself with an eConnect custom integration that I developed.
I am not aware of a supported way to have eConnect import distributions for accounts that are set to now allow entry.
There are three workarounds that come to mind. I haven't tried them, but they should work in theory.
1. The integration could use SQL to temporarily modify the GL account to allow entry before the integration, import the transactions, then change the GL account back to not allow entry. This isn't terribly elegant, but it's relatively simple and should work in concept.
2. Similar to #1, you could add SQL script to the eConnect "Pre" procedure to allow account entry, and add script to the eConnect "Post" procedure to turn off allow account entry. This is probably better than option #1 since it keeps it all contained in the standard eConnect procs, but you'll need to re-apply the pre and post procs after every service pack and upgrade.
3. You could modify the eConnect stored procedure that creates the distributions and disable the check for the Allow Account Entry option. This has the benefit of not having to change the GL account entry option, but it involves modifying the eConnect proc, which isn't supported, and it too would have to be re-applied after every service pack and upgrade.
Let me know if you end up implementing a solution and how it works out for you.
Steve
#1
André Arnaud de Cal...
292,516
Super User 2025 Season 1
#2
Martin Dráb
231,407
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (
