You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am investigating how one might update the library to generate the trailer record aggregates. At first this seemed to me like it should be a relatively simple task by following some of the ACH library Create() patterns and iterating through the hierarchy.
However as I've come to understand the file specification more, and from reading through the bai2 library code, I can see counting the continuation records is becoming a bit of a foil. In particular, reading through string() in pkg/lib/record_transaction_detail.go#L114 and reading through util.WriteBuffer()pkg/util/write.go#L16, I can see that the total number of records is also directly tied to the file's Physical Record Length which follows the rules of the file spec.
I have some ideas of how I could count the number or records, which I can present both here and/or in a PR but I am curious, what are your thoughts on this issue, and why weren't the aggregate fields calculated in the design of the library to this point?
The text was updated successfully, but these errors were encountered:
Here is one idea I had. Give each record type a recordCount() function like this. You would reuse the existing compile logic in string() to find the total records.
I am investigating how one might update the library to generate the trailer record aggregates. At first this seemed to me like it should be a relatively simple task by following some of the ACH library
Create()
patterns and iterating through the hierarchy.However as I've come to understand the file specification more, and from reading through the bai2 library code, I can see counting the continuation records is becoming a bit of a foil. In particular, reading through
string()
in pkg/lib/record_transaction_detail.go#L114 and reading throughutil.WriteBuffer()
pkg/util/write.go#L16, I can see that the total number of records is also directly tied to the file's Physical Record Length which follows the rules of the file spec.I have some ideas of how I could count the number or records, which I can present both here and/or in a PR but I am curious, what are your thoughts on this issue, and why weren't the aggregate fields calculated in the design of the library to this point?
The text was updated successfully, but these errors were encountered: