Friday, May 25, 2012

Problem with Dynamics GP 2010 EFT Payables CCD+ CTX File Format

UPDATE:  An anonymous comment was posted below, apparently from someone at Microsoft, explaining that this does appear to be a bug in GP 2010 SP2.  As of May 2012 there was no scheduled date for a fix.  For those already on GP 2010 SP2 or later, you should be able to use the CCD+ format and uncheck the "Detail Line Addenda" option.  

For those who have not yet upgraded to GP 2010 SP2 or later and are on an earlier release of GP 2010, there is a separate bug in the CCD+ format that causes GP to export multiple addenda lines instead of a single line for the CCD+ specification.  Since my client is not yet on GP 2010 SP2, this means that they cannot use CCD+, and that we must now use the CCD format.  Unless you are paying vendors that can utilize the extra data that the CCD+ or CTX formats provide, CCD should be fine.  But if you have vendors that can receive your detail remittance data in a CTX file format, you'll need to wait for a fix (unless you want to manually edit the file, or ask your bank to accept a non-standard file).   


I'm guessing this is a pretty obscure feature that relatively few people have used, but I thought I would document it in case some other poor soul experiences the same issue.

I am setting up Dynamics GP 2010 EFT Payables for a client.  Since their bank supports sending multiple remittance lines in the ACH file (aka ACH "addenda" records), I thought that we might as well go that route in case any of their vendors can receive the remittance electronically via an ACH download.

And luckily, with GP 2010 SP2, Microsoft has added a feature in the EFT File Format setup that enables GP to export multiple addenda records.  This feature is apparently referred to as a "CTX" file format, and was introduced into the ACH file format standard in late 2007.  

http://support.microsoft.com/kb/2551488



Unfortunately, from what I can tell, there is a problem with the GP 2010 implementation of the CTX file format.

When you setup the CTX file format to send multiple addenda records, you need to also send the number of addenda records per payment.  So if you send a $1,000 payment to a vendor to pay off 10 invoices, you will send an addenda count value of "0010" in your "Detail" record, followed by the 10 addenda records.

Here is some documentation I found on the NACHA CTX file format, shown on page 11.

http://www.regaltek.com/docs/NACHA%20Format.pdf

Note Field 8, "Number of Addenda Records".  This field is not required for CCD+, which only supports a single addenda record--but if you use the GP "Detail Line Addenda" option, you move up to the CTX format, which does require this field.

From what I can tell, Dynamics GP EFT does not have a field or feature that allows it to send this addenda count value in the detail record.  If you try and add the field, it always sends a value of "0000", as shown below in red:

6221231231231234567890  00000306001EFT  0000TEST EFT VENDOR   011123123120000001

In this example, I used the "Addenda Count" Calculation Type in the EFT File Format setup window, but obviously that doesn't work.





The Addenda Count calculation type is used in the Addenda lines to sequentially number the addenda rows, so my guess is that the Addenda Count value is only active in Addenda lines, and only offers a sequential value, and does not provide a value or addenda count in other line types.

I've looked through and tested several other Calculation Type values, and checked other options, such as Data Fields, but none seem to provide the required addenda count value.

I posted this issue on the Community Forum, but not surprisingly I haven't received any responses yet.  The client doesn't want to bother with a support case, so for now I'll be disabling the "Detail Line Addenda" option.

I'm guessing that this is either a bug or a lack of full support for the CTX file format. If anyone has more info, has had a similar experience, or knows of a workaround, please post a comment and let me know.


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


2 comments:

Unknown said...

Thanks for bring this to our attention. I opened a case and found that it's officially a bug. So anyone affected can open a free support case and be added to the notification list. Here is the reply from Dynamics Support:

After reading through the blog post it appeared to be referencing an issue with the addenda count value in the detail record showing as “0000”. I did do some research and did find bug #64115 that appears to be the same issue.

There is a work-around listed, which I am including below for your reference:

Work-arounds:
1. Use the ‘Detail + Addenda count’ field instead and ask the bank if they will accept that instead.
2. Use the “Detail + Addenda count” field instead. The user would have to edit the file manually by doing the math between the Detail Count field and the Detail + Addenda Count field before sending it to the bank.

We then discussed that I would add you to the listing for this bug so that when this is resolved you would be contacted. Also, keep in mind that currently there is no timeframe set to resolve this.

Steve Endow said...

Hi,

Thank you for the update and confirmation that it appears to be a bug in GP 2010 SP2.

Option 1 does not appear to be an option with City National Bank.

I considered Option 2, but I'm reluctant to have someone manually edit every Detail record of every EFT file that they generate--the chance of a mistake is too high.

I could write a script to automate Workaround #2, but similarly, I don't want to run the risk of having something go wrong that causes the EFT file to be incorrect.

For now I'm recommending they revert to the CCD format, since GP 2010 pre-SP2 appears to have a separate bug in the CCD+ format. It looks like CCD works properly, so we're going to give that a try.

Thanks,

Steve Endow