Blog

The Core Concept: Handling Unit Driven Logic

At the heart of this strategy lies the Handling Unit (HU). In IFS Cloud, an HU represents a physical container—a pallet, a box, or a cage—that holds inventory. The efficiency of your picking process is directly correlated to how well you manage these units.

The One and Two Step concept is particularly useful when your warehouse layout includes bulk zones (often high-bay storage) and picking zones (floor-level or flow racks). Operating on complete top-level handling units in bulk zones is far more efficient than picking single units from them. The system categorizes these operations into three distinct scenarios:

Deep Dive: One Step Picking

One Step Picking is the epitome of lean warehousing. It is designed to minimize touches. If you have a pallet of goods and a customer wants a pallet of goods, you shouldn't touch the goods inside—you simply move the pallet.

How to Configure It

To enable this, the reservation logic in IFS must be prioritized to look for full top-level handling units first. This involves configuring the Automatic Reservation priorities on the Site or Part level. By prioritizing "Largest Quantity on Handling Unit" and "Outermost Handling Unit," the system will naturally attempt to lock onto full pallets.

Execution Flow

Once the reservation is locked onto a full HU, the execution is straightforward. You navigate to the Create Consolidated Pick List for Customer Orders or Create Consolidated Pick List for Shipment job.

Pro Tip: When running the pick list creation job, select the filter option "Only Handling Units to be Picked in One Step". This is crucial. It filters out any partial demands and generates pick lists specifically for your forklift drivers who move full pallets.

The result is a streamlined pick list that directs the operator to Location X, to pick Handling Unit Y, and deposit it directly at the Dock or Staging Lane. No counting, no unpacking.

Deep Dive: Two Step Picking

Two Step Picking acts as a bridge between your bulk storage and your detailed picking operations. It facilitates the picking of reservations that constitute only a part of a handling unit, or when a unit is "contested" by multiple orders.

Step 1: The Move (Replenishment logic)

The first step is purely logistical: moving the inventory from a "hard to pick" location to an "easy to pick" location. This could be moving a pallet from level 5 of a rack down to a floor location, or moving it from a bulk warehouse to a forward picking zone.

This is achieved by running specific batch programs:

• Move Customer Order Reservations with Transport Task
• Move Shipment Reservations with Transport Task

These jobs are powerful. They allow the warehouse manager to define criteria: "Move all partial reservations from Bulk Zone A to Picking Zone B." When executed, the system generates Transport Tasks. These tasks instruct the forklift drivers to bring the stock down.

Step 2: The Pick

Once the Transport Task is executed (or even while it is active, if configuration allows), the inventory is now virtually or physically in a pickable location. You then run the standard Create Consolidated Pick List job. This generates the actual picking document for the picker to take the specific quantity needed for the order.

Strategic Configuration: Bulk Zones vs. Picking Areas

Implementing One and Two Step picking requires a deliberate warehouse layout strategy within IFS Cloud. The system needs to know which locations are "Bulk" and which are "Picking."

1. Defining Storage Zones

Navigate to the Storage Zone window. Create at least two zones:

• BULK: High capacity, high racking, intended for full pallet storage.
• PICK: Floor level, flow racking, or shelving intended for breaking bulk.

2. Automatic Reservation Priorities

This is where the magic happens. On the Site / Inventory / Automatic Reservation tab, you must align the priorities to favor the logic of stripping the bulk area of full pallets first, and using the pick area for loose units.

Recommended Setup:

• Priority 1: Highest Putaway Zone Ranking (This forces the system to look at zone preference first).
• Priority 2: Largest Quantity on Handling Unit (This ensures we grab the biggest available unit first—a full pallet).
• Priority 3: Outermost Handling Unit (Ensures we take the parent pallet, not a box inside the pallet).

3. Putaway Zone Basic Data & Ranking

The final piece of the puzzle connects the Zones to the Priorities. In Putaway Zone Basic Data, you define the ranking logic.

• For the BULK Zone: Set the ranking to prioritize Full Handling Units. Give it a high rank (low number) for full pallets.
• For the PICK Zone: Set the ranking to prioritize Less than Full Handling Units. Give it a high rank for loose picks.

The Result: When an order comes in for 100 units (a full pallet), the logic sees that BULK has a higher rank for full pallets and directs the reservation there (One Step). When an order comes in for 10 units, the logic sees that PICK has a higher rank for partials and directs the reservation there. If no stock exists in PICK, the Two Step logic kicks in to move stock from BULK to PICK.

Benefits for the Enterprise

Why invest the time to configure this?

1. Labor Efficiency: Forklift drivers stay on forklifts; pickers stay on the floor. Specialized labor is used for its intended purpose.
2. Safety: Reduces the need to pick loose items from high levels, minimizing the risk of falling objects or injury.
3. Inventory Accuracy: By managing full HUs, you reduce the instances of miscounting loose items in deep reserve locations.
4. Scalability: As order volume grows, this logic scales automatically without needing manual intervention from warehouse supervisors.

Deep Dive: CTO in IFS Cloud Purchasing

The Configure-to-Order (CTO) functionality within IFS Cloud’s Purchasing module is not a standalone feature; it is the critical execution arm of a unified supply chain strategy. Its primary development focus is to support the purchase of configured products throughout the Internal Order Flow and external procurement.

When we talk about "configured parts" in IFS, we are referring to parts linked to a Configuration Specification. In a standard flow, this configuration travels seamlessly through the message handling system between sites (for multi-site implementations) and appears on external purchase order documents (PDFs) or digital messages (EDI).

Handling Configured Parts within Procurement

In the IFS Cloud ecosystem, a configured part in procurement never exists in a vacuum. It is always the child of a demand source. Understanding the origin of this demand is crucial for troubleshooting and process optimization.

The creation of a purchase line for a configured part typically stems from:

• Sales Quotations: Early-stage estimation where vendor quotes are needed for bespoke items.
• Customer Orders (CO): The most common trigger, creating direct demand.
• Dynamic Order Processing (DOP): Complex, multi-level pegged orders used in Project manufacturing or complex A&D environments.
• Material Requisitions: Internal consumption needs.

Visibility vs. Editability

Regardless of the origin, traceability is key. When a user navigates to a Purchase Requisition Line, Purchase Order Line, or Request for Order Quotation Line, the system flags the part as configured. By selecting the line and accessing View Configuration, procurement officers can see the exact characteristic values (e.g., Color: Red, Voltage: 220V, Material: Steel) that generated that specific part number revision.

"The inability to change the configuration on the PO is a safety mechanism. If a supplier states they cannot provide 'Red', the change must be driven from the Customer Order or DOP Header to ensure the Sales team and the End Customer agree to the deviation." — Senior IFS Solution Architect

Demand Inheritance and Order Conversion

The lifecycle of the configuration data is persistent. When a demand originates from a Customer Order (OE) or a DOP Order, it carries a unique Configuration_ID.

When a Purchase Requisition is converted into a Purchase Order or a Request for Order Quotation, the system does not "copy" the data; it inherits the reference. This ensures that if the configuration is updated at the source (before the PO is released), the purchasing documents reflect the latest reality.

The Role of Supply Codes

The automation of this process is governed heavily by the Supply Code defined on the Customer Order Line or the Sales Part. This is a critical setup step during the implementation phase:

Operational Constraints: Deletion and Copying

While automation is robust, manual intervention has rules. You can delete lines with configured parts on a Purchase Order. However, IFS Cloud will issue a warning. This is because deleting the supply (PO) leaves the demand (CO or DOP) unfulfilled ("orphaned demand"). The best practice is to manage cancellations from the demand source downwards.

Furthermore, copying a Purchase Order for a configured part is restricted. Since a configuration is unique to a specific demand instance (a specific customer's requirements), copying a PO would create supply without a linked demand, breaking the CTO logic. The only exception is creating a replacement order derived from a DOP structure, where the system understands the pegging relationship.

Subcontracting and Consignment Limitations

For organizations utilizing outside processing (subcontracting), the CTO flow encounters specific architectural boundaries in IFS Cloud.

Subcontracted work in purchasing is not modified to handle configured parts in the standard core. The technical reason lies within the DOP (Dynamic Order Processing) logic. DOP supports functionality strictly for "Charge" or "No Charge" regarding supplier material shipping. It does not natively support the complexity of passing variable configuration characteristics to a subcontractor via the standard purchasing flow in the same way it does for internal manufacturing.

Similarly, Consignment Stock for configured parts is not a supported combination. Configured parts are, by definition, unique or distinct. Consignment stock relies on standard, interchangeable inventory. Mixing these concepts creates valuation and tracking paradoxes that the system prevents to maintain financial integrity.

MHS and EDI: Digitalizing the Configured Supply Chain

In modern Industry 4.0 implementations, PDF purchase orders are being replaced by EDI (Electronic Data Interchange) and MHS (Message Handling System). IFS Cloud supports this robustly for CTO.

Outgoing Messages (ORDERS / ORDCHG)

When sending a Purchase Order (message type `ORDERS`) or a Change Order (`ORDCHG`), the configuration information—specifically the Characteristic Codes and their Values—is embedded in the XML/EDI message. This allows the supplier's ERP system to automatically read the specifications without human data entry.

Consultant Tip: Not all suppliers are capable of parsing configuration data. If a supplier treats your "Configured Part X" as a standard "Part X" (perhaps they only make one variant for you), sending the configuration data might cause their EDI import to fail. You can disable this via the Transfer Configuration Characteristics toggle in the Supplier for Purchase Part / General tab.

The Pricing Paradox in Internal Flows

A nuanced behavior occurs in Inter-site trade (Internal Order Flow). The outgoing message from the Purchasing Site includes both the Price and the Description. However, when the Manufacturing Site (Seller) receives this message, it ignores the incoming price.

Why? Because the Manufacturing Site calculates its price based on its own Customer Order pricing logic (which might involve cost-plus logic based on the configuration). This prevents the Purchasing Site from dictating the transfer price incorrectly. However, if your business rules dictate that the PO price should override the CO price, you can utilize the Send Order Price flag on the Supplier/Part setup.

The Mandatory Order Response (ORDRSP)

One of the most frequent support tickets we see relates to the "Arrival" step for configured parts. In IFS Cloud, if you buy configured parts via MHS/EDI, the use of Order Response (ORDRSP) is mandatory.

The system performs a hard validation during the Register Arrival step. It checks if an Order Response has been received. If not, the user is blocked (or warned, depending on strictness settings).

The Logic Behind the Restriction:

1. A Purchase Order for a configured part is often created with a Price of 0 (zero) initially, because the final price depends on the supplier's evaluation of the configuration.
2. The Supplier receives the order, calculates the cost of the specific configuration, and sends back an ORDRSP with the correct, confirmed price.
3. IFS updates the PO Line with this confirmed price.
4. Only then is the system ready to receive the goods at the correct inventory valuation.

This check is ubiquitous—it triggers during Dispatch Advice reception and Direct Delivery registration as well.

Receipt and Inventory Management

Once the goods hit the dock, the complexity doesn't end. In the Receipt process, warehouse staff can view the configuration to verify the physical goods against the specs (e.g., "Does this motor actually have the Red casing requested?").

Upon entering inventory, the configured part maintains its link to the configuration ID. This is visible in the Inventory Part Unit Cost page. This is vital for tracking actual costs versus estimated costs for specific projects.

Configuration of the Print Output

Not all configuration characteristics are relevant for the supplier. You might have internal characteristics (like "Sales Margin Category") that the supplier doesn't need to see. IFS Cloud offers granular control over document outputs.

• Global Control: Use the Configuration Characteristic page to flag specific characteristics as "Print on Order" or "Print on Return."
• Supplier Specific Control: In Supplier for Purchase Part, you can suppress the entire configuration printout for specific vendors who don't need that level of detail.