EDI 300
From UG
(→Events) |
(→Events) |
||
| Line 119: | Line 119: | ||
'''300''': | '''300''': | ||
* '''created''' (new) - 300 was initiated by Jag user, XML created by CT2 and waiting scheduled time to be transmitted to VAN/Carrier | * '''created''' (new) - 300 was initiated by Jag user, XML created by CT2 and waiting scheduled time to be transmitted to VAN/Carrier | ||
| - | * '''transmitted''' - | + | * '''transmitted''' - 300 was posted into VAN/Carriers FTP folder, waiting to be read |
* '''updated''' - Jag user initiates updates to existing 300 | * '''updated''' - Jag user initiates updates to existing 300 | ||
* '''cancelled''' - Jag user cancels existing 300 | * '''cancelled''' - Jag user cancels existing 300 | ||
'''997''': | '''997''': | ||
| - | * '''acknowledged''' - no errors (corresponds to 997 accepted) | + | * '''acknowledged''' - 300 has no errors (corresponds to 997 accepted) // set by VAN or carrier |
| - | * '''error''' - significant errors found (syntax, structure, validations, etc)(corresponds to 997 rejected) | + | * '''error''' - significant errors found in 300 (syntax, structure, validations, etc)(corresponds to 997 rejected) // set by VAN or carrier |
'''301''': | '''301''': | ||
| - | * '''conditionally accepted''' - ( | + | * '''conditionally accepted''' - (300 was set as conditionally accepted by carrier) |
| - | * '''pending''' - ( | + | * '''pending''' - (300 was set as pending by carrier) |
* '''rejected''' (300 was rejected by carrier) | * '''rejected''' (300 was rejected by carrier) | ||
* '''confirmed''' (300 was confirmed by carrier) | * '''confirmed''' (300 was confirmed by carrier) | ||
Revision as of 22:06, 14 November 2013
Contents |
Intro
EDI 300 is a Booking Request message.
It is an outgoing Message: Jaguar sends info to Carrier.
The shipper or forwarder can use this transaction set to reserve cargo space.
Message Flow
Below covers most scenarious except updates from carriers.
Limitations
We impose this limitation:
At any moment in time there could be only one Booking Request/Update 300 and related Booking Response 301
Theoretically we could send multiple alternative booking requests to:
- different steamshiplines (to maximize chance of any booking)
- same steamshipline (say different dates)
but we are not going to support this now.
Business Process
Below is defined for New Booking.
Actual Master BP
When Master contains actual data.
- 1/ Combine CTs into GRPs and then into Master (currently not all operators are doing this at the moment of booking)
- 2/
- Enter all missing booking related information (if any)
- Pass all validations.
- 3/ Send booking request from #EDI tab. Most data will come from Master fields.
Estimated Master BP
When Master contains estimated data.
- 1/ create empty master from Master template
- 2/ steps 2,3 from #Actual Master BP
- some data will be estimated and some of it entered on EDI template (example: weight per container)
Note: User will wrap CTs inside the master with one or more groups later on (before EDI 301 is transmitted)
EDI tab
This tab is active only if:
Master#Steamshipline in given Master is on the list of active carriers in OS Admin (see OS#Steamshiplines) AND Master#Master Mode of Transport = Full Container Load (AW) OR Full Container Load (MLB)
NOTE: ----- When Master MOT is set as FCL (AW or MLB) then CT/GRP could have MOT set as: FCL (AW) or FCL(MLB) or Client Consol
See mock up below.
Booking Request / Confirmation
Columns:
- ANSI# - 300 or 301 or 997
- Message type - Booking or Confirmation or Acknowledgement
- Date - date/time of update
- Event - see #Events
- By - Jag user name (First Name + Last Name) or CT2 or Carrier
- View Message - Link to human readable copy of a saved message - #Message View
- XML - XML version of a message
Rows:
Each row corresponds to one update by operator or CT2 system or VAN/Carrier.
Actions:
- create - see #300 Create
- update - see #300 Update
- cancel - see #300 Cancel
Shipping Instructions
See EDI 304
Status Updates
See EDI 315
Events
Each event relates to 300 message and leads to a new status with the same name.
300:
- created (new) - 300 was initiated by Jag user, XML created by CT2 and waiting scheduled time to be transmitted to VAN/Carrier
- transmitted - 300 was posted into VAN/Carriers FTP folder, waiting to be read
- updated - Jag user initiates updates to existing 300
- cancelled - Jag user cancels existing 300
997:
- acknowledged - 300 has no errors (corresponds to 997 accepted) // set by VAN or carrier
- error - significant errors found in 300 (syntax, structure, validations, etc)(corresponds to 997 rejected) // set by VAN or carrier
301:
- conditionally accepted - (300 was set as conditionally accepted by carrier)
- pending - (300 was set as pending by carrier)
- rejected (300 was rejected by carrier)
- confirmed (300 was confirmed by carrier)
- updated (300 was updated by carrier)
- canceled (300 was canceled by carrier)
Actions
See actions available for each state:
General Rule ------------ You can only send cancellations on confirmed, conditionally accepted or pending bookings.
300 Create
Template to create new 300 request.
300 Update
Template to update 300 request.
NOTE: ----- We are not pulling data from last saved state of 300. Per Marc - pull from Master/other entities as for new 300. Lets discuss/confirm.
300 Cancel
Present Confirmation pop-up:
Are you sure you want to cancel this Booking? [OK] [Cancel]
On OK:
- schedule cancellation message
- send e-mail to user who submitted with details of submission
On Cancel return user to Master Editor.
Message Template
Opens in pop-up.
Fields are defined in #OOCL 300.
All non-yellow fields are read-only and are pulled from Master entity or other entities.
Yellow fields define interactive form controls.
See mock up below.
Message View
Is a read only version of #Message Template.
Data to Send
- see OOCL 300
Reporting and Notifications
Booking Status Line
See mock up under #Booking Menu.
Shows latest status/event related to the Booking.
Until 301 has been received I suggest to show 300 statuses:
- new, transmitted, accepted, rejected
After 301 is received I suggest to show 301 message statuses:
- confirmed, rejected, conditionally accepted, pending
It is possible to post more info here, for example BOOKING UPDATED but it would be more complex and not sure if needed -alex-
Master Comments Tab
Post all events/updates related to all messages here:
- Add record every time message was sent or received
- Record content of the message, operator who initiated.
TBC: Marc had idea here - need to ask again
Email Notifications
- notification of 997 (TBC)
- email defined in #Booking Preview Screen (TBC)
Email Template
'''From''': cybertrax@jaguarfreight.com [cybertrax@jaguarfreight.com] '''Sent''': <date> '''To''': <user name> '''Subject''': Rejected: <protocol number><message type><related master numbers> Dear <user name>, The following transmission was rejected: <protocol number><message type><related master numbers> This is automated message generated by Cybertrax 2 System.
- <protocol number>: 300, 301, etc
- <protocol name>: Booking Request, etc
- <related master numbers>: Master numbers related to thi transmission. Example: M1234, M12414
Reports
997 Reporting
Optional for 300 (since we have 301 as a response).
Required for 304.
Dashboard similar to 997 dashboard in SI EDI (Data2Log).
Provides counter of Rejected messages.
Must be based off of #List Masters.
Log
Log all related events:
- when Process started
- when Process ended
- 300 sent
- 301 received
- 304 sent
- 315 received
- any 997 received
Additional info to include into log event description:
- related list of Master numbers
- status for incoming messages (such as accepted/rejected)
Misc
Grouping inside Master
Add ability to group/ungroup selected CTs inside the Master.
Extended Master Templates
Following additional fields must be copied at the moment of creating a template from Master Clone.
Add column / filter of user who created them.
TBD: ask opers/team leads if they cross share
or there is a benefit of cross sharing
Make Address Text firlds read only
Make the following fields read-only on Masters profile:
Master#Master Shipper Text Master#Master Consignee Text Master#Master Notify Text Master#Master Pick-up Text Master#Master Delivery Text
Add Estimated vs Actual Haz
Tags for required fields
EDI transmission assumes strict validations.
All required fields mast be marked as colored "*" (say orange).
Add note (in orange): "* Required fields for Booking Confirmation"
EDI Vendor Implementations
- CargoSmart: CSmart 300
