We are trying to import GL Control Codes. I am getting “GLCntrlAcct Not Found”. When I look at the error records and compare them to the GL Control Type the account contexts are there and the numbers match. I’ve also verified that the natural accounts I’m trying to set are there. Anyone have issues with this import working correctly?
Limited import for testing
The actual errored records
AP Account type with its contexts
I find it helpful to personalize the grid on the form to show all the fields I’ll be including in my DMT file. Then use “Copy to Excel” to see what the fields contents actually look like.
One common “gotcha” with DMT, is when the grid displays the description, but the actual value in the field is an ID or code. Probably not your exact issue as some did go through. But looking at the raw values can sometimes point you to some other issue.
I dumped the data from a BAQ using the fields in the DMT template, setting up a secondary company with identical codes. This one is pretty straight forward. Not all of these are failing either some are just fine. It’s weird.
I don’t think that error message is related to the GL Acct, as your DMT errored on #4 , but not #16 - which both specify the same GL acct.
Not that I’d think it should matter, but any better lucky if it is sorted by:
GLC Type -> GLC Code -> GLCTAcctNum
One other thing I noticed, is that it fails on every other - with a reset at change of GLC Code.
Your DMT order was:
APT 6 - Pass
APT 4 - Fail
APT 16 - Pass
APT 1 - Fail
APT 2 - Pass
APT 9 - Fail
APT 5 - Pass
< change of code>
ART 7 - Pass
ART 19 - Fail
ART 8 - Pass
ART 5 - Fail
ART 1 - Pass
ART 3 - Fail
hmmmm you’re onto something there with the every other. I can say it imports into my K2021 environment fine but not my 10.2.600.10 maybe a bug where something isn’t clearing between? I’ll try the numeric sort on account num but it shouldn’t matter. It doesn’t care what order you fill context IRL.
Is there a non-combined DMT template?
Also, I don’t think you need to specify the segment values. Just the GL Acct (with the pipe character as the segment separator) should be all you need.
If the DMT just updates tables, and doesn’t create transactions, then I try to use the minimal number of fields possible. Because you can always add more fields and subsequent uploads just update the existing records.
If you want to try a real hack … Just make two duplicate rows for each row in your DMT file.
I’m thinking about just reprocessing the error files halving the total until nothing is left LOL
HA HA HA HA HA OMFG that worked. I just reprocessed until they were all in.
Here they all are in my database
I’d want - no … I’d need - to know why. I’d forever be wondering if the GLC’s were actually set up correctly.
They are setup correctly it’s easy to confirm. I think it’s safe to assume something during the update isn’t being disposed causing the error, when the error occurs it causes the disposal and the next works. It’s likely because of the child table structure in this one, but you can’t do parent then child with this import.
It’s a bug fixed (in my case) in 600.12.
Interesting, I’m having the exact same issue, but we are currently on 10.2.700.11.
Contact support reference case CS0002567860 - or - DMT several times until there are no records left erroring out LOL. That’s what I did. Took 5 imports to half the records until they were all in.
I guess not exactly the same, I don’t get any successful results. Same error, same situation, but not the 50/50 errors…at least that way you had a work around. Thanks for the suggestion and case number, I’ll see if it applies. It’s likely just me, but I find DMT to be more of an infinite error generator than a useful tool.
I was called into the CFO’s office today for this same exact issue. After watching what he was doing for a few minutes, it was easy to see that something wasn’t right. So I did what I do best and did a quick search here.
I was shocked to see that the “run the reprocess file” over and over again as a potential fix for this and was even more shocked to see that it worked for us!
I never would have thought of trying to do that.
