The Document Chain and How Documents Reference Each Other

In SAP Business One a single business process is not one document — it is a chain of documents, created in order, each one referencing the one before it. A sale is not just an invoice; it is a quotation, then an order, then a delivery, then an invoice, then a payment. A purchase is not just a supplier bill; it is a request, then an order, then a goods receipt, then an invoice, then a payment. Each step is its own document, and the chain is what ties them together so that quantities and balances stay consistent from beginning to end.

Understanding a process in SAP B1 means understanding its chain: which document comes next, what each one does, and how each one points back to its predecessor. This document explains the mechanism that links the chain together and the status rules that tell you whether a chain is finished.

Copy-from: how a chain is built

SAP B1 chains are built by copying from. Rather than re-typing the details of a purchase order onto a goods receipt, a user creates the goods receipt from the purchase order — the system copies the partner, the items, the quantities, and the prices forward into the new document. The new document is not a duplicate; it is a successor that carries a reference back to its source.

This copy-from action is the backbone of every flow. It is why the ordered sequence matters, and it is why bypassing the sequence causes trouble: a document created from scratch, outside the chain, has nothing to reconcile against, so the quantities and balances that should tie back to earlier steps are left dangling.

The three reference fields: BaseType, BaseEntry, BaseLine

The reference from one document to its source is not stored loosely — it is recorded precisely, on every line, using three fields. When a document line is copied from a source document, SAP B1 stamps that line with exactly where it came from:

BaseType  = the DocObjectCode (type) of the source document
BaseEntry = the DocEntry (internal key) of the source document
BaseLine  = the LineNum (line index) of the source line

Together these three fields form a complete pointer: they name the kind of source document, the specific source document, and the exact line on it. A delivery line whose BaseType = 17 (the code for a sales order) and BaseEntry = 42 was copied from sales order number 42; its BaseLine says which line of that order it fulfils.

Two other identifiers are worth naming because the reference fields point at them:

• DocEntry is a document’s internal primary key — a stable integer the system assigns, unique across all documents of that type. It is what BaseEntry refers to.
• DocNum is the user-visible document number a person sees on screen. It is not the same as DocEntry, and the chain is linked by DocEntry, not by the number printed on the page.

Because the reference lives on each line, a single successor document can draw from several source documents at once — for example one invoice that bills two different deliveries — with each line pointing back to its own origin. The chain is line-precise, not merely document-precise.

Tracing a chain

Following a chain means following the reference fields from one hop to the next. Given a line, its BaseType and BaseEntry identify its parent; reading that parent’s lines gives their BaseType/BaseEntry, which identify the grandparent; and so on back to the start of the chain. Walking the fields forward and backward reconstructs the full Order to Delivery to Invoice path.

This is the only mechanism the system provides for cross-document tracing. There is no single field that holds the whole chain and no one query that returns it end to end — each hop is a separate step that follows BaseType and BaseEntry to the next document. The chain is real and precise, but it is walked one link at a time.

Open and closed: knowing when a chain is finished

Every transactional document carries a status, and the status is how SAP B1 tells whether a document still has work outstanding:

• Open — the document has not yet been fully drawn from. A sales order is open while goods remain to be delivered; a delivery is open while it remains to be invoiced.
• Closed — the document has been fully consumed by its successors, or was closed manually. Nothing further is expected from it.

The status is driven by the chain. When a successor copies from a source and fulfils the whole of it, the source closes automatically. A purchase order closes when its goods receipt accounts for everything ordered; a goods receipt closes when its A/P invoice accounts for everything received. Partial fulfilment keeps a document open, because part of it is still outstanding — a partially delivered order stays open for the remainder.

This gives the open/closed status a plain business meaning: open documents are the unfinished work. Open sales orders are the backlog to ship; open deliveries are the shipments not yet billed; open invoices are the amounts not yet paid. Reading status across a chain is how a company sees what is still in flight.

The document relationship map

The chains do not run in isolation. The sales side and the purchasing side each have their own sequence, the inventory documents bridge the two by moving stock, and the finance backbone receives postings from all of them. The map below shows how the major documents relate — how each side flows toward a payment, where stock is increased and decreased, and where the general ledger is posted.

flowchart TD
    subgraph SALES["Sales Side — Order to Cash"]
        OPP[Opportunity] --> SQ[Sales Quotation]
        SQ --> SO[Sales Order]
        SO --> DEL[Delivery]
        SO --> ARI[A/R Invoice]
        DEL --> ARI
        ARI --> IP[Incoming Payment]
        IP --> BR1[Bank Reconciliation]
    end

    subgraph PURCHASE["Purchasing Side — Procure to Pay"]
        PR[Purchase Request] --> PQ[Purchase Quotation]
        PQ --> PO[Purchase Order]
        PO --> GRPO[Goods Receipt PO]
        GRPO --> API[A/P Invoice]
        API --> OP[Outgoing Payment]
        OP --> BR2[Bank Reconciliation]
    end

    subgraph INVENTORY["Inventory Bridge"]
        DEL -- decreases --> STOCK[(Stock)]
        GRPO -- increases --> STOCK
        XFER[Transfer] -- moves --> STOCK
    end

    subgraph FINANCE["Finance Backbone"]
        ARI -- posts --> GL[(General Ledger)]
        API -- posts --> GL
        IP -- posts --> GL
        OP -- posts --> GL
        DEL -- posts COGS --> GL
        GRPO -- posts value --> GL
    end

Reading the map, three patterns stand out. First, each side is a linear chain toward a payment: the sales side runs quotation to order to delivery/invoice to receipt; the purchasing side mirrors it, request to order to receipt to invoice to payment. Second, the inventory bridge is where physical stock actually moves — a delivery decreases stock, a goods receipt increases it, a transfer relocates it — and it is shared by both sides. Third, the finance backbone collects the automatic postings: invoices post receivables and payables, payments post to the bank, and the delivery and goods receipt post the inventory value and cost of goods sold. Every arrow into the ledger is a posting the document makes on its own.

Why the chain matters

The chain is not bureaucracy; it is the safeguard that keeps the business correct. Because a successor copies from its source and closes it on full fulfilment, the chain guarantees that a company does not, for example, pay for goods it never received or bill for goods it never shipped — the invoice ties back through the receipt or delivery to the order, and the quantities reconcile at every link.

The practical way to reason about any SAP B1 process is therefore to think in the chain: identify which document a user is on, what its BaseType/BaseEntry references point back to, whether it is open or closed, and what the correct next document in the sequence is. Guiding someone along that reference chain, in the right order, is what keeps quantities and balances consistent — and it is the heart of working correctly in the system.