IT Feature Project-A - Improvement on OEM Client ID application logic

A. Problem Statement / Objective Many shippers, use the PRO AV (for example) account to export (and there are a lot of exporters who piggy-back on other parties’ Carrier Co accounts). Naturally, the Shipper Match will reference the Carrier Co account number (PRO AV) but the actual shipper will be different. Those shippers' TIN does not apply and a separate application has to be submitted each time. As long as it is a “piggy-back shipper”, everything is being done manually – from application to searching for the result to adding it manually in SBSS. Based on current OEM Client ID application process, CLS will be added on multiple shipments with the same Carrier Co account witch blocks the separate OEM Client ID application on real shipper. B. Scope / Acceptance Criteria OEM Client ID message submission Once a OEM Client ID application message is sent Add Reference Number CLS in Declaration Shipper/Importer Address of all shipments with the same Shipper/Importer name Once a separate OEM Client ID application message is triggered, validate if CLS is already added. If no, send the message to customs. If yes, raise an warning that OEM Client ID message is already been sent on this Client. If users ignore the warning, they can still send the message. Response message process Approval message Once an approval message is received, store TIN/OEM Client ID to the following SBSS mappings: Reference Number TIN/OID in Declaration Shipper/Importer Address of all shipments with the same Shipper/Importer name Full Turbo Tax ID/OEM Client ID of all shipments with the same Shipper/Importer name Rejection message Once a rejection message is received Locate the shipment triggering the OEM Client ID application Reflect error response to Customer Supplied References and Remark popup of the shipment located OID status updates Once a OEM Client ID application message is sent, update OID status to SNT on all shipments with the same Shipper/Importer Name Once an approval message is processed, update OID status to CMP on all shipments with the same Shipper/Importer Name Once a rejection message is processed Locate the shipment triggering the OEM Client ID application Update OID status to ERR on the shipment located

Input documents:

title: SBSS Platform Knowledge Document
content: ## Carrier Co Australia Customs Brokerage System

---

## 1. Platform Overview

### What is SBSS?
SBSS (Brokerage Operations Support System) is Carrier Co Australia's customs brokerage platform used to manage import and export declarations for shipments entering or leaving Australia. It serves as the primary interface between Carrier Co customs brokers and the Customs Border Force (CBF) for regulatory compliance and customs clearance.

### Who Uses SBSS?
- **Customs Brokers (BRK)** – Process and submit declarations to customs authorities
- **Administrators (ADM)** – Configure system parameters and manage operational settings
- **Compilers (COM)** – Prepare and validate declaration data before submission
- **Operations Supervisors** – Oversee workflow and exception handling
- **Front Office Staff** – Handle day-to-day shipment processing and customer liaison

### Business Purpose
SBSS supports the end-to-end customs brokerage workflow for international shipments, including:
- Declaration preparation and validation
- Submission to customs authorities via integrated government systems
- Response handling (approvals, rejections, exceptions)
- Document management and record retention
- Charge calculation and billing
- Regulatory compliance with CBF requirements

---

## 2. System Architecture

### Core Systems in the SBSS Ecosystem

#### SBSS (Brokerage Operations Support System)
The central platform where all declaration work is performed. SBSS maintains shipment records, declarations, commodities, parties, and documents. It orchestrates communication between internal Carrier Co systems and external government platforms.

#### TPS (Trade Processing System)
The Customs Border Force's primary customs processing system. SBSS submits declarations to TPS and receives responses (permits, rejections, holds) via TradeNet messaging.

#### TradeNet
Singapore's national trade facilitation platform. For Singapore operations, SBSS communicates with TradeNet for customs approvals using EDIFACT-based messaging protocols.

#### BDIS (Brokerage Document Imaging System)
Document management system that stores scanned copies of invoices, packing lists, certificates of origin, and other supporting documents. BDIS integrates with SBSS to attach documents to declarations for customs review.

#### TCS (HAWB Management System)
Manages House Air Waybill (HAWB) records and shipment tracking references. TCS provides shipment master data to SBSS including consignee details, weights, values, and routing information.

#### MSG-ESM (Enterprise Shipment Management)
Carrier Co's enterprise-level shipment tracking system. MSG-ESM provides real-time visibility into shipment status across the Carrier Co network and feeds operational data to SBSS.

#### MSG-CSA (Cargo Release System - Trucking)
Manages cargo release for trucking operations and inland movement. MSG-CSA coordinates with SBSS to ensure shipments are physically released only after customs clearance.

#### OLAF (Operations Logistics and Forwarding)
Freight forwarding system that manages booking, routing, and carrier coordination. OLAF sends shipment forecast data to SBSS before physical arrival.

#### BCR (Broker Client Reporting)
Reporting and analytics platform that generates operational and compliance reports for brokers and customers. BCR extracts data from SBSS for business intelligence.

#### BSIS (Brokerage Statistical Information System)
Archives historical declaration data for regulatory reporting, audits, and compliance verification. BSIS ensures long-term retention of customs records as required by law.

---

## 3. Integration Patterns

### Message Exchange with Customs Authorities

#### EDIFACT Messaging
SBSS uses UN/EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) standard messages to communicate with TradeNet (Singapore) and TPS (Australia). Common message types include:

- **Declaration Messages**: Submit formal customs declarations
- **Permit Messages**: Receive customs approvals and permit numbers
- **Error Messages (ERRORM)**: Receive validation failures and rejection reasons
- **Status Messages (STATUS-R)**: Query and receive status updates on submitted declarations
- **Update Messages**: Submit amendments to previously lodged declarations

#### Message Patterns

**Synchronous Communication**:
- Real-time validation responses during declaration submission
- Immediate error feedback for malformed messages

**Asynchronous Communication**:
- Declaration submission → customs processing → permit issuance (can take minutes to hours)
- Status polling to track declaration progress through customs workflow
- Event-driven updates when customs officers complete manual review

#### Message Naming Conventions
- **INPDEC**: Import Payment Declaration (for formal clearances with duty/GST payable)
- **IPTDEC**: Import Payment Declaration (specific duty treatment types)
- **TNPDEC**: Transhipment Declaration (Batam consolidation scenario)
- **INPUPD**: Import Payment Update (amend existing declarations)
- **IPTUPD**: Import Payment Update (specific treatment amendments)
- **OUTDEC**: Outbound/Export Declaration
- **COODEC**: Country of Origin Declaration
- **INPPMT**: Import Permit (approval response)
- **IPTPMT**: Import Permit (specific treatment approval)
- **TNPPMT**: Transhipment Permit
- **OUTPMT**: Export Permit
- **COODCI**: Country of Origin Declaration Information response

### APIs and File Transfers
- **Shipment Download**: TCS pushes shipment manifests to SBSS via batch file transfer
- **Document Upload**: BDIS receives document images via API calls triggered by SBSS
- **Charge File Generation**: SBSS exports charge files to billing systems via scheduled jobs
- **Reference Data Sync**: Tariff codes, exchange rates, and regulatory tables updated via periodic feeds

---

## 4. Data Model Overview

### Key Entities and Relationships

#### Shipment
The central object representing a physical cargo movement from origin to destination.
- **Identifiers**: Shipment ID, MAWB (Master Air Waybill), HAWB (House Air Waybill), 1Z Tracking Number
- **Routing**: Origin country/port, destination country/port, transit country (for transhipments)
- **Parties**: Shipper, consignee, importer, broker
- **Weights/Values**: Gross weight, net weight, declared value, freight charges
- **Status**: Shipment status codes (e.g., 03 = in-process, 04 DA = cleared)

#### Declaration
The formal customs submission for one or more shipments.
- **Declaration Number**: Customs Reference Number (CRN) assigned by SBSS, Customs Control Number (CCN) assigned by CBF
- **Clearance Type (CT)**: FML (Formal), DEM (De minimis), LND (Low-value No-Duty), FTZ (Free Trade Zone)
- **Declaration Type**: Import/Export, Treatment codes (APS/GTR/SHO/DES/REX/GST/DUT/DNG/BKT)
- **Totals**: Declaration total value, statistical value, freight amount, insurance, duties
- **Brokerage Status**: Tracks workflow stages (RAT, EBC, CUS statuses)

#### Commodity Line
Individual line items within a declaration representing distinct products.
- **Classification**: HS Code (Harmonized System tariff code), commodity description
- **Values**: Commodity value, duty amount, supplementary quantities
- **Origin/Treatment**: Country of origin, preference codes, treatment applications
- **Linkages**: Maps back to shipment ID and invoice number via Form Type references (SHP, INV, TRK)

#### Invoice
Commercial invoice associated with shipment.
- **Invoice Number**: Unique identifier from shipper
- **Currency**: Original currency and converted value (to AUD/SGD)
- **Line Items**: Commodity details, quantities, unit prices
- **Charges**: Freight, insurance, discount allocations

#### Consignment
Grouping of related shipments for consolidated processing.
- **CONSREF#**: Consolidation Reference Number generated based on matching criteria
- **Virtual Shipment**: Temporary shipment record (prefixed with #) representing consolidated group
- **Lead Shipment**: Primary shipment within consolidation used for customs submission
- **Child Shipments**: Related shipments rolled up into virtual declaration

#### Party
Entities involved in the shipment transaction.
- **Types**: Shipper, Consignee, Importer of Record (IOR), Broker, Carrier
- **Identifiers**: TIN (Australian Business Number), OEM Client ID (Client Code ID), Tax ID
- **Attributes**: Name, address, contact details, postal code

---

## 5. User Roles and Permissions

### Front Office Roles

**Broker (BRK)**
- Primary role for declaration processing
- Can create, edit, and submit declarations to customs
- Handles document attachment and commodity classification
- Resolves exceptions and holds
- Consolidation of shipments assigned to BRK can proceed

**Administrator (ADM)**
- Configures system parameters including consolidation criteria
- Manages reference data (tariff codes, ports, countries)
- Sets up user roles and permissions
- Monitors system health and integration status
- Consolidation of shipments assigned to ADM can proceed

**Compiler (COM)**
- Prepares declarations for review before broker submission
- Validates data completeness and accuracy
- Attaches supporting documents via BDIS
- Consolidation of shipments assigned to COM can proceed

### Back Office Roles
- **Operations Supervisor**: Assigns shipments to front office staff, monitors workflow bottlenecks
- **Compliance Officer**: Audits declarations for regulatory adherence
- **Customer Service**: Responds to client inquiries about shipment status

### Assignment Logic (AST)
- Shipments must be assigned (AST) to a front office role (BRK/ADM/COM) before they can be consolidated
- Consolidation criteria can include AST status as a parameter to ensure only properly assigned shipments are grouped
- Unassigned shipments (back office) are excluded from consolidation until assignment occurs

---

## 6. Consolidation Reference System

### CONSREF# (Consolidation Reference Number)
A dynamically generated identifier that groups shipments with matching attributes for consolidated declaration submission.

#### Purpose
- Combine multiple low-value or related shipments into a single declaration
- Reduce processing overhead and submission costs
- Ensure accurate duty/tax calculation on aggregated values
- Prevent tax evasion on de minimis thresholds

#### Generation Logic
CONSREF# is constructed by parsing and concatenating values from configured matching parameters:

| Parameter | Max Chars | Parsing Rule | Example |
|-----------|-----------|--------------|---------|
| Importer Account # | 6 | Last 6 chars (exclude leading zeros) | 123456 |
| Movement Number | 8 | Full value | 12345678 |
| MAWB | 8 | Last 8 digits | 81542000 |
| Import Date | 8 | DDMMYYYY | 18032024 |
| Transit Country | 2 | Full country code | SG |
| Clearance Type | 3 | Full code | DEM |
| Shipment Indicator | Variable | Full value | TTR |
| Forecast Status | 6 | Literal value | FORCMP |

**Maximum Length**: 35 characters (right-trimmed if exceeded)

#### Matching Criteria Sets
Admins configure multiple criteria sets, each with a primary parameter:

- **Set A (Trusted Traders)**: Shipment Indicator (TTR) + Importer Account + Import Date
- **Set B (Batam Transhipments)**: Transit Country (SG/MY) + Destination Country + Import Date
- **Set C (De minimis)**: Clearance Type (DEM) + Import Date + Consignee Telephone + Movement Number
- **Set D (Forecast Complete)**: Forecast Status (FOR=CMP) + Importer Account + MAWB

#### Priority Order
Systems check criteria sets in configured sequence:
- **Australia**: Set A → Set C (Trusted Traders → De minimis)
- **Singapore**: Set B → Set C (Batam → De minimis)

### Virtual Shipments
When consolidation occurs:
1. System creates a **Virtual Shipment** with ID starting with # (e.g., #000000035)
2. Virtual shipment aggregates declaration data from all child shipments
3. **Lead Shipment** (highest value or package count) represents the group in customs submission
4. Child shipments retain individual records but reference virtual/lead via comments and events

---

## 7. Environment and Infrastructure

### Deployment Architecture
- **Production Environment**: Live system processing real customs declarations
- **Testing Environment**: Mirrors production for user acceptance testing and regression testing
- **Development Environment**: Sandbox for feature development and integration testing

### Connectivity
- **CBF TPS Connection**: Secure gateway for Australian customs messaging (encrypted, VPN-tunneled)
- **TradeNet Connection**: Singapore customs network access via certified messaging protocol
- **SBSS Internal Network**: Connects to TCS, MSG-ESM, OLAF, BDIS, MSG-CSA within Carrier Co infrastructure

### Data Residency
- Australian operations: Data stored in Australia to comply with CBF data sovereignty requirements
- Singapore operations: Data stored in Singapore for TradeNet compliance

---

## 8. Glossary of Domain Terms

### Shipment and Routing
- **MAWB**: Master Air Waybill – carrier's shipment identifier
- **HAWB**: House Air Waybill – freight forwarder's sub-shipment identifier
- **1Z Number**: Carrier Co tracking number format
- **PTN**: Package Tracking Number
- **OCC**: Origin Country Code
- **OPC**: Origin Port Code
- **DCC**: Destination Country Code
- **DPC**: Destination Port Code
- **TCC**: Transit Country Code

### Declaration Types and Clearance
- **FML**: Formal Entry – full customs declaration with duty/tax calculation
- **DEM**: De minimis – low-value exemption clearance
- **LND**: Low-value No-Duty – clearance for goods below duty threshold
- **FTZ**: Free Trade Zone – special customs area treatment
- **INF**: Informal Entry (deprecated, replaced by DEM)

### Brokerage Status Codes
- **RAT**: Rating Status (duty calculation stage)
- **EBC**: E-Broker Complete (internal validation complete)
- **CUS**: Customs Status (submission and response tracking)
- **FOR**: Forecast Status (document scanning/preparation stage)
- **AST**: Assignment Status (which user role owns the shipment)
- **MAN**: Manual Review Status (customs hold for examination)

### CUS Status Values
- **SNT**: Sent to Customs
- **SCR**: Successfully Received (acknowledgment from customs)
- **SCA**: Scanning Required (customs document request)
- **APP**: Approved
- **ERR**: Error (validation failure)
- **REJ**: Rejected (customs refusal)
- **INS**: Inspection Required
- **CLR**: Cleared for Release
- **CMP**: Complete

### RAT Status Values
- **CMP**: Complete (rating calculation finished)
- **RFC**: Ready for Customs (validation passed, ready to submit)
- **HLD1**: Hold Level 1 (pending additional information)

### Exception and Hold Codes
- **RTS**: Return to Sender
- **RTO**: Return to Origin
- **BYP**: Bypass (skip validation)
- **HLD1**: Hold Level 1 (broker action required)
- **1U**: Specific exception reason code (customs query)
- **NST**: Not Sent (message content validation failed)
- **NRQ**: No Request (declaration not yet submitted)

### Message Types
- **INPDEC**: Import Payment Declaration
- **IPTDEC**: Import Payment (Treatment-specific) Declaration
- **TNPDEC**: Transhipment Declaration
- **INPUPD**: Import Payment Update
- **IPTUPD**: Import Payment (Treatment) Update
- **OUTDEC**: Outbound/Export Declaration
- **COODEC**: Country of Origin Declaration
- **INPPMT**: Import Permit (approval)
- **IPTPMT**: Import Payment Permit
- **TNPPMT**: Transhipment Permit
- **OUTPMT**: Export Permit
- **ERRORM**: Error Message (rejection with reasons)
- **STATUS-R**: Status Request/Response

### Treatment and Preference Codes
- **APS**: ASEAN Preferential Scheme
- **GTR**: General Tariff Rate
- **SHO**: Special Handling Order
- **DES**: Destruction
- **REX**: Re-export
- **GST**: Goods and Services Tax
- **DUT**: Duty Treatment
- **DNG**: Dangerous Goods
- **BKT**: Blanket Treatment

### Parties and Identifiers
- **IOR**: Importer of Record (entity legally responsible for duties)
- **COD**: Consignee on Demand
- **TIN**: Australian Business Number
- **OEM Client ID**: Client Code ID
- **Shipper**: Party sending goods
- **Consignee**: Party receiving goods
- **Broker**: Customs agent filing declarations

### Consolidation Terms
- **CONSREF#**: Consolidation Reference Number
- **VRT/VID**: Virtual Shipment ID (prefixed with #)
- **Lead Shipment**: Primary shipment in consolidated group
- **Child Shipment**: Individual shipment rolled into consolidation
- **TTR**: Trusted Trader (shipment indicator for preferential processing)
- **Batam**: Singapore-Indonesia transhipment consolidation scenario

### Document Types
- **INV**: Commercial Invoice
- **SHP**: Shipment Identifier reference
- **TRK**: Tracking Number reference
- **CA**: Customs Acknowledgment
- **SC**: Special Conditions
- **AFD**: Additional Fee Detail
- **ERD**: Error Detail

### Financial and Charges
- **COD**: Cash on Delivery
- **FRT**: Freight Charges
- **INS**: Insurance
- **DIS**: Discount
- **UNS**: Upload Not Sent (charge file suppression flag)
- **Sigma**: Summation/total across multiple shipments

### Reference Numbers
- **CRN**: Customs Reference Number (SBSS-assigned)
- **CCN**: Customs Control Number (CBF-assigned)
- **PMT#**: Permit Number
- **PMTSD**: Permit Start Date
- **PMTED**: Permit End Date
- **CAADT**: Customs Approval Actual Date/Time
- **PMADT**: Permit Actual Date/Time
- **DESDT**: Declaration Submission Date/Time

### Shipment Status Codes
- **03**: In-Process/Submitted
- **04 DA**: Cleared/Delivered Available

---

## 9. Regulatory Context

### Customs Border Force (CBF) Requirements
- All import/export declarations must be lodged electronically via TPS
- Declarations must include accurate HS codes for tariff classification
- Supporting documents (invoices, certificates) must be retained for 5 years
- Duty and GST calculations must follow CBF guidelines
- Permit numbers must be obtained before cargo release

### Singapore Customs (TradeNet) Requirements
- Transhipment declarations required for cargo moving through Singapore en route to final destination
- De minimis thresholds apply for low-value goods
- Preferential tariff treatment requires certificates of origin
- TradeNet messaging must conform to UN/EDIFACT standards

### Compliance Obligations
- Brokers must hold valid customs broker licenses
- Declarations must be signed electronically by authorized brokers
- Tariff classification errors can result in penalties and audits
- False declarations are criminal offenses
- Record retention: 5-7 years depending on jurisdiction

---

title: Customs Brokerage Process Flow
content: ## Import and Export Clearance for Carrier Co Australia

---

## 1. Import Declaration Process (End-to-End)

### Phase 1: Shipment Arrival and Manifest Download

**Trigger**: Cargo arrives at destination airport/port or manifest is transmitted by carrier

**Activities**:
1. **Manifest Receipt**: TCS receives cargo manifest from airline/carrier with shipment details (MAWB, HAWB, consignee, origin, declared value, weight)
2. **Shipment Download to SBSS**: Manifest data flows from TCS to SBSS, creating shipment records
3. **Consolidation Matching** (if configured):
   - SBSS checks shipment attributes against configured consolidation criteria (importer account, import date, transit country, clearance type, etc.)
   - If matching criteria are met, SBSS generates CONSREF# and groups shipments
   - Admin reviews consolidation report showing CONSREF# and matching shipment counts
4. **Assignment**: Shipment assigned (AST) to broker (BRK), compiler (COM), or admin (ADM) role in front office

**Key Data Captured**:
- Shipment ID, MAWB, HAWB, tracking number
- Parties (shipper, consignee, importer)
- Declared value, weight, package count
- Routing (origin, destination, transit points)
- Movement number, flight/vessel details

**System Interactions**: TCS → SBSS → (Optional) Consolidation Engine

---

### Phase 2: Document Receipt and Validation

**Trigger**: Shipment assigned to broker for processing

**Activities**:
1. **Document Collection**:
   - Broker receives commercial invoice, packing list, certificate of origin, permits (if applicable) from shipper/consignee
   - Documents scanned and uploaded to BDIS
2. **Document Attachment**:
   - Broker attaches BDIS images to shipment declaration
   - For consolidated shipments, documents from all child shipments are merged and grouped by shipment ID in virtual declaration
3. **Forecast Status Update**:
   - Forecast status (FOR) updated to CMP (Complete) once all documents received and scanned
   - If consolidation criteria include FOR=CMP, shipments only receive CONSREF# after forecast completion

**Key Validations**:
- Invoice value matches declared shipment value
- HS codes are present and valid
- Required certificates/permits are attached
- Consignee/importer details are accurate

**System Interactions**: Broker → BDIS → SBSS

---

### Phase 3: Declaration Preparation

**Trigger**: FOR=CMP and broker begins declaration entry

**Activities**:
1. **Clearance Type Determination**:
   - **FML (Formal)**: Shipment value exceeds de minimis threshold or specific commodity requires formal entry
   - **DEM (De minimis)**: Low-value consignments below duty threshold
   - **LND (Low-value No-Duty)**: Goods below duty threshold but requiring GST
   - **FTZ**: Free trade zone clearance for bonded warehouses
2. **Declaration Data Entry**:
   - Broker enters/validates summary data (declaration type, clearance type, gross weight, declared value)
   - Customer details (shipper, consignee, importer with TIN/tax ID)
   - Movement details (arrival date, import date, movement number, port codes)
   - Charges (freight, insurance, other charges)
3. **Commodity Classification**:
   - Broker assigns HS code to each commodity line
   - Enters commodity description, quantity, unit value
   - Specifies country of origin
   - Applies treatment codes (APS/GTR/SHO/DES/REX) if preferential tariff treatment claimed
   - Attaches licenses, permits, or quota references if required
4. **Invoice Processing**:
   - For single-currency invoices: Use original declared value
   - For multi-currency invoices: SBSS converts all values to local currency (AUD/SGD) using declaration exchange rate
   - For consolidated shipments with mixed currencies: Use declaration total value (already in AUD/SGD) as baseline
5. **Consolidation (if applicable)**:
   - Broker selects matching shipments via CONSREF# from consolidation report
   - SBSS creates **Virtual Shipment** (ID starting with #) combining:
     - All commodity lines from child shipments
     - Sigma (sum) of declared values, gross weights, freight, insurance, duties
     - Common clearance type (FML forced for consolidated declarations)
     - Form type references (SHP, INV, TRK) mapping commodities back to original shipment IDs
   - **Lead Shipment** selected (highest value or package count) as primary reference for customs submission
   - Virtual shipment's declaration number (CRN) assigned

**Key Calculations**:
- **Declaration Total Value**: Sum of all invoice values (converted to local currency if needed)
- **Statistical Value**: Includes freight and insurance added to invoice value
- **Duty Amount**: Calculated per commodity line based on HS code tariff rate
- **GST/Tax**: Applied to sum of invoice value + freight + insurance + duty

**System Interactions**: SBSS (Declaration Module) → Rating Engine → Tariff Database

---

### Phase 4: Rating and Validation

**Trigger**: Broker completes data entry and initiates rating

**Activities**:
1. **Rating Calculation**:
   - SBSS rating engine retrieves tariff rates for each HS code
   - Calculates duty per commodity line (value × tariff rate)
   - Applies treatment codes (preferential rates if applicable)
   - Calculates GST on dutiable value
   - Computes total declaration charges
2. **Internal Validation**:
   - **RAT (Rating) Status** checks:
     - All commodity HS codes valid
     - Quantities and values within acceptable ranges
     - Treatment codes match HS code eligibility
     - Licenses/permits present for restricted goods
   - **EBC (E-Broker Complete) Status** checks:
     - All required fields populated
     - Party details complete (TIN, addresses)
     - Documents attached for all invoice line items
     - No conflicting data between shipment and declaration
3. **Manual Review (if needed)**:
   - High-value shipments flagged for supervisor approval
   - Unusual commodity classifications escalated to compliance officer
   - Missing document exceptions logged

**Status Progression**:
- RAT = CMP → EBC = CMP → CUS = RFC (Ready for Customs)

**System Interactions**: SBSS → Rating Engine → Validation Rules Engine

---

### Phase 5: Submission to Customs

**Trigger**: CUS = RFC and broker approves submission

**Activities**:
1. **Message Generation**:
   - SBSS constructs EDIFACT message based on declaration type and treatment:
     - **INPDEC**: Standard formal import declaration (APS/GTR/SHO/DES/REX)
     - **IPTDEC**: Import declaration with specific duty treatment (GST/DUT/DNG/BKT)
     - **TNPDEC**: Transhipment declaration (Batam consolidation scenario with inbound/outbound MAWB/HAWB)
   - For consolidated shipments:
     - Message includes all commodity lines (up to 50 per message per TradeNet limit)
     - Each commodity tagged with Form Type references (SHP/INV/TRK) to original shipment
     - Lead shipment HAWB used as declaration reference (virtual # ID not sent to customs)
2. **Message Transmission**:
   - SBSS sends message to TPS (Australia) or TradeNet (Singapore)
   - **CUS Status** updated to **SNT (Sent)**
   - Shipment status updated to **03** (In-Process)
   - Exception reason code **1U** logged (message sent, awaiting response)
   - **MAN Status** updated to **NST (Not Sent)** if validation fails, or **NRQ (No Request)** if awaiting customs action
3. **Acknowledgment**:
   - Customs system sends synchronous acknowledgment (message received and queued)
   - **CUS Status** updated to **SCR (Successfully Received)**
   - Broker sees confirmation in SBSS that declaration is in customs processing queue

**System Interactions**: SBSS → TradeNet/TPS Gateway → Customs Backend

---

### Phase 6: Customs Processing and Response

**Customs Processing (External)**:
1. Customs system validates message format and content
2. Runs risk assessment algorithms
3. Routes to officer review if flagged, otherwise auto-processes
4. Generates permit or rejection

**SBSS Receives Response**:

#### Scenario A: Approval (Permit Issued)

**Inbound Message**: INPPMT, IPTPMT, or TNPPMT

**Activities**:
1. SBSS receives permit message with:
   - **CCN (Customs Control Number)**: Official customs identifier
   - **Permit Number (PMT#)**: Authorization to release cargo
   - **PMTSD/PMTED**: Permit validity period
   - **CAADT/PMADT**: Customs approval date/time
2. **CUS Status** updated to **APP (Approved)**
3. **Shipment Status** updated to **04 DA (Cleared/Delivered Available)**
4. **For Consolidated Shipments**:
   - Virtual shipment receives response first
   - SBSS automatically syncs permit details to **Lead Shipment** declaration
   - Lead shipment's permit details copied to all **Child Shipments** via:
     - Declaration > Customs > Reference Number fields (CCN, PMT#, PMTSD, PMTED, CAADT, PMADT)
     - Shipment comments (Customer Supplied References synced)
     - Brokerage events logged for each child ("Consolidated under Shipment ID XXXXX", "Permit received: PMT#")
5. **Charge File Generation**:
   - For consolidated shipments, single charge file generated from **Lead Shipment** only
   - Charge file includes:
     - Government charges (duties, GST) from declaration
     - Accessorial charges (brokerage fees, document fees) from shipment
   - Child shipments flagged **UNS (Upload Not Sent)** to suppress duplicate charge files
6. **Document Update**:
   - Approved declaration form (PDF) generated and attached to BDIS
   - For consolidated shipments, declaration form available on virtual, lead, and all child shipments
7. **Release Notification**:
   - SBSS notifies MSG-CSA that shipment is cleared for release
   - Warehouse receives pickup authorization

**System Interactions**: TPS/TradeNet → SBSS → Lead/Child Shipments → MSG-CSA → Billing System

---

#### Scenario B: Rejection (Declaration Refused)

**Inbound Message**: ERRORM or STATUS-R with rejection codes

**Activities**:
1. SBSS receives rejection message with:
   - Error codes and descriptions (e.g., "HS code invalid", "Missing license", "Value discrepancy")
   - Line-level or declaration-level errors
2. **CUS Status** updated to **ERR (Error)** or **REJ (Rejected)**
3. **Shipment Status** remains **03** (not cleared)
4. **MAN Status** may update to specific hold code indicating reason
5. Broker reviews error details in SBSS
6. **For Consolidated Shipments**:
   - If entire declaration rejected, all child shipments receive rejection status sync
   - If specific commodity lines rejected, broker identifies faulty child shipments via Form Type SHP references
7. **Exception Handling**:
   - Broker corrects errors (amends HS code, uploads missing document, adjusts value)
   - Broker submits **INPUPD/IPTUPD** (update message) with corrections
   - Or broker withdraws declaration and resubmits fresh INPDEC

**System Interactions**: TPS/TradeNet → SBSS → Broker Worklist

---

#### Scenario C: Hold for Inspection

**Inbound Message**: Customs inspection request or SCA (Scanning Required) status

**Activities**:
1. SBSS receives hold notification
2. **CUS Status** updated to **INS (Inspection Required)** or **SCA (Scanning Required)**
3. **MAN Status** updated to **HLD1** or specific hold code
4. Broker coordinates with customs officer:
   - Provides additional documents
   - Arranges physical inspection at cargo facility
   - Responds to queries via SBSS messaging or email
5. Once inspection cleared:
   - Customs issues permit (follows Scenario A path)
   - Or requests amendment (follows Scenario B path)

**System Interactions**: SBSS ↔ Customs Officer (manual intervention) → TPS/TradeNet

---

### Phase 7: Cargo Release and Finalization

**Trigger**: CUS = APP and shipment status = 04 DA

**Activities**:
1. **Cargo Release**:
   - MSG-CSA receives clearance notification from SBSS
   - Warehouse releases cargo to consignee or delivery carrier
   - Physical handover confirmed in MSG-ESM
2. **Billing**:
   - Charge file sent to billing system
   - Customer invoiced for duties, GST, brokerage fees, accessorial charges
   - For consolidated shipments, single invoice issued to lead shipment's importer
3. **Record Archival**:
   - Declaration, commodity, document, and message data archived in BSIS
   - Retention period: 5 years minimum for compliance
4. **Reporting**:
   - BCR generates reports for:
     - Daily clearance volumes
     - Duty/GST collected
     - Exception rates (rejections, holds)
     - Consolidation efficiency metrics

**System Interactions**: SBSS → MSG-CSA → MSG-ESM → Billing System → BSIS/BCR

---

## 2. Export Declaration Process (End-to-End)

### Phase 1: Booking and Shipment Creation

**Trigger**: Customer books export shipment via OLAF or Carrier Co sales channel

**Activities**:
1. **Booking Entry**:
   - Customer provides shipper, consignee, commodity details, destination, requested pickup date
   - OLAF creates shipment booking record
2. **Manifest Generation**:
   - OLAF transmits shipment manifest to SBSS
   - SBSS creates export shipment record
3. **Assignment**:
   - Shipment assigned to broker for export declaration preparation

**Key Data Captured**:
- Shipper (exporter), consignee (foreign buyer)
- Commodity descriptions, HS codes, values
- Export country, port of exit, destination country
- Export date, outbound movement number

**System Interactions**: OLAF → SBSS

---

### Phase 2: Export Declaration Preparation

**Trigger**: Broker receives assigned export shipment

**Activities**:
1. **Document Collection**:
   - Commercial invoice, packing list, certificate of origin (if required)
   - Export licenses/permits for controlled goods
2. **Declaration Entry**:
   - Export declaration type selected (OUTDEC or COODEC)
   - Commodity classification (HS code, description, quantity, value)
   - Party details (exporter with TIN, foreign consignee)
   - Movement details (export date, port of exit, vessel/flight details)
3. **Validation**:
   - Restricted/prohibited goods checks
   - Export license verification for dual-use or strategic goods
   - Country-of-origin certification for FTA eligibility

**System Interactions**: SBSS → Tariff/License Database

---

### Phase 3: Submission to Customs

**Trigger**: Broker completes and approves export declaration

**Activities**:
1. **Message Generation**:
   - **OUTDEC**: Standard export declaration
   - **COODEC**: Certificate of origin declaration (for FTA preferential treatment in destination country)
2. **Transmission**:
   - SBSS sends message to TPS/TradeNet
   - **CUS Status** = **SNT**
   - **Shipment Status** = **03**
   - **Exception Reason** = **1U**
3. **Acknowledgment**:
   - Customs acknowledges receipt
   - **CUS Status** = **SCR**

**System Interactions**: SBSS → TPS/TradeNet

---

### Phase 4: Customs Response and Clearance

#### Scenario A: Approval

**Inbound Message**: OUTPMT or COODCI

**Activities**:
1. SBSS receives export permit
2. **CUS Status** = **CLR (Cleared)**
3. **Shipment Status** = **04 DA**
4. Cargo released for loading onto vessel/aircraft
5. Permit attached to shipment for carrier handover

**System Interactions**: TPS/TradeNet → SBSS → MSG-CSA

---

#### Scenario B: Hold/Rejection

**Inbound Message**: ERRORM or hold notification

**Activities**:
1. **CUS Status** = **ERR** or **HLD (Hold)**
2. Broker coordinates with customs officer to resolve issue
3. Submits correction via **OUTUPD** (export update message)
4. Re-approval follows Scenario A path

---

### Phase 5: Departure and Finalization

**Trigger**: Cargo loaded and vessel/aircraft departs

**Activities**:
1. Carrier confirms departure to SBSS
2. Final shipment status updated in MSG-ESM
3. Export declaration archived in BSIS
4. Customer invoiced for brokerage fees

**System Interactions**: Carrier → MSG-ESM → SBSS → BSIS

---

## 3. Message Lifecycle (Import/Export)

### Creation
- Declaration data entered in SBSS UI
- SBSS constructs EDIFACT message per customs schema (INPDEC/IPTDEC/TNPDEC/OUTDEC/COODEC)

### Validation
- **Pre-Submission**: SBSS validates message structure, mandatory fields, data types
- **Post-Submission**: Customs performs content validation (HS codes, party IDs, value ranges)

### Submission
- SBSS transmits message via secure gateway to TPS/TradeNet
- CUS = SNT, Shipment Status = 03, Exception = 1U

### Response Handling
- **Acknowledgment**: SCR (message received, queued for processing)
- **Approval**: APP → Permit issued (INPPMT/IPTPMT/TNPPMT/OUTPMT/COODCI)
- **Rejection**: ERR/REJ → Error message returned (ERRORM)
- **Hold**: INS/SCA/HLD1 → Manual review required

### Status Update
- **Synchronous**: Immediate feedback (acknowledgment, validation errors)
- **Asynchronous**: Delayed response (permit issuance after officer review, can take minutes to hours)

### Retry/Amendment
- If rejected, broker submits update message (INPUPD/IPTUPD/OUTUPD)
- Or withdraws and resubmits fresh declaration

---

## 4. Clearance Types

### FML (Formal Entry)
- **Trigger**: Shipment value exceeds de minimis threshold, or commodity requires formal declaration (e.g., restricted goods)
- **Process**: Full declaration with commodity classification, duty calculation, GST
- **Outcome**: Permit issued after customs approval, duties/taxes payable

### DEM (De minimis)
- **Trigger**: Low-value consignments (typically below AUD 1,000 or SGD 400)
- **Process**: Simplified declaration, often auto-cleared
- **Outcome**: No duty, minimal GST or exempt, faster clearance

### LND (Low-value No-Duty)
- **Trigger**: Goods below duty threshold but subject to GST
- **Process**: Declaration focuses on GST calculation, no tariff classification needed
- **Outcome**: GST payable, no customs duty

### FTZ (Free Trade Zone)
- **Trigger**: Cargo entering bonded warehouse or FTZ for storage/re-export
- **Process**: Suspended duty/tax until cargo leaves FTZ for domestic consumption
- **Outcome**: No immediate payment, duty deferred or waived on re-export

### Alternate Broker / Transhipment
- **Trigger**: Cargo transiting through country en route to final destination (e.g., Batam scenario: air into Singapore, sea out to Indonesia)
- **Process**: Transhipment declaration (TNPDEC) with inbound and outbound MAWB/HAWB
- **Outcome**: Permit issued for cargo to continue journey, no import duty (cargo not entering commerce)

---

## 5. Exception Handling

### Rejection Scenarios
- **HS Code Invalid**: Tariff code not found or incorrect format → Broker corrects and resubmits
- **Missing License**: Restricted goods require permit → Broker uploads permit document and updates declaration
- **Value Discrepancy**: Invoice value doesn't match declared value → Broker amends value or provides explanation
- **Party Details Incorrect**: TIN invalid, address incomplete → Broker updates party data

### Hold Scenarios
- **Document Request (SCA)**: Customs officer requests additional supporting documents → Broker uploads to BDIS and notifies customs
- **Physical Inspection (INS)**: Cargo examination required → Broker coordinates inspection appointment with warehouse and customs
- **Valuation Query (HLD1)**: Declared value under question → Broker provides additional invoices or valuation evidence

### Refund/Withdrawal
- **Overpayment**: Duty calculated incorrectly → Broker submits refund request with corrected calculation
- **Withdrawal (BYP)**: Declaration no longer needed (shipment cancelled, returned to sender) → Broker withdraws declaration, cargo re-exported or destroyed

---

## 6. Status Lifecycle

### Shipment Status Progression
- **Downloaded** → Shipment created in SBSS from manifest
- **Assigned (AST)** → Allocated to broker/compiler/admin
- **03** → Declaration submitted to customs, awaiting response
- **04 DA** → Cleared by customs, available for delivery
- **RTS/RTO** → Return to sender/origin (clearance failed or shipment refused)

### Declaration Brokerage Status Progression
- **RAT**: Rating calculation in progress
  - **RAT = CMP**: Rating complete, duty/tax calculated
- **EBC**: Internal validation in progress
  - **EBC = CMP**: Validation complete, ready for submission
- **CUS**: Customs submission and response tracking
  - **CUS = RFC**: Ready for Customs (internal approval to submit)
  - **CUS = SNT**: Sent to Customs
  - **CUS = SCR**: Successfully Received (acknowledged by customs)
  - **CUS = APP**: Approved (permit issued)
  - **CUS = ERR**: Error (validation failed)
  - **CUS = REJ**: Rejected (declaration refused)
  - **CUS = INS**: Inspection Required
  - **CUS = CLR**: Cleared (export approved)
  - **CUS = CMP**: Complete (all processing finished)

### Forecast Status (FOR)
- **Initiated** → Document scan process started
- **In Progress** → Some documents scanned, others pending
- **CMP (Complete)** → All documents scanned and attached
- **Note**: FOR = CMP may be consolidation criterion trigger

### Manual Review Status (MAN)
- **NST (Not Sent)**: Message content validation failed before submission
- **NRQ (No Request)**: Awaiting broker action to submit
- **HLD1**: Hold for manual review
- **Specific Exception Codes**: 1U (customs query), etc.

---

## 7. Regulatory Context

### CBF Import Requirements
- All cargo arriving in Australia must be declared electronically via TPS before release
- Importers must provide accurate HS codes for tariff classification
- Duty and GST calculated based on customs value (transaction value + freight + insurance)
- Permits required for restricted goods (food, pharmaceuticals, weapons, etc.)
- Supporting documents must be retained for 5 years for audit

### CBF Export Requirements
- Export declarations required for controlled goods (strategic exports, dual-use items)
- Certificate of origin declarations for FTA preferential treatment
- Exporters must provide accurate commodity descriptions and HS codes
- Departure confirmation required before cargo leaves Australian jurisdiction

### Singapore TradeNet Requirements
- All imports/exports/transhipments must be declared via TradeNet
- EDIFACT messaging mandatory for electronic submissions
- Transhipment permits required for cargo moving through Singapore (Batam scenario)
- De minimis threshold: SGD 400 for GST exemption
- Preferential tariff schemes (ASEAN, FTA) require certificates of origin

### Compliance Obligations
- **Broker Licensing**: Customs brokers must hold valid licenses issued by CBF or Singapore Customs
- **Electronic Signatures**: Declarations must be electronically signed by authorized brokers
- **Tariff Classification Accuracy**: Errors in HS codes can result in penalties, back-duty assessments, or criminal charges for deliberate misclassification
- **False Declarations**: Submitting false information (undervaluation, misdescription) is a criminal offense
- **Record Retention**: 5-7 years depending on jurisdiction and commodity type
- **Audit Cooperation**: Brokers must provide records upon request during customs audits

---

## 8. Consolidation-Specific Process Flow

### Identification Phase
1. Shipment downloads from manifest
2. SBSS checks shipment attributes against configured consolidation criteria sets (in priority order)
3. If match found on primary parameter + secondary parameters, CONSREF# generated and assigned
4. Shipment flagged for consolidation (viewable in consolidation matching report)

### Selection Phase
1. Broker reviews consolidation matching report (sorted by CONSREF# with highest shipment count first)
2. Broker selects shipments under same CONSREF# for consolidation
3. SBSS creates Virtual Shipment (# ID) combining:
   - All declarations and commodity lines from selected shipments
   - Sigma values (declared value, gross weight, freight, insurance, duties)
   - Common clearance type (forced to FML for consolidated submissions)
   - Form Type references mapping commodities to original shipment IDs

### Lead Shipment Assignment
1. SBSS selects lead shipment (highest value, or highest package count if values equal, or alphabetically if tied)
2. Lead shipment HAWB becomes declaration reference (virtual # ID not sent to customs)

### Submission Phase
1. Virtual declaration submitted to customs (INPDEC/IPTDEC/TNPDEC)
2. Message includes all commodity lines with Form Type tags (SHP/INV/TRK)
3. CUS = SNT on virtual, lead, and child shipments

### Response Sync Phase
1. Customs response received on virtual shipment
2. SBSS syncs permit details to lead shipment
3. Lead shipment syncs to all child shipments:
   - Declaration references (CCN, PMT#, dates)
   - Customer supplied references
   - Brokerage events
   - CUS and shipment status
   - Exception codes

### Charge File Phase
1. Single charge file generated from lead shipment
2. Child shipments flagged UNS to suppress duplicate billing

### Document Availability Phase
1. Approved declaration form available on virtual, lead, and all child shipments
2. BDIS documents merged and tagged by originating shipment ID

---

This process flow serves as the operational blueprint for all customs brokerage activities in SBSS. Brokers, compilers, and administrators follow these workflows to ensure compliant, efficient, and accurate customs clearance for Carrier Co customers.

title: IT Feature Project-A - Improvement on OEM Client ID application logic — Feature Brief
content: ## Feature Title and Business Need

**Enhancement of OEM Client ID Application Logic for Multi-Party Export Scenarios**

The current OEM Client ID (Customs Client ID) application process in SBSS creates operational inefficiencies when multiple exporters share the same Carrier Co account (e.g., "piggy-back" shippers using the PRO AV account). When these shippers' Australian Business Numbers (TINs) do not apply to the Carrier Co account holder, customs brokers must manually submit separate OEM Client ID applications, search for responses, and manually update SBSS records for each shipper. This manual process is error-prone, time-consuming, and prevents automated status tracking across related shipments.

## Business Objectives

1. **Automate OEM Client ID Status Propagation**: When a OEM Client ID application is submitted for a party (shipper/importer/supplier), automatically update status indicators across all shipments involving that party, eliminating manual record updates.

2. **Prevent Duplicate Applications**: Implement validation logic to warn brokers when a OEM Client ID application has already been submitted for a party, reducing wasted effort and customs processing overhead.

3. **Centralize Party Registration Data**: Maintain a centralized repository of party OEM Client ID registration status in SBSS Admin Party Address records, enabling reuse of TIN/OEM Client ID data across multiple shipments.

4. **Improve Data Consistency**: Synchronize TIN and OEM Client ID values across multiple SBSS data entry points (Full Turbo, Declaration Customer screens, Admin Party Address) to eliminate data discrepancies.

5. **Enhance Operational Visibility**: Provide clear status indicators differentiating between importer, shipper, and supplier OEM Client ID registration states, enabling brokers to identify and resolve registration issues efficiently.

## Scope

### In Scope

**Outbound MSG-CLR (Client Registration) Message Submission:**
- Validation logic to detect existing OEM Client ID applications for a party before submission
- Warning prompts when duplicate applications are detected (with user override capability)
- Automatic addition of tracking references (CLS - MSG-CLR message sent) to Declaration Customer records
- Synchronization of MSG-CLR submission status to SBSS Admin Party Address records

**Inbound MSG-CLRR (Client Registration Response) Message Processing:**
- Automatic population of TIN/OEM Client ID to Declaration Customer Reference Numbers upon approval
- Synchronization of TIN/OEM Client ID to Full Turbo Address fields
- Propagation of registration results to SBSS Admin Party Address records (Tax ID, Reference Numbers)
- Error message reflection to shipment Customer Supplied References and Remarks

**Inbound CLNTDUP (Client Duplicate) Message Processing:**
- Processing of duplicate registration responses indicating TIN/OEM Client ID already exists
- Population of existing TIN/OEM Client ID from customs response to Declaration and Full Turbo fields
- Status completion for shipments receiving duplicate notifications

**Status Model Enhancement:**
- Introduction of Declaration Customs Codes (TPS - Importer OEM Client ID Status, SCS - Shipper OEM Client ID Status) to differentiate registration states by party role
- Deprecation of single Brokerage Status OID in favor of role-specific status tracking
- AWA (Awaiting second approval) status for scenarios where one party is registered but the counterparty is pending

**Multi-Shipment Status Synchronization:**
- Batch update capability to apply OEM Client ID registration results to all shipments involving the same party (matched by name and address)
- NTSA background job to load affected shipments and apply registration data without manual intervention

**Data Synchronization:**
- Bidirectional synchronization of TIN (Tax ID) and OEM Client ID (FZ/CW#) between Full Turbo Address, Declaration Customer, and Admin Party Address screens
- User confirmation prompts when manual data entry triggers cross-screen synchronization

**MSG-ESM Message Mapping Update:**
- Correction of Goods Owner Party ID mapping to reference Declaration Customer Reference Numbers instead of deprecated Shipper Profile Comments

### Out of Scope

- Changes to MSG-CLR message structure or EDIFACT segment definitions (customs-controlled)
- Modifications to customs authority processing logic or response times
- Automated OEM Client ID application submission without broker review and approval
- Retrospective correction of historical shipments processed before this enhancement
- Integration with external party databases or third-party TIN lookup services

## Stakeholders and Actors

**Primary Users:**
- **Customs Brokers (BRK)**: Submit OEM Client ID applications, review warnings, process responses, update party data
- **Compilers (COM)**: Prepare declarations with accurate party identification prior to broker submission
- **Administrators (ADM)**: Configure party address records, review OEM Client ID registration audit trails

**Secondary Stakeholders:**
- **Operations Supervisors**: Monitor OEM Client ID application exception rates and resolution times
- **Compliance Officers**: Ensure party identification meets CBF regulatory requirements
- **Customer Service Representatives**: Respond to client inquiries about OEM Client ID registration delays

**External Systems:**
- **TPS (Trade Processing System)**: Receives MSG-CLR messages, returns MSG-CLRR/CLNTDUP responses
- **TradeNet**: Processes OEM Client ID applications for Singapore operations (where applicable)
- **SBSS Admin Party Address**: Central repository for party registration data

## Dependencies

**Data Dependencies:**
- Accurate and complete party name and address data in Declaration Customer fields (prerequisite for party matching logic)
- Consistent address formatting between shipments to enable multi-shipment party matching
- URN (Unique Reference Number) assignment to declarations before MSG-CLR submission (for response matching)

**Technical Dependencies:**
- EDIFACT message parsing capability for MSG-CLRR (segments FTX+TIN, FTX+CCI, CNT+55, FTX+AAO)
- EDIFACT message parsing capability for CLNTDUP (segments DOC+TIN, DOC+CCI, TAX+RN)
- NTSA (background job framework) operational for batch shipment updates
- IBLOCTX table availability for storing shipment lists requiring status updates

**Process Dependencies:**
- Existing MSG-CLR message submission workflow (triggered by Declaration Comment codes CCI/CCO/CII/COI/CIS/COS)
- Existing party address matching logic (name + address line 1 + address line 2 + postal code + city + region + country)
- Feature 6220858 (Project-A / Project-S - Customer Profile Look-up) must be deployed before multi-shipment status synchronization

**Reference Data Dependencies:**
- SBSS Admin Shipment Reference Number Type table (new codes: CLS, STA, SHP, PT, CN)
- SBSS Admin Brokerage Status Value table (new OID value: AWA)
- Declaration Customs Code types (new: TPS, SCS with values RFC/SNT/CMP/ERR/SYN)

## Success Criteria

**Operational Efficiency:**
- 80% reduction in manual OEM Client ID data entry time for brokers processing "piggy-back" shipper scenarios
- 95% reduction in duplicate OEM Client ID application submissions detected by validation warnings
- Batch status updates complete within 15 minutes of MSG-CLRR/CLNTDUP message receipt

**Data Accuracy:**
- 100% of approved TIN/OEM Client ID values synchronized across Declaration, Full Turbo, and Admin Party Address within 1 save cycle
- Zero discrepancies between party registration status in Admin Party Address and Declaration Customs Codes after response processing

**User Experience:**
- Brokers receive clear, actionable warning messages when duplicate OEM Client ID applications are detected
- TIN/OEM Client ID synchronization prompts provide sufficient context for broker decision-making (party type, data source, target fields)
- TPS/SCS status values visible in Declaration Customs Codes grid for all shipments with OEM Client ID interactions

**Regulatory Compliance:**
- 100% of MSG-CLRR error responses (CNT+55 > 0) reflected in shipment Customer Supplied References and Remarks for audit trail
- Contact Name recorded in Admin Party Address for all new party records created via MSG-CLR submission

## Assumptions and Risks

**Assumptions:**
1. Party address data entered by brokers is sufficiently consistent to enable accurate matching (name spelling, address format)
2. Customs MSG-CLRR/CLNTDUP responses contain accurate TIN/OEM Client ID values suitable for direct population into SBSS fields
3. Brokers will respond appropriately to duplicate OEM Client ID warnings (reviewing party history before overriding)
4. NTSA background job infrastructure can handle peak volumes during high-traffic periods (e.g., end-of-month declaration surges)
5. MSG-ESM messages already reference Shipper Profile Comments for Goods Owner Party ID (mapping change is correction, not new integration)

**Risks:**

| Risk | Impact | Mitigation |
|------|--------|------------|
| **Party matching false negatives**: Minor address variations (e.g., "Pty Ltd" vs "Pty. Ltd.") prevent matching, causing duplicate party records | Medium | Implement fuzzy matching logic or address normalization preprocessing; provide Admin search tools to identify near-duplicate party records |
| **MSG-CLRR message delays**: Customs responses take hours/days, causing brokers to re-submit thinking message was lost | Medium | Display clear "SNT" status with submission timestamp; provide broker training on expected response timeframes |
| **NTSA batch job failures**: Background job crashes mid-execution, leaving some shipments with stale status | High | Implement job retry logic with transaction rollback; log failed shipment IDs to IBLOCTX for manual review |
| **Data synchronization conflicts**: User modifies TIN in Full Turbo while MSG-CLRR response updates Declaration simultaneously, causing data overwrite | Low | Implement last-write-wins with event logging; flag conflicting updates in Brokerage Events for broker review |
| **TIN "already registered" handling**: MSG-CLRR returns "TIN ALREADY REGISTERED" but Declaration Tax ID field is blank (customs has TIN but SBSS doesn't) | Medium | Process "TIN ALREADY REGISTERED" responses by copying Tax ID to Reference Number TIN; update status to CMP without error reflection |
| **Multi-role OEM Client ID scenarios**: Single shipment requires both Importer and Shipper OEM Client ID, responses arrive out of order causing premature status completion | Low | Introduce AWA (Awaiting second approval) status; only set CMP when both TPS and SCS are approved (if both parties require OEM Client ID) |

**Regulatory Risks:**
- **CBF Audit Compliance**: Failure to retain MSG-CLR error details in audit trail could result in compliance violations → Ensure all FTX+AAO segments written to Customer Supplied References and Remarks
- **Data Privacy**: Party address records contain sensitive business information → Apply existing SBSS role-based access controls to Admin Party Address screens

---

## Approval and Sign-Off

**Business Owner**: [Customs Brokerage Operations Manager]  
**Technical Lead**: [SBSS Platform Architect]  
**Compliance Reviewer**: [CBF Compliance Officer]  

**Approval Date**: [To be completed upon stakeholder review]

---

title: IT Feature Project-A - Improvement on OEM Client ID application logic — Technical Specification
content: **Document Version**: 1.0  
**Related Platform Documents**: Platform Knowledge §2 (System Architecture), §3 (Integration Patterns), §4 (Data Model), §6 (Consolidation Reference System); Process Flow §1 (Import Declaration), §2 (Export Declaration), §6 (Clearance Types)

---

## 1. Message Format & Segment Reference

### 1.1 Outbound Message: MSG-CLR (Client Registration)

**Purpose**: Request TIN or OEM Client ID assignment from customs for a party (Exporter, Importer, Supplier)

**Trigger Conditions**: (See §4 Business Rules for full trigger logic)
- Export: Declaration Comment CCI or CCO present, Declaration Customs Code SCS = RFC
- Import Importer: Declaration Comment CII or COI present, Declaration Customs Code TPS = RFC
- Import Supplier: Declaration Comment CIS or COS present, Declaration Customs Code SCS = RFC

**Key Segments**:

| Segment | Data Element | Description | Format | Mandatory/Optional | Source Mapping |
|---------|--------------|-------------|--------|-------------------|----------------|
| BGM | 1056 | Sender Reference Version | Integer (auto-increment per submission) | M | Generated by SBSS |
| MEA | 6154 | Role Name | Code: EXPORTER, IMPORTER, SUPPLIER | M | Derived from Declaration Comment trigger (CCI/CCO→EXPORTER, CII/COI→IMPORTER, CIS/COS→SUPPLIER) |
| RFF+ABO | 1154 | Sender Reference | Alphanumeric (URN) | M | Declaration > Customs > Reference Numbers > URN |
| NAD+XX | 3035 | Party Qualifier | Code: varies by role | M | Fixed per role (Exporter/Importer/Supplier) |
| NAD+XX | 3036-3045 | Party Name and Address | Text fields | M | Declaration > Customer > [Shipper/Importer] > Name, Address Line 1, Address Line 2, Postal Code, City, Region, Country |
| NAD+XX | C082 | Party Identification | TIN (if available) or blank | O | Declaration > Customer > [Shipper/Importer] > Tax ID or Reference Numbers > TIN |
| FTX+AAA | 4440 | Free Text | Contact Name | O | Declaration > Customer > [Shipper/Importer] > Contact Name |

**Message Count Constraint**: TradeNet limit: 50 commodity lines per message (not directly applicable to MSG-CLR, but reference for context; see Platform Knowledge §3)

---

### 1.2 Inbound Message: MSG-CLRR (Client Registration Response)

**Purpose**: Customs response with approved TIN/OEM Client ID or rejection reasons

**Response Types**:
- **Approval with TIN**: Contains FTX+TIN segment with Australian Business Number
- **Approval with OEM Client ID**: Contains FTX+CCI segment with Customs Client ID
- **Rejection**: Contains CNT+55 (Total Comments > 0) and FTX+AAO (error descriptions)
- **Already Registered**: Special case where FTX+AAO contains "TIN ALREADY REGISTERED"

**Key Segments**:

| Segment | Data Element | Description | Format | Mandatory/Optional | Processing Rule |
|---------|--------------|-------------|--------|-------------------|-----------------|
| RFF+ABO | 1154 | Sender Reference | Alphanumeric (URN) | M | Match to Declaration > Customs > Reference Numbers > URN to identify shipment |
| RFF+ABO | 4000 | Sender Reference Version | Integer | M | Match to Declaration > Misc > Customer Supplied References > CLREGSRV > Number to identify corresponding MSG-CLR |
| FTX+TIN | 4441 | Australian Business Number | Numeric (11 digits) | C | Present if TIN approved; store to multiple SBSS mappings (see §2.2) |
| FTX+CCI | 4441 | Customs Client ID | Alphanumeric | C | Present if OEM Client ID approved; store to multiple SBSS mappings (see §2.2) |
| CNT+55 | 6066 | Total Comments | Integer | M | If > 0, indicates rejection; trigger error status |
| FTX+AAO | 4440 | Message Text | Free text (error descriptions) | C | Present if CNT+55 > 0 OR special case "TIN ALREADY REGISTERED"; store to Customer Supplied References and Remarks |

**Conditional Logic**:
- If FTX+TIN OR FTX+CCI present: Approval path
- If CNT+55 > 0 AND FTX+AAO contains "TIN ALREADY REGISTERED" AND Declaration Tax ID populated: Special approval path (see §4.5)
- If CNT+55 > 0 AND FTX+AAO does NOT contain "TIN ALREADY REGISTERED": Rejection path

---

### 1.3 Inbound Message: CLNTDUP (Client Duplicate)

**Purpose**: Customs notification that party is already registered (TIN/OEM Client ID exists in customs system)

**Key Segments**:

| Segment | Data Element | Description | Format | Mandatory/Optional | Processing Rule |
|---------|--------------|-------------|--------|-------------------|-----------------|
| RFF+ABO | 1154 | Sender Reference | Alphanumeric (URN) | M | Match to Declaration > Customs > Reference Numbers > URN |
| RFF+ABO | 4000 | Sender Reference Version | Integer | M | Match to CLREGSRV > Number |
| TAX+RN | 5152 | Role Name | Code: EXPORTER, IMPORTER, SUPPLIER | M | Filter processing logic by role |
| DOC+TIN | 1000 | Australian Business Number | Numeric (11 digits) | C | Present if TIN already registered; store to SBSS mappings |
| DOC+CCI | 1000 | Customs Client ID | Alphanumeric | C | Present if OEM Client ID already registered; store to SBSS mappings |

**Processing Note**: CLNTDUP is treated as approval (status → CMP) since party is confirmed registered, just not newly registered by this MSG-CLR.

---

### 1.4 Inbound Message: CONTRL (Syntax Error)

**Purpose**: EDIFACT syntax validation failure (message structure invalid)

**Key Segments**:

| Segment | Data Element | Description | Format | Processing Rule |
|---------|--------------|-------------|--------|-----------------|
| UCI / UCM | 0083 | Syntax Error Indicator | Code: 4 = rejected | If 0083 = 4, trigger SYN (Syntax Error) status |
| (Associated) ICRN | Comment | Role Name | Text: EXPORTER, IMPORTER, SUPPLIER | Match to determine which status to update (TPS vs SCS) |

**Note**: CONTRL processing logic references Bug 6964044 for detailed segment parsing rules.

---

### 1.5 Outbound Message: MSG-ESM (Enterprise Shipment Management)

**Purpose**: Notify Carrier Co enterprise systems of shipment customs status

**Mapping Update** (see Platform Knowledge §2 for MSG-ESM architecture):

| Segment | Data Element | Current Mapping (Deprecated) | Updated Mapping |
|---------|--------------|------------------------------|-----------------|
| NAD+GO | 3039 | Goods Owner Party ID | Shipper > Profile > Comments > TIN (if available), else Shipper > Profile > Comments > OID | Declaration > Customer > Shipper > Reference Numbers > TIN (if available), else Declaration > Customer > Shipper > Reference Numbers > OID |

**Message Function Codes**: 9 (Original), 5 (Replacement)

---

## 2. Data Mapping Rules

### 2.1 SBSS Data Model Entities

**Reference Tables** (SBSS Admin configuration):

| Table | New Entries | Description |
|-------|-------------|-------------|
| Shipment Reference Number Type | CLS | Code: CLS, Description: "MSG-CLR message sent", Parent Type: SHP (Shipment), Quick Searchable: Yes |
| Shipment Reference Number Type | PT | Code: PT, Description: "Party Address reference", Parent Type: (none), Quick Searchable: Yes |
| Shipment Reference Number Type | STA | Code: STA, Description: "OID Status", Parent Type: PT, Quick Searchable: Yes |
| Shipment Reference Number Type | SHP | Code: SHP, Description: "Shipment ID sending MSG-CLR", Parent Type: PT, Quick Searchable: Yes |
| Shipment Reference Number Type | CN | Code: CN, Description: "Contact Name", Parent Type: PT, Quick Searchable: Yes |
| Brokerage Status Value | OID / AWA | Status Type: OID, Status Value: AWA, Description: "Awaiting second approval on MSG-CLR" |
| Declaration Customs Code | TPS | Type: TPS, Description: "Importer OEM Client ID Status", Values: RFC, SNT, CMP, ERR, SYN |
| Declaration Customs Code | SCS | Type: SCS, Description: "Shipper OEM Client ID Status", Values: RFC, SNT, CMP, ERR, SYN |

**Deprecated Mappings** (to be removed):

| Deprecated Path | Replacement |
|-----------------|-------------|
| Shipment > Shipper > Profile > Comments > CLS | Declaration > Customer > Shipper > Reference Numbers > CLS (Export only; Import logic removes CLS) |
| Shipment > Shipper > Profile > Comments > TIN | Declaration > Customer > Shipper > Reference Numbers > TIN |
| Shipment > Shipper > Profile > Comments > OID | Declaration > Customer > Shipper > Reference Numbers > OID |
| Shipment > Importer > Profile > Comments > TIN | Declaration > Customer > Importer > Reference Numbers > TIN |
| Shipment > Importer > Profile > Comments > OID | Declaration > Customer > Importer > Reference Numbers > OID |
| Declaration > Misc > Customer Supplied References > TIN | (Removed; TIN now stored in Reference Numbers only) |
| Declaration > Misc > Customer Supplied References > OID | (Removed; OID now stored in Reference Numbers only) |

---

### 2.2 MSG-CLRR Approval Response → SBSS Mapping (Exporter)

**Trigger**: MSG-CLRR received with CLREGSRV > Comment = "EXPORTER"

**Segment FTX+TIN Processing**:

| Source (MSG-CLRR) | Target (SBSS) | Transformation Rule |
|-----------------|---------------|---------------------|
| FTX+TIN / 4441 | Declaration > Customer > Shipper > Reference Numbers > TIN | Direct copy; if existing TIN/OID in Reference Numbers, clear before writing |
| FTX+TIN / 4441 | Full Turbo > Address > Shipper > Tax ID | Direct copy; if existing value, overwrite |

**Pre-Condition**: If existing values in Declaration > Customer > Shipper > Reference Numbers > TIN, OID, or Full Turbo > Address > Shipper > Tax ID, FZ/CW#, clear those fields before processing FTX+TIN.

**Segment FTX+CCI Processing**:

| Source (MSG-CLRR) | Target (SBSS) | Transformation Rule |
|-----------------|---------------|---------------------|
| FTX+CCI / 4441 | Declaration > Customer > Shipper > Reference Numbers > OID | Direct copy; if existing TIN/OID in Reference Numbers, clear before writing |
| FTX+CCI / 4441 | Full Turbo > Address > Shipper > FZ / CW # | Direct copy; if existing value, overwrite |

**CLS Retention**: Declaration > Customer > Shipper > Reference Numbers > CLS remains (not removed upon approval for Export)

**Status Update**: Declaration > Customs > Customs Codes > SCS → CMP

---

### 2.3 MSG-CLRR Approval Response → SBSS Mapping (Importer)

**Trigger**: MSG-CLRR received with CLREGSRV > Comment = "IMPORTER"

**Segment FTX+TIN Processing**:

| Source (MSG-CLRR) | Target (SBSS) | Transformation Rule |
|-----------------|---------------|---------------------|
| FTX+TIN / 4441 | Declaration > Customer > Importer > Reference Numbers > TIN | Direct copy; clear existing TIN/OID first |
| FTX+TIN / 4441 | Full Turbo > Address > Importer > Tax ID | Direct copy; overwrite existing |

**CLS Removal**: Declaration > Customer > Importer > Reference Numbers > CLS → Removed upon approval

**Status Update**:
- Declaration > Customs > Customs Codes > TPS → CMP (if no Shipper OEM Client ID pending)
- OR → AWA (if Declaration > Customer > Shipper > Reference Numbers > CLS exists, indicating Shipper OEM Client ID pending second approval)

---

### 2.4 MSG-CLRR Approval Response → SBSS Mapping (Supplier)

**Trigger**: MSG-CLRR received with CLREGSRV > Comment = "SUPPLIER"

**Segment FTX+TIN / FTX+CCI Processing**: Same as §2.3 (Importer), but target is Declaration > Customer > Shipper instead of Importer.

**Status Update Logic**:
- Check Declaration > Customer > Importer > Reference Numbers for TIN or OID
- If Importer TIN/OID exists: SCS → CMP
- If only Importer CLS exists (no TIN/OID): SCS → AWA
- If no Importer references: SCS → CMP

---

### 2.5 MSG-CLRR Rejection Response → SBSS Mapping

**Trigger**: CNT+55 / 6066 > 0 (rejection)

**Segment FTX+AAO Processing**:

| Source (MSG-CLRR) | Target (SBSS) | Transformation Rule |
|-----------------|---------------|---------------------|
| FTX+AAO / 4440 (all occurrences) | Declaration > Misc > Customer Supplied References | Append each FTX+AAO text as new Customer Supplied Reference entry |
| FTX+AAO / 4440 (concatenated) | Shipment > Remarks Popup | Display all error messages in popup for broker review |

**CLS Removal**:
- Exporter: Declaration > Customer > Shipper > Reference Numbers > CLS → Removed
- Importer: Declaration > Customer > Importer > Reference Numbers > CLS → Removed
- Supplier: Declaration > Customer > Shipper > Reference Numbers > CLS → Removed

**Status Update**:
- Exporter: SCS → ERR
- Importer: TPS → ERR
- Supplier: SCS → ERR

---

### 2.6 MSG-CLRR "TIN Already Registered" Special Case → SBSS Mapping

**Trigger**: CNT+55 > 0 AND FTX+AAO contains text "TIN ALREADY REGISTERED" AND Declaration > Customer > [Shipper/Importer] > Tax ID is populated

**Processing Logic**:
1. Check if Declaration > Customer > [Shipper/Importer] > Reference Numbers > TIN exists:
   - If TIN Reference Number does NOT exist: Add TIN Reference Number with value from Tax ID field
   - If TIN Reference Number exists: Skip addition
2. Update status to CMP (treat as approval since TIN is confirmed registered)
3. **Do NOT** write FTX+AAO text to Customer Supplied References or Remarks (suppress error message display)

**Rationale**: Customs is confirming the party is registered with the TIN already in SBSS; this is not a true error condition.

---

### 2.7 CLNTDUP Response → SBSS Mapping

**Segment DOC+TIN / DOC+CCI Processing**: Identical logic to MSG-CLRR FTX+TIN / FTX+CCI (see §2.2, §2.3, §2.4), except:
- Source element: DOC / 1000 instead of FTX / 4441
- Always results in CMP status (no AWA logic, as CLNTDUP indicates definitive registration)

---

### 2.8 SBSS Admin Party Address → Declaration Synchronization (Pre-Submission)

**Trigger**: Shipment load OR change to Declaration > Customer > [Shipper/Importer] > Name

**Party Matching Criteria** (all must match):

| Declaration Field | Party Address Field |
|-------------------|---------------------|
| Customer > [Shipper/Importer] > Name | Name |
| Customer > [Shipper/Importer] > Address Line 1 | Address Line 1 |
| Customer > [Shipper/Importer] > Address Line 2 | Address Line 2 |
| Customer > [Shipper/Importer] > Postal Code | Postal Code |
| Customer > [Shipper/Importer] > City | City |
| Customer > [Shipper/Importer] > Region | Region |
| Customer > [Shipper/Importer] > Country | Country |

**If Party Matched**:

| Party Address Source | SBSS Shipment Target | Condition |
|----------------------|----------------------|-----------|
| Reference Numbers > STA (if value = SNT) | Declaration > Customer > [Shipper/Importer] > Reference Numbers > CLS (add with party Name as value) + Declaration > Customs > Customs Codes > [TPS/SCS] → SNT | Import or Export |
| Tax ID (if not blank) | Declaration > Customer > [Shipper/Importer] > Reference Numbers > TIN + Full Turbo > Address > [Shipper/Importer] > Tax ID + Declaration > Customs > Customs Codes > [TPS/SCS] → CMP | Any |
| Reference Numbers > OID (if not blank) | Declaration > Customer > [Shipper/Importer] > Reference Numbers > OID + Full Turbo > Address > [Shipper/Importer] > FZ / CW # + Declaration > Customs > Customs Codes > [TPS/SCS] → CMP | Any |

**Note**: For Export shipments, only Shipper matching applies (no multiple declarations scenario). For Import shipments, both Importer and Shipper matching apply; if both have OID/TIN, final status is CMP; if one has CLS only, status is AWA.

---

### 2.9 SBSS UI Cross-Screen Synchronization (Manual Data Entry)

**Trigger**: User manually adds or modifies Tax ID or FZ/CW# in Full Turbo, Declaration Customer, or Admin Party Address

**User Confirmation Prompt** (popup):

| Trigger Field Modified | Popup Text |
|------------------------|------------|
| Full Turbo > Address > Importer > Tax ID | "Would you like to apply the data to Declaration Importer and Customer Profile?" |
| Full Turbo > Address > Shipper > Tax ID | "Would you like to apply the data to Declaration Shipper and Customer Profile?" |
| Full Turbo > Address > Importer > FZ / CW # | "Would you like to apply the data to Declaration Importer and Customer Profile?" |
| Full Turbo > Address > Shipper > FZ / CW # | "Would you like to apply the data to Declaration Shipper and Customer Profile?" |
| Declaration > Customer > Importer > Tax ID | "Would you like to apply the data to Full Turbo and Customer Profile?" |
| Declaration > Customer > Importer > Reference Numbers > TIN | "Would you like to apply the data to Full Turbo and Customer Profile?" |
| Declaration > Customer > Importer > Reference Numbers > OID | "Would you like to apply the data to Full Turbo and Customer Profile?" |
| (Similar for Shipper) | (Similar text with "Shipper" substituted) |
| Admin Party Address > Tax ID | "Would you like to apply the data to [Importer/Shipper] Admin Party Address?" |
| Admin Party Address > Reference Numbers > OID | "Would you like to apply the data to [Importer/Shipper] Admin Party Address?" |

**If User Clicks "Yes"**:

**Tax ID / TIN Synchronization Matrix**:

| Source Field | Target Fields (synchronized) |
|--------------|------------------------------|
| Full Turbo > Address > Importer > Tax ID | Declaration > Customer > Importer > Tax ID, Declaration > Customer > Importer > Reference Numbers > TIN |
| Declaration > Customer > Importer > Tax ID | Full Turbo > Address > Importer > Tax ID, Declaration > Customer > Importer > Reference Numbers > TIN |
| Declaration > Customer > Importer > Reference Numbers > TIN | Full Turbo > Address > Importer > Tax ID, Declaration > Customer > Importer > Tax ID |
| (Same logic for Shipper) | (Shipper equivalents) |
| Admin Party Address > Tax ID (if party matched to Declaration) | Declaration > Customer > [Importer/Shipper] > Tax ID, Full Turbo > Address > [Importer/Shipper] > Tax ID, Declaration > Customer > [Importer/Shipper] > Reference Numbers > TIN |

**FZ/CW# / OID Synchronization Matrix**:

| Source Field | Target Fields (synchronized) |
|--------------|------------------------------|
| Full Turbo > Address > Importer > FZ / CW # | Declaration > Customer > Importer > Reference Numbers > OID |
| Declaration > Customer > Importer > Reference Numbers > OID | Full Turbo > Address > Importer > FZ / CW # |
| (Same for Shipper) | (Shipper equivalents) |
| Admin Party Address > Reference Numbers > OID (if party matched) | Declaration > Customer > [Importer/Shipper] > Reference Numbers > OID, Full Turbo > Address > [Importer/Shipper] > FZ / CW # |

---

### 2.10 MSG-CLR Submission → SBSS Admin Party Address Recording

**If Party NOT Matched** (pre-submission party matching fails):

| Declaration Source | Party Address Target | Notes |
|--------------------|----------------------|-------|
| Customer > [Shipper/Importer] > Name | Name | Create new Party Address record |
| Customer > [Shipper/Importer] > Address Line 1 | Address Line 1 | |
| Customer > [Shipper/Importer] > Address Line 2 | Address Line 2 | |
| Customer > [Shipper/Importer] > Postal Code | Postal Code | |
| Customer > [Shipper/Importer] > City | City | |
| Customer > [Shipper/Importer] > Region | Region | |
| Customer > [Shipper/Importer] > Country | Country | |
| Customer > [Shipper/Importer] > Contact Name | Reference Numbers > CN | Stored as reference, not in main Contact Name field |
| (Current Shipment ID) | Reference Numbers > SHP | Track which shipment triggered MSG-CLR |
| (Fixed value: SNT) | Reference Numbers > STA | Initial status upon MSG-CLR submission |

**If Party Matched**:

| Update Field | Logic |
|--------------|-------|
| Reference Numbers > STA | If STA not present: add with value SNT. If STA = SNT: skip. If STA = ERR/SYN/CMP: overwrite to SNT. |
| Reference Numbers > SHP | If SHP not present: add with current Shipment ID. If SHP present but different Shipment ID: overwrite to current Shipment ID. If SHP matches current Shipment ID: skip. |

---

### 2.11 MSG-CLRR/CLNTDUP Response → SBSS Admin Party Address Recording

**Party Matching**: Use same criteria as §2.8.

**If Party Matched**:

**For MSG-CLRR Approval (FTX+TIN or FTX+CCI)**:

| Response Segment | Party Address Target |
|------------------|----------------------|
| FTX+TIN / 4441 | Tax ID (overwrite existing value) |
| FTX+CCI / 4441 | Reference Numbers > OID (overwrite existing value) |
| (Status logic) | Reference Numbers > STA → CMP |

**For MSG-CLRR Rejection (CNT+55 > 0)**:

| Response Condition | Party Address Target |
|--------------------|----------------------|
| CNT+55 > 0 | Reference Numbers > STA → ERR |

**For CLNTDUP (DOC+TIN or DOC+CCI)**:

| Response Segment | Party Address Target |
|------------------|----------------------|
| DOC+TIN / 1000 | Tax ID (overwrite) |
| DOC+CCI / 1000 | Reference Numbers > OID (overwrite) |
| (Status logic) | Reference Numbers > STA → CMP |

---

### 2.12 Multi-Shipment Batch Update (NTSA Background Job)

**Trigger**: MSG-CLRR or CLNTDUP message processed to Party Address

**Team-B Prerequisite** (stored procedure):
- Identify all shipments in SBSS where Declaration > Customer > [Shipper/Importer] matches the updated Party Address (using §2.8 matching criteria)
- Insert Shipment IDs into IBLOCTX table (Identifier = Shipment ID)

**NTSA Job Logic**:
1. Retrieve list of Shipment IDs from IBLOCTX
2. For each Shipment ID:
   - Load shipment (programmatic load, not UI)
   - Execute party matching logic (§2.8) to populate Declaration > Customer > Reference Numbers and Full Turbo fields
   - Execute TPS/SCS status update logic (§2.8) based on Party Address STA value
   - Record Brokerage Event: "OEM Client ID registration data synchronized from Party Address [Party Name]"
   - Save shipment
   - Remove Shipment ID from IBLOCTX
3. Log completion summary (count of shipments updated, errors encountered)

**Performance Target**: Complete batch within 15 minutes of response message receipt for up to 500 affected shipments.

---

## 3. Business Rules & Validation

### 3.1 MSG-CLR Submission Validation (Export - Exporter)

**Trigger**: Brokerage event when Declaration Customs Code SCS changes to RFC and shipment is saved

**Pre-Conditions**: Declaration Comment CCI or CCO is present

**Validation Sequence**:

1. **Check for Party Match in Admin Party Address** (using §2.8 criteria matching Declaration > Customer > Shipper)
   - If NO party matched: Proceed to MSG-CLR data validation (existing validation logic)
   - If party matched: Proceed to step 2

2. **Check Party Address Reference Numbers**:
   - **If STA not present**: Proceed to MSG-CLR data validation
   - **If STA = SNT**:
     - Display popup: "Client registration message has already been sent for Shipper [Shipper Name]. Would you resubmit?"
     - User clicks "Yes": Proceed to MSG-CLR data validation
     - User clicks "No": Block MSG-CLR submission
   - **If STA = ERR or SYN**:
     - Check if Party Address Reference Numbers > SHP matches current Shipment ID:
       - If SHP matches: Proceed to MSG-CLR data validation (this is the original failed shipment, allow retry)
       - If SHP does NOT match: Display popup: "Client registration message for Shipper [Shipper Name] got error response on Shipment [SHP value]. Would you submit from this shipment?"
         - User clicks "Yes": Proceed to MSG-CLR data validation
         - User clicks "No": Block MSG-CLR submission
   - **If STA = CMP**:
     - Check if Party Address > Tax ID has value:
       - Display popup: "TIN has already been registered for Shipper [Shipper Name]. Would you resubmit?"
       - User clicks "Yes": Proceed to MSG-CLR data validation
       - User clicks "No": Block MSG-CLR submission
     - Check if Party Address > Reference Numbers > OID has value:
       - Display popup: "OEM Client ID has already been registered for Shipper [Shipper Name]. Would you resubmit?"
       - User clicks "Yes": Proceed to MSG-CLR data validation
       - User clicks "No": Block MSG-CLR submission

3. **MSG-CLR Data Validation** (existing field-level validation):
   - Validate mandatory segments (BGM, MEA, RFF, NAD)
   - Validate party address completeness
   - Validate URN assignment
   - If validation passes: Submit MSG-CLR message
   - If validation fails: Block submission with error message

**Deprecated Validation** (removed):
- Do NOT check Shipment > Shipper > Profile > Comments > CLS
- Do NOT check Shipment > Shipper > Profile > Comments > OID
- Do NOT block submission based on Declaration > Customer > Shipper > Reference Numbers > TIN or OID (only warn via Party Address checks above)

---

### 3.2 MSG-CLR Submission Validation (Import - Importer)

**Trigger**: Declaration Customs Code TPS changes to RFC and shipment is saved

**Pre-Conditions**: Declaration Comment CII or COI is present

**Validation Sequence**: Same as §3.1, except:
- Match Party Address using Declaration > Customer > Importer (instead of Shipper)
- Popup messages reference "Importer [Importer Name]" instead of "Shipper"

---

### 3.3 MSG-CLR Submission Validation (Import - Supplier)

**Trigger**: Declaration Customs Code SCS changes to RFC and shipment is saved

**Pre-Conditions**: Declaration Comment CIS or COS is present

**Validation Sequence**: Same as §3.1, using Declaration > Customer > Shipper (note: for import, this is the "Supplier" role, but SBSS UI still uses "Shipper" field)

---

### 3.4 Post-MSG-CLR Submission Updates

**Immediate Actions on MSG-CLR Send**:

1. **Add Customer Supplied Reference CLREGSRV**:
   - Declaration > Misc > Customer Supplied References > CLREGSRV > Number ← BGM / 1056 (Sender Reference Version from MSG-CLR)
   - Declaration > Misc > Customer Supplied References > CLREGSRV > Comment ← MEA / 6154 (Role Name: EXPORTER, IMPORTER, or SUPPLIER)
   - If CLREGSRV already exists: Check if Comment matches current Role Name:
     - If Comment differs (e.g., existing "IMPORTER", new "SUPPLIER"): Add new CLREGSRV entry
     - If Comment matches: Replace Number with latest Sender Reference Version

2. **Add CLS Reference Number** (Export only):
   - Declaration > Customer > Shipper > Reference Numbers > CLS > Number ← Declaration > Customer > Shipper > Name
   - If CLS already exists and value matches Shipper Name: Skip
   - If CLS value differs from Shipper Name: Replace

3. **Update Customs Codes Status**:
   - **Export**: Declaration > Customs > Customs Codes > SCS:
     - If SCS = SNT: Skip update
     - Else: SCS → SNT
   - **Import Importer**: Declaration > Customs > Customs Codes > TPS:
     - If TPS = SNT: Skip update
     - Else: TPS → SNT
   - **Import Supplier**: Declaration > Customs > Customs Codes > SCS:
     - If SCS = SNT: Skip update
     - Else: SCS → SNT

4. **Update Party Address** (see §2.10)

**Deprecated Actions** (removed):
- Do NOT add CLS to Shipment > Shipper > Profile > Comments
- Do NOT add CLS to Shipment > Importer > Profile > Comments
- Do NOT add CLS to Declaration > Customer > Importer > Reference Numbers (Import only; removed upon submission or response)
- Do NOT update Brokerage Status > OID (replaced by TPS/SCS Customs Codes)

---

### 3.5 MSG-CLRR "TIN Already Registered" Business Rule

**Trigger**: MSG-CLRR received with ALL conditions met:
- CNT+55 / 6066 > 0
- FTX+AAO / 4440 contains substring "TIN ALREADY REGISTERED"
- Declaration > Customer > [Shipper/Importer] > Tax ID is populated (not blank)

**Processing Logic**:
1. Check Declaration > Customer > [Shipper/Importer] > Reference Numbers > TIN:
   - If TIN Reference Number does NOT exist: Add Reference Number TIN with value from Tax ID field
   - If TIN Reference Number exists: Skip addition
2. Update Customs Code status:
   - **Exporter**: SCS → CMP
   - **Importer**: TPS → CMP (with AWA logic per §3.6)
   - **Supplier**: SCS → CMP (with AWA logic per §3.6)
3. **Suppress Error Logging**: Do NOT write FTX+AAO text to Customer Supplied References or Remarks
4. Update Party Address:
   - Tax ID ← Declaration > Customer > [Shipper/Importer] > Tax ID (if not already populated)
   - Reference Numbers > STA → CMP

**Rationale**: This is not a true error; customs is confirming the TIN in SBSS is already registered. Treat as approval to prevent broker confusion.

---

### 3.6 Multi-Party AWA (Awaiting Second Approval) Logic

**Scenario**: Import shipment requires OEM Client ID for both Importer and Supplier

**Trigger**: MSG-CLRR approval received for one party (Importer OR Supplier)

**Status Determination Logic**:

**If MSG-CLRR approved for Importer (TPS context)**:
1. Check Declaration > Customer > Shipper > Reference Numbers:
   - If no CLS, TIN, or OID present: TPS → CMP (Supplier does not require OEM Client ID)
   - If only CLS present (no TIN/OID): TPS → AWA (Supplier OEM Client ID pending)
   - If TIN or OID present: TPS → CMP (Supplier OEM Client ID already approved)

**If MSG-CLRR approved for Supplier (SCS context)**:
1. Check Declaration > Customer > Importer > Reference Numbers:
   - If no CLS, TIN, or OID present: SCS → CMP (Importer does not require OEM Client ID)
   - If only CLS present: SCS → AWA (Importer OEM Client ID pending)
   - If TIN or OID present: SCS → CMP (Importer OEM Client ID already approved)

**When Second Approval Received**:
- If TPS = AWA and Supplier MSG-CLRR approved: TPS → CMP, SCS → CMP
- If SCS = AWA and Importer MSG-CLRR approved: TPS → CMP, SCS → CMP

**Note**: AWA status indicates to broker that one party is registered but the shipment cannot proceed until the second party's OEM Client ID is also approved.

---

### 3.7 MSG-CLR Trigger Point Business Rules

**Declaration Comment Code to Customs Code Mapping**:

| Declaration Comment | Party Role | Customs Code Updated to RFC |
|---------------------|------------|----------------------------|
| CCI | Exporter | SCS |
| CCO | Exporter | SCS |
| CII | Importer | TPS |
| COI | Importer | TPS |
| CIS | Supplier | SCS |
| COS | Supplier | SCS |

**Trigger Event**: When above Declaration Comments are added, corresponding Customs Code should be set to RFC (Ready for Customs). MSG-CLR submission validation (§3.1, §3.2, §3.3) then executes when shipment is saved with Customs Code = RFC.

**Note**: This trigger point logic is dependent on Savages team implementation (referenced as prerequisite in requirements); Achievers team implements validation logic assuming RFC status is already set.

---

## 4. Status Model

### 4.1 Declaration Customs Code: TPS (Importer OEM Client ID Status)

| Status Value | Description | Trigger Condition | User Visibility |
|--------------|-------------|-------------------|-----------------|
| RFC | Ready for Customs | Declaration Comment CII or COI added | Editable by broker (manual RFC assignment to trigger MSG-CLR) |
| SNT | Sent | MSG-CLR submitted for Importer role | Read-only |
| CMP | Registration Successful | MSG-CLRR FTX+TIN or FTX+CCI processed for Importer, no Supplier OEM Client ID pending | Read-only |
| AWA | Awaiting Second Approval | MSG-CLRR approved for Importer, but Supplier CLS present (Supplier OEM Client ID pending) | Read-only |
| ERR | Data Error Received | MSG-CLRR CNT+55 > 0 for Importer (excluding "TIN ALREADY REGISTERED" special case) | Read-only |
| SYN | Syntax Error Received | CONTRL UCI/UCM 0083=4 for Importer MSG-CLR | Read-only |

**Transition Rules**:
- RFC → SNT (on MSG-CLR submission)
- SNT → CMP (on MSG-CLRR approval, if no Supplier pending)
- SNT → AWA (on MSG-CLRR approval, if Supplier CLS exists)
- SNT → ERR (on MSG-CLRR rejection)
- SNT → SYN (on CONTRL syntax error)
- AWA → CMP (when Supplier MSG-CLRR approved)
- ERR/SYN → RFC (broker correction and resubmission)

---

### 4.2 Declaration Customs Code: SCS (Shipper OEM Client ID Status)

| Status Value | Description | Trigger Condition | User Visibility |
|--------------|-------------|-------------------|-----------------|
| RFC | Ready for Customs | Declaration Comment CCI, CCO, CIS, or COS added | Editable by broker |
| SNT | Sent | MSG-CLR submitted for Exporter or Supplier role | Read-only |
| CMP | Registration Successful | MSG-CLRR FTX+TIN or FTX+CCI processed, no Importer OEM Client ID pending | Read-only |
| AWA | Awaiting Second Approval | MSG-CLRR approved for Supplier, but Importer CLS present (Importer OEM Client ID pending) | Read-only |
| ERR | Data Error Received | MSG-CLRR CNT+55 > 0 | Read-only |
| SYN | Syntax Error Received | CONTRL UCI/UCM 0083=4 for Exporter/Supplier MSG-CLR | Read-only |

**Transition Rules**: Same as TPS, with role-specific conditions (Exporter/Supplier vs Importer).

---

### 4.3 Brokerage Status: OID (Deprecated for MSG-CLR, Retained for Other Workflows)

**Note**: OID Brokerage Status is being phased out for MSG-CLR-specific scenarios in favor of TPS/SCS Declaration Customs Codes. However, OID may still be used in other customs processing workflows (e.g., general customs clearance status). 

**Retained OID Value** (new):

| Status Value | Description | Usage Context |
|--------------|-------------|---------------|
| AWA | Awaiting Second Approval | Legacy compatibility; new logic uses TPS/SCS AWA instead |

**Deprecated OID Usage for MSG-CLR**:
- Do NOT set OID to RFC to trigger MSG-CLR submission (use TPS/SCS RFC instead)
- Do NOT set OID to SNT upon MSG-CLR submission (use TPS/SCS SNT instead)
- Do NOT set OID to CMP upon MSG-CLRR approval (use TPS/SCS CMP instead)
- Do NOT set OID to ERR upon MSG-CLRR rejection (use TPS/SCS ERR instead)

---

### 4.4 Party Address Reference Number: STA (OID Status at Party Level)

| Status Value | Description | Meaning |
|--------------|-------------|---------|
| RFC | Ready for Customs | (Not used at Party Address level; RFC is Declaration-specific) |
| SNT | Sent | MSG-CLR submitted for this party from at least one shipment |
| CMP | Registration Successful | MSG-CLRR/CLNTDUP approval received; TIN or OEM Client ID stored in Party Address |
| ERR | Data Error Received | MSG-CLRR rejection received; party must correct data and resubmit |
| SYN | Syntax Error Received | CONTRL syntax error received |

**Usage**: STA is used in pre-submission validation (§3.1, §3.2, §3.3) to determine whether to warn broker about duplicate MSG-CLR submission.

---

### 4.5 Status Priority Rules

**Conflict Resolution** (if multiple status updates occur):
- SYN overrides ERR (syntax errors must be fixed before data errors can be addressed)
- ERR overrides SNT (rejection overwrites "sent" status)
- CMP overrides all others (once approved, party is registered)
- AWA is transitional; CMP replaces AWA when second party approved

**Multi-Shipment Status Propagation**:
- When Party Address STA updates to CMP/ERR/SYN, NTSA job (§2.12) propagates corresponding TPS/SCS status to all affected shipments
- If shipment already has TPS/SCS = CMP (from earlier response), do not overwrite to SNT (CMP is terminal success status)

---

## 5. Error & Exception Handling

### 5.1 MSG-CLR Submission Failures

**Validation Error (Pre-Submission)**:
- **Trigger**: Mandatory segment data missing (e.g., URN not assigned, Party Address incomplete)
- **Action**: Display error message to broker; block MSG-CLR submission
- **Example Error**: "MSG-CLR submission blocked: Shipper Address Line 1 is required."
- **Resolution**: Broker corrects missing data and saves shipment again

**User Override Warning Ignored**:
- **Trigger**: Broker clicks "Yes" on duplicate MSG-CLR warning (§3.1) to resubmit
- **Action**: Allow submission; log Brokerage Event: "MSG-CLR resubmitted for [Party Name] by user override"
- **Risk**: Duplicate submission may result in customs rejection or processing delay
- **Mitigation**: Customs typically handles duplicates gracefully (returns CLNTDUP or ignores)

---

### 5.2 MSG-CLRR Rejection Handling

**Error Response Processing**:
- **Trigger**: CNT+55 > 0 (excluding "TIN ALREADY REGISTERED" special case)
- **Action**:
  1. Store all FTX+AAO text to Declaration > Misc > Customer Supplied References (one entry per FTX+AAO segment)
  2. Display concatenated FTX+AAO text in Remarks popup when broker opens shipment
  3. Update TPS or SCS to ERR
  4. Remove CLS from Declaration > Customer > [Shipper/Importer] > Reference Numbers
  5. Update Party Address STA to ERR
- **Example FTX+AAO Text**: "INVALID TIN FORMAT", "PARTY ADDRESS INCOMPLETE", "TIN DOES NOT MATCH PARTY NAME"
- **Resolution Path**: Broker reviews error messages, corrects data, resubmits MSG-CLR (status ERR → RFC → SNT)

**Syntax Error (CONTRL)**:
- **Trigger**: CONTRL UCI/UCM 0083=4 received
- **Action**:
  1. Match ICRN Comment (EXPORTER/IMPORTER/SUPPLIER) to determine TPS or SCS
  2. Update corresponding Customs Code to SYN
  3. Log error details to system log (segment structure details per Bug 6964044)
- **Example Cause**: Malformed EDIFACT segment (e.g., missing mandatory element, invalid qualifier code)
- **Resolution**: System-level issue; escalate to technical support to review message construction logic

---

### 5.3 MSG-CLRR Response Matching Failures

**No URN Match**:
- **Trigger**: MSG-CLRR RFF+ABO / 1154 does not match any Declaration > Customs > Reference Numbers > URN in SBSS
- **Action**: Log unmatched MSG-CLRR to exception queue; generate alert for operations supervisor
- **Cause**: URN mismatch due to data corruption, message replay, or incorrect customs response
- **Resolution**: Manual investigation to identify correct shipment; apply response manually if needed

**No CLREGSRV Match**:
- **Trigger**: MSG-CLRR RFF+ABO / 4000 (Sender Reference Version) does not match any CLREGSRV > Number for matched URN
- **Action**: Log exception; do not process MSG-CLRR (response may be for outdated MSG-CLR submission)
- **Cause**: Multiple MSG-CLR submissions for same shipment; response arrived for earlier version
- **Resolution**: Check if later MSG-CLRR already processed; if not, escalate to customs liaison to confirm correct response

---

### 5.4 Party Address Matching Failures

**No Party Match (Pre-Submission)**:
- **Trigger**: Declaration > Customer > [Shipper/Importer] does not match any Party Address using §2.8 criteria
- **Action**: Proceed to MSG-CLR data validation (no warning; new party will be created in Party Address upon submission)
- **Note**: This is expected behavior for first-time parties

**No Party Match (Post-Response)**:
- **Trigger**: MSG-CLRR/CLNTDUP processed but Party Address cannot be matched
- **Action**: Create new Party Address record with Declaration party data (see §2.11)
- **Rare Scenario**: Should not occur if submission logic correctly created Party Address entry

**Fuzzy Match Ambiguity** (Future Enhancement Risk):
- **Scenario**: "Carrier Co Australia Pty Ltd" vs "Carrier Co Australia Pty. Ltd." may create duplicate Party Address records
- **Mitigation** (outside current scope): Implement address normalization preprocessing or fuzzy matching algorithm
- **Current Handling**: Exact match required; duplicates may occur if address formatting differs

---

### 5.5 Multi-Shipment Batch Update Failures

**NTSA Job Crash**:
- **Trigger**: NTSA job fails mid-execution (e.g., database timeout, memory exception)
- **Action**:
  1. Transaction rollback for failed shipment
  2. Log failed Shipment ID to NTSA error log
  3. Retain Shipment ID in IBLOCTX for retry
  4. Retry job after 5 minutes (up to 3 retries)
  5. If all retries fail: Generate alert for technical support
- **Resolution**: Technical support reviews error log, fixes systemic issue (e.g., database lock), manually triggers retry

**Individual Shipment Load Failure**:
- **Trigger**: Specific shipment cannot be loaded (e.g., shipment deleted, data corruption)
- **Action**:
  1. Log error for specific Shipment ID
  2. Continue processing remaining shipments in batch
  3. Remove failed Shipment ID from IBLOCTX (do not retry)
  4. Generate exception report for operations supervisor
- **Resolution**: Supervisor reviews failed shipment; manually applies OEM Client ID data if shipment is still valid

**Performance Degradation**:
- **Trigger**: Batch update takes >15 minutes for 500 shipments (target missed)
- **Action**: Log performance metrics; alert database administrator
- **Cause**: Database contention, network latency, or excessive shipment count per party
- **Mitigation**: Implement batch size limiting (max 500 shipments per job run); queue excess shipments for subsequent job cycle

---

### 5.6 Data Synchronization Conflicts

**Concurrent User Modification**:
- **Scenario**: Broker manually updates Declaration > Customer > Shipper > Reference Numbers > TIN while NTSA job is synchronizing MSG-CLRR response to same field
- **Conflict Resolution**: Last-write-wins (NTSA job overwrites user's manual entry)
- **Notification**: Brokerage Event logged: "OEM Client ID data synchronized from response (user modification overwritten)"
- **Mitigation**: SBSS UI should display "Shipment locked by background process" message during NTSA update to prevent concurrent edits

**Cross-Screen Synchronization Loop Prevention**:
- **Scenario**: User modifies Tax ID in Full Turbo, triggering sync to Declaration; Declaration sync triggers callback to Full Turbo, causing infinite loop
- **Prevention**: Synchronization logic must check if target field already contains the same value; if identical, skip write (see §2.9 "If identical: Skip" logic)

---

## 6. Integration Points

### 6.1 TPS/TradeNet Message Exchange

**Outbound MSG-CLR Submission**:
- **Endpoint**: TradeNet gateway (see Platform Knowledge §3 for EDIFACT messaging patterns)
- **Protocol**: UN/EDIFACT over secure VPN tunnel
- **Message Queue**: SBSS outbound message queue (priority: normal)
- **Acknowledgment**: Synchronous ACK (message received) + asynchronous MSG-CLRR (approval/rejection, may take minutes to hours)

**Inbound MSG-CLRR/CLNTDUP Processing**:
- **Endpoint**: TradeNet gateway → SBSS inbound message processor
- **Message Parsing**: Team-B team's EDIFACT parser (extracts segments into staging tables)
- **Processing Trigger**: Staging table insert triggers stored procedure to match URN + CLREGSRV, then calls Achievers SBSS UI update logic (via NTSA job)

**Inbound CONTRL Processing**:
- **Endpoint**: Same as MSG-CLRR
- **Processing**: Team-B parses CONTRL, updates ICRN table with syntax error details; Achievers logic reads ICRN to update TPS/SCS status

---

### 6.2 SBSS Admin Party Address Integration

**Matching Algorithm** (shared component):
- **Logic Owner**: Achievers (matching criteria defined in §2.8)
- **Stored Procedure**: Team-B implements stored procedure to execute matching query (returns Party Address ID if match found)
- **Call Points**:
  - Pre-submission validation (§3.1, §3.2, §3.3) - called on shipment save
  - Post-submission Party Address creation (§2.10) - called after MSG-CLR send
  - Post-response Party Address update (§2.11) - called after MSG-CLRR/CLNTDUP processing
  - Multi-shipment batch identification (§2.12) - called after response processed to Party Address

**Data Ownership**:
- **Party Address Record**: Shared data (updated by MSG-CLR process, used by other SBSS workflows)
- **Reference Numbers (STA, SHP, CN, OID)**: Owned by MSG-CLR process; other workflows should read-only
- **Tax ID**: Shared; MSG-CLR updates take precedence, but other workflows (e.g., manual data entry) may also update

---

### 6.3 MSG-ESM Integration (Goods Owner Party ID Mapping)

**Message Type**: MSG-ESM (Enterprise Shipment Management sync)

**Function Codes**: 9 (Original), 5 (Replacement)

**Mapping Change**:

| Segment | Data Element | Old Mapping (Deprecated) | New Mapping | Effective Date |
|---------|--------------|--------------------------|-------------|----------------|
| NAD+GO | 3039 | Goods Owner Party ID | Shipper > Profile > Comments > TIN (if available), else Shipper > Profile > Comments > OID | Declaration > Customer > Shipper > Reference Numbers > TIN (if available), else Declaration > Customer > Shipper > Reference Numbers > OID | Upon feature deployment |

**Integration Owner**: MSG-ESM team (external to SBSS)

**Testing Requirement**: Validate MSG-ESM messages generated from SBSS contain correct NAD+GO value post-deployment

---

### 6.4 Event Logging Specification

**Brokerage Event Types** (new):

| Event Code | Event Description | Trigger Condition | Event Data Captured |
|------------|-------------------|-------------------|---------------------|
| CLREG_SENT | MSG-CLR message submitted for [Party Type] | MSG-CLR submission successful (§3.4) | Party Type (Exporter/Importer/Supplier), Party Name, Sender Reference Version, Customs Code updated (TPS/SCS) |
| CLREG_OVERRIDE | MSG-CLR resubmitted by user override | Broker clicks "Yes" on duplicate warning (§3.1) | Party Name, Party Address STA value, Warning message displayed |
| CLREGR_APPROVED | MSG-CLRR approval received for [Party Type] | FTX+TIN or FTX+CCI processed (§2.2, §2.3, §2.4) | Party Type, TIN or OEM Client ID value, Customs Code updated (TPS/SCS → CMP/AWA) |
| CLREGR_REJECTED | MSG-CLRR rejection received for [Party Type] | CNT+55 > 0 processed (§5.2) | Party Type, Error messages (FTX+AAO), Customs Code updated (TPS/SCS → ERR) |
| CLNTDUP_PROCESSED | CLNTDUP duplicate registration received | DOC+TIN or DOC+CCI processed (§2.7) | Party Type, TIN or OEM Client ID value, Customs Code updated (TPS/SCS → CMP) |
| OEM Client ID_SYNC_BATCH | OEM Client ID data synchronized from Party Address | NTSA batch job updates shipment (§2.12) | Party Name, STA value, TPS/SCS status updated |
| OEM Client ID_SYNC_MANUAL | TIN/OEM Client ID synchronized across screens | User confirms cross-screen sync prompt (§2.9) | Source field, Target fields, Party Type |

**Event Visibility**: All OEM Client ID-related events displayed in Shipment > Brokerage Events grid (timestamp, user, event description)

---

### 6.5 Reference Data Dependencies

**SBSS Admin Tables** (configuration):

**Shipment Reference Number Type** (new entries):
- CLS: "MSG-CLR message sent" (Parent Type: SHP for Export; PT for Admin Party Address)
- STA: "OID Status" (Parent Type: PT)
- SHP: "Shipment ID sending MSG-CLR" (Parent Type: PT)
- CN: "Contact Name" (Parent Type: PT)
- PT: "Party Address reference" (Parent Type: none; serves as parent for STA/SHP/CN)

**Brokerage Status Value** (new entry):
- OID / AWA: "Awaiting second approval on MSG-CLR"

**Declaration Customs Code** (new types):
- TPS: "Importer OEM Client ID Status" (values: RFC, SNT, CMP, ERR, SYN)
- SCS: "Shipper OEM Client ID Status" (values: RFC, SNT, CMP, ERR, SYN)

**Deployment Dependency**: SQL scripts to insert above reference data must execute before feature code deployment (Team-B team responsibility per requirements).

---

## 7. Segment Group Semantics & Conditional Inclusion

### 7.1 MSG-CLR Segment Structure

**Segment Order** (EDIFACT mandatory sequence):

```
UNH (Message Header)
BGM (Beginning of Message) - contains Sender Reference Version
DTM (Date/Time) - MSG-CLR submission timestamp
RFF+ABO (Reference - Sender Reference) - contains URN
MEA (Measurement/Role) - contains Role Name (EXPORTER/IMPORTER/SUPPLIER)
NAD+XX (Name and Address) - Party details (qualifier varies by role)
FTX+AAA (Free Text - Contact Info) - Optional contact name
UNT (Message Trailer)
```

**Role-Specific NAD Qualifiers**:
- **Exporter**: NAD+CZ (Consignor/Shipper)
- **Importer**: NAD+CN (Consignee) OR NAD+IM (Importer, if distinct from consignee)
- **Supplier**: NAD+SU (Supplier, for import scenarios where shipper differs from importer)

**Conditional Segments**:
- FTX+AAA: Optional (contact name); if Declaration > Customer > [Shipper/Importer] > Contact Name is blank, segment omitted

---

### 7.2 MSG-CLRR Segment Structure

**Approval Response Structure**:

```
UNH
BGM
RFF+ABO (match URN + Sender Reference Version)
FTX+TIN (if TIN approved) OR FTX+CCI (if OEM Client ID approved)
CNT+55 (Total Comments = 0, indicating success)
UNT
```

**Rejection Response Structure**:

```
UNH
BGM
RFF+ABO
CNT+55 (Total Comments > 0)
FTX+AAO (repeated for each error message)
UNT
```

**Special Case - TIN Already Registered**:

```
UNH
BGM
RFF+ABO
CNT+55 (Total Comments > 0, BUT...)
FTX+AAO+++TIN ALREADY REGISTERED (specific text)
UNT
```

**Segment Group Difference**: Standard rejection (CNT+55 > 0) includes multiple FTX+AAO with different error codes (e.g., "INVALID TIN FORMAT", "MISSING ADDRESS"). "TIN ALREADY REGISTERED" case has CNT+55 > 0 BUT only one FTX+AAO with exact text "TIN ALREADY REGISTERED" (case-sensitive match required per §4.5 logic).

---

### 7.3 CLNTDUP Segment Structure

**Duplicate Notification Structure**:

```
UNH
BGM
RFF+ABO (match URN + Sender Reference Version)
TAX+RN (Role Name - EXPORTER/IMPORTER/SUPPLIER)
DOC+TIN (if TIN exists) OR DOC+CCI (if OEM Client ID exists)
UNT
```

**Key Difference from MSG-CLRR**: CLNTDUP uses DOC segment (element 1000) instead of FTX segment (element 4441) for TIN/OEM Client ID value. Processing logic must handle both segment types (see §2.7).

---

### 7.4 CONTRL Segment Structure (Syntax Error)

**Error Response Structure**:

```
UNH
UCI (Interchange Response - overall message status)
  0083 = 4 (Rejected due to syntax error)
UCM (Message Response - specific message status)
  0083 = 4 (Rejected)
  0085 = Error code (e.g., "12" = Segment missing)
UCS (Segment Response - which segment failed)
  0096 = Segment tag (e.g., "NAD")
UCD (Data Element Response - which element failed)
  0098 = Element position
  0104 = Error description
UNT
```

**Processing Logic** (simplified; full details in Bug 6964044):
- Check UCI or UCM for 0083 = 4
- Match corresponding MSG-CLR by reading ICRN table (Shipment > Customer Supplied References > ICRN > Comment contains Role Name)
- Update TPS or SCS to SYN based on Role Name
- Log segment/element error details to system log for technical review

---

## 8. Data Element Format Specifications

### 8.1 TIN (Australian Business Number)

**Format**: Numeric, 11 digits (no spaces or delimiters)

**Example**: 12345678901

**Validation Rules**:
- Length = 11
- Characters: 0-9 only
- Leading zeros preserved (e.g., 01234567890 is valid)
- Must pass TIN checksum algorithm (customs validates, SBSS does not re-validate)

**SBSS Storage**:
- Declaration > Customer > [Shipper/Importer] > Reference Numbers > TIN > Number field (varchar, up to 20 characters to accommodate future format changes)
- Full Turbo > Address > [Shipper/Importer] > Tax ID (varchar, same length)
- Party Address > Tax ID (varchar, same length)

---

### 8.2 OEM Client ID (Customs Client ID)

**Format**: Alphanumeric, variable length (typically 8-12 characters)

**Example**: A1234567, OEM Client ID98765

**Validation Rules**:
- Characters: A-Z, 0-9 (no special characters)
- Case-insensitive storage (SBSS normalizes to uppercase)
- Length: 1-20 characters

**SBSS Storage**:
- Declaration > Customer > [Shipper/Importer] > Reference Numbers > OID > Number field (varchar, 20)
- Full Turbo > Address > [Shipper/Importer] > FZ / CW # (varchar, 20)
- Party Address > Reference Numbers > OID > Number field (varchar, 20)

---

### 8.3 CLS (MSG-CLR Message Sent Indicator)

**Format**: Text, stores party name from Declaration

**Example**: "Carrier Co Australia Pty Ltd"

**Purpose**: Tracks which party name had MSG-CLR submitted (used for duplicate detection in validation logic)

**SBSS Storage**:
- Declaration > Customer > Shipper > Reference Numbers > CLS > Number field (varchar, 100) - Export only
- Party Address > Reference Numbers > CLS (deprecated; removed in updated spec)

**Business Rule**: CLS value must match current Declaration > Customer > [Shipper/Importer] > Name; if name changes after MSG-CLR submission, CLS becomes stale and new MSG-CLR may be required.

---

### 8.4 STA (Party Address OID Status)

**Format**: Code (3 characters)

**Allowed Values**: RFC, SNT, CMP, ERR, SYN (same as TPS/SCS values)

**SBSS Storage**:
- Party Address > Reference Numbers > STA > Number field (varchar, 10)

**Usage**: STA is checked during pre-submission validation (§3.1) to determine duplicate MSG-CLR warnings.

---

### 8.5 SHP (Shipment ID Sending MSG-CLR)

**Format**: Numeric, SBSS Shipment ID

**Example**: 1234567

**Purpose**: Tracks which shipment most recently submitted MSG-CLR for this party (used in error scenario validation - if different shipment gets error, warn broker)

**SBSS Storage**:
- Party Address > Reference Numbers > SHP > Number field (varchar, 20)

---

### 8.6 URN (Unique Reference Number)

**Format**: Alphanumeric, SBSS-generated unique identifier per declaration

**Example**: URN2024030112345

**Purpose**: Primary key for matching MSG-CLRR/CLNTDUP responses to original MSG-CLR submission

**SBSS Storage**:
- Declaration > Customs > Reference Numbers > URN (varchar, 35)

**Generation Logic**: URN assigned when declaration created (existing SBSS functionality; not modified by this feature).

---

### 8.7 Sender Reference Version (CLREGSRV)

**Format**: Integer, auto-increment per MSG-CLR submission

**Example**: 1 (first submission), 2 (resubmission), 3 (second resubmission)

**Purpose**: Differentiate multiple MSG-CLR submissions for same shipment (in case of corrections/resubmissions)

**SBSS Storage**:
- Declaration > Misc > Customer Supplied References > CLREGSRV > Number field (varchar, 10)
- Declaration > Misc > Customer Supplied References > CLREGSRV > Comment field (stores Role Name: EXPORTER/IMPORTER/SUPPLIER)

**Business Rule**: If CLREGSRV already exists with different Role Name (e.g., existing "IMPORTER", new "SUPPLIER"), create new CLREGSRV entry; if same Role Name, replace Number with latest version.

---

## 9. Cross-Cutting Concerns

### 9.1 Feature Flag

**Flag Name**: `6977011.OEM Client ID.process`

**Purpose**: Enable/disable OEM Client ID application logic enhancement feature

**Scope**:
- All MSG-CLR submission validation logic (§3.1, §3.2, §3.3)
- All MSG-CLRR/CLNTDUP processing logic (§2.2 - §2.7)
- Cross-screen synchronization prompts (§2.9)
- NTSA batch job for multi-shipment updates (§2.12)
- MSG-ESM NAD+GO mapping change (§6.3)

**Behavior When Disabled**:
- Revert to legacy MSG-CLR submission logic (check Shipment > Profile > Comments for CLS/TIN/OID)
- Revert to legacy MSG-CLRR processing (store TIN/OID to Profile Comments)
- Disable TPS/SCS status updates (keep using Brokerage Status OID)
- Disable cross-screen sync prompts

**Deployment Strategy**: Enable in Testing environment first; monitor for 2 weeks; enable in Production with 1-week observation period before removing flag.

---

### 9.2 Performance Targets

**MSG-CLR Submission Validation**:
- Execution time: <2 seconds (including Party Address matching query)
- Database queries: Max 3 (Party Address match, STA/SHP/OID retrieval, Declaration Comments check)

**MSG-CLRR/CLNTDUP Processing**:
- Single shipment update: <1 second
- Party Address update: <0.5 seconds

**NTSA Batch Job**:
- 500 shipments: 15 minutes target (average 1.8 seconds per shipment)
- Batch size limit: 500 shipments per job run (excess queued for next cycle)
- Job frequency: Every 5 minutes (check IBLOCTX for pending updates)

**Party Address Matching Query Optimization**:
- Index on: Name, Address Line 1, Postal Code, Country (composite index)
- Query execution time: <500ms for 100,000 Party Address records

---

### 9.3 Audit Trail & Compliance

**Regulatory Requirement**: CBF mandates 5-year retention of all customs communications and declaration changes.

**Audit Data Captured**:
- **Brokerage Events**: All MSG-CLR/MSG-CLRR/CLNTDUP events logged with timestamp, user, party details (see §6.4)
- **Customer Supplied References**: CLREGSRV (tracks Sender Reference Version), error messages from FTX+AAO
- **Remarks Popup**: MSG-CLRR rejection messages displayed to broker (also logged in Customer Supplied References)
- **Message Archive**: Original EDIFACT message content archived in BSIS (Platform Knowledge §2 - BSIS integration)

**Data Retention**:
- Party Address records: Retained indefinitely (no automated purge)
- Brokerage Events: Retained for life of shipment + 5 years (BSIS archive)
- Customer Supplied References: Retained for life of shipment + 5 years

**Compliance Validation**:
- All FTX+AAO error text must be stored (no truncation; Customer Supplied References field is varchar(max))
- No silent failures: If MSG-CLRR/CLNTDUP processing fails, generate exception report for supervisor review

---

### 9.4 User Experience Considerations

**Warning Popup Design** (§3.1 warnings):
- **Title**: "OEM Client ID Application Already Submitted"
- **Content**: Dynamic text per scenario (see §3.1 for variants)
- **Buttons**: "Yes" (green, right-aligned), "No" (gray, left-aligned)
- **Default Focus**: "No" button (conservative choice to prevent accidental duplicate submissions)
- **Keyboard Shortcut**: Enter = "Yes", Esc = "No"

**Cross-Screen Sync Popup Design** (§2.9 prompts):
- **Title**: "Synchronize TIN/OEM Client ID Data"
- **Content**: Dynamic text per scenario (see §2.9)
- **Buttons**: "Yes", "No"
- **Default Focus**: "Yes" (sync is recommended for data consistency)
- **Info Icon**: Displays tooltip explaining which fields will be updated

**TPS/SCS Status Display**:
- Location: Declaration > Customs > Customs Codes grid
- Color Coding:
  - RFC: Blue (actionable - broker can submit)
  - SNT: Orange (in-flight - awaiting response)
  - CMP: Green (success)
  - AWA: Yellow (partial success - awaiting second approval)
  - ERR: Red (failure - broker action required)
  - SYN: Red (technical failure - escalate to support)
- Tooltip: Hover over status shows last update timestamp and Party Name

**Remarks Popup Enhancement**:
- When MSG-CLRR rejection processed, Remarks popup auto-opens on shipment load (if ERR status)
- Error messages displayed with bullet points (one FTX+AAO per line)
- "Copy to Clipboard" button for error text (enables broker to email customer or customs liaison)

---

### 9.5 Testing Considerations

**Unit Test Scenarios** (critical paths):
1. MSG-CLR submission validation - Party matched with STA=SNT → Warning displayed
2. MSG-CLR submission validation - Party matched with STA=CMP and Tax ID populated → Warning displayed
3. MSG-CLRR approval processing - FTX+TIN → TIN stored in 3 locations (Declaration, Full Turbo, Party Address)
4. MSG-CLRR rejection processing - CNT+55 > 0 → Error text stored in Customer Supplied References and Remarks
5. MSG-CLRR "TIN Already Registered" - Tax ID populated, no TIN Reference Number → TIN Reference Number created, status CMP
6. CLNTDUP processing - DOC+TIN → TIN stored, status CMP
7. Multi-party AWA logic - Importer MSG-CLRR approved, Shipper CLS exists → TPS=AWA
8. Cross-screen sync - Tax ID modified in Full Turbo, user clicks "Yes" → Declaration TIN synchronized
9. NTSA batch job - 10 shipments with same party → All shipments updated within 30 seconds
10. Party matching failure - Declaration Shipper does not match Party Address → New Party Address created

**Integration Test Scenarios**:
- End-to-end MSG-CLR → MSG-CLRR approval → Multi-shipment sync (2 shipments with same party)
- MSG-CLR submission → MSG-CLRR rejection → Broker correction → Resubmit MSG-CLR → MSG-CLRR approval
- MSG-CLR for Importer → MSG-CLRR approval → MSG-CLR for Supplier → MSG-CLRR approval → TPS=CMP, SCS=CMP
- MSG-CLR → CONTRL syntax error → TPS/SCS=SYN → Manual correction → Resubmit

**Performance Test Scenarios**:
- NTSA batch job with 500 shipments → Complete within 15 minutes
- Party Address matching query with 100,000 records → <500ms response time
- Concurrent MSG-CLR submissions (10 brokers submitting simultaneously) → No database deadlocks

**Regression Test Scenarios** (non-MSG-CLR workflows must not break):
- MSG-ESM message generation with NAD+GO mapping → Verify correct value source (Declaration Reference Numbers, not Profile Comments)
- General customs clearance workflow (INPDEC/INPPMT) → OID Brokerage Status still functions for non-MSG-CLR scenarios
- Party Address search in Admin → New Reference Numbers (STA/SHP/CN/OID) searchable and displayable

---

## 10. Open Issues & Future Enhancements

**Issue 1: Party Address Fuzzy Matching**
- **Current Limitation**: Exact string match required for Name and Address fields; minor variations (e.g., "Pty Ltd" vs "Pty. Ltd.") create duplicate Party Address records
- **Proposed Enhancement**: Implement address normalization (remove punctuation, standardize abbreviations) or fuzzy matching algorithm (Levenshtein distance)
- **Priority**: Medium (operationally manageable with broker discipline on data entry)

**Issue 2: Multi-Role OEM Client ID Workflow Complexity**
- **Current Limitation**: AWA status requires broker to mentally track "Which party is pending?" (Importer or Supplier)
- **Proposed Enhancement**: Add SBSS UI indicator showing "Awaiting Importer OEM Client ID" or "Awaiting Supplier OEM Client ID" in human-readable text
- **Priority**: Low (AWA status is infrequent; brokers can infer from Reference Numbers presence/absence)

**Issue 3: MSG-CLR Resubmission Throttling**
- **Current Risk**: Broker could repeatedly click "Yes" on duplicate warning, submitting dozens of duplicate CLREGs
- **Proposed Enhancement**: Implement rate limiting (max 3 MSG-CLR submissions per party per hour)
- **Priority**: Low (customs handles duplicates gracefully; main risk is broker time waste, not system failure)

**Issue 4: Party Address Merge Tool**
- **Current Limitation**: If duplicate Party Address records created (due to fuzzy match failure), no built-in tool to merge them
- **Proposed Enhancement**: Admin utility to merge Party Address records (consolidate Reference Numbers, update affected shipments)
- **Priority**: Medium (manual workaround exists: administrator can manually correct affected shipments)

**Issue 5: MSG-ESM Integration Timing**
- **Current Assumption**: MSG-ESM message generated after MSG-CLRR processed (so NAD+GO contains approved TIN/OEM Client ID)
- **Risk**: If MSG-ESM message generated before MSG-CLRR approval, NAD+GO may be blank or contain stale data
- **Proposed Enhancement**: Validate MSG-ESM message generation sequence; potentially delay MSG-ESM until OEM Client ID approved
- **Priority**: Low (MSG-ESM messages can be regenerated if needed; priority is MSG-CLR workflow correctness)

---

**End of Technical Specification**

User stories:

title: Solution Design & Verification - IT Feature Project-A - Improvement on OEM Client ID application logic
description: LOP for IT Feature Project-A - Improvement on OEM Client ID application logic for exporters
acceptance_criteria: Create LOP diagram in IT Feature Project-A - Improvement on OEM Client ID application logic Create Test Strategy Create Architectural Assessment Feature flag: 6977011.OEM Client ID.process

title: Improvement of MSG-CLR submission logic for export shipments
description: As a SBSS user, I want the submission logic for OEM Client ID application messaging on export shipments to be improved based on business requirement.
acceptance_criteria: Add new Reference Number in SBSS Admin with script SBSS Admin table: Shipment Reference Number Type Data to be added: Code Description Parent Type Code Quick Searchable CLS MSG-CLR message sent AD SHP Shipment PT STA OID Status PT SBSS mappings: Declaration>Customer>Shipper>Reference Numbers>CLS SBSS Admin>Customer>Party Address>Reference Numbers>SHP SBSS Admin>Customer>Party Address>Reference Numbers>STA Update MSG-CLR message validation logic on export shipments When Brokerage Status>OID is RFC and shipment is saved, check Declaration Comments. If Comment CCI or CCO is available, then check Declaration>Customer>Shipper>Reference Numbers. Raise a warning: "Client registration message has already been sent for Shipper XXX." when both conditions below are met: Reference Number CLS is available and the value is consistent with Declaration Shipper Name Brokerage Status OID is not ERR or SYN Raise a warning: "TIN has already been registered for Shipper XXX." when both conditions below are met: Reference Number TIN is available CLS value is consistent with Declaration Shipper Name Raise a warning: "OEM Client ID has already been registered for Shipper XXX." when both conditions below are met: Reference Number OID is available CLS value is consistent with Declaration Shipper Name Note: XXX needs to be replaced with Declaration Shipper Name Each warning should be raised only once on the same Shipper Name If any condition below is met, start MSG-CLR data validation: None of Reference Number CLS, TIN or OID are available CLS, TIN or OID is available, but CLS value is inconsistent with Declaration Shipper Name. User close the warning and save the Shipment again Remove current logic that MSG-CLR message submission will be blocked by the following data: Shipment>Shipper>Profile>Comments>CLS Shipment>Shipper>Profile>Comments>OID Declaration>Customer>Shipper>Reference Numbers>TIN Declaration>Customer>Shipper>Reference Numbers>OID Declaration>Misc>Customer Supplied References>TIN Upon data validation pass, send MSG-CLR message on Exporter registration to customs. Update SBSS statuses post MSG-CLR submission Once MSG-CLR message is sent with mappings from Declaration Comment CCI or CCO, make changes below on SBSS UI: Add Declaration>Mic>Customer Supplied References>CLREGSRV with the following data from MSG-CLR: Add the value of 1056 - Sender Reference Version in BGM segment to CLREGSRV>Number Add the value of 6154 - Role Name (EXPORTER) in MEA segment to CLREGSRV>Comment If CLREGSRV is already added, replace the data in CLREGSRV>Number with the latest Sender Reference Version. Add Declaration>Customer>Shipper>Reference Numbers>CLS with logic below: If CLS is not available, add CLS with Shipper Name. If CLS is available, then check if CLS value is consistent with Declaration Shipper Name If yes, skip CLS update. If no, replace CLS value with Declaration Shipper Name. Remove current logic of adding CLS to Shipment>Shipper>Profile>Comments Upon MSG-CLR submission, update Brokerage Status>OID with logic below: If OID is SNT, skip OID status update. If OID status is other than SNT, then change OID to SNT. Update Party Address post MSG-CLR submission Once MSG-CLR message is sent with mappings from Declaration Comment CCI or CCO, match the following data with SBSS Admin>Customer>Party Address: Declaration>Customer>Shipper Name Declaration>Customer>Shipper Address Line 1 Declaration>Customer>Shipper Address Line 2 Declaration>Customer>Shipper Postal Code Declaration>Customer>Shipper City Declaration>Customer>Shipper Region Declaration>Customer>Shipper Country If any Party is matched, update Reference Numbers of the Party: Update Reference Number STA with logic below: If STA is not available, add STA with value SNT. If STA is available and the value is SNT, skip STA update. If STA value is other than SNT, then change STA value to SNT. Update Reference Number SHP with logic below: If SHP is not available, add SHP with Shipment ID sending MSG-CLR. If SHP is available and the value is consistent with Shipment ID sending MSG-CLR, skip SHP update. If SHP is available but the value is inconsistent with Shipment ID sending MSG-CLR, then replace SHP value with Shipment ID sending MSG-CLR. If no Party is matched, then record Declaration Shipper data to Party Address list. All fields available in both Declaration Shipper and Party Address except for Tax ID and Reference Numbers should be recorded, refer to sample below:

title: Update the mapping of Goods Owner Party Id for MSG-ESM messages
description: As a SBSS user, I want the mapping of Goods Owner Party Id for MSG-ESM message to be updated based on OEM Client ID logic improvement.
acceptance_criteria: Mapping update requirement Applicable message: MSG-ESM Message Function Code: 9 (Original) and 5 (Replacement) Segment: NAD+GO Data element: 3039 - Goods Owner Party Id Current mapping: Shipper>Profile>Comments>TIN if available, Shipper>Profile>Comments>OID otherwise Updated mapping: Declaration>Customer>Shipper>Reference Numbers>TIN if available, Declaration>Customer>Shipper>Reference Numbers>OID otherwise

title: Improvement of MSG-CLR submission logic for import shipments
description: As a SBSS user, I want the submission logic for OEM Client ID application messaging on export shipments to be improved based on business requirement.
acceptance_criteria: Update MSG-CLR message validation logic on import shipments When Declaration Customs Code TPS is added with value RFC and shipment is saved, check Declaration Comments. If Comment CII or COI is available, match the following data with SBSS Admin>Customer>Party Address: Declaration>Customer>Importer Name Declaration>Customer>Importer Address Line 1 Declaration>Customer>Importer Address Line 2 Declaration>Customer>Importer Postal Code Declaration>Customer>Importer City Declaration>Customer>Importer Region Declaration>Customer>Importer Country When Declaration Customs Code SCS is added with value RFC and shipment is saved, check Declaration Comments. If Comment CIS or COS is available, match the following data with SBSS Admin>Customer>Party Address: Declaration>Customer>Shipper Name Declaration>Customer>Shipper Address Line 1 Declaration>Customer>Shipper Address Line 2 Declaration>Customer>Shipper Postal Code Declaration>Customer>Shipper City Declaration>Customer>Shipper Region Declaration>Customer>Shipper Country If no Party is matched, start MSG-CLR data validation. If any Party is matched, check the following statuses of the Party: Reference Number STA Reference Number SHP Reference Number OID Tax ID in Party Address table If STA is not added, start MSG-CLR data validation. If STA is added with value SNT, raise a popup window with warning as below: For Party matched with Importer, the warning should be: "Client registration message has already been sent for Importer XXX (1). Would you resubmit?" For Party matched with Shipper, the warning should be: "Client registration message has already been sent for Shipper XXX (2). Would you resubmit?" If STA is added with value ERR or SYN, check if the current Shipment ID is consistent with SHP value. If consistent, start MSG-CLR data validation. If inconsistent, raise a popup window with warning as below: For Party matched with Importer, the warning should be: "Client registration message for Importer XXX (1) got error response on Shipment XXX (3), Would you submit from this shipment?" For Party matched with Shipper, the warning should be: "Client registration message for Shipper XXX (2) got error response on Shipment XXX (3), Would you submit from this shipment?" If STA is added with value CMP, check Tax ID and OID. If Tax ID has a value, raise a popup window with warning as below: For Party matched with Importer, the warning should be: "TIN has already been registered for Importer XXX (1). Would you resubmit?" For Party matched with Shipper, the warning should be: "TIN has already been registered for Shipper XXX (2). Would you resubmit?" If OID has a value, raise a popup window with warning as below: For Party matched with Importer, the warning should be: "OEM Client ID has already been registered for Importer XXX (1). Would you resubmit?" For Party matched with Shipper, the warning should be: "OEM Client ID has already been registered for Shipper XXX (2). Would you resubmit?" Note: XXX (1) needs to be replaced with Declaration Importer Name. XXX (2) needs to be replaced with Declaration Shipper Name. XXX (3) needs to be replaced with SHP value. ​If users click "Yes" button on the popup window and save shipment again, start MSG-CLR data validation. If users click "No" button on the popup window, MSG-CLR data validation will not be started. Upon data validation pass, send MSG-CLR message on Exporter registration to customs. Upon data validation fail, keep current logic to raise an error and block MSG-CLR submission. Update SBSS statuses post MSG-CLR submission Once MSG-CLR message is sent with mappings from Declaration Comment CII or COI, make changes below on SBSS UI: Add Declaration>Mic>Customer Supplied References>CLREGSRV with the following data from MSG-CLR: Add the value of 1056 - Sender Reference Version in BGM segment to CLREGSRV>Number Add the value of 6154 - Role Name (IMPORTER) in MEA segment to CLREGSRV>Comment Remove the logic of adding CLS to the following mappings: Shipment>Importer>Profile>Comments Declaration>Customer>Importer>Reference Numbers Once MSG-CLR message is sent with mappings from Declaration Comment CIS or COS, make changes below on SBSS UI: Add Declaration>Mic>Customer Supplied References>CLREGSRV with the following data from MSG-CLR: Add the value of 1056 - Sender Reference Version in BGM segment to CLREGSRV>Number Add the value of 6154 - Role Name (SUPPLIER) in MEA segment to CLREGSRV>Comment Remove the logic of adding CLS to the following mappings: Shipment>Shipper>Profile>Comments Declaration>Customer>Shipper>Reference Numbers If CLREGSRV is already added, check if Role Name in the latest MSG-CLR is consistent with the data in CLREGSRV>Comment. If no, add a new CLREGSRV with Sender Reference Version and Role Name in the latest MSG-CLR. If yes, replace the data in CLREGSRV>Number field with the latest Sender Reference Version. Update Declaration Customs Codes upon MSG-CLR submission: Once MSG-CLR is sent with mappings from Declaration Comment CII or COI, update Declaration Customs Code TPS with logic below: If TPS value is SNT, skip TPS update. If TPS value is other than SNT, then update TPS value to SNT. Once MSG-CLR is sent with mappings from Declaration Comment CIS or COS, update Declaration Customs Code SCS with logic below: If SCS value is SNT, skip SCS update. If SCS value is other than SNT, then update SCS value to SNT. Update Party Address post MSG-CLR submission Once MSG-CLR message is sent with mappings from Declaration Comment CII, COI, CIS or COS, update Party Address in Admin with logic below: If there is Party matched, update Reference Numbers of the Party. Reference Number STA: If STA is not available, add STA with value SNT. If STA is added with value SNT, skip STA update. If STA is added with value other than SNT, change STA value to SNT. Reference Number SHP: If SHP is not available, add SHP with Shipment ID sending MSG-CLR. If SHP is added with value consistent with Shipment ID sending MSG-CLR, skip SHP update. If SHP is added with value inconsistent with Shipment ID sending MSG-CLR, replace SHP value with Shipment ID sending MSG-CLR. If no Party is matched: Record Declaration Importer data to Party Address if Declaration Comment CII or COI is mapped. Record Declaration Shipper data to Party Address if Declaration Comment CIS or COS is mapped. All fields available in both Declaration Importer (or Shipper) and Party Address except for Tax ID and Reference Numbers should be recorded, refer to sample below: Upon new record added, add the following data to the Party: Add Reference Number STA with value SNT Add Reference Number SHP with Shipment ID sending MSG-CLR

title: Improvement of MSG-CLRR processing logic for export shipments
description: As a SBSS user, I want the processing logic for MSG-CLRR messages to be improved based on business requirement.
acceptance_criteria: Process RFF+ABO Match 1154 - Sender Reference with Declaration>Customs>Reference Numbers>URN to identify the corresponding shipment Match 4000 - Sender Reference Version with Declaration>Mic>Customer Supplied References>CLREGSRV>Number to identify the corresponding MSG-CLR message If both data above are matched, process MSG-CLRR message. The improvement logic below is only applied when Declaration>Mic>Customer Supplied References>CLREGSRV>Comment is EXPORTER Process FTX+TIN If FTX+TIN is included in MSG-CLRR message Keep CLS in Declaration>Customer>Shipper>Reference Numbers Store the value of 4441 - Australian Business Number to the following SBSS mappings: Declaration>Customer>Shipper>Reference Numbers>TIN Full Turbo>Address>Shipper>Tax ID If data is already available in the following SBSS mappings, the existing data needs to be removed before FTX+TIN from the latest MSG-CLRR is processed. Declaration>Customer>Shipper>Reference Numbers>TIN Full Turbo>Address>Shipper>Tax ID Declaration>Customer>Shipper>Reference Numbers>OID Full Turbo>Address>Shipper>FZ / CW # Remove current logic of adding TIN to the following SBSS mappings: Shipment>Shipper>Profile>Comments>TIN Declaration>Misc>Customer Supplied References>TIN Upon FTX+TIN process, update Brokerage Status>OID to CMP. Process FTX+CCI If FTX+CCI is included in MSG-CLRR message Keep CLS in Declaration>Customer>Shipper>Reference Numbers Store the value of 4441 - Customs Client Id to the following SBSS mappings: Declaration>Customer>Shipper>Reference Numbers>OID Full Turbo>Address>Shipper>FZ / CW # If data is already available in the following SBSS mappings, the existing data needs to be removed before FTX+CCI from the latest MSG-CLRR is processed. Declaration>Customer>Shipper>Reference Numbers>TIN Full Turbo>Address>Shipper>Tax ID Declaration>Customer>Shipper>Reference Numbers>OID Full Turbo>Address>Shipper>FZ / CW # Remove current logic of adding OEM Client ID to Shipment>Shipper>Profile>Comments>OID Upon FTX+CCI process, update Brokerage Status>OID to CMP. Process CNT+55 Keep current logic that update Brokerage Status>OID to ERR when the value of 6066 - Total Comments > 0 Keep CLS in Declaration>Customer>Shipper>Reference Numbers when Total Comments > 0 Process FTX+AAO Keep current logic to store the value of 4440 - Message Text to Declaration Customer Supplied References Keep current logic to reflect error response in MSG-CLRR in Remark popup Update Party Address upon MSG-CLRR process Upon MSG-CLRR process on Exporter, match the following data with SBSS Admin>Customer>Party Address: Declaration>Customer>Shipper Name Declaration>Customer>hipper Address Line 1 Declaration>Customer>Shipper Address Line 2 Declaration>Customer>Shipper Postal Code Declaration>Customer>Shipper City Declaration>Customer>Shipper Region Declaration>Customer>Shipper Country If any Party is matched, record MSG-CLRR response on the Party: If FTX+TIN is processed, add Australian Business Number to Tax ID field of the matched Party, refer to sample below: If FTX+CCI is processed, add Customs Client Id to Reference Number OID of the matched Party, refer to sample below: Update Reference Number STA of the matched Party based on MSG-CLRR response process: If Total Comments > 0, update STA value to ERR. If FTX+TIN or FTX+CCI is processed, update STA value to CMP.

title: Improvement of CLNTDUP processing logic for export shipments
description: As a SBSS user, I want the processing logic for CLNTDUP messages to be improved based on business requirement.
acceptance_criteria: Process RFF+ABO Match 1154 - Sender Reference with Declaration>Customs>Reference Numbers>URN to identify the corresponding shipment Match 4000 - Sender Reference Version with Declaration>Mic>Customer Supplied References>CLREGSRV>Number to identify the corresponding MSG-CLR message If both data above are matched, process CLNTDUP message. The improvement logic below is only applied when 5152 - Role Name in Segment TAX+RN of CLNTDUP is EXPORTER Process DOC+TIN If DOC+TIN is included in CLNTDUP message Keep CLS in Declaration>Customer>Shipper>Reference Numbers Store the value of 1000 - Australian Business Number to the following SBSS mappings: Declaration>Customer>Shipper>Reference Numbers>TIN Full Turbo>Address>Shipper>Tax ID If data is already available in the following SBSS mappings, the existing data needs to be removed before DOC+TIN from the latest CLNTDUP is processed. Declaration>Customer>Shipper>Reference Numbers>TIN Full Turbo>Address>Shipper>Tax ID Declaration>Customer>Shipper>Reference Numbers>OID Full Turbo>Address>Shipper>FZ / CW # Remove current logic of adding TIN to the following SBSS mappings: Shipment>Shipper>Profile>Comments Declaration>Misc>Customer Supplied References Upon DOC+TIN process, update Brokerage Status>OID to CMP. Process DOC+CCI If DOC+CCI is included in CLNTDUP message Keep CLS in Declaration>Customer>Shipper>Reference Numbers Store the value of 1000- Customs Client Id to the following SBSS mappings: Declaration>Customer>Shipper>Reference Numbers>OID Full Turbo>Address>Shipper>FZ / CW # If data is already available in the following SBSS mappings, the existing data needs to be removed before DOC+CCI from the latest CLNTDUP is processed. Declaration>Customer>Shipper>Reference Numbers>TIN Full Turbo>Address>Shipper>Tax ID Declaration>Customer>Shipper>Reference Numbers>OID Full Turbo>Address>Shipper>FZ / CW # Remove current logic of adding OEM Client ID to the following SBSS mappings: Shipment>Shipper>Profile>Comments>OID Declaration>Misc>Customer Supplied References>OID Upon DOC+CCI process, update Brokerage Status>OID to CMP. Update Party Address upon CLNTDUP process Upon DOC+TIN or DOC+CCI process on Exporter, match the following data with SBSS Admin>Customer>Party Address: Declaration>Customer>Shipper Name Declaration>Customer>Shipper Address Line 1 Declaration>Customer>Shipper Address Line 2 Declaration>Customer>Shipper Postal Code Declaration>Customer>Shipper City Declaration>Customer>Shipper Region Declaration>Customer>Shipper Country If any Party is matched, record CLNTDUP response on the Party: If DOC+TIN is processed, add Australian Business Number to Tax ID field of the matched Party, refer to sample below: If DOC+ CCI is processed, add Customs Client Id to Reference Number OID of the matched Party, refer to sample below: Upon DOC+TIN or DOC+CCI recording, update Reference Number STA of the matched Party to CMP.

title: Update SBSS Statuses of Associated Export Shipments Upon MSG-CLR Messaging
description: As a SBSS user, I want the SBSS status relevant to MSG-CLR messaging to be updated on multiple shipments associated with the same customer name. Note: Sequentially, the functionality of this user story must take place following Feature 6220858: Project-A / Project-S - Import / Export - Customer Profile Look-up.
acceptance_criteria: Check SBSS Admin Customer Record On Shipment Load and On Change of Declaration > Customer > Shipper > Name: If the shipment is an Export Shipment: Validate whether a matching Shipper is available in the SBSS Admin > Party Address list, using: Declaration > Customer > Shipper > Name Declaration > ... > Address Line 1 Declaration > ... > Address Line 2 Declaration > ... > Postal Code Declaration > ... > City Declaration > ... > Region Declaration > ... > Country Update Customer OEM Client ID Status If a matching Shipper is identified: If Party Address > (Matched Shipper Record) > Reference Numbers > STA exists with a value of SNT in the Number field: Add Declaration > ... > Shipper > Reference Numbers > CLS with Declaration > ... > Shipper > Name in the Number field. Update the value of Shipment > Status > Brokerage Status > OID to SNT ⁽¹⁾. If Party Address > (Matched Shipper Record) > Tax ID is not blank: Add Declaration > ... > Shipper > Reference Numbers > TIN with the value of Party Address > (Matched Shipper Record) > Tax ID in the Number field. Update Full Turbo > Address > Shipper > Tax ID with the value of Party Address > (Matched Shipper Record) > Tax ID. Update the value of Shipment > Status > Brokerage Status > OID to CMP ⁽¹⁾. If Party Address > (Matched Shipper Record) > Reference Numbers > OID exists and the Number field is not blank: Add Declaration > ... > Shipper > Reference Numbers > OID with the value of Party Address > (Matched Shipper Record) > Reference Numbers > OID in the Number field. Update Full Turbo > Address > Shipper > FZ / CW # with the value of Party Address > (Matched Shipper Record) > Reference Numbers > OID. Update the value of Shipment > Status > Brokerage Status > OID to CMP ⁽¹⁾. ⁽¹⁾ Note: Export shipments will never have multiple declarations.

title: Update SBSS Statuses of Associated Import Shipments Upon MSG-CLR Messaging
description: As a SBSS user, I want the SBSS status relevant to MSG-CLR messaging to be updated on multiple shipments associated with the same customer name. Note: Sequentially, the functionality of this user story must take place following Feature 6220858: Project-A / Project-S - Import / Export - Customer Profile Look-up.
acceptance_criteria: Check SBSS Admin Customer Record On Shipment Load and On Change of Declaration > Customer > Importer > Name and On Change of Declaration > Customer > Shipper > Name: If the shipment is an Import Shipment: Validate whether a matching Importer is available in the SBSS Admin > Party Address list, using: Declaration > Customer > Importer > Name Declaration > ... > Address Line 1 Declaration > ... > Address Line 2 Declaration > ... > Postal Code Declaration > ... > City Declaration > ... > Region Declaration > ... > Country Validate whether a matching Shipper is available in the SBSS Admin > Party Address list, using: Declaration > Customer > Shipper > Name Declaration > ... > Address Line 1 Declaration > ... > Address Line 2 Declaration > ... > Postal Code Declaration > ... > City Declaration > ... > Region Declaration > ... > Country Update Customer OEM Client ID Status If a matching Importer is identified: If Party Address > (Matched Importer Record) > Reference Numbers > STA exists with a value of SNT in the Number field: Add Declaration > ... > Importer > Reference Numbers > CLS with Declaration > ... > Importer > Name in the Number field. Update the value of Shipment > Status > Brokerage Status > OID to SNT. If Party Address > (Matched Importer Record) > Tax ID is not blank: Add Declaration > ... > Importer > Reference Numbers > TIN with the value of Party Address > (Matched Importer Record) > Tax ID in the Number field. Update Full Turbo > Address > Importer > Tax ID with the value of Party Address > (Matched Importer Record) > Tax ID. If Party Address > (Matched Importer Record) > Reference Numbers > OID exists and the Number field is not blank: Add Declaration > ... > Importer > Reference Numbers > OID with the value of Party Address > (Matched Importer Record) > Reference Numbers > OID in the Number field. Update Full Turbo > Address > Importer > FZ / CW # with the value of Party Address > (Matched Importer Record) > Reference Numbers > OID. If a matching Shipper is identified: If Party Address > (Matched Shipper Record) > Reference Numbers > STA exists with a value of SNT in the Number field: Add Declaration > ... > Shipper > Reference Numbers > CLS with Declaration > ... > Shipper > Name in the Number field. Update the value of Shipment > Status > Brokerage Status > OID to SNT. If Party Address > (Matched Shipper Record) > Tax ID is not blank: Add Declaration > ... > Shipper > Reference Numbers > TIN with the value of Party Address > (Matched Shipper Record) > Tax ID in the Number field. Update Full Turbo > Address > Shipper > Tax ID with the value of Party Address > (Matched Shipper Record) > Tax ID. If Party Address > (Matched Shipper Record) > Reference Numbers > OID exists and the Number field is not blank: Add Declaration > ... > Shipper > Reference Numbers > OID with the value of Party Address > (Matched Shipper Record) > Reference Numbers > OID in the Number field. Update Full Turbo > Address > Shipper > FZ / CW # with the value of Party Address > (Matched Shipper Record) > Reference Numbers > OID. When any of the following conditions are met... Declaration > ... > Importer > Reference Numbers > TIN or Declaration > ... > Importer > Reference Numbers > OID exists. Declaration > ... > Shipper > Reference Numbers > TIN or Declaration > ... > Shipper > Reference Numbers > OID exists....update the value of Shipment > Status > Brokerage Status > OID to CMP.

title: Improvement of MSG-CLRR processing logic for import shipments
description: As a SBSS user, I want the processing logic for MSG-CLRR messages to be improved based on business requirement.
acceptance_criteria: Add new reference to SBSS Admin with script SBSS Admin table: Brokerage Status Value Data to be added: Status Type Status Value Description OID AWA Awaiting for second approval on MSG-CLR Process RFF+ABO Match 1154 - Sender Reference with Declaration>Customs>Reference Numbers>URN to identify the corresponding shipment Match 4000 - Sender Reference Version with Declaration>Mic>Customer Supplied References>CLREGSRV>Number to identify the corresponding MSG-CLR message If both data above are matched, process MSG-CLRR message. The improvement logic below is only applied when Declaration>Mic>Customer Supplied References>CLREGSRV>Comment is IMPORTER or SUPPLIER Process FTX+TIN on Importer If FTX+TIN is included in MSG-CLRR message Remove CLS from Declaration>Customer>Importer>Reference Numbers Store the value of 4441 - Australian Business Number to the following SBSS mappings: Declaration>Customer>Importer>Reference Numbers>TIN Full Turbo>Address>Importer>Tax ID If data is already available in the following SBSS mappings, the existing data needs to be removed before FTX+TIN from the latest MSG-CLRR is processed. Declaration>Customer>Importer>Reference Numbers>TIN Full Turbo>Address>Importer>Tax ID Declaration>Customer>Importer>Reference Numbers>OID Full Turbo>Address>Importer>FZ / CW # Remove current logic of adding TIN to the following SBSS mappings: Shipment>Importer>Profile>Comments>TIN Declaration>Misc>Customer Supplied References>TIN Process FTX+CCI on Importer If FTX+CCI is included in MSG-CLRR message Remove CLS from Declaration>Customer>Importer>Reference Numbers Store the value of 4441 - Customs Client Id to the following SBSS mappings: Declaration>Customer>Importer>Reference Numbers>OID Full Turbo>Address>Importer>FZ / CW # If data is already available in the following SBSS mappings, the existing data needs to be removed before FTX+CCI from the latest MSG-CLRR is processed. Declaration>Customer>Importer>Reference Numbers>TIN Full Turbo>Address>Importer>Tax ID Declaration>Customer>Importer>Reference Numbers>OID Full Turbo>Address>Importer>FZ / CW # Remove current logic of adding OEM Client ID to Shipment>Importer>Profile>Comments>OID Process CNT+55 on Importer Keep current logic that update Brokerage Status>OID to ERR when the value of 6066 - Total Comments > 0 Remove CLS from Declaration>Customer>Importer>Reference Numbers when Total Comments > 0 Process FTX+TIN on Supplier If FTX+TIN is included in MSG-CLRR message Remove CLS from Declaration>Customer>Shipper>Reference Numbers Store the value of 4441 - Australian Business Number to the following SBSS mappings: Declaration>Customer>Shipper>Reference Numbers>TIN Full Turbo>Address>Shipper>Tax ID If data is already available in the following SBSS mappings, the existing data needs to be removed before FTX+TIN from the latest MSG-CLRR is processed. Declaration>Customer>Shipper>Reference Numbers>TIN Full Turbo>Address>Shipper>Tax ID Declaration>Customer>Shipper>Reference Numbers>OID Full Turbo>Address>Shipper>FZ / CW # Remove current logic of adding TIN to the following SBSS mappings: Shipment>Shipper>Profile>Comments>TIN Declaration>Misc>Customer Supplied References>TIN Process FTX+CCI on Supplier If FTX+CCI is included in MSG-CLRR message Remove CLS from Declaration>Customer>Shipper>Reference Numbers Store the value of 4441 - Customs Client Id to the following SBSS mappings: Declaration>Customer>Shipper>Reference Numbers>OID Full Turbo>Address>Shipper>FZ / CW # If data is already available in the following SBSS mappings, the existing data needs to be removed before FTX+CCI from the latest MSG-CLRR is processed. Declaration>Customer>Shipper>Reference Numbers>TIN Full Turbo>Address>Shipper>Tax ID Declaration>Customer>Shipper>Reference Numbers>OID Full Turbo>Address>Shipper>FZ / CW # Remove current logic of adding OEM Client ID to Shipment>Shipper>Profile>Comments>OID Process CNT+55 on Supplier Keep current logic that update Brokerage Status>OID to ERR when the value of 6066 - Total Comments > 0 Remove CLS from Declaration>Customer>Shipper>Reference Numbers when Total Comments > 0 Process FTX+AAO Keep current logic to store the value of 4440 - Message Text to Declaration Customer Supplied References Keep current logic to reflect error response in MSG-CLRR in Remark popup Update OID status upon MSG-CLRR process When either condition below is met, change OID status o ERR: Total Comments > 0 in MSG-CLRR message on either Importer or Supplier When FTX+TIN or FTX+CCI is processed on Importer, check Declaration Shipper Reference Numbers. If none of CLS, TIN or OID is added, change OID status to CMP. If only CLS is added, change OID status to AWA. If TIN or OID is added, change OID status to CMP. When FTX+TIN or FTX+CCI is processed on Supplier, check Declaration Importer Reference Numbers. If none of CLS, TIN or OID is added, change OID status to CMP. If only CLS is added, change OID status to AWA. If TIN or OID is added, change OID status to CMP. Update Party Address upon MSG-CLRR process Upon MSG-CLRR process on Importer, match the following data with SBSS Admin>Customer>Party Address: Declaration>Customer>Importer Name Declaration>Customer>Importer Address Line 1 Declaration>Customer>Importer Address Line 2 Declaration>Customer>Importer Postal Code Declaration>Customer>Importer City Declaration>Customer>Importer Region Declaration>Customer>Importer Country Upon MSG-CLRR process on Supplier, match the following data with SBSS Admin>Customer>Party Address: Declaration>Customer>Shipper Name Declaration>Customer>hipper Address Line 1 Declaration>Customer>Shipper Address Line 2 Declaration>Customer>Shipper Postal Code Declaration>Customer>Shipper City Declaration>Customer>Shipper Region Declaration>Customer>Shipper Country If any Party is matched, record MSG-CLRR response on that Party: If FTX+TIN is processed, add Australian Business Number to Tax ID field of the matched Party, refer to sample below: If FTX+CCI is processed, add Customs Client Id to Reference Number OID of the matched Party, refer to sample below: Update Reference Number STA of the matched Party based on MSG-CLRR response process: If Total Comments > 0, update STA value to ERR. If FTX+TIN or FTX+CCI is processed, update STA value to CMP.

title: Improvement of CLNTDUP processing logic for import shipments
description: As a SBSS user, I want the processing logic for MSG-CLRR messages to be improved based on business requirement.
acceptance_criteria: Process RFF+ABO Match 1154 - Sender Reference with Declaration>Customs>Reference Numbers>URN to identify the corresponding shipment Match 4000 - Sender Reference Version with Declaration>Mic>Customer Supplied References>CLREGSRV>Number to identify the corresponding MSG-CLR message If both data above are matched, process CLNTDUP message. The improvement logic below is only applied when 5152 - Role Name in Segment TAX+RN of CLNTDUP is IMPORTER or SUPPLIER Process DOC+TIN on Importer If DOC+TIN is included in CLNTDUP message Remove CLS from Declaration>Customer>Importer>Reference Numbers Store the value of 1000 - Australian Business Number to the following SBSS mappings: Declaration>Customer>Importer>Reference Numbers>TIN Full Turbo>Address>Importer>Tax ID If data is already available in the following SBSS mappings, the existing data needs to be removed before DOC+TIN from the latest CLNTDUP is processed. Declaration>Customer>Importer>Reference Numbers>TIN Full Turbo>Address>Importer>Tax ID Declaration>Customer>Importer>Reference Numbers>OID Full Turbo>Address>Importer>FZ / CW # Remove current logic of adding TIN to the following SBSS mappings: Shipment>Importer>Profile>Comments Declaration>Misc>Customer Supplied References Process DOC+CCI on Importer If DOC+CCI is included in CLNTDUP message Remove CLS from Declaration>Customer>Importer>Reference Numbers Store the value of 1000- Customs Client Id to the following SBSS mappings: Declaration>Customer>Importer>Reference Numbers>OID Full Turbo>Address>Importer>FZ / CW # If data is already available in the following SBSS mappings, the existing data needs to be removed before DOC+CCI from the latest CLNTDUP is processed. Declaration>Customer>Importer>Reference Numbers>TIN Full Turbo>Address>Importer>Tax ID Declaration>Customer>Importer>Reference Numbers>OID Full Turbo>Address>Importer>FZ / CW # Remove current logic of adding OEM Client ID to Shipment>Importer>Profile>Comments>OID Process DOC+TIN on Supplier If DOC+TIN is included in CLNTDUP message Remove CLS from Declaration>Customer>Shipper>Reference Numbers Store the value of 1000 - Australian Business Number to the following SBSS mappings: Declaration>Customer>Shipper>Reference Numbers>TIN Full Turbo>Address>Shipper>Tax ID If data is already available in the following SBSS mappings, the existing data needs to be removed before DOC+TIN from the latest CLNTDUP is processed. Declaration>Customer>Shipper>Reference Numbers>TIN Full Turbo>Address>Shipper>Tax ID Declaration>Customer>Shipper>Reference Numbers>OID Full Turbo>Address>Shipper>FZ / CW # Remove current logic of adding TIN to the following SBSS mappings: Shipment>Shipper>Profile>Comments Declaration>Misc>Customer Supplied References Process DOC+CCI on Supplier If DOC+CCI is included in CLNTDUP message Remove CLS from Declaration>Customer>Shipper>Reference Numbers Store the value of 1000- Customs Client Id to the following SBSS mappings: Declaration>Customer>Shipper>Reference Numbers>OID Full Turbo>Address>Shipper>FZ / CW # If data is already available in the following SBSS mappings, the existing data needs to be removed before DOC+CCI from the latest CLNTDUP is processed. Declaration>Customer>Shipper>Reference Numbers>TIN Full Turbo>Address>Shipper>Tax ID Declaration>Customer>Shipper>Reference Numbers>OID Full Turbo>Address>Shipper>FZ / CW # Remove current logic of adding OEM Client ID to Shipment>Shipper>Profile>Comments>OID Update OID status upon CLNTDUP process OID status should be set to CMP when either condition below is met: When DOC+TIN or DOC+CCI is processed on Importer, check Declaration Shipper Reference Numbers. If none of CLS, TIN or OID is added, change OID status to CMP. If only CLS is added, change OID status to AWA. If TIN or OID is added, change OID status to CMP. When DOC+TIN or DOC+CCI is processed on Supplier, check Declaration Importer Reference Numbers. If none of CLS, TIN or OID is added, change OID status to CMP. If only CLS is added, change OID status to AWA. If TIN or OID is added, change OID status to CMP. Update Party Address upon CLNTDUP process Upon CLNTDUP process on Importer, match the following data with SBSS Admin>Customer>Party Address: Declaration>Customer>Importer Name Declaration>Customer>Importer Address Line 1 Declaration>Customer>Importer Address Line 2 Declaration>Customer>Importer Postal Code Declaration>Customer>Importer City Declaration>Customer>Importer Region Declaration>Customer>Importer Country Upon CLNTDUP process on Supplier, match the following data with SBSS Admin>Customer>Party Address: Declaration>Customer>Shipper Name Declaration>Customer>hipper Address Line 1 Declaration>Customer>Shipper Address Line 2 Declaration>Customer>Shipper Postal Code Declaration>Customer>Shipper City Declaration>Customer>Shipper Region Declaration>Customer>Shipper Country If any Party is matched based on Name and Account (or Address), record CLNTDUP response on that Party: If DOC+TIN is processed, add Australian Business Number to Tax ID field of the matched Party, refer to sample below: If DOC+CCI is processed, add Customs Client Id to Reference Number OID of the matched Party, refer to sample below: Upon DOC+TIN or DOC+CCI recording, update Reference Number STA of the matched Party to CMP.

title: Improvement of MSG-CLR submission logic for export shipments - Part 2
description: As a SBSS developer, I want duplicate MSG-CLR submission to be validated from Party Address instead of SBSS UI from technical perspective.
acceptance_criteria: Background The current user story is to improve the logic of the following one based on input from business and SA perspective. User Story 6997872: Improvement of MSG-CLR submission logic for export shipments Update MSG-CLR message validation logic on export shipments When Brokerage Status>OID is RFC and shipment is saved, check Declaration Comments. If Comment CCI or CCO is available, match the following data with SBSS Admin>Customer>Party Address: Declaration>Customer>Shipper Name Declaration>Customer>Shipper Address Line 1 Declaration>Customer>Shipper Address Line 2 Declaration>Customer>Shipper Postal Code Declaration>Customer>Shipper City Declaration>Customer>Shipper Region Declaration>Customer>Shipper Country If no Party is matched, start MSG-CLR data validation. If any Party is matched, check the following statuses of the Party: Reference Number STA Reference Number SHP Reference Number OID Tax ID in Party Address table If STA is not added, start MSG-CLR data validation. If STA is added with value SNT, raise a popup window with warning: "Client registration message has already been sent for Shipper XXX (1). Would you resubmit?" If STA is added with value ERR or SYN, check if the current Shipment ID is consistent with SHP value. If consistent, start MSG-CLR data validation. If inconsistent, raise a popup window with warning: "Client registration message for Shipper XXX (1) got error response on Shipment XXX (2), Would you submit from this shipment?" If STA is added with value CMP, check Tax ID and OID. If Tax ID has a value, raise a popup window with warning: "TIN has already been registered for Shipper XXX (1). Would you resubmit?" If OID has a value, raise a popup window with warning: "OEM Client ID has already been registered for Shipper XXX (1). Would you resubmit?" Note: XXX (1) needs to be replaced with Declaration Shipper Name. XXX (2) needs to be replaced with SHP value. ​If users click "Yes" button on the popup window and save shipment again, start MSG-CLR data validation. If users click "No" button on the popup window, MSG-CLR data validation will not be started. Upon data validation pass, send MSG-CLR message on Exporter registration to customs. Upon data validation fail, keep current logic to raise an error and block MSG-CLR submission. Update SBSS statuses post MSG-CLR submission Once MSG-CLR message is sent with mappings from Declaration Comment CCI or CCO, make changes below on SBSS UI: Add Declaration>Mic>Customer Supplied References>CLREGSRV with the following data from MSG-CLR: Add the value of 1056 - Sender Reference Version in BGM segment to CLREGSRV>Number Add the value of 6154 - Role Name (EXPORTER) in MEA segment to CLREGSRV>Comment If CLREGSRV is already added, replace the data in CLREGSRV>Number with the latest Sender Reference Version. Add CLS to Declaration>Customer>Shipper>Reference Numbers Upon MSG-CLR submission, update Brokerage Status>OID with logic below: If OID is SNT, skip OID status update. If OID status is other than SNT, then change OID to SNT. Update Party Address post MSG-CLR submission Once MSG-CLR message is sent with mappings from Declaration Comment CCI or CCO, update Party Address in Admin with logic below: If there is Party matched, update Reference Numbers of the Party. Reference Number STA: If STA is not available, add STA with value SNT. If STA is added with value SNT, skip STA update. If STA is added with value other than SNT, change STA value to SNT. Reference Number SHP: If SHP is not available, add SHP with Shipment ID sending MSG-CLR. If SHP is added with value consistent with Shipment ID sending MSG-CLR, skip SHP update. If SHP is added with value inconsistent with Shipment ID sending MSG-CLR, replace SHP value with Shipment ID sending MSG-CLR. If no Party is matched, record Declaration Shipper data to Party Address. All fields available in both Declaration Shipper and Party Address except for Tax ID and Reference Numbers should be recorded, refer to sample below: Upon new record added, add the following data to the Party: Add Reference Number STA with value SNT Add Reference Number SHP with Shipment ID sending MSG-CLR Remove CLS upon approval message process When any condition below is met, remove CLS from Declaration Shipper Reference Numbers: Brokerage Status OID is changed to CMP Brokerage Status OID is changed to ERR Brokerage Status OID is changed to SYN

title: Storing Importer / Shipper Party Address MSG-CLR Messaging Status in Declaration Customs Codes
description: As a SBSS user, I should have visibility on the status of MSG-CLR message responses received from Customs for Importer and Shipper OEM Client ID requests.
acceptance_criteria: The following Declaration > Customs > Customs Codes types with the below Values should be made available: Type Description TPS Importer OEM Client ID Status SCS Shipper OEM Client ID Status Type Value Description TPS CMP Registration Successful TPS ERR Data Error Received TPS RFC Ready for Customs TPS SNT Sent TPS SYN Syntax Error Received SCS CMP Registration Successful SCS ERR Data Error Received SCS RFC Ready for Customs SCS SNT Sent SCS SYN Syntax Error Received Further to the functionality outlined in User Story 7002505: Update SBSS Statuses of Associated Export Shipments Upon MSG-CLR Messaging: If a matching Shipper is identified: If Party Address > (Matched Shipper Record) > Reference Numbers > STA exists: Add / update Declaration > Customs > Customs Codes > SCS with a Value matching that in the Number field of Party Address > (Matched Shipper Record) > ... > STA. Record this as a new Brokerage Event. Further to the functionality outlined in User Story 7010439: Update SBSS Statuses of Associated Import Shipments Upon MSG-CLR Messaging: If a matching Importer is identified: If Party Address > (Matched Importer Record) > Reference Numbers > STA exists: Add / update Declaration > Customs > Customs Codes > TPS with a Value matching that in the Number field of Party Address > (Matched Importer Record) > ... > STA. Record this as a new Brokerage Event. If a matching Shipper is identified: If Party Address > (Matched Shipper Record) > Reference Numbers > STA exists: Add / update Declaration > Customs > Customs Codes > SCS with a Value matching that in the Number field of Party Address > (Matched Shipper Record) > ... > STA. Record this as a new Brokerage Event. When Consolidated Comments > Declaration Comments > CII or COI are added: Add / update Declaration > Customs > Customs Codes > TPS with a Value of RFC. Record this as a new Brokerage Event. When Consolidated Comments > Declaration Comments > CIS, COS, CCI or CCO are added: Add / update Declaration > Customs > Customs Codes > SCS with a Value of RFC. Record this as a new Brokerage Event.

title: Apply Declaration Customs Codes to reflect OEM Client ID status for export shipments
description: As a SBSS user, I want MSG-CLR relevant statuses to be reflected via Declaration Customs Codes to differentiate between Importer and Shipper.
acceptance_criteria: Notes The main purpose of the current story is to change MSG-CLR message relevant statuses from Shipment Brokerage Status OID to Declaration Customs Codes. MSG-CLR trigger points update needs to be implemented after corresponding change made by Savages. New Declaration Customs Codes TPS and SCS will be added by Achievers based on User Story 7036498 Apart from statuses change, all other requirements in the following stories and bug are still valid: User Story 7027017: Improvement of MSG-CLR submission logic for export shipments - Part 2 User Story 6999800: Improvement of MSG-CLRR processing logic for export shipments User Story 7002437: Improvement of CLNTDUP processing logic for export shipments Bug 6964044: Project-A : MSG-CLR PRD - Error Details not showing on Remarks nor Shipment CSR Update MSG-CLR trigger points for export shipments When Declaration Customs Code SCS is added with value RFC and shipment is saved, check Declaration Comments. If Comment CCI or CCO is available, submit MSG-CLR on Exporter registration upon validation pass. Post MSG-CLR submission updates on Exporter Once MSG-CLR is sent with mappings from Declaration Comment CCI or CCO: Update Declaration Customs Code SCS with logic below: If SCS value is SNT, skip SCS update. If SCS value is other than SNT, then update SCS value to SNT. Remove the logic of adding CLS to the following mappings: Shipment>Shipper>Profile>Comments Declaration>Customer>Shipper>Reference Numbers Update SCS status upon MSG-CLRR process Once MSG-CLRR is received and matched CLREGSRV>Comment is EXPORTER, update Declaration Customs Code SCS with logic below: When 6066 - Total Comments in segment CNT+55 is greater than 0, update SCS value to ERR. When segment FTX+TIN or FTX+CCI is processed, update SCS value to CMP. Update SCS status upon CLNTDUP process When the following conditions are met, update SCS value to CMP. 5152 - Role Name in Segment TAX+RN of CLNTDUP is EXPORTER Segment DOC+TIN or DOC+CCI is processed Update SCS status upon error CONTRL process When the following conditions are met, update SCS value to SYN. Element 0083 in segment UCI or UCM is 4 Data in Shipment>Customer Supplied References>ICRN>Comment is EXPORTER The detailed logic is clarified in Bug 6964044

title: Apply Declaration Customs Codes to reflect OEM Client ID status for import shipments
description: As a SBSS user, I want MSG-CLR relevant statuses to be reflected via Declaration Customs Codes to differentiate between Importer and Shipper.
acceptance_criteria: Notes The main purpose of the current story is to change MSG-CLR message relevant statuses from Shipment Brokerage Status OID to Declaration Customs Codes. MSG-CLR trigger points update needs to be implemented after corresponding change made by Savages. New Declaration Customs Codes TPS and SCS will be added by Achievers based on User Story 7036498 Apart from statuses change, all other requirements in the following stories and bug are still valid: User Story 6999692: Improvement of MSG-CLR submission logic for import shipments User Story 7016811: Improvement of MSG-CLRR processing logic for import shipments User Story 7016814: Improvement of CLNTDUP processing logic for import shipments Bug 6964044: Project-A : MSG-CLR PRD - Error Details not showing on Remarks nor Shipment CSR Update MSG-CLR trigger points for import shipments When Declaration Customs Code TPS is added with value RFC and shipment is saved, check Declaration Comments. If Comment CII or COI is available, submit MSG-CLR on Importer registration upon validation pass. When Declaration Customs Code SCS is added with value RFC and shipment is saved, check Declaration Comments. If Comment CIS or COS is available, submit MSG-CLR on Supplier registration upon validation pass. Post MSG-CLR submission update for import shipments Once MSG-CLR is sent with mappings from Declaration Comment CII or COI: Update Declaration Customs Code TPS with logic below: If TPS value is SNT, skip TPS update. If TPS value is other than SNT, then update TPS value to SNT. Remove the logic of adding CLS to the following mappings: Shipment>Importer>Profile>Comments Declaration>Customer>Importer>Reference Numbers Once MSG-CLR is sent with mappings from Declaration Comment CIS or COS: Update Declaration Customs Code SCS with logic below: If SCS value is SNT, skip SCS update. If SCS value is other than SNT, then update SCS value to SNT. Remove the logic of adding CLS to the following mappings: Shipment>Shipper>Profile>Comments Declaration>Customer>Shipper>Reference Numbers Update status upon MSG-CLRR process for import shipments Once MSG-CLRR is received and matched CLREGSRV>Comment is IMPORTER, update Declaration Customs Code TPS with logic below: When 6066 - Total Comments in segment CNT+55 is greater than 0, update TPS value to ERR. When segment FTX+TIN or FTX+CCI is processed, update TPS value to CMP. Once MSG-CLRR is received and matched CLREGSRV>Comment is SUPPLIER, update Declaration Customs Code SCS with logic below: When 6066 - Total Comments in segment CNT+55 is greater than 0, update SCS value to ERR. When segment FTX+TIN or FTX+CCI is processed, update SCS value to CMP. Update status upon CLNTDUP process for import shipments When both conditions below are met, update Declaration Customs Code TPS value to CMP. 5152 - Role Name in Segment TAX+RN of CLNTDUP is IMPORTER Segment DOC+TIN or DOC+CCI is processed When both conditions below are met, update Declaration Customs Code SCS value to CMP. 5152 - Role Name in Segment TAX+RN of CLNTDUP is SUPPLIER Segment DOC+TIN or DOC+CCI is processed Update status upon error CONTRL process for import shipments When the following conditions are met, update Declaration Customs Code TPS value to SYN. Element 0083 in segment UCI or UCM is 4 Data in Shipment>Customer Supplied References>ICRN>Comment is IMPORTER When the following conditions are met, update Declaration Customs Code SCS value to SYN. Element 0083 in segment UCI or UCM is 4 Data in Shipment>Customer Supplied References>ICRN>Comment is SUPPLIER The detailed logic is clarified in Bug 6964044

title: OEM Client ID | Remove existing logic of declaration comments
description: As a RATER I want to set newly introduced brokerage status (TPS & SCS) as RFC when OEM Client ID form is submitted so that I can differentiate whether I submitted the OEM Client ID form for shipper or importer or supplier.
acceptance_criteria: As is: If OEM Client ID form is submitted for below scenario, Brokerage status OID will be set to RFC (OID = RFC) Declaration comments Brokerage status = RFC If CII added, OID will be set If CIS added OID will be set If COI added OID will be set If COS added OID will be set If CCI added OID will be set If CCO added OID will be set Remove the above logic since achievers is going to introduce below (To be) logic with new statuses. -------------------------------------------------------------------------------------------------------------------------------------------------------- NOT OUR SCOPE To be: 2 new Declaration custom code has been introduced TPS - Importer Customs Status SCS - Shipper Customs Status Above 2 statuses to be applied for below scenarios TPS - Importer Customs Status Declaration comments Brokerage status = RFC If CII added, set TPS If COI added, set TPS SCS - Shipper Customs Status Declaration comments Brokerage status = RFC If CIS added, set SCS If COS added, set SCS If CCI added, set SCS If CCO added, set SCS

title: Sync up TIN and OEM Client ID in multiple SBSS UI fields
description: Scope : As a SBSS user, I want TIN and OEM Client ID # to be synced up through multiple SBSS UI mapping fields. Deals with 2 discrete parties - Importer and Shipper. Deals with 2 discrete parameters - TIN/Tax ID and OID - FZ/CW# numbers Covers both New value entry & ON CHANGE. Deals with 2 discrete screens - Full Turbo and Declaration Customer screens Background : Usually , TIN/Tax ID is populated from Customer profile onto the Shipment Declaration. In case, this is missing or empty, the SBSS user enters these values Manually on the shipment declaration. This story aims to sync up the manual additions or modifications on 2 parameters : TIN - TaxID and OID -FZ/CW# between the Turbo screen and the Declaration screens by popping up User concurrence to automatically sync up values depending upon which party's references are being added or modified between shipper and importer.
acceptance_criteria: As a SBSS user, I can see that : Whenever I manually add TaxID or OID numbers or modify existing numbers to missing party references, I get to see a Popup on tab out as follows: POPUP CREATION : • Raise a popup window with content: "Would you like to apply the data to XXXX and YYY ?" Here XXXX refers to dynamically populating the complementary screen where the update is required based on which screen the user is adding or modifying the data: YYY in the popup window should be dynamically replaced based on customer type (Shipper or Importer) and current field (TIN<->TaxID) or (OID <->FZ# /OID). Refer to references below: Scenario 1: If a value is added to (XXXX)Turbo>Address>Importer(YYY)>Tax ID, then the popup content should be: "Would you like to apply the data to (XXXX)Declaration Importer(YYY) and Customer Profile? " Scenario 2: If the value is modified in (XXXX)Declaration> Shipper(YYY)> Reference Numbers> OID, then the popup content should be: "Would you like to apply the data to (XXXX)Full Turbo and Customer Profile?"  If users click "No" button on the popup, no action required.  If users click "Yes" button on the popup, ensure the entered data is synced up to all SBSS fields listed below. For inside data sync up, ensure the data is reflected to all fields related to the same customer type (Importer or Shipper). Sync up TIN and OEM Client ID on multiple SBSS fields: • When the value is added or modified in any field below on SBSS UI:  On Full Turbo:  Address > Importer > Tax ID should be synchronized with: Declaration>Customer > Importer > Tax ID  Declaration> Customer > Importer > Reference Numbers > TIN -  Address > Importer > FZ / CW # should be synchronized with: Customer > Importer > Reference Numbers > OID - Already working  Address > Shipper > Tax ID should be synchronized with: Declaration>Customer > Shipper > Tax ID - - Already working  Declaration>Customer > Shipper > Reference Numbers > TIN  Address > Shipper > FZ / CW # should be synchronized with: Declaration>Customer > Shipper > Reference Numbers > OID - Already working  On Declaration:  Customer > Importer > Tax ID should be synchronized with: Address > Importer > Tax ID - Already working  Customer > Importer > Reference Numbers > TIN  Customer > Importer > Reference Numbers > TIN should be synchronized with: Address > Importer > Tax ID  Customer > Importer > Tax ID  Customer > Importer > Reference Numbers > OID should be synchronized with: Address > Importer > FZ / CW # - Already working  Customer > Shipper > Tax ID should be synchronized with: Address > Shipper > Tax ID - Already working  Customer > Shipper > Reference Numbers > TIN  Customer > Shipper > Reference Numbers > TIN should be synchronized with: Address > Shipper > Tax ID  Customer > Shipper > Tax ID  Customer > Shipper > Reference Numbers > OID should be synchronize with: Address > Shipper > FZ / CW # - - Already working

title: Creation of NTSA Job to Load / Process Shipments with Party Address MSG-CLRR Messages (Export Enhancement)
description: As a SBSS user, I should have MSG-CLRR messages processed such that response information (related to OEM Client IDs) is automatically updated to affected shipments.
acceptance_criteria: Prerequisite Events ⁽¹⁾ Upon receiving a MSG-CLRR message: The contents of the response will be processed to the Party Address. A stored procedure will be used to identify the shipments incorporating this party address. For each shipment found, a record will be inserted in the IBLOCTX table with the Shipment ID serving as the Identifier. ⁽¹⁾ To be fulfilled by Team-B. Achievers Requirements Design and implement an NTSA job which retrieves the aforementioned list of shipments, loads each of them one by one, and executes the functionality previously outlined in User Story 7002505: Update SBSS Statuses of Associated Export Shipments Upon MSG-CLR Messaging and User Story 7036498: Storing Importer / Shipper Party Address MSG-CLR Messaging Status in Declaration Customs Codes.Additionally, for each shipment: Following execution, record a new Brokerage Event indicating such. Save and exist the shipment. Remove the existing "On Shipment Load" triggers outlined in the above user stories. The functionality should only be triggered when the NTSA job loads a shipment - not the user.

title: Creation of NTSA Job to Load / Process Shipments with Party Address MSG-CLRR Messages (Import Enhancement)
description: As a SBSS user, I should have MSG-CLRR messages processed such that response information (related to OEM Client IDs) is automatically updated to affected shipments.
acceptance_criteria: Prerequisite Events ⁽¹⁾ Upon receiving a MSG-CLRR message: The contents of the response will be processed to the Party Address. A stored procedure will be used to identify the shipments incorporating this party address. For each shipment found, a record will be inserted in the IBLOCTX table with the Shipment ID serving as the Identifier. ⁽¹⁾ To be fulfilled by Team-B. Achievers Requirements Design and implement an NTSA job which retrieves the aforementioned list of shipments, loads each of them one by one, and executes the functionality previously outlined in User Story 7010439: Update SBSS Statuses of Associated Import Shipments Upon MSG-CLR Messaging and User Story 7036498: Storing Importer / Shipper Party Address MSG-CLR Messaging Status in Declaration Customs Codes.Additionally, for each shipment: Following execution, record a new Brokerage Event indicating such. Save and exist the shipment. Remove the existing "On Shipment Load" triggers outlined in the above user stories. The functionality should only be triggered when the NTSA job loads a shipment - not the user.

title: QA Story: Testing on updated OEM Client ID messaging flow
description: As a SBSS user, I want the E2E flow for OEM Client ID outbound message submission and inbound message process to be tested based on customs regulations and latest business requirements.
acceptance_criteria: Update Party Address Reference Numbers Add new references in SBSS Admin with script SBSS Admin table: Shipment Reference Number Type Data to be added: Code Description Parent Type Code Quick Searchable CN Contact Name PT Remove existing references in SBSS Admin script SBSS Admin table: Shipment Reference Number Type Data to be removed: Code Description Parent Type Code Quick Searchable CLS MSG-CLR message sent AD ROL The Role name from MSG-CLR message AD UEN Unique Entity Number PT TIN Australia Business Number PT CLS MSG-CLR message sent PT ROL The Role name from MSG-CLR message PT Record Contact Name to Party Address upon MSG-CLR submission Once MSG-CLR message is sent with mappings from Declaration Comment CCI, CCO, CIS or COS, match Declaration Shipper with Admin Party Address. If no Party is matched, record Declaration Shipper data to Party Address covering all fields in both Declaration Shipper and Party Address. Upon new entry recorded in Admin, add Reference Number CN with Declaration Shipper Contact Name as the value. Once MSG-CLR message is sent with mappings from Declaration Comment CII, COI, match Declaration Importer with Admin Party Address. If no Party is matched, record Declaration Importer data to Party Address covering all fields in both Declaration Importer and Party Address. Upon new entry recorded in Admin, add Reference Number CN with Declaration Importer Contact Name as the value. Apply the logic for MSG-CLRR on registered TIN When a MSG-CLRR is received, keep the current logic to match corresponding Declaration and Sender Reference Version based on RFF+ABO. Once the Declaration and Sender Reference Version are matched, check if all conditions below are met in MSG-CLRR: If no FTX+TIN or FTX+CCI is included If the value of CNT+55 is greater than 0 If FTX+AAO+++TIN ALREADY REGISTERED is included If no, keep the current logic to process the response. If yes, process the response with logic below: If the MSG-CLRR is on Exporter or Supplier, check the following data: Declaration>Customer>Shipper>Tax ID Declaration>Customer>Shipper>Reference Numbers>TIN If Tax ID is available and Reference Number TIN is not added: Add Reference Number TIN with Tax ID as the value Change Declaration Customs Code SCS to CMP Don't reflect the value of FTX+AAO segments to Customer Supplied References and Remark popup If Tax ID is available and Reference Number TIN is added with a value: Change Declaration Customs Code SCS to CMP Don't reflect the value of FTX+AAO segments to Customer Supplied References and Remark popup If Tax ID is not available, keep the current logic to process the response. If the MSG-CLRR is on Importer, check the following data: Declaration>Customer>Importer>Tax ID Declaration>Customer>Importer>Reference Numbers>TIN If Tax ID is available and Reference Number TIN is not added: Add Reference Number TIN with Tax ID as the value Change Declaration Customs Code TPS to CMP Don't reflect the value of FTX+AAO segments to Customer Supplied References and Remark popup If Tax ID is available and Reference Number TIN is added with a value: Change Declaration Customs Code TPS to CMP Don't reflect the value of FTX+AAO segments to Customer Supplied References and Remark popup If Tax ID is not available, keep the current logic to process the response.

title: FF6977011 - Sync up TIN and OEM Client ID into Admin->Party Address conditionally
description: Scope : As a SBSS user, I want TIN and OEM Client ID # to be synced up through multiple SBSS UI mapping fields. Deals with 2 discrete parties - Importer and Shipper. Deals with 2 discrete parameters - TIN/Tax ID and OID - FZ/CW# numbers Covers both New value entry & ON CHANGE. Deals with Sync on Admin>Party Address screen. Background : Usually , TIN/Tax ID is populated from Customer profile onto the Shipment Declaration. In case, this is missing or empty, the SBSS user enters these values Manually on the shipment declaration. This story deals with syncing TIN/TaxID and / or OID/FZ numbers onto Admin>Party addresses> under same fields whenever the Party name and addresses match on the admin side.
acceptance_criteria: As a SBSS user, I can see that : Whenever I manually add TaxID or OID numbers or modify existing numbers to missing party references, I get to see a Popup on tab out as follows: POPUP CREATION: • Raise a popup window with content: "Would you like to apply the data to Admin>(YYY) Party Address?" YYY in the popup window should be dynamically replaced based on customer type (Shipper or Importer) and current field (TIN<->TaxID) or (OID <->FZ# /OID). Refer to references below: Scenario 1: If a value is added to Turbo>Address>Importer (YYY)>Tax ID, then the popup content should be: "Would you like to apply the data to Importer (YYY) Admin Party Address?" Scenario 2: If the value is modified in Shipper (YYY)> Reference Numbers> OID, then the popup content should be: "Would you like to apply the data to Admin Shipper (YYY) Party Address?"  If users click "No" button on the popup, no action required.  If users click "Yes" button on the popup, ensure the entered data is synced up to all SBSS fields listed below.  For data sync up : Shipment -> SBSS Admin>Customer>Party Address Ensure Declaration Customer is matched with Party Address with the following items: o Importer:  Declaration>Customer>Importer Name  Declaration>Customer>Importer Address Line 1  Declaration>Customer>Importer Address Line 2  Declaration>Customer>Importer Postal Code  Declaration>Customer>Importer City  Declaration>Customer>Importer Region  Declaration>Customer>Importer Country o Shipper  Declaration>Customer>Shipper Name  Declaration>Customer>Shipper Address Line 1  Declaration>Customer>Shipper Address Line 2  Declaration>Customer>Shipper Postal Code  Declaration>Customer>Shipper City  Declaration>Customer>Shipper Region  Declaration>Customer>Shipper Country o Once the Party address is matched  Reflect Tax ID or TIN on Shipment to Admin> Party Address>Tax ID on Shipment Store (Trigger)  Reflect FZ / CW # or OID on Shipment to Admin> Party Address>Reference Numbers on Shipment Store (Trigger)