Problem 4 (Order processing operations)

This is an example of how hierarchical logical networks are put together with NMOD. The content is a limited version of a program for supporting a small company's back-office operation that turns Internet orders into packages to be mailed. The program contains a small postage model formulated as a [sub]network in the process, showing how quantitative models can be easily plugged into NMOD process networks.

The two Excel tables in the image above contain postage rates in existence as of before March 1, 2002 for shipping orders by US Postal Service's Priority Mail, and information about what box types the company uses to ship orders of different sizes.

How this problem is structured is more easily understood through its ORMSware network diagram and its supplemental data files. Click the links below to open these files in separate windows for reference while reading this document.

VSD file: Image of Visio network file describing the model
NET file: Contains expanded logic, if any, underneath each node and arc.
ADD file: If link exists, contains procedures supplied by analyst to link with NET file.
PGM file: If link exists, contains model execution control statements supplied by analyst.
Results: Preview of results of this model.

Click here to view the orders file put together (names, numbers, etc. have been changed to protect customer privacy) to demonstrate the execution of the networks presented here.

Purpose/content of some of the nodes and arcs in this program are explained below:

OrderProc.n[1]CustomerArrival

This node in the OrderProc network is of the Arrival type. An Arrival node introduces a new customer into the system every time it is evoked. In this problem, every order is treated as a new customer entering the system. If there is one Arrival node in the model network, there must also be at least one Departure node in the model through which customers can leave. Otherwise, the system could eventually get overloaded with accumulation of customers. This is usually not an issue, because anytime there is a need for using customer arrival, there is a corresponding need for causing customer departure (known as birth-and-death processes in Operations Research/Management Science). In this case, customer departure happens at n[4]AddToShippedFile when processing of an order is finished.

There are two reasons why arrivals and departures were used in this model. Since we chose not to use the duration property on any of the node or arc in the problem, there is no time dimension controlling the sequence of events. We can keep items relating to each order separate and sequenced properly through customer arrivals and departures.

The other reason is the use of hierarchical networks in this model. Every execution thread has a stack object holding its calling sequence. When there are convergence nodes in a [sub]network, it is critical that execution threads of an order is not merged with that of another. When customer entities are used, NMOD automatically manages all of these activities so that the analyst need not be concerned about all of the housekeeping. All of this is explained in detail in Chapter 6 (Calculation/execution threads) and Chapter 7 (ORMSware entities) of the Primer.

This node (n[1]CustomerArrival) calls a customer-written procedure called ReadOrder (see ADD file) to read an order from orders file PedOrd.DAT opened in OrderProc.n[5]Initializations. ReadOrder puts various properties of the order in appropriate places (into properties of an order object in the real program used by the business), but ReadOrder calls another procedure called ReadAndChk to read each record. When there are no more records to read in the orders file, ReadAndChk turns off a flag (NextExists) to prevent n[1]CustomerArrival from sending out execution threads to its successor nodes.

OrderProc.n[3]PrintLabel: This is a network node. When an execution thread gets to this node, NMOD looks for a network named PrintLabel in the model file and routes execution to the start node in that network. When execution thread hits a Return node in the PrintLabel network, it comes back to this node and continues execution as if this were any other node.

If there are any references to other networks in the PrintLabel network, NMOD repeats the same procedure. The Postage network node in the PrintLabel network is an example of this kind of nested referencing. As a practical matter the only condition that restricts the number of nested levels is a computer's memory. There are no restrictions on recursive referencing. It is completely within the total control of the analyst.

OrderProc.n[2]PrintInvoice: This is a Network node, too. The reader will notice that there is no information about it in the NET file. That is because there is nothing happening in this node other than the automatic reference to the PrintInvoice network. Therefore, NMOD has all of the information it needs to execute this node. So, nothing needs to be included in NET file about this node by NMOD's network translater (called NETrans).

PrintLabel.n[4]FlagRequirements: This is a node in the PrintLabel network. It tracks the number of domestic, international and overnight orders in the latest PedOrd.DAT file to alert packers about certain requirements.

Postage network: This is a model for calculating postage based on the number of units in an order. Current business of the company involves shipping only one or more copies of the same product. The reader will notice that this model can be expanded to accommodate any number of products if the company decides to expand its product line. The company could use machines to determine postage, but this postage calculation model has been easy to put together and has been sufficiently accurate with little consequential costs.

Postage.n[10]BoxType: Based on the number of units to be shipped, this node in the Postage network figures out what box type should be used to ship the order. To do this, it looks up the table in the spreadsheet shown at the beginning of this document.

Postage.n[10]BoxAndPackMatWeight: Based on the box type and the number of units to be shipped, this node determines the weight of packing paper required to fill any void in the box. It combines this weight with the weight of the box to calculate the total non-content weight of the shipment.

Postage.n[1]ShippingWeight: This is a convergence node which waits for content weight from Postage.n[1]ContentWeight and container and packing materials weight from Postage.n[10]BoxAndPackMatWeight to determine total shipping weight.

a[3]ItemsInTheOrder--->|Postage

Postage.n[4]Postage: For Priority Mail rates this node pulls postage based on the shipping weight from the table shown earlier in this document. This is also a Return node, so when this node is finished, NMOD transfers execution control back to the node in the higher level network that evoked the Postage network.

Notice that there are two arcs terminating at this node, but neither of them is an AND arc. Does this mean that this node will get executed twice from one evocation of this network? No, it does not. The reason is that branching conditions on arcs leading out of n[11]ItemsInTheOrder are such that for any given order only one entity will arrive at Postage.n[4]Postage.

The Branch property on a[3]ItemsInTheOrder--->|Postage (see image of [3]'s dialog box at left) will allow an entity to travel to n[4] only if the shipping option is not Priority. The branch conditions on a[13] and a[14] will allow entities to travel along them only if the shipping option is Priority.

PrintInvoice network: Notice that there is no content on any of the objects in this network in this model's NET file, including the Return node [3] which is a Convergence node. The analyst did not have to write any convergence logic, because default convergence requirements could be used.

Notice that though the whole network is absent in the NET file, execution threads still traverse this network. We deliberately made this network empty to illustrate the point that a big portion of standard logic that would normally have to be written and tested in implementing a model using traditional programming is already quality-ensured and built into NMOD's design. NETrans knows when a node or an entire network does not have to be included in a model's NET file. We have pointed out this fact in previous examples when certain network objects were not included in their respective NET files, but thought a totally content-free network may drive home this point.

This model is not available for download. You can see and download another example of hierarchically networked model in Chapter 6 (Converting spreadsheet model to NMOD model) in the Hands-on Tutorial.