9.3 KiB
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 inBMSEstimateCommonTypes_2024R1_V6.9.0.xsd) - Service group:
EstimateServicefromBMSEstimateService_2024R1_V6.9.0.xsdGroup 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) — requiredAsyncRqUID(UUID) — optionalPartnerKey(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) — optionalPropertyInfo(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:
…AddRqrequires several containers (AdminInfo,EstimatorIDs,ProfileInfo,DamageLineInfo,RepairTotalsInfowithSummaryTotalsInfo, etc.).…ChgRqonly requiresMessageHeaderType/RqUIDandDocumentInfo; everything else is optional so you can send just what changed.CalibrationInfoandScanInfo(present in…AddRq) are not present inEstimateChgRqType.- Because almost everything is optional, the burden is on you to correctly identify the target
document/version in
DocumentInfo(or viaReferenceInfo) 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.0DocumentType=E(estimate)DocumentID— your estimate IDCreateDateTime— when you formed this change messageReferenceInfo— link back to the prior/authoritative doc (e.g., originalDocumentID/DocumentVer), if your workflow uses referencesDocumentVer— 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(orPropertyInfoType) — vehicle path stays underVehicleInfo(optional) -
ProfileInfoType— rates/taxes/rules (optional) -
DamageLineInfoType— send changed/added/removed lines only (your trading partner may require specific flags/LineStatusCode or useParentLineNum+UniqueSequenceNumto identify updates) -
RepairTotalsInfoType— updated totals (optional; some partners expect totals to reconcile with changed lines) -
PaymentInfoType, memos, custom print/image &OtherMemos— all optional
Because
ChgRqis 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
DocumentIDand some way to reference the prior document/version so the receiver can apply changes.
<VehicleDamageEstimateChgRq xmlns="http://www.cieca.com/BMS">
<!-- MessageHeaderType -->
<RqUID>00000000-0000-0000-0000-000000000000</RqUID>
<!-- EstimateChgRqType sequence -->
<DocumentInfo>
<BMSVer>6.9.0</BMSVer>
<DocumentType>E</DocumentType>
<CreateDateTime>2025-08-14T12:00:00Z</CreateDateTime>
<!-- Strongly recommended for change requests: -->
<!-- <DocumentID>EST-12345</DocumentID> -->
<!-- <DocumentVer>
<DocumentVerCode>REV</DocumentVerCode>
<DocumentVerNum>2</DocumentVerNum>
</DocumentVer>
<ReferenceInfo>
<RefDocumentID>EST-12345</RefDocumentID>
<RefDocumentVerNum>1</RefDocumentVerNum>
</ReferenceInfo> -->
</DocumentInfo>
<!-- Add only what changed. Examples: -->
<!-- Update a rate -->
<!--
<ProfileInfo>
<RateInfo>
<RateType>BODY_LABOR</RateType>
<TaxableInd>true</TaxableInd>
<TaxRate>13.00</TaxRate>
</RateInfo>
</ProfileInfo>
-->
<!-- Add/update a labor line -->
<!--
<DamageLineInfo>
<LineNum>10</LineNum>
<LaborInfo>
<LaborType>BODY</LaborType>
<LaborHours>1.5</LaborHours>
<LaborHourlyRate>85.00</LaborHourlyRate>
</LaborInfo>
</DamageLineInfo>
-->
<!-- Sync totals if your partner requires it with each change -->
<!--
<RepairTotalsInfo>
<SummaryTotalsInfo>
<TotalType>GRAND_TOTAL</TotalType>
<TotalTypeDesc>Grand Total</TotalTypeDesc>
<TotalAmt>1234.56</TotalAmt>
</SummaryTotalsInfo>
</RepairTotalsInfo>
-->
</VehicleDamageEstimateChgRq>
Practical guidance & gotchas
- Targeting the right document/version
DocumentInfo/DocumentID+DocumentVerand/orReferenceInfoshould point unambiguously to the estimate being changed. This is essential because the schema does not include a separate “ChangeTarget” field—partners expect this info inDocumentInfo/ReferenceInfo.
- Sparsity vs completeness
- You can send just the changed sections (e.g., one
DamageLineInfo, oneRateInfo). - Some receivers require you to also include reconciled
RepairTotalsInfo/SummaryTotalsInfo. Check partner specs.
- Line identity
- If you’re updating an existing line, keep its identity stable using
LineNumand/orUniqueSequenceNum. - For nested structures, preserve
ParentLineNum. UseLineStatusCodeif your partner requires explicit “added/changed/deleted” flags.
- 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.
- What’s not in ChgRq vs AddRq
CalibrationInfoandScanInfodo not appear inEstimateChgRqType. If you need to change those data, partner workflows may expect a re-send under Add/PhotoAdd or a separate message family—confirm externally.
- Header is still mandatory
RqUIDmust be a real UUID.
- 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/DocumentVerand/orReferenceInfo(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,VehicleInfofragments as needed
Pointers to definitions in your bundle
VehicleDamageEstimateChgRqelement →BMSEstimateMessages_2024R1_V6.9.0.xsdEstimateChgRqType→BMSEstimateCommonTypes_2024R1_V6.9.0.xsdMessageHeaderType,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(groupEstimateServicecontains the ChgRq/Rs)