Open Issues

1. Is OLE using OBJ or JPA? Peri: OJB
   1. What will the upgrade to JPA look like in the future for OLE?

KFS & OLE

Based on KFS Fit Analysis Team FC determined KFS functionality is a good fit for OLE.

Tasks Required for Base Functionality

Jonathan shares concerns with upgrade path to OLE FS below, from email dated 7/19/2012.

From the beginning, I had thought that I was converting KFS to form a base on which the OLE project would start.  I had hoped that it would be taken and modified to suit OLE.  But, very quickly it came out from the functional committee that they wanted to keep as close to baseline on the core code as possible so that OLE could take advantage of upgrades as they were developed.  So, that forced the development style to be more along the lines of an implementing school, extending and adding to their own objects and tables rather than making the more simple modifications to the original code.

I believe that attempting to maintain this connection (upgrade compatibility) is detrimental to the project in the long run.  It leaves a lot of "extra" code and configuration and database objects which are not being used.  If the select module is to continue to be based on the KFS purchasing module, then we should properly strip all the components of KFS which are not required by that functionality.

Also if that is the case (staying with the KFS base), then we need to complete the upgrade of the system to KFS 5.0 to get the 2.0 upgrades.  That is going to take some time still.  The merge I've been working on is not complete and I could use some help.  Additionally, we will need to do two additional merges.  One to pull in KFS 5.0 final once it is released and one to merge in all the changes which have been made on trunk since I branched.  (Or to merge it into the trunk after it's complete.)

We had talked a little a long time ago about using KSB service calls to talk to a "real" KFS instance.  However, since OLE had to function without depending on the institution also running KFS (which at the time a number the OLE partners were not likely to switch to KFS), that functionality (purchasing/payables) needed to be included in the OLE application.

Now, if we assume that KFS purchasing will still be the underlying core, then the suggestion to build KRAD screens for any OLE components is a good one.  The OLE screens can then generate KFS-style documents "underneath" which would be pushed into any further routing needed.  (The later approvers would then see the KFS-style KNS-based screens.)  And, the acquisition functionality was what was already being developed in KRAD and Rice 2.0, correct?

To the question: "Does it make more sense to build this functionality in OLE in the simple form that is required directly on OLE 2.0?"  Anything new, yes.  KFS was to provide a jump-start and provide some of the complex plumbing needed for purchasing (and apparently some financial tracking - given the interest in the GL and sufficient funds.)  It was never intended that OLE had to extend anything which was not a good fit.  As far as the levels of work.  Only the OLE development team would know what it would take to re-create all the UI components used for the select process and then call services for their back end.  That would have ramifications on business logic and workflow. Including some which did not have to be developed by OLE.  (part of KFS baseline)  I'm assuming that would not be an inconsiderable amount of time.  The benefit would be that we would dump the KFS components and utilize a vanilla (almost un-customized) KFS 5.0 instance.  I'm not sure what that would mean in terms of the base changes which OLE has made to the requisition and purchase order documents.  Nor what the implication would be for some other desired changes like the multiple-PO per payment request modification that was being looked into.