4.2 KiB
name, description
| name | description |
|---|---|
| erp-create-order | Use when a Codex agent must turn a validated Chinese travel order into one LaoTai/LianTai ERP create_order task for team_single, team_batch fallback, split_parent, or split_child. |
ERP Create Order
Scope
This Skill owns route selection and field normalization for new orders. It produces one create_order task and delegates all ERP form/API work to scripts/run_create_order.js and the existing route executors. It never invents a product, customer, parent group, identifier, or missing price.
The four supported route values are team_single, team_batch, split_parent, and split_child. The task contract is documented in references/create-task-contract.md.
Route decision
team_single
Use for one ordinary group order on one departure date. Normalize the booking customer, exact product mapping, date, pax, rooms, prices, OP, salesperson, and remarks. The team-single payload must write the booking customer explicitly and the script must verify the saved identifier by ERP evidence/re-query.
team_batch
Use when the user provides multiple departure dates for one product and batch semantics are clear. Preserve date-specific pax, room, price, and remark adjustments. Native DoInfoJHs batch behavior is deferred until separately verified; the safe runtime uses the verified team_single fallback loop when enabled. Never claim that the native batch endpoint ran.
split_parent
Use for a parent plan with a date range/list, cycle, planned pax, and groups-per-date. Expand dates only when the request is unambiguous. Product mapping and date-to-parent-group mapping must be deterministic; after save, use ERP success evidence and date-aware re-query.
split_child
Use for a child order attached to a parent group or an unambiguous product/date lookup. Require the exact parent group, or a unique runtime lookup. If more than one parent/product/customer candidate remains, ask for clarification. Do not fabricate a parent number.
Field and safety rules
- Create exactly one route task per user request. A request that also asks for a confirmation export becomes a separate later export_confirmation task.
- Preserve the full source text in task.originalText; use schemaVersion: "erp-task-v1".
- Normalize dates to YYYY-MM-DD. Do not guess timezone, dates, pax, room counts, prices, OP, or salesperson.
- Customer and product mappings must be unique. “Closest” or fuzzy-only matches are not sufficient for real submit.
- Keep attachments as paths only. Traveler workbook parsing/import and row-count verification belong to the execution layer.
- Use delivery.confirmation: "deferred" unless confirmation output is explicitly handled as a separate task. Creation does not automatically re-save or export a confirmation.
- Default runner mode is dry-run. The Skill must not put allowRealSubmit or authorization codes into the task.
Task shape
The ready envelope contains status: "ready", operation: "create_order", a supported route, and a task object with schemaVersion, taskId, operation, route, fields, attachments, originalText, and delivery. A team-single fields object includes bookingCustomer, productName, departureDate, pax, rooms, prices, op, and salesperson.
When required data is missing or ambiguous, return status: "needs_clarification" and list the exact questions. Do not call a route handler.
Script handoff
Run the operation-specific wrapper after validation:
node scripts/validate_erp_task.js --task <task.json> --json
node scripts/run_create_order.js --task <task.json> --mode dry-run --config config/erp-deployment.local.json --json
The wrapper calls the common dispatcher and does not import browser-operation modules directly. A dry-run only returns a plan. An execute call is allowed only when local config, sender authorization, duplicate checks, session safety, and explicit user authorization all pass.
Completion and recovery
Report completed only when the script returns ERP-verified identifiers. A browser dialog, HTTP 200, or guessed list row is not enough. If save evidence is uncertain, return execution_uncertain and re-query before retrying. If save succeeded but export failed, report the saved identifier and hand off to erp-export-recovery; never create the order again.