MK admin2 Full Functional Test Checklist¶
- Status:
DATED TEST RUNBOOK - Owns: the rerun procedure and readback criteria for MK admin2 functional verification
- Does not own: current Runtime fact, test result, production write authorization or user procedure
-
Update when: an approved MK verification scenario changes
-
Target: MK Metal Trading,
admin2Administrator - Recommended model:
GPT-5.6 Luna - Minimum reasoning effort:
high - Purpose: verify the MK features admin2 can reach from the menus, with a real work flow and read-back.
Execution Principles¶
- Record the test environment and DB identity on the first line. Never write to the operational DB.
- After login, enter through the app menus instead of typing a URL directly. On each screen, confirm the current workspace is MK.
- A write test uses only run-exclusive local data. Every created record carries an
MK-UAT-<YYYYMMDD>-<seq>marker, and you re-read 0 rows before creation and 0 active rows after cleanup. A preserved soft-delete audit is recorded as normal. - After Save, Apply, Complete and Delete, do not pass on the success notification alone. Re-search the list and reopen the detail to check the header, items, state, quantity/UOM and linked IDs.
- Print spool and external provider calls are outside the default scope of this document. Running them requires separate approval of the target and the rollback.
Common Evidence¶
- [ ] Recorded the execution date and time, the environment URL, the DB host/database and the confirmation that
admin2is in the MK workspace. - [ ] One failed login: a wrong password shows an error and creates no authenticated session.
- [ ] After a normal login, all of these routes are visible in the menus: Daily Dashboard, Commercial Orders, Inbound Orders, Doortrade Orders, Export Brokerage, Outbound Orders, Booking List, Order Schedule, Allocation Workbench, Scale Portal, Scale Ticket List, Trade Summary, Daily Commodity Report, Commodity Rate, Freight Rate.
- [ ] Opened each menu route through the menus and recorded the initial GET, the empty and result states, a filter change, and console/network errors.
- [ ] For each write scenario, recorded 0 rows before the marker search, the exact row count after execution, and 0 active rows after cleanup.
1. Exhaustive Read And Menu Coverage¶
Each row covers the screen load, the default and changed filters, opening a row or the detail, and the URL, HTTP and console errors.
| ID | Menu / screen | Check |
|---|---|---|
| R-01 | Daily Dashboard > Daily Dashboard: change the date and period, check the purchase, sales, receiving, outbound, inventory and exception figures, then navigate to one source screen. |
[ ] |
| R-02 | Operations > Orders > Commercial Orders: search by period, type and keyword, open the list and the Detail, and check that the header, items, links and status agree. |
[ ] |
| R-03 | Operations > Orders > Inbound Orders: open the list, the detail, the commodity options and an existing item, and check the order, item and receipt states. |
[ ] |
| R-04 | Operations > Orders > Doortrade Orders: confirm through the customer alias filter that it really queries the same inbound repository. |
[ ] |
| R-05 | Operations > Orders > Export Brokerage: check the existing job and booking search, and the empty state and cancel path of the PDF analysis screen. Analysis or generation happens only in a separate write item. |
[ ] |
| R-06 | Operations > Orders > Outbound Orders: search by period and keyword, and check the booking, container and allocation projection in the Detail. |
[ ] |
| R-07 | Operations > Orders > Booking List: search by period and keyword, and check the vessel, cutoff, container and flags in the Detail. |
[ ] |
| R-08 | Operations > Schedule & Allocation > Order Schedule: change the date and navigate from the inbound and outbound cards to the source order. |
[ ] |
| R-09 | Operations > Schedule & Allocation > Allocation Workbench: read the target, the available lot, the balance and the UOM. Apply is done only in C-03. |
[ ] |
| R-10 | Operations > Scale Portal and Scale Ticket List: read the existing tickets and list, and check the check-in and check-out controls and the document links. A physical write is done only in S-01. |
[ ] |
| R-11 | Billing & Reports > Trade Summary: check the period, company, commodity and status filters and the AP/AR, cost and claim popups, then open the source record. |
[ ] |
| R-12 | Billing & Reports > Daily Commodity Report: reconcile the period, company and commodity, the purchase and sales tabs, the totals and the source record. |
[ ] |
| R-13 | Billing & Reports > Commodity Rate: check the effective, expired and overlap filters and the existing rate Detail. |
[ ] |
| R-14 | Billing & Reports > MK Freight Rate: check the payer, carrier, origin, destination and effective-date filters and the existing rate Detail. |
[ ] |
2. Core Business End-To-End Tests¶
All writes are performed on Local only. The created data of each scenario is cleaned up in the given order before the end, and the read-back result is attached.
| ID | Scenario | Execution and pass criteria |
|---|---|---|
| C-01 | Commercial Order CRUD | Create one Purchase or Sales agreement with one item. Reconfirm the type, counterparty, reference, dates, commodity, quantity/UOM, rate, terms, linked order and status in the list and detail. Confirm that an edit is reflected exactly, and Delete only the records with no execution link. Re-read 0 active headers and items and 0 downstream links. |
| C-02 | Inbound Purchase → Inventory Lot | Create an inbound order and item and select an existing MK commodity. Run the Warehouse Only complete-without-scale. Re-read the source, order and item ID, quantity, weight, UOM, rate and state of the order and item, the transload and the lot. Confirm that allocation, placement and scale ticket are 0, then clean up the run-owned order, item, transload and lot. |
| C-03 | Outbound + Booking + Allocation | Use an outbound order and item with a linkable booking and lot fixture. After creating the outbound, reconfirm UNMAPPED or the current state. Apply in the Allocation Workbench with the exact lot, balance and UOM, then re-read the allocation summary and the lot balance. If a delete is blocked, check the owning allocation and lot first, and never run an unverified unallocate or reversal on assumption. |
| C-04 | Booking CRUD and document preview | Create a disposable booking or open an existing safe one. Reconcile the shipping line, vessel, type, limits, ERD/SI/cargo cutoffs, ETD/ETA, POL/POD, customer, shipper, commodity, container and linked order in the Detail. In Booking Confirmation and MK Packing List, check that the key booking, container, weight and invoice values match the API projection. |
| C-05 | Commercial Order errors and recovery | Check a missing Shipping Period, a foreign, deleted or self PO-SO link, and a duplicate-number candidate, each before submission or with a safe request. On failure, confirm that no business row was created or changed, and after a timeout or error, search by the marker and reopen the exact Detail. |
| C-06 | Inbound errors and recovery | Check a partial item save, a no-scale rejection, and a blocked edit or delete on a progressed row, using safe fixtures. After a failure or block, re-read the state of the order, item, transload, lot, scale and allocation first, and do not relink manually or force a delete. |
| C-07 | Allocation negative tests | Run a quantity larger than the target, a foreign ID, and a repeat of the same apply, each in its own disposable fixture. For a failed request, confirm 0 allocation, lot balance change and business write, and for a successful request, confirm it is reflected exactly once. |
3. Supporting Features, Output And Master Changes¶
| ID | Scenario | Execution and pass criteria |
|---|---|---|
| S-01 | Scale Portal | Run check-in through check-out and finalize in an approved local fixture that can simulate a physical weighing. Re-read the vehicle, party and cargo, the gross, tare and net, the source order and item, and the generated ticket. No real scale equipment or operational ticket is used. |
| S-02 | Export Brokerage | With a sample PDF or an existing run-owned job, confirm analyze, correcting the extracted values, then create and cancel. Re-read the source file, the analysis result, the generated inbound and outbound links, and the job state, and confirm that nothing active is left after the cancel. |
| S-03 | Commodity Rate | Create, edit and delete a disposable effective-dated commodity rate. Re-read the company, commodity, rate, UOM, effective and expiration date and the overlap and expired filters, and compare the actually applied value in a consuming transaction. |
| S-04 | Freight Rate | Create, edit and delete a disposable freight rate. Re-read the payer, carrier, origin and destination, the delivery condition, the rate and the effective and expiration date, and compare the actually applied value in a consuming transaction. |
| S-05 | Trade Summary and cost | Check the AP/AR, cost, claim, invoice and margin projections on a run-owned order. Re-read a cost create, edit and delete in both the source transaction and the summary. Never modify a source transaction from the summary figures alone. |
| S-06 | Document output | Render Booking Confirmation, MK Packing List, the legacy Packing List, FBOL, Scale Ticket, Local Invoice and Sales Weight Ticket, each from an existing safe record. Reconcile the labels, booking, order and container, the parties, the ports, the weights, and the rates and amounts against the source and API. Print and download are checked only as far as where the file lands and what it contains. |
4. Verdict And Cleanup¶
- [ ] Recorded
PASS/FAIL/BLOCKED/NOT RUNfor each item, with who ran it, when, the record ID and the screenshot, console and network evidence. - [ ] For each
FAIL, recorded the reproduction step, the expected and actual result, the HTTP status and envelope, the console error, the marker and record ID, and whether residual data remains. - [ ] For each
BLOCKED, recorded the exact cause among authority, fixture, provider approval and physical-device dependency. An admin2 pass is not read as a field-role approval. - [ ] Re-read the cleanup result of every run-owned record that was created, changed or soft-deleted. A progressed or externally linked row that cannot be cleaned up keeps its ID and current state and is not deleted arbitrarily.
- [ ] The final report lists, separately, the menu coverage result, the state of C-01 through C-07, the state of S-01 through S-06, the items not run because of external effects, and the remaining authority and fixture gaps.
Current Execution State — 2026-07-20¶
| Scope | State | Basis |
|---|---|---|
| R-01 to R-14 | PASS (route/load + control) |
In an admin2 session, 15 menu routes and the core read APIs returned HTTP 200. The Date, keyword, type, range, refresh and month-load control or the table host of each screen was confirmed in the real UI, and page errors were 0. The Rate screens have no page-level filter, so only host load was confirmed. The row and detail field comparison remains inside each business-scenario evidence scope. |
| Negative authentication | PASS |
A login with an invalid local password was rejected, and in the same browser context an access to a protected Daily Dashboard route redirected to the login screen. |
| C-01 to C-04, C-06 | PASS |
Commercial, inbound→lot, outbound allocation, booking CRUD and preview, atomic rollback and cleanup were confirmed by read-back. |
| C-05 | PASS |
An invalid Due Date, a foreign soft-deleted link, a self link and a duplicate order number were each rejected with HTTP 400, and the disposable rows were 0 active after cleanup. |
| C-07 | PASS |
An overdraw and a foreign lot returned HTTP 400 with no change, and a repeat of the same Apply was confirmed to produce 2 allocations and move the lot 10→8, after which removing the allocations and restoring 8→10 was confirmed. |
| S-01, S-03 to S-04 | PASS |
Scale finalize and the Commodity and Freight Rate CRUD were confirmed with local run-owned fixtures and a cleanup read-back. |
| S-02 | PASS |
The synthetic PDF WP08-18-1784564704734-905949 was AI-extracted in the admin2 Export Brokerage UI, confirming PDF analyzed. and the reference mapping. After review and correction a local job was created and inbound 154075, outbound 154076 and 1 allocation were read back; after Cancel, active order and allocation were 0/0. |
| S-05 | PASS |
On the run-owned outbound 154074, the Outbound Cost AP was created, edited from 12.34 → 23.45 and deleted, and the API re-read and the Trade Summary OUTBOUND_AP_COST_AMOUNT=23.45 projection were confirmed. After the delete there were 0 active cost transactions, and the order and booking were cleaned up. |
| S-06 | PASS (render + field parity + output binding) |
Booking Confirmation, the MK and legacy Packing List, Purchase Local Invoice, Sales Weight Ticket, the physical Scale Ticket and the run-owned FBOL fixture were rendered with HTTP 200. The identifiers of the 7 documents were reconciled against the source and API, as were the Booking Confirmation party and header, every line rate, weight and amount on the Local Invoice and Sales Ticket, the per-axis weights on the physical Ticket, and the FBOL carrier, shipper and consignee. The Booking 57305 Packing Invoice rate autosave and source re-read of 1.25 → 2.5 → 1.25, the print binding of the MK and legacy Packing List and Scale Ticket, and the HTTP response bytes of the legacy Packing List Excel export were confirmed. No real spool or file save was performed. |
Existing Basis And Re-Verification Priority¶
| Existing evidence | Handling in the current checklist |
|---|---|
docs/research/mk/2026-07-19/MK_CLIENT2_VALIDATED_SCREEN_REFERENCE.md: admin2 menu route capture 13/13, GET/HEAD only, 0 business writes |
Re-verify R-01 to R-14 extended to a real session, filters and detail. The document and output surface is separated into S-06. |
docs/research/mk/2026-07-15/MK_CLIENT2_SOURCE_GAP_BASELINE.md: UAT-MK-010/020 complete, 030 to 070 backlog |
Keep C-01 as the CRUD baseline and break the backlog down into runnable units as C-02 to C-07 and S-01 to S-06. |
docs/research/mk/2026-07-17/MK_INBOUND_PURCHASE_TO_INVENTORY_LOT_UAT.md: Inbound → Lot local UAT and cleanup complete |
C-02 must use the same no-scale read-back and cleanup criteria. |
261-wp08-830-mk-booking-packing-preview-uat.md: Booking Confirmation and MK Packing List key field parity |
C-04 and S-06 keep the same booking, container and API comparison, and a file or rate write is not treated as an additional pass. |
43-wp08-07-mk-business-policy-and-field-uat-decisions.md: only admin2 exists, provider approval is gated |
Role tests and external effects are not run automatically. |
Reference Manuals¶
- Screen and route baseline:
docs/research/mk/2026-07-19/MK_CLIENT2_VALIDATED_SCREEN_REFERENCE.md - Overall work flow: Wiki
mk-operations - Detailed procedures: Wiki
mk-commercial-orders,mk-inbound-orders,mk-outbound-orders,mk-booking,mk-schedule-allocation,mk-scale,mk-trade-summary
Source:
docs/runbooks/MK_ADMIN2_FUNCTIONAL_TEST_RUNBOOK.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.