145 lines
13 KiB
Markdown
145 lines
13 KiB
Markdown
# LTJT System Operation Scope
|
|
|
|
Date: 2026-07-07
|
|
|
|
## Purpose
|
|
|
|
This document narrows the pure business background into the part that should be automated against the LTJT system.
|
|
|
|
The business document defines how WeChat instructions are understood, checked, clarified, and replied to. The LTJT adapter should not consume raw chat text directly. It should only receive a validated, standard operation object from the user's business system/database and then perform a deterministic system action.
|
|
|
|
## Layer Boundary
|
|
|
|
### Upstream business layer
|
|
|
|
Responsible for:
|
|
- Identifying the action type from the customer's instruction.
|
|
- Checking whether one message contains exactly one business action.
|
|
- Asking follow-up questions when fields are missing or ambiguous.
|
|
- Confirming risky passenger-list operations such as modify, delete, replace, full replace, or passenger reduction.
|
|
- All active orders are production/formal; the upstream business system's explicit confirmation, server execution ID, and plugin guard control the write boundary.
|
|
|
|
This layer may use AI during drafting or customer-service assistance, but it must produce structured data and explicit human/system validation results before the LTJT adapter writes anything.
|
|
|
|
### Standard operation layer
|
|
|
|
Responsible for converting approved business intent and database-maintained field data into a stable object, for example:
|
|
- `action`: `team_order_create`, `team_order_batch_create`, `shared_plan_create`, `shared_child_order_create`, legacy `order_update`, `passenger_list_import`, five `arrangement_*`, three route-specific `order_update_*`, `order_cancel`, edit-only `order_restore`, guarded `order_delete`, `confirmation_export`
|
|
- `order_nature`: active operations use `formal`; `test` remains historical compatibility only
|
|
- `product`, `route`, `departure_dates`
|
|
- `customer`
|
|
- `passenger_counts`
|
|
- `room_counts`
|
|
- `shared_plan_create` uses `planned_capacity` and top-level `room_counts` as required mother-plan fields. ERP-supported child information is represented by optional `split_order.customer` and `split_order.passenger_counts`; each may be supplied independently and is written only when present.
|
|
- optional `prices` overrides for compatibility; active product selection/GetProduct owns linked pricing
|
|
- optional `op_user`, `sales_user`; active runtime resolves login-default staff when omitted
|
|
- optional flight, hotel, transfer, special-request, attachment, and passenger-list fields
|
|
- existing `order_no`, `plan_no`, or `child_order_no` where required
|
|
|
|
The LTJT adapter should treat this object as its only input contract.
|
|
|
|
The user's own business system/database is expected to maintain the source data for these fields, including customer, product, route, passenger counts, room counts, price rules, OP/salesperson assignment, order status, passenger-list metadata, and any configured defaults. The LTJT adapter should not create business meaning from unstructured text; it should only validate and translate the standard object into LTJT's form contract.
|
|
|
|
### LTJT system operation layer
|
|
|
|
Responsible for:
|
|
- Opening the correct LTJT page in an approved session.
|
|
- Resolving system-side customer/product/staff/resource values through exact-match or configured deterministic matching.
|
|
- Filling the target form or building the same form-encoded request as the page.
|
|
- Running dry-run serialization and validation.
|
|
- Submitting only after deterministic checks pass and write permission has been explicitly enabled.
|
|
- Reading the created or updated system identifier from the response/page.
|
|
|
|
This layer should not make AI judgments at runtime.
|
|
|
|
## Operation Matrix
|
|
|
|
| Business action | System operation target | Current discovery status | Next technical work |
|
|
|---|---|---|---|
|
|
| 团队-单个下单 | 独立团计划表 -> 下单 -> `/System/Business/orders_add.asp` -> `POST /System/DAT/orders.asp` with `Act=DoInfoJH` | Extension has the guarded formal preflight/submit path. Product/GetProduct derives linked route, customer, staff defaults and prices; the ERP group-number receipt is used for re-query. | Reverify against the current production account and current product-template price-row positions. |
|
|
| 团队-批量下单 | 独立团计划表 -> per-date `team_single` fallback | Native `DoInfoJHs` remains unverified; the root plugin executes formal tasks serially through the verified single-order path and stops on the first incomplete date. | Keep the fallback as the active contract until native batch behavior is separately captured. |
|
|
| 散拼-创建母团计划 | 散拼团计划表 -> `/System/Business/plan_add.asp?fabudanwei=...` | Extension fills required mother-plan fields and conditionally fills supported `split_order` customer/passenger fields, submits `DoInfoSPs`, and re-queries the returned parent group. | Complete one authorized real save with the optional-field matrix and retain the response/requery evidence. |
|
|
| 散拼-拼单/录入子单 | 散拼团计划表 -> existing plan -> `/System/Business/plan_order.asp?tdid=...` | Handoff parent lookup, child fields, duplicate guard, and page probe are absorbed. Root plugin does not save a child order. | Capture the child form submit evidence and parent-after re-query in the extension context. |
|
|
| 补充/修改订单 | Existing order lookup -> edit page, likely `orders_add.asp?ddid=...` or related detail pages | Handoff structured `set/delta/append` rules are absorbed. Root plugin locates a unique order candidate and produces a no-write preview; no edit submit is enabled. | Capture edit-frame snapshot and submit-intercept evidence for room/remark changes on a dedicated test order. |
|
|
| 游客名单导入/补充 | Order detail or team/passenger-related pages, TBD | Handoff attachment-path, traveler-upsert, parser, count-check, and PII-redaction boundaries are absorbed. Root plugin verifies task intent and order candidate only; it does not read local workbooks or import rows. | Capture the actual import frame/upload route and row-count verification in the browser plugin. |
|
|
| 导出确认件 | Existing order -> confirmation/export page, TBD | Handoff export-only/recovery rules and Xingyou/Liantai/JOB source-path mapping are absorbed. Root plugin locates the order and builds source URLs without re-saving or claiming delivery. | Capture download/file-delivery behavior and explicit artifact verification. |
|
|
|
|
## Submit Preconditions
|
|
|
|
The adapter must refuse to submit when any of these are true:
|
|
- The action type is missing or maps to more than one LTJT workflow.
|
|
- `order_nature` is missing for a write operation.
|
|
- Required business fields are missing for the selected action.
|
|
- A batch order contains more than one product.
|
|
- Product, customer, OP, salesperson, route, or resource lookup returns zero or multiple acceptable matches.
|
|
- Product `GetProduct(cpm)` side effects are not executed in the browser before serialization.
|
|
- Product-template fields are empty or disagree with an explicitly supplied standard-operation value for product, trip, route, route prefix, customer, or customer id.
|
|
- Product-generated receivable rows and prices are not preserved, or passenger quantities/derived amounts cannot be updated deterministically.
|
|
- Passenger-list count exceeds order passenger count.
|
|
- Passenger-list operation is modify, delete, replace, full replace, or reduction without explicit confirmation.
|
|
- A modification/export request lacks the required existing order number, plan number, or child order number.
|
|
- The LTJT page returns login-expired or permission-alert JavaScript.
|
|
- The live page schema differs from the versioned mapping used by the adapter.
|
|
- Dry-run serialization fails required-field, hidden-id, currency/unit, count, or generated-order-number checks.
|
|
- The page's own `SubmitInfoForm()` has not been tested through an AJAX intercept that prevents `DoInfoJH` from reaching the network.
|
|
- A live submit is attempted without a passed real browser preflight report, a passed real submit-intercept report, matching payload SHA-256 values, `--execute-live-submit`, and the exact approval token.
|
|
|
|
## Business-To-System Gaps
|
|
|
|
- The active business template for 团队-单个下单 explicitly requires 预订客户/组团社; the plugin re-applies it after the product “更新行程” side effect instead of trusting the product template customer.
|
|
- The active 散拼团新增计划 template treats customer and passenger controls as optional: the plugin fills each supplied supported field independently and leaves absent fields untouched.
|
|
- The LTJT form stores receivable rows with item, unit, currency, quantity, unit price, amount, payment-state metadata, and remarks. Product/GetProduct owns the template row and unit price; the plugin updates category quantities and derived amounts without clearing the template.
|
|
- `游客名单附件` is not proven to be the same as the general `PicFile0/PicFile1` attachment fields in `orders_add.asp`. The actual passenger-list import workflow still needs capture.
|
|
- `确认件类型` is defined by the business template, but the LTJT export endpoint and parameters are still unknown.
|
|
|
|
## Handoff Absorption Boundary
|
|
|
|
The business system and plugin accept the active create and confirmation actions plus historical compatibility actions. The three `lwlt-newbooking` behaviors are connected to guarded formal create paths, and `lwlt-confirmation` is connected to export-only source reads. `lwlt-updating` and `lwlt-arrangement` remain Skill-level stable blockers because their formal operation contracts are not published; they must not fall back to unrelated compatibility actions.
|
|
|
|
## Priority Path
|
|
|
|
The first practical integration target should remain:
|
|
|
|
`team_order_create` -> 独立团计划表下单 -> `orders_add.asp` -> `Act=DoInfoJH`
|
|
|
|
Reasons:
|
|
- It matches the user's stated priority: 独立团计划表内的下单功能.
|
|
- The save endpoint, required fields, page validation flow, and full field schema are already captured.
|
|
- It can be implemented as a deterministic dry-run serializer before enabling any real submit.
|
|
|
|
## Non-AI Runtime Contract
|
|
|
|
Production runtime should be:
|
|
|
|
`business system/database -> standard operation JSON -> versioned mapping -> lookup resolution -> page-context fill -> ListForm.serialize() -> deterministic validation -> optional submit`
|
|
|
|
AI can help maintain discovery notes and propose mapping drafts, but the deployed operation path should be rules, schemas, and tests.
|
|
|
|
## Immediate Build Artifacts
|
|
|
|
Built first-pass artifacts:
|
|
- `schemas/standard_system_operation.schema.json`
|
|
- `mappings/orders_add.mapping.json`
|
|
- `tools/dry_run_order_create.mjs`
|
|
- `tools/browser_order_add_dry_run.mjs`
|
|
- `tools/browser_order_add_preflight.mjs`
|
|
- `samples/team_order_create.dry-run.example.json`
|
|
|
|
Current preflight behavior is non-submitting until the business system confirms the task: it validates a standard operation, resolves product and login-default fields, runs `Find_product/GetProduct`, preserves linked pricing rows, and captures the page's `ListForm.serialize()`/`DoInfoJH` payload hash. The confirmed executor then submits once and re-queries the ERP receipt.
|
|
|
|
Important SelectBox constraint: the live LTJT page uses `SelectBox` widgets for many visible text fields. These are not free-text fields for production. The adapter must exact-match one existing LTJT option and apply the widget's linked `SetVal` fields before any submit. This applies at minimum to route, product, customer, OP, salesperson, hotel, restaurant, attraction, flight, and receivable/resource fields.
|
|
|
|
For `team_order_create`, submit readiness now requires this non-writing sequence:
|
|
- lookup resolution passes for all critical SelectBox fields
|
|
- browser-context preflight executes product/page side effects such as `GetProduct(cpm)`
|
|
- product-template route/trip/customer/core metadata is nonempty and matches any explicitly supplied standard-operation value
|
|
- product-owned receivable rows and prices are preserved; passenger quantities and derived amounts are updated after product side effects
|
|
- final live `ListForm.serialize()` passes required-field and count checks
|
|
- submit-intercept dry run captures exactly one prevented `DoInfoJH` request and no validation alerts
|
|
- approved submit, if used, verifies the current browser payload SHA-256 still matches the approved preflight/intercept hash immediately before allowing the page's real AJAX request
|
|
- post-submit verification confirms the ERP group-number receipt is visible in the authorized `JH_OrderList` response; historical test markers are only a fallback
|
|
|
|
## Controlled Submit Status
|
|
|
|
The independent-team create-order path uses the same guarded pipeline for formal production operations. A business-system confirmation is not a bypass: deterministic lookup, product-side-effect, preflight, submit-intercept, execution-ID, payload-hash, write-started, and post-operation receipt verification remain mandatory.
|