I am working with a large utility to determine if a standard implementation is feasible for Open Text Vendor Invoice Management within SAP for our situation. The procedure includes scanning an invoice into the computer, taking advantage of OCR to identify key data and populating this data into the appropriate fields within SAP. The SAP Invoice Receipt is complete immediately after the OCR process finishes or once a clerk reviews and adjusts the document. Next, the invoice must be approved. Open Text requires the configuration of 2 tables to determine the Delegation of Authority. The configuration is accessed through the transaction “/n/OPT/VIM_7CX1” including table “/ORS/USERMAP” to simulate the firm’s organizational hierarchy and table “/OPT/BL_APPCOA” to list the user’s monetary approval level by the expense type and the account assignment.
Since the SAP ECC HCM Organizational Hierarchy is available, we wanted to avoid the effort to duplicate the data into the SAP Open Text table “/ORS/USERMAP” and to eliminate the on-going maintenance of this table as organizational changes occur. In addition to avoiding the costs of creation and maintenance, we wanted to avoid the inconsistencies that are likely to occur in an attempt to maintain 2 sets of duplicate data. Then, we decided to modify the Open Text workflow redirecting it from the Open Text table “/ORS/USERMAP” to the SAP ECC HCM Organizational Hierarchy. Custom code is necessary to make the changes necessary to redirect the Open Text workflows.
SAP SRM allows only 1 type of expense, therefore, we were already planning to develop a custom table for this utility to differentiate the delegation of authority approval levels for Shopping Carts and Purchase Orders among different expense types based on the pay grade of the user. This table is to be included within SAP SRM. Since this table was already designed and is similar to the Open Text table “/OPT/BL_APPCOA”, then the same custom table will be placed into both ECC and SRM to replace the Open Text table “/OPT/BL_APPCOA”. Maintenance will be performed on 1 table only. Once the changes to the source table are saved, then the table will be automatically interfaced and the data duplicated into the other system. We have not decided whether the source table will reside in ECC or SRM.
I researched, but was unable to find, any recommendations from Open Text consultants or independent SAP consultants that had worked with Open Text to provide a standard solution when the SAP ECC HCM Organizational Hierarchy is available. Are there standard Open Text configuration elements available within SAP that would allow the SAP ECC Organizational Hierarchy to replace the Open Text table “/ORS/USERMAP” as a normal feature of the Vendor Invoice Management product? Are Open Text programs, reports, function modules, or any other programmatic device available to duplicate the SAP ECC Organizational Hierarchy into the standard Open Text tables “/ORS/USERMAP”? Does Open Text provide a standard capability to replicate the table “/OPT/BL_APPCOA” from a source ECC system into any other ECC or SRM systems? If so, we may consider using it to replace our custom table. We would prefer to find standard solutions to avoid customizing the ECC and SRM systems.
The short answer to your questions is no, no standards are delivered. But I'll try to give a longer answer for each of your question of the options available.
Are there standard Open Text configuration elements available within SAP that would allow the SAP ECC Organizational Hierarchy to replace the Open Text table “/ORS/USERMAP” as a normal feature of the Vendor Invoice Management product? There is no standard code available but you have the option to create your own logic. The approval process is steered by the approver calss. You can create a subclass for this class and redefine the methods as appropriate. By entering your subclass in the constant table you can make sure you use your class in stead of the standard one. In that way you can use the Organizational Hierarchy. To be able to still use all functionality but not the usermap table you probably would need to create your own usermap class also.
Are Open Text programs, reports, function modules, or any other programmatic device available to duplicate the SAP ECC Organizational Hierarchy into the standard Open Text tables “/ORS/USERMAP”? As stated at the beginning no there aren't. You would need to create your own logic to populate the Usermap table from the Organizational Hierarchy. Open Text could deliver this, but for a consulting fee. It is not delivered as standard. In the usermap class methods are available to create the entries in a controlled manner.
Does Open Text provide a standard capability to replicate the table “/OPT/BL_APPCOA” from a source ECC system into any other ECC or SRM systems? Same as for your previous question, you would need to create it yourself.
Hope this helps a little.
Though this is a old post... I thought this will be useful for everyone.. Though the Opentext VIM addon is being sold at a very competitive price. Its OCR may not meet the expectations of most organizations, if u don't use the OCR its easier just developing a simple bespoke VIM solution that uses your existing HR data.. You may just need 2-3 webdynpro screens, a workflow and some reports.
The architecture is so stupid, they have a Usermap class for which you can create a subclass and use to read from HR/User master but Opentext reads directly from the usermap table where ever they need. I would have thought you would use the usermap class to check user data instead of reading directly from the table.
You can only get past this usermap/coa issue by modifying the opentext code.. (not even implicit enhancements) .
Even if there are just 10 checks/business rules, the user has to complete the workitem by clicking the "run business rules" button and a new workitem is created if the check fails.. why cant we have an option to complete the checks in the foreground? this is so awkward for end users.
I know two organizations that have implemented this solution and don't want to upgrade to the latest VIM solution because of the number of changes in the code. Every new version looks like a brand new solution.
The only selling point is OCR and Opentext but those who know the technical aspects of this solution will not like it. Don't know how reliable the Opentext OCR is in other countries..