Due Date: 1 day.
Attach: Excel, PDF
Requirements: Parsed and neatly "html mail" formatted ASC_X12 856 Ship Notice. See attached pdf and excel for how I want the email formatted, almost exactly.
If 856 was valid, send Accepted 997, If 856 was not valid, send Denied 856 using methods provided.
EDI Parser is written. See attached '[url removed, login to view]' and the output '[url removed, login to view]' to see how parser already places information into the corresponding loops.
For understanding what each loop and segment is, see the eidx specs at: [url removed, login to view]
A brief overview:
Each EDI "line" (called a segment) is seperated by $this->segmentTerminator,
Each section in that line, (called an element) is seperated by $this->elementSeperator
The edi specs will mention segment and elements in this format:
O or M means optional or manditory
field size and max field size is specified
where * is the elementSeperator and ~ is the segmentTerminator:
HL01 is pos1 in HL segmengt, HL02 is pos2 in HL segment...
In the EDI document, there are loops. Take a look at the parser output to see how the loops are determined.
Loops can contain other loops. Loops begin and end and are determined by certain mandatory segments. See the EIDX Specs.
Notice that there is a layout in the EIDX specs of how the loops are structured and what valid items are in each loop. (Use segment tables pg 1 and 2).
Now each EDI document begins and ends with a ISA and IEA. This contains information about the sender and reciever, the date, and Interchange control number.
In side of Each Interchange Transcation, can be 1 or more Functional Group transactions, which start with GE segment and end with GE segments. For our purposes, we will only have one function group per interchange transcation.
Within each group transcations can be one or multiple Transactions Sets, which begins with ST segment and SE Segment. For our purposes, we will only have one transaction set per functional group transactions.
A special note about the SE Sement:
The SE segment's SE01 pos indicates how many segments are inside the transaction set which also includes ST and SE segment as well. This should be validated.
Validation is important!!
- Validate data
- if $this->getSenderCode != $parser->getSenderCode, save the file using save file method and return an array('saved', $loc);
- make sure all mandatory fields are accepted
- make sure incoming document is complete (contains ISA, and IEA segments),
- make sure all required fields are set.
- make sure 856 po_number (segment PRF) exists in database ( use checkPurchaseOrder($poNumber), follow how 997 -process function uses it. )
- make sure 856rcvd isnt already set in the databse, ill provide you with a function that handles this.
- if 856rcvd is set, set $this->errors with a warning, and use savedFailedDocument method, follow how 997 does it.)
- make sure SE01 segment count actually equals the number of segments, functions are already written, see 997->process();
- do any other validation you see as important.
If 856 basic params are parsable, write to database and send either a 997 accepted or a 997 rejected using simple methods I will provide.
wherever you return false for errors, store error message in $this->errors array. The failed document will be saved to file system and $this->errors will be emailed to backend development to hadnle the issues.
whenever you return false, reject the 997 using method provided.
whenever you return true, accept the 997 using method provided.
Please make all use of me as needed to get you up to speed.
I am available by phone and by email. Contact information will be provided at start of project.