The Back Orders tab is where you define List properties associated with back orders. To get to the Fields tab of a List, double-click on the desired List in the Toolbox (if you haven't added a List you can add if from the 
button in the Toolbox). Then select the Back Orders tab.
- Back Order Queue Strategy The Back Order Queue Strategy defines how back orders will be prioritized for a given value. When a value is pushed onto the List, outstanding back orders are processed for that value in the order defined by this queue strategy. It should be an SQL ORDER BY statement that references at least one puller-dependent field (see the puller term in the List Concepts topic for more information). This is because the back order queue strategy is used to prioritize back orders against a single entry. An ORDER BY statement that gets data only associated with the entry value would consequently have the same result value for all back orders, and would thus be unable to properly prioritize the back orders.
Examples
ORDER BY Puller.priority DESC- This will prioritize the pullers who have the "priority" label with the highest value.ORDER BY pullerPriority DESC- This example is essentially the same as the previous example, except that here you would need to explicitly add a dynamicpuller-dependentexpression field named pullerPriority, and give it the expression:getlabel(puller, "priority").ORDER BY distance ASC- This example will prioritize the back orders with the lowest distance value, which usually defines a distance between the value and the puller. - Unique Pullers Only Check this box to disallow multiple back orders with the same puller. If this is checked and a pull request is made with the same puller as an existing back order, then that pull request will replace the previous pull request.
- Back Order Reevaluation Events This pane lets you define when back orders should be reevaluated. This is usually only needed if in your pull request you have a WHERE clause whose result may change while the back order is active. For example, consider the following query:
WHERE queueSize <= 5. If the pull request is made at a point when queueSize is greater than 5, then you may want to reevaluate that pull request when queueSize becomes less than 5. FlexSim doesn't automatically know when this condition may change, so you need to define events that will trigger reevaluation.To add a reevaluation event, click on the
button, and choose an event to add. Then choose the Event Type you want to listen for. Events
There are several categories of reevaluation events, as follows:
Puller Event
A puller event is an event that happens on the puller. Here the puller must be an object (not a number or string). When a back order is created, the List will listen for the defined event on the puller object, and when the event fires, the back order will be reprocessed for all values in the list.
Value Event
A value event is an event that happens on the value, i.e. the primary value of an entry. Here the value must be an object (not a number or string). When the value is pushed to the List, the List will listen for the defined event on the value object, and when the event fires, all back orders will be reprocessed for that entry.
Global Event
A global event is some event that is not associated with either values or back orders. The List will listen for this event and will reprocess all back orders whenever the event happens.
Time Interval
A timer interval event will cause the List to repeatedly reevaluate back orders at a set time interval. When the first back order is added, the List starts the timer loop and reevaluates back orders after the given time elapses. The timer loop ends when the back order queue is emptied.
