As participants in this meeting, we need to be mindful of the constraints of antitrust laws. There shall be no discussions of agreements or concerted actions that may restrain competition. This prohibition includes the exchange of information concerning individual prices, rates, coverages, market practices, claims settlement practices, or any other competitive aspect of an individual company’s operation. Each participant is obligated to speak up immediately for the purpose of preventing any discussion falling outside these bounds.
Agenda
Antitrust
Network/Welcome
Review Previous Meeting Minutes(s)
Review Parts
Review Jira Board
Meeting Minutes
Antitrust accepted
Meeting minutes reviewed and accepted
Reviewed PartInfo
We are using PartNumInfo aggregate as an array, this aggregate included
PartNumType
PartNum
and others
Mike shared an example with OEM part Number and Estimating System and Aftermarket part number
Part Prices was broken up in different Price aggregates in the BMS and caused confusion with the prices and when to use.
Price Type is code list that includes things like ‘List Price’ and then the base price is always there and a price adjustment, then the net price is calculated from those values.
RecycledPriceType is a new code list for damaged price and undamaged price.
Seems PartInfo was done in a different structure than parties in the flattening?
In the BMS we had ID info array, the idea for Party ID
Is there a way in JSON that pulls out the price type in an array?
JSON does not have elegance of XPath that allows you to sort array values
If we have List Price and Cost Price could the REST code pull out the specifics like they do in XML?
Named value paired in BMS was 2 lines and in JSON the name and the value are the same.
We are looking for flexibility and reuse, but we need to be careful
We want to make sure Part and Parties is consistent flattening
Dan needs to take examples of his estimate and damage lines to see how they work
The BMS added things that were not needed to damage lines on estimates, and they were ignored if not using. But now we are trying to rationalize and flatten.
The goal to Part Info was to standardize the differences from PMP actual Part and Estimate Part.
Mike showed the Excel document that shows the flattening
Removed the non-OEM aggregate and replaced with the afatermarketinfo and recyledInfo aggregate
Mike to show instance documents
Alot of data for Glass and Property was removed for zero based
Mike wants to bring the PMP committee to go through the PMP Aggregates, PartInfo will be there for first round and in November PMP will work on the next 30 aggregates.
GitHub
For October work we will do in current branch
For all work after October can have a new branch
Testing
Andy is working on standardized batch validation with Dan
Creating a Jira for this work
Dan completed Test Instances for Claim, Vehicle, Party and the combination, with both positive and negative test instance.
Problem with XPath can be shared with Andy to see if he can find a solution to the issues that we ran into.
Reviewed Jira Log and added new JIRAS
Going to move all CAPIS Jira to the new CAPIS Schema Standards
asOf needs to be anyof R22022-147 we had questions for Andy to see if we still needed to remove anyOf
Adding Jiras
Add Object schema for Parts
Add Testing (Batch Validation) to CAPIS Build
Add Check-in of bundled schemas (both json and YAML) to CAPIS build
This is already done in our build process
Add Automated Generation of code list definitions to CAPIS build
At this time leverage the actual sqllight and generate from there and stay away from more excel
Create a new excel file with only CAPIS code list
We do have an olde conversion program that can convert the code list
This may not be necessary for first release of CAPIS
We won’t suffer by not having an automated process for first release.
For this release we will add to schema and not use the EXCEL
Stoplight can be used to show these values
Create OAS documents, either as part of CAPIS build or in separate process like we managed with BMS
Minimal Viable Product we need the Open API Specification and document that makes use of the schema. It can be very minimal.
Create OAS documents is top priority
We can use Stoplight and use models
Stoplight Licensing. We have a 5-user license
Tool that creates static webpage from API, most don’t support 3.1 version that we are using.
For October we would show in Stoplight. Everyone may not be able to sign into it, but the others can use it with their own free license.
We will say we have open api spec nifty spec and put it on the members to render open API specs.
The part info and all the Aggregates can be used as is and we are okay for first version.
Contact object proposal
The BMS has the JABER protocol.
Make an instance to include in the schema.
Action items
Decisions
Participants
Paulette Reed
Dan Webster
Phil Martinez
Brad B
Mike Hastings
Andy Bober
Paul Barry
Jeff Schroder
Participants in the meetings are noted for your information. If you have questions on the committee’s activities, please contact a recent attendee. https://cieca.atlassian.net/wiki/spaces/ARCH