When feed plan is approved, farm managers will plan operations around expected delivery dates.  There may be logistical and planning reasons which require the feed mill to commit to the agreed upon dates, one such an example provided is when it snows, and farmers have to plan for plowing services to clear the road for scheduled deliveries. Once something like this has to be coordinated, deliveries optimized by flock performance take a lower priority to showing up at a certain times and dates.  

The feed plan fixed date feature will force the regeneration process to lock down specific delivery dates and prioritize creating records with those dates.

Adding Single Fixed Dates

...

If the user clicks "Yes", the feed plan will be approved and saved with dates created for each distinct delivery date.

Calculating Fixed Delivery Dates

During the calculation of the feed plan, fixed dates are treated as two things: An inspection criteria and an override for delivery date buffers.

A new delivery cause was added with the creation of this new feature. "Fixed Date Max Delivery Size" is a reason that we might see as we approach an upcoming fixed delivery date. Uncommitted, past deliveries may recalculate to recommend less feed to be delivered, so that more can be scheduled on the fixed date, or so that we do not get a bin return on that date.

This new reason has been added as the lowest priority reason to package and schedule a delivery.

Fulfilled Fixed Dates

Before the feed plan begins to calculate the first step the code performs is to mark all fixed dates behind delivered or committed orders as "fulfilled". Fulfilled dates will still appear in the tool list of dates, and will give the user no indication as to whether a delivery actually occurred at that date or time. When the plan recalculates, these records will not be considered, as we cannot go back and plan orders in the past, behind older orders and deliveries.

If a delivery did not go out at the scheduled, fixed date or time, this can be inferred by comparing the list of fixed dates to the delivery date, or users can add comments to the fixed dates themselves.

Deliveries or committed orders do not have to have been created from the actual fixed date record for the older dates to be marked as fulfilled.

Calculating Delivery Date Every Interval

When each hour of consumption is calculated for the flock, the delivery date for that hour is calculated as well (interval date - configured feed buffers). These delivery dates are now also audited. This is a change from the last version of feed plan, where these dates were calculated once when an order was initialized and then saved in memory.

Now that each hour of the life of the flock has a delivery date, these are compared to each of our fixed dates. If this date meets or exceeds a fixed date by no more than twice the buffer, then this planned delivery that we are calculating must go out on that fixed date. All loads assigned to that order for that day will be assigned that fixed date.

Because delivery date buffers change with overall consumption, and because our logic for rounding will assume past or future hours of consumption to make rounded delivery amounts, we could not code the fixed date logic to look for exact delivery dates. Because of the code above that will wrap up deliveries prior to a fixed date, and because the feed plan process is already designed to optimize delivery sizes without causing overflows or feed returns, the approximation of the dates always results if a difference of hours that should not cause any concerns.

We might want to deliver even more on fixed delivery dates. At present, the code will already attempt this, until a ration or medication goal is met and the "Allow mixed feed" configuration for feed plan is set to false. When this is set, more loads will can be added to other bins on the house, but cannot be dumped on top of current. Turning this configuration off will ignore this constraint, and more feed will go out of fixed dates. Tuning or reducing the size of feed buffers might also improve this, albeit to a small degree.

Fixed Dates Bypass Delivery Optimization

When feed plans are created and their "order object" (the object in the code that attempts to pack up hours of consumption into one or more optimized feed plan loads) has assigned all these records their fixed date, that fixed date is marked in memory as "fulfilled". As we iterate through the hours of consumption on the flock, creating more feed plans, that date cannot be reused.

Rounding

Rounding on fixed date deliveries will only round up, to optimize the amount of rounded feed delivered on the fixed date.

Update to Inspection Criteria

...

A new key can be added to the app.config. This key, "FeedPlanAuditPath" will enable the audit of each feed plan to be written to a file on the local machine.

<add key="FeedPlanAuditPath" value="C:\imp\fp\" />

Process

...

Check every order event reason supported by the feed plan generate process

...

• We created a new reason event that checks for the time when the current date in the flock life cycle matches an existing fixed date. 
• Unlike other reason events, this process does not trigger the generation of a feed plan. 
• Instead, it will assign the matching fixed date as the 'next' delivery date and place it on hold.   No other action is taken at this time
• The process will continue consuming for the current feed plan until completed.

...

When a reason criterion is met, the process will check if there are any fixed dates assigned to the next delivery date placeholder.  If there are, it will force a hard completion of the current order request. 

...

After creating the current feed plans, the process creates a new order request.  It is at this point that the fixed date placed on hold by FplConditionInspector.FixedDateIsNext is used

...