Johannes Auer

30-Min-Call DE
SAP VIM customizing



Hinweis: Wir veröffentlichen alle Blogbeiträge ausschließlich auf Englisch.

Kategorie: Development

  • Practical Role Determination for SAP VIM Solutions Beyond Invoice: A Simple Approach + Free Template

    Practical Role Determination for SAP VIM Solutions Beyond Invoice: A Simple Approach + Free Template

    When you start working with SAP VIM Solutions Beyond Invoice — whether it’s Incoming Delivery Notes, Sales Orders, Remittance Advices, Order Confirmations or Quotations — you quickly notice a familiar limitation: the out-of-the-box setup doesn’t provide meaningful role definitions. The delivered BC-Sets rely entirely on SAP’s Organizational Object Assignment, pointing to predefined work centers, rules, jobs, org units, positions, or individual users.

    In real projects, these structures are rarely maintained in a way that supports smooth routing. That’s why, in most implementations, one of the very first tasks is building a practical, maintainable role resolution logic — one that matches how the organization actually works.

    blank
    /otx/pf00_img > Process Configuration > Profiles

    A very minimal role resolution logic which works without creating a table, maintenance view and more is this one: We tap into the existing table of validation agents maintained in Validation Assignment. This is a very simple and very easy solution as you can set up a list of users per ArchiveLink Document Type and this user will then be assigned both for validation and document processing.

    blank
    /OTX/PF00_IMG > Inbound Configuration > Capture > Validation Assignment

    The link between ArchiveLink Document Type and User is stored in table /OTX/PF01_T_VALR.

    blank
    SE16N displaying /OTX/PF01_T_VALR

    The only way to achieve any logic for determining users besides SAP’s Organizational Object Assignment is using the setting Role Resolution Logic which requires an ABAP Class being assigned.

    Create a new class in SE80 using Superclass /OTX/PF04_CL_ROLE

    blank

    Redefine method /OTX/PF04_IF_ROLE~ROLE_LOGIC

    blank

    A minimal version of this method could look like this (simply returning one user with username Alex):

      METHOD /otx/pf04_if_role~role_logic.
    DATA: ls_actor   TYPE swhactor.

    ls_actor-otype = 'US'.
    ls_actor-objid = 'Alex'.

    APPEND ls_actor TO pet_role_result.
  ENDMETHOD.

    In order to add our logic we will retrieve the ArchiveLink Document Type and select the responsible user from table /OTX/PF01_T_VALR. 

      METHOD /otx/pf04_if_role~role_logic.
    DATA: lh_plh      TYPE REF TO data,
          ls_actor    TYPE swhactor,
          ls_fallback TYPE /otx/pf04_t_rol, " optional for fallback
          lt_valr     TYPE TABLE OF /otx/pf01_t_valr.

    FIELD-SYMBOLS:   TYPE /otx/ps09_t_plh, " [TODO] replace with your PLH table! Format is /otx/ps*_t_plh for out of the box solutions.
                    TYPE /otx/pf01_t_valr.

* Get data from workitem header
    CALL METHOD /otx/pf04_if_role~mh_data->head_data_get( IMPORTING peh_head = lh_plh ). 
    ASSIGN lh_plh->* TO .

* Use Validation Agents from /otx/pf01_t_valr in case ArchiveLink Document Type is filled.
    IF -ar_object IS NOT INITIAL.

      SELECT otype, objid
        FROM /otx/pf01_t_valr
        INTO CORRESPONDING FIELDS OF TABLE @lt_valr
        WHERE ar_object = @-ar_object.

      IF sy-subrc EQ 0.
        LOOP AT lt_valr ASSIGNING .
          CLEAR ls_actor.

          ls_actor-otype = -otype.
          ls_actor-objid = -objid.

          APPEND ls_actor TO pet_role_result.
        ENDLOOP.
      ENDIF.
    ENDIF.

* Fallback (optional) 
    IF pet_role_result IS INITIAL.

      SELECT SINGLE otype, objid
        FROM /otx/pf04_t_rol
        INTO CORRESPONDING FIELDS OF @ls_fallback
        WHERE profile_id = 'PS02_BCF_ORDER' " [TODO]example! to be replaced!
        AND role_id = 'SOL_1ST_PROC'. " [TODO] example! to be replaced!
      IF sy-subrc EQ 0.
        CLEAR ls_actor.
        CONCATENATE ls_fallback-otype ls_fallback-objid INTO ls_actor.
        APPEND ls_actor TO pet_role_result.
      ENDIF.
    ENDIF.

  ENDMETHOD.

    Once the class is complete and activated we can assign it in /OTX/PF00_IMG > Process Configuration > Profiles > Profile Configuration > Version Definition > Role Definition. Here you can now switch your Role Type to Role Resolution Logic, add your Role class and add a Fallback user in case the logic does not return any user:

    blank

    Now you have created a very clean, reliable and super straightforward role determination for VIM Beyond invoices. This enables you to fully set up any of the SAP VIM Solutions Beyond Invoice processes. And in case there is no complex requirement for user determination there is a chance that you already reached your goal!

    If your requirements extend beyond this or you would like support in reviewing or refining your configuration, you are welcome to get in touch.

    This article is for SAP VIM Solutions Beyond Invoice and is not compatible with role determination configuration for invoice processing.

    This article is intended for informational purposes only and does not supersede or replace the official documentation provided by OpenText. It serves as supplementary guidance to assist with common challenges. For authoritative instructions and compliance requirements, refer to OpenText’s official documentation and support. Do not use this in production systems.

  • Struggling With Logic Modules in SAP VIM? Here’s How to Master the Debugger (Without Going Crazy)

    Struggling With Logic Modules in SAP VIM? Here’s How to Master the Debugger (Without Going Crazy)

    This article is intended for informational purposes only and does not supersede or replace the official documentation provided by OpenText. It serves as supplementary guidance to assist with common challenges. For authoritative instructions and compliance requirements, refer to OpenText’s official documentation and support. Do not use this in production systems.

    Debugging Logic Modules in SAP VIM is rarely straightforward. Setting multiple breakpoints, stepping through code execution, and still failing to reach the relevant section can quickly become frustrating and time-consuming.

    However, there’s a little-known approach that can make this process far more efficient.

    In case you are interested in creating your own Logic Module in VIM check this article: How to Create a Custom Logic Module (Data Enrichment) for SAP VIM Invoice Processing (Step-by-Step Guide)

    The Hidden Program That Simplifies Debugging

    Within the SAP VIM development packages, there is a program that can be executed via transaction SE38:

    /OPT/DR_BPF_TEST

    This program does not appear in the standard OpenText documentation, which means many consultants are unaware of its existence. Yet it provides a structured way to analyze and debug Logic Modules.

    Key Capabilities

    • Display a list of all Logic Modules executed for a given document
    • View the sequence of module calls in detail
    • Decide whether to simulate the process start, rerun business rules, or both.
    • Set a breakpoint in the code and execute the program in SE38 to jump into the debugger without detours

    This transforms debugging from a trial-and-error exercise into a transparent, manageable process. Instead of relying on chance to intercept the correct module, you can work systematically through the exact logic that is being applied.

    How to use it

    1. Execute the program in SE38
      blank
    2. Enter the corresponding VIM DP document ID, decide if you want to check the process start, the re-run of business rules or both and decide if you want to show the modules only or process them:
      blank
      blank
    3. Benefit from a clean list that gives all relevant information for debugging Logic Modules. You can pick up the class name, set a breakpoint in the code and repeat.
      blank

    Why This Is Valuable

    Effective debugging is essential in every OpenText Vendor Invoice Management for SAP Solutions (VIM) project, whether for customizing workflows, implementing enhancements, or analyzing issues in production support. By providing direct insight into the sequence and behavior of Logic Modules, /OPT/DR_BPF_TEST can significantly reduce the time spent on troubleshooting.

    Because this tool is not part of the official documentation, knowledge of it can provide consultants and project teams with a clear advantage when working on complex VIM implementations.

  • How to Create a Custom Logic Module (Data Enrichment) for SAP VIM Invoice Processing (Step-by-Step Guide)

    How to Create a Custom Logic Module (Data Enrichment) for SAP VIM Invoice Processing (Step-by-Step Guide)

    This article is intended for informational purposes only and does not supersede or replace the official documentation provided by OpenText. It serves as supplementary guidance to assist with common challenges that may arise during installation and upgrades. For authoritative instructions and compliance requirements, refer to OpenText’s official documentation.

    When working with SAP Vendor Invoice Management (VIM), standard configurations often cover the majority of business needs — but not all of them. In many projects, there comes a point where additional data enrichments are required to ensure invoices are processed correctly and efficiently. This is where Logic Modules come into play. Logic Modules allow you to extend VIMs capabilities by injecting custom ABAP code into the document processing flow.

    In this guide, I’ll walk you through creating a simple data enrichment logic module, step by step: from the ABAP implementation to configuration in /n/OPT/SPRO and finally the mapping to document types. By the end, you’ll have a working example that you can adapt to your own project requirements.

    1. Creating the logic module class

    Creating the logic module class using superclass /OPT/CL_D_LM_SUPER.

    blank

    Redefine method /OPT/IF_D_BP_MODULE~PROCESSING

    blank

    A very minimalistic logic module can just consist of one line:

      METHOD /opt/if_d_bp_module~processing.
    ev_success = 'X'. "this is important!
  ENDMETHOD.

    It is important to remember giving back ev_success = ‚X‘ in logic modules as the missing success indicator can cause the following logic modules to not start.

    „Success“ in this case does not mean that actual data was enriched but just that the logic module did not encounter any issue. This is different in VIM Beyond Invoices Data Enrichments where you only want to give the success marker back when there was really data enriched.

    As an empty logic module does not bring any benefit so lets give it some simple logic. Here’s a basic example that sets an empty reference number to „Test“ + DocID::

      METHOD /opt/if_d_bp_module~processing.

* in case the reference number is empty we fill it with "Test" and the current docid. Resulting in e. g. "Test5" for Doc. ID 5.
    IF cv_index_header-xblnr IS INITIAL.
      CONCATENATE 'Test' cv_index_header-docid INTO cv_index_header-xblnr.
    ENDIF.
    
    ev_success = 'X'. "this is important!

  ENDMETHOD.

    Save and activate your Logic Module class.

    2. Defining a Logic Module

    Now that we have created the logic module class lets head to /n/OPT/SPRO and navigate to Document Processing Configuration > Document Type Configuration > Logic Module Processing > Logic Module Processing

    blank

    Create an entry with an unique Module ID, a meaningful descripton and the name of the class you just created:

    blank

    It is a good practice to start custom logic modules with a „Z“ and stick to the naming convention from product standard.

    Example: „ZN_ITEM_001“ is affecting NPO Invoices and updates line item information (001 is a running number) while „ZP_HEAD_001“ is affecting PO-Related invoices and header information is updated.

    Remember the name and move on to the next step.

    3. Processing Definition and Module Processing Steps

    You can Imagine a „Processing Definition“ as a collection of logic modules which you can later assign to a DP document type like „Z_NPO“ or „PO_75“. It is not possible to directly assign a logic module to a document type therefore lets create a Processing Definition. Add a Process ID and a Description and you can move on the „Module Processing Steps“:

    blank

    For a basic processing definition with just one module you can simply add a counter (We suggest using 10 so you can add something before this module later), the Module ID we defined before, the „Active“ checkbox and the Processing mode (Run only at processing start, only when re-running business rules or both):

    blank

    Now we have created our collection of logic modules (with just one logic module for now) and can can move on to the next step: Process Mapping.

    4. Mapping groups of Logic Modules („Processing Definition“) to DP Document Types

    To complete the setup you simply assign you Process ID („Processing Definition“) to one or more DP Document Types:

    blank

    Official Documentation

    Always cross-check your setup with the official Open Text Guides. Starting with chapter „Processing logic modules“ in „OpenText Vendor Invoice Management for SAP Solutions: Configuration Guide for Invoice Solution“ (for your Version of VIM) is good idea.

    Outro

    Logic Modules are a powerful way to adapt SAP VIM to the unique requirements of your organization. Even though the example shown here is very simple, the same principles can be applied to implement far more complex business logic — from tax code adjustments to automated field population.

    By following the approach outlined above, you now have a blueprint for creating, configuring, and deploying your own custom Logic Modules. With this flexibility, VIM becomes not just a standard solution but a platform you can tailor precisely to your processes.

  • Creating a Business Rule for SAP VIM Solutions Beyond Invoice (+ free Template)

    This article is intended for informational purposes only and does not supersede or replace the official documentation provided by OpenText. It serves as supplementary guidance to assist with common challenges that may arise during installation and upgrades. For authoritative instructions and compliance requirements, refer to OpenText’s official documentation.

    Please note that this article is not about the VIM Invoice process but VIM Solutions Beyond Invoice which is, for example, used to process sales orders, quotations, remittance advices, order confirmations or fully custom document processes (including capture & recognition using OpenText Intelligent Capture for SAP Solutions [IC4S]).

    VIM Solutions Beyond Invoice is formerly known as Business Center and sometimes referred to as VIM Beyond.

    Similar to the invoice process, the document process in SAP VIM Solutions Beyond Invoice is made up of data enrichments, roles, business rules and actions. In today’s article, I will show you how to quickly and easily create and configure an individual business rule. I also provide my template which allows an easy start for your new business rule.

    Creating a Business Rule class

    Create a new class using superclass /OTX/PF04_CL_MODULE. You can use for example SE24 or SE80 to achieve this.

    /OTX/PF04_CL_MODULE
    blank

    To implement a business rule you must redefine method /OTX/PF04_IF_MODULE~MODULE_EXEC_CHECK.

    /OTX/PF04_IF_MODULE~MODULE_EXEC_CHEC

    In earlier versions, data was changed with the help of business rules. This is becoming obsolete today and should therefore be avoided. Business rules check data, data enrichments change data. It is easy to convert old business rules into data enrichments.

    blank

    As a starting point you can use my business rule template:

    ABAP
       METHOD /otx/pf04_if_module~module_exec_check.

    DATA: ls_plh   TYPE z01ca_otx_bc_plh, " header table
          lt_pli   TYPE TABLE OF z01ca_otx_bc_pli, " line item table
          lv_pos   TYPE c LENGTH 10, " line item position for messages
          ls_msg   TYPE SYMSG. " message

    FIELD-SYMBOLS:  TYPE z01ca_otx_bc_pli. " line item table

    ls_plh = pis_plh.
    lt_pli = pit_pli.

    pe_mod_run_status = /otx/pf04_if_category=>mc_run_stat_success. " set rule to successful initially

    LOOP AT lt_pli ASSIGNING .

      CLEAR: lv_pos, ls_msg.
      
      "[...] logic
      
      " pe_mod_run_status = /otx/pf04_if_category=>mc_run_stat_failed. " set rule to failed 

      ls_msg-msgty = 'E'.
      ls_msg-msgid = 'Z...'.
      ls_msg-msgno = 123.  
      ls_msg-msgv1 = 'This rule always fails..'.
      "[...]

      APPEND ls_msg TO pet_mod_msg.
    ENDLOOP.

  ENDMETHOD.

    Customizing for a SAP VIM Solutions Beyond Invoice Business Rule

    Now we have created the class for our business rule and have to create the corresponding customising, which can be done very quickly in the transaction /otx/pf00_img.

    /otx/pf00_img

    Navigate to Process Configuration > Profiles:

    blank

    Select your Profile Configuration and navigate to the corresponding Version > Characteristic Configuration and select Process Steps. Select the process step where you want to add the business rule, then navigate to Rules.

    blank

    When creating the rule, it is important that the rule type here is CHK. Change (CHG) rules are obsolete and have been replaced by data enrichments. Your business rule should not change any data.

    blank

    Don’t forget to activate the active checkbox on the right-hand side of the screen, as this can easily be overlooked depending on the screen resolution.

    Basically, the rule is now active and can be tested. In Customizing, however, you still have to decide which role can skip which rules in which step. Depending on the number of steps and roles, this can be quite extensive:

    blank

    In general, the simulation of each step should be allowed in all steps and the skipping of rules should also be permitted.

    Final Thoughts: Less Is More

    When crafting business rules for non-invoice scenarios in SAP VIM, it’s tempting to add a high number of rules to check every possible scenario. But complexity can lead to confusion of the end users and slow performance.

    Focus on the minimal rules that truly matter—clearly defined conditions, straightforward actions, and well-documented workflows. It can also make sense to group multiple checks into one business rule to declutter the workspace. For example the rule missing material number and invalid material number can be combined into one rule.

    By keeping it simple, you’ll speed up maintenance, reduce errors, and allows you to adapt more quickly when requirements change.

  • Creating a Data Enrichment for SAP VIM Solutions Beyond Invoice (+ free Template)

    This article is intended for informational purposes only and does not supersede or replace the official documentation provided by OpenText. It serves as supplementary guidance to assist with common challenges that may arise during installation and upgrades. For authoritative instructions and compliance requirements, refer to OpenText’s official documentation.

    A data enrichment is a logic or learning based data manipulation which can run, for example, at the begin of a process. From a usage point it is very comparable with a logic module in the VIM Invoice process.

    Please note that this article is not about the VIM Invoice process but VIM Solutions Beyond Invoice which is, for example, used to process sales orders, quotations, remittance advices, order confirmations or fully custom document processes (including capture & recognition using OpenText Intelligent Capture for SAP Solutions [IC4S]).

    To be precise, Solutions Beyond Invoice describes the supplied solution packages, while the Foundation describes the creation of customised solutions, actions, rules and so on. For the sake of simplicity, I will refer to both as Solutions Beyond Invoice.

    In the following steps I will describe how to create a logic based data enrichment for SAP VIM Solutions Beyond Invoice.

    In case you are interested about learning based data enrichments please check the
    OpenText Vendor Invoice Management for SAP Solutions – Configuration Guide for Foundation.

    In case you are interested about using logic modules for the VIM Invoice process please refer to the OpenText Vendor Invoice Management for SAP Solutions – Configuration Guide for Invoice Solution.

    VIM Solutions Beyond Invoice is formerly known as Business Center and sometimes referred to as VIM Beyond.

    In earlier versions, data was changed with the help of business rules. This is becoming obsolete today and should therefore be avoided. Business rules check data, data enrichments change data. It is easy to convert old business rules into data enrichments.

    Creating a data enrichment ABAP class

    The initial step in this process is to create a new class that is both appropriately named and described, while adhering to the relevant naming conventions. You case use for example SE24 or SE80 to achieve this.

    blank

    It is essential to add the correct interface for data enrichments. In the version I am working with, this is /OTX/PF04_IF_DATA_ENRICH_EX. 

    /OTX/PF04_IF_DATA_ENRICH_EX
    blank

    The implementation is carried out in method /OTX/PF04_IF_DATA_ENRICH_EX~DATA_ENRICH_LOGIC.

    /OTX/PF04_IF_DATA_ENRICH_EX~DATA_ENRICH_LOGIC

    I use the following minimalist template for my projects. It already declares the structures, table and field symbol which are needed for processing header and line information. In addition, the success marker is set, if you forget this, the data enrichment is not even executed.

    As the naming conventions for variables and the tables used change from project to project, I recommend creating this template once for each project.

    If the data enrichment is only executed at the start of the process, it will be helpful to use a debug loop. But beware: If only the VIM Solutions Beyond Invoice Invoices solution is used in the system, but not the packages for invoice processing, a custom debug table in the style of /opt/cp_debug must be created.

    ABAP
      METHOD /otx/pf04_if_data_enrich_ex~data_enrich_logic.

* Optional: Debug loop

    DATA: ls_plh TYPE [...]_plh, " header table
          lt_pli TYPE TABLE OF [...]_pli, " line item table
          ls_msg TYPE bapiret2.

    FIELD-SYMBOLS:  TYPE [...]_pli. " line item table

    lt_pli = pct_item.
*   ls_plh = pcs_head.

    pe_success = 'X'. 

    LOOP AT lt_pli ASSIGNING .
      [...]
    ENDLOOP.

    IF pe_success = 'X'.
*     pcs_head = ls_plh. " update header information
      pct_item[] = lt_pli[]. " update item information
    ENDIF.

  ENDMETHOD.

    Whenever data is changed, I recommend issuing a helpful and transparent message to users so that they know what has been changed and why. Here is an example of what such a message could look like in the code. You can of course also assemble the messages (ls_msg) manually, but I find the option mentioned here easier to read.

    ABAP
    DATA ls_msg TYPE bapiret2.

" [...]

CALL METHOD /otx/pf02_cl_error_message=>message_return_build
  EXPORTING
    pi_type    = 'S' " "S" = Success / "E" = Error / "I" = Info
    pi_cl      = 'Z...' " name of your message class
    pi_number  = 019  " your message number.
    pi_par1    = " message parameter 1
    pi_par2    = " message parameter ...
    " [...]
  IMPORTING
    pes_return = ls_msg.
    
  APPEND ls_msg TO pet_return.

    Customizing for a SAP VIM Solutions Beyond Invoice Data Enrichment

    Now we have created the class for our data enrichment and still have to create the corresponding customising, which can be done very quickly in the transaction /otx/pf00_img.

    /otx/pf00_img

    Navigate to Process Configuration > Profiles:

    blank

    Select your Profile Configuration and navigate to the corresponding Version Definition and then Data Enrichment Configuration. Here you can now create a Data Enrichment ID with a speaking name and description.

    blank

    The enrichment point decides when a data enrichment should be executed. For my example I select ALL to execute it at all enrichment points.

    Even if a data enrichment should only run at the beginning of the process, I like to use ALL at the beginning of my implementation because the jump to the debugger is super quick. Simply set a breakpoint in the class, execute the Enrich Data action and you are already in the ABAP Debugger and can analyse if everything is working according to plan.

    blank

    The last step is often forgotten in data enrichments because it was not necessary in earlier versions. The newly created Data Enrichment ID must still be assigned to the corresponding Characteristics Configuration and given a sequence.

    blank

    I have created a data enrichment but it is not working

    If your data enrichment does not work, please check the following points:

    • Is the success marker pe_success returned with true (‘X’)?
    • Is the newly created Data Enrichment Configuration active? There is a checkbox on the far right which can easily be overlooked.
    • Have you perhaps overlooked the last point Assign Data Enrichments?
    • Perhaps your debug loop can help you here? If this is not activated, this can also be a finding.

    Conclusion

    When using SAP VIM Solutions Beyond Invoice, there is no getting round the use of data enrichments. Only with these can the process be properly tidied up and optimised.

    Don’t forget to issue transparent and helpful messages for the users and make sure that the data enrichments run in a sensible sequence.

    I wish you every success with the implementation!