You got it—here’s the same style of breakdown for **`VehicleDamageEstimateChgRq`** (the *change request* variant). I pulled this straight from your XSD set and focused on what differs from `…AddRq`, what’s required vs optional, and what a minimal-but-valid payload looks like. --- # What it is & where it lives * **Global element**: `VehicleDamageEstimateChgRq` * **Namespace**: `http://www.cieca.com/BMS` * **Defined in**: `BMSEstimateMessages_2024R1_V6.9.0.xsd` * **Type**: `EstimateChgRqType` (declared in `BMSEstimateCommonTypes_2024R1_V6.9.0.xsd`) * **Service group**: `EstimateService` from `BMSEstimateService_2024R1_V6.9.0.xsd` Group includes: `PropertyDamageEstimateAddRq/Rs`, `VehicleDamageEstimateAddRq/Rs`, * *`VehicleDamageEstimateChgRq/Rs`**, `VehicleDamagePhotoEstimateAddRq/Rs`. --- # Top-level schema (for `VehicleDamageEstimateChgRq` → `EstimateChgRqType`) `EstimateChgRqType` **extends** `MessageHeaderType` (same header as `…AddRq`) but the **body is almost entirely optional** (intended to send only what’s changing). Only **`DocumentInfo`** is required. **Header (inherited from `MessageHeaderType`):** * **`RqUID`** (UUID) — **required** * `AsyncRqUID` (UUID) — *optional* * `PartnerKey` (Identifier) — *optional* **Body (from `EstimateChgRqType`):** * `SvcProviderName` (Identifier) — *optional* * `RefClaimNum` (Char\_50) — *optional* * **`DocumentInfo`** (`DocumentInfoType`) — **required** * `ApplicationInfo` (`ApplicationInfoType`) — *optional, 0..*\*\* * `EventInfo` (`EventInfoType`) — *optional* * `AdminInfo` (`AdminInfoType`) — *optional* * `EstimatorIDs` (`EstimatorIDsTypeType`) — *optional* * `ClaimInfo` (`ClaimInfoType`) — *optional* * **Choice** — *both optional*: * `VehicleInfo` (`VehicleInfoType`) — *optional* * `PropertyInfo` (`PropertyInfoType`) — *optional* * `ProfileInfo` (`ProfileInfoType`) — *optional* * `DamageLineInfo` (`DamageLineInfoType`) — *optional, 0..*\*\* (send only changed/affected lines) * `NonNewOEMPartInd` (Boolean) — *optional* * `StorageDuration` (Integer\_Range\_0-999) — *optional* * `RepairTotalsInfo` (`RepairTotalsInfoType`) — *optional, 0..*\*\* * `RepairTotalsHistory` (`RepairTotalsHistoryType`) — *optional, 0..*\*\* * `PaymentInfo` (`PaymentInfoType`) — *optional* * `EstimateMemo` (C) — *optional* * `AdministrativeMemo` (C) — *optional* * `Disclaimers` (C) — *optional* * `CustomMemo` (C) — *optional* * `CustomPrintImage` (C) — *optional* * `OtherMemos` (`OtherMemosType`) — *optional, 0..*\*\* **Key deltas vs `VehicleDamageEstimateAddRq`:** * `…AddRq` *requires* several containers (`AdminInfo`, `EstimatorIDs`, `ProfileInfo`, `DamageLineInfo`, `RepairTotalsInfo` with `SummaryTotalsInfo`, etc.). * `…ChgRq` **only requires** `MessageHeaderType/RqUID` and **`DocumentInfo`**; everything else is optional so you can send *just what changed*. * `CalibrationInfo` and `ScanInfo` (present in `…AddRq`) are **not** present in `EstimateChgRqType`. * Because almost everything is optional, **the burden is on you** to correctly identify the target document/version in `DocumentInfo` (or via `ReferenceInfo`) and to include all fields necessary for the receiver to apply your changes. --- # Important dependent types (same as Add, but optional here) * **`DocumentInfoType`** (BMSCommonGlobalTypes) — **required** * Use this to identify *which* estimate you’re changing. Typical: * **`BMSVer`** = `6.9.0` * **`DocumentType`** = `E` (estimate) * `DocumentID` — your estimate ID * `CreateDateTime` — when you formed this change message * `ReferenceInfo` — link back to the prior/authoritative doc (e.g., original `DocumentID`/ `DocumentVer`), if your workflow uses references * `DocumentVer` — version info list, if you lifecycle versions * **`ApplicationInfoType`** — software fingerprint (optional, 0..\*) * **`AdminInfoType`** — parties/roles (optional) * **`EstimatorIDsTypeType`** — supplemental estimator IDs/history (optional) * **`ClaimInfoType`** — claim-level data (optional) * **`VehicleInfoType`** (or `PropertyInfoType`) — vehicle path stays under `VehicleInfo` (optional) * **`ProfileInfoType`** — rates/taxes/rules (optional) * **`DamageLineInfoType`** — **send changed/added/removed lines only** (your trading partner may require specific flags/LineStatusCode or use `ParentLineNum`+`UniqueSequenceNum` to identify updates) * **`RepairTotalsInfoType`** — updated totals (optional; some partners expect totals to reconcile with changed lines) * **`PaymentInfoType`**, memos, custom print/image & `OtherMemos` — all optional > Because `ChgRq` is sparse by design, **schema validation won’t catch semantic issues** (e.g., you > remove a part but don’t update totals). Make sure your payload is self-consistent per partner > rules. --- # Minimal, schema-valid XML skeleton (change request) > This represents the *absolute floor* to validate: **Header/RqUID** + **DocumentInfo** with basic > fields. In practice, include `DocumentID` and some way to reference the prior document/version so > the receiver can apply changes. ```xml 00000000-0000-0000-0000-000000000000 6.9.0 E 2025-08-14T12:00:00Z ``` --- # Practical guidance & gotchas 1. **Targeting the right document/version** * `DocumentInfo/DocumentID` + `DocumentVer` and/or `ReferenceInfo` should point unambiguously to the estimate being changed. This is essential because the schema does **not** include a separate “ChangeTarget” field—partners expect this info in `DocumentInfo`/`ReferenceInfo`. 2. **Sparsity vs completeness** * You can send just the changed sections (e.g., one `DamageLineInfo`, one `RateInfo`). * Some receivers require you to **also** include reconciled `RepairTotalsInfo/SummaryTotalsInfo`. Check partner specs. 3. **Line identity** * If you’re updating an existing line, keep its identity stable using `LineNum` and/or `UniqueSequenceNum`. * For nested structures, preserve `ParentLineNum`. Use `LineStatusCode` if your partner requires explicit “added/changed/deleted” flags. 4. **Profile impacts** * If a change affects pricing (rates, taxes, discounts), update `ProfileInfo` (and possibly totals). Omitting totals may be acceptable for some partners; others will reject mismatches. 5. **What’s *not* in ChgRq vs AddRq** * `CalibrationInfo` and `ScanInfo` do not appear in `EstimateChgRqType`. If you need to change those data, partner workflows may expect a re-send under Add/PhotoAdd or a separate message family—confirm externally. 6. **Header is still mandatory** * `RqUID` must be a real UUID. 7. **Code lists** * Enumerations (e.g., `DocumentType`, `RateType`, `TotalType`, `LaborType`) are validated against your code list XSDs. Use exact codes. --- # Quick field checklist for a *solid* ChgRq * **Header** * `RqUID` ✅ * **Doc identity** * `DocumentInfo/BMSVer` = `6.9.0` ✅ * `DocumentInfo/DocumentType` = `E` ✅ * `DocumentInfo/CreateDateTime` ✅ * `DocumentInfo/DocumentID` (recommended) ✅ * `DocumentInfo/DocumentVer` and/or `ReferenceInfo` (recommended) ✅ * **Changed data only** * `ProfileInfo/RateInfo` (if rates/taxes changed) * `DamageLineInfo[0..*]` (added/updated/removed lines) * `RepairTotalsInfo/SummaryTotalsInfo` (if required by partner) * Any updated `AdminInfo`, `ClaimInfo`, `VehicleInfo` fragments as needed --- # Pointers to definitions in your bundle * `VehicleDamageEstimateChgRq` element → `BMSEstimateMessages_2024R1_V6.9.0.xsd` * `EstimateChgRqType` → `BMSEstimateCommonTypes_2024R1_V6.9.0.xsd` * `MessageHeaderType`, `DocumentInfoType`, `VehicleInfoType`, `TotalsInfoType`, etc. → `BMSCommonGlobalTypes_2024R1_V6.9.0.xsd` * Code lists → `BMSCodeLists_ClassicCode_2024R1_V6.9.0.xsd`, `BMSCodeLists_CodeExt_2024R1_V6.9.0.xsd` * Service wrapper → `BMSEstimateService_2024R1_V6.9.0.xsd` (group `EstimateService` contains the ChgRq/Rs) ---