Support Deposit Tickets/Slips

[adamdecaf]

What were you trying to do?
Deposit Tickets / Slips are physical pieces of paper to describe a check deposit. Typically they're used if you wanted to partially cash out a check. Often X9 files contain this as an additional image (standardized in X9.100-180).

Some implementations have designated 61 as a new record type for this information while others have used standard records. Reader implementations can understand either the new record type or usage of non-valid ABA numbers to signify this slip record. While X9.100-180 offers a standard format for 61 record types not all implementations fully comply.

Source: https://allmypapers.com/iclvariations/

What did you expect to see?
Additional record types which can be parsed in an understandable way should be supported by the ICL library.

[ryanmwetzel]

For the deposit tickets, they look similar to this but more like a check (attached). These can be constructed on data already included in the ICL file, mostly the Credit record, and get the BOFD name from addendum record. I've included an example below so you can see how the JSON fields map to the image.

The only the question would be a boolean indicating if your vendor requires a deposit ticket vs credit record.

creditItems: [ { ID: "", auxiliaryOnUs: "100", externalProcessingCode: "", postingBankRoutingNumber: "123456789", onUs: "12345678", itemAmount: 100, creditItemSequenceNumber: "1", documentationTypeIndicator: "G", acccountTypeCode: "1", sourceWorkCode: "06", userField: "ABC Roofing" } ]

[ryanmwetzel]

Also, to be clear the MICR data is as follows:

check number | routing number | account number (on-us) | transaction code (aux on-us) | amount