Skip to main content

Audi Ordering — Decisions

The choices the Audi implementation makes on top of AccessAudi Ordering. Only decisions new for Audi are here; the cross-OEM architecture is in the ordering platform ADRs.

1. Dry-run validation via structured rules​

AccessAudi publishes its option rules as data (modelOptionRulesBean) and offers no validation call. The ordering service evaluates those rules itself, in a rule engine under oem/audi/validator.py. The validation activity therefore requires no OMS interface: it evaluates the collected rules against the candidate.

2. Rules come from the product-data collection job​

The rule documents are read from the collected product_models snapshots. The product-data collection job gets a wider refresh window than inventory. Fetching rules during the run through getOptions remains an option if collected rules prove too stale.

3. The cure matches the OMS frontend's auto-selection​

The frontend auto-selects a member of an unsatisfied required option group. The cure does the same, so a configuration we submit matches what the same selections would produce in the OMS. Caps on the count and total price of auto-selected options bound the cure; a candidate over either cap is refused.

4. A dry run stops before addToPendingSubmission​

addToPendingSubmission writes to the OMS and consumes allocation, so the dry/execute boundary sits before it.

5. A submit is never retried​

The submission calls carry no idempotency key, so a submit is never retried on an unknown outcome; see AccessAudi Ordering for how that outcome is reconciled instead.

6. Volume targets fill the carline allocation​

Audi assigns all allocated units to the dealer regardless of how many configurations the dealer submits. When an unconfigured unit is assigned, Audi decides the configuration to produce. Dealers report this; it has not been observed in a capture. Leaving allocation unconfigured therefore does not reduce volume. Each run targets the carline's full remaining allocation, and the optimization decides how that total splits across models and configurations. When a submit re-reads the remainder and finds it gone, the run ends that carline's scope and continues with the next (ADR-015).

7. order_id is the OMS commission number​

The submit assigns the OMS commission number, which the attempt records as order_id. The factory commission number is a different identifier and stays in the attempt's raw payload.