30 lines
1.2 KiB
Markdown
30 lines
1.2 KiB
Markdown
# Confirmation Export and Recovery Rules
|
|
|
|
## Confirmation export
|
|
|
|
Use `confirmation_export` only for an existing saved order or a confirmed post-save recovery. Require an existing identifier in `data.existing_refs` and a requested confirmation type:
|
|
|
|
- `default` or `xingyou` → Xingyou confirmation source;
|
|
- `liantai` → Liantai confirmation source;
|
|
- `job` → JOB/filing source.
|
|
|
|
Do not infer an identifier from a stale list row, product name, date, or a browser dialog. Do not treat a generated download URL as proof that the artifact was delivered.
|
|
|
|
## Recovery
|
|
|
|
When an order save is already verified but export or PDF delivery failed, create an export-only recovery plan:
|
|
|
|
```json
|
|
{
|
|
"exportOnly": true,
|
|
"neverResave": true
|
|
}
|
|
```
|
|
|
|
Recovery must never create a replacement order, repeat a successful save, or silently change the export type. If save state is uncertain, return `execution_uncertain` and require registry/ERP re-query before any retry.
|
|
|
|
## Boundary
|
|
|
|
A confirmation export is a separate operation from create or update. Do not return a combined create-plus-export operation. PDF conversion is a delivery step after source export, not a reason to resave ERP data.
|
|
|