There are 13 different forecast methods in Ignite.

They can be split into 4 different groups:

  • Will Calls
  • Tank Monitors
  • Scheduled / Julian / Gallons Per Day
  • Degree Days

Will Calls:

There are 4 different forecast types that fall under the ‘Will Call’ category:

  1. Will Call
  2. Will Call Until Next Delivery – Once a customer is on this forecast type, then when a delivery ticket is created, Ignite will AUTOMATICALLY change the customer’s forecast type back to whatever was in the ‘Previous Forecast Type’ field.
  3. On Hold
  4. Stopped – These fuel records are ignored when a delivery is posted.  Think of them like a deleted record except that you can see it on the screen.  Ignite essentially treats them as a deleted record.

Tank Monitors

With a tank monitor, Ignite will import data from the tank monitoring system and then update the customer’s estimated delivery and % full based on what the tank monitoring system says.
There is a separate screen to pull tank monitor customers and these customers are pulled when their estimated delivery is greater than their optimum delivery.
Scheduled / Julian / Gallons Per Day


These customers have the ‘Julian’ box checked off on the ‘Fuel Schedule’ tab.
They get a delivery every ‘x’ days.
You can enter a start and end date and have different time periods for different times of the year (i.e. in the winter vs. the summer, etc).
The # of days does NOT automatically recalculate when a delivery is posted.

Gallon Per Day (GPD):

These do NOT use the ‘Fuel Schedule’ tab.
It is very similar to the Julian forecast method except you CAN have their forecasting recalculated when a delivery is posted (i.e. if you have ‘recalculate gal/day’ checked off, then the customer’s Gallons Per Day will get recalculated each time a delivery is posted).
The ‘Baseload’ field says how many gallons per day the customer uses.
You change seasons with Gallon Per Day customers like you would change seasons for the Degree Day customers.

Julian vs. GPD – How Do I Choose?

By reviewing the above information, you’ll notice that a Julian schedule is very similar to a Gallon Per Day schedule.  As an example, if you had an optimum delivery of 180 gallons, then setting up a Julian customer for every 30 days would be the same as setting up a Gallon Per Day customer with 6 gallons per day.  So the question to ask yourself is:  Do I want the system to recalculate the value for me?
If your answer is ‘Yes’, then you should use Gallon Per Day.
Of course the other difference has to do with time periods because Julian customers let you customize the time period on a particular customer whereas with Gallon Per Day customers, you have to change seasons and when you do, it changes all the Gallon Per Day customers at the same time.  So, Julian schedules give you more flexibility for different time periods (i.e. farms, pool heaters, etc).


These customers do NOT have the ‘Julian’ box checked off on the ‘Fuel Schedule’ tab.
These are VERY flexible because you can setup deliveries many different ways:

  • For a particular day of the week
  • For the 2ndMonday of the month
  • Every other Wednesday
  • Every 3 days

Basically the schedule can be based on days, days of the week, weeks, months or any combination of these.
And like Julian records, you can have different schedules for different time periods.

Scheduled vs. Julian – How Do I Choose?

Technically both allow you to schedule deliveries every ‘x’ days.  HOWEVER, there is a difference in HOW they do it.  Julian accounts always go ‘x’ days after the last delivery date.  Scheduled records do not.  They go every ‘x’ days from the start date.  So, if you have customer 1 setup as a Julian for every 20 days and you setup customer 2 as a schedule for every 30 days and they both got a delivery on January 2nd, then they would both need a delivery again on January 22nd.  If however you delivered to them both on January 23rd, then the Julian customer would be due 20 days from January 23rdbut the scheduled customer would be due 20 days from January 22nd.
So, as a general rule, unless it is a commercial account, you most likely want to use ‘Julian’.
Since we are talking about the ‘Fuel Schedule’ tab of the customer screen, we should also mention that you also have the ability to ‘Exclude Deliveries’ between 2 dates.  This is done by checking off the ‘Exclude Deliveries’ box and then filling in the start and end dates.

Exclusion periods work for any type of automatic customer.  So, yes, you can setup an exclusion period for a customer on the degree day system and then that customer will not pull for a delivery in that time frame.

Degree Day Forecasting: 

There are 3 different Degree Day Forecasting Methods in Ignite:

Degree Days – There 2 types:

Auto Heat Only – Their usage is calculated by dividing the # of DDays that have elapsed by the customer’s K Factor.

Auto Heat & Hot Water – Their usage is calculated by dividing the # of Hot Water DDays that have elapsed by the customer’s K Factor.  There is a setup table in Ignite that allows you to setup how many extra DDays need to be added each day based on how cold it was that day.

Degree Days with Baseloads – There are 2 types:

Auto Baseload – Their usage is calculated by dividing the # of DDays that have elapsed by the customer’s K Factor and then adding the baseload usage (# of days since their last delivery times the baseload field).

Auto Baseload & Hot Water – Their usage is calculated by dividing the # of Hot Water DDays that have elapsed by the customer’s K Factor and then adding the baseload usage  (# of days since their last delivery times the baseload field).

Baseloads vs. Non Baseloads – How Do I Decide?

Isn’t having a Summer K Factor of a 6 the same as having a baseload of 1?  Yes it is.

So who uses Baseloads instead of Hot Water DDays to forecast?

Baseloads are required when the customer is using fuel for non heat or hot water usages (i.e. cooking, dryer, etc.)  Also, some of you may have come from a software package where they did not allow you to calculate hot water usage by adding extra DDays each day.

How are they treated differently inside Ignite?

For a non baseload customer, the customer is pulled for a delivery when the customer’s Next DDay is less than the DDays you pull out to in the Pull Automatics screen.
For a baseload customer, the customer is pulled by calculating how many gallons the customer has used and if that total is more than the customer’s optimum delivery, then the customer is pulled for a delivery.

Next DDay Field:
The Next DDay does NOT change for Non Baseload customers once it is set (i.e. when the delivery is posted).
The Next DDay DOES change for Baseload customers each day the DDays are entered.

Recalculating After a Delivery is Posted:
When a delivery is posted to a Baseload customer, there are now 2 variables instead of 1 which could need adjusting.  So when recalculating a Baseload customer, Ignite assumes the Baseload is correct and will only adjust the K Factor.  This means if your Baseload is wrong, Ignite will forever  try to correct the K Factor when it is really the Baseload that needs correcting.
With a Non-Baseload customer, the only variable is the K Factor so it is a much cleaner recalculation.


SmartK is a more sophisticated Auto Heat Only or Auto Heat & Hot Water forecasting method.
It will AUTOMATICALLY use the appropriate Season’s K Factor depending on the weather for that day.  So, if it is December and 2 days ago it was 45 degrees and then yesterday it was 25 degrees and today is 60 degrees, the system would automatically use the Fall K Factor to calculate usage 2 days ago, the Winter K Factor to calculate usage yesterday and the Summer K Factor to calculate usage today.
This results in a much more accurate forecast because when there is a warm day in the winter, the system will automatically use the spring or summer K Factor.
Since the system is automated, you are not allowed to change the K Factors.  They are strictly controlled by the SmartK system.