EDI 300

From UG

Revision as of 22:35, 14 November 2013 (edit) Alex (Talk | contribs) (→Message Template) ← Older edit		Revision as of 23:00, 14 November 2013 (edit) (undo) Alex (Talk | contribs) (→Message Template) Newer edit →
Line 191:		Line 191:
	[[File:300 template new general.JPG]]		[[File:300 template new general.JPG]]
		+
		+	==== Dangerous ====
		+
		+	If Cargo Nature = Dangerous add the following controls
		+
		+
		+
		+	==== Reefer ====
		+
		+	If Cargo Nature = Reefer add the following controls
	=== Message View ===		=== Message View ===

---

Revision as of 23:00, 14 November 2013

Contents 1 Intro 1.1 Message Flow 1.2 Limitations 2 Business Process 2.1 Actual Master BP 2.2 Estimated Master BP 3 EDI tab 3.1 Booking Request / Confirmation 3.2 Shipping Instructions 3.3 Status Updates 3.4 Events 3.5 Actions 3.5.1 300 Create 3.5.2 300 Update 3.5.3 300 Cancel 3.6 Message Template 3.6.1 Dangerous 3.6.2 Reefer 3.7 Message View 4 Data to Send 5 Reporting and Notifications 5.1 Master Comments Tab 5.2 Email Notifications 5.2.1 Email Template 5.3 Reports 5.3.1 997 Reporting 5.4 Log 6 Misc 6.1 Grouping inside Master 6.2 Extended Master Templates 6.3 Make Address Text firlds read only 6.4 Add Estimated vs Actual Haz 6.5 Tags for required fields 7 EDI Vendor Implementations 8 Wiki source files

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.

See #Message Template

300 Update

Template to update 300 request.

See #Message Template

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.

Dangerous

If Cargo Nature = Dangerous add the following controls

Reefer

If Cargo Nature = Reefer add the following controls

Message View

Is a read only version of #Message Template.

Data to Send

• see OOCL 300

Reporting and Notifications

Master Comments Tab

Suggest not to duplicate here since we have log on EDI tab.

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

Wiki source files

File:BR+SI+designs Nov13a.xls