BKG 2.0: SD-2719: Remove wrong reference to TransportDocument

[HenrikHL]

User description

SD-2719: Remove wrong TD reference in ShipmentLocation description

---

PR Type

Documentation

---

Description

• Remove incorrect reference to TransportDocument from ShipmentLocation description

• Clarify that ShipmentLocation maps relationship between Shipment and Location

---

Diagram Walkthrough

flowchart LR
  A["ShipmentLocation description"] -- "remove wrong TD reference" --> B["Updated description"]

Loading

File Walkthrough

	Relevant files
Documentation	BKG_v2.0.4.yaml Remove TransportDocument reference from ShipmentLocation  bkg/v2/BKG_v2.0.4.yaml Removed incorrect reference to "Transport Document" from ShipmentLocation schema description Simplified description to focus on the relationship between Shipment and Location entities Maintained all other schema properties and conditions unchanged +1/-1

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🔴	None Description: No security vulnerabilities introduced by this documentation-only change. BKG_v2.0.4.yaml [5065-5071] Referred Code description: | Maps the relationship between `Shipment` and `Location`, e.g., the `Place of Receipt` and the `Place of Delivery` for a specific shipment. **Condition:** In case `routingReference` is provided - then `PRE` (Place of Receipt), `POL` (Port of Loading), `POD` (Port of Discharge) and `PDE` (Place of Delivery) MUST not be provided. properties: location: $ref: '#/components/schemas/Location'
Ticket Compliance
🟡	🎫 #SD-2719 🟢 Remove the sentence stating that ShipmentLocation is reusable between Booking and Transport Document in the API schema/documentation. Ensure the ShipmentLocation description clearly reflects only the relationship between Shipment and Location. ⚪ Verify rendered API documentation no longer shows the removed TD reference in all published targets (e.g., generated site/portal).
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: No runtime code: The PR only updates a schema description line and introduces no executable logic where audit trail requirements could be assessed. Referred Code description: | Maps the relationship between `Shipment` and `Location`, e.g., the `Place of Receipt` and the `Place of Delivery` for a specific shipment. **Condition:** In case `routingReference` is provided - then `PRE` (Place of Receipt), `POL` (Port of Loading), `POD` (Port of Discharge) and `PDE` (Place of Delivery) MUST not be provided. properties: Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: No error paths: The change is limited to a documentation description in the schema and adds no error handling code to evaluate. Referred Code description: | Maps the relationship between `Shipment` and `Location`, e.g., the `Place of Receipt` and the `Place of Delivery` for a specific shipment. **Condition:** In case `routingReference` is provided - then `PRE` (Place of Receipt), `POL` (Port of Loading), `POD` (Port of Discharge) and `PDE` (Place of Delivery) MUST not be provided. properties: Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Documentation-only: The PR only adjusts a description string in the schema and contains no input validation or data handling logic to assess. Referred Code description: | Maps the relationship between `Shipment` and `Location`, e.g., the `Place of Receipt` and the `Place of Delivery` for a specific shipment. **Condition:** In case `routingReference` is provided - then `PRE` (Place of Receipt), `POL` (Port of Loading), `POD` (Port of Discharge) and `PDE` (Place of Delivery) MUST not be provided. properties: Learn more about managing compliance generic rules or creating your own custom rules
Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

No code suggestions found for the PR.