40 lines
2.6 KiB
Markdown
40 lines
2.6 KiB
Markdown
# Create-Order Rules
|
|
|
|
## Team single
|
|
|
|
Use `team_order_create` for one ordinary group order on one departure date. Require:
|
|
|
|
- product;
|
|
- one ISO departure date;
|
|
- non-zero passenger counts with a matching expected total;
|
|
- rooms and explicit prices;
|
|
- OP and salesperson;
|
|
- `order_nature` and `submit_mode=dry_run`.
|
|
|
|
Customer, route, trip, and order-number parts are optional Agent facts. When absent, mark them in `data.resolution.deferred_fields`. The ERP flow must select exactly one product, run `Find_product/GetProduct`, derive the linked trip/route/customer/currency/route prefix, resolve staff and other SelectBox values, and only then satisfy the form's required fields. A product name is not proof that the ERP product is unique.
|
|
|
|
If the user explicitly supplies customer, route, trip, or order number, preserve it. The ERP preflight must compare explicit values with the product-template result and block on mismatch.
|
|
|
|
For `order_nature=test`, keep an explicit test marker or generate `RAWTEST-ERP-YYYYMMDD` from the single departure date. The downstream raw-instruction test uses the marker as the visible `tuanxuhao2` test suffix; formal order suffixes remain a business-system/ERP responsibility.
|
|
|
|
The runtime must exact-match SelectBox-backed values, rebuild standard-owned receivable rows, serialize the form, and verify any approved save by an ERP re-query. `agent_parse_passed` does not claim that these ERP steps have happened.
|
|
|
|
## Team batch
|
|
|
|
Use `team_order_batch_create` only when there are at least two dates for one product. Keep date-specific pax/room/price adjustments separate. Native `DoInfoJHs` is deferred; plan a sequence of team-single operations, one per date, and never claim that native batch execution occurred.
|
|
|
|
## Shared parent plan
|
|
|
|
Use `shared_plan_create` for a date range/list, recurrence, planned capacity, and plans-per-date. Do not fabricate a parent number. Until the parent form and save/re-query are separately verified, return a read-only plan or capability result.
|
|
|
|
## Shared child order
|
|
|
|
Use `shared_child_order_create` for a child order attached to an existing parent group or a unique product/date lookup. Require an exact `existing_refs.parent_group_no` when supplied. If more than one parent, product, customer, or date candidate remains, block and request clarification.
|
|
|
|
## Common prohibitions
|
|
|
|
- Never use “closest” product/customer/parent selection for a write.
|
|
- Never replace an explicit customer with the product template's default customer without a consistency check.
|
|
- Never let a user phrase enable real submit.
|
|
- Never report an ERP identifier until the runtime returns durable evidence.
|