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.

2.6 KiB Raw Permalink Blame History