This topics covers certain concepts and terminology which are important to understand when using Fusion. You can use the links below to jump to different sections within this topic if you like.
In Fusion, a location is physical place that has everything needed to be a feedlot on its own. It will have its own pens, feeding system, chuteside system, etc. Within Fusion, each location has its own lots, pricing, attributes, feed mill, water meters, feed trucks, etc. It is assumed that animals arrive into one location and stay there until they are ready to leave the feedlot. Inventory levels are tracked separately for each location.
There is always one location in Fusion and there can be as many as you like as long as these requirements are met:
Fusion Server will be at one of the locations and all computers at other locations will communicate with it.
You can add locations over time. Each one will need to be transitioned in a similar manner as the first one was.
Most locations you create will reflect locations you actually own and operate. It is also possible to designate locations as "inventory-only". This is useful when you are tracking animals that you own but don't physically take care of. We only charge for a portion of the headcount for these types of locations, but the following features will not be available:
For more information about locations, including how and when to create them, please see Location Edit Window.
A lot is the basic billing unit in a feedlot. It consists of a group of animals, usually with very similar characteristics. Normally they arrive and leave close to the same time, have similar weights, etc. A lot can be spread across multiple pens, but not multiple locations. There can also be multiple lots in a pen. All billing and closeout type information is rolled up to the lot level. (If you find yourself wishing you had closeout type information for groups within a lot, you probably should have created several lots in the first place.)
A lot is owned by one or more people, each on a percentage basis. This ownership arrangement can change over the life of the lot. The owners are billed according to the lot consumption based on their ownership percentage at the time of the consumption.
It is intended that a lot have a limited life span Basically, a lot exists from the day the first animal arrives until the last animal leaves. All expenses associated with the lot must fall within that time period. When an out cohort is created that brings a lot's count to zero, the lot is automatically closed and cannot be reopened unless the out cohort is deleted.
A lot is unique in history. It's name is never reused in a location.
Except for the first few days in a receiving pen, all animals must belong to a lot the entire lot they are in the feedlot. It is possible to move animals from one lot to another, but only by selling them from one lot and buying them back in to another lot.
In the feedlot industry the term pen is used interchangeably while referring to two distinct concepts. The first is a group of animals with similar characteristics that will be billed for together. In Fusion we use the term lot. The second is a physical structure that holds a group of animals for a time. In Fusion, a pen is associated with this latter meaning.
A lot can be spread across multiple pens and a pen can have multiple lots in it at the same time. Animals from a lots can move from pen to pen while they are in the feedlot. Animals must always be in a pen while they are in the feedlot—Fusion does not allow a lot to have animals that aren't in a pen at any point in time. Some events, such as feeding, are always recorded on a pen-level. When Fusion figures out billing and closeout type information, it assumes that the lots in a pen consumed the feed proportionately based on head count or body weight.
A pen always belongs to one location and cannot be moved to another. Once a pen has been used, it cannot be deleted, although it can be marked as non-existent if it is physically removed from the feedlot.
It is generally not possible to get billing and closeout data on a pen basis. You must design your lots to achieve this.
A sublot is simply a unit that Fusion used internally to keep track of head counts within lots and pens. Each lot/pen combination is known as a sublot. For example, if you had 2 lots in pen 5, each with 50 head in them, there would be two sublots in that pen. There can never be more than one sublot in a pen with the same lot/pen combination.
You don't normally have to worry about sublots as Fusion maintains them automatically by creating, deleting, merging, and splitting sublots as necessary to keep track of head count and weight or lot/pen combinations over time. But is can be helpful to know that sublots are what actually tracks where pens are over time and what there weights are each day, etc. And there are a few places where the idea of a sublot is exposed in the interface in Fusion.
An in cohort is a group of animals that arrive at the feedlot together, go into the same initial pen together, and are destined for the same lot. If a group of animals arrives that will be sorted into multiple lots, you will need to create multiple in cohorts for them or wait until you process them and let the chuteside job create in cohorts for you based on the how the sort went.
For feeding and other purposes, animals don't exist in the system until an in cohort is created. Therefore, an in cohort must be created before the animals can be fed. It is possible to create an in cohort for animals in a pen before knowing their lot to allow for feeding, but the lot must be assigned before the animals are moved to another pen and only one lot can be assigned the entire in cohort.
| When an in cohort is created, the total weight and head count are part of the information needed to create the in cohort. Fusion uses this weight to figure out the starting weight for the animals in the pen and it then calculates the weight gain for these animals each night based on feed consumption and other factors. It is important to understand that if you later change the weight of the in cohort, Fusion does not attempt to figure out where the animals from that in cohort currently are and update their current weight! You must do this manually when it is necessary. We recommend entering an accurate or best guess possible weight when creating an in cohort so this isn't an issue. |
Similar to an in cohort, an out cohort is the only way an animal can leave the system, including if it dies. An out cohort consists of one or more animals leaving the system at the same time. The group must all be from the same pen and lot.
Unfortunately, the term animals is often used to refer to two slightly different concepts within Fusion. Although both meanings refer to actual animals, they become distinct because of the way Fusion has to track to separate concepts. As we explain this, we'll refer to to head counts and individual animals to keep the concepts clearer.
As explained above in the Sublots section, internally Fusion keeps track of how many animals are in each lot/pen combination over time. On a simple level you could think of Fusion as keeping track of the count of animals (and their weight) for each pen and lot for each day. So when you create cohorts or make pen moves, internally Fusion is simply changing the head counts it is tracking. Let's look a three examples:
As you create cohorts and pen movements, Fusion handles the math and record keeping for you. It is important to recognize that these head counts are the official record of how many cattle you had in any pen or lot at any time. These counts are used for feeding, billing, closeout reports, calculating head days, and many other areas of Fusion. At the end of the day, these are the counts that matter.
For some feedlots, having Fusion keep track of the head counts as described above is all that matters. However, most feedlots also want to keep track of information about the individual animals the head counts represent. In Fusion, each animal that goes through the chute during a chuteside job gets a record and you can store all kinds of information about an animal including its full health history.
The problem that can occur is when you create a cohort or make a pen move in Fusion, you don't always know (or care) which individual animals belong to the group in question. Which means that Fusion can't always know exactly which individual animals are represented by which head counts. If Fusion tried to force you to tell it which animals where in every pen move, for example, it would be nearly unusable for many people.
Fusion overcomes this problem by having a place to record the current pen for an individual animal and by allowing optional linking to individual animals during a cohort or pen move. When we talk about the current pen for an individual animal, we are referring to the pen number the animal's record indicates it is in. As you will see in a minute, it is possible that this current pen may not, in fact, be where the animal really is! To explain further, let's imagine a few animals that were initially in pen 1. There records in Fusion might look something like this:
| RFID Number | Current Pen | Other Information |
|---|---|---|
| 124000678987544 | 12 | ... |
| 124000678233908 | 12 | ... |
| 124000678109723 | 14 | ... |
Let's also imagine that the head count side of Fusion currently looks like this:
| Pen Number | Current Count | Other Information |
|---|---|---|
| 12 | 2 | ... |
| 13 | 0 | ... |
| 14 | 1 | ... |
This is great since we can see that the individual animal records agree with the pen head counts. However, let's move 1 animal from pen 12 to pen 13. If we don't let Fusion know which individual animal is being moved, it can only change the head counts:
| Pen Number | Current Count | Other Information |
|---|---|---|
| 12 | 1 | ... |
| 13 | 1 | ... |
| 14 | 1 | ... |
But the animal records would remain unchanged so we now have two individual animals that think they are both in pen 12, but the head count side of Fusion (the one that matters) knows there is only one animal in pen 12 and the other is in pen 13.
If you know which animal is being moved, you can link them during the pen move. Let's say we had linked 124000678233908 in the previous move. During the move, Fusion would have updated the individual animal records as well as the head counts:
| RFID Number | Current Pen | Other Information |
|---|---|---|
| 124000678987544 | 12 | ... |
| 124000678233908 | 13 | ... |
| 124000678109723 | 14 | ... |
Obviously, the best scenario is to always link animals to cohorts and pen moves. If you can do this you won't have to worry about the above problem because the head counts and the individual animal records will always match up. The reality, however, is that most feedlots will run into situations where it is more work than it is worth to keep these two sides perfectly in alignment. Fusion will do its best to work with you in either case, but hopefully you can understand why these two sides may not always agree.
There are some particularly important side affects to be aware of if animals are not always linked perfectly:
To learn how to actually link animals, see the Entity Chooser topic.
Generally the "grain" for transactions in Fusion is one day. For example, while the head count for a pen or lot may vary during the day, billing is based on the status of the animals at midnight each day. This simplifies calculations where increased complexity would not result in increased credible accuracy. For example, if an animal was moved from one pen to another at 3:00 p.m., it would be difficult to come up with a formula to indicate how much the animal consumed from one pen compared to another. Note that this means if you deliver feed to a pen that is empty by midnight, Fusion will not know where to bill the feed to so you need to help Fusion account for it some other way (see Unbilled Feed Window).
When Fusion calculates billing information, it does this in a consistent manner so that you will get the same results whether you look at billing for one day or a month, for one lot or across multiple lots. It does this in the following manner. Fusion looks at everything that happened to a lot on a particular day. It will sum up the total of each drug, ingredient, input, etc. associated with the lot during that day. Once it has the sum for each item, it will then round each item to the nearest cent. From there it will sum similar items (all ingredients for feed, all drugs, etc.) to get the total for the day. Of course, these numbers are already rounded. It then repeats this process for subsequent days in the period. Finally it sums the items across all days.
Some calculations, such as the average price per unit, are done at the end of this process. Because Fusion bills on actual ingredients in a load, for example, instead of a theoretical ration, and because pricing of commodities can change throughout the month, it is easiest to figure out the average price per unit after everything else in a period has been summed and rounded. However, this also means that these values may not be exactly what you expect. Normally they are very close, but it is possible that a very high priced ingredient that was consumed in a very low amount can result in exaggerated price per unit values simply because we are calculating on rounded numbers. Unfortunately, it isn't possible to have consistent pricing as explained above and perfect price per unit values at the same time. Either we round for each day or round for a period and we felt the former is more beneficial.
Prior to Fusion 3.8, Fusion calculated taxes for reporting and billing based on a tax formula system. This worked by giving Fusion an overall tax formula in the Preferences window which would be applied to the total for drugs, ingredients, inputs, etc. at the end of each day and then summed across the period to come up with the total tax. As of Fusion 3.8 this system has been deprecated in favor of a new system for calculating tax based on tax rates.
The tax rate system works by having a tax rate associated with each ingredient, drug, input, etc. This is done using the Tax Rate attribute which is available for ingredients, drugs, inputs, and water meters. This tax rate can be set up and changed over time using the attribute edit windows or the Bulk Attribute Change Window. Associating a tax rate with yardage is done in the Lot Edit Window where the other yardage information for each lot is set up. You can also specify a tax amount with each other item in the Lot Edit Window. Fusion calculates tax by applying the tax rate for the total quantity of an item (drug, input, ingredient, etc.) at the end of each day and then summing across the period.
In order for historical data to be unchanged for customers using Fusion prior to version 3.8, there is a field in the Billing section of the Preferences Window which determines the date that Fusion will switch from the old to the new system. When Fusion is calculating a report or invoice, it will use the tax formula system for any day before this date and the new system for any day on or after this date.
It is important to realize that this date field completely controls which tax system Fusion will use. So, even if you have entered a yardage tax rate or a tax amount for an other item, they will be ignored for things that are before this date.
New customers starting with version 3.8 or later should not use the tax formula system at all. For customers who started using Fusion prior to version 3.8, we recommend the following steps to switch to the new tax rate system:
Fusion will now start using the new tax rate system for any data it is calculating from the switch date onward.
There are many places in Fusion where you can associate a contact with something. For example, when you create an in cohort and want to record who did the trucking for the load, you enter then name of a contact. Internally, Fusion associates the trucking for the in cohort to all the information associated with a contact.
Contacts can either be designated as a company or a person. However, both companies and people share most of the same characteristics such as having associated phone numbers, addresses, etc. Company type contacts can be associated with people type contacts and visa-versa so you can keep track who is involved with what companies. It is possible for a person be be associated with multiple companies.
Some people like to take the time to enter all their contacts while they are setting up Fusion. While this takes some time up front, it makes it nicer so you don't have to worry about this later on. Alternatively, you can create contacts on the fly as you enter other data.
Anyone who will be using Fusion at your place needs to have a user account in Fusion. This would include staff members and might include outside consultants such as your vet or nutritionist. Each user is tied to a contact which allows Fusion to know the actual name, phone number, and email address of the user which it can use in some places to save data entry.
Most of the events that are recorded in Fusion are tied to the user responsible for the event. We encourage you to have a different user account for each person who uses Fusion as opposed to generic user accounts such as for those feeding or those in the office.
Each user belongs to a group and you can assign permissions to different groups. This makes it easy to determine which users have permission to do certain things within Fusion.
Commodities and ingredients are the same thing in Fusion. We tend to refer to them as commodities in the context of contracts, scale tickets, and inventory tracking and ingredients in the context of rations and loads. You can define your own list of commodities, including micro ingredients.
If you temper any of your ingredients, you can use a water meter to record the amount of water that is added. Fusion can then ignore the water, leave the water, or bill the water at a different price when billing for that ingredient (see the Preferences Window topic for more information).
When Fusion calculates water used in tempering it tries to get a meter recording from before and after the date in question. It then figures out the amount of the tempered commodity used in the same period and distributes the water equally for the time period. If a meter reading does not exist on each side of the time period, Fusion uses the closest such time period it can. There must be at least two meter readings before this will work.
Because of the way Fusion calculates water usage, you shouldn't record water meter readings too often. For example, if you recorded every day the likelihood of the ratio of water used and that particular ingredient used every single day being the same would be very low. So we recommend choosing a time period between one week and one month to record water meter readings and to then be as consistent as possible.
When recording the dry matter percentage attribute for an ingredient that is being tempered with a water meter, the dry matter percentage should include the water added through tempering.
Fusion can be used to keep track of your commodities contracts and loads that are delivered to each location which fill those contracts. Each contract can be set up to automatically close when it is filled. Contracts specify discounts and premiums so load prices can fluctuate depending on quality. You can also override the price for an individual load when needed.
One contract can be filled by loads that are delivered to multiple locations. Loads are recorded as "scale tickets" in Fusion. These scale tickets should then be reconciled to the contract they filled. It is possible to have multiple contracts open and being filled at the same time, even if they are for the same commodity and broker.
Fusion keeps track of the truck or feed wagon that was used to make and deliver each load. You will need to tell Fusion a bit about each truck including its capacity. This information is then used for things like allowing Fusion to calculate how large a load the truck can handle for each ration.
Some people create a fake truck named Office which they associate with an office computer (in the Physical Computer Management window) where they might enter feed manually when a truck has broken down. This isn't strictly necessary, but it is helpful to distinguish manually built loads in the office from normal loads and this is one way of doing that.
You will create your own list of drugs in Fusion, naming them however you like. Fusion expects that implants are included in the list of drugs. When you define a drug you will need to tell Fusion a few things about it so it knows how to do things like calculate dosage and withdrawal times.
With Fusion you define your own list of inputs that can be given to animals. An input is basically a catch all term for items that need to be billed but that don't fit into the regular drugs, feed, yardage, etc. categories. Inputs range from salt and bedding that are given to whole pens to items that are given to individual animals during a chuteside job such as a chute charge or a tag charge.
Note that it is also possible for an input to be linked to a commodity for inventory tracking purposes. For example, you might feed straw as an ingredient, but also use it as an input for bedding. By linking these, Fusion will know to reduce the straw inventory level even when it is used for bedding.
You can also distribute inputs in one unit (such as bales for bedding) and bill for it in another unit (such as tonnes for bedding). There is an Equivalency attribute which you use to tell Fusion the relationship between the two units is for any period of time. Fusion can then convert the number of bales used to tonnes (or whatever units you have) for billing purposes. (If you do not make an equivalency attribute for an input in a time period, Fusion will assume a 1:1 relationship regardless of the actual units you have entered for the input.)
Drugs and inputs can be assigned a billing category each time they are used. In many places where drug and input usage is shown in Fusion, the usage can be rolled up into these categories. When you define a drug or input, you can assign it a default billing category which will be used when a drug or input event is created without a billing category specified. Normally, however, you would specify the billing category directly. For example, when setting up a chuteside job where a drug or input is used, there are several ways of managing which billing category will be assigned to each drug or input event.
A drug or input can fall into multiple billing categories.
Lots can be assigned a cattle type to be the default for the entire lot. Animals can also be assigned an individual animal type. You create your own list of possible cattle types which are used to generally classify the cattle in your feedlot for comparison purposes. Example types would be Fall Placed Calves, Winter Placed Calves, and Yearlings.
We strongly encourage you to figure out the possible cattle types you want to deal with before you get too far into the setup since there are some things (treatment protocols, for example) which rely on this list that will be a lot of work to update if this list is changed down the road.
Breeds can be assigned to a lot as the lot default. They can also be assigned individual animals. You can create your own list of breeds.
Colors can be assigned to a lot as the lot default. They can also be assigned individual animals. You can create your own list of colors.
You can create your own list of death causes from which you can pick when you create a death type out cohort. Many people get a list from their vet to use.
There are several places where you can track the source or buyer for groups of cattle. On the lot level, you can enter the originating herd and buyer. The originating herd field is meant to record the name of the ranch the cattle originally came from. The buyer field should refer to who put the cattle together for your purchase. If you do enter a buyer for the lot before the first chuteside job, Fusion can be set up to automatically set each animal's source field to be the same as the buyer for the lot.
When a lot is made up of cattle from different sources, you can use the buyer, source, and originating herd fields in each in cohort to track this information on a cohort level. Any information entered at the in cohort level is only useful at that level.
Each animal can have a different source tied to it as well.
For the most part, Fusion doesn't attach any significant meaning to any of these fields beyond giving you a place to record this kind of information, so you can use them however you see fit.
When an animal is in a chuteside job for treatment, the first step is to diagnose the animal. Once this is done, Fusion will look at several of the animal's characteristics (ex. weight and days on feed) and recommend a specific treatment protocol for the animal. A treatment protocol specifies what drugs (if any) should be given during each day of the treatment period.
In Fusion you make your own list of possible diagnoses. Then, for each diagnosis, you will feed it the information it needs to know what the treatment protocol should be under various circumstances. This is normally done under the direction of a vet.
In general, the more information you give Fusion about how to treat animals in various circumstances, the more accurate its recommendations will be. If you are finding that Fusion is consistently recommending the wrong treatment protocol in a situation, we encourage you to make changes to the diagnosis definition so that Fusion gets "smarter" over time.
Fusion's general expectation is that an animal in treatment will be brought through the chute once per day every day during the treatment period. You should not try to treat an animal multiple times in a day or Fusion may become confused. If you skip a day's treatment, and if no drugs needed to be administered on that day (ie. it was an "observe" day), Fusion automatically creates an "observe" treat event for the day. These treat events will not have a user associated with them and will have a note explaining they were automatically generated. This is helpful for places that don't want to run animals through the chute every day if they don't actually need drugs administered on that day. However, if the animal should have been treated with a drug, the next time the animal comes through the chute to be treated Fusion will assume you are still on the day that was skipped.
Ingredients, drugs, inputs, cattle weight classes, and water meters all have attributes associated with each of them. For example, ingredients attributes include dry matter, NEM, NEG, protein, and cost and bill at prices. Each of these attributes will change over time. For example, the bill at price for an ingredient will change over time, probably month to month.
Fusion keeps a history of each attribute for each item at each location and how it has changed over time. For example, if Fusion was calculating the price of an ingredient on a certain day it would look at the history of the price attribute for that ingredient and figure out which price to use for that date.
The date an entry is made is important. It tells Fusion that this is the new value for the attribute from that date forward. It will continue to be the value for that attribute until an entry with a later date is made.
To be clear, if you were doing your billing at the end of October and were updating the pricing of ingredients, you would create new attributes for the beginning of October because you want these prices to take affect for the month of October, not November.
Of course, you can change any of the attributes many times throughout the month and the billing will reflect this.
You can add a new attribute change (or edit an old one) using the options under the Fusion Core → Attributes menu. This is fine if you are changing one or two attributes, but normally you'll change a whole bunch of attributes at the same time—during monthly billing, for example. In that case it will be easier to use the Bulk Attribute Change window. This window still creates individual attribute change records as if you did it manually one at a time, but has a different interface for faster entry.
| When you make attribute changes, make sure you are changing the correct attribute. We have had several reports of Fusion asking for very odd ration formulations after someone in the office changed the bill at values for ingredients, only to find out they actually changed the dry matter percent by accident instead! |
Fusion keeps track of the inventory levels of commodities, drugs, inputs, and cattle. The following information describes how the inventory system works.
It is possible to view usage related inventory in Fusion, both on a location and a lot level. This information is available in the Feedlot Usage Report and by looking at the detail area of the Lot Center window. Usage information can be dissected in various ways and is useful to view inventory from the point of view of what was actually consumed and billed for from the lot level and on up.
The inventory functionality, on the other hand, deals only with the higher level location based inventory which handles the flow of items both in and out of the feed yard. The distinction is important for two reasons. First, depending on the kind of information you are looking for, you might need to look at usage information or inventory information. Second, Fusion always calculates usage information by looking at what an individual lot consumes for one day (for an item), rounding the values at that point, and summing across days and then lots as necessary. Inventory is calculated by looking at the flow of an item for an entire location for a day before rounding. Thus, if you were to compare inventory values against usage values for similar items and similar time periods it is possible that the results do not exactly coincide. Keep in mind that the two methods, of necessity, round at different times and frequencies during calculations. Inventory is good for high level information and usage is good when you need to break down consumption by cattle type, buyer, sex, etc.
There are other slight differences as well. For example, ingredient usage is based on feed deliveries to pens while inventory is based on the ingredients added to a load. Also, usage must always be calculated at the moment it is needed where inventory is kept up to date all the time.
As just mentioned, unlike usage information, Fusion keeps inventory information for commodities, drugs, and inputs up to date all the time. (Cattle inventory is calculated on the fly when needed.) The mechanism it uses to do this is to watch for events that trigger an inventory adjustment and then send a message to the server to process the event. When the server receives such a message, it places it is a queue to be processed in the same order it was received.
Most of the time items in the queue are processed within two to five seconds of the event that triggered the mechanism, meaning you should expect to wait that long before you see inventory adjust itself. However, there can be times when there are many items in the queue waiting to be processed and it can take longer for the inventory values to catch up.
You can see how many items are currently in the queue by viewing the Inventory Queue window. This window updates the queue count about every two seconds. It can also be used to force the complete recalculation of inventory for an item or items from a particular date onward. This should not normally be necessary, but if a bug in Fusion caused the inventory to not be updated when some event triggered, you could use this window to periodically tell Fusion to recalculate a period of inventory flow until the bug is fixed.
The following events will trigger the inventory engine to recalculate the inventory for affected items and date ranges:
Inspecting a record in the Daily Commodity Inventory, Daily Drug Inventory, or Daily Input Inventory windows will show a window detailing all the triggers that affected the inventory flow for the selected item/location/date. Double-Clicking events in this window will take you to the event itself. Inspecting items like this should be the first step in figuring out what is wrong if an inventory value is not correct.
The Inventory Summary window is most often used to view inventory information. However, the Daily Inventory windows for commodities, drugs, and inputs can be valuable when you want to create your own reports, especially if they need to link to or from other reports. These windows can also be used to see the flow of inventory for a particular item over time as well as inspect the details of inventory change as explained in the previous section.
You can lock the beginning balance for an item/location/date combination and specify a quantity to lock. When a beginning balance is locked, you can specify the exact quantity to begin with on that day and changes that happen previous to that day will not flow past the locked balance. Generally, balances are locked when a real inventory is taken. You could either lock the balance to the known inventory level directly, with no explanation, or you could create an adjustment offset with an explanation and then lock the resulting balance. Both have the same effect, but the latter may be better for record keeping.
The Daily Inventory windows allow you to select a row and lock the balance from there. You can also unlock a previously locked row from these windows as well. When this happens, inventory previous to the (now) unlocked date will ripple past if appropriate.
If you will be locking many items at the same time, you will want to use the Bulk Lock Inventory window.
You can create inventory offsets for commodities, drugs, and inputs. An inventory offset is a manual change in quantity of an item for one of three reasons:
Commodities have a way of automatically recognizing increases in inventory levels through scale tickets. However, there is no such mechanism for drugs and inputs. Thus, offsets should be used to account for drugs and inputs being purchased.
Sometimes an item comes to or leaves a location for another purpose. You might sell some of your silage to a neighbor. You might move a quantity of an item from one location to another. Perhaps you mix ingredients together and then feed them as one ingredient. Any of these examples would need to be accounted for by creating the necessary inventory offsets.
When you create an offset you can also associate the offset with a contact and you can override the day's pricing for the specified amount. These are optional and are provided for more accurate record keeping.
It can make sense for several inputs to be linked to commodities for inventory purposes. For example, you might purchase straw as a commodity and feed part of it as an ingredient, but also use part of it for bedding. In this case you could link the straw bedding input to the straw commodity.
You link an input to a commodity through the New Input Attribute window, choosing Inventory Link. You can also unlink an association later on so that the link is only valid for some date range. As with other attributes, this can be done historically and the appropriate changes will occur. You should not link multiple inputs to the same commodity for the same time period, nor should you link an input to multiple commodities during the same time period.
When an input is linked to a commodity, Fusion will assume that the input's billing unit is the same as the commodity's billing unit (usually tonne). Since inputs are given based on the distribution unit, this means that the input's Equivalency attribute will affect the inventory levels as well, so make sure this is all set up correctly.
During an association, any usage of the input will affect the commodity's inventory instead of the input's inventory. New quantities of the inventory during that time are allowed, but wouldn't normally make sense—it is expected that new quantities are applied to the commodity instead.
When defining commodities, drugs, and inputs through Fusion Admin → Setup, some additional, location specific options are available and need to be considered to make the inventory functionality more useful to you.
The Threshold value is the quantity where, if the inventory goes below this level, you want to be warned. When using the Inventory Thresholds window, items will show up in red if they are within so many days of this threshold. To determine how many days it will take to hit the threshold, Fusion will look at the past few days of usage to determine an average usage amount, and then project that amount into the future to determine when the threshold will be met.
For commodities that are used every day, it is probably sufficient for Fusion to look at the past three to seven days to determine the average usage per day to project into the future. Other items, like seldom used drugs, may need to average a month or even a year of usage to project with any degree of accuracy. You can set the number of days Fusion uses for each item at each location by adjusting the Avg Usage Days value.
The Maximum Capacity value can be used to let Fusion know what your capacity of a certain item may be. Percentage of capacity is shown in the Inventory Thresholds window and you can use it in your own reporting if it is important to you. Leave it at zero if not.
Inputs have an additional option that is not location specific. It doesn’t make sense to track inventory for some inputs like chuteside charges. You can turn inventory tracking off for these inputs. The tracking still occurs internally, but most lists won’t show these items.
The Markup Type value is where you define the markup method Fusion will used when calculating the Bill At price based on the Cost price if you used the Defined Markup Formula functionality in the Bulk Attribute Change window. This is an optional way of doing your monthly pricing and is explained more in Bulk Attribute Change Window.
The Markup Amount value is the value percentage or dollar value to use if the markup type is being used.
These are the main windows for viewing and reporting on inventory. The Inventory Summary is where you can see current inventory levels as well as inventory changes over different time periods along with the associated value of the inventory. You can also design reports to print this information. The Inventory Thresholds window is used to give you a heads up when inventory levels are getting low for certain items.
All inventory pricing is based on Cost, Market Value, and Bill At attributes for commodities, drugs, inputs, and cattle weights. It might be assumed that commodity pricing might be automatically based on commodity contracts, but this is not the case. Most people set their Cost attribute for commodities for the previous month at the end of the month and Fusion can make sure this cost reflects the commodity contract pricing. Once the cost, and other attributes are updated, even for the past, affected inventory pricing will be updated. The only exception to this is that pricing for individual offsets can be overridden.
While Fusion does its best to track inventory levels accurately, there are several things that can happen to affect the accuracy. For example, if a truck's load cells are not calibrated correctly, Fusion will record incorrect weights when ingredients are added to a load on that truck.
When you suspect there may be an error in inventory tracking, there are two things you should do to start with.
Once you have done step 1, use the Daily Commodity Inventory, Daily Drug Inventory, or Daily Input Inventory windows and find the item on the date you have identified. You can then inspect the item to see what changed the inventory for that day. This is where you need to identify what event caused the mistake. Was it a truck load? A scale ticket? An offset?
If the cause still isn't apparent, find other days you know the error occurred on and inspect them as well. Remember to Double-Click events in the Inventory Inspector window to learn more about each event. Eventually a pattern should emerge.
Once you have figured out the pattern, you should be able to find the root cause and fix it.
In Fusion we do things on a dry matter basis as often as possible. In the past, many feedlots made bunk calls, formulated rations, and handled other matters on an as fed basis which required less calculations. Since Fusion can automatically perform the necessary conversion calculations, the benefits of doing things on a dry matter basis instead of an as fed basis for many things make it worth switching, even if it takes some time to get used to it.
Darryl Gibb, a nutritionist and partner of Fusion Feedlot Insights, posted a blog article entitled Switching to Dry Matter Based Feeding to help feedlots understand the value of using dry matter basis. Part of it is included below and we encourage you to read then entire article.
Moisture is a worthless, confusing component of all feed ingredients. Because it is has no value, moisture has a big (but often hidden) impact on the accuracy and economics of feeding cattle. Most feedlot diets contain high moisture ingredients such as silage, therefore moisture levels need to be considered when formulating diets and making bunk calls. We are so used to working with the moisture in feeds, we often don't appreciate how it inflates value and complexity. Most feedlot nutritionists balance nutrients and ingredients with moisture removed (dry matter basis). Most additives are cleared to be fed at a specified concentration of the dry matter. Intakes of cattle are limited primarily by dry matter content of the diet.
Working with dry matter is unfamiliar to most feedlot managers. However, once accustomed, working with dry matter is actually simpler, especially since calculations are automatically done by Fusion. In the following discussion, AF = "As Fed" (what is actually fed). DM = dry matter (all moisture removed).
…
At a typical feedlot that makes bunk calls as total pounds AF, bunk calls can vary by over 2-3 fold across pens. This variance is due primarily to differences in head count and ration moisture. Obviously, if a pen has twice as many cattle in it, it will require about twice as much feed. Similarly, rations with vastly different moisture content will have large differences in pounds AF required. For example, if potatoes were introduced in a finishing diet, AF (but not DM) intake would suddenly increase due to the high moisture content of potatoes. As well, as cattle are stepped-up on feed with reducing levels of silage, AF intakes may decline. Although other variables such as animal size and energy content/digestibility influence intakes of a pen, the primary factors are animal numbers and moisture content. Making bunk calls as pounds of dry matter per animal removes these variables so bunk calls are more meaningful and consistent across pens. The value of working with dry matter is amplified when feeding high moisture products like silage and potatoes.
We strongly encourage you to make the necessary effort to think and use a dry matter basis for feed related things. We also recommend taking a look at Dry Matter Tutorial Window for help in understanding this topic.
Feeding protocols give you a way of defining how animals move through a series of rations based on predefined conditions. They can also aid in increasing the amount fed throughout the feeding period in order to maximize growth. You would typically have one feeding protocol for each type of cattle you feed. It is possible to use Fusion with or without these protocols. See Feeding Protocols for more information.
Saved variables can be a real time saver when working with saved searches and advanced print reports. A saved variable is a placeholder for a value which can be referred to from other places in Fusion. When the value is changed, anything referring to it will then use the new value.
A saved variable has a name, a type, and a value. The name must be unique and this is how you refer to it from other places in Fusion. The type refers to what kind of value the variable can hold and must be one of the following:
Saved variables are stored on the server and can be accessed from any client. This means that any user can change a saved variable and the change will be seen by everyone else using it.
Fusion comes with a few built in saved variables. You can change the value of these variables, but you can't rename or delete them. The name of these variables will always start with SSGi_ and are listed below.
One of the more powerful features of variables applies to date type variables. You can set a date type variable to a specific date, but you can also set it to a relative date. For example, if you set it to First of Previous Month, Fusion would figure out the date of the first of the previous month each time the variable was referred to. This makes it easy to setup saved searches, for example, that always find the correct data for a report regardless of when it is run without having to manually change the dates.
Saved variables are most typically used in an advanced find (see Advanced Find Window) and in advanced print reports (see Advanced Print Definition Window). They can be changed directly with the Saved Variables window (see Saved Variables Window) as well as in the Advanced Print Center window (see Advanced Print Center Window).
