System Screen and Dialog Specification¶
0. Document Control And Screen Identification¶
| Item | Baseline |
|---|---|
| Document ID / type | SPEC-UI / Screen and Popup Specification |
| Targets | menu, route, page, list, detail, dialog and drawer, and the report and print surface |
| Basis | the C1 Legacy screens and flows, and the real C2 reference and New-System screens |
| State | the source structure, a render check, and the real acceptance per role are separated |
| Shared contract | the shared UI and design baseline is reused and only the per-screen exception is stated |
| Derived document | only a verified C2 screen procedure is derived into a user manual and the Wiki |
A fictitious screen example is not a real menu, field or authority. The existence of a route or a single screenshot is not expanded into the whole state, viewport and role acceptance.
1. Scope Of The Screen Specification¶
It covers every user touchpoint, from the administration screens to the area lists, details, popups and previews. It defines the purpose of a screen, the actor, the input, columns and buttons, the behaviour per state, and the linkage specification. This document is a development specification, not a user manual or an introduction to the screen features. The common look and interaction follow DESIGN and UI Foundation.
2. Common Screen Contract¶
It distinguishes the filter, sort, selection and page state of a list, the record identity and version of a detail, the default value, required or read-only and validation of an input, and the save, close, dirty, conflict and unconfirmed result states. A menu being visible and the server authority are separate things. A common field, selector, popup and accessibility use the existing shared UI, and a new style or a required input is not created because a document is being written.
3. Per-Area Screen Contents¶
| Area | Screen group in scope | What to check in the detail |
|---|---|---|
| Administration, access and settings | users, roles, tenants, menus and settings | the query and edit scope, the valid state and the recovery |
| Master data | management and selection of companies, items, units and places | search, autocomplete, reference and duplication |
| Trade | the order list, detail and item | the quantity, price, state and the execution link |
| Inbound and outbound | the execution order and the inbound and outbound input | the source selection, weighing, location and partial result |
| Field work and Transload | planning, assignment, and field and office work | the input, evidence and correction per actor |
| Weighing | weighing input, ticket and correction | the unit, the measured value and the original evidence |
| Inventory and warehouse | the inventory list, placement, allocation, loading and reversal | the remaining quantity, the selection, and re-entry after completion |
| Transport and Booking | the booking list, detail, copy and Packing | the Booking screen detail is partially written |
| Equipment and yard | the equipment list, yard, movement, return and photos | the location, state and linked record |
| Documents and output | preview, output, files and dispatch | distinguishing the source, the edit, the save and the transmission effect |
| Billing and settlement | the billing source, unit price, finalisation and query | the amount, currency, correction and source tracing |
This table is the scope for writing the whole screen detail and does not guarantee that every current menu and action exists or is accepted. The existence, state and Client application are compared between catalog/pages/ and the real screen owner. Detail other than Booking, Transload, Scale and Inventory is unwritten or awaits the organisation of the existing contract.
3.1 Currently Confirmed Screen And Route Registrations¶
| Screen ID | Current route and source | State | Preserved and open items |
|---|---|---|---|
page.platform.master-company-compat |
company-list |
SOURCE_MAPPED | the compact density and the route and menu identity; the Party detail specification is incomplete |
page.platform.master-commodity-compat |
commodity-list |
SOURCE_MAPPED | the current master binding is a compatibility classification |
page.platform.master-generic-compat |
master-list and the carrier, driver and chassis lists |
SOURCE_MAPPED | a decision to separate the owner by meaning is needed |
page.commercial.agreement-list-mk-compat |
mk-commercial-orders |
SOURCE_RECONCILED | the compact register, the exact re-read and the print entry are preserved |
page.intake.appointment-ctc-compat |
appointment |
SOURCE_MAPPED | the date, status and sort and the positive field transitions; the Service Request and slot contract is unresolved |
page.transportation.booking-compatibility |
booking-list and mk-booking-list |
LOCAL_RUNTIME | the route and menu, the date and search, the deep link and the popup return are preserved |
page.transportation.booking-workspace |
/bookings/{id} and /bookings/new |
LOCAL_RUNTIME | a native product surface; some lifecycle, role and correction detail is deferred |
page.inventory.* |
/inventory and the Receipt, Allocation and Container dialogs |
SOURCE_MAPPED | the current source and part of the RCP are a basis; the real full C2 role and DB acceptance is NOT_RUN |
page.operations.execution-workspace |
the inbound-planning and loader candidates | TARGET_CANDIDATE | the catalog runtime evidence is NOT_IMPLEMENTED |
page.scale.ticket-workspace |
/scale, ScaleExperience and /api/scale-tickets |
SOURCE_MAPPED | the ticket CRUD, stage and reversal source exists; the real device, role and DB acceptance is NOT_RUN |
page.transport.* and page.equipment.* |
the dispatch, driver, external carrier, Yard and container candidates | TARGET_CANDIDATE | the C1 current source and the target product page are distinguished |
page.platform.user-wiki |
/wiki |
TARGET_STANDARD | search, article navigation and accessibility; the development specification is a separate reader at /wiki/specifications |
A TARGET_CANDIDATE registration or an E2E file path is not proof of a real screen implementation or acceptance. Conversely, when a screen that exists in the current Web has a different name from a catalog candidate, the real component and route are confirmed and recorded in that detail.
3.2 Current Behaviour Contract Per Screen Group¶
- Administration and master data: list, search and options, and create and edit, use a tenant-scoped reference. The fact that a generic table mutation currently exists does not approve the same form and authority for every category.
- Commercial: the list, an exact detail re-read, create, edit and delete, and the print entry are distinguished. The agreement status and the execution state are not merged into one badge.
- Fulfillment: the Inbound and Outbound collection and editor, and the Receipt and Allocation dialog, share one workspace state, while a normal Save and an owner action are separated.
- Operations and Scale: the actor, state and original evidence of the planning, Loader work, timeline, and Scale input and correction screens are separated. A completion button does not indicate that the provider and inventory are also complete.
- Inventory: the quantity, weight and status of a lot and the Placement and Allocation are shown as separate sections and actions. Whether a correction or reversal can be entered for a CLOSED lot is verified against the real contract.
- Transportation and Equipment: Booking, dispatch, the Driver field task, the Yard queue and map, and the Container return are shown as independent screens and states.
- Documents and Settlement: the source identity and revision and PREVIEW or RENDER_ONLY are exposed, and whether there was a real issue, email, print or posting is shown separately.
4. Individual Screen Authoring Items¶
It writes the screen ID, name, purpose and entry and return, the target role and Client, the related requirements, the composing sections, the fields and columns with their type, unit, default, required and read-only state, the buttons with their active condition, action and effect, the API, the loading, empty, error, denied, dirty, conflict and unknown states, mobile and keyboard, the follow-up screen, and the tests. When there is no recent screenshot it stays unconfirmed, and reading only the code is not recorded as having checked the real screen.
5. Transportation Area — Booking Screen¶
It links the detail of the existing Booking specification as it is. The Booking list and popup design is not treated as the screen structure of the whole system. The fields and buttons of another area screen are defined separately on the basis of the relevant C1 Legacy or C2 reference and the product implementation.
The Booking screen is one detail of the whole screen specification. The route and menu identity of the C1 booking-list and the C2 mk-booking-list are preserved during coexistence and linked to the common owner of the native /bookings. The difference between the C1 Legacy fields and flows and the C2 reference and native is kept in the existing screen specification. The special list and dialog behaviour of Booking is not promoted to a common popup rule of another area.
6. Field Work Area — Transload Screen¶
| UI ID | Screen and current source | User purpose and main actions | State and acceptance boundary |
|---|---|---|---|
| TRN-UI-01 | Transload Workspace at /transloads and TransloadExperience.tsx |
the list, detail, create and change, the check-in, dock, start, complete and undo, and entry into the scale and BOL linkage | the loading, error and unknown per action and the authoritative re-read are shown; the real per-role browser acceptance is NOT_RUN |
| TRN-UI-02 | Planner Calendar at PlannerCalendar.tsx and transload-planner |
the weekly plan query and move, the appointment creation, and entry into the Loading Plan dialog | saving a plan is not shown as an assignment or start completion badge |
| TRN-UI-03 | Assignment Board at AssignmentBoard.tsx |
the loader selection, the queue order, and assign and unassign | the UUID loader and the current assignment and planner are read back; the difference between the two stored representations is not hidden from the user as a false single state |
| TRN-UI-04 | Loader Jobs, Timeline and Analysis from each screen component | starting and completing field work, and checking the work time and history | the field completion, the Office confirmation and the inventory and provider state are shown independently |
| TRN-UI-05 | Inbound Planning and Dock Driver Snapshot at InboundPlanningBoard.tsx and DockDriverSnapshot.tsx |
the check-in, staging, dock and clear waiting, and a check of the field state | the queue and the real Yard and warehouse occupancy are distinguished, and an action of a forbidden state is disabled or rejected |
| TRN-UI-06 | Completed Loads, Approval Tracking and the Email Queue | the completion record, the Office review, and the approval and follow-up check | a completion record and an approval or email result are not merged into one success |
| TRN-UI-07 | Warehouse Labels, Appointment Blocks and the Operating Dialog | the label, the time block, and the plan and work detail input | an output or time block save is separated from a work mutation, and after a dialog save the calling screen is refreshed |
The C1 screens are compared with the fields and actions centred on the Legacy Loader, and C2 exposes only the capability actually enabled in the reference and New-System. The Transload screen is not made a mandatory step for a non-physical C2 task. The existence of a screen source and a menu registration is not proof of the acceptance of a real authority, data or action, so the role, browser and DB results of TST-05 stay NOT_RUN.
7. Weighing Area — Scale Screen¶
| UI ID | Screen and source | User purpose and composition | State and acceptance boundary |
|---|---|---|---|
| SCL-UI-01 | the Scale Portal at /scale and ScaleExperience |
the date and search, the inbound and outbound scheduled lane, the in-progress ticket, and the completed history query | the loading, empty and error and the UUID omitted are distinguished; the real role browser acceptance is NOT_RUN |
| SCL-UI-02 | the Check In dialog | the Fulfillment Order selection, the first GROSS or TARE stage per direction, and the 5 axes, vehicle, equipment and driver input | a save is blocked before a valid order, direction and positive axle total; the ticket is re-read after the save |
| SCL-UI-03 | the Check Out and Stage dialog | the remaining stage input, or a correction of the same stage before completion | a normal reweigh of a completed ticket is blocked, and the correction reason and the error are shown |
| SCL-UI-04 | the Reverse dialog | a Void or Reversal with the expected lifecycle and a reason | a downstream block or conflict is not closed as if it were a success, and the list is refreshed |
| SCL-UI-05 | the Scale Ticket List Editor at ScaleTicketEditorFields.tsx |
the ticket snapshot, the times and axles, up to 3 bad bales, and the driver, weigher and signature edits | an expectedUpdatedAt conflict, the correction remark, and the preservation of a sensitive field are checked |
| SCL-UI-06 | the ticket preview and Receipt selector | a ticket output preview and the selection of accepted evidence matching the source order and item | a PREVIEW is not a print or issue, and readyForReceipt is not a completed Receipt |
C1 is compared with the scheduled and in-progress flow of the Legacy Scale Portal and its field and office differences, and C2 applies an Office-centred capability and the Receipt policy. A real device connection, live weight accuracy, keyboard and touch, signature, output, and per-role action are not accepted from the existence of the source alone.
8. Inventory And Warehouse Area — Inventory Screen¶
| UI ID | Screen and source | Purpose and action | Acceptance boundary |
|---|---|---|---|
| INV-UI-01 | the Inventory List and Detail in InventoryExperience |
the Available, Closed and All query, and a check of the lot identity, quantity, weight, status, source and placement | the real acceptance of re-entry into a CLOSED lot and of the role scope is NOT_RUN |
| INV-UI-02 | the Finalize Physical Receipt dialog | the source item, remaining quantity, scale or no-scale evidence and warehouse location input | it is separated from a normal Save; the Receipt and Placement results and errors are shown separately |
| INV-UI-03 | the Receipt Correction and Reversal | the correction and reversal of an allowed lot, and a check of the lineage | the normal C2 input may be hidden; the existence of the API is not shown as a completed user path |
| INV-UI-04 | the Allocation Workbench and Detail | the eligible demand, the lot balance, the partial and full weight, and Apply and Reverse | the basket is a temporary projection; the quantity and weight and an overdraw or conflict are shown |
| INV-UI-05 | the Direct Container Loading dialog | saving or retrying the container, the transloaded time and the allocation result | the original identity is kept and is not regenerated as a new UUID on an unknown |
| INV-UI-06 | the Documents and Billing linkage | a check of the Packing, Invoice and Billing source and the Inventory and target result | a reversal is not shown as having automatically zeroed or cancelled an output or a billing |
The C1 custody and bale screens and the C2 owned-stock screens are explained with the capability and persisted ownership of the shared owner. The real C2 full allocation → Closed → detail → Reverse → return to Available, and the follow-up Container, document and billing read-back, are NOT_RUN.
9. Test And Manual Linkage¶
A screen requirement is linked to Tests and RTM. The C2 user manual is a derivative that explains a verified behaviour in operator language. Creating and saving real data, or publishing a manual, is not required beforehand to build the frame of the screen specification. The hold on a new C1 manual is kept.
10. Screen And Popup Detail Card¶
| Field | Authoring criteria |
|---|---|
| UI/POP ID, route and entry point | the menu path, the direct route, the caller, and the Client and role |
| User purpose and scenario | the start condition, the main steps, the end result, and leaving and resuming |
| Layout and regions | the header, toolbar, content and footer, and the responsive, scroll and overlay behaviour |
| Fields and columns | the label, control, source and type, the required, default, length and unit, and the edit and display conditions |
| action | label, visible/enabled guard, duplicate click, success/failure/cancel/focus |
| Screen state | the distinction between loading, empty, error, denied, stale, dirty and success and the work state |
| Linkage | the request and response, the data mapping, the popup and output, and the audit and manual |
| Quality and verification | keyboard, focus and accessibility, the locale, the viewport and browser, and the visual and runtime test case |
11. Screen Review And Change Impact¶
It checks the menu, route and role, a field loss, a hidden server validation, the list and popup state, the read-back after a save, the keyboard and focus, the mobile overflow, and the C1 and C2 differences. On a change, SRS, DATA, INTERFACES, BEHAVIOR, TESTS, RTM and the impact on the C2 manual are updated.¶
Source:
new-system/docs/specifications/SCREENS.md— ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged. A user instruction quoted inside the text is kept in its original language.