OpenText VIM and ArchiveLink: settle document types before the first invoice

"ArchiveLink OK" is not a prerequisite. It's a hope with a checkbox next to it.

Picture where it leads. The first productive invoices post. AP opens one in the workplace and there's no image, or there is one but it sits in the wrong repository. Somebody remembers QA used a different ArchiveLink document type. The signed checklist has no list of document types attached.

None of that means ArchiveLink is unreliable. It's the standard SAP interface for linking stored documents to SAP business objects. OpenText Archiving and Document Access for SAP uses it to tie business documents, incoming invoices included, to SAP transactions while reusing SAP's own user management and authorizations. OpenText Core Archive for SAP Solutions, the cloud-native option, connects to S/4HANA through ArchiveLink, SAP ILM and CMIS. The interface is fine. The trouble is a storage decision that never got made before invoice volume started.

The implementation prerequisite checklists VIM practitioners share put ArchiveLink right beside FI/MM readiness, document types and the update BAdIs (INVOICE_UPDATE among them). That order isn't ceremony. If ArchiveLink document types and repository assignment are still vague when the first invoice arrives, you don't have a content problem later. You skipped a go-live prerequisite.

Well before cutover: decide

The configuration path is short, which is why it gets rushed. In Foundation (/OTX/PF00_IMG) the ArchiveLink repository is among the first things set, before channels and profiles. Content repositories live in OAC0, global ArchiveLink document types in OAC2, links between object types, document types and repositories in OAC3. On the VIM side, each DP document type in /OPT/VIM_1CX1 carries an archive document type field. A long-standing SAP Community walkthrough recommends one ArchiveLink document type per DP document type, even when the process is the same, so the two stay separable.

Write four things on the cutover checklist that Basis, VIM and AP can all initial:

• ArchiveLink document types in scope. The codes VIM will use for incoming invoices and related images. Never "default."

• Repository assignment. Which content repository, or repositories, receives each type, with the connection tested from every landscape that will post. Country-specific mappings listed, not left to the default.

• The mapping. How VIM document types and process paths map to ArchiveLink types, so retrieval matches what AP expects to open.

• Fail-closed behavior. What happens if the archive is unavailable at capture or post: park, reject or block. Not a silent "post without image."

Then the owners. Basis, or whoever owns content services, runs repository availability, ArchiveLink customizing hygiene and monitoring. The VIM functional lead owns the mapping from VIM document handling to ArchiveLink types. The AP process owner accepts that retrieval in the workplace keeps the business promise: we can open the invoice image. Security and compliance confirm retention and access match policy. Note what's missing from that list: "ArchiveLink was already in the landscape."

Before the first invoice: prove

Store and retrieve sample PO and non-PO images in QA using production-like document types. Walk the whole chain: VIM document type, ArchiveLink type, repository, then retrieval from the workplace and from the posted SAP document.

OpenText's support portal explains why the test has to run per channel and end on the posted document. KB0454946 (updated 24 Sep 2026) lists the reasons a new DP created through OAWD may never appear in the inbox or workplace: an incorrect OAC2 setup, a missing SOA0 workflow-object association, a missing OAC3/TOA01 link, OAWD settings, or a blank archive document type in DP configuration, with the SWO1 object /OPT/V1001 (Customizing tab, delegation type) worth checking. Look at the symptom. A storage gap surfaces as a missing work item, so AP finds it first.

The IDoc channel has its own history. Under KB0469176, /OPT/DP_INBOUND_IDOC_PROC didn't pass the archive object, leaving archive data missing in /OPT/VIM_1HEAD (fixed in VIM 7.0 SP7, VIMI-15316). Under KB0611362, IDoc documents took the DP configuration's "Default archive doc.type" instead of the country-specific ArchiveLink mapping (fixed in 7.0 SP6 and 7.5 SP2). And KB0575454 covers an image missing on the posted SAP document because the TOA0* link entries for BUS2081 weren't there (correction VIMI-22005).

So prove it four ways: every inbound channel, every country mapping, retrieval from the DP, retrieval from the posted document. In our view Basis owns the OAC and SOA0 customizing, the VIM functional lead owns the mapping and knows which of those corrections are in, and AP signs only after opening the image from a posted invoice. Two VIM document types sharing one ArchiveLink type that AP can't tell apart in retrieval is exactly the kind of thing this catches. Train AP on the fail-closed path while it's still theory. Put the FI/MM and update-exit questions on the same checklist page, even when other workstreams own them.

Do the naming while invoice volume is zero. It's tempting to park storage until the "content" workstream has bandwidth, and that's how cutover finds the mismatch for you.

After go-live: a different owner

Write-job discipline and retention still need owners after go-live, named separately. OpenText's GDPR post uses the scanned vendor invoice attached through ArchiveLink as its worked example: keep it as long as tax law requires (10 years in Germany, in their example), then delete it, with SAP ILM able to apply the same retention schedule to attached ArchiveLink documents. That's a real decision with a real owner, but it shouldn't reopen which document type the first PO invoice used.

In an OpenText customer roundup, a Capitec Bank SAP architect put the stakes plainly: their back-office solutions play "a vital role in enabling us to pass audits, address supplier enquiries and pay invoices." All three depend on finding the image.

Defer the naming and two more failures join the ones at the top of this post. Write-job and retention debates start before anyone can find last Tuesday's invoice. And a landscape refresh breaks the repository link, and nobody was ever trained on fail-closed behavior.

Invoice images stay on the ArchiveLink and OpenText repository path you standardized for VIM. Named document types and tested retrieval, not an ad-hoc file share "just for go-live." Content Server when ArchiveLink isn't enough is a real conversation, but it's no reason to skip document-type readiness on the VIM path you already chose. Hosting questions belong in ArchiveLink on RISE, and job scheduling in the document archiving write job. Neither is an excuse to leave document types unnamed. We're not proposing a historical image migration this week either, and we won't quote archive success rates nobody measured.

The SOW line we'd want: "Before first productive OpenText VIM invoice: name ArchiveLink document types and repository assignment; map VIM document handling to those types; test store/retrieve in each relevant landscape; name Basis and VIM owners; define fail-closed behavior if archive is unavailable." If yours only says "configure ArchiveLink," it's describing a component, not a readiness gate.