OpenText VIM document types: determination needs an owner after go-live
Get the document type wrong at the front of OpenText Vendor Invoice Management and everything after it is wrong in a perfectly consistent way.
The configuration explains why. Document type is the highest-level attribute of a VIM document: it sets the screen layout and the SAP transaction that gets called. Every document type needs at least one process type, and the process type decides the initial actors and what they can do. In /OPT/VIM_1CX1 you maintain the document type, its default process type, and the process-type determination sequence that steps through checks to pick a path. Upstream, the Foundation layer holds the BAdIs that classify documents in the first place. Even supplier behavior has a table: /OPT/VT_DOC_DET lists vendors who send PO-based invoices without quoting a PO number.
Most projects still treat it as a build-workshop deliverable: map channels and attributes, set the rules, transport, done.
Then production happens. A supplier moves from email to EDI, from a portal to OAWD, or starts arriving through Ariba. Vendor master attributes change. A company code carve-out appears. Somebody edits determination to close a ticket, and the configuration starts drifting away from the work instructions AP actually follows. The end-to-end VIM roadmaps practitioners share are right to put document type early. Where they stop, at "configured," is where the run problem starts.
So the operating choice is narrow: name who owns determination after go-live, not just who configured it once. (This isn't a rerun of Foundation before Invoice Solution, and it's not another best practices after go-live list.).
What the run team writes down
Five things, kept current without a project manager in the room:
Inputs. Channel, company code, vendor attributes, PO and non-PO signals, and anything else determination really relies on.
The production catalog. Every document type in production, with its business meaning and not only its code.
Who may change determination. The AP process owner and the VIM functional lead; finance as well when the change moves park or post risk.
How a change reaches production. Transport or a controlled customizing path, with a test pack. No silent production edits.
When it gets re-checked. After every channel change and every supplier onboarding that touches determination.
| Who | Owns |
|---|---|
| AP process owner | Whether the business still agrees with how invoices are classified |
| VIM functional lead | The configuration objects and the impact analysis when a rule changes |
| Basis / transport owner | How the change moves through the landscape |
| Finance | Sign-off when a determination change shifts exception or posting risk |
Neighbors, not the same job
Document-type determination decides what kind of VIM document you have. Process type and later rules decide how it's validated, parked and posted. Blur the two ownerships and tickets bounce: AP says "wrong type," IT says "process type is fine," and the invoice ages while they argue.
Keep a thin handshake. When determination changes, the process-type owner confirms the downstream path still fits. When process-type rules change, the determination owner confirms invoices still land on the intended type. Two names on one change ticket whenever both are touched.
Five shapes of drift
A new email or EDI variant lands on the wrong document type, and AP reclassifies by hand forever.
Two analysts keep private notes on "special vendors," and the ruleset and reality part ways.
A hypercare workaround becomes the real determination path, so QA stops predicting production.
Process-type and document-type ownership sit in different teams with no handshake.
A support package or BC-Set refresh changes defaults, and nobody compares determination against the owned catalog.
That isn't complexity. It's a ruleset nobody owns.
When the drift is in the code
Not all drift is human. OpenText Support KB0716729 describes rules with several fields joined by AND: an unsorted internal table put the AND condition last, so the comparison effectively ran as OR, and a blank PO number combined with an EBELN blank-setting could wrongly select the non-PO type (fixed in 7.5 SP5 and 7.0 SP9). KB0841486 covers function module /OPT/VIM_DETERMINE_DOC_TYPE missing the correct type when a document has no line items, reported on VIM 23.4 SPS2 and fixed in 23.4 SPS3. KB0500813 is the sharpest of the three: with no default DP document type and several DP types tied to one archive document type, a document coming from OpenText Business Center could get a random type (fixed in VIM 7.5 SP4).
Two lessons. The ruleset you wrote and the ruleset that runs aren't guaranteed to match, which is why the test pack carries negative tests and an invoice with no line items. And defaults are design decisions: set a default DP document type, and don't let several types share one archive document type (Thursday's post picks that up). We'd hand both lessons to the determination owner, with the VIM functional lead tracking which fixes your release already contains.
OpenText's product FAQ says the process configuration may stay unchanged through SAP ERP upgrades. Useful, and it cuts both ways: a ruleset that survives upgrades also carries every unreviewed edit forward. Determination belongs inside the Invoice Solution customizing path you standardized. One owned ruleset beats unmanaged enhancements that re-label documents after the fact, and a shadow classification spreadsheet is never the system of record. If a "determination change" is really a broader rules change, take it to business rules change owner. If Foundation objects such as channels and profiles are incomplete, fix that sequence first.
None of this means redesigning every document type this quarter, or licensing unchecked production edits. It does take a handful of unglamorous artifacts. The production catalog, with the owner named on the page AP actually uses. A change-request template that asks which suppliers and channels are affected and which process types follow. A test pack with one PO invoice, one non-PO, one with no line items, each inbound channel in scope, and a deliberate wrong-type negative test. No direct production customizing for determination, apart from an emergency path that still names finance. A determination-impact line on the new-supplier and new-channel onboarding checklist. And a quarterly sample of mis-typed invoices, fixed through the owned path instead of tribal knowledge.
If the statement of work just says "configure document types," it's missing the after-go-live half. The line we'd want: "For OpenText VIM document-type determination after go-live: name the AP owner and VIM functional owner; document determination inputs and production document types; require a test pack and transport path for changes; finance signs when exception or posting risk changes."
