JPMorgan Single Use Accounts Implementation

pfaloney

Well Known Member
I am been assigned the task of implementing JPMorgan's Single Use Account as a payment option. Even though I do have a relatively good grasp of the process now, it is not like any of the normal Check/Ach processes that I have have implemented in the past. Some of the new issues are:

1: Use of name and email instead of bank information (issue is getting the proper information from the address book tables)
2: Records are variable, not fixed length.
3: All information, including detail information is on a single line for each payment.

I was going to use the PPD format as the file create. However, is is a Fixed Width format and I am not sure it can be modified to a variable width.

Anyone have suggested and handling the first two issues.

Thanks in advance
 
Last edited:

BOster

Legendary Poster
Funny. Currently working on the exact same thing. Actually it is complete just waiting for a go live date.

1. We have to send an email as well and we simply get that from the electronic addresses in the address book for the vendor.
2. When you say "Records are variable" do you mean comma separated (CSV)? They want a CSV file from us. Within that CSV file some of the fields in a single record have additional embedded CSV files (pipe delimitted instead of comma) - sort of a CSV file in a CSV file record.

The biggest issue I ran into with them (Chase/JPMorgan) is that they don't really conform to the accepted standards for CSV files (RFC4180). Additionally you will need to parse a response file (same file with additional info filled out) to look for errors and possibly update JDE. Because of their malformed CSV data (the RFC4180 thing), you wont be able to use any standard JDE tools (or probably any other CSV tools) for processing CSV files (outputting or parsing) - it will choke on them. You will have to "roll your own". Quite some time ago I created a CSV library that basically was a JDE wrapper to libcsv and with some mods to my internal lib I was able to use that, but it was still quite tedious.
 

pfaloney

Well Known Member
Funny. Currently working on the exact same thing. Actually it is complete just waiting for a go live date.

1. We have to send an email as well and we simply get that from the electronic addresses in the address book for the vendor.
2. When you say "Records are variable" do you mean comma separated (CSV)? They want a CSV file from us. Within that CSV file some of the fields in a single record have additional embedded CSV files (pipe delimitted instead of comma) - sort of a CSV file in a CSV file record.

The biggest issue I ran into with them (Chase/JPMorgan) is that they don't really conform to the accepted standards for CSV files (RFC4180). Additionally you will need to parse a response file (same file with additional info filled out) to look for errors and possibly update JDE. Because of their malformed CSV data (the RFC4180 thing), you wont be able to use any standard JDE tools (or probably any other CSV tools) for processing CSV files (outputting or parsing) - it will choke on them. You will have to "roll your own". Quite some time ago I created a CSV library that basically was a JDE wrapper to libcsv and with some mods to my internal lib I was able to use that, but it was still quite tedious.

Records are variable length as is the header record is a different length than the Detail records which each can be a different length. I am using R04572T1 as the basis for the output file so we get the vouchers marked as paid. What did you use?

As for JPMorgan, this is not my first project with them.
 

BOster

Legendary Poster
Records are variable length as is the header record is a different length than the Detail records which each can be a different length..

Ah, I see what you mean. There is also a trailer record on the response file that has a different number of fields just like the header record. We modified R04572. The way the BA spec'd it, we setup a new payment instrument for SUA payments and then we set those vendors up with that payment instrument as the default. We simply do a normal "check run" using a version of R04572 that data selects on the SUA payment instrument. We also added custom processing options to R04572 for outputting the CSV file and any other data it needs. The check number becomes the payment ID in the SUA file and the check stub records (invoices/POs being paid) are output to the CSV file as well. R04572 has most of the data that we need for the CSV file so it worked pretty well to simply use that as the process for generating the SUA file.

I really don't know that much about the A/P module from a functional standpoint so I don't know if the direction we went has any advantages/disadvantages over using R04572T1.

Because of the format of the "CSV" file you will probably have to manually create it and parse it by simply writing directly to a text file. You probably won't be able to use a UBE that outputs to CSV file or a table conversion for parsing.
 
Top