frePPLev2.0
open source Production PLanning
  • Home
  • Documentation
    • Getting started
    • Modeling guide
    • User guide
    • Installation guide
    • Developer guide
    • FAQ
  • C++ API

Planning algorithm

The algorithm solves demand per demand. The demand is thus sorted in descending order of priority, and next these demands are planned one after the other.

When planning a single demand, the algorithm basically consists of a set of recursive functions structured in a ask-reply pattern, as illustrated in the example below. The indention is such that the ask and its matching reply are represented at the same level.

Every demand has a certain delivery operation associated with it ,either directly or indirectly by specifying a delivery operation for the requested item. The demand asks this operation for the requested quantity on the due date of the demand.

(*) The operation first checks for the lead time constraints.
The operation will ask each of the loads to verify the capacity availability.
The operation will ask each of the flows to check the availability of consumed materials.

A load passes on the question and asks the resource.

The resource reply indicates whether the capacity is available or not.
The load uses the resource reply to reply to the operation.
A flow passes on the question too and asks the buffer.

The buffer checks the inventory situation.
If material is available no further recursion is required.
If the required material isn’t available the buffer will ask an operation for a new replenishment. Each buffer has a field indicating which operation is to be used to generate replenishments.
Depending on the buffer inventory profile, safety stock requirements, etc… the operation may be asked for different quantities and on different dates than the original demand.

When an operation is asked to generate a replenishment it evaluates the lead time, material and capacity constraints. This results in a nested ask-sequence similar as the one described earlier – marked with (*)

…
The maximum recursion depth will be the same as the number of levels in the bill-of-material of the end item.
In some cases the iteration can be stopped at an intermediate level. Eg. When sufficient inventory is found in a buffer and no replenishment needs to be asked: a positive reply can be returned immediately.
Eg. When an operation would need to be planned in the past (ie lead time constraint violated) a negative reply can be returned immediately.
…
The operation collects the replies from all its flows, loads and -indirectly- from all entities nested at the deeper recursion levels. A final reply of the operation is generated.
Based on the reply of the replenishing operation the buffer evaluates whether or not the replenishments are possible, and replies back to the flow. Sometimes a buffer may need to ask multiple times for a replenishment before an answer can be returned.
The flow picks up the buffer reply and replies to the operation.
From the reply of all its loads and flows the operation compiles a reply and returns it to the demand. The interaction of material, lead time and capacity constraint are pretty complex and an operation may require several ask-reply iterations over its flows and loads before a final answer can be returned.
The answer of the operation indicates how much of the requested quantity can be satisfied on the requested date.
Depending on the planning result and the demand parameters (such as allow/disallow satisfying the demand late or in multiple deliveries) we can now decide to commit all operation plans created during the whole ask-reply sequence.
If we’re not happy with the reply the operation plans created are undone again and we can go back to the first step and ask for the remaining material or at a later date.

The ask in each of the above steps consists of 1) ask-quantity and 2) ask-date.
The reply used in each of the above steps consists of 1) reply-quantity and 2) reply-date. The reply-quantity represents how much of the requested quantity can be made available at the requested date. The reply-date is useful when the ask can not -or only partially- be met: it then indicates the earliest date when the missing quantity might be feasible.

In the above sequence the steps are described at a very high level.
In the following sections each of the different ask-reply steps are now explained in further detail.

    • Getting started
    • Modeling guide
      • Simplified domain model
      • Detailed domain model
      • Environment variables
      • Python interpreter
      • Global parameters
      • Buffer
      • Calendar
      • Customer
      • Demand
      • Flow
      • Item
      • Load
      • Location
      • Operation
      • Suboperation
      • Operationplan
      • Problem
      • Resource
      • SetupMatrix
      • Skill
      • Resource skill
      • Solver
      • Extension modules
        • Forecast module
        • REST web service module
        • Linear programming solver module
        • OpenERP connector module
    • User guide
      • Main features
      • Supported browsers
      • Getting around
        • Logging in
        • Logging out
        • Changing password
        • Navigation
          • Menu bar
          • Jump search
          • Context menus
          • Browser bookmarks
        • Filtering data
        • Sorting data
        • Selecting time buckets
        • Exporting data
        • Importing data
        • User preferences
        • User permissions and roles
      • Screens
        • Data input
        • Supply Path / Where Used
        • Comments
        • History – Audit trail
        • Plan analysis
          • Problem report
          • Constraint report
          • Inventory report
          • Inventory detail report
          • Resource report
          • Resource Gantt report
          • Resource detail report
          • Operation report
          • Operation detail report
          • Demand report
          • Demand detail report
          • Demand Gantt report
          • Forecast report
          • Performance indicator report
        • Execute
      • Batch commands
        • manage.py (manage.exe on Windows)
        • frepple (frepple.exe on Windows)
        • freppleservice.exe (Windows only)
    • Installation guide
      • Windows installer
      • Compiling on Windows
      • Linux binary packages
      • Compiling on Linux
      • Compiling on debian-based linux
      • Compiling on Red Hat based Linux
      • Compiling from the subversion source code repository
      • Running the VMWare virtual machine
      • Other platforms
      • Configuring the user interface
      • Configuring multiple models in the user interface
      • Configuring as a Python extension module
    • FAQ
    • Developer guide
      • Code structure
      • Class diagram
      • Solver
        • Solver features
        • Planning algorithm
          • Top level loop
          • Demand solver
          • Buffer solver
          • Flow solver
          • Load solver
          • Operation solver
          • Resource solver
        • Cluster and level algorithm
      • Extension modules
      • Version control
      • Style guide
      • Portability
      • Security
      • Internationalization
      • Translating the user interface
      • Adding or customizing a report
      • Unit tests
        • buffer_procure_1
        • calendar
        • callback
        • cluster
        • constraints_combined_1
        • constraints_combined_2
        • constraints_leadtime_1
        • constraints_material_1
        • constraints_material_2
        • constraints_material_3
        • constraints_material_4
        • constraints_resource_1
        • constraints_resource_2
        • constraints_resource_3
        • constraints_resource_4
        • constraints_resource_5
        • datetime
        • deletion
        • demand_policy
        • flow_alternate_1
        • flow_alternate_2
        • flow_effective
        • forecast_1
        • forecast_2
        • forecast_3
        • forecast_4
        • forecast_5
        • forecast_6
        • jobshop
        • load_alternate
        • load_effective
        • lpsolver_1
        • multithreading
        • name
        • operation_alternate
        • operation_available
        • operation_effective
        • operation_pre_post
        • operation_routing
        • pegging
        • problems
        • python_1
        • python_2
        • python_3
        • safety_stock
        • sample_module
        • scalability_1
        • scalability_2
        • scalability_3
        • setup_1
        • setup_2
        • skill
        • xml
        • xml_remote
    • License
      • GNU Affero General Public License
      • GNU Free Documentation License
    • Third party add-ons
  • Copyright © 2010-2013 frePPLe bvba