Booking Acceptance Tests and Requirements Traceability¶
Evidence Levels for Tests¶
Source comparison verifies the implementation. Model tests verify contracts such as failure and concurrent modification. Real DB tests verify storage, constraints and concurrent execution, and real screen tests verify roles, operation and result display. They do not substitute for each other.
The related execution results of 2026-09-12 are 38 Web contract, 42 DB model and 27 document structure PASS. These numbers do not mean that all the business acceptance below is complete. Past PASS from other Tasks apply only to the revision, environment and role of that time.
Requirement → Design → Test¶
| Requirement | Design / data link | Test conditions and expected result | Current evidence / remaining checks |
|---|---|---|---|
| BKG-R01 | Header creation, UUID, tenant | Query the same UUID after creation, input values match | Local C2 admin2 creation, re-open and DB header/schedule check PASS. Other roles, all fields NOT_RUN |
| BKG-R02 | Data dictionary, input contract | Reject missing required values, wrong quantities and unknown keys before writing | Common parser and route regression for the 7 string boundaries PASS. Real C2 Vessel 51-char rejection and 50-char storage PASS; other field UI, C1, reference NOT_RUN |
| BKG-R03 | Single/multiple edit screen contract·version comparison·batch transaction | Reject stale versions, full rollback on mid-way failure. Single re-read replaces the draft, multiple re-read keeps the draft | PASS for single/multiple stale conflicts, full batch rollback and saving after re-reading the latest version, with local C2 UI and controlled API modifications. Concurrent sessions with different user roles are NOT_RUN |
| BKG-R04 | Recovery flow | Handle match, mismatch, read failure and a new UUID that does not exist separately | PASS for recovery with a single lost successful C2 PATCH response injected, then GET re-read, with no duplicate write. Other failure combinations are the booking-workspace-recovery model, and real acceptance is separate |
| BKG-R05 | Clone receipt, atomic batch | Replay of the same request, conflict on a changed request, mid-way failure and lost response | PASS for local C2 single clone, draft preservation and header/receipt/relations, and for the identical request and changed 409 of UI Retry Clone. PASS for header clone, empty Packing, original invariance and cleanup on an original with 11 Sales back-references. Non-empty direct Sales pointers, DB mid-way failures and lost commit responses are NOT_RUN; the Legacy MK callback difference is unresolved |
| BKG-R06 | Execution order relations, document boundary | Multiple execution links, and company roles and display state are not merged incorrectly | PASS for the real original with Sales11, Invoice12/Consignee1 against 0 on the clone and unchanged back-references. PASS that the company and address in the current Invoice/Email match the execution Sales/API and that the full GET is unchanged. The meaning of the three roles in reference is confirmed; company role recovery is BLOCKED pending approval to add two document UUID columns, and storage/migration/output acceptance is NOT_RUN |
| BKG-R07 | Packing input and storage boundary·original·overlay·unit price | Reject a stale original, keep the equipment original after restore, modify only the selected unit price. Distinguish output temporary values from DB storage | PASS for the current C2 empty/linked Packing query, selection, unit, mode and address height. Editing/recovery/output of NS3-112 REC03C reuses past evidence within the source comparison scope below. Current permissions, settings, change UI and real Excel/physical printing are separate |
| BKG-R08 | File relations, AI draft | Reject invalid input, preserve when the relation is uncertain, analysis does not write | booking-files/booking-instruction-reader. Real provider NOT_RUN |
| BKG-R09 | Session, permissions, tenant | Reject requests for another tenant or without permission | PASS for local C2 Administrator and Office Manager: own 200, real C1 detail/Packing 404, error screen with 0 inputs and disabled commands. admin2 cannot substitute the query tenant and anonymous is 401; PASS for Office Manager menu/detail/Packing read and unchanged full GET. Roles 3-6, per-role writes and writes to another tenant are NOT_RUN |
Existing identifier links¶
| Spec requirement | Existing command / process / scenario |
|---|---|
| R01·R02 | command.transportation.create-ocean-booking-draft; SCN-057/058 |
| R03·R04 | command.transportation.update-ocean-booking-details; SCN-058 |
| R05 | command.transportation.clone-ocean-booking; SCN-050/058 |
| R06 | process.fulfillment.booking-linkage; process.transport.ocean-booking; SCN-100 |
| R07 | SCN-030/100; semantic-booking-packing contract |
| R08 | SCN-055/056/058 |
| R09 | query.read-models.get-ocean-booking-workspace; SCN-010/100 |
Recording conditions for real acceptance tests¶
When running, record the revision, environment, role, effective profile, fixture, operations performed, the re-read of the stored result and the cleanup result. Do not claim business completion from the login screen or HTTP200 alone. Full acceptance is currently not complete.
Open items¶
- The current migration of C2 reference storage Closed → NOT_IN_USE=1 is confirmed. The C2 query, filter and sort of the date-derived Status are recovered and verified. Dates and the native submit/invoice flags are separate, and no automatic mapping or bulk correction is approved.
- The Supplier → native Shipper list link and the report of actually unmapped Shipper/Consignee were confirmed. A mapping that preserves role meaning and verification of the impact on re-migration remain.
- Local DB string widths, enums and keys were checked in the data design document. The 7 string widths were fixed and retested. The later real options include Seal None but the DB enum does not, and the parser also accepts arbitrary enum strings, decimals and values over the int limit. This is a source/schema conflict confirmation and real storage reproduction is NOT_RUN. The weight unit, the required precision and the scope of schema change remain.
- The common Booking editor of Legacy clone calls onSaved({}). A normal list re-reads, but an MK list rejects because of missing ID/DETAIL, confirmed by running the original callback in isolation. The popup/modern router only delivers the result to the existing callback and does not create the missing ID/DETAIL, and the Client2 legacy-editor branch is distinguished. Native re-reads the list after success and keeps the parent draft. Interface evidence and effect of Sales pointers on Packing were compared. The real result of native clone with mode-specific Legacy execution and linked pointers is NOT_RUN.
- Current per-role screen, DB, printing, file and provider acceptance must be performed.
- Requirements, design, data and test specifications for business areas other than Booking are the next extension target.
Draft test manual for Client 2 — operating usage not confirmed¶
This section is a procedure for real C2 verification and is not a published user manual. Execution results are recorded in the separate table below, and every other condition is NOT_RUN. The C1 technical specification is kept, but this draft is not used as a C1 operating procedure.
Preparation: first check the local http://localhost:3000 and the real tenant/role/effective profile of the Client 2 account. Record the revision at execution time and the related uncommitted files, the source the service is running, the DB identity, the test record UUID and unique number, and the cleanup scope. Do not put account secrets or customer data into the evidence. Before writing, check the target DB and fixture scope, and do not modify real customer records in their place.
| Step | Action the tester performs | Storage / follow-up effect check / pass condition |
|---|---|---|
| 1. Entry, query | Filter the Booking list by the test number and open the existing test booking. | The Client 2 context matches the queried UUID. A missing booking, a permission rejection and a communication failure are not confused with an empty list. |
| 2. New creation | In the list's Create → Details, enter a unique Booking #, EXPORT/IMPORT, Shipping Line, the schedule, the quantity by specification and the allowed company → Create Booking. | Do not rely on the success message alone; re-query the list and open the same UUID again. Compare the entered fields, schedule, company, quantity and initial version against the DB and query response. Do not conclude from the header creation alone that Delivery, equipment, stock or billing exist. |
| 3. Edit, close | Change the Remark, schedule and quantity of the same test booking → Submit → open again. Then close with a changed value and check the discard warning. | The saved values and the increased version match. Values discarded without saving must not be in the DB. If re-saving the schedule moves the times, that is a defect. |
| 4. Multiple edit, conflict | Change only one field of two test bookings. Change one booking by a separate request, then edit it from the stale screen. | Fields and rows not selected are preserved. On a row conflict nothing is partially saved. Reload selected rows in multiple edit keeps the draft, while Reload latest in single edit replaces the draft with the server value. Also check the re-read version. |
| 5. Clone | In Clone of the saved test booking, select quantity 1 or 2. Also check the case where the parent has unsaved changes. | It appears in the list with a different new UUID and number. It does not save or overwrite the parent's unsaved draft. Distinguish header clone from copying the Sales, execution, file and Packing originals, and re-read the relations. Quantity 0/10, duplicate resend and lost response are checked in separate controlled tests. |
| 6. Packing, Confirmation | First query the Container, unit and Invoice/Email display. Perform writes only on approved test originals: after changing the unit price, leave the field to save and re-query, and change the address and Amount output temporary values separately. By policy Confirmation is compared against the saved header. | Check that only the original unit price changed and that the address/Amount temporary values are not in the DB. Check that Refresh preview keeps the temporary values and Reload source discards them. Leave separate execution results for restore, conflict, uncertain unit price handling and output file/print content. Do not run physical printing or external delivery without separate effect approval. |
| 7. Input boundary | Test just below, at and over the column widths in the data design document, values outside the enum and fractional weights. | There must be an explicit rejection before writing, or a lossless approved storage. Record silent truncation, value loss after a success indication and internal SQL errors as defects, and fix and re-verify them in the NS3-112 REC03A write path. |
| 8. Cleanup, finalize | Compare the created test UUIDs and relations and clean up only approved fixtures. Record the result and the cleanup readback. | Do not hide leftover test data, failures or unexecuted steps. Reflect only the procedures that passed into the C2 user manual, and publication and Production are a separate approval scope. |
The Photos/EIR, Create Empty and Direct Move procedures of the current generic Booking manual are not copied as usage for the current native Booking screen. Native has no Photos tab, and the existence of the related legacy APIs alone cannot approve a screen procedure. This time the existing C1/C2 manuals, overrides and read permissions were not changed.
Client 2 local execution results — 2026-09-12¶
Environment: the existing localhost:3000 service, a new Ego space 4 for this session, admin2 / Client 2 / trade-inventory. The local DB is 127.0.0.1:3306, kyle-mba / prod / MySQL8.4.8. The source is this Task's parser/transport change after 4d846b6, which was later included in 2a8c69052 from other Git work. Because the screen was restarted by another session's development update, this is not a result of accepting the whole service at a fixed single revision.
| Execution | Verdict | Actual result and limits |
|---|---|---|
| Menu, creation, re-open | PASS | Created a new header under Shipping > Booking and re-opened it with the same UUID. UI/DB match for Vessel 50 chars, carrier TEST, Shipper selection, 40H quantity 2, Regular, ERD 9/12 and cutoff 9/30. This is not business approval of the real company role nor a test of all fields |
| Over-length | PASS | Reproduced the pre-fix Vessel 51-char PATCH503 and the uncertain-result indication, and confirmed the original and version were unchanged. After the fix, a new 51-char entry returns 400 INVALID_REQUEST with the 50-char maximum explanation and no DB row is created. The common parser checks just below, at and over the boundary for the 7 fields of create/update/clone/Multi Edit as a model |
| Single edit | PASS | After changing the Remark, version 0→1; confirmed the existing vessel, schedule, quantity and company are preserved. Conflict/lost response and the later read-only discard are confirmed separately with the separate fixture below |
| Single clone | PASS | The 200 response of Clone quantity1 has a new UUID, number and version. The parent's unsaved Vessel stays on screen and is not stored in the DB. All stored columns of the original and the clone are identical except ID, UUID, number and created/updated timestamps; 1 clone receipt, 12 relation types at 0 |
| Confirmation query | PASS | The preview shows the saved vessel 50 chars, schedule and 2x40H, not an unsaved draft. Print, external delivery and Packing edits are NOT_RUN |
| Cleanup | PASS | After cleaning up the 1 test header of the first failure reproduction, the 2 retest headers and 1 clone receipt were compared by exact UUID, number, tenant, version and 0 relations, backed up and removed. 0 remaining. No change to existing business data, schema or settings |
The retest original UUID is 01a095cc-3a02-77f2-9424-5b0ade0d2160 and the clone is 01a095cf-4f1e-73dd-9aef-feba59553a4d. The request and response, the original backup and cleanup, and the preview evidence are in .generated/acceptance/NS4-017/booking-boundary-runtime.json, booking-fixture.json, booking-fixture-retest.json, booking-clone-runtime.json and booking-confirmation-runtime.json. The post-fix 400 was confirmed by the actual execution output and a DB re-read of 0, and a separate response file could not be kept. The absence of an output file is not presented as stored network evidence.
In the date test, the automated date fill alone did not update the React input value. Saving and re-opening were checked after real arrow key/Tab input, and this is not judged a product date defect. When the development screen restarted during a successful creation, the DB/UUID was read first so nothing was created twice.
The follow-up conflict test was run with the same local account and space, at 476fa734, with a 1-row edit in this Task's common MultiEditDialog. The two NS4-017-260912-C71F headers were prepared by creation/clone through the existing API and are not counted as a creation UI retest.
| Execution | Verdict | Actual result |
|---|---|---|
| Multiple edit conflict and recovery | PASS | Reproduced the defect that a 409 CONFLICT before the fix has no re-read button. Only the relevant code was added to the common stale branch. After the fix, Reload selected rows appears → the draft is kept → retry at the latest 0/2 versions gives 200 → versions 1/3. All stored columns other than Remark are unchanged except the version and updated timestamp |
| Prevention of partial save | PASS | The batch fails on the stale version of the second row in UUID order. The Remark and version of the preceding row were also restored, and only the existing single change is kept |
| Single edit conflict | PASS | With the screen draft and version 1 in place, the server was changed to 2. Submit 409, the draft is kept and Submit is disabled. Reload latest replaces the draft with the server value; no unsaved draft in the DB |
| Lost success response | PASS | Only the single successful PATCH200 response of the same test UUID was lost in the browser. The message confirming storage is shown through an actual GET200, PATCH once/GET once, and only the version increased 2→3. The wrapper was restored |
| Discard warning | NOT_RUN | The display of the "Discard unsaved Booking changes?" dialog was observed. The dismiss response was false and the later observation timed out with No dialog is showing, so cancel and discard completion could not be proven. Recovery was done by reloading the same page and no DB change was confirmed |
| Empty Packing | PASS | "No linked packing rows" with a total of 0; the original Booking#/vessel name was confirmed from the input element values. Since the input values are not in innerText, the first wait timeout is not judged a product preview failure. No edit or output |
| Follow-up fixture cleanup | PASS | The original/clone 2 rows and receipt 1 row were compared exactly, backed up and removed; 12 relation types at 0 and 0 remaining |
Follow-up discard re-verification PASS — 2026-09-12T15:10Z, in the same local admin2/C2 and space 4, only the Remark of the existing CALB779085 was changed as a screen draft. Cancelling the "Discard unsaved Booking changes?" prompt on Close kept Edit Booking and the entered draft, and approving it after Close again closed the window and returned to the list. The Remark in the actual GET200 before and after was identical as an empty value and version 1. The draft was discarded without any Submit/API change or fixture creation, and this check is an API readback of the saved header, not a direct SQL query. The evidence is .generated/acceptance/NS4-017/booking-discard-runtime.json.
The C71F NOT_RUN in the previous table is preserved as the result of that time. This time as well there was a dismiss=false and page response/reload timeout when responding to the dialog in the next tool call, but only my own p1 was closed, and in p2 of the same space 4 the click and the dismiss/accept were handled within the same call, so both results were actually confirmed. No other session or personal space was touched. Other roles, refresh/page navigation and all unsaved paths of Packing and Confirmation are not accepted by this test.
The follow-up UUIDs are 01a095dd-6690-768f-9ab2-7433a812c91a and 01a095dd-6691-7dce-9eb0-644f38b78352. booking-multi-conflict-before.json, booking-multi-conflict-after.json, booking-single-conflict.json, booking-lost-ack.json, booking-empty-packing.json and booking-fixture-conflict.json in the same evidence folder are the actual evidence. The common component handler regression is 1 CONFLICT failure with the 2 existing codes passing before the fix, and 3 passing after the fix, and is kept separate from actual browser/DB results.
Scope of reuse of past Packing evidence¶
The 2026-09-08 local C1/C2 real execution of NS3-112 REC03C and commit 525d0d15c for the inline form were compared with the current 476fa734 and the working tree. The C2 tenant at that time is the same as in the current test, and the original row and cleanup records remain. Past execution is not labelled as having been run again today.
| Scope | Comparison result | Reuse and remainder |
|---|---|---|
| Packing source, overlay, restore | transportation/src/packing.ts, db-mysql/src/packing.ts, semanticBookingPackingRoutes.ts are identical in full | Past evidence is reused for original selection, row/batch save, conflict, restore and lost response. Even then, real fault injection of cross-owner Legacy concurrent writes is NOT_RUN |
| Packing/Invoice/Confirmation renderers | The documents/src/public.ts file changed, but the Booking renderer and 17 helper declarations are identical | Past basis is reused for the CTC/MK form, selection/unit, groups and output draft. A change in other document functions is not treated as the whole Booking being stale |
| Invoice unit price storage | The SELECT * of updateFulfillmentItemRates changed to explicit Order 6 columns/OI 11 columns; the hash/CAS/RATE-only conditions and claimFulfillmentVersion are identical | The existing failure/recovery basis is reused. Current real unit price storage is PASS for UI blur, changing only the 2 original OI rows, preserving everything and cleanup on the new 12-row fixture |
| Screen, route, company info | PackingPanel removed the Cancel button of Restore; the model changed to /api/bookings. The logo default in the company profile and the common auth/screen source changed | Previous screenshots are not promoted to current appearance/permission acceptance. The current empty Packing query was confirmed, but the current screen of a linked original, closing restore and company info are checked separately |
The PASS from re-running the past original verifier packing-inline-assertions.mjs is a consistency check of stored evidence. It checks the row save and draft preservation of that time, rate loss recovery, escaped static output, groups/units, Wiki images and 0 fixture cleanup, and is not a DB write of today. It is kept separate from the current focused Packing/document/UI 34 and DB model 18 PASS. The evidence is in .generated/acceptance/NS3-112/recovery-2026-09-08/ and includes packing-inline-final-readback.json, invoice-inline-final-readback.json, each cleanup and packing-inline-wiki.json. Real Excel download, physical printing, Production and C2 DB manual publication are still NOT_RUN.
The 2026-09-12 follow-up current query was performed read-only on the existing business booking 019fd150-9934-7c32-8537-dab69562fd0a in the same space 4/admin2/C2. Input, unit price blur, save, restore and submit were not run.
| Execution | Verdict | Actual result and limits |
|---|---|---|
| Linked Packing query, selection, unit | PASS | The full 11 containers/12 items, MT219.694. Selecting one container gives 2 items MT22.270/LB49,096. In Email the Invoice area is hidden, and returning to Invoice shows both documents. The observed Booking requests are GET only |
| Original re-query | PASS | The selected rows have no EQC so the two T_LOAD_ITEM items are used. The actual NET_WEIGHT total of 49,096, quantity 0 and RATE 0 match the API and screen. The displayed amount 0 corresponds to the unit price 0 of this data and does not mean the billing work is complete |
| Mode switch address truncation | PASS | Before the fix, in Email→Invoice the two lines of Shipping To/Invoice To were truncated at height 20 with 32 needed. After moving the display switch of the existing syncDocument before the height calculation, 32/32 was confirmed on the same screen. The source order regression is red 1→green 2. No change to storage, form or CSS |
| Re-capture and download after access recovery | PASS | The initial 403 was resolved in the 14:48Z re-check below. Confirmed tms.booking ENABLED and Packing 200 for the same admin2/C2, both addresses 32/32 for the same container/LB/Email→Invoice and 2 captures after the fix. Export Excel actual download 8,316bytes, 2 selected items/Invoice 2 rows with a total of 49,096, 0 input controls, 0 scripts and no unselected containers. Real Excel app compatibility and physical printing are NOT_RUN |
The evidence is .generated/acceptance/NS4-017/packing-current-readonly.json and packing-current-readonly.png. The height after the fix is a value confirmed from actual tool output and is not replaced by a later new capture. The current 4 Packing-related files, 25 tests and the Web types are PASS. The one Commercial Confirmation failure of the full document test run together with it failed because of another writer's change, and the PackingPanel lint 1 error/3 warnings are reproduced on the pre-fix HEAD as well. No unrelated renderer/effect rewrite was done to remove them. This record is not a PASS of full Booking acceptance for the current account.
At 2026-09-12T14:30:23Z, at 8b0713c96 the session 200, tms.booking NOT_ENTITLED and Packing 403 FORBIDDEN of the same space 4/admin2/C2 were reconfirmed, but this access blocker was resolved at 14:48Z. No other session was stopped and no permission was changed, and the screen specification was reconciled independently. The 403 of that time is preserved as a historical result and is not repeatedly reported as a current access failure.
After access recovery, Email→Invoice was performed using the existing Booking/container as is. The two lines of Shipping To and Invoice To are each clientHeight32/scrollHeight32, and after saving packing-current-fixed-shipping.png and packing-current-fixed-invoice.png the actual images were checked. packing-list-CALB779085.xls is the serialized HTML of the current document, and parsing the file body confirmed the selected containers/items, the total and the removal of scripts and form elements. It is not evidence of being opened in the Excel application or of producing .xlsx. All 4 observed Booking requests are GET200 with 0 mutations, and the observation wrapper was restored. That scope is recorded in .generated/acceptance/NS4-017/packing-current-output.json, and source/rate/Submit/Restore/physical Print were not run. It proves only the recovery of the same account and is not extended to full role acceptance.
Clone retry real execution — 2026-09-13¶
It was performed with source 8b0713c96, local kyle-mba:3306/prod, and admin2/C2 in space 4/p2. The test original NS4-017-260913-R3C1 with no references was created through the real authenticated API, and this is not a creation UI retest. It is a test that hid only one response in the browser after the Clone POST of that original succeeded. It is distinguished from a test that injects a lost response or a mid-way failure of the DB commit itself.
| Boundary | Verdict | Actual result |
|---|---|---|
| Lost success response | PASS | UI Clone quantity1 shows the result-not-confirmed notice and Retry Clone after the server 200 stored 1 new header and 1 receipt. Quantity 1 change is disabled and the Clone window is kept |
| UI retry | PASS | Retry Clone sends the same requestUuid, bookingUuids and empty overrides. The UUID, number and version of the 200 are identical to the first result. Only the Clone window is closed and the parent edit window is kept |
| Changed request | PASS | Changing only the remark override on the same requestUuid returns 409 CONFLICT, The Clone request changed. Start a new request. |
| Same request replay | PASS | Sending the original payload again gives 200 and the same result. The observed POST statuses are 200/200/409/200 and the observation wrapper was restored |
| Storage invariance | PASS | After the first clone and in the final re-query, all stored columns of the original/clone and the whole receipt are identical. All 2 rows/receipt 1 row/24 relation checks are 0 |
| Test cleanup | PASS | After confirming the exact UUID, number, tenant, version and backup/0 relations, the 2 test header rows and 1 receipt row were removed with 0 remaining. No change to existing business data |
The original UUID is 01a09632-6fb6-79c8-a716-1926c5c235cf, the clone is 01a09633-f5cc-761d-99a0-af523cd212c1 and requestUuid is 01a09633-f5cc-7507-b4dc-9b6c776e52c0. The execution summary is .generated/acceptance/NS4-017/booking-clone-retry-runtime.json, and the full DB backup, comparison and cleanup are in booking-fixture-clone-retry.json. Since it was not confirmed that the new row appears in the current list filter, this is not extended to list display acceptance. Linked Sales/equipment/files, other roles, quantities 2-9 and real DB mid-way failures are NOT_RUN.
Document status list real execution — 2026-09-13¶
Scope: qa8b0713c96 and the current list change, local 3000/MySQL8.4.8, admin2/C2/tenant019dd494-6e47-72c9-96bf-d250dc575a75, my own space 4/p2, desktop 1680×922. Existing business rows were only queried and there are no changes to DB, accounts, permissions or deployment.
| Check | Result | Evidence and boundary |
|---|---|---|
| Regression | PASS | The 3 new cases pass as expected failures, and the existing list/profile/two DB query paths and rendering give 30 PASS. SQL is also verified with fixed values for 8 date combinations, omitted old groups and active false, for COMPLETED, the exact filter, tenant/count/page/tie-break and unknown values. It is a model, not the full set of real DB tests |
| Strict date SQL | PASS | The first real four-status query returned 503. ER_WRONG_VALUE was reproduced with a local SELECT by comparing DATE with a zero-date string, the success of comparing the number 0 was confirmed, and the common SQL was fixed. The re-queried four statuses return 200. No change to DB settings or data |
| Real query per status | PASS | PENDING290/SI-PENDING0/AR-PENDING1/COMPLETED2992. The dates of up to 5 rows of each non-empty status were compared with the display calculation. There are no real SI-PENDING rows so only the empty status is verified; the temporary date batch is the follow-up |
| Real filter/display | PASS | Clear the date range and Refresh → select Status AR-PENDING → DALA92919800 gives one row/1-1 of1, the filter chip and the AR-PENDING display. The API of the same row with BL2026-02-02 and AR null was compared. booking-document-status.png was checked directly |
| Real sorting | PASS | After removing the filter, the first 10 rows in ascending order are AR-PENDING1+COMPLETED9, and PENDING10 in descending order, compared with aria-sort. The first tool-centre click failed because the th was hidden, but clicking the observed icon position gave asc and the keyboard Enter gave desc. booking-document-status-sorted.png was checked directly |
| Types/lint | PASS | Web and DB TypeScript, and ESLint on the 6 ordinary source files of this change. This does not mean the existing clone any error of the earlier date unit was fixed |
Verified C2 usage: open the filter of the Status column in the list, select a status and press Apply. Clear the status condition with All/Remove. A date range, if present, is applied together. Status sorting is by display string and is not sorting by business stage. Even if the display is COMPLETED it does not mean billing or submission is complete. The date batch was verified in the follow-up unit below, and new DB manual publication, other roles and small screens are NOT_RUN.
Document date multiple edit real execution — 2026-09-13¶
It was performed with the same qa8b0713c96 and current date/list source, admin2/C2 on local 3000/MySQL8.4.8, space 4/p2, 1680×922. Only the two dedicated NS4-017-260913-DTB1/-1 headers were created, changed and cleaned up. The initial dates were all null for A and BL2026-09-02 for B, and the remarks/vessels were different.
| Execution | Result | Actual storage and screen comparison |
|---|---|---|
| First observation attempt | Excluded from acceptance | My observation wrapper lost the Window receiver of fetch and Illegal invocation occurred. The UI showed No server response and both API/SQL versions stayed 0. The tool cause was reproduced with a read-only GET, the wrapper was restored and the attempt was retried after Reload and review rows. It is not counted as a product defect or a successful save |
| SI Date Set | PASS | Select two rows → Edit(2) → Add field SI Date → 2027-09-01 → Apply. Both versions 1, A SI-PENDING/B AR-PENDING. B's BL2026-09-02 is preserved |
| AR Date Set | PASS | Two rows AR2027-09-03, version 2 and both COMPLETED. Existing SI/BL kept |
| BL Date Set | PASS | Two rows BL2027-09-02, version 3. A is new and B is changed from the existing value, SI/AR are kept and COMPLETED is kept |
| Clear three dates | PASS | Select the Action of each date as Clear value → Apply to 2 rows. Both versions 4, all 3 dates null and both PENDING |
| All values and follow-up effect | PASS | In the first/failed/each saved snapshot all DB columns are identical except the 3 dates, ROW_VERSION and UPDATED_AT. flags stay false, the 24 relation checks are 0 and receipt is 0 |
| Cleanup | PASS | After comparing the exact UUID/number/tenant/version and backup, only the two headers were removed with 0 remaining. After confirming Refresh0-0 of0 in the list, the test number filter was cleared. The backup booking-fixture-date-batch.json is kept |
The actual React values and stored values were compared using the native keyboard on the existing normal date input. The screens checked directly are booking-date-batch-si.png, booking-date-batch-clear-draft.png and booking-date-batch-cleared.png, and the execution summary is booking-date-batch-runtime.json. No observation wrapper, open edit window or test row remains. This unit verified the existing date batch for real without Product code change, and date Clone override, other roles and small screens are NOT_RUN.
Document date clone real execution — 2026-09-13¶
It was performed with baseline 8b0713c96 and the existing date recovery diff, with admin2/C2 and space 4/p2 on local kyle-mba:3306/prod. The DCL1 original with three dates was created through the API and opened in the screen under the Shipping > Booking menu. Since the Clone window only takes a quantity, it distinguishes preservation by UI clone from partial date override via the API.
| Boundary | Verdict | Actual result |
|---|---|---|
| UI Quantity1 clone | PASS | The original SI2026-09-01/BL09-02/AR09-03 is preserved on -1. A new number appears in the list and reopening it confirms the three date values match. Original and clone versions are 0 and both rendered Status are COMPLETED |
| API partial override | PASS | Creates -2 with only SI2026-09-04 and AR null specified. BL2026-09-02 and the other header values are preserved, version 0. The dates in the screen actually reopened and the rendered list AR-PENDING match |
| Resend and rejection | PASS | The same request gives 200 with the same UUID, number and version. An SI change on the same request ID is 409 CONFLICT and a non-existent 2026-02-29 is 400 INVALID_REQUEST. The three headers and two receipts are entirely identical immediately before and after |
| Original and other columns | PASS | The whole original row is unchanged after the first creation. The UI clone is identical except the identifier, number and created/updated timestamps. The API clone additionally changes only SI/AR, and the remaining columns including BL, Invoice number and flags are identical. All 12 relation types × 3 rows = 36 checks are 0 |
| Cleanup | PASS | After comparing the exact number, UUID, tenant, version and full backup, the 3 test booking rows and 2 receipt rows were removed with 0 remaining. After the actual list Refresh0-0 of0, the test number filter was cleared. No modal, observer or test data remains |
The original is 01a0967f-7167-792d-a9ab-11a1f07fddf3, the UI clone is 01a09681-99d8-72ca-9c10-f81d00e182e7 and the API clone is 01a0967f-7168-7262-bec6-c3c61e6801f0. The numbers are NS4-017-260913-DCL1 and -1/-2. .generated/acceptance/NS4-017/booking-fixture-date-clone.json is the full backup and cleanup, and booking-date-clone-runtime.json is the execution summary, not a raw network trace. The two screenshots booking-date-clone-ui.png/booking-date-clone-override.png were checked directly. The first stale button ref failure was a tool error before the action, and it was continued in the same space with a new snapshot/semantic selector. There was no new Product modification, observation wrapper or lost response injection.
Linked Sales, quantities 2-9, other roles, small screens, DB mid-way failures/lost commit responses and Wiki DB publication are a separate NOT_RUN. The unverified Clone marking of the earlier date unit below is supplemented by this follow-up result, but the evidence of that time is not retroactively changed.
Document date real execution — 2026-09-13¶
It was performed with 8b0713c96 and this date recovery diff, in local space 4/p2 with admin2/C2. The existing CALB779085 was only queried in SQL/API/the actual screen for SI and BL null, AR2019-01-23, version 1 and not submitted/not invoiced. Only the new NS4-017-260913-DATE1 UUID 01a09647-585f-71cf-a569-baa5879a666a was used as a write target.
| Boundary | Verdict | Actual result |
|---|---|---|
| Date creation | PASS | Creation with SI2026-09-01/BL09-02/AR09-03 through the existing authenticated API gave 200 and version 0. Of the 8 date inputs on the actual screen, values are shown on the 3 document dates. This is not a creation UI retest |
| Date edit and clearing | PASS | With native keyboard input, SI2027-09-01, BL empty value, AR2027-09-03, and the real PATCH200 of Submit, the same stored values and version 1→2. Reopening confirms the three values match |
| Input error | PASS | A date with only part of it cleared is rejected by the browser badInput before Submit and PATCH is 0. 2026-02-29 in the API is also 400 INVALID_REQUEST with version 2 unchanged |
| Previous request compatibility | PASS | A remark PATCH without documentDates gives 200 and version 2→3, with the dates/flags kept. A missing date in a previous request is not clearing the date |
| SQL/cleanup | PASS | The API and SQL dates match. In the initial/final full columns there are 0 changes except the date, remark and version/updated timestamp, and 12 relation types are 0. The 1 test row was backed up exactly, compared, removed with 0 remaining, and 0 receipts were created |
The first automatic fill only changed the DOM value, and the React display and request kept the previous dates. The PATCH200 and version 0→1 at that point are not evidence of a successful edit and are recorded separately. Without arbitrarily modifying the common input, the display and request change was confirmed with the real keyboard and then the save above was performed. The observation wrapper was restored. The evidence is .generated/acceptance/NS4-017/booking-document-dates-runtime.json, booking-fixture-document-dates.json and the directly checked booking-document-dates-saved.png.
The source/model tests are parser/route, UI rendering and recovery 24, and DB create/clone 26 PASS, and the date batch and list progress display were verified for real in the follow-up units above. Date Clone override, other roles and small screens are NOT_RUN. Seal storage conflict, company role recovery and C2 DB manual publication are separate remaining items.
Booking clone with Sales back-references real execution — 2026-09-13¶
It was performed with the baseline 8b0713c96 of 2026-09-13 and the existing clone/Packing source, on local kyle-mba:3306/prod8.4.8, admin2/C2 and space 4/p2. The original of CALB779085 was not changed, and after creating one API clone with only the number overridden to NS4-017-260913-LSC1 the new booking and Packing were opened in the actual list. UI Clone has no number override input.
| Actual result | Status | Evidence |
|---|---|---|
| Original links | PASS | Booking ID66751/version 1 has Sales11, 12 order items, equipment load 11 and equipment 11. Packing GET200/11 rows, Invoice 12 rows, Consignee 1 and PO MK-SALES-20~30 |
| Clone header | PASS | clone200, UUID01a0969d-6aee-7216-a419-1080ae70f400, version 1. 57 columns are identical to the original except identity/number, created/updated timestamps and the 6 generated columns. Dates/flags, Invoice and quantity 11 are preserved |
| Actual follow-up screen | PASS | Number filter 1-1 of1 → new header/dates → Packing. The Container selection offers only All containers, and the document shows No linked packing rows. and a total of 0. API rows/Invoice items/Consignee 0 and empty PO values, and the list actual/planned quantity is 0/11 |
| Original invariance and clone relations | PASS | All rows of the 7 groups of the original Booking/Sales/items/equipment load/equipment/equipment items/existing events are identical before and after execution. All 12 relation types under the new Booking are 0 |
| Cleanup | PASS | After confirming full backup equality and 0 relations, at 2026-09-12T17:19:05.349Z only the 1 test header and the exact 1 request receipt were deleted. 0 remaining in the DB and the original is unchanged. Refresh0-0 of0 confirmed in the UI, filter cleared |
The request UUID is 01a0969d-6aed-799e-bd6b-fcb6a8deb546 and the receipt points to the original ID66751. Therefore only this request was deleted, without cleaning up all events of the original. The recoverable full backup is booking-fixture-linked-clone.json, the actual execution summary is booking-linked-clone-runtime.json and the screen checked directly is booking-linked-clone-packing.png. The clone/Packing model 28 PASS is kept separate from this real result. There is no change to Product source, the original business rows, schema, accounts, shipping, Git, publication or Production.
Verification limits: at this point all 3284 C2 Bookings have no positive direct SALES_ORDER_ID/SALES_ORDER_UUID value, and the real relation is the BOOKING_ID of Sales. Therefore the header clone of an original with back-references is confirmed, but the combination of PO retention on an original with direct pointers is NOT_RUN. To test it, the pointers of existing business data were not arbitrarily changed. Other roles, quantities 2-9, internal DB failures/lost commit responses and the new Sales link and unit price storage after clone are also unverified. The load timeout on the first list navigation was handled by reconfirming normal rendering on the same Page, and the pagination selector wait after cleanup was a tool failure that used the wrong DOM scope. It was confirmed by the 0-0 of0 of the actual snapshot, and the DB cleanup was not run again.
Small screen read and selection list real execution — 2026-09-13¶
It was performed with the baseline 8b0713c96 and this common forms change, in my own space 4/p2 of local admin2/C2, and only queried the existing CALB779085. The small screen is a reproduction of the viewport of desktop Chromium and is not a real mobile phone test.
| Actually checked | Result | Evidence scope |
|---|---|---|
| 390×844 list and edit window | PASS | Number filter 1-1 of1, edit window 390×844, date input width 358. Clone/Packing List/Booking Confirmation/Submit of the footer are all displayed within the screen |
| Fix of selection list truncation | PASS | Before the fix, Clone covered the position to tap below the Billing list (y713.53). After the fix the list is displayed at the top y282.53~~483.53 and the bottom hit is a real option. The multiple Shippers list was also checked with options at y357.93~~558.93 |
| Escape | PASS | In the single and multiple lists the first Escape closes only the list and keeps modal1. After closing the list, the next Escape closes the parent edit window with no change |
| 768×1024 | PASS | document width 768, edit window 704×928, date input width 313 and 4 footer items displayed. The bottom option of the Billing list and the parent after the first Escape are kept |
| 1680×922/DPR2 restore | PASS | The original CSS viewport is restored, document width 1680, the bottom option of the Billing list and the parent after the first Escape are kept and the second one closes it. Number filter cleared |
| Existing data read | PASS | GET200, version 1, SI/BL null, AR2019-01-23, empty Remark, Billing null and an empty Shippers array are kept. No change to UI/API storage, fixture or SQL |
The existing single Autocomplete and multiple SelectField use the common forms/tomSelectOverlay.ts. The existing Tom Select placement/keyboard hook is corrected, and no per-business popup, CSS or permission was added. The focused regression of 17, the Web/UI type check and ESLint on the new helper/tests are PASS. The 1 ref update error during render and the 1 cleanup warning in the existing forms/index also exist on HEAD, so the whole-file lint is kept separate as FAIL.
The post-fix captures actually checked are booking-mobile-company-after.png, booking-mobile-multiple-after.png, booking-tablet-editor.png and booking-desktop-editor-after.png, and the execution summary is booking-small-screen-runtime.json. Releasing the CDP override alone left the width at 768, so the original 1680×922/DPR2 was explicitly reset before checking. No other space or account was touched. Storage/conflict recovery and saved selection values on a small screen, C1/other roles, the full keyboard/assistive device and real devices are NOT_RUN. This result supplements only the read, list and close parts of the earlier unverified small screen marking above.
Small screen creation, save and conflict recovery real execution — 2026-09-13¶
It was performed with the baseline 8b0713c96 and the current Booking/forms change, local kyle-mba:3306/prod, admin2/C2·trade-inventory, at 390×844 in my own space 4/p2. The test booking is the single NS4-017-260913-MOB1, UUID 01a096ab-1cb8-7545-9341-4358112da674. This is not a real device or concurrent access by different users, but a stale screen created with the desktop Chromium viewport and an API change on the same test row. It supplements the real evidence of BKG-R01~R03 within the scope below.
| Actually checked | Result | Storage and screen evidence |
|---|---|---|
| Required value, new creation | PASS | A missing Booking # and a missing Shipping Line with only the number entered are each rejected with a native required error and 0 in the test DB. After entering the number, Shipping Line HMM, Vessel and Remark, Create Booking creates a new UUID, version 0 and MOBILE_CREATED |
| Normal save | PASS | After the UI Remark MOBILE_SAVED and Submit, the API/SQL version 1 matches. After the last tool output was lost, the data was queried first so nothing was saved twice |
| Stale rejection, draft kept | PASS | Screen draft MOBILE_STALE_DRAFT, same fixture API PATCH expectedVersion1/Remark → server version 2. After UI Submit there is a conflict notice, the draft is kept and Submit is disabled. The stored value MOBILE_API_VERSION2/version 2 is kept |
| Recovery and re-open | PASS | Reload latest (y794~828) can be run within the 844 screen. The draft is replaced with the latest Remark, the warning is cleared and server version 2 is kept. Re-entering MOBILE_RECOVERED and Submit → version 3. Reopening from the 1-1 of1 number filter in the list confirms the stored value |
| Preservation of other values and relations | PASS | In the full SQL snapshots of version 0→1→2→3, 59 columns are identical except Remark, ROW_VERSION and UPDATED_AT. Company, dates, quantity and flags are unchanged, the 12 relation checks are each 0 and receipt is 0 |
| Cleanup and environment restore | PASS | After comparing the exact backup/UUID/tenant/number/version, the 1 test header was removed and at 2026-09-12T17:38:33.897Z 0 remained. UI Refresh0-0 of0·GET404, filter and edit window cleared, 1680×922/DPR2 restored |
booking-fixture-mobile-save.json is the full row history and cleanup backup, and booking-mobile-save-runtime.json is the execution summary. booking-mobile-conflict.png and booking-mobile-recovered.png were checked directly. Only the last subtree snapshot failed with a stale ref, and the successful save was confirmed through SQL and reopening the new list instead of being repeated. There is no new Product code modification. It supplements the unverified small screen save and single conflict of the read test above, while changing the company selection value, running the date batch on a small screen, real devices/assistive devices, other roles, Packing unit price, files/provider and Wiki DB publication are separately unverified.
Invoice unit price current storage real execution — 2026-09-13¶
It was performed with the current trade/fulfillment-write.ts at the baseline 8b0713c96 and the existing Booking/Packing UI, with admin2/C2·trade-inventory and my own space 4/p2 on local kyle-mba:3306/prod. The existing fixture composition of NS3-112 REC03C was reused, but past rows were not reused. Under the new marker NS4-017-INV-X8f370db5Z and Booking UUID 01a096bb-b3ef-7b66-95e4-b1cdbaf977bd, only Booking1, Sales Order1, Equipment2, EQL2, OI4 and EQC2 were created. The company/item master and existing business data are read-only.
| Actually checked | Result | Evidence scope |
|---|---|---|
| Initial Invoice | PASS | 2 containers pointing to the same Sales, and the 4 real OI are displayed as 3 groups. The group with MT unit price 100 has 2 originals/amount 300, the MT200 group 100 and the EACH10 group 30, for a total of 430 |
| UI unit price blur save | PASS | After changing the 100.0000 input of the Invoice to 200, the focus was left with Tab. Only the RATE of the 2 original OI changes from 100→200 and the existing MT200/EACH10 stay as they are. They are merged into 2 groups and display MT700+EACH30=730 |
| Full DB preservation | PASS | The difference in the full 12-row snapshot is only the RATE of those 2 OI, the automatic UPDATED_AT and Sales UPDATED_AT. Booking version 7, decoy COMMODITY_RATE987.65, quantity, weight, UOM, Packing EQC/EQL, equipment and the remaining unit prices are identical. overlay 0 and 0 unexpected relations |
| Close and re-open | PASS | After closing the window and reopening the same Booking, 200.0000/10.0000 and 730.00 of the Packing Invoice are confirmed. Compared with the original DB result of this fixture and not with the total of another booking |
| Exact cleanup | PASS | Comparison of UUID/number/tenant, relations and the full snapshot, agreement of the re-read inside the transaction and a delete count of 1 each were confirmed. At 2026-09-12T17:49:59.831Z 12 rows in total were removed, with 0 remaining of the six kinds, overlay 0 and 0 unexpected, and Booking/Packing GET404 with 0 edit windows |
Execution comparison showed that the current rate function is identical to the past 525d0d15c except that the two SELECTs were changed to explicit columns. The above real test supplements the current normal write where only the explicit columns changed, and the same CAS/failure/loss branches reuse the past execution evidence and the current DB model 18 PASS. The model 18 is not presented as 18 real failure injections today.
The full backup, original, change and cleanup are in invoice-rate-fixture.json and the summary is invoice-rate-runtime.json. The two saved screenshots show only the top of Packing and are not used as visual evidence of Invoice 730. The Invoice values and groups were confirmed through the actual iframe DOM, input behaviour, re-opening and SQL comparison. The product code was not changed this time. Real printing/Excel app, other roles, other failure combinations, company role recovery, Wiki DB publication and full Booking acceptance are separately incomplete.
Booking read boundary and first query failure — 2026-09-13¶
Baseline: 8b0713c96 and the current Booking hook/Workspace change, local 3000·kyle-mba:3306/prod, admin2/C2/tenant019dd494-6e47-72c9-96bf-d250dc575a75, my own space 4/p2/1680×922. No existing business row, account, permission or schema was modified and no new test row was created.
| Actual scenario | Execution result |
|---|---|
| Own CALB779085 UUID019fd150-9934-7c32-8537-dab69562fd0a | header 200/version 1, Packing 11 rows and Invoice 12 items |
| C1 UUID019dd48e-9687-76ff-9c6e-c933a9b60858 that really exists in SQL | C2 detail 404 NOT_FOUND/Packing 404 PACKING_SOURCE_NOT_FOUND, no data. SQL confirms the C1 tenant/version 0 |
| Adding C1 tenantUuid/clientId=1 to the query | The C1 detail is still 404. The C2 detail is my own tenant/version 1. All first 10 rows of the list are my own tenant and items/total3283/nextCursor match the normal request entirely |
| List, company selection, detail, Packing and compatibility options GET without cookies | All 401 AUTH_REQUIRED with no data. No change to login, cookies or existing accounts |
| Screen of the real C1 UUID | not-found warning, no other tenant content. Reproduced the pre-fix defect of an empty default form with active commands, and after the fix there are 0 inputs, Submit/Clone/Packing/Confirmation are disabled and it can be closed |
| Re-open of a normal booking | CALB779085 keeps the header, 39 inputs and active Submit. This is not a data storage test and is distinguished from the existing storage/recovery evidence |
| Regression of the new creation window | It keeps 38 inputs and an active Create Booking. It was closed without input/storage and admin2/C2, original version 1, Packing 11/12 and 0 edit windows were reconfirmed |
The fix owner is the existing NS3-112 BookingWorkspace → useBookingWorkspaceState. It reuses the existing baseline of a successful initialization as ready and blocks save entry/form and document behaviour before preparation. Since it does not block on the mere presence of error, the existing edit and draft recovery of an already loaded booking is kept even after a company selection query failure or a save failure. There are no new role restrictions, API changes or common framework.
The actual hook callback model checks 0 update calls on the first 404/403/503 and includes normal query, company selection error, save error and new initialization. The 5 new cases fail before the fix → all 26 related cases PASS, Web types and hook/test lint PASS. The 1 effect error and 3 dependency warnings in the Workspace file lint are reproduced on the identical HEAD source and are kept separate as the existing FAIL. The first runtime observation timeout was resolved by re-querying the same space to confirm the final state, and the request was not saved twice. booking-read-not-found.png, which was checked directly, is visual evidence of the error state.
NOT_RUN out of scope: real 403 of other roles, write isolation, session expiry, the real UI per failure, physical devices and Production. The cases above accept only the read boundary and first query failure handling of admin2 and do not replace full permission acceptance.
Office Manager real read — 2026-09-13¶
The active C2/role2 (Office Manager) of the existing local lwtest_c2 was confirmed by SQL, and a normal login was performed into the same space 4/p2 through the credential path designated by the existing real test in the repository. No new account, password, role, menu or grants were created or changed. The current MENU_ROLE_LIST of Booking menu 103 is 1,2. After login, the user UUID 28f998ac-a19f-11f1-86f5-6ec3885d3c14 of the actual session and the C2 tenant·trade-inventory were compared with the account on the screen.
| Execution | Result and scope |
|---|---|
| Menu, own query | Entered the Shipping→Booking list, and confirmed the list and CALB779085 header GET200/version 1 and Packing GET200/11 rows |
| Actual detail and document | CALB779085 is displayed in Edit Booking, and pressing Packing List in the detail confirms the same booking, TOTAL11X40H and Shipping To. The 2 captures checked directly are kept. Active Submit/Clone and similar displays are not a storage permission test |
| Reading another tenant | The header of the real C1 UUID019dd48e… is 404 NOT_FOUND, Packing is 404 PACKING_SOURCE_NOT_FOUND with no data. The actual detail error, 0 inputs, 4 storage/clone/document commands disabled and closing is possible |
| Original and recovery | The full header/Packing JSON hash is identical before and after. The 2 Office Manager Booking tabs and the edit window opened in the test were closed, the existing Inbound tab was kept and the normal admin2 login was restored. A GET without cookies giving 401 with no data was checked separately |
The evidence is the existing booking-read-access-runtime.json with officeManagerRead, booking-office-manager-detail.png and booking-office-manager-packing.png. Finding the native <dialog> by a role attribute in the initial observation, or finding the booking number only by iframe innerText, was a targeting error and was corrected to the real dialog and input values. When the detail left over from closing a tab was opened again, that window was closed and only that tab was cleaned up. There was session creation and cookie replacement from the normal login, and this does not prove deletion of all auth session rows or disposal of previous Office sessions. No business row write, storage command or document sending was run. Role 2 creation/modification/clone/Invoice unit price storage, roles 3-6, physical output and full permission acceptance are NOT_RUN.
Packing source and selection scope real read — 2026-09-13¶
The subject is local admin2/C2(trade-inventory), the same session space 4/p2. Without any Product/DB write, only the real API, SELECT and document selection in the browser were performed. The 18 PASS of packing.ts hash bddb2a18… and the existing packing.test.ts hash 7fded52f… were reused from the immediately preceding run.
| Case | Actual result | Limit |
|---|---|---|
| CALB779085 all / single | All 11 units and Invoice 12 rows, and 1 unit with Invoice 1 row, GET200. CAIU4349939 is 44,420 LB on both sides with the same sourceVersion/rows. This matches 0 load items in the DB and the shipped item UUID15036e37…/44,420. After actually selecting a Container it shows 20.149 MT, and after returning to All it shows 219.694 MT and Invoice; 2 captures checked directly | The full API is identical before and after, header v1, overlay 0. These are read/selection results and are not reversal or actual output/issuance |
| Existing P2-SCALE-WORKFLOW test Booking | Packing100 uses the load item UUID019fe9ff-6254…, while product Invoice100 uses the shipped item UUID019fe9ff-5281…. The API and a separate DB SELECT match | API/DB read only; this is not acceptance of a new UI or loading/reversal of this case |
| Only some Containers have load items | 0 targets in the SELECT with the current C2 active UUID/valid Container link condition | No new fixture was created. Mixed sources are reused only from the past actual All/selected evidence of NS3-112 REC03C and the existing model, and are not promoted to a current runtime PASS |
The actual current source selection is PASS; mixed source re-execution and Packing/Invoice after partial/final reversal, Billing and settlement are NOT_RUN. The difference between the reference Sales-based query and the complete-set priority of native is stated in the screen specification. The existing document source rule itself was not treated as a defect and was not changed. The earlier observation script waiting for a table in the outer DOM was a test problem that targeted the iframe incorrectly, and it was confirmed with the current iframe DOM and capture. It is not recorded as a product error.
Verified basic C2 usage — partial draft before publication¶
Role scope: the real test of the storage and recovery procedure below is based on Administrator. For Office Manager, the Shipping→Booking list, the existing detail, Packing read and the error handling of a missing booking were confirmed. The storage, clone and unit price edit of Office Manager, or the usage of other roles, are not finalized by this result.
If The requested booking was not found. appears when opening a booking, the booking to edit could not be read. At that point the save, clone and document buttons are not available. Close the window and check the target again in your own Booking list. Do not conclude from this message alone that another company has the booking.
- Press Create under Shipping > Booking. Enter the Booking #, Shipping Line and the required schedule, quantity and company, then press Create Booking. The vessel name is at most 50 characters, and if an over-length error appears, fix the value and save again.
- Open the created booking again and check the entered values. Edit the header and save it with Submit. SI Date, BL Date, AR Date can each be entered, or cleared by clearing the whole date. They are different items from the SI cutoff, and storing the AR Date does not automatically change Invoice/Billing Ready. Do not conclude from the header save alone that equipment, stock or Sales were created or synchronized. When closing unsaved header changes, cancelling the discard confirmation lets you keep entering values, and approving it discards the draft and closes. This is not an undo of already saved data.
- You can clone with quantity 1 from Clone of the saved booking. The clone is based on the saved header and does not clone or save the parent's unsaved input. SI Date, BL Date and AR Date are cloned as they are. Open the new number in the list again to confirm. Since the Clone window has no date input, edit and save in the cloned booking to change a date. If the result-not-confirmed notice appears, retry the same request with Retry Clone in the open window. The quantity cannot be changed at that point and a new Clone request is not created twice. Check the new number and UUID. Do not use it as a feature that automatically resets the Invoice number, flags or Sales references. Sales, containers and Invoice items linked to the original are not cloned automatically. A displayed cloned planned quantity does not mean actual Packing link rows were created, so open Packing to confirm. The procedure for a new Sales link and unit price storage after clone is not finalized usage yet.
- Booking Confirmation is a preview of the saved content. Unsaved changes must be saved first to appear in the preview. This draft does not finalize the Packing edit with printing and link data yet.
- To change several bookings, select only the relevant rows in the list and press Edit (quantity). In Add field, choose the column to change and enter the value, then press Apply to N rows. SI Date, BL Date and AR Date can each be set with Set value or cleared with Clear value. Dates/columns not selected stay as they are. After saving, check the list Status and, if needed, the dates of each booking. If the date range was cleared, apply the query with Refresh.
- If a conflict with another edit occurs during multiple editing, press Reload selected rows. The draft you entered remains, so check the latest content, decide whether to apply it and save again. A batch that failed because of a row conflict is not partially saved.
- Reload latest in single booking edit is different. It replaces the current draft with the latest server value, so store any input you need first and then press it. If the storage result is uncertain, do not unconditionally save again and check the re-read result instead. Save confirmed by authoritative readback. means that the storage was confirmed by a query.
- In Packing List, select all or one container with Container and query with a different unit. Email is a display format and not a send button. Returning to Invoice shows Packing and Invoice together. When you change an editable Invoice unit price and move to another input, the unit price of the linked order item is stored. If the same group has several original items, those items change together, and rows with the same unit price may be merged. Check the updated unit price and total, and reopen the booking if needed. It does not change a separate Booking unit price or a Packing quantity/weight. When only querying, do not change the unit price.
- Export Excel downloads an
.xlsfile of the current selection and displayed content. The file content actually checked is HTML and contains the Packing/Invoice items and total of the selected container. Compatible viewing in the Excel app and physical printing have not been checked yet, so this draft does not present it as normal output completion. In the local app check of 2026-09-13, Microsoft Excel could not be found, so compatible viewing isBLOCKED. Checking the file content or viewing it in another app is not a substitute for Excel acceptance. - On a small screen, scroll inside the edit window to see the dates, company and so on. Escape while a selection list is open closes only the list. Escape after closing the list follows the existing close behaviour of the edit window. If Booking # or Shipping Line is empty, fill in that required input and then create. After editing the remark, save with Submit and reopen it from the list to confirm. If a change conflict appears, store your input and load the latest values with Reload latest, then edit and save again. This procedure was checked on a 390px screen and does not mean acceptance of a real mobile phone, all fields or multiple editing.
This draft derives only from the PASS scope above and did not publish or replace the existing DB manual. The normal save of the Invoice unit price on focus loss and the group update supplemented the current real verification. The remaining failure combinations of recovery, other unsaved paths, the full procedure of output temporary values, Excel app compatibility/physical printing, other roles and the remaining input boundaries are still the target of the next real verification.
Actual source and differences of the current Client 2 manual¶
In the read-only local investigation of 2026-09-12 the two overrides mk-booking and mk-booking-confirmation of the C2 T_WIKI_PAGE were confirmed (stored update date 2026-08-01). The Wiki catalogue gives the DB override of the same slug priority over the profile-generated one. It is not the same source as the generic booking document, and changing only the generated one will not update the procedure of this screen.
| Actually stored manual content | Compared with current native / update condition |
|---|---|
| Entry through Operations > Orders > Booking List | Actual entry through the current C2 menu Shipping > Booking is PASS. When publishing, only the entry of that C2 draft is corrected |
| Creation/edit runs the BOOKING_RATE link synchronization and can change lot/allocation | It is a Legacy effect. It is not applied as is to the native header save. The BILLING_READY event of changing the submit flag is separate and different from stock synchronization |
| Clone does not return a creation ID | It is a description of the Legacy response. Native returns a new UUID, number and version plus the request UUID, and distinguishes a re-run by the receipt |
| After a concurrent edit, compare the whole Detail manually | Native conflict recovery is actually confirmed. Multiple editing keeps the draft after the re-read and single editing replaces it with the server value, so they are described separately |
| Remark/Special instruction are not printed on Confirmation | The two fields must be distinguished. Native Confirmation has no Remark item, but it renders a separate section when the stored Special instruction is not empty. The actual query scope below is an existing booking with a Remark value and an empty Special instruction, and actually viewing and physically printing a non-empty Special instruction is NOT_RUN |
On 2026-09-13 the existing booking DALA91044100(fcebd0bd-5933-5406-8567-57613c7bba3a, v0) of admin2/C2 was opened through the actual Detail→Booking Confirmation. The Remark of the Detail was Edge Metals and the Special instruction was an empty value. The preview is SHIPPING INSTRUCTION and there was no Remark item and no Special Instruction section. The place in the body where the same string was found is the Supplier's Edge Metals LLC, and it is not evidence of Remark output. The full header JSON hash 44f663b4… was identical before and after. The packing.ts of the source passes SPECIAL_INSTRUCTION to the document, and documents/src/public.ts::confirmation creates that section only when it is not empty. Source comparison and the actual empty-value viewing are distinguished, and this result alone does not accept the display or physical output of a non-empty instruction. The follow-up record of the existing booking-confirmation-runtime.json was used and the DB manual override was not changed yet.
In the follow-up SELECT of 2026-09-13, of the 3,283 non-deleted C2 bookings on local kyle-mba:3306/prod, 0 had a non-empty SPECIAL_INSTRUCTION. Since the real TENANT_ID is BINARY(16), the total count and the candidate query using the same binary argument were checked together. The 3,338 bookings of the provided MK original SQL have no SPECIAL_INSTRUCTION column at all and only REMARK (original SQL hash68e74064…). The current importer preserves REMARK and initializes SPECIAL_INSTRUCTION to an empty value. This investigation does not prove a missing instruction migration, and the cause of the count difference between the original and the current is not judged by this query either. There is no case to proceed with acceptance of a non-empty instruction from existing data alone, so the execution is BLOCKED — no test data, and the execution result is NOT_RUN. No original re-migration, modification of existing bookings or creation of a new fixture was done.
The differences above are the result of a source/stored-original investigation and are not a PASS of new business execution. No existing override was arbitrarily deleted and no Legacy manual was globally replaced. Once the verified C2 procedure is finalized, only that C2 document should be updated through the current edit/concurrent-modification path and the actual read should be checked separately.
Status and company roles: it is not finalized that the progress display computed from the reference Active/Closed and SI/BL/AR dates corresponds one to one with the active, submit and invoiced flags of native. The Supplier of the reference SHIPPER column and the Shipper of the AGENCY column are also not merged by name. The current migration and combined execution results are recorded in the data design document, and the final mapping that preserves role meaning is unresolved.
The follow-up read-only comparison links to the option and weight conflict and the effect of status and company on consumption. The fact that the source dates and the three company roles are separate is already confirmed, so the user is not asked again to decide the distinction of meaning. The native input/query, storage, migration and document consumption that are still missing must be recovered in the existing owner and accepted with real data. This time no existing business/test row, setting or schema was used, and no unverified None/decimal storage or date→billing completion procedure was added to the C2 draft.
Source:
new-system/docs/pages/transportation/booking-workspace/ACCEPTANCE.md— ctc repository