default value in ImmediateOrigin error is always displayed, regardless of value

[busitech]

ACH Version

v1.35.1 cli

What were you trying to do?

We were trying to validate an ACH file.

What did you expect to see?

We expected not to have an *ach.FieldError on line 1 because the file input to the program did not have a default value in ImmediateOrigin.

What did you see?

line:1 record:FileHeader *ach.FieldError ImmediateOrigin xxxxxxxxx is a mandatory field and has a default value, did you use the constructor?

How can we reproduce the problem?

Try validating any file. We are unable to avoid the error.

[adamdecaf]

If there's no value in the ImmediateOrigin field then an error will be displayed. Is the field blank?

With achcli you can supply a JSON file of the ValidateOpts settings you'd like to use.

achcli -validate custom.json ... 

Or you can disable all validation for a quick sanity check.

achcli  -skip-validation ... 

[busitech]

The field was not blank. There was a valid value in the ImmediateOrigin field, and the error was still displayed.

[adamdecaf]

Can you share more about the field's value or the full header line with me in private? adam@moov.io

[busitech]

ach-test.txt
opts.json

I am providing a test file for you, along with the options file and command line used for testing.

achcli-darwin-amd64 -v -validate opts.json ./ach-test.txt
moov-io/ach:v1.35.1 cli tool
------
line:1 record:FileHeader *ach.FieldError ImmediateOrigin 460000001 is a mandatory field and has a default value, did you use the constructor?
^^^^^^ why does this message appear, regardless of the value supplied? ^^^^^^
------
Describing ACH file '/Users/mfrederes/Downloads/ach-test.txt'

  Origin      OriginName               Destination  DestinationName          FileCreationDate  FileCreationTime
   460000001  Destination Name          090000018   Origin Name        4023  240517            0235

  BatchNumber  SECCode  ServiceClassCode            CompanyName       DiscretionaryData     Identification  EntryDescription  EffectiveEntryDate  DescriptiveDate
  0000001      PPD      200 (Mixed Debits/Credits)  Origin Name                             1460000001      Payment           240518              240515

    TransactionCode       RDFIIdentification  AccountNumber      Amount  Name                    TraceNumber      Category
    22 (Checking Credit)  09000002            100000000003       100     Credit Account          090000010000001  Forward

    TransactionCode       RDFIIdentification  AccountNumber      Amount  Name                    TraceNumber      Category
    27 (Checking Debit)   09000001            100000000004       100     Debit Account           090000010000002  Forward

  ServiceClassCode            EntryAddendaCount  EntryHash   TotalDebits  TotalCredits  MACCode              ODFIIdentification  BatchNumber
  200 (Mixed Debits/Credits)  000002             0018000003  100          100                                09000001            0000001

  BatchCount  BlockCount  EntryAddendaCount  TotalDebitAmount  TotalCreditAmount
  000001      000001      00000002           100               100

[adamdecaf]

460000001 is not a valid routing number, so that's why the error is returned. That error doesn't seem clear enough to tell you that's the issue though. The checksum digit should be 6 which would make it a valid routing number 460000006.

[busitech]

Immediate Origin is not restricted to routing numbers, and many banks we deal with require EIN, TID or Company Id in this field. I'm not sure the program should be assuming the field will contain a routing number.

[busitech]

Even the nacha.org website states, "Often your ODFI will have you insert your company ID in this field."

[adamdecaf]

I agree that it's very common to not use a routing number. That's why we offer ValidateOps which let you disable validation of Origin/Destination.

This library aims to implement the Nacha spec, but work for all real world situations. Currently I see the Nacha spec requiring that field is a routing number.

[busitech]

If the error message is updated to replace the has a default value language with has a checksum mismatch, use ValidateOpts to disable check digit validation if not using a routing number in this field or something similarly helpful, and the ValidateOpts only disable check digit validation on Immediate Origin in the header record only, then the issue we encountered will be resolved. Thank you!

[adamdecaf]

Yea we can do that.