Two requisition lines go in. One purchase order line comes out, with the quantities added together. Most of the time that is exactly right, and nobody thinks about it. Then one day a buyer expects a single clean schedule and gets two instead, or expects two separate lines and the system fuses them into one. Suddenly the automation looks broken. It is not broken. It is doing precisely what it was told, following grouping rules most people never actually learned. This is the part of requisition to purchase order that quietly decides the shape of every automated PO, and understanding it is what separates a buyer who fights the system from one who drives it.

The name, and what it means in Fusion

Longtime Oracle people call this Autocreate, from the classic Purchasing window that turned requisition lines into purchase orders. The name stuck, so people still search for it. In Fusion Cloud the same job lives in a different place. Approved requisition lines flow into the Process Requisitions page, get pulled into the Document Builder, and become a purchase order. For backing requisitions, the automated process does it without a buyer touching anything at all.

Different screens, same core question underneath. When several requisition lines become a purchase order, how do they collapse together? That question has a definite answer, and the answer is a set of rules, not a mystery.

The rule that decides PO lines

Here is the first layer. When requisition lines are eligible to become a purchase order, the application tries to combine them into a single purchase order line when they share the same key attributes. Same item. Same category. Same unit of measure. The same core details that make two lines genuinely the same thing being bought.

Share those attributes and two requisition lines become one PO line with the quantities summed. That is the behavior people see when their two lines quietly merge into one. It is not a glitch. The lines matched, so the system did what matching means.

The flip side matters just as much. Change one of those key attributes and the lines refuse to merge. Different item, different category, and they stay separate on the order. So when a buyer swears two lines "should" have combined and they did not, the answer is almost always a mismatch in one of the grouping attributes hiding in plain sight.

The second layer nobody remembers: schedules

This is where the earlier surprise comes from, the one clean PO line that somehow carries two schedules. Grouping happens twice, not once.

First the application decides PO lines. Then, for the lines it has grouped into a single purchase order line, it looks again and splits them into schedules based on a different, tighter set of attributes. Lines land on the same schedule only when they share the same need by date, the same ship to location, and the same ship to organization.

Read that carefully, because it explains the whole puzzle. Two requisition lines can share the same item and category, so they merge into one PO line. But if their need by dates differ, or they ship to different locations, they split into two schedules under that single line. One line, two schedules. Perfectly logical once the two layers are visible, and baffling until they are.

So the mental model is a funnel with two filters. The first filter, wide, sets the PO lines by item and category. The second filter, narrow, sets the schedules by date and ship to. A line passes the first and can still be divided by the second.

Default versus Requisition grouping

There is a setting that changes the whole character of the output. The grouping method.

Default grouping combines requisition lines into consolidated PO lines based on document type. This is the efficiency play. Ten requisitions for the same item across the company collapse into tidy, merged lines, and the supplier gets one clean order instead of ten fragments.

Requisition grouping does the opposite. It builds a purchase order that mirrors the structure of the requisition it came from, line for line. No consolidation across requisitions. This is what a business wants when traceability matters more than tidiness, when each requisition needs to stay visible and distinct on its own order.

Neither is correct in the abstract. Consolidation saves the supplier from noise. Mirroring preserves a clean audit trail. The right pick depends entirely on what the business values, and choosing it deliberately is the whole point.

When automation gets it wrong, take the wheel

Sometimes the rules produce a grouping the buyer does not want. The system would merge two lines that a business reason says must stay apart. The automation is not the final word here, and this is the part people miss most.

Inside the Document Builder, a buyer can edit the document before creating it and control the grouping by hand. The order line column becomes editable, and entering order line numbers forces lines onto separate order lines even when the rules would have fused them. Left alone, the application groups by its predefined logic. Edited, the buyer overrides that logic line by line. Automatic behavior with a manual escape hatch, which is exactly what a good buyer reaches for when a specific order needs a specific shape.

The through line

Every automated purchase order that comes out of a requisition got its shape from these rules. Item and category decide the lines. Need by date and ship to decide the schedules. The grouping method decides whether the order consolidates or mirrors. And the Document Builder decides who has the final say, the rules or the buyer.

None of it is random. When an automated PO comes out looking strange, it is not the system misbehaving. It is the system revealing a grouping attribute that did not match, or a schedule split hiding under a merged line. Learn the two layers and the automation stops being a black box. It becomes a tool with a steering wheel.