> ## Documentation Index
> Fetch the complete documentation index at: https://agents.nanonets.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# SAP Read Goods Receipts (Material Documents)

> Reads every material document line posted against a purchase order, grouped by material document.

Reads the goods movements posted against a purchase order (`A_MaterialDocumentItem` in `API_MATERIAL_DOCUMENT_SRV`, with each document's header). Display name **"SAP Read Goods Receipts (Material Documents)"**. Off by default.

Use it to see what was actually received, for invoice matching. For inbound deliveries rather than posted receipts, use `read_sap_grn`.

## Authentication and enablement

Requires a workspace SAP integration. `base_url` and `authorization` are injected. Enable the tool and bind the integration.

## Inputs

| Field | Required | Notes |
| - | - | - |
| `purchase_order_number` | yes | The purchase order whose receipts to read, e.g. `4500000001`. |
| `movement_types` | no | SAP movement type codes to keep, e.g. `["101","102"]`. Filtered in SAP, so the lines never leave it. Omitted, every movement on the order comes back. Codes are configured per system; pass the ones the system uses. |

## Outputs

`material_documents[]`, one per material document in the order SAP returned them, with `total_documents` and `total_items`.

* Each document: `material_document`, `material_document_year`, `fiscal_year`, `posting_date`, `document_date`, `delivery_note` (the supplier's delivery or packing slip number), `header_text`, and `items[]`. `creation_date` also holds the posting date.
* Each line: `material_document_item`, `material`, `description`, `goods_movement_type`, `debit_credit_code`, `quantity`, `unit`, `quantity_in_base_unit`, `base_unit`, `plant`, `storage_location`, `purchase_order`, `purchase_order_item`, `supplier`, `is_cancelled`, `is_completely_delivered`, `currency`, and the reversal link `reversed_material_document`, `reversed_material_document_year`, `reversed_material_document_item`.

<Warning>
  Every movement on the purchase order comes back unless `movement_types` narrows it: receipts, reversals, returns and transfers. Quantities are never negative, so a reversal reads like a receipt. Adding up `quantity` across all lines reports more received than arrived — on one real order, 20 of 34 lines were 321 transfer postings and the unfiltered total came to more than twice what was received.

  Decide each line from `debit_credit_code` (S debits stock, H credits it) and `goods_movement_type` — 101 is a receipt, 102 reverses one, and a transfer such as 321 references the order without being a receipt at all. Some releases do not return `debit_credit_code`; then the movement type is the only signal.

  A reversed receipt is reported twice over: the original line carries `is_cancelled` and the reversal is its own H line. Net by one of the two, never both, or the reversal comes off twice.

  There is no amount on a receipt line: the tool returns none, and `currency` stands alone. Take the value from the purchase order.
</Warning>

A receipt booked in a different unit than the purchase order (cartons against an each item) can only be reconciled through `quantity_in_base_unit` and `base_unit`.

Pair it with `sap_read_invoiced_items` to work out the open quantity. An invoiced line names the receipt it settled in `reference_document` and `reference_document_item`, which match `material_document` and `material_document_item` here.

Dates are written out, e.g. "October 8, 2026".

## Store the result as a task variable

On by default: a successful read stores its structured result as a task variable, so the agent hands it to another tool as `${VAR_N}` instead of copying rows into the call. To keep the result inline only, bind `store_result_as_variable` to `false` on a configured tool. The binding is hidden from the agent, and any value other than `true` or `false` is rejected when saved. Set it through the API or the platform MCP's `update_configured_tool`; the configured-tool dialog keeps it when the tool is saved again.

* The variable holds the structured result as the tool returns it. A path such as `${VAR_N.material_documents}` reads one part of it and arrives as parsed data.
* A bare `${VAR_N}` reaches a python tool as JSON text; parse it with `json.loads`.
* With harness\_v2 on, the agent's history keeps the reference and a short preview instead of the whole result, and the agent can read more with `request_variables`. The task feed still shows the full result.
* An error stores nothing. Set the binding to `false` to turn this off.

## Limits and errors

* Reads to the end rather than taking a page, bounded at 50 of SAP's pages. Hitting that bound adds an **error-severity** `NN/SEARCH_TRUNCATED` message to `sap_messages`: the lines are a partial picture, so do not decide what is open from them.
* A purchase order with no receipt yet returns an empty `material_documents` list, not an error.
* One failed page fails the whole read; no partial list is returned.
* An empty `purchase_order_number` is refused, and without a bound SAP integration the call fails with "SAP integration not configured".


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.