Blog

1. The CTP Paradigm: High-Fidelity Discrete Order Promising

In legacy enterprise resource planning systems, order promising relies on simple static rules or unconstrained Availability Check (Available-to-Promise/ATP) logic. ATP queries the inventory balance table, adds firmed supply receipts, subtracts firmed demand obligations, and outputs a binary yes/no or a quantity-time bucket. This mechanism fails in volatile manufacturing environments because it assumes infinite capacity, linear supply yields, and localized inventory pools.

IFS Cloud eliminates this systemic vulnerability through the Capable-to-Promise (CTP) engine. CTP functions as a real-time, high-fidelity deterministic simulation engine. When a customer order or sales quotation line requests a specific quantity and delivery date, CTP evaluates the absolute multi-dimensional constraints of the enterprise network. It does not merely look at what is available; it evaluates what can be made available within the requested temporal boundary.

Operational Definition: CTP is a multi-level, constraint-aware scheduling algorithm that synthesizes the Material Requirements Planning (MRP) bill of material explosion with the Advanced Planning and Scheduling (APS) finite resource allocation engine at the exact millisecond of order entry.

Standard Availability Check vs. IFS Cloud CTP Execution Paths

To understand why CTP must be deployed for complex environments, consider the underlying execution differences during a Sales Order save transaction:

2. Under the Hood: The Three Pillars of CTP Engine Mechanics

The CTP engine operates via three discrete, mathematically rigorous processing phases whenever a Capability Check is invoked from a sales object. Understanding these pillars prevents misconfiguration and system latency during high-volume data entry.

Pillar 1: Multi-Dimensional Constraint Evaluation

When the engine fires, it instantly maps out a dynamic matrix consisting of physical inventory, firmed purchase orders, in-transit transfer orders, current shop order allocations, and machine/labor capacity records. The engine uses a backward-scheduling heuristic by default. It begins at the user’s requested delivery date, moves backward through the transport lead time, and identifies the target completion date for the manufacturing cycle.

If backward scheduling reveals a constraint violation—for instance, a machine load exceeds 100% on day three of the sequence, or a critical chemical component has an unalterable 14-day vendor lead time—the engine stops backward execution. It flips instantly to a forward-scheduling pass from the earliest point of constraint clearance, projecting the mathematically true earliest possible delivery date.

Pillar 2: Multilevel and Multi-Site Structures

Products are rarely flat. A custom pump assembly contains an impeller sub-assembly, which contains machined castings, which require raw stainless-steel bar stock. Standard ATP checks fail here because they assume the impeller is on the shelf. The IFS Cloud CTP engine explodes down through every branch of the active Engineering or Manufacturing Structure revision.

If the part configuration dictates multi-site sourcing (e.g., the casting occurs at Site A in Poland, but final assembly occurs at Site B in Germany), the CTP engine executes a cross-site database pipeline. It calculates the Inter-Site Material Transfer Lead Time, queries the production capacity of Site A, hooks into the calendar constraints of both locations, and builds a unified delivery timeline across company boundaries.

P Pillar 3: The Interim Order Architecture

To prevent the "phantom promise" problem—where two sales reps concurrently promise the exact same machine slot to two different customers—IFS Cloud uses the Interim Order mechanism. When a Capability Check is executed and found valid, the system creates an interim reservation layer. This layer writes lightweight, high-speed tracking records directly to the database:

• INTERIM_ORDER_HEAD: Holds the unique session identifier tied to the specific Customer Order Line or Sales Quotation Line.
• INTERIM_ORDER_LINE: Maps directly to the required material components and structural routing stages.
• INTERIM_ORDER_OPERATION: Places a temporary, firmed block on the specified Work Center Resource capacity grid, effectively hoarding that slot until the customer order is firmed or the quotation session expires.

3. Complete Master Configuration Protocol

To enable CTP functionality within an IFS Cloud site, the master data must be structurally configured to shift from static inventory counting to dynamic promise planning. Skip no steps in this sequence; any missing flag will cause the system to default silently back to a standard unconstrained inventory check.

Step 3.1: Inventory Part Manufacturing Parameters

Navigate to the Inventory Part page. Query your target component or parent part. Open the Manufacturing sub-tab. Locate the fields governing order promising and planning behaviors. Execute the following configuration changes:

Ensure that the **Planning Method** under the Acquisition properties is set to a method compatible with discrete tracking (such as A, B, or M). Methods designed for kanban or point-of-use consumption (like Planning Method H or I) will cause structural validation errors during the CTP explosion because they decouple direct demand-to-supply parent-child linking.

Step 3.2: Routing and Work Center Optimization

Navigate to the Work Center screen for every critical execution node in your facility. Under the Capacity properties, verify that your efficiency and utilization factors are precisely calibrated. If your machine runs at 90% real-world output due to calibration drift or setup overhead, set the **Efficiency Factor** to 0.90. Leaving this value at the speculative ideal of 1.00 will force the CTP engine to over-promise delivery dates based on machine rates your shop floor cannot physically achieve.

Next, open the Routing Revision and Alternative page for the parent part. Ensure that your operations are linked to these work centers with verified **Setup Time** and **Factor/Run Time** constants. Toggle the **Resource Capacity Check** option to Finite Capacity on your bottleneck work centers to force CTP to respect hard scheduling thresholds.

Step 3.3: Site-Level Execution Control Flags

Navigate to Site / Manufacturing Information. Under the general rules matrix, ensure the checkbox for **Use Interim Orders for CTP** is explicitly marked TRUE. This enables the database persistence layer to write capacity allocations on a draft Sales Quotation before it hard-converts into a real Shop Order.

4. Advanced Operational Scenarios: Step-by-Step Execution Workflows

The implementation architecture of CTP alters fundamentally depending on your commercial delivery strategy. Below are the three primary production workflows deployed by enterprise-scale IFS Cloud architectures.

Scenario A: Pure Make-To-Order (MTO) Engineering Pipelines

In a strict MTO ecosystem, parts are pre-defined structurally via bills of material, but zero component or parent safety stock is held in warehouse locations. Supply chains run strictly just-in-time based on actual demand signals.

The Operational Execution Workflow:

1. The inside sales engineer opens the Customer Order window and initiates a new record for a client requesting 15 units of heavy industrial winch assemblies (Part ID: W-400-DISC).
2. The user adds a line item, specifying the delivery target as exactly 21 calendar days from today. Stock on hand is checked automatically by the framework; it returns a balance of zero.
3. The user clicks the **Capability Check** command link on the command bar. The system initializes a background transaction isolation thread.
4. The engine reads the active revision of MANUF_STRUCTURE for W-400-DISC. It calculates that raw material steel plates are available, but a specialized hydraulic motor component has an external supplier lead time of 10 days.
5. The engine simultaneously checks the **Finite Capacity** matrix for Work Center 302 (Machining and Welding). It identifies that the center is currently booked to 98% utilization by pre-existing firmed shop orders for the next 12 days.
6. CTP performs its backward pass, identifies a resource overlap collision between days 3 and 8, stops, and invokes the forward-scheduling loop. It calculates: 10 days for motor arrival + 4 days for machining queue availability + 3 days for final assembly and testing + 2 days for transport packaging. Total required time: 19 days.
7. The system drops a validation dialog to the sales rep: "Requested date cannot be met. Earliest valid promise date is T+19 days."
8. The user accepts the calculated compromise date. The system automatically populates the **Planned Delivery Date** with the calculated constraint value and creates an active INTERIM_ORDER_HEAD token, locking those capacity segments against other users.

Scenario B: Dynamically Configured Parts via Product Variant Matrix

Configured components leverage the IFS Product Configurator module. These components do not possess a fixed, static Bill of Material or a immutable Routing sheet. Instead, the structure and the runtime labor paths are dynamically generated on-the-fly based on characteristic responses selected by the customer during sales qualification.

The Operational Execution Workflow:

1. The operator opens a Sales Quotation line for a commercial HVAC unit. The part number is flagged as a configurable template part.
2. The operator clicks **Configure Part**, stepping through the rule evaluation options: choosing a 50kW compressor package, corrosion-resistant copper coils, and an integrated digital telemetry module.
3. Upon confirmation of the configuration characteristics, IFS Cloud dynamically constructs a temporary transactional structure tree and an associated operation routing array inside the session memory cache.
4. The operator executes the **Capability Check** on the quotation line.
5. The CTP engine intercepts this temporary configuration matrix. Rather than pulling from static tables, it reads the custom assembly requirements from the configuration output cache. It detects that the 50kW compressor alternative demands an additional 2.5 hours of specialized vacuum testing at Work Center 509 (Quality Lab).
6. The engine evaluates the live availability log of the testing bay. It discovers that a high-volume preventative maintenance shutdown is scheduled for that testing bay precisely during the assembly window.
7. CTP extends the calculated production timeline by exactly 48 hours to account for the maintenance down-time window and provides an exact, risk-adjusted promise date. The user saves the quotation, and the custom parameters are written to the database under an interim configuration profile, securing the testing time slot.

Scenario C: Inter-Site Supply Chains & Multi-Company Distribution

In highly distributed global manufacturing topologies, final customer delivery happens at a local distribution node (Site Sales), but production occurs across multiple distinct manufacturing facilities (Site Machining, Site Assembly) located in different regions or under separate legal entities.

The Operational Execution Workflow:

1. A customer order is registered at the North American Sales office (Site US_SALES) for an order of custom transmission gears.
2. The regional site does not manufacture these gears; its supply network matrix points to an internal manufacturing source in Sweden (Site SE_GEAR).
3. The sales representative runs the **Capability Check** at the US_SALES order line.
4. The CTP algorithm initiates a distributed multi-site calculation sequence. First, it identifies the **Inter-Site Material Transfer Lead Time** rule template between Sweden and the United States (configured for 7 days ocean freight + 2 days customs clearance).
5. The engine jumps across site contexts and evaluates SE_GEAR. It explores the local manufacturing structure and looks at the capacity limitations of the cutting and heat-treating furnaces in Sweden.
6. It discovers that the heat-treating furnace is booked out for the next 5 days.
7. The multi-site algorithm aggregates the distinct operational delays: 5 days furnace backlog + 2 days run time + 9 days global freight pipeline = 16 total execution days.
8. The promise timeline is returned to the user at US_SALES, displaying a rock-solid, fully integrated cross-border commitment date. When confirmed, the system generates linked internal Purchase/Customer Order patterns across both site structures alongside an interim manufacturing footprint in the Swedish plant database.

5. Exploiting the System: Non-Obvious & Advanced Implementations of CTP

Beyond traditional order verification, the architectural layout of the IFS Cloud CTP engine allows it to be leveraged for creative operational advantages across complex macro-industrial execution structures.

5.1 Strategic Capacity Hoarding for Enterprise Account Preservation

During competitive deal cycles with enterprise-tier tier-1 accounts, inside sales teams frequently find themselves trapped in multi-week negotiation standstills. While contracts are routed through legal checkpoints, smaller, low-margin transactional orders coming in from web portals or EDI links can steadily consume your finite production capacities. This leaves your plant unable to satisfy the major account’s delivery targets once the contract is signed.

To hedge against this risk, execute a Capability Check on a dummy **Sales Quotation Line** matching the estimated volume of the pending enterprise contract. Ensure the system parameter for *Save Interim Orders* is active. This action writes temporary, firmed records directly into your work center capacity pools.

5.2 Proactive Procurement Hedging Against Volatile Material Constraints

When the CTP engine executes a Capability Check across a deep, promise-planned BOM, it flags the exact raw material components that trigger a forward-scheduling shift due to lead-time delays. This asset can be reversed for predictive inventory management.

By regularly running batch capability simulations via data migration or script schedules against speculative master schedules, you can identify precisely which raw material sub-components will break your lead-time commitments if demand ticks up by a specific percentage. This allows your procurement officers to issue targeted forward supply contracts or execute strategic buffer buys on raw commodities long before standard MRP systems register a critical material shortage alarm.

5.3 Dynamic Load Balancing Across Twin Production Facilities

For operations running parallel manufacturing sites with identical or overlapping structural capabilities, CTP serves as an automated distributed logistics broker. By setting up your inventory items as multi-site routed components with alternative supply options mapped directly inside your distribution matrices, a capacity check can be run across multiple locations.

If Site A returns an unacceptable forward-scheduled promise date due to machine maintenance or labor constraints, the calculation loop can immediately run an alternative site trace against Site B. If Site B can fulfill the manufacturing requirements quicker—even when factoring in any additional inter-site logistics transport overhead—the sales agent can re-route the internal fulfillment logic on the spot, achieving live load balancing across separate facilities based entirely on temporal constraint matching.

6. Strategic Value Metrics and Business Process Integration

Implementing Capable-to-Promise is not simply a system configuration project; it is an overarching business transformation that changes how an enterprise handles customer fulfillment. Moving to an automated, high-fidelity constraint check impacts multiple business domains:

• Sales Operations: Eliminates the guesswork and manual spreadsheets historically used by sales teams to estimate delivery times. This reduces quoting time, boosts win rates on time-sensitive bids, and protects margins by preventing over-commitments that lead to rush expediting fees.
• Production Control: Protects the shop floor from erratic disruptions caused by unrealistic delivery promises. Because CTP respects finite capacity limits, the manufacturing schedule remains stable, reducing setup overhead and optimizing asset utilization.
• Procurement Management: Provides visibility into raw material constraints early in the sales cycle. Purchasing teams can shift focus from reactionary fire-fighting to strategic vendor management, leveraging the early warning signals generated by the CTP engine's interim structures.

7. Execution Verification Script (High-Speed DB Pipeline Check)

To verify that your CTP transaction layers, interim tables, and state flags are executing with correct database-level validation, run the following PL/SQL validation block within your test console. This block executes an explicit state check, ensuring your master data changes are active and that no null values are present on critical columns.

DECLARE
    v_part_no      VARCHAR2(25) := 'W-400-DISC';
    v_contract     VARCHAR2(5)  := 'SE10';
    v_prom_planned VARCHAR2(20);
    v_interim_cnt  NUMBER;
BEGIN
    -- 1. Verify Inventory Part Order Promising configuration state
    SELECT order_promising_type
      INTO v_prom_planned
      FROM inventory_part_tab
     WHERE part_no = v_part_no 
       AND contract = v_contract;
       
    IF v_prom_planned != 'PROMISE_PLANNED' THEN
        RAISE_APPLICATION_ERROR(-20001, 'Critical Configuration Failure: Part is not Promise Planned.');
    END IF;
    
    -- 2. Verify that the Interim Order Persistence Layer tables are structurally sound
    SELECT COUNT(*)
      INTO v_interim_cnt
      FROM interim_order_head_tab
     WHERE rownum <= 5;
     
    Dbms_Output.Put_Line('CTP Validation Succeeded. Target Part Status: ' || v_prom_planned);
EXCEPTION
    WHEN NO_DATA_FOUND THEN
        Dbms_Output.Put_Line('Master Data missing for verified combination: ' || v_part_no || ' @ ' || v_contract);
    WHEN OTHERS THEN
        Dbms_Output.Put_Line('Structural system validation fault: ' || SQLERRM);
END;
/