---
name: erp-create-order
description: 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.