<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/> <title>Frepple / Implementation details </title> <link rel='stylesheet' href='../styles.css' type='text/css' /> <!--PageHeaderFmt--> </head> <body> <div id="container"> <div id="menubar"> <div id="logo" align="center"> <br/><img src='../frepple.bmp' alt="frepple" /><br/> <a href='http://www.frepple.com/'> <strong>a Free<br/>Production Planning<br/>Library</strong> </a></div> <div id="menu"> <br/> <h3><a href='../Main/HomePage.html'>Main</a></h3> <h3><a href='../UI/Main.html'>User Manual</a></h3> <h3><a href='../Tutorial/Main.html'>Tutorial</a></h3> <h3><a href='Main.html'>Reference Manual</a></h3> <h3><a href='../Main/FAQ.html'>FAQ</a></h3> <h3><a href='../reference/index.html'>C++ API</a></h3> <br/><div> </div> </div> </div> <div id="content"> <br/> <!--PageText--> <div id='wikitext'> <p><a class='wikilink' href='../Main/HomePage.html'>Main</a> > <span class='wikitrail'><a class='wikilink' href='Main.html'>Reference Manual</a> > <a class='wikilink' href='Solver.html'>Solver algorithm</a> > <a class='selflink' href='Solverimpl.html'>Implementation details</a></span> </p> <p class='vspace'>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. </p> <p class='vspace'>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. </p> <div class='vspace'></div><div class='indent'>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 <strong>asks</strong> this <strong>operation</strong> for the requested quantity on the due date of the demand. <div class='indent'>(*) The operation first checks for the lead time constraints. </div><div class='indent'>The operation will <strong>ask</strong> each of the <strong>loads</strong> to verify the capacity availability. </div><div class='indent'>The operation will <strong>ask</strong> each of the <strong>flows</strong> to check the availability of consumed materials. <div class='indent'>A load passes on the question and <strong>asks</strong> the <strong>resource</strong>. <div class='indent'>The <strong>resource reply</strong> indicates whether the capacity is available or not. </div></div><div class='indent'>The <strong>load</strong> uses the resource reply to <strong>reply</strong> to the operation. </div><div class='indent'>A flow passes on the question too and <strong>asks</strong> the <strong>buffer</strong>. <div class='indent'>The buffer checks the inventory situation. </div><div class='indent'>If material is available no further recursion is required. </div><div class='indent'>If the required material isn't available the buffer will <strong>ask</strong> an <strong>operation</strong> for a new replenishment. Each buffer has a field indicating which operation is to be used to generate replenishments. </div><div class='indent'>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. <div class='indent'>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 (*) <div class='indent'>... </div><div class='indent'>The maximum recursion depth will be the same as the number of levels in the bill-of-material of the end item. </div><div class='indent'>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. </div><div class='indent'>Eg. When an operation would need to be planned in the past (ie lead time constraint violated) a negative reply can be returned immediately. </div><div class='indent'>... </div></div><div class='indent'>The operation collects the replies from all its flows, loads and -indirectly- from all entities nested at the deeper recursion levels. A final <strong>reply</strong> of the <strong>operation</strong> is generated. </div></div><div class='indent'>Based on the reply of the replenishing operation the <strong>buffer</strong> evaluates whether or not the replenishments are possible, and <strong>replies</strong> back to the flow. Sometimes a buffer may need to ask multiple times for a replenishment before an answer can be returned. </div></div><div class='indent'>The <strong>flow</strong> picks up the buffer reply and <strong>replies</strong> to the operation. </div></div><div class='indent'>From the reply of all its loads and flows the <strong>operation</strong> compiles a <strong>reply</strong> 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. </div></div><div class='indent'>The answer of the operation indicates how much of the requested quantity can be satisfied on the requested date. </div><div class='indent'>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. </div><div class='indent'>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. </div><p class='vspace'>The ask in each of the above steps consists of 1) ask-quantity and 2) ask-date.<br />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. </p> <p class='vspace'>In the above sequence the steps are described at a very high level. <br />In the following sections each of the different ask-reply steps are now explained in further detail. </p><ol><li><a class='wikilink' href='Solverimplplan.html'>Top level loop</a> </li><li><a class='wikilink' href='Solverimpldemand.html'>Demand solver</a> </li><li><a class='wikilink' href='Solverimplbuffer.html'>Buffer solver</a> </li><li><a class='wikilink' href='Solverimploperation.html'>Operation solver</a> </li><li><a class='wikilink' href='Solverimplflow.html'>Flow solver</a> </li><li><a class='wikilink' href='Solverimplload.html'>Load solver</a> </li><li><a class='wikilink' href='Solverimplresource.html'>Resource solver</a> </li></ol> </div> <!--PageFooterFmt--> <!--HTMLFooter--> </div></div> </body> </html>
