Public Page

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

🔓 Public Page

Date:

ANTITRUST STATEMENT

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

      • Crate 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

  • No labels