In the post below, I’m sharing a short look at an AI-based document extraction approach that runs directly inside the SAP VIM inbound process.
At the core is a purpose-built middleware I developed to bridge SAP VIM with modern AI models — cleanly, safely, and without breaking the existing architecture.
Same VIM architecture.
A very different level of intelligence.
In SAP VIM (OpenText Vendor Invoice Management for SAP) you may occasionally notice a small blue symbol next to a business rule — some refer to it as a diamond, others as a badge or Rhombus. It’s a subtle visual element, barely documented, yet it often triggers questions among AP processors, key users, consultants, and anyone involved in maintaining VIM rule logic.
The meaning behind it is simple but important: this blue indicator shows that the business rule is newly added to the system and has not yet been evaluated for the current document. In other words, the rule exists, but it has never been considered by the VIM engine and therefore has had no influence on the current status or outcome of the document you are viewing.
This explains why a rule may appear correct in configuration while the document itself does not reflect the expected change. The system is essentially telling you that the logic has not been executed yet. As soon as the document is resubmitted or the rules are applied again, VIM will process this rule for the first time. Once that happens, the symbol disappears because the rule has officially taken effect and is now part of the evaluated ruleset for that document.
This small blue icon—whether you think of it as a diamond, marker, indicator, or flag—is easy to overlook, but it plays a useful role in everyday troubleshooting. It prevents you from searching for errors in the configuration when the actual issue is simply that VIM has not yet re-evaluated the rule. Knowing this helps both operational teams and consultants understand exactly why a document behaves the way it does, especially when introducing new rules or adjusting existing logic in productive environments.
In the OpenText Vendor Invoice Management for SAP Solutions User Guide for Invoice Solution the icon is mentioned once as „Business rule run was not logged.“ Have you seen this icon before?
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.
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.
The link between ArchiveLink Document Type and User is stored in table /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
Redefine method /OTX/PF04_IF_ROLE~ROLE_LOGIC
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: 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:
Now you have created a very clean, reliable and super straightforward role determination 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.
Are you struggling with single documents extracting wrong data in SAP VIM inbound process after coming back from extraction by IES (Intelligent Capture for SAP Solutions [IC4S] or Core Capture for SAP Solutions [CC4S])? Wrong training might be the reason for this.
The good news: You don’t have to reset all training data. With just a few steps, you can identify and reset the learning data for one specific layout.
On a very high level a Document Layout is a unique identifier for all documents that look the same. Meaning that usually all documents from one vendor share the same document layout while the content is different. In some cases it can also be that multiple vendors are using the same layout id. Machine learning through validation and feedback usually affects only one Document Layout.
We can quickly find the Layout ID in the Inbound Administration:
/otx/pf03_wpFirst you need to know your Registration ID or Target ID.
RegID is the ID you see in the Validation Client.
Target Key is the Workitem ID in the target process (e. g. VIM Doc. Id for invoice processing.
The Target Key may not be unique in your system. There can be an invoice with Doc. Id. 1 and an order confirmation using the same target process key.
Once you know which ID to use for identifying your document you can utilize the selection pane. Make sure to press Apply once you have filled Registration ID or Target Process Key.
Once you have identified the document you want to reset the learning data for you can read the value in column Document Layout Id:
1) Switch to Work Center IES Administration
2) Select Layouts
3) Filter for your Layout Id and choose Reset Layout.
Resetting the learning data for a single layout in SAP VIM is a simple yet powerful way to fix recurring extraction issues without impacting other vendors or document types. By identifying the correct Layout ID, verifying which documents are linked to it, and resetting only that layout, you avoid unnecessary retraining and keep your inbound process running smoothly.
This targeted approach helps you regain accuracy quickly, reduces manual corrections, and ensures that SAP VIM continues to learn the right patterns from your documents.
At the end of the day, machine learning in SAP VIM Capture follows a simple rule: „garbage in, garbage out“ If your training data is wrong, your results will be wrong. Resetting the layout gives you the chance to fix the root cause instead of just correcting errors endlessly.
If you have the impression that your capture application does not learn at all check out the article If your SAP VIM Capture feels like it is not learning at all, it might be missing this crucial setting!
If you want to dive deeper into validation, training, and optimization of OpenText Capture in SAP VIM, check out my Udemy course: OpenText Capture Validation for SAP VIM & Beyond Invoices – where I walk you through practical examples, tips, and real-world troubleshooting strategies.
Your team could be spending hours every week on avoidable validation tasks — a frustrating effort that can often be avoided with the right setup and training. In this course, I walk you through practical examples, proven tips, and real-world troubleshooting strategies to help you cut down on wasted time and improve accuracy.
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)
Within the SAP VIM development packages, there is a program that can be executed via transaction SE38:
/OPT/DR_BPF_TESTThis 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.
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.
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. For authoritative instructions and compliance requirements, refer to OpenText’s official documentation and support.
In the world of Accounts Payable automation, efficiency is king. One of the standout innovations in Open Text Vendor Invoice Management (VIM) for SAP Solutions is Smart Coding — a feature designed to make invoice processing faster, more accurate, and less dependent on repetitive manual entries.
Smart Coding is a machine learning–driven function in VIM that helps users automatically assign coding proposals to invoice line items. Instead of manually entering cost centers, GL accounts, or other coding data every time, VIM learns from historical postings and suggests coding values during document indexing.
Availability of this feature depends on your VIM version, and the specific fields that can be learned may differ.
In Open Text VIM Smart Coding, the Basic Model and the PAL Model differ mainly in complexity and accuracy.
The Basic Model is a simple, frequency-based approach. It analyzes historical postings for a given company code and supplier, then suggests a GL account and cost object based on how often that combination was used before. It’s easy to set up and works as a foundation, but it’s limited to pattern recognition and doesn’t adapt well to complex scenarios.
The PAL Model, on the other hand, is powered by SAP HANA’s Predictive Analytics Library (PAL). It applies machine learning, using multiple factors like company code, supplier, requester, expense type, tax rate, and invoice amount to generate proposals. This makes it far more accurate and dynamic than the Basic Model, but it requires SAP S/4HANA with PAL installed and builds on the Basic Model’s training.
In short: the Basic Model is static and straightforward, while the PAL Model is context-aware and designed for higher accuracy in real-world invoice coding.
Make sure to check chapter Smart coding in OpenText Vendor Invoice Management for SAP Solutions: Configuration Guide for Invoice Solution. Please understand that Step 1 deletes all coding statistics from your system.
To start with a clean surface the first step is to delete what is in the system using T-Code /OTX/PS302_TRAIN_CODING_DELETE.
Warning: This will delete the coding statistics in the selected system!
Now that we have an empty Smart Coding environment we start by training the basic Smart Coding model using /OTX/PS302_TRAIN_CODING.
For the first run always use the „Test Mode“ to make sure everything is working correctly. If the first run in test mode was successful, it can be repeated without test mode.
From this point of time it is already possible to use smart coding in the system by clicking on Smart Coding button in the Line Items Tab on the Indexing Screen:
To use the more advanced PAL Decision Model you must ensure that your system has the following prerequisites in place:
Similar to the Basic Model: for the first run always use the „Test Mode“ to make sure everything is working correctly. If the first run in test mode was successful, it can be repeated without test mode.
Once you have completed the training for the PAL Decision Tree Model you can see an entry in VIM Central Workplace (/n/OTX/PF03_WP) in work center Smart Coding:
Smart Coding in OpenText VIM can offer significant benefits — especially for organizations processing moderate to high invoice volumes. It has the potential to reduce manual data entry, improve consistency, and help teams spend less time on repetitive tasks. However, it’s important to keep expectations realistic:
In short: Smart Coding can be a useful tool to help reduce workload and increase consistency, but it’s not a magic bullet. Proper expectation setting, pilot testing, and incremental rollout are key for getting good value.
What has been your experience with Smart Coding so far? Did it meet your expectations, or did you run into challenges? Share your thoughts in the comments below — I’d love to hear them.
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.
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 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.
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.
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.
To complete the setup you simply assign you Process ID („Processing Definition“) to one or more DP Document Types:
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.
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.
If you’re managing SAP Vendor Invoice Management (VIM) and Capture solutions, ensuring compatibility between different software versions is critical. Open Text provides an invaluable resource—the „Orange Compatibility Matrix“—to simplify this.
The Orange Compatibility Matrix is an essential document provided by Open Text that outlines which versions of OpenText Vendor Invoice Management for SAP Solutions (VIM) are compatible with various Open Text Capture solutions. It clearly displays supported configurations, ensuring you always pair compatible software versions to maintain system stability and optimize performance.
Regularly checking the Orange Compatibility Matrix will keep your SAP VIM environments running smoothly.
The capture component used in conjunction with OpenText Vendor Invoice Management for SAP Solutions (SAP VIM) is usually Intelligent Capture for SAP Solutions (short: IC4S; on premise) or Core Capture for SAP Solutions (short: CC4S; hosted in the OpenText Cloud).
Continuous feedback allows the capture component of VIM to read and interpret more and more incoming .pdf-documents fully or partly. In some systems, however, it is simply never switched on. As a result, the automatic recognition of data on the documents never improves and a high manual validation effort is required. This is not only annoying but also expensive.
In simple terms, the process for continuous learning works like this:
An Archive Link Document Type refers to a classification used for documents that are stored in an external archive system but linked to SAP transactions via SAP ArchiveLink. ArchiveLink is an SAP technology that enables the connection of external document management systems (DMS) to SAP applications.
In the simplest case, there is one archive link document type in a VIM project for storing, for example invoices, let’s call it “ZINVOICE”. Whether the learning is executed or not depends on the settings assigned for this archive link document type.
In VIM projects, usually one or more archive link document types are created for both invoicing and non-invoicing processes. These allow you to create your own scenarios independently of the document types supplied with the product.
My recommendation here is always to create your own archive link document types. This makes customization easier and you don’t run the risk of accidentally resetting all possible settings during the next VIM upgrade. However, this also opens the door for the customizing mistake which I describe in this article.
You can find out in just a few minutes whether your system is learning, or at least is encouraged to learn (in addition to this setting, there are also other reasons that can prevent learning).
First we find out which Archive Link document type we are using, the quickest way to do this is in transaction /OTX/PF03_WP (VIM Central Workplace) in the work center Inbound administration.
/otx/pf03_wpSelect the „Processed“ note and select the line of a recently processed document.
In the line you can scroll to the right until you see the column „Document type“. Note all the Document types you are using. For example „ZINVOICE“.
The next step ist to check the customizing in /OTX/PF00_IMG.
/otx/pf00_imgNavigate to Inbound Configuration > Capture > Feedback:
In the table you should see all active archive link document types you are using with an active checkbox next to them:
In case you archive link document type is missing here there will be no learning taking place after validating documents. This means that your validation process does not generate a sustainable learning effect but is only valid for the current document.
The problem is quickly solved. Add the missing entry in the development system, test, transport and the issue is resolved (learning will only take place for newly processed documents).
In the case of non-invoice-related document processes, the problem is usually immediately apparent because without learning results, not a single field (with the exception of business entities) is recognized and therefore an exorbitantly high validation effort is required.
The situation is different for invoice-related processes, where the product standard already provides basic recognition results, which are then improved by validation. Therefore you already have a basis of recognition results and do not initially notice that the feedback is missing.
This setting is very simple but unfortunately easy to overlook. The system does not complain about the missing setting and everything initially appears to be working. If this article has helped you to resolve a big problem in a simple way, I would be happy if you share it!
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.
Create a new class using superclass /OTX/PF04_CL_MODULE. You can use for example SE24 or SE80 to achieve this.
/OTX/PF04_CL_MODULETo implement a business rule you must redefine method /OTX/PF04_IF_MODULE~MODULE_EXEC_CHECK.
/OTX/PF04_IF_MODULE~MODULE_EXEC_CHECIn 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:
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: 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_imgNavigate 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.
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.