rubyritas / ach Goto Github PK

Hey @jm81, thanks for merging the last PR and making the necessary fixes!

I noticed you didn't release 0.6.2 to rubygems yet, but instead of asking you to do it, I'd like to step forward to maintain the project as you mention in the readme note.
I'm currently working on two projects that uses this gem at job, one already in production, so me and also a few colleagues would be able to spare some work and/or personal time if necessary.

If you like the idea, my rubygems handle is "henriquegasques", and the repo could be transferred to my account? Let me know if you'd rather do it another way.

As far as taking over or helping out with maintaining, that would be awesome. I can give collaborator access as needed or if you'd like to put the official repo on another account, I can just update the README to point there. And then I could add you as an owner of the gem on rubygems.org. If you have an account there and want me to so, just let me know your email or handle for rubygems. But you can also just let me know when it's ready for a new gem version to be pushed and I can do so though it might take me a couple days.

Originally posted by @jm81 in #66 (comment)

Could you release the same-day ach change to a new version?

Thanks,

-LostHawkGSW

Does this gem have any support for parsing ach files?

If not I may take a crack at it, maybe by allowing a string to be passed in the initialize method in lib/ach/ach_file.rb?

Thanks for sharing this gem.

The repo doesn't have any tag for recent released versions, which and tools like Dependabot can't help describing what changed between one version to another

Bundler's docs suggest the gem-release to handle releases and it has gem tag gem bump -t to help with this

Hi there,

We are using ACH gem in production to generate batch files for Chase bank, however company_identification we have to use is 10 digits company ACH ID instead of 9 digits Company TAX ID so we end up changing these lines to accepts 10 digits numbers

https://github.com/jm81/ach/blob/master/lib/ach/records/batch_control.rb#L19
https://github.com/jm81/ach/blob/master/lib/ach/records/batch_header.rb#L17

Would you consider relaxing company_identification requirement to have at least 9 digits instead of have exactly 9 digits (or having 9-10 digits)? I can send a pull-request.

\A\d{9}\z => \A\d{9,}\z or \A\d{9}\z => \A\d{9,10}\z

I'm not really familiar with ACH (just started with a new company), but according to this doc http://www.regaltek.com/docs/NACHA%20Format.pdf Company ID is supposed to be 10 digits unless I'm missing something.

Hi,

I'm getting .rvm/gems/ruby-2.7.7@brokerage_engine-2_7_rails_5_2/gems/ach-0.4.11/lib/ach/field_identifiers.rb:54: warning: Using the last argument as keyword parameters is deprecated warning messages when running @ach_doc.to_s. Please help and let me know if this is something I need to worry about. Thank you so much!

Hello!

I used this gem to generate an ACH file for our bank, submitted via their https connector. The feedback that we got from the bank was that the file was invalid due to "extra blank lines" between each line of the file.

I saw that the file used Windows line endings (CRLF), and converted it to use UNIX line endings (LF), then resubmitted the file. It worked properly after that change.

I see in the code that it's joining lines with CRLF (https://github.com/jm81/ach/blob/master/lib/ach/ach_file.rb#L54) - is that something that's in the spec, but Bank Of America wants something different? Or something that might be useful to be tunable when building a file with the gem?

In file_header.rb, File ID Modifier has a default value of 'A', and a validation regex. In the file_identifier.rb, the setter performs validation on the provided file ID modifier and does not consider the default value. In my case, I provided a nil for file ID modifier thinking that it should be set to the default, but rather, an error was raised that the value does not validate against the regex.

What's the purpose of the default value when used with a validation regex?

Could you explain why ACH returns Tuesday as the next business day for Fri-Sun? That's been a recurring issue for us. Thanks for all your work.

Given the example ach file ach.txt:

101 000000000 0000000002112151052A094101BANK NAME              BANK NAME                      
5220COMPANY NAME                        1123456789PPDDESCRIPTIO211215211216   1000000000000001
62200000000000000000000      0000000100EMPLOYEE NAME  EMPLOYEE NAME           0000000000000001
822000000100000000000000000000000000000001001123456789                         000000000000001
9000001000001000000010000000000000000000000000000000100                                       
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999

Read it then write it to ach2.txt:

ach = ACH::ACHFile.new(File.read("ach.txt"))
File.write("ach2.txt", ach.to_s)

Content of ach2.txt becomes:

101 000000000 0000000002112151052A094101BANK NAME              BANK NAME                      
5220COMPANY NAME                        1123456789PPDDESCRIPTIO211215211216   1000000000000001
62200000000000000000000      0000000100EMPLOYEE NAME  0000EMPLOYEE NAME       0000000000000001
822000000100000000000000000000000000000001001123456789                         000000000000001
9000001000001000000010000000000000000000000000000000100999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999

I expect the ach2.txt to be the same as ach.txt.

It seems that, by default, when parsing or creating an ACH, non-ascii characters are replaced with a space or removed by replacing it with an empty string. That seems a bit dangerous since it's not really clear that it's doing it, and that character might be in an important position, so simply "ignoring" it might not be what people really want. I think at least a warning should be given, but for my current case, It might be ideal to consider the file to be invalid, or maybe only the section which has the bad character.

The batch control and file control records both include a field called entry_count. This field should actually include both the detail records and any addenda records.

Hi, I've been doing some digging and I have a couple of questions the versioning of the holidays gem in ach.gemspec.
s.add_runtime_dependency('holidays', '>= 1.2.0', '< 5.4.0')

1. Do versions above 5.4.0 affect this code in unexpected ways?
2. It seems like quite a range of versions, is there a need to support this range? (I ask because I see that TravisCI is failing on holiday gem 3.0.0)

Thank you in advance!

Any chance that IAT transaction formatting will get added?

I might be the issue here, but wanted to raise as I couldn't find any call in the code setting batch_number in the header

We're currently using this library to generate NACHA files for some internal payment processing and it works well. However, we recently ran into an odd quirk with on specific bank: company name in the batch header is case sensitive!

I monkey-patched out version so :company_name is the only field that isn't converted to uppercase, but the solution isn't ideal. I'm fine adding a patch for this if you'd prefer, but I wanted to report it first as a matter of making the quirk known.

Want me to patch this?