As you, probably, know Canadian EFT (ACH) formats vary from bank to bank. You have already set the default CA EFT to RBC. Excellent. Our existing and particularly prospective clients that use other banks need a bit more flexibility to choose Business Central. For example, those that use Scotiabank (CPA005 EFT standard) need that OOB EFT functionality in Business Central must allow the following:
1) Date format: YYYDDD (current is YYYYDDD and substring Transformation Rule does not work as it should);
2) File Creation Number (FCN) must be available on Detail and Footer (it is already available on Header)
3) Originator's cross-reference number (19 characters) on Detail - Users must be able to map this field in Data Exchange Definition to "Document No." Field on the Payment Journal
Because this can be of use to a lot of exiting and prospective Business Central users, my colleagues and I hope that the above suggestions can be considered by Microsoft Team soon.
Thank you,
Iaroslav
(Consultant at BDO [Partner])
Comments
Can anyone tell me the data format I need to put on the data exchange definition for CYYDDD?
Category: Financial Management
I'm not sure why this has gone down as a localisation for NA only, it appears that banks in other areas have similar issues - HSBC (and some other banks that use the BACS Standard 18) in the UK require YYDDD formats.
Looks like another extension is required...
Category: Financial Management
We are in the first phase of our implementation project to move from NAV 2013 to BC SaaS and are just now working on the Canadian EFT setup with our partner. During our testing we have discovered that the OOB data exchange definition which is supposed to be for Royal Bank of Canada (RBC) does not actually follow the RBC ACH specification for some fields as per the document posted on their website (https://www.rbcroyalbank.com/ach/file-451772.pdf). The exported file uses a Julian date with two-digit year, but the RBC spec requires a four-digit year (I confirmed this with our account manager at RBC). There are also several fields which RBC requires to be populated for payments destined to US-based banks, and the OOB file contains blanks for these fields. While confirming with our account manager these differences, they also noted that if a customer submits a file with any errors which result in the file being rejected, the bank will charge a service fee. This has real-world financial implications for customers who do not realize these discrepancies exist in the 'RBC compatible' OOB data exchange definition and attempt to use it as-is.
Category: Financial Management
Hi all
We're beginning to look into this area (EFT in general) and would like to create a small V-team with partners to make sure we're making the right changes. If interested, could you please send me an email at soalex@microsoft.com
Thanks in advance!
Best regards
Søren Alexandersen
Program Manager, Business Central Localization
Category: Financial Management
I can confirm that Canadian EFT out of the box for BC requires coding 99% of the time. Data Exchange definitions tables should at least have the information needed for us to be able to map the format.
MS should include a CPA005 format, which is used by BNC, Desjardins and TD
https://www.payments.ca/sites/default/files/standard-005.pdf
Thanks
Category: Financial Management
I am really happy that I stumbled upon this post. I thought that I just wasn't smart enough to figure this out. But in fact the configuration of a data exchange definition to work with CPA005 is not supported by BC out of the box and requires custom development. At least I can stop banging my head against the wall and look to a solution that involves custom coding.
Thank you laroslav and I hope that MS is listening.
Category: Financial Management
Business Central Team (administrator)