Project

General

Profile

Actions

Task #17506

open

Task #18123: Ocean Sprint Planning for 04/06/2025 - 13/06/2025

User Story: Generate & Send HDO XML to CCS

Added by Redmine Admin 7 months ago. Updated 31 minutes ago.

Status:
QA
Priority:
Normal
Assignee:
-
Start date:
04/04/2025
Due date:
06/13/2025 (about 6 months late)
% Done:

100%

Estimated time:
64:00 h
Spent time:
GitLab ID:
2333
GitLab Milestone:
GitLab Ticket Number:
422
GitLab Time Logged:
288000
Lock Timeline Date:
No
gitlab project trace:
Ocean Sprint Planning for 04/06/2025 - 13/06/2025

Description

A House Delivery Order (HDO) in Ocean Import refers to a document issued by a Freight Forwarder (FFWD) in the CCS to the consignee or their representative, authorising them to take delivery of cargo followed by the IRN, which is also generated in the CCS.

A Freight Forwarder (FFWD) should be able to generate a House Delivery Order (HDO) in XML format from the FFS and send it to the CCS.

 

Pre-requisites:

  • A valid File Reference and HBL must be created and confirmed.
  • The BL Type should be either in Express Release (TELEX) or Original BL state.
  • Should have a standard invoice in FFS which has been fully or partially paid for cash clients.
  • The system should be configured with Freight Forwarder (FFWD)/Importer Codes/Broker CCS codes (available from CCS).

Acceptance Criteria:

1.      HBL Selection Interface:

a)      Implement a new screen listing all HBLs with the following columns:​

  • ATP
  • Vessel
  • Voyage No.
  • Master File Ref.
  • File Reference
  • HBL Number
  • Port of Origin
  • Shipment Date we do not such field in FFS system. I will display loadOption instead
  • Client Code + Name
  • Client Type (Cash or Credit)
  • Invoice Payment Status (Paid, Partially Paid, Unpaid)
  • Option/button labelled 'Issue HDO'

b)      Enable filtering options for users to sort and search HBLs based on:​

  • Client Code/Name
  • Client Type
  • Payment Status
  • Date Ranges
  • Other pertinent criteria

2.      HDO Issuance Process:

a)      Upon selecting a particular HBL from the list and clicking on the button “Issue DO”, the user is redirected to another screen (House Delivery Order) listing the existing details of the HBL listed below in a distinct section:

Labels:

Shipment Details Section:

  • ATP
  • Vessel Name
  • Voyage Number
  • Origin
  • Destination
  • Container Ref.
  • No. of Packages – Type of Packages (e.g 30 PK)
  • Weight
  • Volume
  • Goods Description

HBL Information Section:

  • Master File Reference
  • File Reference
  • Master BL Ref
  • HBL Reference
  • Shipper
  • Consignee
  • Client Type
  • Payment Status

Checkbox:

  • Issue Manual DO (Should be enabled only if option is enabled in configuration settings; refer to user story: #431)
  • Issue Temporary DO

HDO Status:

  • Should have a label "HDO Status" displaying the latest status of the HDO

b)   In another section, prompt the user to input the following mandatory information:​

  • DO Recipient Code: Dropdown list populated with all Freight Forwarder (FFWD) codes/Importer Codes/Broker codes + names retrieved from the Cargo Community System (CCS).
  • Subsidiary Reference : Textbox for the user to input – max length 15
  • Delivery Expiry Date & Time: Date and time picker ensuring the expiry is set to a future date and time.
  • Reason: This field is mandatory only if the checkbox "Manual DO" is checked. The user will have to input a reason why he/she is issuing a manual DO from FFS.
  • Temporary Delivery Order (TDO) additional fields:
    • Remarks: the reason for issuing the TDO (e.g., Bank Guarantee or Bond, Inspection or Sampling, ATA Carnet/Temporary Import Permit, Free Zones/FTZs/Bonded Warehouses, Delayed Document Arrival (Original B/L).
    • These fields should be enabled and mandatory for input only if the checkbox "Issue Temporary DO" is checked.

c)  The system should allow the user to Save the HDO.

d)  The system should allow the issuance of the HDO for cash clients based on the following conditions:

  • Unpaid invoices or partially paid invoices or credit clients – need approval by higher level to proceed with the HDO integration with CCS
  • Paid invoices – no approval needed; can proceed with the HDO integration with CCS

3.      Approval Workflow Based on Payment Status:

a)  For Unpaid or Partially Paid Invoices (both Cash and Credit clients):

Request for Approval:

  • Upon attempting to issue the HDO, the system prompts the user to send the HDO request for approval.
  • A mandatory Remarks textbox appears for the user to input any relevant comments or justifications.

Approval Stage:

  • The approver reviews the request and inputs a mandatory Approval Reason detailing the grounds for granting the HDO issuance.

 b)  For Fully Paid Invoices:

  • Allow HDO issuance without the need for additional approval.

4.      Integration with CCS:

  • After completing the above steps, provide an option to send the HDO directly to CCS (XML format).​
  • Implement validation checks to ensure all required fields are populated and adhere to the expected formats before allowing transmission.​
  • Display confirmation messages upon successful transmission or error messages detailing any issues encountered (Success or Error details).​

5.     CCS Validations Enhancements:

  • While integrating with the CCS, check if the Master DO Expiry Date & Time matches the HDO Expiry. If not, then it should return a validation error message to FFS.
  • If the DO Recipient Code does not match with the one in the BOE, then return an error message to FFS.

6.      Audit and Logging:

  • Maintain an audit trail capturing:​
    • User initiating the HDO issuance
    • Details of the approval process (if applicable), including approver's name, approval reason, and timestamps
    • Status of the HDO transmission to CCS

7.      User Permissions and Access Control:

  • Ensure that only authorised personnel have access to initiate HDO issuance and approve HDOs for unpaid invoices.​

8.      Generate XML File:

  • Upon issuing a House Delivery Order in the FFS, the system should auto-generate a valid XML file with the following fields (as per CCS specs), which will eventually be sent to CCS:
  • Xml

<HOUSE_DO_HEADER>

    <BL_NUMBER>10ME3661311</BL_NUMBER>

    <ATP>ATP21000711</ATP>

    <COMPANY_CODE>FSILS</COMPANY_CODE>

    <DO_RECIPIENT_CODE>FVELO</DO_RECIPIENT_CODE>

    <DELIVERY_EXPIRY_DATE>24/03/2025 12:09</DELIVERY_EXPIRY_DATE>

    <SUBSIDARY_REF>XXX9999</SUBSIDARY_REF>

</HOUSE_DO_HEADER>

 9.      Mapping Logic:

  • BL_NUMBER → HBL Number in FFS
  • ATP → ATP number
  • COMPANY_CODE → FFWD company code
  • DO_RECIPIENT_CODE → Same as COMPANY_CODE or Co-Loader Code – DO Recipient Code input above
  • DELIVERY_EXPIRY_DATE → Date & Time – Delivery Expiry Date & Time input above
  • SUBSIDARY_REF → FFWD internal Ref - Subsidiary Reference input above

10.      Send XML to CCS:

  • The system should allow the user to click a "Send to CCS" button.
  • Upon sending, an acknowledgement or status update should be displayed (e.g., Success/Failure).
  • If failed, allow for a retry mechanism and record in the audit trail.

11.      Status Update:

  • Once the HDO has been sent to the CCS successfully, disable the "Send to CCS" button.
  • Update the HDO status to "Sent to CCS".

GitLab Sync Log

[{"id": "23642", "author": "Avisham", "hours": 8.0, "created": "2025-05-22T11:39:07.001Z", "log_date": "2025-05-21", "comment": "Imported from GitLab by @Avisham on 2025-05-22T11:39:07.001Z: 1d-(8.0)h spend at: 2025-05-21", "status": "active", "deleted_by": "", "redmine_entry_id": 8842}, {"id": "23641", "author": "Avisham", "hours": 8.0, "created": "2025-05-22T11:38:58.511Z", "log_date": "2025-05-20", "comment": "Imported from GitLab by @Avisham on 2025-05-22T11:38:58.511Z: 1d-(8.0)h spend at: 2025-05-20", "status": "active", "deleted_by": "", "redmine_entry_id": 8843}, {"id": "23639", "author": "Avisham", "hours": 24.0, "created": "2025-05-22T11:38:34.399Z", "log_date": "2025-05-20", "comment": "Imported from GitLab by @Avisham on 2025-05-22T11:38:34.399Z: 3d-(24.0)h spend at: 2025-05-20", "status": "deleted", "deleted_by": "23640", "redmine_entry_id": 8844}, {"id": "23638", "author": "Avisham", "hours": 8.0, "created": "2025-05-22T11:38:20.703Z", "log_date": "2025-05-19", "comment": "Imported from GitLab by @Avisham on 2025-05-22T11:38:20.703Z: 1d-(8.0)h spend at: 2025-05-19", "status": "active", "deleted_by": "", "redmine_entry_id": 8845}, {"id": "23637", "author": "Avisham", "hours": 8.0, "created": "2025-05-22T11:38:11.981Z", "log_date": "2025-05-18", "comment": "Imported from GitLab by @Avisham on 2025-05-22T11:38:11.981Z: 1d-(8.0)h spend at: 2025-05-18", "status": "active", "deleted_by": "", "redmine_entry_id": 8846}, {"id": "22891", "author": "Avisham", "hours": 8.0, "created": "2025-05-08T05:52:19.114Z", "log_date": "2025-05-05", "comment": "Imported from GitLab by @Avisham on 2025-05-08T05:52:19.114Z: 1d-(8.0)h spend at: 2025-05-05", "status": "active", "deleted_by": "", "redmine_entry_id": 8847}, {"id": "22091", "author": "Avisham", "hours": 8.0, "created": "2025-04-24T07:27:07.255Z", "log_date": "2025-04-22", "comment": "Imported from GitLab by @Avisham on 2025-04-24T07:27:07.255Z: 1d-(8.0)h spend at: 2025-04-22", "status": "active", "deleted_by": "", "redmine_entry_id": 8848}, {"id": "22090", "author": "Avisham", "hours": 8.0, "created": "2025-04-24T07:26:49.314Z", "log_date": "2025-04-24", "comment": "Imported from GitLab by @Avisham on 2025-04-24T07:26:49.314Z: 1d-(8.0)h spend at: 2025-04-24", "status": "active", "deleted_by": "", "redmine_entry_id": 8849}, {"id": "23851", "author": "Vishesh Jodhoa", "hours": 6.0, "created": "2025-05-27T06:43:38.870Z", "log_date": "2025-05-22", "comment": "Imported from GitLab by @Vishesh Jodhoa on 2025-05-27T06:43:38.870Z: 6h-(6.0)h spend at: 2025-05-22", "status": "active", "deleted_by": "", "redmine_entry_id": 9241}, {"id": "23850", "author": "Vishesh Jodhoa", "hours": 6.0, "created": "2025-05-27T06:43:26.480Z", "log_date": "2025-05-21", "comment": "Imported from GitLab by @Vishesh Jodhoa on 2025-05-27T06:43:26.480Z: 6h-(6.0)h spend at: 2025-05-21", "status": "active", "deleted_by": "", "redmine_entry_id": 9242}, {"id": "23849", "author": "Vishesh Jodhoa", "hours": 6.0, "created": "2025-05-27T06:43:12.643Z", "log_date": "2025-05-20", "comment": "Imported from GitLab by @Vishesh Jodhoa on 2025-05-27T06:43:12.643Z: 6h-(6.0)h spend at: 2025-05-20", "status": "active", "deleted_by": "", "redmine_entry_id": 9243}, {"id": "24692", "author": "Vishesh Jodhoa", "hours": 6.0, "created": "2025-06-10T07:11:54.259Z", "log_date": "2025-06-08", "comment": "Imported from GitLab by @Vishesh Jodhoa on 2025-06-10T07:11:54.259Z: 6h-(6.0)h spend at: 2025-06-08", "status": "active", "deleted_by": "", "redmine_entry_id": 9562}]

Actions #1

Updated by Redmine Admin 7 months ago

  • GitLab Sync Log updated (diff)
Actions #2

Updated by Redmine Admin 7 months ago

  • % Done changed from 87 to 100
  • GitLab Time Logged changed from 201600 to 266400
Actions #3

Updated by Redmine Admin 7 months ago

  • GitLab Sync Log updated (diff)
Actions #4

Updated by Redmine Admin 6 months ago

  • Status changed from New to Development Done
Actions #5

Updated by Redmine Admin 6 months ago

  • Due date changed from 05/30/2025 to 06/13/2025
  • Parent task changed from #16323 to #18123
  • gitlab project trace changed from Ocean Sprint Planning for 19/05/2025 - 30/05/2025 to Ocean Sprint Planning for 04/06/2025 - 13/06/2025
Actions #6

Updated by Redmine Admin 6 months ago

  • Status changed from Development Done to New
Actions #7

Updated by Redmine Admin 6 months ago

  • GitLab Time Logged changed from 266400 to 288000
Actions #8

Updated by Redmine Admin 6 months ago

  • GitLab Sync Log updated (diff)
Actions #9

Updated by Redmine Admin 6 months ago

  • Status changed from New to Development Done
Actions #10

Updated by Redmine Admin 5 months ago

  • Status changed from Development Done to QA
Actions

Also available in: Atom PDF