74) Buying on a Budget

When we shop for ourselves we, (as mature responsible people), set a budget.   It wouldn't do to spend more than we can afford.   So why is it, when we set up planning models to shop for tankerfuls of crude oil, there are no spending limits?  Planning models are usually run as if there is no concern for total costs. The optimization maximizes profit margin; no limits are set on what can be spent to achieve it.   I’m guessing in that in normal times for an established business, lines of credit can be assumed to take care of outgoings until the sales revenue arrives.   But what if credit is tight? The global economy and political landscape have had quite a few upsets so far this century. For some companies that has meant operating with limited access to finance. Feedstock evaluation changes from being an assessment of how valuable each option is to asking "What is the best combination of  feeds that can be obtained for the money available?".

GRTMPS does not have a specific feature for controlling total purchase costs. However, it is possible to create such a constraint with the Purchase/Sale Combined Limits options.   Here are the crude purchases from the Weight Demo model (TABLE 1BR.0 in the case data file if you prefer the spreadsheet input system).

Controls summing over multiple purchases can be set up on the Combined Limits tab.  For example, here is a Combined Group definition with all the crude purchases as members.

The members all have a Value of 1 so each purchase contributes to any limit on group TOC the same as the amount bought. (TABLE 1BR.3).   The purchases in this model are priced and limited per tonne, so any limit on this group would also be in tonnes. This simple 1-to-1 counting is both useful and common, but other things can be counted by using different Values.  For example,  you could use the specific volume (1/density) for each crude for limits on the total m3.  For a limit on the money spent, put the price.


If the purchases are priced and limited in the primary weight or volume units – for this model either $/TON or $/M3 – then the Value entry is the price.   However, if crudes are priced in secondary units - $/BBL for volume in this model - then  convert the price to per primary unit to get the correct Value entry, using factor given on the Units of Measurement panel (1COSTW2 or 1COSTV2 in TABLE 900.0).  The variables in the matrix are always in primary units. If you are mixing volume prices with weight limits or vice-versa, you will need a density factor as well to match the matrix co-efficient. 

The limits go in the bottom grid (or TABLE 1BR.1). If you have multiple periods and locations then you can also set limits on particular subsets and use XX in place of a specific code to include them all. See Note 12) Bounds, Limits and Groups for more details.   If the purchases span multiple accounts, use the Combined Limit panel on the top level purchase node  (TABLEs 110.1/ 110.3) instead of the account specific one. 

Whenever I build a new limit, I test it with a minimum of 0, so that it will be generated and reported.

Then I can see if the value is the sort of number I am expecting. (The TOC limit is not necessary for making the other control, just interesting.)

Since I am counting all the spend in the BRX account (I moved all the non-crude purchases to a different one), this value is the same as what is on the economic summary report.

This is an especially useful check when a conversion factor is needed for the Value as the totals will only agree if that has been done correctly. You can also keep an eye on this relationship to make sure that the group membership and Values have been refreshed when crudes are added or the price set is updated. The Value numbers are Base/Alternate data so you can have different price sets in different cases with matching group factors. There is also a Spreadsheet Import (SSI) option for loading data into this panel. If the purchase data is set up in Excel, you could link them together to simplify the maintenance. 

 When setting an actual limit, remember to note the per period or per day setting for the account and any scaling factors.   For the WT demo model, the maximum budget is going to be for a 30-day period and there is no model level input scaling - so the value is quite large, in comparison to the limits on the quantities bought/sold/processed.

 In this small model the bad scaling makes no difference to the behaviour, although it overruns the space on some of the reports.   I could improve that by expressing everything in a larger unit, such as thousands of dollars. The decimal place on the Values would move – 445.8 to 0.4458, and the Limit would be 227500.

If the budget limit is constraining, the marginal value will be shown on the report.

If there was another dollar to spend, the net benefit would be 5 cents. The amount of crude dropped a little as well. The marginal values on the crude stream balances from the unconstrained case would have given you some idea of which grades were likely to be reduced. However, to properly handle the budget issue, the purchases should probably be presented as cargo size choices, using Batch or Semi-Continuous limits since most sellers won’t let you take just a fraction of a load. With that taken into account the shifts in choices might be rather more dramatic.

Need to control other costs too? Utilities have similar combined limit features. For inventory, blending, transportation and process units you can count costs onto a Unit Cap limit and associate it with a pretend process unit (ACC-DP for Accounting Department?). The purchases could always be included in such a control as well to make an overall count.

So if you really have to count your pennies, you can get the model to do it for you and still use optimization to find a plan without worrying about it breaking the bank.

From Kathy's Desk.