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.
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
Execute the program in SE38
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:
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.
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.
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.
Redefine method /OPT/IF_D_BP_MODULE~PROCESSING
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 ISINITIAL.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
Create an entry with an unique Module ID, a meaningful descripton and the name of the class you just created:
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”:
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):
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:
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.
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
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.
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 cLENGTH10, " line item position for messages ls_msg TYPE SYMSG. " messageFIELD-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:
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.
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.
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:
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.
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.
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.
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
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 loopDATA: 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." [...]CALLMETHOD /otx/pf02_cl_error_message=>message_return_buildEXPORTING 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:
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.
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.
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.
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.
