Currently, applications that deal with non-person entities (customers, vendors, sponsors, etc.) are forced to store this information in their own way. However, as applications grow, the interactions between them will grow as well. The need to integrate in a way that allows each application or module within an application to share information about these entities becomes more and more important. This update would provide applications a common way to store and reference these non-person entities in much the same way that they can person entities with KIM.
Give a detailed description for the enhancement. Clearly describe all concerns, eliminating ambiguities.
From the related JIRA
- It would be handy to know if the Vendor I'm paying on the PURAP side is the same AR Customer (or KC sponsor) that's terribly overdue in paying our invoices.
- With TEM we are struggling with that because we span across Vendor, Customer and Employee. We are way overdue with that side of "entities".
- In this day, it would be particularly important to know if an entity has a bad payment record/gone bankrupt, etc. before doing additional business no matter the app.
- DV payee lookup (reason code and payee) gets complicated when we are trying to look for payees from Vendor, Customer (for refund), and Employees (Note: AR customer lookup was enabled by CGB and TEM but not part of the base yet)
- TEM profile is having to track a few IDs to be associated with a traveler – profile ID, employee (KIM) and customer (if traveler has travel advance). It will be nice to be able to simplify it. When it comes to non-employee traveler, we are tracking their data in the TEM profile (future version) or AR customer (current version) instead of in KIM.
- AR customer is not integrated with KIM. If institutions want to use AR to track any other employee receivables, I think they would want to link them.
Mocks and Diagrams
Include any mocks (for UI enhancements) or diagrams that might be helpful in understanding the issue.
If applicable, list expectations for performance (optimal and worst cases would be fine, give time in seconds).
- KFSMI-8866 - multiple entity types in kim
- KULRICE-6029 - Research and document requirements for allowing for multiple entity types in KIM
- Update KIM to allow for additional entity type of business as a delivered type
- Update KIM to allow for additional affiliation types of:
- Address Book (historically called Rolodex)
- Organizations (not same as Orgs in KFS) - often subcontractors could be a performance site too. DUNS number is stored here, even the university has to have one (or many)
- Add effective dates to affiliations
- Ensure that the model is updated so that an affiliation is associated with a specific entity type
- Modify KIM data structure to accommodate the storage of additional data needed for the new affiliation types
- See Technical Issues Below
- Implement an identity match functionality that would allow for different levels of matching based on pre-built search profiles
- This is a larger scope item that may need to be reviewed as its own separate task.
- Provide basic screens, similar to Person, that would allow for add, lookup, and edit.
- Provide an affiliation type service or API that would allow for affiliation type to be sourced from elsewhere and tied into KIM via this service.
List any functional or technical work that must be completed before work on this item can begin.
- We currently have Vendor, Customer, Sponsor, Address Book (Rolodex in COEUS), and Organizations as potential Business affiliation types. Need to ensure there are not others from KS and KPME.
- After having the full list of affiliation types, we need to come up with the standard set of information that would be available in KIM to allow for the integration and id match to successfully work.
- KRIM Data Structure - In the current KRIM data structure contact, privacy, and membership information is associated with an Entity. This limits the ability for a single entity to have contact, privacy, and membership setting differ between the various affiliations they may have.
- Should the data structure be updated to have this type of information associated with an affiliation instead of an entity? This gives an entity much more flexibility as to how they are viewed based on their affiliations, however it makes the maintenance of information much more labor intensive if there are no differences. For example if a person is a student and staff member, and their addresses are the same for both affiliations, the person (or some logic) would need to update an address change for both.
- Sticking with the current structure would leave the data tied to the entity and types (student home address, mailing address, etc.) being used to differentiate between the different uses.
QA or Regression Testing Plan
List steps needed to test the basic functionality of this update, enhancement, bug fix.
Functional Analysis Complete? No (completed by SME)
Needs Review by KAI? Yes (completed by SME)
Technical Analysis Complete? No (completed by DM)
Needs Review by KTI? Yes (completed by DM)
Estimate: n hours (completed by DM)
Technical Design: Link Here (completed by DM)
JIRA: KRRM-146 (completed by SME)
Final Documentation: Link Here (completed by DM)
Added to QA: No (completed by SME)