Hello to the Australian Microsoft Dynamics GP community.
Today I wanted to post online the results of a support case we had where we were trying to make the built in EFT (Electronic Funds Transfer) functionality of Microsoft Dynamics GP work with the Australian Bankers Association (ABA) Australian Direct Entry EFT file format.
The Australian Direct Entry (aka AUSDE or DE) file format is used to electronically provide details of payments to Australian banks. It is a single format used by all Australian banks.
During the course of the case I contacted a couple of the major Australian banks and obtained their specifications for the Direct Entry file format. If you need the specific details of the format, please contact your bank and request the specifications for the ABA Direct Entry file format that the bank uses for EFT payments.
Once we had the we format setup in the EFT File Format Maintenance window (Financial >> Cards >> EFT File Format) and had it tested, the partner on the case agreed that we should post the results on the blog for the benefit of the Australian Microsoft Dynamics GP community.
EFT File Format Maintenance
0 01ABA COMPANY ABCD PTY LTD 301500EFT-PAYMENT 0512061062-000 10001000 530000010050CLIENT COMPANY XYZ INVOICE 123456 063-000100000000COMPANY ABCD P/L000000001063-000 10000000 130000010050COMMPANY ABCD PTY LTD PAYMENT 063-000100000000COMPANY ABCD P/L000000007999-999 000000000000000100500000010050 000002
The ABA Direct Entry file format export is attached to the bottom of this article. It is provided "as is" and should undergo User Acceptance Testing for each Customer site.
Hope you find this useful
I had been trying to do the same with the NZ file format. Our banks require an 11 digit Hash Total and I found that GP's option in this area was less than that. Does Australia have the same hash requirements?
You cannot achieve the NZ File Format with the 11 digit Hash Total using the core code. However, it has been achieved using a Dexterity Customization.
Can you confirm that all NZ banks use the same format?
It will help me discuss the NZ format with the Development team and see if we can get the Hash customisation brought into core.
Leave it to the Aussies, to be able to agree upon a single format :)
Thanks to the Partner for sharing info!
I'm trying to setup EFT as per your instructions above. I find that when choosing "Data Field" in the "Maps To" column GP will not accept that. I'm assuming it's trying to reference another field here that I possibly haven't set up correctly. I'd appreciate any hints.
Just download and import the file attached to this blog post.
So the EFT module from Microsoft could have handled the Australian format since its release all those years ago. At present we use an ISV product so it can generate the AUSDE format file.
Thanks to the partner and to you David to releasing the layout.
Time for some testing, especially to check it is one line per payment and rather than one line per invoice paid.
Great article David. I'm glad you were able to map out another EFT format for the masses.
However, it did bring to mind a current (unsolvable) issue with an interface to HSBC in the Bahama/Cayman Islands. GP's date-output options do not include a way to insert slashes in a date.
GP file header IFH,IFILE,CSV,,UNIREG,,20131127,1629,A,1.0,0
HSBC wants the date to be 2013/12/04 and GP only has a 20131204 option.
HSBC wants the time to include colons and seconds 16:29:00 but GP only puts out 1629.
HSBC counts lines differently so a count of 3 in GP is 5 in their format.
The client is not yet live but we are now at the point where a person will need to modify the very first line of the HSBC ACH file to 'fix' it.
I've expressed my angst that an ERP company with 40-50,000 customers in almost all of the civilized world and the largest bank on the planet haven't figured out how to interface. Neither GP nor HSBC can or will provide a solution so every customer that has to play in that space has to custom-design something.
Also, the ACH file format in GP does not contain a place for some of the HSBC requirements so we're having to include odd abbreviations in the Vendor UDF fields to provide that data. Again, it's really hard to believe that the GP ACH file format does not have 'spare' fields or 'enough' fields to include values required by HSBC.
So I'm posting here with a plea for a response from anyone who has solved the HSBC ACH interface issue or knows of an ISV solution.
And, not to make it too easy, HSBC has three formats that are different for Wire-Transfer, Local (Cayman Island or Bahama) payments, and ACH transactions. And since we're using vendor UDF's we can just create a different address ID and ACH format for the three of them and easily swap back and forth.
Lupro Associates LLC
I have been discussing the HSBC format issues with development as I have a case that also wants HSBC ACH XML format.
I will pass on your comments to the appropriate people.
Thanks for working through this case and uploading this in your blog. I am using this as a repository easy to download for my next site :)
HI. Thanks for that I had managed to build this myself from looking at the ABA file and breaking back, found this too late to save most of the work.
Anyone use GP2013 and bank with ST George? They require the BSB as nnn-nnn but my Out of the Box install (trying to do as little customization as possible) keeps putting the - at the font of my Transit Routing Number.
Is this not possible without changing the window?
PLEASE READ BEFORE POSTING
Please only post comments relating to the topic of this page.
If you wish to ask a technical question, please use the links in the links section (scroll down, on right hand side) to ask on the Newsgroups or Forums. If you ask on the Newsgroups or Forums, others in the community can respond and the answers are available for everyone in the future.