Skip to content
Cette page existe aussi en français. Voir en français
SAP Tutorials

SAP DMS: the Document Info Record, and when you actually need it

Dropping a PDF onto a maintenance order through the generic object services is not document management. Until a Document Info Record exists, that is a typed master record, versioned and linked to the object, you do not have a managed document: you have an attachment. The distinction sounds academic. On a project, it decides whether your drawings, certificates and specifications are still findable in five years or dissolve into a shared drive. Here is exactly where the line runs, and how SAP DMS draws it.

Key takeaways in 30 seconds
  • SAP DMS manages documents through a Document Info Record (DIR), an object far more structured than a plain attachment.
  • Four transactions cover daily work: CV01N (create), CV02N (change), CV03N (display), CV04N (find).
  • The document type, configured in DC10, drives numbering, statuses, classification and links to SAP objects.
  • DMS is fully available in S/4HANA, in the classic GUI as well as through the Fiori Manage Documents app.

An attachment is not a managed document: what a DIR really is

SAP offers two very different ways to attach a file. The first, the generic object services (GOS), sticks an attachment onto a business object. It is fast, but the file stays mute: no type, no version, no status, no cross-object search. The second goes through the Document Management System and its central object, the Document Info Record.

A DIR is a master record. It does not hold the file itself: it carries the document’s metadata (number, type, version, document part, status) and points to one or more originals stored in a content repository. Technically, the DIR header lives in table DRAW, its multilingual descriptions in DRAT. This metadata layer is what turns an inert file into a governed document.

A DIR is identified by a four-part key: the document type, a number, a document part and a version number. That key is why two revisions of the same drawing coexist without overwriting each other: they only differ by version. A GOS attachment, by contrast, is stored without that structure, with no notion of version or part. That is the whole gap between a deposited file and an identified document.

Beyond metadata, the DIR links external files to SAP objects while managing versions, statuses and classification. In practice: an assembly drawing linked to a material, a safety sheet linked to a functional location, a material certificate linked to a batch. As soon as a document must be typed, found by characteristic or linked to an object, an attachment no longer cuts it.

Create, change, find: CV01N, CV02N, CV03N, CV04N

Classic DMS rests on four transactions, all centered on the DIR. You need no more than these to be operational.

TransactionRole
CV01NCreate a Document Info Record
CV02NChange an existing document (new version, status, originals)
CV03NDisplay a document in read-only mode
CV04NFind a document by multiple criteria
The four core DMS transactions, all centered on the Document Info Record.

The transaction that changes daily life is CV04N. It does not look for a file by name: it queries the DIR repository by document type, status, classification data or linked object. That is the difference between digging through a shared folder and querying a structured database. In the SAP menu, these transactions sit under Logistics, Central Functions, Document Management System, Document.

The document type, the backbone: DC10 and the SPRO path

Everything starts with the document type. It decides the DIR’s behavior: number range, field selection, the linked class, and above all which objects a document of that type is allowed to link to. Designing it poorly means dooming yourself to documents that cannot be found or attached.

Configuration happens through transaction DC10, or the customizing path below.

SPRO path:

Cross-Application Components → Document Management System → Control Data → Define Document Types

Three sub-steps deserve attention in that same Control Data node: defining number ranges (Define Number Ranges), allowed statuses (Define Document Status) and permitted object links (Define Object Links). A document type is never an empty shell: it encodes your document policy.

Two settings carried by the document type change the daily experience. Field selection decides which attributes are mandatory, optional or hidden when a DIR of that type is created: it is what stops a user from creating a document without filling in what matters to you. Number ranges, in turn, are declared internal or external. Internal means SAP numbers automatically; external means the number is keyed by hand, which becomes essential when your document numbering already exists and must be honored.

When you need to create document types in bulk or load a volume of existing DIRs, you leave manual entry for a data-load tool. The classics remain LSMW and LTMC; on the S/4HANA migration-object modeling side, the Migration Object Modeler (LTMOM) is the entry point to know.

Classifying a DIR: classification through class type 017

A DIR’s standard fields never fully describe a business document. That is where classification comes in. In DMS, the dedicated class type is 017. You create a class of that type, attach characteristics to it (an application area, a discipline, a confidentiality level, a project reference) and assign it to the document type.

The benefit is twofold. First, these characteristics become search criteria in CV04N: a poorly classified document is a lost document. Second, they structure the information without touching the standard, so without development. To go deeper into the general mechanism, the SAP classification system follows the same principles of classes and characteristics, whatever the classified object.

Note a second class type, 048, reserved for the classification of object links. It is an advanced refinement: keep it for cases where the link itself must carry attributes. In a first rollout, 017 covers most needs.

This is where DMS earns its keep, and where it finally parts ways with a shared drive. A DIR can be linked directly to business objects: material, bill of material, functional location, equipment, maintenance order, and many more. Table DRAD materializes these document-object links.

One Document Info Record linked to several SAP objects through object links Document Info Record Material Equipment Functional location Maintenance order Batch
One Document Info Record links a document to several SAP objects (material, equipment, functional location, maintenance order, batch) through the object links stored in table DRAD.

The concrete effect: from an equipment record, you reach its drawings, procedures and certificates without ever leaving SAP. Conversely, from the document, you see every object it documents. Information stops being filed somewhere and becomes linked to what it describes. When the linked object is tracked individually, for example through a serial number, document traceability reaches down to the individual part.

Allowed link types are not universal: they are declared precisely in the document type’s customizing, the Define Object Links sub-step mentioned earlier. A document type only accepts the objects you have authorized it to carry.

Lifecycle: versions, status network, originals

The old reflex was to describe a document’s lifecycle in four fixed boxes: creation, validation, distribution, archiving. The SAP reality is finer, and more robust.

The DIR first manages versions. A drawing revision does not replace the old one: it creates a new version, and the history stays available. It then manages a status network: each document type defines its possible statuses and the allowed transitions between them, for example from In Process to Released to Obsolete. This is not decorative: a status conditions who can do what, and may trigger downstream actions.

A status carries more than a label. It can mark a version as released, restrict changes to the originals and depend on an authorization. In practice, a document moved to a Released status is locked for editing for profiles that have no right to reopen it, while a new version starts again from a work status. It is this interplay between versions and statuses that gives DMS its value as evidence, where a shared drive can never tell which copy is authoritative.

Finally, the DIR manages the originals. Files are deposited through a check-in mechanism, and taken back out through check-out for changes. They do not sit on a workstation: they are stored in a content repository (a SAP Content Server or an external archive depending on the setup). The DIR always knows where the authoritative version is, and who deposited it.

Classic GUI or Fiori Manage Documents: DMS under S/4HANA

First thing to clear up, because the question keeps coming back: no, DMS is not a legacy on borrowed time. The Document Management System remains a component of S/4HANA, available both on-premise and in the cloud. No end-of-support date is announced for document management itself.

What changes is the interface. On-premise and in private cloud, transactions CV01N to CV04N are still there, identical. In S/4HANA Cloud Public, document management goes through the Fiori Manage Documents app, which covers versioning, search, statuses, attributes and classification, multilingual descriptions, object links and file handling. APIs around the Document Info Record and the Attachment Service component round out the setup for integrations.

For a consultant, the right reading is not GUI versus Fiori, but: same business object, the DIR, exposed through two doors depending on the edition. The codes (document types, 017 classes, statuses) stay the same underneath. If you are framing an S/4HANA project, the document topic comes up early, like the rest of your SAP rollout.

SAP DMS or a plain shared network drive?

The whole practical question sits here. A shared drive is free, immediate, and largely enough for files with no stakes. DMS asks for configuration. The table below states the decision criterion rather than the feature list.

CriterionAttachment / shared driveDocument Info Record (DMS)
Link to an SAP objectNoYes (material, equipment, order…)
VersioningManual and fragileNative, with history
Status networkNoYes, configured transitions
Search by characteristicsNoYes, through 017 classification
Traceability and auditWeakStrong
Multilingual descriptionsNoYes
Originals managementNoneCheck-in / check-out to a repository
When a shared drive is enough, and when a Document Info Record becomes necessary.

The decision rule is simple. If a document just has to exist somewhere, a shared folder will do. As soon as it must be linked, versioned, searched or traced, you need a DIR. Putting DMS everywhere is as counterproductive as putting it nowhere: the right reflex is to target the documents that have a business life.

Frequently asked questions about SAP DMS

What is the difference between an SAP attachment and a Document Info Record?

An attachment added through the generic object services (GOS) stays a file stuck onto an object, with no typing or lifecycle. A Document Info Record is a typed master record: it carries metadata, a version, a status, a classification and links to SAP objects. Until there is a DIR, there is no managed document.

Which transactions are used to manage a document in SAP?

The four core transactions are CV01N (create), CV02N (change), CV03N (display) and CV04N (find). All act on a Document Info Record.

Where are document types configured in SAP DMS?

Through transaction DC10, or the SPRO path Cross-Application Components, Document Management System, Control Data, Define Document Types. The document type drives number ranges, field selection, the class and the allowed object links.

Does SAP DMS still exist under S/4HANA?

Yes. The Document Management System remains available under S/4HANA, both on-premise and in the cloud. The CV0xN transactions exist on-premise and in private cloud; S/4HANA Cloud Public exposes document management through the Fiori Manage Documents app and the Document Info Record APIs.

Do I need SAP DMS or a plain shared network drive?

A shared drive is enough to store files with no business link. As soon as you need to link a document to an SAP object, manage versions, a status, a search by characteristics or audit traceability, DMS and its Document Info Record become necessary.

What is class type 017 in SAP DMS?

Class type 017 is used to classify Document Info Records: you attach characteristics to it (custom metadata) that make documents searchable. Class type 048, in turn, covers the classification of object links.

DMS is not about filing away files: it turns a document into a linked, versioned and traceable business object. If you are starting out, open CV01N in a sandbox and create a first Document Info Record linked to a material. In ten minutes you will understand what no attachment will ever do.

Share

Keep reading

SAP Tutorials

SAP EWM Master Data Integration: ERP Sync with CIF, ALE, DRF

Since the move to S/4HANA, the question "how do you synchronize data between SAP ERP and EWM" no longer has the same answer, and many projects still get it wrong...

Michael Antoine Michael A. 7 min read
SAP Tutorials

SAP Serial Number: OIS2 setup and material vs equipment

A SAP serial number is the unique identifier attached to one specific physical unit of a given material. It is the tool for unit-level traceability, the foundation for individualized after-sales...

Pierre Balbinot Pierre B. 15 min read
SAP Tutorials

SAP PRT: Production Resources and Tools

On an industrial site, the tools shared between production lines are often invisible in SAP. Jigs, probes and technical drawings move from one order to the next, but nobody knows...

Pierre Balbinot Pierre B. 13 min read
SAP Tutorials

SAP WM 2 Step Picking: Optimize your order-picking processes

2-step picking cascade in SAP WM 2-step picking SAP WM: the full cascade From group creation to the dispatched delivery Step 0: Group creation VL06P (deliveries) or LT41 (transfer requirements)...

Michael Antoine Michael A. 15 min read