PLFL table — Task List Sequence Relationships Table

Each row in PLFL represents one recorded relationship between a node in the standard sequence of a routing and a node in an alternative or parallel sequence attached to the same task list. Routings can have more than one sequence: the standard sequence that covers the normal flow, and alternative or parallel sequences that branch out at a given operation and either merge back or run independently to the end. PLFL is where that branching topology is persisted, keyed by task list type and group. A routing that never uses alternative or parallel sequences has no rows in this table, because there is nothing to branch. It is populated automatically when a sequence is created or changed in routing maintenance, not something a functional consultant edits by hand.

MANDT is the client restriction as always. PLNTY and PLNNR together are the real selectivity in this table; without both, a scan touches every sequence relationship across every routing type in the client. The table itself is small relative to PLPO because it only holds branching relationships, so a full scan is less dangerous than on operation-level tables, but it is still not a table to browse without a task list key in hand. If engineering change management is active on the routing, multiple valid records for the same node pair can exist across different change numbers or validity dates, so a lookup that ignores the change number can return more rows than expected and mislead about what is currently effective.

Symptom: an order or a routing display shows an operation sequence that does not match what production expects, or a parallel sequence does not appear to trigger. Select PLFL restricted to the routing's PLNTY and PLNNR to list every recorded branch and merge node. Take the PLNKN values returned and look them up in PLPO for the same PLNTY and PLNNR to see which operation numbers and control keys sit at those nodes, then confirm the sequence category matches what the process planner intended.

PLFL is retained in S/4HANA in its classic form. The routing and task list data model has not been restructured in the way order execution tables have, so the table continues to be maintained by the same routing maintenance transactions and read by the same standard logic. No compatibility CDS view is commonly used as a substitute for direct access to this table in typical project work.

Questions about what PLFL actually contains for a given routing belong to whoever owns process engineering or routing master data on the project, usually the PP or manufacturing engineering consultant maintaining routings through the standard maintenance transactions. Order execution teams should confirm the routing structure with that owner before assuming a sequence problem observed on an order is a program defect.

PLKO is the task list header PLFL points back to. PLPO holds the operation detail for every node PLFL references. PLAS assigns the task list group to a plant and counter, and MAPL links that assignment to material numbers, which is how a functional user finds which materials are affected by a given sequence structure. Routing maintenance transactions write and change PLFL whenever a sequence is added, altered, or removed.