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.

  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.

  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

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.