Creating flat file in JDE

jimmymac

Reputable Poster
We are having an issue trying to create a payment detail file that is going to be sent to American Express. I am using business function B34A1010 Open Flat File to create the .txt file. Then using B34A1010 Write One Line to Flat File to output header, detail, and trailer records.

Our issue is that American Express requires a file with a record length of 220. I am loading the various data elements into a variable using data dictionary item GPTX. Then doing a right pad function to pad the variable with blanks to a length of 220.

After creating the file, using a tool like UltraEdit, it certainly appears to have a record length of 220. However, Amex is stating the file has an incorrect record length, that's about all they are telling us.

Any advice as to how to address this record length issue would be appreciated.
 
Jimmy,

Two Questions:

1) Can you find out how long Amex is saying the record is? (No harm in asking.)

2) On what machine/Operating system is the flat file created?
 
Thanks Peter,

I have asked for more clarification as to what length they say it is, and which record had the wrong length, or did all. No response overnight.

I am actually running the job now locally on my windows fat client, with the output file being created on an Windows 2008 server. Then we upload that .txt file using their website.
 

Attachments

  • 185727-AMEX.txt
    888 bytes · Views: 168
Maybe it's not a problem of oneworld. if you upload windows textfiles to machines with a unix (linux)- os you will have problems. can you set a upload parameter like "Text"? textfiles shouldn't be uploaded as binary / in binary mode.

windows "end of line" uses 2 characters, linux and mac only one

if you cant' find out by requesting AE, you can test this:
1. FTP-upload the file in textmode to a linux server,
2. FTP-download the same file in binary mode. (UltraEdit shows maybe something like ^M at the end of each line)
3. upload to american express by the website
 
Have you tried BSFN N0800500

It brings back the text in D200 (200 long)

Have you checked the length yourself?
 
Thanks, yes we have checked and our length when viewing in notepad, wordpad, or ultra edit is 220.

Our JDE system is replacing a process that a Peoplesoft process that is currrently outputing a file to Amex. One thing we do notice is that in the JDE file, there is an OA Line feed and OD Carriage Return characters at the end of each record. While in the current PSFT file that is being created, only has the OA Line Feed.

Don't know why that would cause an issue but that is the only difference. At least in using the function B34A1010 there does not appear to be any way to control that. Any thoughts? or could the extra OD be a red herring here.
 
FYI, we appear to have the issue resolved. On the Amex upload website, there is a button 'Set ASCII'. When we select that and then upload the file, it was accepted and passed the Amex edit.
 
You mentioned that your JDE system is the replacement for a former PeopleSo ft process.
Oracle document 631627.1 (Flat File Use in EnterpriseOne) explains:
s, Unix, AS400) where the table conversion creates the flat file.
 
Jimmy,

What you describe is the typical Unix (one character line-feed end-of-line) verses Windows (two character line-feed and carriage-return end-of-line) problem that WonderWhy pointed out (and that I suspected when I first read your initial post). There are ways within JDE on Windows to create text files with the Unix end-of-line.

It seems that Amex are aware of this potential problem for incoming interface files and have provided a solution.

I'm glad you got it resolved - one way or another.
 
Back
Top