Booking Requirements Specification¶
Purpose And Scope Of Booking¶
Booking manages a carrier's booking number, transport schedule, planned equipment quantity, related companies and document information. Saving a booking does not by itself complete inbound, loading, dispatch, billing, or document dispatch.
The main actor is the operator who creates and edits bookings. Actual access is decided by the logged-in user's tenant and server authority. The presence of a general input screen in the reference does not mean every user of the new system has write access.
Functional Requirements And Acceptance Criteria¶
What follows is a draft requirement set for review, reconciled against the sources and the current contract. It includes open conditions and does not mean business approval or accepted completion of any item. The R numbers are traceability numbers internal to this specification. The mapping to existing command/query/SCN identifiers is in the test specification.
| Requirement | Content | Acceptance criteria |
|---|---|---|
| BKG-R01 Booking create and read | Create an identifiable booking and read it back. | The entered result has to be visible for the same tenant and the same booking. |
| BKG-R02 Input validation | Validate number, carrier, schedule, quantity and company references against the applicable contract. | Invalid input must not be stored, and the mandatory-condition difference between C1 and C2 is distinguished. |
| BKG-R03 Edit and conflict | Edit an existing booking without silently overwriting another user's latest change. | New-System compares the submitted version. Do not claim that a Legacy lock alone guarantees the same level. |
| BKG-R04 Recovery from a lost save response | When the save response is not received, check whether the save happened. | Re-read the same UUID with the submitted values. Do not assert an uncertain outcome as success or failure. |
| BKG-R05 Copy | Create 1–9 new booking headers based on the selected booking. | New-System does not create duplicates by re-running the same request. It does not copy child rows such as equipment or documents. |
| BKG-R06 Execution and document linkage | Distinguish planned quantity from actual execution, and Packing from Confirmation. | Saving a booking does not substitute for linking execution orders, allocating inventory, or dispatching documents. |
| BKG-R07 Packing edit and restore | Treat output-side edited values as distinct from the equipment source and execution pricing. | Restore undoes the output-side overwrite. Do not present it as reverting separately stored equipment information. |
| BKG-R08 Attachments and AI | Distinguish attachment storage, AI analysis, and the result of saving a booking. | Applying AI is a draft change; the booking does not change until it is explicitly saved. |
| BKG-R09 Access and visibility | The server decides the tenant and the accessible scope. | Bookings and references of another tenant must not be readable or editable. Real role verification is done separately. |
Important Per-Client Differences¶
| Item | C1 Legacy source | C2 reference source | Current New-System implementation |
|---|---|---|---|
| Required input | Booking number, carrier, Shipper, Booking type | Booking number is an explicit required field on screen | Booking number, type and carrier required. An empty Shipper list is allowed |
| Planned quantity | 5 per-size quantities | One SIZE plus one QUANTITY | 5 per-size quantities |
| Company meaning | Billing, Shipper list, terminal | Supplier, Shipper and Consignee are distinguished | Company UUID reference. The role mapping is not fixed from the reference's column names alone |
| State | Document and operation flags are separate | A stored Active/Closed coexists with date-derived display state | The migration code converts Closed to inactive. Dates are preserved separately and are not computed from submission or billing flags. This implementation is not an approved business mapping |
The real company and state mapping of the current migration path is recorded in the data specification. The requirement is not fixed by replacing the C2 reference's Supplier/Shipper/Consignee distinction with the single Shipper list of the current migration. Preserving the state date and being able to read and edit it on screen are separate acceptance conditions.
Non-Functional Requirements And Limits¶
- Tenant isolation and server authority checks follow the shared baseline.
- The public New-System identifier is a UUID, and the Inspector company reference is also passed as
inspectorCompanyUuid. - The certainty of the save response, concurrent-edit detection and atomic batch save are linked to design and tests.
- The 8-second response limit is a current implementation value, not an agreed business SLA. Exceeding the limit does not guarantee that the DB work is cancelled.
- Retention period, availability targets, personal-data classification and weight units are not fixed arbitrarily without a basis.
Source:
new-system/docs/processes/BOOKING_REQUIREMENTS.md— ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.
In this section¶
| Document | Contents |
|---|---|
| BOOKING_REQUIREMENTS | Booking Requirements Specification |
| BOOKING_STAGE_A_SOURCE_AND_DECISION_PACKET | Historical Source And Decision Packet |
| OCEAN_BOOKING_SOURCE_RECONCILED | Traditional Development Specification |
| PROCESS_RECONSTRUCTION_STANDARD | Process Reconstruction Standard |
| README | Process Documentation |