606
PRODUCTION SUPPORTDiagnose and sustain the live P2P flow

P2P 606 · PRODUCTION SUPPORT

How do you support Procure to Pay when something goes wrong?

Restore the procurement flow while establishing where the P2P chain broke and why. Use the supplier, material, purchase order, goods receipt, invoice, accounting, and payment evidence to find the first incorrect decision—not merely the visible error.

P2P DOCUMENT CHAIN

Trace the commercial agreement, receipt evidence, and supplier claim

An invoice or payment issue can originate in the purchase order, goods receipt, supplier master, or an intended control. Follow the actual document relationship before changing a tolerance, release rule, or payment setting.

  1. 01
    RequirementNeed
  2. 02
    Purchase requisitionRequest
  3. 03
    Purchase orderAgreement
  4. 04
    Goods receiptReceipt
  5. 05
    Supplier invoiceClaim
  6. 06
    PaymentSettlement

SUPPORT OPERATING LOOP

Use the same evidence discipline for every P2P incident

01TRIAGE

Establish business impact

Identify the supplier, material, plant, PO, invoice, scope, urgency, blocked process step, and recent change. Preserve a reproducible example before opening configuration.

02TRACE

Find the failed transition

Locate the last successful P2P document or status, then the failing hand-off and observed message. An invoice block often starts in the PO or goods receipt.

03CLASSIFY

Choose the right cause family

Separate transaction data, supplier or material master data, configuration, custom logic, integration, authorization, workflow, jobs, locks, and operating procedure.

04RESOLVE

Correct the owning layer

Fix one PO, receipt, or invoice when it is exceptional; correct master data, configuration, code, or an interface only when that layer consistently caused the behavior.

05PROVE

Retest end to end

Validate quantities, prices, inventory, commitments, expense or asset posting, tax, supplier liability, payment status, and document relationships.

06PREVENT

Make recurrence visible

Capture symptom, scope, root cause, resolution, validation, and prevention. Turn recurring incidents into supplier-data validation, monitoring, tests, guidance, or controls.

FIRST P2P DECISION

Diagnose the procurement failure pattern

Start with the business issue and follow the relevant purchasing, logistics, invoice-verification, accounting, or payment determination. These are P2P operational playbooks—not generic system troubleshooting.

PO VS GR VS INVOICE

Compare what was agreed, what was received, and what the supplier claims. When they differ, establish which statement reflects business reality.

LOGISTICS VS ACCOUNTING

A goods receipt can change stock or consumption and create accounting entries. A Finance symptom may start in logistics.

CONTROL OR ERROR?

Approval, tolerance, duplicate-invoice, payment, and posting-period stops can be intended controls rather than defects.

P2P DIAGNOSTIC PLAYBOOKS

Follow the path that matches the failing business step

Each case identifies the document relationship and determination evidence to understand before correction.

01 · PO cannot be created

Trace: Supplier → material or service → purchasing organization and group → plant → source → price → account assignment. Confirm that valid procurement data exists for the transaction.

02 · PO cannot be approved

Trace: PO value and attributes → approval condition → workflow or release rule → approver → authorization → status. Check the expected route, agent, access, and any post-approval change.

03 · Goods receipt cannot be posted

Trace: PO → item → open quantity → plant and storage location → movement type → stock type → posting period → account determination. Check both logistics and accounting consequences.

04 · Supplier invoice cannot be posted

Trace: PO → goods receipt → invoice quantity and price → tax → tolerance → account posting. Classify quantity, price, receipt, tax, account, duplicate, or period issues.

05 · Invoice is blocked

Trace: PO value ↔ goods receipt quantity and value ↔ supplier invoice. Identify the failed comparison: quantity, price, delivery-cost, tolerance, or missing-receipt variance.

06 · Payment did not happen

Trace: Supplier invoice → open item → due date → payment terms and method → payment block → supplier bank data → payment run. The cause can predate the payment program.

P2P SUPPORT MOMENT

The supplier invoice cannot be posted

Do not begin with invoice configuration. Confirm the PO, goods receipt, quantity, price, tax, PO reference, and whether the issue is isolated or widespread. The invoice screen may reveal the failure while the PO or receipt contains the cause.

  • Record the known-good step and failing transition.
  • Preserve the message, statuses, master data, and expected result before changing anything.
  • Correct only the layer that owns the first incorrect decision.
USE THE FULL PATHReturn to the P2P learning path when deeper context is needed

Use 101 for process language, 202 for individual capabilities, 303 for the operating day, 404 for configuration and control design, and 505 for implementation context.

Open the P2P path