Has anyone used Dundas to create NACHA files for ACH upload? If so, could you share how you worked it out?
I’m not seeing this functionality, but it seems like it would be good use of Dundas.
NACHA file create with Dundas?
https://engineering.gusto.com/how-ach-works-a-developer-perspective-part-4/
https://engineering.gusto.com/generating-fixed-width-documents-in-ruby-introducing-fixy/
It doesnt look like it will be easy. I am not sure what the source is for the Fixy program so not sure if you would be able to export to excel and then right off use the excel file you might have to convert it to TXT.
Not sure what your data in Dundas looks like and how familure you are with the details of an ACH file.
Maybe you can get the company Gusto to help you out?
I can get the data to come out of my Oracle Database correctly, but I’m hoping I don’t have to build a little standalone JAVA app to get the file to export in the right format and automate it dropping into a location and/or sent via email since that is the only piece I’m missing. It’s not looking like it though, since the excel/csv loses all the leading zeros that must in the file for the format to be correct.
I reviewed that first Gusto link yesterday. Their solution is a slightly different method to solving the problem that I would go, but they have lots of good info for sure.
So, feature request maybe?
The only way you will not have to do something else to it is for Dundas to have that as an option for export. The ACH file format is not only an old way of doing things but highly specific and if everything is not exactly right it fails completly. That is why it is bets to have a standalone program that adjustments can be made in it to get the file right.
I honestly think it would not be a good idea for Dundas to try and match this file format for export.
They might get it right for a general case but there will be too many it not working support calls then they will have to put in a setting for adjustments. Possibly to text or some format that the program that converts the data to ACH reads (but you can have it export to excel and just open it save it as txt).
Now if Dundas wants to open up what it can do and work on this and then be able to say "We can make you ACH Files for you" then they can look into all the different ACH file formats (yes there are many different type) look at first link and at the 3rd to last paragraph with the link to the rulebook. They could get into that market and possible pick up a few clients, maybe. But that for them to decide if it is all worth it or not. I am surre there some formula like complexity of design * people willing to get something new to replace something that works * how many people need this and dont have it divided by risk of investment of development time blah blah hick up sneeze. (smilly face)
I had looked at creating ACH files in Dundas, and I agree with James Davis: probably not a good use of Dundas. The real show stopper was the 94 characters per record because there isn't a clever way to strip the CR/LF from the end of the line, so out of the box, your recs would be 96 and instantly rejected. All the other rules depend if you're pushing money or pulling money from the target accounts touched by ACH transactions, and Payroll is a whole lot harder than Accounts Payable. As James cites, the rulebook is big and complex. I would also advocate the creation of the Dundas ACH file would be "hands off" and "lights out", meaning we'd want to avoid managing the file content with two or more tools. Our bank, by the way, uses an online access portal where credentialed users "drop" the NACHA file for the bank to submit to ACH.
However, if there were a group effort on this development, I think we'd be interested in at least the Accounts Payable path.
I' m only using it for Positive Pay so the format for my purposes is fairly simple. I guess I'll stick to writing it myself.
Dundas Export to Excel can be the start point, then change it to txt then open in notpad++ and strip out the CR/LF.
That could make things a little easier.
Sorry there is not an easy fully automated solution.
.
I did not try it before, but you can create custom .Net program for export and then use it as a new option if export. There is good sample on dundas website for that. and I kniw that dundas have such paid professionaal services for building extension to out of box features in dundas
I believe Mohammad is referring to the following sample that allows you to hook into the server event for export completed and do a custom action.
Did we give up too soon? Joyce is it possible that you can use this method? (I dont know if you know C# or have someone that does that can write it.)
NACHA compliant files are over-kill for Positve Pay in my opninion - must depend on your bank. In the USA, we only provide check number, check amount, payee name, and check date to our bank. And correct me, James: notepad++ will allow you to strip out just CR or LF, never both. If notepad++ can indeed strip both, then I'd be willing to write ACH files.
I have written an export of single use credit card account payments (SUA) which the users export in CSV from a dashboard. It's like Positive Pay on steroids in that the file also generates an email listing the items paid emailed to the payee with the credit card info. Dundas tweaked the CSV to remove extraneous spaces when replacing "unknown" with a space character for the dashboard readability,
The Positive Pay format is indeed very simple, but we are also looking at NACHA files for other purposes so I’m trying to determine if the best solution is homegrown or if we can use Dundas. Homegrown seems to be the way we are trending and I’m the one who would likely code it.
My employer uses JAVA as our primary language, but I’ve done more than my share of C# and ASP.NET so I’m sure we can work out something.