4.0 KiB
name, description
| name | description |
|---|---|
| erp-update-order | Use when a Codex agent receives a Chinese ERP order modification, supplemental request, or traveler-list attachment for an existing LaoTai/LianTai identifier. |
ERP Update Order
Scope and entry conditions
This Skill converts a change to an existing ERP order into one update_order task. It requires the existing ERP identifier, preserves the source wording, and delegates lookup, form/API mutation, duplicate protection, traveler import, and post-save verification to scripts/run_update_order.js and the existing update handlers.
If the user provides only a customer/product/date without an identifier, return needs_clarification. Do not create a replacement order and do not guess an identifier from a name.
Normalize the update plan
Build updatePlan.actions with explicit targets and operations:
- set: replace a known field with a stated final value.
- delta: add or subtract a stated amount after the script reads the current ERP value.
- append: add text to a remark or special-request field without erasing existing content.
- traveler_upsert or row correction: identify a traveler-list/import action; the execution layer parses the attachment and verifies appended/fixed rows.
Supported verified update areas include room/TWN, remark, room plus remark, traveler-list import, and traveler-row correction. Keep route resolution from the local order registry. Team remarks must preserve the ERP xiadanbeizhu field through the script contract. Price and pax changes remain optional/unverified across routes; ask for explicit confirmation and do not promise them as equivalent to room/remark updates.
Do not convert “overwrite everything” into a broad write. Keep the plan scoped to the named fields and preserve a duplicate-update fingerprint. A repeated identical update is blocked unless the local safety layer explicitly permits a reviewed override.
Traveler attachment boundary
When the user supplies an Excel/CSV traveler list, put the file path in attachments and describe the intended import or correction in updatePlan. Do not open the workbook, read its rows, copy names/passports into task JSON, or invent a traveler count in the Skill layer. The script parses, validates expected totals, imports, and verifies the filled-row count; audit output redacts traveler PII.
Task shape
The ready task includes status: "ready", operation: "update_order", a non-empty identifier, updatePlan with an actions array, attachments, and originalText. A representative plan is:
{
"status": "ready",
"operation": "update_order",
"task": {
"schemaVersion": "erp-task-v1",
"taskId": "task-20260712-002",
"operation": "update_order",
"identifier": "LW-270520A-A",
"updatePlan": {
"status": "ready",
"actions": [
{ "target": "rooms.TWN", "operation": "set", "value": 10 },
{ "target": "remark", "operation": "append", "value": "客户备注" }
]
},
"attachments": [],
"originalText": "原始修改指令"
}
}
If the identifier, target field, final value, delta basis, or attachment intent is ambiguous, return needs_clarification and do not call the runner.
Script handoff
Use:
node scripts/validate_erp_task.js --task <task.json> --json
node scripts/run_update_order.js --task <task.json> --mode dry-run --config config/erp-deployment.local.json --json
The default is dry-run. Real execution still requires config and sender authorization, duplicate protection, session readiness, and explicit authorization. The Skill cannot enable allowRealSubmit.
Results and recovery
Report success only when the script confirms the update after ERP re-query. A blocked result names the missing identifier, ambiguous lookup, duplicate fingerprint, unsupported field, failed traveler verification, or safety gate. An execution_uncertain result must be re-queried before retrying. An attachment/export failure after a confirmed update must use its recovery path and must not re-save unrelated fields.