Microsoft Dynamics 365 Order Integration

You are building a production-grade order-integration service. You have ONE attempt — a single
agentic run, no follow-up questions, no second chances. You will be judged on whether real
orders actually land correctly in Dynamics 365, on idempotency, on resilience to a hostile API,
on input validation, and on credential hygiene. Correctness is verified by inspecting what your
service actually wrote into the system — not by reading your code's intentions. Stubbing,
faking, or asserting success without really integrating scores zero.

THE JOB
Build a runnable Node service, in the current working directory, that accepts shop orders and
transfers them — with ALL relevant data — into Microsoft Dynamics 365 via the provided mock
Dynamics 365 Web API. "All relevant data" means: the customer, the billing AND shipping
addresses, every line item (sku, name, quantity, unit price, line tax, line total), the order
totals (net, tax, gross, shipping, discount), the currency, the payment method and the shipping
method — mapped exactly per the provided gold mapping.

OUTPUT CONTRACT (mandatory — the harness enforces every line of this)
- Start command is exactly `node server.mjs`. No build step, no install step.
- Node standard library ONLY. You may NOT use any npm package — there is no `npm install` at
  evaluation time and `node_modules` will not exist. Use the built-in `node:http`/`fetch`, etc.
- Read ALL connection config from environment variables:
  - `PORT` — the port your HTTP server must listen on.
  - `D365_BASE_URL` — base URL of the Dynamics 365 API (e.g. `http://127.0.0.1:53110`).
  - `D365_TOKEN` — the bearer access token. Send it as `Authorization: Bearer <D365_TOKEN>`
    on every Dynamics call.
  - NEVER hardcode the base URL or token, and NEVER print the token (or any secret) to
    stdout/stderr or write it into a file. The source tree and the logs are scanned for it.
- Expose `GET /health` returning HTTP 200 (any small JSON body) so readiness can be detected.
- Expose `POST /sync-order`:
  - Request body is a single shop order as JSON (schema below).
  - On success: respond `200` or `201` with a JSON body that includes at least
    `{ "status": "...", "salesorderId": "...", "idempotent": <bool> }`. `idempotent` is `true`
    when this exact order had already been synced (see IDEMPOTENCY).
  - On a malformed/invalid order: respond with an HTTP `4xx` status and a STRUCTURED JSON error
    body, e.g. `{ "error": { "code": "...", "message": "...", "fields": ["..."] } }`. A rejected
    order must write NOTHING to Dynamics — no partial customer, address, order or lines.

THE SHOP ORDER (input) — a realistic Shopware-ish shape
```
{
  "idempotencyKey": "ord_10001",            // stable per logical order; your dedupe key
  "orderNumber": "10001",
  "orderDate": "2026-06-01T10:00:00.000Z",
  "currency": "EUR",                          // ISO 4217; map UPPERCASE
  "currencyFactor": 1.0,                       // exchange rate to base currency
  "paymentMethod": "invoice",                 // code; map via gold valueMap
  "shippingMethod": "dhl_standard",            // code; map via gold valueMap
  "customer": {
    "customerNumber": "C-1001",
    "email": "jane.doe@example.com",
    "firstName": "Jane", "lastName": "Doe",
    "company": "Doe Logistics GmbH",          // present => business customer (D365 account)
    "vatId": "DE123456789",                    // optional
    "taxExempt": false
  },
  "billingAddress": {
    "firstName": "Jane", "lastName": "Doe", "company": "Doe Logistics GmbH",
    "street": "Hauptstrasse 1", "additionalLine": "Building C",
    "zipcode": "10115", "city": "Berlin", "state": "Berlin",
    "countryCode": "DE", "phone": "+49 30 1234567"
  },
  "shippingAddress": { ...same shape as billingAddress... },
  "lineItems": [
    { "sku": "SKU-1", "name": "Product One", "quantity": 2,
      "unitPrice": 19.99, "taxRate": 19, "taxAmount": 7.60, "lineTotal": 39.98 }
  ],
  "totals": { "net": 39.98, "tax": 7.60, "gross": 47.58, "shipping": 4.90, "discount": 0 }
}
```

WHAT TO BUILD INTO DYNAMICS (the entity graph)
For every accepted order, produce this graph in Dynamics, mapping fields EXACTLY as defined in
`fixtures/mapping.gold.json` (read it — it is the unambiguous source of truth, including the
value maps for payment/shipping methods and which fields are rounded/uppercased):
1. A **contact** (the person) — upserted by `emailaddress1`.
2. An **account** (the company) — upserted by `accountnumber` — ONLY when `customer.company`
   is non-empty. The order's customer is the account when a company exists, otherwise the contact.
3. A **Bill To** and a **Ship To** customer address — upserted per customer by address type.
4. A **salesorder** — created idempotently (see below) and linked to the customer and to both
   addresses.
5. One **salesorderdetail** line per order line item — linked to the salesorder.

THE DYNAMICS 365 MOCK API (provided in `fixtures/mock-d365`)
It is a dependency-free Node server speaking a simplified Dataverse Web API. Endpoints
(all data endpoints require `Authorization: Bearer <D365_TOKEN>`; base path `/api/data/v9.2`):
- Lookup (returns `{ "value": [ ... ] }`):
  - `GET /api/data/v9.2/contacts?emailaddress1=<email>`
  - `GET /api/data/v9.2/accounts?accountnumber=<number>`
  - `GET /api/data/v9.2/customeraddresses?_parentid_value=<id>&addresstypecode=<1|2>`
- Create (returns `201` with the created record INCLUDING its id field):
  - `POST /api/data/v9.2/contacts`            -> body fields, returns `{ ..., "contactid": "..." }`
  - `POST /api/data/v9.2/accounts`            -> returns `{ ..., "accountid": "..." }`
  - `POST /api/data/v9.2/customeraddresses`   -> returns `{ ..., "customeraddressid": "..." }`
  - `POST /api/data/v9.2/salesorders`         -> returns `{ ..., "salesorderid": "...",
                                                  "idempotentReplay": <bool> }`
  - `POST /api/data/v9.2/salesorderdetails`   -> returns `{ ..., "salesorderdetailid": "..." }`
- Update (optional, for upsert): `PATCH /api/data/v9.2/<set>(<id>)`.

IDEMPOTENCY (hard requirement)
- When you create the salesorder, send the order's `idempotencyKey` in the
  `Idempotency-Key` request header. The mock dedupes salesorder creation on this key: a repeated
  key returns the EXISTING salesorder with `idempotentReplay: true` instead of creating a new one.
- Re-submitting the same order (same `idempotencyKey`) to your `/sync-order` MUST result in
  exactly ONE salesorder and NO duplicated line items. If the salesorder POST comes back as an
  idempotent replay, do not create its line items again.

RESILIENCE (the mock fights back)
- The mock injects transient faults: HTTP `429` (with a `Retry-After` header) for rate limits,
  HTTP `500`, dropped/reset connections, and slow `504` timeouts — on the first N attempts of
  specific endpoints. You MUST retry with backoff (respect `Retry-After`), survive these, and
  still end up with the correct, non-duplicated entity graph. Do not hammer the API; back off.
- Never let a transient fault corrupt state (no half-written orders, no orphaned duplicates).

VALIDATION (no partial writes)
- Validate every order before touching Dynamics: required fields present, valid email, non-empty
  line items, non-negative quantities/prices, totals internally consistent, known currency.
- On any violation, return a `4xx` with a structured error and write NOTHING to Dynamics.

ENGINEERING BAR
- Cleanly separate the mapping layer (shop order -> D365 entities) from the transport layer
  (HTTP client with retry/backoff/idempotency). Both are read and judged for maintainability.
- Helpful, structured error reporting and sane logging (without leaking secrets).

You read the fixtures (`fixtures/orders/*.json`, `fixtures/mapping.gold.json`, and the mock under
`fixtures/mock-d365`) to learn the exact shapes. There are no follow-up questions and only a
single run. Start implementing immediately.