37 lines
3.3 KiB
Markdown
37 lines
3.3 KiB
Markdown
# Operation Matrix
|
|
|
|
| Action | Chinese intent | Agent task minimum | ERP resolution / execution boundary |
|
|
|---|---|---|---|
|
|
| `team_order_create` | 团队-单个下单 | product, one date, pax, rooms, prices, op, sales | ERP derives/checks customer, route, trip and order prefix from the product template; preflight still requires all target fields. |
|
|
| `team_order_batch_create` | 团队-批量下单 | Same user facts, at least two dates, one product | Resolve each date through the team-single path; native batch remains deferred. |
|
|
| `shared_plan_create` | 散拼-创建母团计划 | product, departure_dates, planned_capacity, op_user | Current root path is read-only planning/probing. |
|
|
| `shared_child_order_create` | 散拼-录入子单 | customer, pax, prices, op, sales, parent reference or unique product/date | Parent association must be exact; current root path is read-only planning/probing. |
|
|
| `order_update` | 修改已有订单 | existing_refs, explicit updates/actions | Only named targets; delta needs a baseline; current root path previews before edit submit. |
|
|
| `passenger_list_import` | 旅客名单导入/补充 | existing_refs plus attachment or passenger_list intent | Paths and metadata only; file rows remain in the deterministic import layer. |
|
|
| `confirmation_export` | 确认件导出/恢复 | existing_refs plus confirmation type | Export-only; recovery must never resave. |
|
|
|
|
## Action selection
|
|
|
|
- Prefer explicit business labels such as “下单模式”, “操作类型”, “订单编号”, “确认件类型”.
|
|
- Use natural-language synonyms only when they resolve to one action.
|
|
- If creation and export/update appear in one request, return clarification/block instead of combining them.
|
|
- A parent plan is not a customer order and cannot be treated as an exportable order.
|
|
|
|
## Shared data rules
|
|
|
|
- `customer`, `product`, `route`, `op_user`, and `sales_user` are named business references. The runtime resolves accepted ERP records; the Agent does not invent IDs.
|
|
- `departure_dates` uses ISO dates. Single-create has exactly one; batch-create has at least two; child order has exactly one.
|
|
- `passenger_counts` uses `adult`, `child_bed`, `child_no_bed`, `infant`, `leader`, and optional `expected_total`.
|
|
- `room_counts` uses `SGL`, `TWN`, `TRP`, `DBL`, `HNM`, and `TL`.
|
|
- `prices` preserves explicit user prices and optional item rows; do not infer missing prices.
|
|
- `existing_refs` must carry an existing identifier for update, traveler, or export actions.
|
|
|
|
## Team-order field ownership
|
|
|
|
The parser and ERP do not own the same fields:
|
|
|
|
- Agent-owned facts: product, departure date(s), passenger counts, rooms, explicit prices, OP, salesperson, order nature, and any user-supplied customer/route/trip/order number.
|
|
- ERP-owned resolution: after exact product selection and `Find_product/GetProduct`, the ERP derives or validates trip, route, customer, currency, and route-based order prefix. The ERP execution layer also supplies or validates the order suffix according to the business task/test policy.
|
|
- If an Agent task omits customer, route, trip, or order number, record the omission in `data.resolution.deferred_fields`. Do not invent hidden IDs or visible names.
|
|
- `agent_parse_passed` means task creation is allowed. ERP preflight remains responsible for resolving every required LTJT form target before any write.
|