Johannes Auer

30-Min-Call DE
SAP VIM customizing



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

Schlagwort: OpenText

  • What is Smart Coding and how can I use it in SAP VIM?

    What is Smart Coding and how can I use it in SAP VIM?

    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.

    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.

    What is Smart Coding?

    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.

    Benefits of Smart Coding

    • Time savings: Reduces manual effort in entering repetitive cost allocations.
    • Consistency: Ensures coding aligns with historical and organizational patterns.
    • Fewer errors: Minimizes the risk of incorrect GL postings.
    • Scalability: Supports large volumes of invoices without increasing headcount.

    Basic Model and PAL Model: What’s the difference?

    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.

    How to activate Smart Coding

    Step 0: Read the documentation and test in a sandbox environment first.

    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.

    Step 1: Delete Coding Statistics

    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!

    blank
    blank

    Step 2: Train Coding Statistics: Basic Model

    Now that we have an empty Smart Coding environment we start by training the basic Smart Coding model using /OTX/PS302_TRAIN_CODING.

    blank

    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.

    blank

    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:

    blank
    blank

    Step 3: Train Coding Statistics: PAL Decision Model

    To use the more advanced PAL Decision Model you must ensure that your system has the following prerequisites in place:

    • SAP S/4 HANA
    • PAL model installed and activated
    • Basic Model training is completed (Step 2)
    blank

    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:

    blank

    Final Thoughts

    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:

    • Smart Coding usually requires a period of training before it produces reliable results. Initially, proposals will need review, and accuracy may be limited for uncommon combinations or new suppliers.
    • The PAL model improves accuracy over the basic model, but it also requires a solid foundation: enough historical data, correct setup, and ongoing monitoring.
    • Smart Coding won’t eliminate coding errors entirely. Edge cases, exceptions, complex allocations, or unusual cost objects will still require human intervention.
    • Benefits are greatest when invoice volumes are high and coding rules relatively stable. In very volatile or complex environments, the value may be less dramatic.


    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.

  • Let’s Make History! Enabling the SAP VIM Workflow History Log

    Let’s Make History! Enabling the SAP VIM Workflow History Log

    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.

    When working with OpenText Vendor Invoice Management (VIM) for SAP, one of the most overlooked yet powerful features is the Workflow History PDF Log. This capability automatically generates a comprehensive PDF at the conclusion of the VIM process—capturing every key detail, from process milestones and approvals to workflow logs and user comments.

    This isn’t just a convenience for auditors or a checkbox for compliance. It’s a transparent, time-stamped audit trail that gives AP managers and business users immediate visibility into how an invoice was handled. What’s more, the history log is securely archived and linked to both the DP document and the SAP invoice—so it’s always accessible and never lost.

    blank

    Benefits of the Workflow History PDF

    • Audit-ready: A single document with all approvals, comments, and workflow steps.
    • Transparency: Clear visibility into who did what and when.
    • Compliance: Securely archived and linked to the invoice for future reference.
    • Flexibility: Can be customized to include company-specific information.
    blank

    How to Set It Up

    You configure the PDF history log within a profile which describes all settings for the creation of the PDF history log. You assign this profile to a OpenText VIM for SAP process step.


    You must specify that the PDF history log will be created at the end of the OpenText VIM for SAP process. To enable the creation of the PDF history log, you must assign the profile for the PDF history log (default profile: HISTORY) to the OpenText VIM for SAP process “VIM process is finished”. Without this, the PDF history log will not be created at the end of the OpenText VIM for SAP process.

    1) Define the profile for the PDF History Log

    Run the /n/OPT/SPRO transaction and navigate to OpenText Vendor Invoice Management Invoice Solution > Cross Component Configuration > PDF Log >Maintain Customizing Profiles.

    blank

    The PDF profile ‘HISTORY‘ is delivered with the baseline. You can either customize it or create your own custom profile.

    blank
    blank

    In the Define Profiles screen, you will find the following parameters that are specific for the PDF history log:

    PDF Log Class
    The complete logic of the PDF history log is included in the PDF log class /OPT/CL_C_PDF_LOG, which is delivered with the baseline. You can enhance the class by redefining components of the class within a custom class, which you can maintain instead of the baseline class.

    PDF Form Type
    Enter the type of the PDF form.

    Currently, Smart Forms is the only available entry for this field. However, it is also possible to redefine the logic of the PDF log class /OPT/CL_C_PDF_LOG within a custom class to support other techniques, for example SAP Interactive Forms.

    Default value: Smart Forms

    Form Name
    Enter the name of the SAP Smart Forms form.
    Baseline delivery includes a Smart Form /OPT/C_WORKFLOW_HISTORY01. You can copy the Smart Form using the smartforms transaction and adjust it to
    your needs. You can maintain this adjusted Smart Form in the Form Name box instead of the baseline Smart Form. The baseline Smart Form uses the SAP Smart Style /OPT/C_SF_STYLE01 for the format options of the Smart Form, for example the font and the font size of headers or default paragraphs. You can copy the Smart Style using the smartstyles transaction and adjust it to your needs. Additionally, copy the Smart Form and maintain your new Smart Style in the Output Options tab of the Form Attributes screen of the Smart Form.

    Document type
    Enter the archive document type to be used for archiving the PDF history log. Within baseline, the archive document type /OPT/PDF is delivered (we suggest that you create your own archive link document type for this).

    You must link the archive document type to the OpenText VIM for SAP Business Object and to SAP Business Objects (in case it’s not already linked by default, you can link the document type ‘/OPT/PDF’ to object types ‘/OPT/V1001’ and ‘BKPF’ via transaction OAC3).

    Overwrite
    Select this check box to overwrite PDF history logs that have already been linked to the DP document and its SAP invoice with the same archive document type.
    It is possible to create a PDF history log to a DP document manually by using the /OPT/CR_PDF_LOG report. When using this report, a PDF history log linked to the DP document and its SAP invoice can already exist.

    Selecting the Overwrite check box deletes the physical PDF document (the PDF history log) and its links to the DP document and the SAP invoice. This PDF history log can either be created manually or automatically.
    Default value:

    2) Assigning the profile to a OpenText VIM for SAP process step

    To create this PDF history log at the end of the OpenText VIM for SAP process, you must assign the profile to the VIM process is finished process step for your company codes. If you leave Company Code empty, the setting is used for all
    company codes.

    blank

    By setting up the Workflow History PDF log, you create a single source of truth for your invoice processes. With just a few configuration steps, your organization gains audit-ready documentation, transparent tracking of every approval and action, and a secure archive that is always accessible.

    Whether for compliance, audit preparation, or day-to-day process insight, the Workflow History PDF log ensures that your AP processes are not only more transparent but also more reliable and future-proof.

  • 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.

  • Stay Ahead of SAP VIM Compatibility Issues: the Orange Compatibility Matrix for VIM and Capture

    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.

    What is the Orange Compatibility Matrix?

    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.

    How to Obtain the Orange Compatibility Matrix:

    1. Navigate to support.opentext.com.
    2. Log in using your Open Text Support credentials.
    3. In the search bar, enter KB0795415.
    4. You’ll be directed to the article with a download link for the latest “Orange Compatibility Matrix for VIM and Capture for SAP Solutions”.
    5. Download and refer to the matrix when planning software updates or troubleshooting compatibility issues.
    blank

    Why is the Orange Compatibility Matrix Useful?

    • System Stability: Ensures your system operates reliably by confirming compatibility between VIM and Capture solutions.
    • Support Assurance: OpenText Support verifies compatibility using this matrix. Unsupported combinations are not eligible for official support, potentially leaving your organization without assistance during critical issues.
    • Simplifies Upgrade Planning: Clearly see what combinations of VIM and Capture solutions are certified to work together.

    Regularly checking the Orange Compatibility Matrix will keep your SAP VIM environments running smoothly.

  • If your SAP VIM Capture feels like it is not learning at all, it might be missing this crucial setting!

    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.

    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.

    blank

    How does the learning work?

    In simple terms, the process for continuous learning works like this:

    1. The system (IC4S or CC4S) extracts as much data as possible from the document
    2. The extracted data is corrected and supplemented by users in the validation client.
    3. The corrected results are sent back to the capture component via the so-called feedback link, which expands the set of rules for extracting data and generally delivers a better result for the next similar document.
    blank

    What is an Archive Link Document Type?

    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.

    Is my system learning or is it standing still?

    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_wp

    Select the “Processed” note and select the line of a recently processed document.

    blank

    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”.

    blank

    The next step ist to check the customizing in /OTX/PF00_IMG.

    /otx/pf00_img

    Navigate to Inbound Configuration > Capture > Feedback:

    blank

    In the table you should see all active archive link document types you are using with an active checkbox next to them:

    blank

    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.

    My learning is not activated, how do I solve the problem?

    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).

    blank

    Why didn’t we realize this earlier?

    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.

    Conclusion

    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!

  • 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.

  • Never forget this step before activating Business Configuration Sets (BC-Sets) for OpenText Vendor Invoice Management for SAP Solutions (SAP VIM) upgrade in SCPR20

    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 upgrading or installing OpenText Vendor Invoice Management for SAP Solutions (SAP VIM), it is often necessary to activate so-called BC Sets (Business Configuration Sets). A BC Set (Business Configuration Set) in SAP is a tool that allows users to store, manage, and transport configuration settings efficiently. It acts as a template for predefined customizing settings that can be applied to an SAP system, ensuring consistency and reducing manual effort in system configuration.

    Check all the available documentation before starting with the activation

    Compiling a list of the necessary BC Sets and activating them in the correct order can be challenging, especially given the current state of the VIM documentation.

    To ensure a smooth process, it is essential to not only refer to the Installation Guide but also carefully review the Configuration Guides and Release Notes. Also refer to the documentation for all service packs included in the upgrade, not only the latest one.

    Never forget to export the table comparison

    One of the most critical steps when performing an upgrade—especially in complex SAP environments—is to conduct a thorough comparison between the BC Set and the existing table contents before activation. This step ensures that no essential configurations are overwritten, lost, or modified unexpectedly, which could lead to system inconsistencies or functional disruptions.

    During an upgrade, new BC Sets introduced by OpenText may contain updated settings that enhance functionalities or align with new system requirements. However, they may also overwrite existing custom configurations, potentially impacting workflows, document processing, or approval rules. A careful comparison allows you to identify discrepancies, retain necessary custom settings, and selectively adopt only the relevant changes.

    To prevent accidental data loss, it is highly recommended to create a complete backup of the table contents before making any modifications. This backup acts as a safety net, allowing you to restore previous configurations if unexpected issues arise during or after the activation of new BC Sets.

    Taking the time to perform this verification process not only safeguards critical system settings but also minimizes downtime and troubleshooting efforts in case of unintended changes. In the following section, we will go through the exact steps to compare BC Sets with table contents and securely back up configurations before proceeding with the upgrade.

    Exporting the SCPR20 table comparison to .html (without cutting off important tables by mistake)

    Entering the comparison in SCPR is easy by clicking on the button below:

    blank

    The displayed list usually shows you all the data which is different (yellow) or new (green).

    blank

    In general, the export of the table comparison is often forgotten. However, if the export is carried out, there is another pitfall that should not be overlooked, otherwise data may be lost. We have to go into the output options for this.

    blank

    The output width is set to 150 by default, increase the number to 800. if tables, labels and content exceed 150 characters, they will otherwise be cut off and important information may be lost. Please also check whether 800 is sufficient here, I have not noticed any data loss in the exported files with this number. Do not change anything else in these settings.

    blank

    Now that we have prevented the file from being truncated, we can continue with the export. To do this, we go to List, Save/send and then to File.

    blank

    I prefer to save the comparison files as .html. This is small, clear and universally applicable. In addition, I don’t have to worry about Microsoft Excel versions and separators.

    blank

    For the file name I recommend using the BC Set name with “/” replaced by “_”. Also creating a folder per service pack level does help to keep the overview. I also recommend to replace the suggested .htm with .html. At least on my computer this helps with directly opening in my browser on double click.

    blank

    The export gives you a .html file which is lightweight and provides a very good overview. I recommend storing all the BC-Set comparisons together with your documentation. This is applicable for every single BC-Set in every service pack level.

    blank

    If you have paid very close attention, you will notice that in the screenshot above the BC sets of VIM 7.6 SP 5 are compared with the table contents of VIM 7.6 SP 6. This is of course not a realistic scenario and the BC sets should never be activated as shown in the comparison.

    One of the main reasons I prefer using .html as an export format is that it allows for seamless copying and pasting into Excel while preserving the structure and formatting of the data. Unlike plain text or CSV files, which may require additional adjustments, HTML tables often retain proper column alignment, making the data immediately usable for further processing, analysis, or reporting in Excel. This method helps avoid common issues like misaligned columns, missing delimiters, or incorrect data types, ensuring a smooth workflow when handling exported information.

    blank

    Conclusion

    This may seem like a lot of effort, but failing to carefully verify BC Sets before activation can lead to serious issues. If a BC Set overwrites an important configuration, and you only realize it after deploying transport requests into the production system, it becomes extremely difficult to trace back what was changed and when. At that point, identifying the root cause of the issue can be time-consuming and complex, often requiring manual comparisons, system rollbacks, or troubleshooting unexpected system behavior. Taking the time to perform a thorough review and backup beforehand can save countless hours of debugging and help avoid disruptions in critical business processes.

    With that in mind, I hope this guide helps make your VIM upgrade process smoother and more efficient. Wishing you great success with your upgrade.