Uploaded image for project: 'Kuali Rice Roadmap'
  1. Kuali Rice Roadmap
  2. KRRM-146

Integrate entities that are used by multiple modules or multiple applications.

    Details

    • Type: Rice Enhancement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Component/s: KIM
    • Labels:
      None
    • Rice Theme:
      Kuali Application Business Drivers
    • Priority Score:
      0
    • Functional Justification :
      Hide
      Following are use cases:

      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.

      Show
      Following are use cases: 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.
    • Technical Justification:
      A single, central repository for these entities would allow for a single scheme across applications reducing duplication of data and effort.
    • Impact if not Implemented:
      Hide
      Without this, implementers using multiple Rice based applications will need to come up with their own way to reconcile these common entities slowing or complicating the task of adoption. Applications will continue to need to develop their own schemes for such entities as well.
      Show
      Without this, implementers using multiple Rice based applications will need to come up with their own way to reconcile these common entities slowing or complicating the task of adoption. Applications will continue to need to develop their own schemes for such entities as well.
    • Priority - KFS:
      No Priority
    • Priority - KC:
      No Priority
    • Priority - KS:
      No Priority
    • Priority - Rice:
      No Priority

      Description

      At one point KOM was going to address not only Organizations, but other entities that crossed applications and modules, such as AR customers/Vendors/Agencies. However, KOM seems to only focus now on Organizational management across applications.

        Attachments

          Issue Links

            Activity

            Hide
            masargen Matt Sargent added a comment -

            There are a couple of options (and probably more) that we could explore one being to expand KIM for additional attributes necessary for these entities or add on a new/separate module for them. Likely, expanding KIM further makes the most sense.

            Show
            masargen Matt Sargent added a comment - There are a couple of options (and probably more) that we could explore one being to expand KIM for additional attributes necessary for these entities or add on a new/separate module for them. Likely, expanding KIM further makes the most sense.
            Hide
            abyrne Ailish Byrne added a comment -

            my recollection is that organization management and multiple entity types in kim are two separate things. kim was intended to allow multiple entity types and currently supports person and system but was intended way back when we started building it to eventually be a central repository for all sorts of entity data and eliminate overlaps - vendor, sponsor, customer, etc. the ones initially discussed were kfs and kc entity types and and entity needs to be able to be of multiple types. not sure how this one fell off the radar when we couldn't fit it into phase 1 of kim, but, the only other jira i see for it is KULRICE-6029. at least it was still on eric's radar!

            Show
            abyrne Ailish Byrne added a comment - my recollection is that organization management and multiple entity types in kim are two separate things. kim was intended to allow multiple entity types and currently supports person and system but was intended way back when we started building it to eventually be a central repository for all sorts of entity data and eliminate overlaps - vendor, sponsor, customer, etc. the ones initially discussed were kfs and kc entity types and and entity needs to be able to be of multiple types. not sure how this one fell off the radar when we couldn't fit it into phase 1 of kim, but, the only other jira i see for it is KULRICE-6029 . at least it was still on eric's radar!
            Hide
            ewestfal Eric Westfall added a comment - - edited

            Thinking about this, I wonder if using the concept of an affiliation makes more sense than using entity type. In such a case the entity type might be "business" but the affiliation might be vendor, customer, sponsor, etc. Either way, I think it's possible to support this now in the data model at the very least. Do we have more of an idea on what the gaps are here or how the business processes to support this would work?

            In order to estimate this, I might need some more info on the requirements.

            If I was making a guess, I might think what you are asking for here is the ability to essentially place "business" entities into KIM and then flag them with the appropriate affiliations either through an automated provisioning process or through real-time API integration. I would imagine in the case of Vendors, this would happen at the point in time in which you create the new vendor. Additionally, is there an ID match/reconciliation requirement here as well? For example, do you need to be able to run matching to determine if the vendor being entered matches a pre-existing entity in KIM so that it can add an affiliation to an existing record rather than creating a duplicate? In this case, I assume we are talking about still storing the vendor-specific or sponsor-specific or whatever-specific information on the application side, but having links to the entity record in KIM?

            Am I off base on assumptions here or this close to what you were thinking?

            Show
            ewestfal Eric Westfall added a comment - - edited Thinking about this, I wonder if using the concept of an affiliation makes more sense than using entity type. In such a case the entity type might be "business" but the affiliation might be vendor, customer, sponsor, etc. Either way, I think it's possible to support this now in the data model at the very least. Do we have more of an idea on what the gaps are here or how the business processes to support this would work? In order to estimate this, I might need some more info on the requirements. If I was making a guess, I might think what you are asking for here is the ability to essentially place "business" entities into KIM and then flag them with the appropriate affiliations either through an automated provisioning process or through real-time API integration. I would imagine in the case of Vendors, this would happen at the point in time in which you create the new vendor. Additionally, is there an ID match/reconciliation requirement here as well? For example, do you need to be able to run matching to determine if the vendor being entered matches a pre-existing entity in KIM so that it can add an affiliation to an existing record rather than creating a duplicate? In this case, I assume we are talking about still storing the vendor-specific or sponsor-specific or whatever-specific information on the application side, but having links to the entity record in KIM? Am I off base on assumptions here or this close to what you were thinking?
            Hide
            kymber Kymber Horn added a comment -

            A meeting is being scheduled with KFS and KC to refine requirements and to address Eric's comments.

            Show
            kymber Kymber Horn added a comment - A meeting is being scheduled with KFS and KC to refine requirements and to address Eric's comments.
            Hide
            kymber Kymber Horn added a comment -

            Adding Keiko's comments -

            I forgot to tell you that I am in Japan until 8/20 on vacation (I got here on 8/1).. I don't think I can join your call, it will be midnight over here A few things that i can mention regarding the entity issues (not sure if my comments help any but thought I'd list them here):

            (1) 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)

            (2) 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.

            (3) 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.

            Show
            kymber Kymber Horn added a comment - Adding Keiko's comments - — I forgot to tell you that I am in Japan until 8/20 on vacation (I got here on 8/1).. I don't think I can join your call, it will be midnight over here A few things that i can mention regarding the entity issues (not sure if my comments help any but thought I'd list them here): (1) 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) (2) 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. (3) 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.

              People

              • Assignee:
                kymber Kymber Horn
                Reporter:
                kymber Kymber Horn
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: