Goods Receipt PO (GRPO)

A Goods Receipt PO (GRPO) records the physical arrival of goods from a supplier. It is the first document in the purchasing chain that actually moves something: it increases stock immediately and posts an accounting accrual. It is the “what actually arrived” leg of the three-way match, and it usually copies from the Purchase Order it fulfils.

Purpose

A GRPO answers the question “what did we actually receive?” When a delivery lands at the warehouse, the receiving team records it against the open Purchase Order. The GRPO captures the quantities that physically arrived — which may be less than, equal to, or (in error) more than what was ordered — and lands that stock in the receiving warehouse.

Recording receipt separately from billing is deliberate. The goods can arrive before, after, or without the supplier’s invoice, and the business needs its stock and its liability to be correct the moment goods change hands, not whenever the paperwork catches up. The GRPO makes the stock real and books a Goods Received Not Invoiced (GRNI) accrual for the liability that will later be settled by the A/P Invoice.

Position in the document chain

The GRPO sits between the Purchase Order and the A/P Invoice. It copies from the PO and is itself copied into the A/P Invoice.

flowchart TD
    PO[Purchase Order] -->|goods arrive| GRPO[Goods Receipt PO]
    GRPO -->|supplier invoices| API[A/P Invoice]
    GRPO -->|goods sent back| PRET[Purchase Return]

    style GRPO fill:#dcfce7,stroke:#16a34a,stroke-width:3px
    style PO fill:#ede9fe,stroke:#7c3aed
    style API fill:#fef9c3,stroke:#ca8a04
    style PRET fill:#fee2e2,stroke:#dc2626

• Copies from: a Purchase Order (normal), or nothing — a GRPO can be raised directly, though that breaks the three-way match.
• Becomes: an A/P Invoice when the supplier bills. If received goods must go back, a Purchase Return reverses the GRPO.

Partial receipts are allowed: one PO can be received across several GRPOs. Each GRPO line carries BaseType / BaseEntry / BaseLine pointing back to the originating PO line, so the received quantity can always be matched against the ordered quantity.

The three-way match

The GRPO is the middle leg of purchasing’s core control. Best practice is to match three documents before a supplier is paid:

flowchart TD
    PO[Purchase Order — what we agreed to buy]
    GRPO[Goods Receipt PO — what actually arrived]
    API[A/P Invoice — what the supplier is charging]

    PO --> MATCH{Three-Way Match}
    GRPO --> MATCH
    API --> MATCH

    MATCH -->|quantities + prices agree| PAY[Approve for payment]
    MATCH -->|discrepancy| HOLD[Hold — investigate]

Because the A/P Invoice is normally based on the GRPO, which is based on the PO, the chain builds the match automatically. A quantity mismatch between the PO and the GRPO is the classic signal that something needs manual attention before payment.

Key fields

A GRPO is a Document entity — the universal base shared by every SAP B1 transactional document — distinguished by its DocObjectCode of oPurchaseDeliveryNotes (20). The supplier’s CardCode is a vendor V-code (e.g. V001).

Header

Lines (DocumentLines collection)

Stock and G/L effect

Stock increases immediately. The received quantity is added to on-hand stock in each line’s WarehouseCode. A wrong warehouse here puts real stock in the wrong place and causes downstream picking failures.

Under perpetual inventory the GRPO also posts a journal entry: it debits Inventory (stock is now an asset the business holds) and credits Goods Received Not Invoiced — a temporary liability accrued because the goods are owed for but not yet formally billed.

Goods Receipt PO (goods arrive, not yet invoiced):

DR  Inventory                          1,000
CR      Goods Received Not Invoiced           1,000

The GRNI credit is the accrual the A/P Invoice will later clear. If no PO/GRPO ever existed and the A/P Invoice were posted alone, that control step would be skipped and inventory would not be updated by the receipt.

Service Layer entity

(SAP’s current generally-available Service Layer is /b1s/v2/; Norma’s connector and mock both speak /b1s/v1/PurchaseDeliveryNotes. Note the SL name is PurchaseDeliveryNotes even though the business calls it a Goods Receipt PO.)

How to create it in Norma

Use the create_goods_receipt_po tool. It needs:

• card_code — the supplier’s code, a vendor V-code (e.g. V001).
• lines — each an item_code + quantity (the quantity actually received).

Every Norma write is held for human review before it reaches SAP. This gate matters especially here: a GRPO moves real stock and books the GRNI accrual, so the review shows exactly what will be received (supplier, lines, quantities, warehouse, value) before anything posts. Only on approval does the connector POST it to /b1s/v1/PurchaseDeliveryNotes. Nothing is written to SAP until a human approves.