Manufacturer acceptance manual — ZHZN cabinets

For the line technician, QA signer and shipping coordinator using the ZHZN Android vending APK (ai.intelliverse.zhzn.kioskx). Reyeah, a support companion and the operator's phone app have different roles; this procedure does not qualify their hardware.

Illustrated installation atlas and cabinet checklist · Detailed Android sign-off procedure · 中文版 · Printable bilingual factory card

Release prerequisite: choose the approved cabinet APK from Downloads, and verify its identity against the published ZHZN release record. These procedures include the audit repairs; confirm the installed APK, gateway and operator releases contain the required behavior. Publishing an APK or this manual does not deploy the gateway or establish a physical pass.

Shipping requires actual cabinet evidence and two distinct manufacturer signatures. The Android handwritten acceptance certificate and the Partner factory build signature are separate records. A local PASS, queued upload, readyForSignoff value or warehouse receipt does not replace either signature. The receiving operator later completes a separate delivery acceptance and commissioning.

Instructional illustrations simplify screens and hardware. Use the approved cabinet specification and actual UI; the pictures are not wiring diagrams, test results or certificates.

1. Before the first cabinet

For an authorized ADB installation, replace both placeholders with the verified values:

adb -s '<cabinet-adb-serial>' install -r '<verified-zhzn-apk-path>'

A successful install does not establish correct provisioning or device ownership. On a signature, ABI or version refusal, stop and use the approved migration or higher-version fix. Do not uninstall or clear app data to bypass it: credentials, pending reports and vend history must survive.

Have the authorized provisioning owner arm the correct serial/device and let the APK complete /zhzn/enrol. An arm is permission to enroll, not a completed enrollment. Verify enrolled and successful subsequent contact. Resolve needs-arming (428), budget-exhausted (429), needs-key-rescue (409), revoked (403) or no-bootstrap through the identity workflow; do not repeatedly reinstall or issue a competing key.

If accessory tooling uses bootstrap authentication, record the real fitted/absent state at its approved point before enrollment. After enrollment, that endpoint requires the established device key/witness workflow (§6).

2. Open the factory test

1. Complete the physical FAT in §6 before signing. Keep the work area supervised and resolve any active payment, queued vend or unknown outcome before another action or restart.
2. On the kiosk screen, tap the top-left corner seven times within five seconds. Enter the assigned cabinet admin PIN. If refused, ask the provisioning owner to reconcile the cabinet's actual PIN/configuration; do not try a documented default or borrow the owner's cloud password.
3. In the service menu choose Factory test / 工厂测试. Grant camera, microphone and the correct USB-device permissions when required, then rerun an affected test.
4. Verify the approved manufacturer credential is available to the APK through the factory.api-key provisioning workflow and that the actual Partner FAT upload can authenticate. This is separate from enrollment. The key may be cached in app preferences; deleting its source file alone does not remove it. Arrange authorized removal/revocation at handover without wiping device identity or reports.

3. The six tests

Run all six checks on this physical cabinet. The handwritten certificate requires all six to pass with identified camera and board evidence. A skipped required test is unfinished; if the build lacks a required subsystem, escalate the acceptance-profile mismatch rather than inventing PASS.

Do not assume a port from another cabinet is correct. Follow qualified electrical/service procedures before opening or changing internal wiring. Recheck board/USB recovery after the approved restart or adapter reseat.

4. Summary and upload

Review the serial, run, six results, detected camera/board information and installed APK version. Resolve failures while the cabinet is accessible.

• Wait for the diagnostic upload and the Partner FAT upload result. Upload OK confirms the corresponding report was accepted; inspect canSignOff and blockers instead of inferring permission to ship.
• With no network, queued reports/signatures remain unfinished. Restore connectivity, use the supplied retry and read the saved records back. A refusal requires correction of its reason; replaying unchanged rejected data is not a repair.
• The APK files only observed Partner FAT vmc board-communication and screen screen/touch rows. It does not manufacture dispense, power or network passes, or declare optional equipment not_fitted. Two accepted rows do not complete physical FAT.
• Review the latest saved run and results after a rerun. Before final Partner sign-off, file and verify the remaining physical observations (§6). Retain the original order/report when a reply is lost; do not create another sale to investigate it.

5. Sign-off (e-sign)

After actual physical tests, correct accessories and eligible uploads, open Acceptance sign-off / 验收签核:

1. Enter the real Technician name / 技术员姓名, Employee ID / 员工编号 and optional Factory lot / 生产批次.
2. Read and accept the displayed personal attestation. Address clock warnings; do not alter timestamps to make evidence look trusted.
3. Draw the technician's own signature in Sign here with your finger / 请用手指在此签名. A typed name is not a handwritten attestation.
4. Submit once. Wait for SIGNED — acceptance certificate issued, then read the saved certificate back and verify the same serial/run and returned reference. QUEUED or REJECTED is unfinished. Inspect an existing saved certificate after a lost response before signing again.

This Android certificate does not sign the Partner factory build. Complete that second signature last:

1. The authorized manufacturer files final physical FAT results through POST /api/v1/machines/{no}/build/tests, including suite, tester, time and evidence references.
2. Read GET /api/v1/machines/{no}/build; compare latestResults, testSummary and readiness against all ten subsystem dispositions in §6 and the actual cabinet.
3. Only after the evidence is complete, the real authorized signer submits POST /api/v1/machines/{no}/build/signoff with their identity, role and evidence reference.
4. Read the build again and retain the actual factory signature. A later diagnostic rerun can change the observed rows before signing, so review them again. A signed build refuses further test changes; subsequent work needs a service/rework record.

Do not use a laptop-generated green report, simulated cabinet, copied signature or demo order as shipping evidence. The factory/operator read views do not provide an unimplemented factory-write button; use the authorized bench workflow for Partner writes.

6. What the software does not test — record on paper

The six APK diagnostics do not cover the full machine. Perform these checks before §5, then file their actual observations in the final Partner FAT; the paper traveller is supporting evidence, not a substitute upload or signature.

Record pass only when observed, fail for a fault, skip for an unperformed test, and not_fitted only for an actually absent optional subsystem supported by the current catalog. Never use not_fitted for power, vmc, dispense, network or screen, or to hide an untested fitted reader. Read the current catalog/readiness response before signing.

Record fitted/absent photoPrint, powerbank and nayax accessories against this cabinet. The current APK has no accessory scan/write screen. Authorized bench tooling uses /zhzn/factory-attach with cabinet authentication: approved bootstrap before enrollment, established device key/witness afterward. The manufacturer's Partner key is not a replacement. Inspect attachment/binding results and blockers; an absent write can release a binding, so never blanket-mark fitted equipment absent.

For Nayax, preserve the actual sticker Device Number and its leading zeros; do not substitute the shorter Core Machine ID. Verify merchant/settlement ownership separately. For a power bank, verify the real door binding and release/return flow. For an advertised printer, perform a real print. Optional experiences require their own physical acceptance.

Test the destination country/currency/payment profile, correct shopper price, one stock decrement, declined/cancelled/late payment, failed delivery, refund completion, network/power loss and report replay. Native MDB card is one product line and one unit per purchase, online and offline; match reader currency and decimal places. Spark is USD-only; Stripe QR has its own supported-currency and capture-after-delivery quantity limits. Follow the precise payment limits.

A timeout or missing drop does not prove no charge. Resolve the original payment and queued reports without automatic repeat purchases/vends. For held offline inventory, follow the PIN-gated reconciliation procedure after payment/report resolution and a physical stock count. Record enabled age checks, accessibility and optional shopper flows using the shopper acceptance guide.

7. Ship

The shipping coordinator checks the same serial across cabinet plate, software, build, accessories and records. Do not ship until these are complete:

• Observed every-lane FAT, fitted/absent dispositions, destination payment/recovery checks and resolved defects.
• Accepted Android diagnostic and handwritten certificate, plus the final Partner factory build signature, each read back from the server.
• Exact release identities, wiring/port/tray maps, accessory bindings, evidence and certificate/build references.
• Batch/destination/shipping information, support/warranty contact, outstanding limitations and protected credential handover. Do not put passwords or API keys on the crate.
• A final supervised cold start, correct Home/lockdown, board/cloud recovery, no unresolved purchases or queued outcomes, and authorized bench-access cleanup.

A queued upload/signature, missing required record, wrong binding or untested fitted component blocks release. No promised number of minutes replaces these checks. Keep the cabinet unclaimed until the intended operator's claim stage.

8. What headquarters sees

Authorized factory/admin staff review the build, diagnostics, certificate and shipment for the correct serial. Use the supported factory/warehouse read views or Partner API. Warehouse receipt is not operator delivery acceptance and does not make the cabinet live.

The receiving operator uses their own authorized account or accepted scoped crew access; never share an owner's password or MFA code. Follow First-time install: inspect shipping damage, claim the exact machine, review and explicitly confirm its structured address, separately attest actual on-site installation, configure payment and physically load/count stock. Record the actual host agreement or supported no-host arrangement with a reason.

Use the supported web host/delivery-acceptance workflow to inspect the Partner factory signature and record the receiving operator's actual acceptance. The compact native phone app uses its web fallback; a Flutter factory read card does not supply every web acceptance control. Inspect current payment/address/installation/readiness gates, perform the real acceptance purchase and verify order, stock and processor settlement. Production refuses forced go-live with incomplete checks.

Keep Android certificate, Partner manufacturer signature, warehouse receipt, operator delivery acceptance and go-live as separate milestones. One saved status does not establish the others.

9. Escalation

Appendix — the calls behind the screen (for the manufacturer's engineers)

Use only authorized tooling; this table is a route map, not a simulated signing recipe. The current schema, credential scopes and cabinet readback govern each request.

Use the 60-row cabinet checklist for the serial, releases, identity, physical tests, accessories, payment/recovery, both factory signatures, shipment and recipient evidence. Its browser-local export is a working record; it does not submit a signature or synchronize to the cloud.