Version 20.1.1 |
Scroll |
Note: The Item reference numbers in the document are from the BluJay Solutions Control Tower issue tracking system and are intended for use by BluJay Solutions Support.
The TMS ORDER XML has been enhanced to include additional information to create TMS Supplier record.
▪Additional data elements are also mapped to the ORDER XML.
▪Email address, transaction type and shipper details entered in CT are now available to TMS system to process the order.
WSO2 Mapping Changes:
CT Field |
TMS Field |
Notes |
TransportOrderVarious > TransactionType |
Order > DirectionCategory |
Valid values are Inbound & Outbound (case insensitive). Need to maintain same codes in CT as code and description. If different transaction type is user (i.e. other than Inbound & Outbound), then the Order will not be sent to TMS. |
PickupParty (PKUP) > Email address |
Instructions > Instruction Visibility |
Email address available against PKUP party to be sent to TMS. If an email address is not available against pickup party in CT, then the Pickup Party will not be sent to TMS. Multiple email addresses against one party is not a valid scenario. Only one Instruction Visibility tag with qualifier of 0 needs to be included.
|
T.O > Supplier (SPLR) party |
SupplierDetail |
Supplier party added in CT will be sent as Supplier party to TMS. Check below individual field mapping of Supplier party. |
Supplier Mapping:
Segment |
TMS field |
CT Segment |
CT field |
Notes |
SupplierDetail |
Name |
TransportOrderParty >> Party Type=SPLR >>Address |
Name |
As is |
|
Address1 |
|
Street |
Cut the street value every 32 chars. i.e. TMS address1 accepted value |
|
Address2 |
|
Street |
|
|
Address3 |
|
Street |
|
|
|
As is |
||
|
Country |
|
Country |
As is |
|
City |
|
City |
As is |
|
State |
|
State |
As is |
|
Zip |
|
Zip |
As is |
|
TimeZone |
|
|
Default value = ZZZ |
|
ShipWithPrefix |
|
|
Not required |
CT-TMFF-CM US Integration Enhancement
Based on the current enhancement, when CT receives updates separately from TMFF and CM US against a T.O, the same T.O will be updated in CT without duplicating the T.O.
▪TMFF sends the GShipID (BackboneRefId) as well to CMUS along with UNID.
▪CMUS will store the GShipID in a new field at the same level as the UNID is currently stored and passes it through to CT while sending shipment information. CMUS will not use the GSHPID for any functionality.
▪CT will use the GShipID sent from both TMFF and CMUS as the Match Key so there is a shared data field for creating and updating T.Os.
The following changes have been done as a part of this development:
▪C.O XSD has been updated with a new non-mandatory field <BackboneRefID> in the <BillOfLanding> segment.
▪CM US – CT mapping has been enhanced.
Resolved Issues:
JIRA -Id |
Description |
KCT-15621 |
T.O. item weight and volume details are now displayed appropriately. |
KCT-15780 |
Users are now able to create a new company for CLX customer. |
KCT-15697 |
T.O.s created in CT for Inland shipments are now being passed to the correct Owner ID in TMFF |
KCT-15661 |
LN Infor JAR is now generating the TXT file for shipments. |
KCT-15601 |
The issue of UPS EDI 240 file processing failure due to mandatory optional element is fixed. |
KCT-14481 |
While entering dimensions of an item, the weight and volume values are now summing up to the item level and displayed accurately. |
KCT-15844 |
UPS EDI files are now being picked from the path & processed successfully. |
KCT-15815 |
The following mapping changes have been done for Sea segment in TBLTO Equipment: oWeight à CtnTOTWGT oWeight Unit à CtnTOTWGT_UT
|
KCT-15817 |
Volume is now being calculated and updated while entering dimensions irrespective of UOM changes |
KCT-15838 |
Sending Milestone updates from CT to TMFF is working fine even when sbackbonerefid is null. |