PO auto-generation from requisition

Generate the PO only after the requisition carries an approval stamp. Speed is the retyping you remove after that stamp, not the approval you skip. Create the order from two sources that already exist: the approved requisition, and the executed contract those lines buy against.

A parsed Slack line is a draft card. free-text request parsing fills fields for the requester to confirm. It does not authorize spend, and it does not create a PO. If generation fires on that card, you posted an order that never saw doa compliance enforcement. The failure is an unapproved parse becoming a live PO number. The supplier sees it, and the control story is already broken.

Buying suites in this class, including SAP Ariba, Coupa, Oracle, and Jaggaer, already convert approved requisitions into purchase orders when the request sits in the same system as the catalog or contract. Use that create-PO path. Numbering, tax, receiving, and invoice matching stay on the purchasing document those suites already post. A side process that writes a PO into the ERP while bypassing the suite's document is a second source of truth, not faster buying.

If the requisition is still draft, rejected, or waiting on an approver, generation does not run. If there is no executed contract, or no catalog punchout that is the contract, generation does not run. A buyer typing a local vendor "to get the order out" is not this process.

After the approval stamp is on the requisition, copy requisition fields and overlay contract price, Incoterm, and payment terms. Do not ask the buyer to re-key either set.

From the approved requisition, take:

• Supplier ID as stored on the req, not a similar vendor a matcher prefers
• Item, quantity, and unit of measure
• Ship-to, plant, and storage location
• Company code and purchasing organization
• Account assignment: cost center, GL, internal order, or WBS
• Need-by date and requester

From the executed contract, take the terms the requisition often does not carry: unit price and currency for that item, including the tier that matches this quantity; Incoterm and named place; payment terms; validity dates, so you do not stamp a price from an expired schedule.

contract terms auto-applied to PO is the overlay. Generation consumes it. It does not re-read a PDF and guess. If the contract is silent on Incoterm or payment, leave the PO field blank or on the vendor-master default your policy already named, and queue it. Do not invent DAP or Net 30 because that is what you usually do.

Company code is a mapping, not a default from the buyer's login. A buyer who works across two entities will otherwise post Plant 4's filters to the shared-services company code they used this morning. Wrong company code is a goods-receipt failure, an intercompany cleanup, and a PO the plant cannot receive. If company code, purchasing org, or plant on the req do not form a valid combination in the ERP, hold. Do not pick the nearest valid set.

Price mapping misses are holds, not guesses. If the requisition unit price, the catalog price, and the contract schedule disagree, or the UOM on the req is case while the contract is box, do not transmit the lower number to be helpful. Flag the miss, show the three values, and wait for the buyer.

The walk-through is illustrative, not a measured result.

A plant facilities coordinator at Plant 4 has an approved requisition: 40 boxes of 20x20x2 MERV-13 HVAC filters, contracted MRO punchout supplier V-8841, $420, cost center FAC-4, ship-to Plant 4 receiving dock, need-by next Tuesday. The requisition sits on company code 1000 (US manufacturing) and plant 1200. low-risk auto-approval stamped it because it was in-catalog, in-band, and in-DoA. The frame agreement for V-8841, still in date, lists $10.50 per box at this quantity, Incoterm DAP Plant 4, payment Net 45.

Generation maps those fields onto a PO in the buying suite: supplier V-8841, 40 boxes, $10.50, DAP Plant 4, Net 45, company code 1000, plant 1200, account assignment FAC-4, ship-to the dock on the req. Anomaly detection compares quantity, price, and supplier to the contract and to recent MRO patterns. The row is ordinary. The buyer is not asked to retype. Transmit goes to the supplier on the suite's usual channel.

Change one fact and the same flow must stop.

The coordinator's Slack line was parsed into a tidy card on Friday afternoon, and nobody confirmed category, budget, or urgency. Generation must not create a PO from that parse. There is no approval stamp. Queue it as a draft requisition, not as an order.

The mapper used the buyer's default company code 2000, the shared-services entity they posted a laptop against yesterday, instead of 1000 from the requisition. Plant 1200 does not receive for 2000. Hold. Show both company codes. Do not transmit and fix it at goods receipt.

The contract schedule has a stale header list price of $12.00 and a valid line price of $10.50. The requisition copied $12.00 from an old catalog cache. That is a mapped-price miss. Flag it. The buyer confirms $10.50 against the live schedule, or they reject the line. Transmitting $12.00, or transmitting $10.50 without that confirm, is how you either overpay or ship a price the supplier will dispute.

After the PO is built and before it leaves the company, run po anomaly detection. Quantity far from the contract or from recent receipts, a supplier that is not the contracted ID, a price off the schedule: those are holds for a buyer, not auto-cancels and not silent corrections.

A mapped-price miss is a specific hold. The buyer sees the requisition price, the contract schedule price, and the UOM on each. They confirm which price and UOM belong on the PO, or they send the line back. Generation does not pick. Transmit does not run until that confirm is recorded on the PO.

Do not retry a failed post by dropping required fields. If the ERP rejects the PO for a locked vendor, a missing tax code, or an invalid company-code and plant pair, park the document with the rejection text. A retry that blanks company code to make it post is the wrong-company-code failure in another form.

Transmission is a separate step from creation. Creating the PO in the suite so numbering and downstream matching can see it is useful. Sending it to the supplier while a price miss or a company-code mismatch is still open is not.

Turn this on first where the requisition and the contract already live in the same buying record: punchout or catalog lines against an executed frame agreement, one company code, one plant, one UOM. SAP Ariba, Coupa, Oracle, and Jaggaer all host that conversion. Configure it there. Do not stand up a parallel process that posts POs the suite never numbered.

Park complex services, statement-of-work lines, and free-text local vendors until a buyer has built the PO once. Those lines still need human judgment on description, milestones, and whether the contract even applies. Auto-generation multiplies whatever was wrong on the requisition.

Before you widen beyond one catalog category, replay a sample of recently approved requisitions into a PO that nobody transmits. Compare field by field: supplier ID, quantity, UOM, unit price, Incoterm, payment terms, company code, plant, account assignment, ship-to. A wrong company code or an unconfirmed price miss is a fail even if the PO looks complete. Name who owns each hold: buyer for price and UOM misses, master data for company-code and plant combinations, intake if the requisition was never approved.

Success is a PO the buyer did not retype, posted in the right entity, at the contract price the buyer confirmed when the map was messy, and transmitted only after the anomaly check was clean. It is not a PO that appeared from a chat draft.