Public Page

2023-01-31 Architecture Meeting Minutes

Public Page

Date: Jan 31, 2023

 

 

 

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

  • Network/Welcome

  • This meeting is subject to the terms of our anti-trust statement shown here.  In addition, this meeting may be recorded. 

  • Review Meeting Minutes

  • Review Contact/Party/Person/Company

Meeting Minutes

  • Network

    • Eucalypts tress are falling due to all the rain in California.

  • Antitrust Accepted

  • Meeting Minutes Reviewed/Accepted

  • Meeting Minutes

    • Mike has completed JIRAS that were assigned to him.

    • Jeff Shared Diagram with User, Company, Contact and Party

      • Contact is simple concept, ways to contact a person or an organization. A claimant can be a person or an organization. The communication is a superset in the BMS, but the diagram shows contact have the communication of name, address, phone number, email.

      • A company may have different kinds of contacts, so a one to many and a user can have many types of contacts as well because they can have business contact, home contact or parent contact.

      • Terminology is throwing everyone off, we need to determine the terminology of party and company and person.

    • Mike showed his examples.

      • First one was simple concept: basically, a user or a buyer purchasing parts and we have user ID and username.

        • few properties tell us the user

        • primary contact tells us who the user is with first name, last name and ID.

        • contact information for the user.

        • we can have bill to and ship to contact.

        • when these are different addresses, we send the different addresses for those.

      • Next examples show if the user if from body shop or company.

        • Same user information and username

        • name is added.

        • in this case the user if from the company. The user works for a bodyshop as an estimator, so the reference to the company id.

        • The Bill to and ship to build the address.

      • Third Example is the amazon model.

        • You have a user and a buyer.

          • Addition of birthdate

    • The BMS has overlap with party object and contact.

      • Recommend removing the duplicate contact fields from the party and just reference a contact within the party.

      • Can a company have a contact with no name? Yes

        • Have company name.

        • Have first name/last name under contact.

    • Named Value Pairs

      • Phone numbers, because we can have a type of phone number.

      • Company Id is a named Value pair because we can have different types of IDs for a company.

      • When it comes to primary bill to contact, we don’t have a contacts array with a contact type property, we have a flattened primary bill to contact and a secondary bill to contact and a shipped to contact.

      • It's an inconsistent design.

    • Another look.

      • Primary bill too contact is a contact object. Do we need an ID array?

      • We could add a Contact ID, but we don’t have it in the code list currently, which is why company id code list is being used in the example.

    • Universal Problem

      • Another way to look at this is the company’s party and contact are duplicates of each other and unnecessary and we need to normalize this, but how?

      • Need generic object to fit in everyone’s business use cases.

      • ID should be at the level of the person or the company. Basically, we should be the party and then once you have an ID for that, you have enough information.

    • Inconsistencies of arrays and valued pairs.

      • we need examples of how this would work with all the 100 things we have as ID qualifier code so we can flatten properties.

Great Discussion everyone!

Up Next

  • Network/Welcome

  • Antitrust

  • Review Meeting Minutes

  • Review new concepts in examples being worked.

Action items

Decisions

 

Participants

  • Paulette Reed

  • Mike Hastings

  • Jeff Schroder

  • Dan Webster

  • Paul Barry

Participants in the meetings are noted for your information.  If you have questions on the committee’s activities, please contact a recent attendee. Architecture Committee