OpenText VIM BC-Sets: compare before you activate
Activation is an operating choice
OpenText Vendor Invoice Management ships Business Configuration Sets so teams can load or refresh customizing during install and upgrade. In SAP, that work usually lands in transaction SCPR20. The tool is familiar. The risk is treating Activate as a checkbox on a cutover runbook.
Public practitioner notes (including guidance that circulates around VIM upgrades) are consistent on one point: compare the BC-Set to your current customizing tables before you activate, review differences, and keep a backup of what you are about to overwrite. That is not ceremony. It is how you avoid silently resetting park reasons, channels, or process parameters that AP already tuned after go-live.
This article is not a license conversation and not a mandate to upgrade to a particular VIM release on a calendar. It is the narrower choice: compare, back up, name who may activate—especially for sets that change how invoices are processed.
The operating choice
Write four lines Basis, VIM functional, and AP can all defend:
Which BC-Sets are in scope. Install baseline, upgrade delta, support-package delta—named by the OpenText / project list for your release path, not a generic “activate all VIM sets.”
Compare before activate. In SCPR20, run the comparison against customizing tables (including variable-inclusive comparison when prompted values matter). Export or save the comparison result. Review entries that would overwrite production-tuned values.
Back up what you have. Customizing transport, table export, or the controlled backup your change process already uses—before activation, not after the log surprises you.
Who may activate which class of set. Technical baseline sets vs process-affecting sets. Process-affecting sets need AP (and often finance) sign-off on the comparison delta—not only a Basis window.
Who carries it? Basis / technical VIM lead owns SCPR20 execution, comparison export, activation log, and transport hygiene. VIM functional lead interprets which differences are process-affecting. AP process owner signs acceptance when park reasons, routing, match, or channel behavior would change. Finance signs when authority, tolerance, or payment-adjacent controls sit in the delta. There is no sentence “the upgrade guide said activate” that replaces those names.
What “process-affecting” means in practice
You do not need a dramatic outage. You need patterns like:
A delta BC-Set reloads document-type or process parameters AP changed in hypercare and never re-documented.
Channel or mapping defaults return; EDI and email paths behave differently on Monday morning.
Park reasons or workflow-adjacent customizing shift; the queue looks “wrong” with no transport AP approved.
Two landscapes activate the same set with different overwrite choices; QA no longer predicts production.
None of that is “BC-Sets are unsafe.” It is activation without comparison ownership.
Clean core reading
Keep VIM customizing inside the OpenText add-on tables and published activation path you standardized. Prefer a named comparison review over a shadow spreadsheet of “values we must put back after upgrade.” Do not invent a parallel config store outside SAP to avoid BC-Set discipline. Do not treat partner messaging about ECC maintenance end-dates as a reason to skip compare-and-backup on this activation.
What this is not
This is not a demand to freeze all BC-Set activity. It is not permission to activate every set because a window is open. It is also not a rewrite of best practices after go-live or of RISE re-prove work. It is not competitor blame when a queue spikes after cutover. Name the set, the comparison, the backup, and the signer.
A practical checklist
Inventory: BC-Sets planned for this install/upgrade; owner per set class.
Compare: SCPR20 comparison run and exported before activate; variable-inclusive when values matter.
Backup: customizing backup or transport of current values logged in the change ticket.
Sign-off: AP (and finance when needed) on process-affecting deltas; Basis alone is not enough for those.
Activate: expert/overwrite options per OpenText guidance for your release—chosen deliberately, not by habit.
After: activation log reviewed; smoke paths for PO, non-PO, and each inbound channel in scope; rollback plan named if a process path regresses.
How the SOW should read
Prefer language like: “For OpenText VIM BC-Set activation in SCPR20: run and retain table comparison before activate, back up current customizing, classify technical vs process-affecting sets, and require AP (and finance when applicable) sign-off before activating process-affecting sets; Basis owns execution and the activation log.” If the paper only says “activate VIM BC-Sets,” require the compare-and-sign lines.
