Project-A - Import / Export - TIN and OEM Client ID (Customs Client ID)

This feature is to allow SBSS to comply with the AU Customs requirement of Customs Client IDs for shippers, importers and exporters (both individuals and organizations) which enables entry submission. OEM Client ID efforts are under Feature 5321174: Client registration integration with Customs for OEM Client ID (incl message visibility) Are trigger points required? On download, system to check for profile match including OEM Client ID, and either auto submits a OEM Client ID application or warns the user that a profile is not registered. User can manually submit an application via Custom Action. Enhancements to the custom action screen to accommodate new requirements for the OEM Client ID submission. * * Requirement added subsequent to Planning; to be investigated in Task 5952679: OEM Client ID screen to be modified under what conditions?.

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: Project-A - Import / Export - TIN and OEM Client ID (Customs Client ID) — Feature Brief
content: ## 1. Feature Title and Business Need

**Feature Title**: Customs Client Registration and Identification (OEM Client ID/TIN) for Customs Border Force Compliance

**Business Need**: 
Customs Border Force (CBF) requires all entities involved in import/export declarations—shippers, importers, and exporters—to be registered with customs authorities and assigned either an Australian Business Number (TIN) or a Customs Client Identifier (OEM Client ID). Without these identifiers, declarations cannot be submitted to the Trade Processing System (TPS), resulting in cargo holds, clearance delays, and potential non-compliance penalties.

Carrier Co Australia's SBSS platform must ensure that all parties in a declaration have valid TIN or OEM Client ID values before submission. The system must automatically identify missing registrations, request new identifiers from customs when required, process registration responses, and maintain accurate identifier records on customer profiles.

---

## 2. Business Objectives

1. **Regulatory Compliance**: Ensure 100% of import/export declarations submitted to TPS include valid TIN or OEM Client ID for all required parties (shippers, importers, exporters)

2. **Operational Efficiency**: Minimize broker manual intervention by automatically detecting missing identifiers and triggering registration requests where appropriate

3. **Customer Experience**: Reduce clearance delays caused by missing or incorrect party identifiers by proactively managing registrations

4. **Data Quality**: Maintain accurate, up-to-date TIN and OEM Client ID records on customer profiles to prevent duplicate registration requests and ensure reusability across shipments

5. **Audit Readiness**: Provide full visibility and traceability of registration requests, responses, and identifier assignments through system events and status tracking

---

## 3. Scope

### In Scope

**Party Types Requiring Identifiers**:
- Importers (entities receiving goods into Australia)
- Exporters (entities sending goods from Australia)
- Shippers (overseas suppliers/consignors)

**Entity Types**:
- Organizations (companies, partnerships, trusts)
- Individuals (private persons importing/exporting goods)

**Identifier Types**:
- TIN (Australian Business Number): 11-digit numeric identifier for registered Australian businesses
- OEM Client ID (Customs Client Identifier): 11-character alphanumeric code (e.g., CET7934637L) issued by CBF for parties without TIN
- CAC (Client Account Code): Optional 3-digit extension to TIN for multi-location businesses

**Processes**:
- Automatic detection of missing identifiers on shipment download
- Conditional triggering of registration requests based on configurable business rules
- Manual registration request submission via broker interface
- Processing of customs registration responses (approval, duplicate, rejection)
- Synchronization of identifiers to customer profiles and declarations
- Validation of identifier formats and address data

**Integration Points**:
- TPS message exchange (MSG-CLR outbound, MSG-CLRR/CLNTDUP inbound)
- Customer profile comment system (TIN and OID storage)
- Shipment brokerage status tracking (OID status lifecycle)
- Declaration party data (importer, exporter, shipper addresses)

### Out of Scope

- Validation of TIN/OEM Client ID values against external TIN lookup services (beyond format validation)
- Retrospective application of identifiers to historical declarations
- Automatic cancellation or withdrawal of registration requests
- Integration with party master data management systems outside SBSS
- Registration request approval workflows (customs authority handles all approvals)

---

## 4. Stakeholders and Actors

**Primary Users**:
- **Customs Brokers (BRK)**: Submit registration requests manually, resolve missing identifier exceptions, validate party data before declaration submission
- **Compilers (COM)**: Review and prepare shipments for brokerage, identify missing identifier issues early
- **Administrators (ADM)**: Configure auto-registration rules, manage lookup values, monitor registration success rates

**Secondary Users**:
- **Operations Supervisors**: Monitor exception queues for registration rejections, assign rework to brokers
- **Compliance Officers**: Audit identifier accuracy, ensure regulatory adherence

**External Systems**:
- **Customs Border Force TPS**: Processes registration requests, issues OEM Client ID values, validates party uniqueness
- **Customer Profile System**: Stores TIN/OEM Client ID as customer comments, provides profile matching logic

**Business Owners**:
- Carrier Co Australia Brokerage Operations Management
- Compliance and Regulatory Affairs Team

---

## 5. Dependencies

**Technical Dependencies**:
- Existing TPS messaging infrastructure (EDIFACT gateway, message handler framework)
- Customer profile comment system with types TIN and OID
- Shipment brokerage status engine (must support new OID status type)
- Declaration party address fields (must support all required identifier and address attributes)
- Local lookup configuration system (for auto-registration rules)

**Data Dependencies**:
- Master Town reference table (Australian postal codes, localities, states) for address validation
- ICAO country codes reference (for individual travel document country selection)
- Search word reference system (for customer name matching logic)

**Process Dependencies**:
- Shipment download process must complete before identifier checks occur
- Declaration initialization must occur before identifier validation
- Customer profile matching logic must execute before auto-registration triggers

**External Dependencies**:
- CBF TPS availability and response time (registration responses may take minutes to hours)
- Accuracy of shipper/importer/consignee data provided by customers
- Validity of addresses and party details for successful registration

---

## 6. Success Criteria

**Functional Success**:
- System correctly identifies shipments with missing TIN/OEM Client ID for importers, exporters, and shippers
- Auto-registration requests are triggered only once per customer profile to prevent duplicate submissions
- Manual registration interface supports both organization and individual registrations with all required data fields
- Registration responses are processed and mapped to correct customer profiles without manual intervention
- Identifiers propagate correctly from customer profiles to declaration party fields
- Address validation prevents registration rejections due to invalid Australian postal codes or locality mismatches

**Operational Success**:
- Reduction in declaration submission rejections due to missing party identifiers by >90%
- Broker exception handling time for identifier issues reduced by >50%
- Auto-registration success rate >80% (rejections <20%)
- No duplicate OEM Client ID requests for the same customer profile within processing window

**Data Quality Success**:
- TIN and OEM Client ID values stored on customer profiles match CBF-issued values with 100% accuracy
- Identifier format validation prevents storage of malformed values
- All shipments linked to registered customer profiles have identifiers available for subsequent declarations

**Compliance Success**:
- 100% of submitted declarations include valid TIN or OEM Client ID for all required parties
- System events provide full audit trail of registration requests, responses, and identifier assignments
- Configuration controls allow operations to disable auto-registration if required by business policy

---

## 7. Assumptions and Risks

### Assumptions

1. **Data Accuracy**: Customer-provided shipper, importer, and exporter details (names, addresses) are accurate enough for CBF to validate and issue identifiers
2. **Response Timeliness**: CBF will respond to MSG-CLR requests within a reasonable timeframe (typically same business day) to avoid prolonged shipment holds
3. **Profile Matching**: Existing customer profile matching logic correctly identifies the same party across multiple shipments
4. **Address Standards**: Australian postal code and locality reference data is complete and maintained current
5. **Unique Party Identification**: CBF's duplicate detection logic is robust enough to prevent multiple OEM Client IDs for the same entity

### Risks

| Risk | Impact | Likelihood | Mitigation |
|------|--------|------------|------------|
| High volume of auto-registration requests overwhelms TPS | High | Medium | Implement throttling via configurable lookup; allow disable of auto-registration; batch processing |
| Registration rejections due to incomplete/incorrect addresses | Medium | High | Implement robust address validation pre-submission; provide broker UI for correction; populate from validated customer profiles |
| Duplicate OEM Client ID requests for same customer during concurrent downloads | Medium | Medium | Use pending status on first request; check processing table before triggering; time-based deduplication window |
| CBF response delays cause shipment clearance SLA breaches | High | Low | Provide manual override for time-sensitive shipments; escalation queue for delayed responses; retry logic |
| OEM Client ID format changes by CBF break validation logic | Low | Low | Externalize format rules to configuration; monitor CBF technical bulletins |
| Identifiers assigned to wrong customer profile | High | Low | Validate response correlation via transaction table; log all assignments with source reference; manual correction workflow |

**Critical Risk**:
If auto-registration is enabled without proper deduplication controls, the same customer could receive multiple OEM Client ID requests during bulk shipment downloads, potentially causing CBF to flag Carrier Co for system abuse. **Mitigation**: Transaction table check before triggering, pending status assignment, and configurable auto-registration disable switch.

---

## 8. High-Level Process Flow

1. **Shipment Download**: Manifest received from carrier, shipment created in SBSS, customer profile matching occurs
2. **Identifier Check**: System evaluates whether importer/exporter/shipper has TIN or OEM Client ID on profile
3. **Auto-Registration Decision**: Based on lookup configuration, shipment status, and profile state, determine if automatic request should trigger
4. **Registration Request Preparation**: Gather party data (name, address, role, entity type), populate registration message
5. **Submission to Customs**: Send MSG-CLR message to TPS, set shipment status to track request
6. **Response Processing**: Receive MSG-CLRR (new OEM Client ID issued) or CLNTDUP (duplicate party detected, existing identifier returned)
7. **Identifier Assignment**: Update customer profile comments with TIN or OEM Client ID from response
8. **Declaration Propagation**: Identifiers automatically available for all future declarations using that customer profile
9. **Exception Handling**: Rejections logged, broker notified, manual correction workflow initiated

---

## 9. Business Context

**Regulatory Background**:
Customs Border Force introduced mandatory party registration requirements to improve supply chain security, prevent trade-based money laundering, and enable entity-level risk assessment. All parties in import/export transactions must have a unique identifier traceable to a legal entity or individual.

**Industry Practice**:
Brokers typically manage party registrations reactively—receiving rejection errors during declaration submission and then manually registering parties. This approach causes delays and operational inefficiency. Proactive, automated registration is a competitive differentiator.

**Carrier Co Strategic Alignment**:
Automation of regulatory compliance tasks aligns with Carrier Co's digital transformation strategy, reducing manual touchpoints and improving brokerage service quality. Accurate party identifier management supports future capabilities such as consolidated billing across customer accounts and enhanced customer self-service portals.

---

title: Project-A - Import / Export - TIN and OEM Client ID (Customs Client ID) — Technical Specification
content: **Document Version**: 1.0  
**Effective Date**: [Current Date]  
**System**: SBSS (Brokerage Operations Support System)  
**Jurisdiction**: Australia (AU)  
**Customs Authority**: Customs Border Force (CBF)  
**Integration Platform**: Trade Processing System (TPS)

---

## 1. Message Format and Segment Reference

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

**Message Type**: MSG-CLR  
**Direction**: SBSS → TPS  
**Purpose**: Request issuance of Customs Client Identifier (OEM Client ID) for a party not registered with CBF  
**Trigger Conditions**: Missing TIN/OEM Client ID on customer profile, shipment meets auto-registration criteria, or broker manual submission

#### Segment Structure

| Segment | Element | Data Type | Max Length | Mandatory | Conditional | Description | Example |
|---------|---------|-----------|------------|-----------|-------------|-------------|---------|
| UNH | Message Reference | AN | 14 | M | - | Unique message identifier | CLREG000001 |
| BGM | Document/Message Code | N | 3 | M | - | Message type code 351 = Client Registration | 351 |
| BGM | Document Number | AN | 35 | M | - | SBSS-generated reference (CRN) | CRN123456789 |
| DTM | Date/Time/Period Qualifier | N | 3 | M | - | 137 = Message preparation date/time | 137 |
| DTM | Date/Time/Period Value | N | 12 | M | - | CCYYMMDDHHMI format | 202403181430 |
| NAD | Party Qualifier | AN | 3 | M | - | Role type: IM=Importer, EX=Exporter, SU=Supplier | IM |
| NAD | Party Identification | AN | 35 | C | If TIN known | TIN value (11 or 14 digits) | 12345678901 or 12345678901234 |
| NAD | Name and Address | AN | 512 | M | - | Composite: Name, Address Line 1, Address Line 2, City, Postal Code, State, Country | See below |
| FTX | Text Subject Qualifier | AN | 3 | C | Organization only | TIN = Australian Business Number indicator | TIN |
| FTX | Text Literal | AN | 11-14 | C | Organization only | TIN value with optional CAC | 12345678901 or 12345678901234 |
| FTX | Text Subject Qualifier | AN | 3 | C | If CAC provided | CAC = Client Account Code indicator | CAC |
| FTX | Text Literal | AN | 3 | C | If CAC provided | 3-digit CAC value | 001 |
| FTX | Text Subject Qualifier | AN | 3 | C | If CAC provided | CAT = CAC Address Type | CAT |
| FTX | Text Literal | AN | 2 | C | If CAC provided | BA = Business Address, PA = Postal Address | BA |
| FTX | Text Subject Qualifier | AN | 3 | C | Individual only | DOB = Date of Birth | DOB |
| FTX | Text Literal | N | 8 | C | Individual only | DDMMYYYY format | 15031985 |
| FTX | Text Subject Qualifier | AN | 3 | C | Individual only | SEX = Gender | SEX |
| FTX | Text Literal | AN | 1 | C | Individual only | M = Male, F = Female, X = Unspecified | F |
| DOC | Document Type | AN | 3 | C | Individual with travel docs | Passport, Driver License, etc. | PAS |
| DOC | Document Number | AN | 35 | C | Individual with travel docs | Document number | N1234567 |
| DOC | Issuing Country | AN | 3 | C | Individual with travel docs | 3-char ICAO country code | AUS |

**Name and Address Composite Format** (NAD segment):
- **Organization**: `[Company Name]+[Address Line 1]+[Address Line 2]+[City]+[Postal Code]+[State]+[Country Code]`
- **Individual**: `[Title] [First Name] [Second Name] [Family Name] [Suffix]+[Address Line 1]+[Address Line 2]+[City]+[Postal Code]+[State]+[Country Code]`

**Conditional Logic**:
- If NAD Party Qualifier = IM (Importer) and TIN provided → FTX segments for TIN, CAC (optional), CAT (if CAC exists) must follow
- If NAD Party Qualifier = IM and no TIN → Name must be individual format if entity type = Individual
- If entity type = Individual → FTX segments for DOB (optional), SEX (mandatory) must follow
- If entity type = Individual AND "Evidence of Identity Confirmed" checkbox selected → DOC segment(s) for travel documents must follow
- If Address Country Code = AU → Postal Code and State must be valid per Master Town reference table

---

### 1.2 Inbound Message: MSG-CLRR (Client Registration Response - New OEM Client ID Issued)

**Message Type**: MSG-CLRR  
**Direction**: TPS → SBSS  
**Purpose**: Provide newly issued OEM Client ID for registered party  
**Trigger**: CBF successfully processed MSG-CLR request and party was not previously registered

#### Segment Structure

| Segment | Element | Data Type | Max Length | Mandatory | Conditional | Description | Example |
|---------|---------|-----------|------------|-----------|-------------|-------------|---------|
| UNH | Message Reference | AN | 14 | M | - | Unique response identifier | CLREGR000001 |
| BGM | Document/Message Code | N | 3 | M | - | Message type code 355 = Registration Response | 355 |
| BGM | Response Code | N | 3 | M | - | Status: 1 = Accepted, 4 = Rejected | 1 |
| RFF | Reference Qualifier | AN | 3 | M | - | ABO = Original request reference | ABO |
| RFF | Reference Number | AN | 35 | M | - | Original MSG-CLR message reference/CRN | CRN123456789 |
| DTM | Date/Time/Period Qualifier | N | 3 | M | - | 137 = Response date/time | 137 |
| DTM | Date/Time/Period Value | N | 12 | M | - | CCYYMMDDHHMI format | 202403181445 |
| FTX | Text Subject Qualifier | AN | 3 | C | If TIN submitted | TIN = Australian Business Number | TIN |
| FTX | Text Literal | AN | 11-14 | C | If TIN submitted | Echoed TIN value | 12345678901 |
| FTX | Text Subject Qualifier | AN | 3 | M | Always | CCI = Customs Client Identifier | CCI |
| FTX | Text Literal | AN | 11 | M | Always | Newly issued OEM Client ID | CET7934637L |
| FTX | Text Subject Qualifier | AN | 3 | C | If rejected | AAO = Error/Rejection reason | AAO |
| FTX | Text Literal | AN | 512 | C | If rejected | Rejection message | THIS TRANSACTION WAS REJECTED |

**Processing Rules**:
- If BGM Response Code = 1 → Extract FTX+CCI segment value and store as customer profile comment type OID
- If BGM Response Code = 4 → Extract FTX+AAO segment value, log rejection reason, set OID status to ERR
- Correlation: Match RFF+ABO reference number to original MSG-CLR message to identify correct shipment/customer

---

### 1.3 Inbound Message: CLNTDUP (Client Duplicate Response - Existing Identifier Returned)

**Message Type**: CLNTDUP  
**Direction**: TPS → SBSS  
**Purpose**: Indicate party already registered with CBF, return existing TIN or OEM Client ID  
**Trigger**: CBF matched submitted party details to existing registration record

#### Segment Structure

| Segment | Element | Data Type | Max Length | Mandatory | Conditional | Description | Example |
|---------|---------|-----------|------------|-----------|-------------|-------------|---------|
| UNH | Message Reference | AN | 14 | M | - | Unique response identifier | CLNTDUP000001 |
| BGM | Document/Message Code | N | 3 | M | - | Message type code 356 = Duplicate Notification | 356 |
| RFF | Reference Qualifier | AN | 3 | M | - | ABO = Original request reference | ABO |
| RFF | Reference Number | AN | 35 | M | - | Original MSG-CLR message reference/CRN | CRN123456789 |
| DTM | Date/Time/Period Qualifier | N | 3 | M | - | 137 = Response date/time | 137 |
| DTM | Date/Time/Period Value | N | 12 | M | - | CCYYMMDDHHMI format | 202403181450 |
| FTX | Text Subject Qualifier | AN | 3 | M | Always | AAO = Advisory message | AAO |
| FTX | Text Literal | AN | 512 | M | Always | Duplicate detection message | DUPLICATE PARTY DETECTED |
| DOC | Document Type Qualifier | AN | 3 | M | Always | TIN or CCI | TIN or CCI |
| DOC | Document Number | AN | 11-14 | M | Always | Existing TIN (11-14 digits) or OEM Client ID (11 chars) | 23869413369 or CGJ4763467L |

**Processing Rules**:
- Parse DOC segment to determine identifier type: DOC+TIN → store in customer comment type TIN; DOC+CCI → store in customer comment type OID
- CRITICAL: FTX+AAO segment may also contain rejection indicator "THIS TRANSACTION WAS REJECTED" — check for this string before processing DOC segment
- If rejection string present in FTX+AAO → Set OID status to ERR, do NOT update customer profile
- If no rejection string → Extract DOC segment value, update customer profile comment, set OID status to REC (Received)
- Correlation: Match RFF+ABO reference number to original MSG-CLR message

---

## 2. Data Mapping Rules

### 2.1 Customer Profile to MSG-CLR Message Mapping

**Source Entity**: Customer Profile (Importer, Exporter, Shipper address)  
**Target Entity**: MSG-CLR NAD segment and associated FTX segments

#### Organization Mapping

| SBSS Source Field | MSG-CLR Segment | MSG-CLR Element | Transformation Rule | Validation Rule | Conditional |
|-------------------|---------------|---------------|---------------------|-----------------|-------------|
| Customer.Comments[TIN].Comment | FTX | Text Literal (TIN) | Strip spaces, format as 11 or 14 digits | Length = 11 (TIN only) or 14 (TIN+CAC), numeric only | If TIN exists |
| Customer.Comments[TIN].Comment (positions 12-14) | FTX | Text Literal (CAC) | Extract rightmost 3 digits if length = 14 | Numeric, 3 digits | If TIN length = 14 |
| Declaration.Comment[CCI].CustomField[CACAddressType] | FTX | Text Literal (CAT) | Pass through value | Must = 'BA' or 'PA' | If CAC provided |
| Customer.Name | NAD | Name Component | Pass through, truncate to 512 chars | Not null, min 1 char | Always |
| Customer.Address.Addr1 | NAD | Address Line 1 Component | Pass through, truncate to 512 chars composite limit | Not null, min 1 char | Always |
| Customer.Address.Addr2 | NAD | Address Line 2 Component | Pass through, may be empty | - | Optional |
| Customer.Address.City | NAD | City Component | Pass through | Not null if Country = AU | Always |
| Customer.Address.PostalCode | NAD | Postal Code Component | Pass through | Not null, valid per Master Town if Country = AU | Always |
| Customer.Address.State | NAD | State Component | Pass through | Not null if Country = AU, validate per Master Town | Always |
| Customer.Address.Country | NAD | Country Code Component | 2-char country code | ISO 3166-1 alpha-2 | Always |

#### Individual Mapping

| SBSS Source Field | MSG-CLR Segment | MSG-CLR Element | Transformation Rule | Validation Rule | Conditional |
|-------------------|---------------|---------------|---------------------|-----------------|-------------|
| Declaration.Comment[CCI].CustomField[Title] | NAD | Name - Title | Pass through | Free text, optional | Optional |
| Declaration.Comment[CCI].CustomField[FirstName] | NAD | Name - First | Pass through | Free text, optional | Optional |
| Declaration.Comment[CCI].CustomField[SecondName] | NAD | Name - Second | Pass through | Free text, optional | Optional |
| Declaration.Comment[CCI].CustomField[FamilyName] | NAD | Name - Family | Pass through | Not null, min 1 char | Mandatory |
| Declaration.Comment[CCI].CustomField[Suffix] | NAD | Name - Suffix | Pass through | Free text, optional | Optional |
| Declaration.Comment[CCI].CustomField[DateOfBirth] | FTX | Text Literal (DOB) | Format as DDMMYYYY | Valid date, 8 digits | Optional |
| Declaration.Comment[CCI].CustomField[Sex] | FTX | Text Literal (SEX) | Pass through | Must = 'M', 'F', or 'X' | Mandatory |
| Declaration.Comment[CCI].CustomField[TravelDocuments][].Type | DOC | Document Type | Pass through | Valid document type code | If EvidenceConfirmed = true |
| Declaration.Comment[CCI].CustomField[TravelDocuments][].Number | DOC | Document Number | Pass through | Not null if document type provided | If EvidenceConfirmed = true |
| Declaration.Comment[CCI].CustomField[TravelDocuments][].Country | DOC | Issuing Country | 3-char ICAO country code lookup | Valid ICAO country code from reference ICC | If EvidenceConfirmed = true |
| Customer.Address.Addr1 | NAD | Address Line 1 Component | Pass through | Not null, min 1 char | Mandatory |
| Customer.Address.Addr2 | NAD | Address Line 2 Component | Pass through | - | Optional |
| Customer.Address.PostalCode | NAD | Postal Code Component | Pass through | Not null, valid per Master Town if Country = AU | Mandatory |
| Customer.Address.City | NAD | City Component | Auto-populated from Master Town if Postal Code provided and Country = AU | Not null | Mandatory |
| Customer.Address.State | NAD | State Component | Auto-populated from Master Town if Postal Code provided and Country = AU | Not null | Mandatory |
| Customer.Address.Country | NAD | Country Code Component | Auto-populated from Master Town if Postal Code provided; else 2-char from customer record | ISO 3166-1 alpha-2 | Mandatory |

**Role Type Determination**:
- If Declaration.Comment[CCI].RoleType = "Exporter" → NAD Party Qualifier = EX, source data from Declaration.Customer.Shipper
- If Declaration.Comment[CCI].RoleType = "Importer" → NAD Party Qualifier = IM, source data from Declaration.Customer.Importer
- If Declaration.Comment[CCI].RoleType = "Supplier" → NAD Party Qualifier = SU, source data from Declaration.Customer.Shipper

---

### 2.2 MSG-CLRR/CLNTDUP Response to Customer Profile Mapping

**Source Entity**: MSG-CLRR or CLNTDUP inbound message  
**Target Entity**: Customer Profile Comments

| Response Segment | Response Element | SBSS Target Field | Transformation Rule | Update Condition |
|------------------|------------------|-------------------|---------------------|------------------|
| FTX+CCI | Text Literal | Customer.Comments[OID].Comment | Extract OEM Client ID value (11 chars, format: 3 alpha + 7 numeric + 1 alpha uppercase) | MSG-CLRR message received, BGM response code = 1 |
| DOC+TIN | Document Number | Customer.Comments[TIN].Comment | Extract TIN value (11 or 14 digits), store without spaces | CLNTDUP message received, DOC type = TIN, FTX+AAO does NOT contain "REJECTED" |
| DOC+CCI | Document Number | Customer.Comments[OID].Comment | Extract OEM Client ID value (11 chars) | CLNTDUP message received, DOC type = CCI, FTX+AAO does NOT contain "REJECTED" |

**Correlation and Multi-Shipment Update**:
- Use transaction table (IBLOCTX) to correlate response message to original MSG-CLR request via RFF+ABO reference number
- Extract Customer OID from original MSG-CLR transaction record
- Load customer profile via Customer OID
- Update customer comment using `Customer.SetCommentText(commentType, commentValue)` method
- Save customer profile
- Query all shipments linked to same Customer OID within time window (configurable, default 10 minutes) using stored procedure `GetShipmentsForCustomerUpdate`
- Update OID brokerage status on all matched shipments to REC (Received) if success, ERR (Error) if rejected

---

### 2.3 Customer Profile to Declaration Party Address Mapping

**Purpose**: Propagate TIN/OEM Client ID from customer profile comments to declaration party fields for TPS submission  
**Trigger**: Declaration initialization, party address population

| Customer Profile Source | Declaration Target Field | Mapping Rule | Validation |
|-------------------------|--------------------------|--------------|------------|
| Customer.Comments[TIN].Comment | Declaration.ImporterAddress.TaxID | Copy TIN value (11-14 digits) | If importer role and TIN exists on profile |
| Customer.Comments[OID].Comment | Declaration.ImporterAddress.CustomField[OEM Client ID] | Copy OEM Client ID value (11 chars) | If importer role and OID exists on profile, store in FZ/CW field equivalent |
| Customer.Comments[TIN].Comment | Declaration.ShipperAddress.TaxID | Copy TIN value | If shipper role and shipper country = AU and TIN exists |
| Customer.Comments[OID].Comment | Declaration.ShipperAddress.CustomField[OEM Client ID] | Copy OEM Client ID value | If shipper role and OID exists, always required for shippers regardless of TIN |
| Customer.Comments[TIN].Comment | Declaration.ExporterAddress.TaxID | Copy TIN value | If exporter role and TIN exists |
| Customer.Comments[OID].Comment | Declaration.ExporterAddress.CustomField[OEM Client ID] | Copy OEM Client ID value | If exporter role and no TIN, use OID |

**Fallback Logic**:
- If declaration importer has no TIN/OID comment on matched profile → Lookup shipper profile comments, apply if found
- If declaration shipper has no TIN/OID comment on matched profile → Lookup importer profile comments, apply if found
- Event logging: Capture source of identifier in shipment event (e.g., "OID ABC1234567E applied from Account No - 8AU123456")

---

### 2.4 Declaration Comment CCI Storage Format

**Purpose**: Store MSG-CLR request details in declaration comment for audit and retry scenarios  
**Comment Type**: CCI (Customs Client Identifier)  
**Storage Format**: Structured key-value pairs delimited by pipe `|` and equals `=`

**Data Fields**:

| Field Name | Data Type | Max Length | Source | Example |
|-----------|-----------|------------|--------|---------|
| RoleType | String | 10 | User selection from dropdown | Importer, Exporter, Supplier |
| EntityType | String | 15 | User selection from radio button | Organization, Individual |
| TIN | String | 14 | User input or auto-populated | 12345678901 or 12345678901234 |
| CAC | String | 3 | User input | 001 |
| CACAddressType | String | 2 | User selection from dropdown | BA, PA |
| Title | String | 20 | User input | Mr, Ms, Dr |
| FirstName | String | 50 | User input | John |
| SecondName | String | 50 | User input | Paul |
| FamilyName | String | 100 | User input or auto-populated | Smith |
| Suffix | String | 10 | User input | Jr, III |
| DateOfBirth | String | 8 | User input DDMMYYYY | 15031985 |
| Sex | String | 1 | User selection | M, F, X |
| AddressLine1 | String | 512 | Auto-populated from customer address | 123 Main St |
| AddressLine2 | String | 512 | Auto-populated from customer address | Unit 5 |
| PostalCode | String | 10 | Auto-populated or user input | 2000 |
| Locality | String | 100 | Auto-populated from Master Town | Sydney |
| StateCode | String | 3 | Auto-populated from Master Town | NSW |
| CountryCode | String | 2 | Auto-populated or user input | AU |
| EvidenceConfirmed | Boolean | 1 | User checkbox | Y, N |
| TravelDocuments | Array | - | User input table rows | See below |

**TravelDocuments Array Format** (if EvidenceConfirmed = Y):

Each document stored as: `Type:Number:Country;Type:Number:Country;...`

Example: `PAS:N1234567:AUS;DL:VIC123456:AUS`

**Storage Example**:

```
RoleType=Importer|EntityType=Individual|FamilyName=Smith|FirstName=John|DateOfBirth=15031985|Sex=M|AddressLine1=123 Main St|AddressLine2=Unit 5|PostalCode=2000|Locality=Sydney|StateCode=NSW|CountryCode=AU|EvidenceConfirmed=Y|TravelDocuments=PAS:N1234567:AUS
```

**Update Rule**: If comment CCI exists and user re-submits via custom action, overwrite existing comment with new values. If comment does not exist, create new comment record.

---

## 3. Business Rules and Validation

### 3.1 Identifier Format Validation Rules

**TIN Validation**:
- **Interactive Mode** (broker manual entry):
  - Format: Numeric only, no spaces, hyphens, or special characters
  - Length: Exactly 11 digits (TIN alone) OR exactly 14 digits (TIN + CAC)
  - If length = 14: First 11 digits = TIN, last 3 digits = CAC
  - Validation trigger: Customer profile comment update, custom action form submission
  - Error message: "TIN must be 11 or 14 numeric digits. Format: 12345678901 or 12345678901234"
- **Non-Interactive Mode** (response processing):
  - No validation performed, accept value as provided by customs response
  - Rationale: Customs authority is authoritative source, always correct

**OEM Client ID Validation**:
- **Interactive Mode**:
  - Format: Alphanumeric, uppercase letters only
  - Length: Exactly 11 characters
  - Pattern: 3 alpha + 7 numeric + 1 alpha (e.g., CET7934637L)
  - Validation trigger: Customer profile comment update, custom action form submission
  - Error message: "OEM Client ID must be 11 characters in format ABC1234567D (3 letters, 7 numbers, 1 letter, all uppercase)"
- **Non-Interactive Mode**:
  - No validation performed, accept value as provided by customs response

**Implementation Note**: Use `CommonEngine.IsInteractive()` method to determine validation mode. If false, skip all format validations in `ValidateCustomerCommentBasedOnFormatAndLength.cs` class.

---

### 3.2 Address Validation Rules

**Australian Address Validation** (Country Code = AU):

Applies to: All MSG-CLR requests where NAD segment Country Code = AU  
Reference Table: Master Town (`AutoRefTypes.TYPE_MasterTown`)

**Validation Scenarios**:

1. **Postal Code Provided, City Empty**:
   - Lookup Master Town by Postal Code
   - Auto-populate City (Locality) from Master Town.City
   - Auto-populate State from Master Town.State
   - If Postal Code not found in Master Town → Validation error: "Invalid Australian postal code. Please verify address."

2. **City Provided, Postal Code Empty**:
   - Lookup Master Town by City (case-insensitive match)
   - Populate dropdown of valid Postal Codes for that City
   - Auto-populate State from Master Town.State (if single match)
   - If multiple Postal Codes match City → User must select from dropdown
   - If City not found in Master Town → Validation error: "City not found in Australian postal code reference. Please verify address."

3. **Both Postal Code and City Provided**:
   - **Postal Code takes priority**
   - Lookup Master Town by Postal Code
   - If returned City does not match user-entered City → Overwrite City with Master Town.City, display warning: "City corrected based on postal code. Original: [user entry], Corrected: [Master Town value]"
   - Auto-populate State from Master Town.State

4. **Postal Code and City Both Empty**:
   - Validation error: "Postal Code or City is required for Australian addresses."

**Overseas Address Validation** (Country Code ≠ AU):

- No postal code validation performed
- No city/state auto-population
- Accept all fields as provided by user
- Country Code must exist in reference table (ISO 3166-1 alpha-2)

**Validation Trigger Points**:
- Custom action form field change (OnChange event for Postal Code or City fields)
- Custom action form submission (onClick Send button, pre-validation before MSG-CLR generation)
- Declaration party address update (when customer profile address copied to declaration)

---

### 3.3 Auto-Registration Trigger Rules

**Configuration-Driven Logic**:

Auto-registration controlled by two local lookup types:

**Lookup Type 1: AUTOOID** (Enable/Disable Auto-Submission)

| Lookup Key | Valid Values | Description |
|-----------|--------------|-------------|
| AUTOOID LPM-I | Y, N | Auto-submit OEM Client ID for imports if Y, manual only if N |
| AUTOOID LPM-X | Y, N | Auto-submit OEM Client ID for exports if Y, manual only if N |

**Lookup Type 2: CIDCTRAT** (Clearance Type and Rating Status Filter)

| Lookup Key | Format | Description | Example |
|-----------|--------|-------------|---------|
| CIDCTRAT LPM-I | \|RAT=status1,status2\|CT=type1,type2\| | Only auto-submit if import shipment RAT and CT match these values | \|RAT=CMP,INT,HLD\|CT=FML,INF\| |
| CIDCTRAT LPM-X | \|RAT=status1,status2\|CT=type1,type2\| | Only auto-submit if export shipment RAT and CT match these values | \|RAT=CMP,INT,HLD\|CT=FML,INF\| |

**Auto-Registration Decision Logic** (executed on shipment download and save):

```
IF (Shipment.ProcessingMode = Import AND LocalLookup[AUTOOID LPM-I] = N) 
   OR (Shipment.ProcessingMode = Export AND LocalLookup[AUTOOID LPM-X] = N) 
THEN
   EXIT (auto-registration disabled)

IF LocalLookup[CIDCTRAT] exists for processing mode THEN
   Parse CT and RAT values from lookup
   IF Shipment.ClearanceType NOT IN parsed_CT_values 
      OR Shipment.RatingStatus NOT IN parsed_RAT_values THEN
      EXIT (shipment does not meet CT/RAT criteria)

IF Shipment.ProcessingMode = Import THEN
   target_customer = Declaration.ImporterAddress.Customer
ELSE IF Shipment.ProcessingMode = Export THEN
   target_customer = Declaration.ShipperAddress.Customer

IF target_customer.Comments[TIN] exists OR target_customer.Comments[OID] exists THEN
   EXIT (customer already has identifier)

IF target_customer.Name NOT MATCH SearchWord[Type=OID] THEN
   EXIT (customer name not in approved search word list)

IF ValidationRecord exists in IBLOCTX 
   WHERE CustomerOID = target_customer.OID 
   AND ProcessedStatusCode IN (5, 6) THEN
   EXIT (OEM Client ID request already submitted for this customer, pending or processed)

SET Shipment.BrokerageStatus[OID] = RFC (Ready for Customs)
```

**Deduplication Time Window**:
- Default: 10 minutes (configurable via orchestration property `TimeRange`)
- Purpose: Prevent duplicate OEM Client ID requests when multiple shipments for same customer download within short time
- Mechanism: Query `IBLOCTX` transaction table for CustomerOID with ProcessedStatusCode 5 or 6 (pending/sent) within last [TimeRange] minutes
- If record found → Skip auto-registration (assume prior request in flight)

---

### 3.4 Search Word Matching Rule

**Purpose**: Restrict auto-registration to pre-approved customer names to prevent spurious requests for invalid/incomplete profiles

**Reference Table**: Search Word Reference (`Type = OID`, Description = "Customs Client Identifier Search Words")

**Matching Logic**:
- Extract customer name from target party (importer for imports, shipper for exports)
- Normalize: Convert to uppercase, trim whitespace
- Query Search Word table for Type = OID
- Check if normalized customer name contains ANY search word as substring (case-insensitive)
- If match found → Proceed with auto-registration checks
- If no match → Skip auto-registration, do not set OID status

**Configuration Example**:

| Type | Search Word | Description |
|------|-------------|-------------|
| OID | Carrier Co | Carrier Co entity variants |
| OID | FEDEX | FedEx entity variants |
| OID | DHL | DHL entity variants |
| OID | TOLL | Toll Group entities |

**Admin Management**: Administrators add/remove search words via SBSS Admin > Reference Tables > Search Word Reference. Changes take effect immediately (no system restart required).

---

### 3.5 Manual Registration Validation Rules

**Custom Action Form Validation** (triggered on Send button click):

**Common Validations** (Organization and Individual):
- RoleType: Must select one of: Exporter, Importer, Supplier (mandatory)
- AddressLine1: Not null, min 1 character (mandatory)
- PostalCode: Not null (mandatory); if Country = AU, must exist in Master Town
- Locality: Not null (mandatory); if Country = AU and auto-populated from Master Town, read-only
- CountryCode: Not null, must exist in ISO country reference (mandatory)

**Organization-Specific Validations**:
- If TIN provided:
  - Format: 11 or 14 numeric digits
  - If length = 14 → CAC (last 3 digits) automatically extracted and populated
  - If CAC provided (either extracted or manually entered) → CACAddressType is mandatory (must = BA or PA)
- If TIN not provided:
  - OrganizationName: Not null, min 1 character (mandatory)
  - Address validations apply as per common rules

**Individual-Specific Validations**:
- FamilyName: Not null, min 1 character (mandatory)
- Sex: Must select M, F, or X (mandatory)
- DateOfBirth: Optional; if provided, must be valid date in DDMMYYYY format
- If "Evidence of Identity Confirmed" checkbox selected:
  - TravelDocuments table: At least one document row required
  - Each document row: DocumentType (not null), DocumentNumber (not null), CountryCode (not null, must exist in ICAO country reference ICC)

**Validation Failure Handling**:
- Display error message in red text below invalid field
- Prevent form submission until all validation errors resolved
- Focus cursor on first invalid field

---

## 4. Status Model

### 4.1 Shipment Brokerage Status: OID

**Status Type Code**: OID  
**Description**: Customs Client Identifier Submission Reference  
**Purpose**: Track lifecycle of OEM Client ID registration request from trigger to completion

**Status Values**:

| Status Value | Description | Meaning | Set By | Trigger Condition |
|--------------|-------------|---------|--------|-------------------|
| REQ | Submission Required | Shipment meets auto-registration criteria, OEM Client ID request needed but not yet generated | Auto-registration rule step | Auto-registration conditions met, customer lacks TIN/OID |
| NRQ | Submission Not Required | Customer already has TIN or OID, or auto-registration disabled/filtered | Auto-registration rule step | Customer profile has TIN/OID comment, or lookup AUTOOID = N, or CIDCTRAT filter excludes shipment |
| RFC | Ready for Customs | OEM Client ID request validated and queued for transmission on next shipment save | Auto-registration rule step OR manual custom action | OID status set to RFC, awaiting shipment save trigger |
| SNT | Submission Sent | MSG-CLR message transmitted to TPS | Message generation step | MSG-CLR message successfully built and sent via gateway |
| ERR | Error | MSG-CLR request rejected by customs, or MSG-CLRR/CLNTDUP response contains rejection indicator | Response processing step | MSG-CLRR with BGM code 4, or CLNTDUP with FTX+AAO containing "REJECTED" |
| REC | Received | OEM Client ID or TIN successfully received from customs and applied to customer profile | Response processing step | MSG-CLRR or CLNTDUP processed, identifier updated on customer comments |
| CMP | Complete | All shipments for customer updated with identifier, no further action required | Response processing step | After REC, all related shipments within time window updated |

**Status Transition Rules**:

```
[Initial] → REQ (if auto-registration criteria met)
[Initial] → NRQ (if customer has identifier or auto-registration disabled)

REQ → RFC (after validation passes)
RFC → SNT (on shipment save, MSG-CLR message sent)

SNT → REC (on MSG-CLRR/CLNTDUP success response)
SNT → ERR (on MSG-CLRR/CLNTDUP rejection response)

REC → CMP (after multi-shipment update completes)

ERR → RFC (broker corrects data, re-submits via custom action)
```

**Priority Rule**: If multiple status updates occur within same transaction, later status overwrites earlier (no status rollback logic).

---

### 4.2 CUS Status Interaction

**Context**: OID status is independent of CUS (Customs submission) status but impacts declaration submission eligibility

**Blocking Rule**:
- If declaration party (importer, exporter, shipper) requires TIN/OEM Client ID (per party role rules) AND customer profile lacks both TIN and OID comments → Block CUS status progression to RFC
- Display broker alert: "Declaration cannot be submitted. [Party Role] requires TIN or OEM Client ID. Status: OID = [current status]. Action: Wait for OEM Client ID response or manually register via Custom Action."

**Non-Blocking Scenarios**:
- OID status = NRQ (customer has identifier, or not required for this clearance type)
- OID status = REC or CMP (identifier received and applied)
- OID status = SNT (request in flight, broker may choose to wait or proceed if urgent — warning displayed but submission not blocked)

**Override**: Administrator role (ADM) can force declaration submission despite missing OID by setting custom bypass flag (for exceptional circumstances such as time-sensitive clearances where customs pre-approval obtained via alternate channel).

---

## 5. Error and Exception Handling

### 5.1 MSG-CLR Submission Errors

**Error Scenario**: MSG-CLR message construction fails validation before transmission

**Possible Causes**:
- Mandatory segment missing (e.g., NAD segment empty due to no customer address)
- Invalid data format (e.g., malformed postal code, non-numeric TIN)
- Message exceeds size limit (rare, but possible with very long address fields)

**Handling**:
- Set OID status = ERR
- Log error in shipment events: "OEM Client ID request validation failed: [specific error message]"
- Create exception record in broker worklist with priority = High
- Display broker alert on shipment open: "OEM Client ID submission error. Review customer address and identifier details in Custom Action."
- Do NOT transmit message to TPS
- Broker action required: Correct invalid data via custom action, re-submit

---

### 5.2 MSG-CLRR/CLNTDUP Rejection Responses

**Error Scenario 1**: MSG-CLRR received with BGM Response Code = 4 (Rejected)

**Handling**:
- Parse FTX+AAO segment for rejection reason (e.g., "Invalid postal code", "Incomplete address", "Party name mismatch")
- Set OID status = ERR
- Log event: "OEM Client ID registration rejected by customs. Reason: [FTX+AAO text]"
- Update shipment comment with rejection reason for broker visibility
- Do NOT update customer profile (no identifier received)
- Broker action required: Review rejection reason, correct data via custom action (e.g., fix address, provide missing TIN), re-submit MSG-CLR

**Error Scenario 2**: CLNTDUP received with FTX+AAO containing "THIS TRANSACTION WAS REJECTED"

**Handling**:
- Parse FTX+AAO segment, detect rejection keyword
- Set OID status = ERR
- Log event: "OEM Client ID duplicate check rejected by customs. Reason: [FTX+AAO text]"
- Do NOT process DOC segment (even if present, identifier is invalid)
- Do NOT update customer profile
- Broker action required: Investigate why customs rejected duplicate check (common reasons: TIN provided does not match party name in CBF records, address mismatch). Correct and re-submit.

---

### 5.3 Response Correlation Failures

**Error Scenario**: MSG-CLRR or CLNTDUP received, but RFF+ABO reference number does not match any MSG-CLR transaction in IBLOCTX table

**Possible Causes**:
- Message delayed beyond transaction retention window
- Reference number corrupted in transmission
- SBSS internal transaction record lost (database issue)

**Handling**:
- Log error in system integration log: "OEM Client ID response received with unmatched reference: [RFF+ABO value]. Message type: [MSG-CLRR/CLNTDUP]. Unable to correlate to shipment."
- Do NOT update any customer profile or shipment status (cannot determine which customer this response applies to)
- Archive orphaned response message in error queue for manual review
- Administrator action required: Manually identify customer from NAD segment in original MSG-CLR (if available in audit logs), apply identifier via manual customer profile update, document resolution in incident log

---

### 5.4 Duplicate OEM Client ID Requests (Race Condition)

**Error Scenario**: Multiple shipments for same customer download concurrently, auto-registration triggers MSG-CLR for each before first response received

**Prevention Mechanisms**:
1. **Transaction Table Check**: Before setting OID status = RFC, query IBLOCTX for existing CustomerOID records with ProcessedStatusCode 5/6 within time window. If found, skip auto-registration.
2. **Pending Status Assignment**: On first MSG-CLR transmission, immediately insert transaction record with ProcessedStatusCode = 5 (Pending), preventing concurrent checks from detecting "no prior request".
3. **Time Window Configuration**: Default 10 minutes provides buffer for typical TPS response time. Increase to 30 minutes if high rejection rate observed due to duplicates.

**Residual Risk Handling** (if duplicates still occur):
- TPS will respond to first MSG-CLR with MSG-CLRR (new OEM Client ID issued)
- TPS will respond to subsequent CLREGs with CLNTDUP (duplicate detected, return same OEM Client ID issued to first request)
- Both responses processed correctly by SBSS (MSG-CLRR updates profile, CLNTDUP recognizes duplicate and also updates profile with same OEM Client ID)
- Result: No harm, customer profile correctly updated, minor inefficiency (multiple messages for same outcome)
- Monitoring: Track CLNTDUP rate; if >5% of total responses, investigate time window tuning or deduplication logic enhancement

---

### 5.5 Missing Customer Profile (Casual Account Scenario)

**Error Scenario**: Shipment downloads with casual account (account number format: starts with digit followed by "AU", e.g., 7AU123456), no matched customer profile in SBSS

**Background**: Casual accounts are temporary/one-time customers, not pre-registered in SBSS customer database

**Handling**:
- On shipment download, attempt customer profile match by account number
- If no match found AND account format = [digit]AU[number]:
  - Extract importer name and address from declaration
  - Perform secondary lookup: Search existing customer profiles for exact match on Name + Address Line 1 + Postal Code
  - If secondary match found:
    - Check matched profile for TIN or OID comment
    - If identifier exists: Apply to declaration importer, log event: "OID [value] applied from Account No - [matched account number]"
    - If identifier missing: Proceed with auto-registration logic (subject to AUTOOID and CIDCTRAT rules)
  - If no secondary match found:
    - Display remark popup to broker on shipment open: "OEM Client ID is required. Customer profile not found for casual account [account number]."
    - Broker action required: Manually submit MSG-CLR via custom action, or create customer profile and link to shipment

**Profile Creation Workflow** (if broker opts to create profile):
- Broker uses SBSS Admin > Customer Management > Add New Customer
- Enter customer details from declaration (name, address, contact)
- Save customer profile (system assigns SBSS Customer OID)
- Return to shipment, update declaration importer customer reference to new profile OID
- Auto-registration logic re-evaluates on next shipment save, triggers MSG-CLR if conditions met

---

## 6. Integration Points

### 6.1 TPS Gateway Interface

**Protocol**: UN/EDIFACT over secure VPN tunnel  
**Message Exchange Pattern**: Asynchronous request-response  
**Endpoint Configuration**: Australia TPS production gateway (URL and credentials managed in SBSS system configuration, not hardcoded)

**Outbound Message Flow**:
1. SBSS generates MSG-CLR message in EDIFACT format
2. Message serialized to flat file or XML wrapper (per gateway adapter configuration)
3. Transmitted via HTTPS POST to TPS gateway endpoint
4. Gateway returns synchronous HTTP 200 acknowledgment (message received, queued for processing)
5. SBSS logs transmission success, sets OID status = SNT

**Inbound Message Flow**:
1. TPS gateway pushes MSG-CLRR or CLNTDUP message to SBSS listener endpoint (configured callback URL or polling interval)
2. SBSS listener deserializes message, validates EDIFACT structure
3. Routes message to appropriate response handler class (`ClregrBsisResponseHandler.cs` or `ClntdupBsisResponseHandler.cs`)
4. Response handler parses segments, extracts identifier, correlates to shipment/customer
5. Updates customer profile, sets OID status = REC or ERR, logs event

**Error Retry Logic**:
- If outbound transmission fails (network timeout, gateway unavailable):
  - Retry up to 3 times with exponential backoff (30 sec, 2 min, 5 min)
  - If all retries fail, set OID status = ERR, log error, create manual exception for broker
- If inbound message parsing fails (malformed EDIFACT, missing mandatory segment):
  - Log error, archive raw message to error queue, do NOT update shipment/customer
  - Administrator reviews error queue, corrects issue (e.g., missing segment due to TPS bug), manually reprocesses

---

### 6.2 Customer Profile Comment System

**Storage Mechanism**: Customer.Comments collection (one-to-many relationship: Customer → CustomerComment)

**Comment Type Reference**:

| Comment Type Code | Description | Data Format | Max Length | Validation Class |
|-------------------|-------------|-------------|------------|------------------|
| TIN | Australian Business Number | Numeric, 11 or 14 digits | 14 | ValidateCustomerCommentBasedOnFormatAndLength.cs |
| OID | Customs Client Identifier | Alphanumeric, 3 alpha + 7 numeric + 1 alpha uppercase | 11 | ValidateCustomerCommentBasedOnFormatAndLength.cs |
| CCI | Customs Client Identifier Request Data | Structured key-value pairs (see §2.4) | 2048 | None (free text) |

**Access Methods**:
- **Read**: `Customer.GetCommentText(commentType)` → Returns comment value string or null if not exists
- **Write**: `Customer.SetCommentText(commentType, commentValue)` → Creates new comment if not exists, updates existing if present
- **Delete**: `Customer.DeleteComment(commentType)` → Removes comment record (use sparingly, typically only for admin corrections)

**Concurrency Handling**:
- Customer profile updates use optimistic locking (version number check on save)
- If concurrent update detected (e.g., two responses for different shipments updating same customer simultaneously), last-write-wins (version conflict triggers retry with refresh)

**Audit Trail**:
- All comment create/update/delete operations logged in Customer History table
- Log entry includes: Timestamp, User ID (system user for auto-updates), Old Value, New Value, Source (e.g., "MSG-CLRR Response Processing")

---

### 6.3 Shipment Brokerage Status Engine

**Implementation**: Shipment object method `Shipment.SetBrokerageStatus(statusType, statusValue)`

**Persistence**: ShipmentBrokerageStatus table (many-to-many relationship: Shipment ↔ BrokerageStatusType ↔ BrokerageStatusValue)

**Status Type Registration** (one-time setup via SQL script):

```sql
INSERT INTO BrokerageStatusType (Code, Description, Active)
VALUES ('OID', 'Customs Client Identifier Submission Reference', 1);

INSERT INTO BrokerageStatusValue (StatusTypeCode, Value, Description, Sequence)
VALUES 
  ('OID', 'REQ', 'Submission Required', 1),
  ('OID', 'NRQ', 'Submission Not Required', 2),
  ('OID', 'RFC', 'Ready for Customs', 3),
  ('OID', 'SNT', 'Submission Sent', 4),
  ('OID', 'ERR', 'Error', 5),
  ('OID', 'REC', 'Received', 6),
  ('OID', 'CMP', 'Complete', 7);
```

**Query Methods**:
- **Get Current Status**: `Shipment.GetBrokerageStatus(statusType)` → Returns current status value or null
- **Get Status History**: `Shipment.GetBrokerageStatusHistory(statusType)` → Returns ordered list of status changes with timestamps

**UI Display**:
- Full Turbo > Shipment > Brokerage Status tab
- Display OID status alongside existing RAT, EBC, CUS, FOR statuses
- Color coding: RFC/SNT = yellow (in progress), REC/CMP = green (success), ERR = red (action required), NRQ = gray (not applicable)

---

### 6.4 Declaration Comment CCI Workflow

**Purpose**: Custom action form data must persist across shipment saves and be available for MSG-CLR message mapping

**Write Process** (custom action Send button onClick):
1. Serialize all form fields to key-value string (see §2.4 format)
2. Call `Declaration.SetCommentText("CCI", serializedData)`
3. Save declaration object
4. Set OID status = RFC
5. Save shipment (triggers auto-message generation on next shipment save event)

**Read Process** (MSG-CLR message generation):
1. Load shipment and declaration
2. Call `Declaration.GetCommentText("CCI")` → Returns serialized string or null
3. If null (auto-registration, no custom action data):
   - Use default mapping: Pull data from declaration party address (importer/shipper/exporter based on role)
   - EntityType assumed = Organization, RoleType determined by processing mode (import = Importer, export = Exporter)
4. If not null (custom action submission):
   - Deserialize key-value string to dictionary
   - Extract RoleType field → Determines which declaration party address to use
   - Extract EntityType field → Determines Organization vs. Individual message structure
   - Extract all other fields → Override declaration party address values for MSG-CLR segments

**Conflict Resolution**:
- Custom action data takes precedence over declaration party address data
- If custom action data incomplete (missing mandatory field), fall back to declaration party address, log warning event

---

### 6.5 Transaction Correlation Table (IBLOCTX)

**Purpose**: Track MSG-CLR message transmission for deduplication and response correlation

**Schema** (relevant columns):

| Column Name | Data Type | Description | Populated By |
|-------------|-----------|-------------|--------------|
| TransactionID | GUID | Unique identifier for this MSG-CLR transmission | Auto-generated on message send |
| ReferenceNumber | String(35) | MSG-CLR message reference number (CRN from BGM segment) | MSG-CLR message generation step |
| CustomerOID | Long | SBSS Customer OID that MSG-CLR applies to | Auto-registration or custom action step |
| ProcessedStatusCode | Int | 5 = Pending (sent, awaiting response), 6 = Processed (response received) | Message send sets 5, response handler sets 6 |
| MessageType | String(10) | MSG-CLR | Fixed value |
| CreatedDateTime | DateTime | Timestamp of MSG-CLR transmission | Auto-populated |
| UpdatedDateTime | DateTime | Timestamp of response processing | Updated by response handler |

**Insert Logic** (on MSG-CLR send):

```csharp
processingTable.InsertNTSAData(
    string.Empty,  // Not used for MSG-CLR
    string.Empty,  // Not used for MSG-CLR
    customerOID,
    string.Empty,  // Not used for MSG-CLR
    7,             // Interface type code for MSG-CLR
    clregMessageReference,  // ReferenceNumber
    Guid.NewGuid().ToString(),  // TransactionID
    0,
    0,
    string.Empty,
    string.Empty,
    true  // Active flag
);
```

**Query Logic** (deduplication check):

```sql
SELECT COUNT(*) 
FROM IBLOCTX 
WHERE CustomerOID = @CustomerOID 
  AND ProcessedStatusCode IN (5, 6) 
  AND CreatedDateTime >= DATEADD(MINUTE, -@TimeWindow, GETDATE())
```

If count > 0 → Prior request exists, skip auto-registration

**Update Logic** (on response processing):

```sql
UPDATE IBLOCTX
SET ProcessedStatusCode = 6,
    UpdatedDateTime = GETDATE()
WHERE ReferenceNumber = @RFF_ABO_ReferenceNumber
  AND ProcessedStatusCode = 5
```

---

### 6.6 Master Town Reference Table

**Purpose**: Validate and auto-populate Australian postal codes, localities (cities), and state codes

**Schema**:

| Column Name | Data Type | Description | Example |
|-------------|-----------|-------------|---------|
| PostalCode | String(4) | 4-digit Australian postal code | 2000 |
| Locality | String(100) | City/suburb name | Sydney, Millers Point, The Rocks |
| State | String(3) | Australian state/territory code | NSW, VIC, QLD, SA, WA, TAS, NT, ACT |
| Country | String(2) | Always "AU" for this table | AU |

**Data Source**: Australia Post official postal code database (updated quarterly via admin import process)

**Lookup Patterns**:

1. **By Postal Code** (one-to-many relationship: one postal code can serve multiple localities):
   ```csharp
   var towns = localAutoRef.GetRefDataView(AutoRefTypes.TYPE_MasterTown)
       .Where(row => row["PostalCode"] == userEnteredPostalCode)
       .ToList();
   ```
   Result: List of localities for that postal code, all with same state

2. **By Locality** (one-to-many relationship: one locality name can exist in multiple states with different postal codes):
   ```csharp
   var towns = localAutoRef.GetRefDataView(AutoRefTypes.TYPE_MasterTown)
       .Where(row => row["Locality"].ToUpper() == userEnteredCity.ToUpper())
       .ToList();
   ```
   Result: List of postal codes for that locality name across all states

**UI Auto-Population Logic** (Custom Action Form):
- User enters Postal Code → OnChange event fires
  - Lookup by Postal Code
  - If single locality match: Auto-populate City field (read-only), auto-populate State field (read-only)
  - If multiple locality matches: Populate City dropdown with all localities, require user selection, then auto-populate State based on selected locality
- User enters City → OnChange event fires
  - Lookup by Locality
  - If single postal code match: Auto-populate Postal Code field, auto-populate State field (read-only)
  - If multiple postal code matches: Populate Postal Code dropdown, require user selection, then auto-populate State
- User enters both Postal Code and City → Postal Code takes precedence (see §3.2 validation rule 3)

---

### 6.7 ICAO Country Codes Reference (ICC)

**Purpose**: Provide 3-character country codes for individual travel document issuing country selection

**Reference Type**: ICC (ICAO Country Codes)  
**Parent Type**: CU (Customer-related reference data)  
**Data Source**: International Civil Aviation Organization (ICAO) official country code list (https://www.CBF.gov.au/help-and-support/TPS/integrated-cargo-system-(TPS)/software-developers/reference-materials/code-list/icao-country-codes)

**Schema**:

| Custom Code Value | Custom Code Value Description | Usage Context |
|-------------------|-------------------------------|---------------|
| AUS | Australia | Passport, Driver License |
| USA | United States of America | Passport |
| GBR | United Kingdom | Passport |
| NZL | New Zealand | Passport, Driver License |
| ... | ... | ... |

**Access Method**:
```csharp
var countryList = customCodesEngine.GetCustomCodesByType("ICC", "CU");
// Returns collection of CustomCode objects with Value (3-char code) and Description (country name)
```

**UI Binding** (Custom Action Form, Travel Documents table):
- Country dropdown populated from ICC reference
- Display format: "AUS - Australia", "USA - United States of America"
- Store value: 3-character code only (e.g., "AUS")

---

### 6.8 Search Word Reference (Type OID)

**Purpose**: Whitelist customer names eligible for auto-registration to prevent erroneous MSG-CLR submissions for incomplete/invalid profiles

**Reference Type**: OID (Customs Client Identifier Search Words)  
**Access Path**: SBSS Admin > Reference Tables > Search Word Reference

**Schema**:

| Type | Search Word | Description | Active |
|------|-------------|-------------|--------|
| OID | Carrier Co | Carrier Co entity variants | 1 |
| OID | FEDEX | FedEx entity variants | 1 |
| OID | DHL | DHL entity variants | 1 |
| OID | TOLL | Toll Group entities | 1 |

**Matching Algorithm**:
```csharp
string customerName = targetCustomer.Name.ToUpper().Trim();
var searchWords = searchWordEngine.GetSearchWordsByType("OID");

bool isMatchFound = searchWords.Any(sw => customerName.Contains(sw.SearchWord.ToUpper()));

if (!isMatchFound) {
    // Skip auto-registration
    return;
}
```

**Admin Workflow**:
1. Administrator identifies new major customer requiring OEM Client ID auto-registration (e.g., "ACME IMPORTS PTY LTD")
2. Navigate to SBSS Admin > Reference Tables > Search Word Reference
3. Add new row: Type = OID, Search Word = "ACME", Description = "ACME Imports and subsidiaries", Active = Yes
4. Save reference table
5. All future shipments with importer/shipper names containing "ACME" now eligible for auto-registration (subject to other criteria)

**Maintenance Frequency**: Review quarterly, add new major customers, remove defunct entities

---

## 7. Event Logging Specification

### 7.1 Auto-Registration Events

**Event Type**: Shipment Event (ShipmentEvent table)  
**Category**: Brokerage Processing

| Event Trigger | Event Description Template | Severity | Example |
|---------------|---------------------------|----------|---------|
| Auto-registration triggered | "Auto application for OEM Client ID for {role} account {accountNumber} sent" | Info | "Auto application for OEM Client ID for importer account 8AU123456 sent" |
| Auto-registration skipped (has identifier) | "OEM Client ID auto-registration skipped. {role} account {accountNumber} has {identifierType}: {identifierValue}" | Info | "OEM Client ID auto-registration skipped. Importer account 0000F12345 has TIN: 12345678901" |
| Auto-registration skipped (lookup disabled) | "OEM Client ID auto-registration disabled by lookup AUTOOID = N" | Info | "OEM Client ID auto-registration disabled by lookup AUTOOID = N" |
| Auto-registration skipped (CT/RAT filter) | "OEM Client ID auto-registration skipped. Shipment CT={ct} RAT={rat} does not match lookup CIDCTRAT criteria" | Info | "OEM Client ID auto-registration skipped. Shipment CT=DEM RAT=CMP does not match lookup CIDCTRAT criteria" |
| Auto-registration skipped (search word mismatch) | "OEM Client ID auto-registration skipped. {role} name '{name}' not in search word list" | Info | "OEM Client ID auto-registration skipped. Importer name 'UNKNOWN PARTY' not in search word list" |
| Auto-registration skipped (prior request exists) | "OEM Client ID auto-registration skipped. Prior request for customer OID {oid} found in transaction table" | Info | "OEM Client ID auto-registration skipped. Prior request for customer OID 123456 found in transaction table" |

---

### 7.2 Manual Registration Events

| Event Trigger | Event Description Template | Severity | Example |
|---------------|---------------------------|----------|---------|
| Custom action form opened | "Customs Client Identifier form opened for {role}" | Info | "Customs Client Identifier form opened for Importer" |
| Custom action Send button clicked | "OEM Client ID registration request submitted manually for {entityType} {role}. ReferenceNumber: {crn}" | Info | "OEM Client ID registration request submitted manually for Organization Importer. ReferenceNumber: CRN987654321" |
| Custom action validation error | "OEM Client ID registration submission failed validation: {errorMessage}" | Warning | "OEM Client ID registration submission failed validation: Family Name is required for Individual entity type" |

---

### 7.3 Message Transmission Events

| Event Trigger | Event Description Template | Severity | Example |
|---------------|---------------------------|----------|---------|
| MSG-CLR sent successfully | "MSG-CLR message sent to TPS. ReferenceNumber: {crn}, CustomerOID: {oid}" | Info | "MSG-CLR message sent to TPS. ReferenceNumber: CRN123456789, CustomerOID: 789012" |
| MSG-CLR transmission failed | "MSG-CLR message transmission failed. Error: {errorMessage}. Retry attempt {attemptNumber} of 3." | Error | "MSG-CLR message transmission failed. Error: Gateway timeout. Retry attempt 1 of 3." |
| MSG-CLR transmission retry exhausted | "MSG-CLR message transmission failed after 3 retries. Manual intervention required. ReferenceNumber: {crn}" | Critical | "MSG-CLR message transmission failed after 3 retries. Manual intervention required. ReferenceNumber: CRN123456789" |

---

### 7.4 Response Processing Events

| Event Trigger | Event Description Template | Severity | Example |
|---------------|---------------------------|----------|---------|
| MSG-CLRR received (success) | "OEM Client ID registration successful. OEM Client ID {ccidValue} issued by customs for customer OID {oid}" | Info | "OEM Client ID registration successful. OEM Client ID CET7934637L issued by customs for customer OID 789012" |
| MSG-CLRR received (rejection) | "OEM Client ID registration rejected by customs. Reason: {rejectionReason}. ReferenceNumber: {crn}" | Warning | "OEM Client ID registration rejected by customs. Reason: Invalid postal code. ReferenceNumber: CRN123456789" |
| CLNTDUP received (duplicate TIN) | "Duplicate party detected by customs. TIN {abnValue} returned for customer OID {oid}" | Info | "Duplicate party detected by customs. TIN 23869413369 returned for customer OID 789012" |
| CLNTDUP received (duplicate OEM Client ID) | "Duplicate party detected by customs. OEM Client ID {ccidValue} returned for customer OID {oid}" | Info | "Duplicate party detected by customs. OEM Client ID CGJ4763467L returned for customer OID 789012" |
| CLNTDUP received (rejection) | "OEM Client ID duplicate check rejected by customs. Reason: {rejectionReason}. ReferenceNumber: {crn}" | Warning | "OEM Client ID duplicate check rejected by customs. Reason: TIN does not match party name. ReferenceNumber: CRN123456789" |
| Response correlation failed | "OEM Client ID response received with unmatched reference: {reference}. Message type: {messageType}. Unable to correlate to shipment." | Error | "OEM Client ID response received with unmatched reference: CRN999999999. Message type: MSG-CLRR. Unable to correlate to shipment." |

---

### 7.5 Customer Profile Update Events

| Event Trigger | Event Description Template | Severity | Example |
|---------------|---------------------------|----------|---------|
| TIN applied from response | "TIN {abnValue} applied to customer OID {oid} from {messageType} response" | Info | "TIN 12345678901 applied to customer OID 789012 from CLNTDUP response" |
| OEM Client ID applied from response | "OEM Client ID {ccidValue} applied to customer OID {oid} from {messageType} response" | Info | "OEM Client ID CET7934637L applied to customer OID 789012 from MSG-CLRR response" |
| Identifier applied from alternate profile | "{identifierType} {identifierValue} applied from Account No - {sourceAccountNumber}" | Info | "TIN 12345678901 applied from Account No - 8AU123456" |
| Multi-shipment status update | "{shipmentCount} shipments updated with OID status {statusValue} for customer OID {oid}" | Info | "5 shipments updated with OID status REC for customer OID 789012" |

---

### 7.6 Declaration Update Events

| Event Trigger | Event Description Template | Severity | Example |
|---------------|---------------------------|----------|---------|
| Identifier copied to declaration | "{identifierType} {identifierValue} copied from customer profile to declaration {role}" | Info | "OEM Client ID CET7934637L copied from customer profile to declaration Importer" |
| Address auto-populated from Master Town | "Address corrected based on postal code. Original City: {originalCity}, Corrected City: {correctedCity}, State: {state}" | Info | "Address corrected based on postal code. Original City: Sidney, Corrected City: Sydney, State: NSW" |

---

## 8. Configuration Reference

### 8.1 Local Lookup Configuration

**Table**: LocalLookup  
**Maintenance Path**: SBSS Admin > System Configuration > Local Lookup

#### AUTOOID Lookup

**Purpose**: Enable/disable auto-registration per processing mode

| Lookup Key | Valid Values | Default | Description |
|-----------|--------------|---------|-------------|
| AUTOOID LPM-I | Y, N | Y | Auto-submit OEM Client ID for imports if Y |
| AUTOOID LPM-X | Y, N | Y | Auto-submit OEM Client ID for exports if Y |

**Configuration Script**:
```sql
-- Import auto-registration (enabled by default)
INSERT INTO LocalLookup (Type, ProcessingMode, Value, Description)
VALUES ('AUTOOID', 'LPM-I', 'Y', 'Auto-submit OEM Client ID for imports');

-- Export auto-registration (enabled by default)
INSERT INTO LocalLookup (Type, ProcessingMode, Value, Description)
VALUES ('AUTOOID', 'LPM-X', 'Y', 'Auto-submit OEM Client ID for exports');
```

**Usage Context**: Auto-registration rule step checks this lookup first. If N, all auto-registration logic skipped (manual submission via custom action still available).

#### CIDCTRAT Lookup

**Purpose**: Filter auto-registration by Clearance Type and Rating Status

| Lookup Key | Format | Example | Description |
|-----------|--------|---------|-------------|
| CIDCTRAT LPM-I | \|RAT=status1,status2,...\|CT=type1,type2,...\| | \|RAT=CMP,INT,HLD\|CT=FML,INF\| | Only auto-submit OEM Client ID for imports if RAT and CT match |
| CIDCTRAT LPM-X | \|RAT=status1,status2,...\|CT=type1,type2,...\| | \|RAT=CMP,INT,HLD\|CT=FML,INF\| | Only auto-submit OEM Client ID for exports if RAT and CT match |

**Configuration Script**:
```sql
-- Import CT/RAT filter (formal and informal clearances with completed rating)
INSERT INTO LocalLookup (Type, ProcessingMode, Value, Description)
VALUES ('CIDCTRAT', 'LPM-I', '|RAT=CMP,INT,HLD|CT=FML,INF|', 'Auto-submit OEM Client ID only for formal/informal clearances with completed rating');

-- Export CT/RAT filter (formal clearances only)
INSERT INTO LocalLookup (Type, ProcessingMode, Value, Description)
VALUES ('CIDCTRAT', 'LPM-X', '|RAT=CMP,INT,HLD|CT=FML|', 'Auto-submit OEM Client ID only for formal export clearances');
```

**Parsing Logic**:
```csharp
string lookupValue = localLookup.GetSpecificLocalValue("CIDCTRAT", processingMode);
if (string.IsNullOrEmpty(lookupValue)) {
    // No filter configured, proceed with auto-registration
} else {
    // Parse RAT values
    string ratPattern = @"\|RAT=([^|]+)\|";
    var ratMatch = Regex.Match(lookupValue, ratPattern);
    string[] validRatValues = ratMatch.Success 
        ? ratMatch.Groups[1].Value.Split(',') 
        : new string[0];
    
    // Parse CT values
    string ctPattern = @"\|CT=([^|]+)\|";
    var ctMatch = Regex.Match(lookupValue, ctPattern);
    string[] validCtValues = ctMatch.Success 
        ? ctMatch.Groups[1].Value.Split(',') 
        : new string[0];
    
    // Check shipment
    if (!validRatValues.Contains(shipment.RatingStatus) 
        || !validCtValues.Contains(shipment.ClearanceType)) {
        // Shipment does not meet criteria, skip auto-registration
    }
}
```

**Usage Context**: After AUTOOID check passes, evaluate CIDCTRAT filter. Allows business to restrict auto-registration to high-value formal clearances only, avoiding MSG-CLR spam for de minimis or informal entries where OEM Client ID rarely required.

---

### 8.2 Orchestration Rule Properties

**Rule**: Declaration_Initialize  
**Step**: ValidateCustomsClientIdentifierSubmission.cs

| Property Name | Data Type | Example Value | Description |
|--------------|-----------|---------------|-------------|
| CommentsType | String | "TIN,OID" | Comma-delimited list of customer comment types to check for existing identifiers |
| SearchWordsType | String | "OID" | Search word type to use for customer name matching |
| VerifyValidationRecord | Boolean | true | If true, check IBLOCTX transaction table for prior MSG-CLR requests |
| ShipmentBrokerageStatusType | String | "OID" | Brokerage status type to set on shipment |
| ShipmentBrokerageStatusValue | String | "RFC" | Brokerage status value to set if conditions met |

**Rule**: Shipment_StoreValidationComplete  
**Step**: AutoTriggerCustomsClientIdentifier.cs

| Property Name | Data Type | Example Value | Description |
|--------------|-----------|---------------|-------------|
| ShipmentBrokerageStatusType | String | "OID" | Brokerage status type to check for triggering |
| ValidSubmissionStatus | String | "RFC" | Status value that triggers MSG-CLR message generation |
| PostSubmissionStatus | String | "SNT" | Status value to set after MSG-CLR sent successfully |

**Response Handler Properties** (in message configuration, not code):

| Property Name | Data Type | Example Value | Description |
|--------------|-----------|---------------|-------------|
| TimeRange | Int | 10 | Time window in minutes for multi-shipment status update query |

---

### 8.3 Custom Action Configuration

**Custom Action Number**: 3000  
**Name**: Customs Client Identifier  
**Rule**: Rule_CustomAction  
**Rule Step**: RuleCustomActionFor3000.cs  
**Form Class**: AUVisualsAndForms.CustomsClientIdentifier.cs

**Availability**:
- Processing Mode: All (imports and exports)
- User Roles: BRK, COM, ADM (broker, compiler, administrator)
- Shipment Status: Any (available on all shipments regardless of CUS/RAT/FOR status)

**UI Launch Path**:
1. Open shipment in Full Turbo
2. Click "Actions" menu
3. Select "Customs Client Identifier" from dropdown
4. Form modal window opens

**Form Behavior**:
- Auto-populates fields from declaration party address based on selected Role Type
- Validates fields on Send button click
- Saves data to Declaration.Comment[CCI] on successful validation
- Sets Shipment.BrokerageStatus[OID] = RFC
- Saves shipment (triggers MSG-CLR generation on next save event)
- Displays confirmation message: "OEM Client ID registration request submitted. Reference: [CRN]"

---

## 9. Performance and Scalability Considerations

### 9.1 Message Volume Projections

**Assumptions**:
- Average shipments per day (AU operations): 5,000
- Percentage requiring OEM Client ID (new customers or missing identifiers): 10%
- Auto-registration trigger rate: 500 MSG-CLR messages per day
- Average TPS response time: 5 minutes (during business hours)

**Peak Load Scenario**:
- Bulk manifest download at start of business day: 2,000 shipments within 1 hour
- If all trigger auto-registration: 2,000 MSG-CLR messages queued
- TPS gateway throughput: ~100 messages per minute
- Queue processing time: 20 minutes
- Response processing: 2,000 MSG-CLRR/CLNTDUP messages over subsequent 30 minutes

**Bottleneck Analysis**:
- IBLOCTX transaction table insert rate: >1,000 inserts/sec (no bottleneck expected)
- Customer profile update rate: Limited by database row-level locking, ~50 updates/sec (potential bottleneck if many concurrent responses for same customer)
- Mitigation: Serialize customer profile updates via transaction queue, process in FIFO order

---

### 9.2 Database Indexing Requirements

**IBLOCTX Table**:
- Index on: CustomerOID, ProcessedStatusCode, CreatedDateTime (composite index)
- Purpose: Optimize deduplication query (`WHERE CustomerOID = ? AND ProcessedStatusCode IN (5,6) AND CreatedDateTime >= ?`)
- Expected query performance: <50ms for typical deduplication check

**Customer Comment Table**:
- Index on: CustomerOID, CommentType (composite index)
- Purpose: Fast lookup of TIN/OID comments during declaration initialization
- Expected query performance: <10ms

**ShipmentBrokerageStatus Table**:
- Index on: ShipmentOID, StatusType, StatusValue (composite index)
- Purpose: Fast filtering of shipments by OID status for worklist views
- Expected query performance: <100ms for typical broker worklist query (last 7 days, OID = ERR)

---

### 9.3 Retry and Throttling Strategy

**Outbound MSG-CLR Throttling**:
- Max concurrent transmissions: 10 (configurable)
- Queue overflow behavior: Hold in SBSS internal queue, process FIFO as gateway capacity available
- Priority: Manual custom action submissions processed before auto-registration queue

**Response Processing Throttling**:
- Max concurrent customer profile updates: 5 (to avoid database lock contention)
- Queue overflow behavior: Hold responses in processing queue, process sequentially
- Timeout: If customer profile locked for >30 seconds, log error, retry after 1 minute

---

---

**End of Technical Specification**

---

**Revision History**:

| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | [Current Date] | System Architect | Initial release |

**Approval**:

| Role | Name | Signature | Date |
|------|------|-----------|------|
| Product Owner | [Name] | __________ | _____ |
| Technical Lead | [Name] | __________ | _____ |
| Compliance Officer | [Name] | __________ | _____ |

User stories:

title: Customs Client ID (OID) - Auto apply OID for 8AU IOR
description: As a user, I want SBSS to check for available OID for shipments matched to casual accounts and to apply for OID if required so that OID can be submitted.
acceptance_criteria: When shipment is downloaded with matched customer's account starting with a number followed "AU" eg "7AU/8AU", SBSS is to check if OID or TIN is available in the customer profile If yes, do nothing If no, lookup the Declaration Importer Name and Address against existing customer profiles in SBSS If same name & address are matched to existing profiles, apply the OID or TIN as per User Story 4252992: Customs Client ID (OID) and User Story 4976163: OID Removal from TAXID and TIN/OID consider from customer accounts Apply TIN or OEM Client ID in Declaration >>> Importer. Events to capture on the information applied as well as source. Eg "OID or TIN - ABC1234567E applied from Account No - 8AU123456" If no match is found from Declaration >>> Importer >> OID or TIN, SBSS is to show on Remarks pop-up "OEM Client ID is required".

title: OID Removal from TAXID and TIN/OID consider from customer accounts
description: As OID is getting conflicts with TIN while adding TAX ID back to customer profile as a comment.
acceptance_criteria: For AU: Remove OID from TAX ID updates from customer( Earlier TIN/OID) ( Demo point from other story Tax ID back to TIN with Popup User Story 4252970: Australia Business Number (TIN)) Considering the Importer and Shipper profiles for TIN to check (User Story 4648834: Customer Comment Type from Shipper/Importer customer profile ) It means that if the shipper (F12345) dont have the comment type eg TIN, SBSS is to look up the importer's profile (0000F12345). And if the importer (0000F12345) dont have the comment type eg TIN, SBSS is to look up the shipper's profile (F12345). OID to be reflected on full turbo under OID to be stored under Customer Profile > Comments Code - OID, Description - Customs Clearance Identification ID It means that if the shipper (F12345) dont have the comment type eg OID, SBSS is to look up the importer's profile (0000F12345). And if the importer (0000F12345) dont have the comment type eg OID, SBSS is to look up the shipper's profile (F12345). OID to be showing under Reference Number

title: Customs Client ID (OID) Application & Submission – Enhancement for Organization
description: As a user, I want to add on to the OEM Client ID application screens to allow for the submission of OEM Client ID requests for individuals and suppliers.
acceptance_criteria: This story is to modify User Story 4253011: Customs Client ID (OID) Application & Submission to extend the OEM Client ID request for individuals and overseas shippers. 2. From the current Client Registration Request screen (below screenshot), add the following client types: Organisation Individual 3. Move the Role field immediately below item A and provide a dropdown list of all Role Types. Exporter (AU Shipper) Importer (AU Receiver) Supplier (Overseas Shipper) 4. Populate fields depending on Role Type selected. When user selects Exporter, the fields will populate with the Declaration >>> Customer >>> Shipper details. When user selects Importer, the fields will populate with the Declaration >>> Customer >>> Importer details. When user selects Supplier, the fields will populate with the Declaration >>> Customer >>> Shipper details. 5. From item 2, when user selects Organisation, show the details on the screenshot. 6. If user selects Individual, show the current pop up with a few additional (modified) fields. a. Title --- Free Text (optional) b. First Name --- Free Text (optional) c. Second Name --- Free Text (optional) d. Family Name --- Free Text (Required) e. Suffix --- Free Text (optional) f. Date of Birth --- DDMMYYYY (optional) g. Sex --- Provide dropdown (Required) h. Address Line 1 --- same as the screenshot (Required) i. Address Line 2 --- same as the screenshot (optional) j. Locality --- same as the screenshot (Required) k. Validate from User Story 4722122: Postal code Validation l. Postal Code --- same as the screenshot (Required) m. State Code --- populate based on post code table from User Story 4722122: Postal code Validation n. Country Code --- same as the screenshot (Required) o. Travel Documents i. Provide a table to enter Document details. 7. Save Details in Declaration Comments.

title: ROV - Customs Client ID (OID) Application & Submission – Organisations
description: As a user, I want to add on to the OEM Client ID application screens to allow for the submission of OEM Client ID requests for individuals and suppliers.
acceptance_criteria: * NOTE : This story has nothing to implement. Can leave this as it is... * 1. This story is to modify User Story 4253011: Customs Client ID (OID) Application & Submission to extend the OEM Client ID request for individuals and overseas shippers. 2. From the current Client Registration Request screen (below screenshot), add the following client types: Organisation Individual 3. Move the Role field immediately below item A and provide a dropdown list of all Role Types. Exporter (AU Shipper) Importer (AU Receiver) Supplier (Overseas Shipper) 4. Populate fields depending on Role Type selected. When user selects Exporter, the fields will populate with the Declaration Exporter details. When user selects Importer, the fields will populate with the Declaration Importer details. When user selects Supplier, the fields will populate with the Declaration Shipper details. 5. From item 2, when user selects Organisation, show the details on the screenshot. 6. If user selects Individual, show the current pop up with a few additional (modified) fields. a. Title --- Free Text (optional) b. First Name --- Free Text (optional) c. Second Name --- Free Text (optional) d. Family Name --- Free Text (Required) e. Suffix --- Free Text (optional) f. Date of Birth --- DDMMYYYY (optional) g. Sex --- Provide dropdown (Required) h. Address Line 1 --- same as the screenshot (Required) i. Address Line 2 --- same as the screenshot (optional) j. Locality --- same as the screenshot (Required) l. Validate from User Story 4722122: Postal code Validation m. Postal Code --- same as the screenshot (Required) n. State Code --- populate based on post code table from User Story 4722122: Postal code Validation o. Country Code --- same as the screenshot (Required) p. Travel Documents Provide a table to enter Document details.

title: Customs Client ID (OID) Application & Submission – Individual & Organization
description: This story is to modify User Story 4253011: Customs Client ID (OID) Application & Submission to extend the OEM Client ID request for individuals and overseas shippers If user selects Individual, show the current pop up with a few additional (modified) fields. Title --- Free Text (optional) First Name --- Free Text (optional) Second Name --- Free Text (optional) Family Name --- auto populated from Declaration > Importer > Name (Required) Suffix --- Free Text (optional) Date of Birth --- DDMMYYYY (optional) Sex --- Provide dropdown (Required) Address Line 1 --- auto populated from Declaration > Importer > Address line 1 (Required) Address Line 2 --- auto populated from Declaration > Importer > Address line 2 (optional) Postal Code --- auto populated from Declaration > Importer > Postal Code (Required) Locality -- Populate based on post code table > City from User Story 4722122: Postal code Validation (Required) State Code -- Populate based on post code table > City from User Story 4722122: Postal code Validation (Required) Country Code --- Populate based on post code table > Country from User Story 4722122: Postal code Validation (Required). If not AU postal code, leave blank for user to enter Travel Document Document Number is a free text field For Ctry, provide the dropdown of country codes (https://www.CBF.gov.au/help-and-support/TPS/integrated-cargo-system-(TPS)/software-developers/reference-materials/code-list/icao-country-codes) Allow user to enter more than one travel document Technical Details: There are two categories basically with the Radio buttons Individual Organization Custom Action Details: Custom Action is already configured with previous implementation nothing is required on it. Custom Action Number: 3000 Name: Customs Client Identifier Rule: Rule_CustomAction Rule Step For custom action: RuleCustomActionFor3000 This rule step is to open the popup from custom action. Form Details: AU> AUVisualsAndForms> CustomsCLientIdentifier.cs Request And Response: Request and Response implementations covering from other stories as these are only screen and earlier it was temporarily saving in shipment comments, looks it is not required now.
acceptance_criteria: Individual Fields Validation: Family Name --- auto populated from Declaration > Importer > Name (Required) Address Line 1 --- auto populated from Declaration > Importer > Address line 1 (Required) Address Line 2 --- auto populated from Declaration > Importer > Address line 2 (optional) Postal Code --- auto populated from Declaration > Importer > Postal Code (Required) Individual and Organisation common form changes: Move Postal Code before the Locality/Street fields on the UI. Submit Individual and Organisation Requests: Once the validations are passed, perform the below Update all the fields related to the Role type from Customs Client Identifier form to the Declaration -> Customer -> Addresses.

title: Customs Client ID (OID) Application – Enhancement Part 2
description: As a user, I want to add on to the OEM Client ID application screens to allow for the submission of OEM Client ID requests for individuals and suppliers.
acceptance_criteria: Enhancement for User Story 5530913: Customs Client ID (OID) Application & Submission – Enhancement for Organization Add three fields on top of the screen. TIN - 11 numbers, no space CAC - 3 numbers (optional) CAC Adress Type - provide dropdown (required when CAC is provided) BA - Business Address PA - Postal Address 3. Populate this field when : user manually affixes TIN in Full Turbo >>> Address >>> Importer >>> Tax ID an TIN is added as a comment on the customer profile vice versa - if TIN added in OEM Client ID screen, reflect in Tax ID field or Customer Profile 4. When an TIN is provided for registration, a. Allow user to proceed without selecting Organisation or Individual. b. Role is defaulted to Importer. c. Populate the remaining fields from the importer profile. Declaration >>> Customer >>> Importer details 6. For individuals, add a checkbox at the bottom of the window >>> Evidence of Identity Confirmed. 7. When users tick the box, show the document table, and allow user to add document numbers and place of issue. 8. Save Details in Declaration Comments.

title: Customs Client Identifier Form Address Validation
description: If a Supplier (Shipper), Importer or an Exporter party address has an AU Country Code, validate the address per User Story 4722122: Postal code Validation. If all fields are provided, allow the submission of a OEM Client ID application. ---------------------- 5. Referring to country codes when documents are added to importer OEM Client ID applications, please use "Country local" table, and add local codes for the countries per Jorrit's discussion point on User Story 5530913: Customs Client ID (OID) Application & Submission – Enhancement for Organization. ---------------------- 6. Please update mapping of Acceptance Criteria 2(d) per User Story 5534700: Customs Client ID (OID) Application & Submission – Individual Family Name --- auto populated from Declaration > Importer > Name (Required) ---------------------- 7.When a CAC is provided, it is displayed with the TIN per User Story 4252970: [Project-A Country Name] Business Number (TIN). Technical Details: Validate the fields as mentioned details above There are two categories basically with the Radio buttons Individual Organization Custom Action Details: Custom Action is already configured with previous implementation nothing is required on it. Custom Action Number: 3000 Name: Customs Client Identifier Rule: Rule_CustomAction Rule Step For custom action: RuleCustomActionFor3000 This rule step is to open the popup from custom action. Form Details: AU> AUVisualsAndForms> CustomsCLientIdentifier.cs Request And Response: Request and Response implementations covering from other stories as these are only screen and earlier it was temporarily saving in shipment comments, looks it is not required now.
acceptance_criteria: Functional Requirement: On Customs Client Identifier form, for both Individual and Organisation forms, for the role selected, if the address is overseas address (country code <> AU), Validation for Postal code/Country/State is NOT required. Non Overseas address (country code = AU), then perform the following When Postal Code is available, but no Locality/City Then populate City and State list based on Postal code range based on the following reference table data available in AU. When Locality/City is available , but not the Postal Code Populate Postal Codes and States available from the "Master Town" table When Both Locality/City and Postal Code is available Postal code takes the priority to populate Locality/City and State from the "Master Town" table

title: LOP - TIN & OEM Client ID (Customs Client ID - individual)
description: We need a description of how the process for applying for a OEM Client ID and using the OEM Client ID would look in SBSS, so we can identify which parts are already covered, and which parts still need new functionality to be developed. We should also be able to reference this process description as an LOP.
acceptance_criteria: For declaration, on download, system to check for profile match including OEM Client ID, and either auto submits a OEM Client ID application or warns the user that a profile is not registered. User can manually submit an application via Custom Action. General: OEM Client ID number need to be included for some parties in the declaration messages that are sent to TPS. Those parties are:Exporters, it's shippers, importers. Under these conditions: for exporter and importer- When they don't have TIN. for shippers: Can have TIN but they always need OEM Client ID. OEM Client ID numbers can be stored on the customer profile in SBSS. Customer Profile>Comments>OID>Comment . A user can put TIN/OEM Client ID on full turbo. Format limitations on OID: OID comment type valid length is 11 and Sample formats are Ex: CET7934637L (the letters always in caps) . for TIN, the standard length is 11 (always numeric), It can be extended for 3 number (CAC). The user can enter in any format (with space, without space) If a customer profile does not have an OEM Client ID, we can apply for a OEM Client ID by sending a OEM Client ID registration message to TPS. TPS will then respond with either a new OEM Client ID number for that profile, or a message that it is a duplicate profile.: Request for OEM Client ID: MSG-CLR - Client Registration Response with OEM Client ID: MSG-CLRR - Client Registration Response Response indicating a duplicate: CLNTDUP - Client Duplicate Response If MSG-CLRR message is received from TPS, the OEM Client ID must be applied to the customer profile. The trigger point will be when the user clicks on send button on OEM Client ID (below is the screen shot attached). Process on shipment download: Check for profile match including OEM Client ID: We get the OEM Client ID when we check for a match on download. We need to check Exporter, importer and shipper profile. Exporter, importer and shipper. The data do we need for application of OEM Client ID (Name, address and the role) for organization for individuals: https://tfs.Carrier Co.com/tfs/UpsProd/P07AGit_GTS/_workitems/edit/5534700 TIN Name/address/Role either auto submits a OEM Client ID application: If we download 100 shipments with the same importer at the same time, we don't want to trigger 100 messages in that case. Then set the OID value to a 'pending' value when the first request is sent, preventing follow-up triggers The exact conditions for auto OEM Client ID application: If Customer Profile>Comments>OID>Comment does not exist on matched profile, then we apply for OEM Client ID by sending a MSG-CLR message to TPS: When applying (requesting) a OEM Client ID on a customer profile, record in shipment events "Auto application for OEM Client ID for importer account {Account} sent" else, we do nothing. There are no other conditions., if the TIN is provided that can be used for registration. Warns the user that a profile is not registered. If not number 2 the user can select number 3 Valid length is 11 and Sample formats are Ex: CET7934637L. If there no is user intervention then no validation is required, as it's a response and we map it from there. for TIN, the standard length is 11 (always numeric), It can be extended for 3 number (CAC). Process of manual application: Full turbo>>Declaration screen (importer/exporter/shipper)>>Custom client identifier>>Enter TIN (not all TIN have CAC)>> Select role (if TIN is not available select TIN and if state is not correct then it will be rejected). If message response received, OEM Client ID will appear in addressed section. TIN will be reflected in Tax ID and OEM Client ID will be reflected in FZ/CW field.

title: Set Trigger Point of OEM Client ID for Customer - CLRREG
description: As a user, when shipment is getting downloaded, if the customer is not having the TIN/OEM Client ID on the profile, automatically trigger OEM Client ID request. And this trigger should be turned ON/OFF with lookup configuration.
acceptance_criteria: Maintain a Local lookup for the auto submission (AUTOOID) , configure this for import and exports separately AUTOOID LPM-I Y/N(any one value to be configured) AUTOOID LPM-X Y/N(any one value to be configured) Create a Database script to insert a Shipment Brokerage Status Type "OID" - Description - Customs Client Identifier Submission Reference Already Existing When shipment is getting downloaded, verify the following conditions should be Non-interactive, verify local lookup - AUTOOID lookup = N -> Do not trigger auto submission, Skip the process lookup = Y -> check the next condition If RAT status to be configured, in local lookup, if RAT on the shipment matches with lookup values do not submit OEM Client ID request. If CT status to be configured, in local lookup, if CT on the shipment matches with lookup values do not submit OEM Client ID request. CIDCTRAT CIDCTRAT LPM-I =|RAT=CMP,INT,HLD|CT=FML,INF|(any one value to be configured) CIDCTRAT LPM-X =|RAT=CMP,INT,HLD|CT=FML,INF|(any one value to be configured) for Import Shipment -> Verify Importer / for export Shipment -> Verify Shipper with TIN/OID under customer -> Comments, if both of them / any one of them is available do not trigger any request for OID. if none of them is available then check for next condition We need to verify Search Word Type - OID for the matching shipper or importer names if they are not matched, do not Auto submit if they are matched, then check the next condition. Verify Reference record with Customer OID in the transaction table with ProcessedStatusCode as 5/7. (This is technical no need to verify in the testing phase) If Exists do not trigger any other OID request because this refers to the submission previously. If it does not exists trigger OID request because this refers to that OEM Client ID/TIN is not available on customer profile and was not previously requested too, then verify next condition When all the conditions are matched, set shipment Brokerage status OID to RFC

title: Update Trigger Point for CLRREG Message for Manual Submission
description: As a user, I should be able to submit the request by manually updating the values from the existing custom action available by clicking on Send.
acceptance_criteria: Under the custom action > Select the option "Customs Client Identifier" > fill the form based on the needs, Individual/Organization with TIN/CAC/CAC Address Type Then click on Send Once Validations are passed for the fields of the form, Set Shipment Brokerage Status OID to RFC Capture ALL the Data from the fields of the form, Then update the same to the Declaration Comment CCI (already existing). if comment is already there, update if not there, add it. To trigger the message, save the shipment. (Dependency on https://tfs.Carrier Co.com/tfs/UpsProd/P07AGit_GTS/_workitems/edit/5942136) - Team-B toimplement.

title: Process OEM Client ID Response MSG-CLRR/CLNTDUP
description: As a user, I should be able to see the OEM Client ID/TIN which ever is received as a response from TPS customs for the MSG-CLR request sent for OEM Client ID either manually or automatically on the customer profile.
acceptance_criteria: Functional Requirement: MSG-CLRR - Response with OID if the user is not registered with customs Once the shipment found with the customer profile then update all of them with OID shipment brokerage status to CMP. The shipments downloaded after this successful Response is not required to have OID status. We need to validate the response for data segment BGMFTX+TIN++AUST BUSINESS NUMBER' FTX+CCI++CUSTOMS CLIENT ID CLNTDUP - Response with OID/TIN if the user is already registered with customs Modification is required with the existing message mapping, currently the response under this message is again mapping with OEM Client ID ONLY ( sometimes we receive TIN as the response as well then, we need to update the TIN comment). we need to validate the response for the data segment FTX+DOC If this segment has been sent with TIN, response would be DOC+TIN:::23869413369' if the segment has been sent with OEM Client ID, response would be DOC+CCI:::CGJ4763467L' This Segment need to be evaluated and if TIN is received -> map it to customer -> Comments -> TIN if OEM Client ID is received -> map it to customer -> Comments -> OID After associating the shipment with the customer profile then need to update all of them with OID shipment brokerage status to REC. Upcoming shipments should not send any more requests to customs as the response is received. The shipments downloaded after this successful Response is not required to have OID status. A declaration cannot be submitted if relevant parties are not registered with Customs. The reference user story: User Story 5975945: MSG-CLRR Response Processing for OEM Client ID Testing Scope: When MSG-CLRR response is processed, OEM Client ID received from the response should be captured on the Customer -> Comments When CLNTDUP response is processed, based on the FTX+AAO segment if TIN is received it should update Customer -> Comments -> TIN, if OEM Client ID is received should update Customer -> Comments -> OID. Even though the format is not incorrect, this should not stop the OID or TIN from getting updated because we are turning off the validation as part of the story https://tfs.Carrier Co.com/tfs/UpsProd/P07AGit_GTS/_workitems/edit/5942308. Once OEM Client ID or TIN is available then the new shipment downloaded with the same customer should not trigger any duplicate message.User Story 5975945: MSG-CLRR Response Processing for OEM Client ID

title: ROV - Bypass Validation for Customer Comments - TIN/OID - 3
description: As a user, I should be able to edit the customer comments OID and TIN if the input is wrong then the validation should be performed and stop for any unusual inputs but not for the responses received from customs.
acceptance_criteria: Functional Requirement: There are existing validations for TIN and OID. Update the validations to interactive and non-interactive mode. Interactive - perform validations Non-interactive while receiving responses, do not perform any validations. * Note : This needs no implementation because we already have the conditions implemented for IsInteractive() and we can configure this existing class using it. Technical Implementation: ValidateCustomerCommentBasedOnFormatAndLength.cs is the class implementing the validations for the customer comments. It is valid to add the interactive and non-interactive mode check in generic to all the validations in the beginning of the file. if(!commonEngine.isInterative()) { return; } 3. It is also valid in this class to verify the type TIN/OID with interactive and non interactive conditions, but it is better to implement the step 2, because non-interactive mode will never be used for other types. Testing Scope: While response is being processed, the validation should not be performed because the response is from customs. But in interactive mode, if the user is updating the TIN/OID the validation still should work and throw errors to the user if the validation fails.

title: CTS - Configure Local Lookup to decide on OEM Client ID submission
description: Local Lookup to be maintained so, user can decide whether OEM Client ID can be submitted or not based on the configuration in the Non-Interactive Mode.
acceptance_criteria: Maintain Local lookup for the auto submission AUTOOID AUTOOID LPM-I Y/N(any one value to be configured) AUTOOID LPM-X Y/N(any one value to be configured) CIDCTRAT CIDCTRAT LPM-I =|RAT=CMP,INT,HLD|CT=FML,INF|(any one value to be configured) CIDCTRAT LPM-X =|RAT=CMP,INT,HLD|CT=FML,INF|(any one value to be configured) For Local lookup create a script that inserts the configuration type with both import and export separated. 5942136_S_AU_LookupConfiguration_AutoSubmitCcid_AUTOOID.sql 5942136_S_AU_LookupConfiguration_AutoSubmitCcidOnBrokerageStatus_CIDCTRAT.sql.

title: FTS - Pre-Conditions to verify OEM Client ID Auto submission
description: OEM Client ID is something that is given by customs about the customer registration with them. If customer has no OEM Client ID we need to request one when the conditions are satisfied.
acceptance_criteria: Implement this in CommonRuleSteps. Create a RuleStep under Declaration_Initialize Rule with class name ValidateCustomsClientIdentifierSubmission.cs Add all the following Orchestration Rule Details to it [OrchestrationRuleSuggestedForRule("Declaration_Initialize")] [OrchestrationRuleDescription("Validate Conditions to submit Customs Client Identifier on Declaration Initialize")] [OrchestrationRuleDbSettings(OrchestrationRuleDbSettingsAttribute.SettingsTable.LocalLookup, "CIDCTRAT", "", "Local Lookup to configure Auto submission allowed or not")] Create an OrchestrationSettingsProperty as CommentsType (Ex: that receives input like "TIN,OID") Create an OrchestrationSettingsProperty as SearchWordsType (Ex: that receives input like "TIN,OID") Create an OrchestrationSettingsProperty as VerifyValidationRecord (Ex: that receives input like true/false.) Create an OrchestrationSettingsProperty as ShipmentBrokerageStatusType(Ex: that receives input like "OID".) Create an OrchestrationSettingsProperty as ShipmentBrokerageStatusValue(Ex: that receives input like "RFC") Validation: Fetch Local Lookup of type CIDCTRAT to fetch CT and RAT valid for OID request submission. If the result is empty skip the validation and go to next step If the result has data, then verify CT and RAT with matching brokerage status on the shipment. If valid, continue with next step if invalid do early return. Local Lookup format will be as follows. CIDCTRAT LPM-I =|RAT=CMP,INT,HLD|CT=FML,INF|(any one value to be configured) CIDCTRAT LPM-X =|RAT=CMP,INT,HLD|CT=FML,INF|(any one value to be configured) Add condition to verify Importer on Imports and Shipper on Exports for the Comments passed from Property CommentsType , if none of them is available do early return. Based on above condition, verify the customer name with the search words available under type passed from property SearchWordsType, if none of them is available do early return. Create Stored Procedure "GetCustomerValidationRecord.sql" verifies ProcessedStatusCode as 5/7. by passing Parameters, Customer OID For Property VerifyValidationRecord , If true, Use GetCustomerValidationRecord.sql to verify validation record in IBLOCTX by passing the Customer OID. if not skip the verification. All the above conditions are passed, set Custom Code passed from property ShipmentBrokerageStatusType to value passed from Property ShipmentBrokerageStatusValue.

title: FTS - Condition to verify Local Lookup with the value getting passed
description: Create a Condition class to verify the Local Lookup type passed as a property with the value that is also passed as a property.
acceptance_criteria: Add a new Condition class with name "IsLocalLookupSpecificTypeEquals.cs" - check for the existence Create Orchestration Property of type "Type" (Ex: gets the input as "AUTOOID") Create Orchestration Property of type "Value" (Ex: gets the input as any single word string). Validations: fetch Local lookup of type passed from property "Type" using locallookup.GetSpecificLocalValue(Type). Verify the value fetched in the first step passed from the property "Value" if(localLookup.GetSpecificLocalValue("Type") == Value){ return true;}else{ return false;}

title: CTS - Database script to insert Shipment Brokerage Status type OID and Values
description: As a user, I should be able to see a Brokerage Status type under shipment status of OID and the values needed under it to refer the submission status of OID request.
acceptance_criteria: Create a Database script to insert a Shipment Brokerage Status Type "OID" - Description - Customs Client Identifier Submission Reference Values: REQ - Submission Required NRQ - Submission Not Required SNT - Submission Sent ERR - Error REC - Received 5972754_S_AU_ShipmentBrokerageStatus_CID.sql

title: FTS - Auto Submit OEM Client ID message request to Customs
description: As a User, while shipments are getting downloaded, when the Shipments matches with the conditions to submit OEM Client ID, on save the MSG-CLR message should be triggered.
acceptance_criteria: Implement this in AULocalMessages Create a RuleStep AutoTriggerCustomsClientIdentifier.cs under the Rule Shipment_StoreValidationComplete Add all the following Orchestration Rule Details to it [OrchestrationRuleSuggestedForRule("Shipment_StoreValidationComplete")] [OrchestrationRuleDescription("Auto Trigger Customs Client Identifier request to customs based on conditions")] Create an Orchestration Property as ShipmentBrokerageStatusType (Ex: Value as "OID") Create an Orchestration Property as ValidSubmissionStatus (Ex: Value as "RFC") Create an Orchestration Property as PostSubmissionStatus (Ex: Value as "SNT") Validate the condition for Shipment Brokerage Status from property "ShipmentBrokerageStatusType" with Value from property "ValidSubmissionStatus" If Valid, Call message generation from this save, pick up the reference from SendCustomMessages.cs under the method CreateMessageCLREG() Message mapping should be default, when shipment -> Comment -> CCI is not there. If shipment -> Comment -> CCI is there, fields mapping should be from the CCI reference. if (declaration -> Comment -> CCI has the RoleType == "Importer"){ OEM Client ID to be submitted from Declaration.ImporterAddress;}else if (declaration -> Comment -> CCI has the RoleType == "Shipper"){ OEM Client ID to be submitted from Declaration.ShipperAddress;}else{ and so on....} Once message is triggered, insert a record in IBLOCTX transaction table using interface IProcessingTable from the same class (AutoTriggerCustomsClientIdentifier.cs) Replace the below sample code with {} with the relevant values required. processingTable.InsertNTSAData( string.Empty, string.Empty, {shipper.OID/Importer.OID}, string.Empty, 7, { Generate random GUID}, { Generate random GUID}, 0,0,string.Empty, string.Empty, true); Set Shipment Brokerage Status passed from property "ShipmentBrokerageStatusType" (OID) to the status passed from property "PostSubmissionStatus" (SNT).

title: FTS - Trigger MSG-CLR from Customs Client Identifier Custom action manually
description: MSG-CLR message for OID submission can be triggered manually from Custom action.
acceptance_criteria: Form is already developed under AUVisualsAndForms Project > CustomsClientIdentifer.cs Form has a Send Button designed, onClick() function Capture ALL the Data from the fields of the form, Then update the same to the Shipment Comment (already existing). if comment is already there, update if not there, add it. Set Shipment Brokerage Status OID to RFC To trigger the message save the shipment.

title: FTS - CLNTDUP Response Processing for OEM Client ID
description: MSG-CLRR , CLNTDUP are the response messages those are received as a response from customs for MSG-CLR request trigger.
acceptance_criteria: CLNTDUP - response is being processed from ClntdupBsisResponseHandler.cs Add Orchestration Property TimeRange (Ex: receives the data as "10" these are mins) Method GetCciData() to be modified to fetch OEM Client ID from FTX+AAO instead of DOC segment. Validations to update OID/TIN on customer: If FTX+AAO Segment data contains, TIN split the data content with "=" and map the split('=')[1] to Customer -> Comment -> TIN OEM Client ID split the data content with "=" and map the split('=')[1] to Customer -> Comment -> OID Customer should be loaded through Customer Engine, Update Comments using customer.leSetCommentText() Save the customer. Set Shipment Brokerage Status OID to CMP. (Follow the steps under "Process to Update Shipment Status") Use the Stored Procedure created in https://tfs.Carrier Co.com/tfs/UpsProd/P07AGit_GTS/_workitems/edit/5975945 using IDataQueryEngine If FTX+AAO Segment data contains Rejection in any of CLNTDUP and MSG-CLRR responses, FTX+AAO+++THIS TRANSACTION WAS REJECTED' Set Shipment Brokerage Status OID to ERR.(Check the step "Process to Update Shipment Status") Process to Update Shipment Status: Call the helper class IdentifyAndInsertRecordsForCustomerShipments.cs created from the story MSG-CLRR Response Processing for OEM Client ID Pass the Parameters as Customer OID, TimeRange, BrokerageStatusType, BrokerageStatusValue.

title: CTS - Database script to insert Search Word type OID
description: As a user, I should be able to see a new search word type in the Search Word Reference table in Admin to configure the Importer and Exporter names.
acceptance_criteria: Create a Database script to insert a Search Word Type Type "OID" - Description - Customs Client Identifier Search Words 5972754_S_AU_CustomsClientIdentiferSearchWord_CID.sql

title: Job to update Customs Client Identifier Status on Shipments before the response
description: Job to update Shipment Customs Client Identifier status to the shipments based on the OID response from customs.
acceptance_criteria: Create a RuleStep with Name RuleLookupValueForStatusUpdateStep.cs under the Rule Rule_LookupValue Job Name - AUTOOID Add the following rule information [OrchestrationRuleSuggestedForRule("Rule_LookupValue")] [OrchestrationRuleDescription("Update the shipments under the customer with the OEM Client ID status based on the Request and Response")] Capture the record using string message = IblocTxTable.Rows[0]["MESSAGE"].ToString();, Split the message with '=' string brokerageStatusType = message.split('=')[0] string brokerageStatusValue = message.split('=')[1] Then set shipment.setBrokerageStatus(brokerageStatusType, brokerageStatusValue)

title: FTS - OEM Client ID - Customs Client Identifier Customer Address Validation
description: As a user, I should be able to validate the overseas and non overseas address and populate the city/postal/state details based on Master town reference.
acceptance_criteria: Implement this in the AUVisualsAndForms. Custom action implementation is already available identified by the RuleStep name RuleCustomActionFor3000.cs. Form is available under AUVisualsAndForms identified by name CustomsClientIdentifier.cs Following is required to happen on both Individual and Organisation sections, When Role Type is selected, respective forms with Customer details by Role are populated from the Methods private void radioButton2_CheckedChanged(object sender, EventArgs e) private void radioButton1_CheckedChanged(object sender, EventArgs e) Add a condition, if(Country Code != countrySettings.ProcessingCountry) then no validation required for address. else Create a private method with name private void PopulatePostalStateAndCountryDetailsByDefault() then check for the below conditions from this private method if(selected customer by role type.postalcode != empty || (selected customer by role type.postalcode != empty && selected customer by role.city!= empty) { populate Locality/City based on postal code range provided from Master Town table reference using localAutoRef.GetRefDataView(AutoRefTypes.TYPE_MasterTown); } else if(selected customer by role.city!= empty) { populate postal code range based on Locality/City provided from Master Town table reference using localAutoRef.GetRefDataView(AutoRefTypes.TYPE_MasterTown); } else { populate What ever is available on the declaration customer address. } Master Town Table Reference:

title: FTS - Customs Client ID (OID) Application & Submission – Individual & Organisation
description: Customs Client Identifier form should populate the updated fields back to the declaration customer with some validations updated.
acceptance_criteria: Implement this in the AUVisualsAndForms. Custom action implementation is already available identified by the RuleStep name RuleCustomActionFor3000.cs. Form is available under AUVisualsAndForms identified by name CustomsClientIdentifier.cs Customs Client Identifier has two sections in the form Individual and Organization, add validations for individual form as below When Role Type is selected, respective forms with Customer details by Role are populated from the Methods private void radioButton2_CheckedChanged(object sender, EventArgs e) private void radioButton1_CheckedChanged(object sender, EventArgs e) Add Individual Section Fields Validation for the following fields ONLY: Family Name --- auto populated from Declaration > Importer > Name (Required) Address Line 1 --- auto populated from Declaration > Importer > Address line 1 (Required) Address Line 2 --- auto populated from Declaration > Importer > Address line 2 (optional) Postal Code --- auto populated from Declaration > Importer > Postal Code (Required) Make the Individual and Organisation common form changes: Change the sequence of Postal Code and Locality/Street fields on the UI. Postal Code first then Locality/City OnClick() method private void btnSend_Click(object sender, EventArgs e) along with the existing functionality,Copy the respective customer details from form to the declaration -> Importer/Shipper/Supplier based on the RoleType. if(RoleType == "Importer") { declaration.ImporterAddress.Name = lblName/txtOrgName declaration.ImporterAddress.Addr1 = lblAddressLine1/txtOrgAddressLine1; declaration.ImporterAddress.Addr2 = lblAddressLine2/txtOrgAddressLine2; declaration.ImporterAddress.City = lblCity/txtOrgCity; declaration.ImporterAddress.PostalCode = lblPostalCode/txtOrgPostalCode; declaration.ImporterAddress.State = lblState/txtOrgState)); declaration.ImporterAddress.Country = lblCountry/txtOrgCountry; etc., based on the fields available in the organisation and individual forms. } else if(RoleType == Shipper) { //Use the same format like above but instead of ImporterAddress use ShipperAddress } else if() and so on...

title: CTS - Database script to insert Country and Location codes
description: As a I should be able to see the country and location details in SBSS admin and can be used in OEM Client ID custom action screen when preparing the message
acceptance_criteria: Create a Database script to insert a country codes list for location dropdown Country Location data should be copied from below linkhttps://www.CBF.gov.au/help-and-support/TPS/integrated-cargo-system-(TPS)/software-developers/reference-materials/code-list/icao-country-codes As we need 3-character country codes, Country and Location codes so changing this configuration to customs codes. Type - ICC - ICAO Country Codes Parent Type - CU - Customer Custom code values are 3-character country codes from customs site as mentioned above. 6007403_S_AU_Country_And_Locations_CID.sql

title: FTS - Location dropdown mapping for OEM Client ID form
description: As a user, we must be able to see the location details which are mentioned in the ICAO sites for Travel documents submission
acceptance_criteria: Load the Location details for below screen will be from custom codes. Customs codes Screen Type - ICC Parent Type - CU Location codes - custom code values Location Name - custom code value description

title: LOP - MSG-CLR Inbound and Outbound message enhancements
description: While sending OEM Client ID request and response, mapping of the data should go as requested by customs only then it would be possible to process them back on the shipment or declaration if not we will end up having the rejections.
acceptance_criteria: Outbound message mapping for CRN data segment. While the inbound message is being processed, if an export is received for Shipper its okay to process, if an import is received with Importer it could also be processed, what if an export is requested for Importer which can generally happen, how to identify and process the response on the shipment?? Enhancements on the response processing approach already implemented while fetching the shipment with the help of the declaration in the existing framework. We are dealing with only OID mapping on MSG-CLRR response processing, what happens for TIN then?

title: Tech Debt - Moving below Custom Actions From Country to Common
description: Moving below Custom Action and related visual form From Country to Common
acceptance_criteria: Moving below Custom Action and related visual form From Country to Common Visual Form: CustomsClientIdentifier Custom Actions: RuleCustomActionFor3000