I then clicked on the Distributions button (because one should ALWAYS test the distributions on any transaction import), and after I clicked OK to close the distribution window, the following error message was displayed:
The following errors were found while validating distributions:
Fiscal period for posting date does not exist
Hmmm. Okay.
I went to another transaction to check the distributions but the error did not appear. I tried to check other distributions, but I couldn't seem to reproduce the issue.
I deleted my test batch and reimported it again. I pulled up the first transaction in the batch and was able to reproduce the error. So I open the distribution window to see what might be wrong, and I confirm that there is no posting date visible on that window. I check the eConnect documentation and confirm that there is no posting date field that can be set--and regardless, the distributions are being defaulted by GP, so I'm puzzled why the distributions would have a problem.
I then check the database tables, starting with the Misc Log Distributions Work table, PA10203. There is no posting date in that table, just basic distribution info. Then I check the Misc Log Work table, PA10200. While browsing the dates, I see something odd. One of the transactions has a value of "1900-01-01" in the "PAPD" field. The rest of the transactions have the proper test date of 7/1/2017.
I reviewed the eConnect documentation yet again and confirm that there is no posting date available--only a document date.
After doing more testing, I determine that only the first transaction that is imported has a bad posting date. Very odd. At first I think it's because it's the first transaction imported for some reason, but after doing more testing that doesn't seem to be the case.
After a few more rounds of tests, I finally figure it out.
By default, the Fabrikam company is set to use a Batch posting date for Misc Log transactions (Setup -> Posting -> Posting -> Post Date From: Batch).
So that "PAPD" field value is technically coming from the batch posting date rather than from the transaction data that I am sending in to eConnect. But for this import, I am not creating the batch--I'm just sending in the Misc Log transactions and letting eConnect create the batch automatically.
Well, it seems that there is a bug in the Misc Log import. When the first Misc Log transaction is sent to eConnect for a new batch that does not yet exist, eConnect is not properly setting or updating the PAPD date value for the transaction. Perhaps it is inserting the transaction first (resulting in a PAPD value of 1/1/1900) and then creating the batch, but not updating the PAPD value. Or perhaps when it inserts the transaction, it attempts to get the batch posting date, and returns 1/1/1900 because the batch doesn't yet exist.
In any case, it's a small but annoying bug, since it will potentially affect the transaction posting.
There are two potential workarounds.
1. If the client has their posting setup to use Posting Date From: Transaction, the bug is not triggered, so the import should work fine.
2. If the client uses the posting date from the Batch, then you can create the batch first, using the eConnect taCreateUpdateBatchHeaderRcd transaction type, and then import the Misc Log transactions. As long as the batch exists with a valid posting date, the transactions should import with the correct PAPD value.
Again, this is on GP 10 / eConnect 10 SP3. I don't have time to see if this was resolved with a GP 10 service pack, and I haven't yet tested with GP 2010 to see if it also exists there. In the unlikely event that I can test it with GP 2010 (or when the client upgrades), I'll try and post an update.
Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles. He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.
http://www.precipioservices.com
No comments:
Post a Comment