Lot Info Export Window

Fusion provides the capability to automatically export information for selected lots and associated information each day. This information can then be imported into other software applications or services. This allows these services to always have an up-to-date and accurate context within which they can work while remaining distinct from Fusion. This window is used to set up the automatic export of this information to one or more services.

Each service you send information to is referred to as a destination in this window. For each destination that you create, you can decide which locations to set up (each location will have its own set of files that are sent) and which lots to include. You will also set up where the information is sent to and what kinds of information is included in the files.

Setting Up a Destination

To add a new destination, click the + button below the Destination list. You will be asked to name the destination. (To remove a destination, select it and click the - button. Fusion will delete the destination and stop sending information to it.) With the destination selected, you need to decide which locations will be included when sending information. Check the Include checkbox next to each location you want to include.

The rest of the settings apply to individual locations, so make sure the correct location is selected in the Location list before making more changes.

Included Lots Tab

  • Destination Yard Account. If the service that is consuming this information has an account number of some type that identifies this location, you can enter it here and it will be sent in the export. Whether this field is used is up to the consuming service, so you will need to ask them if something should be entered here.

When Fusion exports data to send each night for this location, it will only include lots that are in the list in this tab. This gives you control over what information is sent. You can manage this list manually using this tab as explained next. There is also a way to have Fusion automatically manage this list and this is described later in this topic (see the Auto Adding Lots Tab section).

The list shows the name of the lot and its current status (open or closed). To add a lot to the list, click the + button. The Lot field will be revealed so that you can enter the name of the lot to add.

If you want to add several lots at the same time, you may be able to use the Add New Lots… button which will show a menu with two options. The first, Add Open Lots Not Already Added, will simply make sure that all open lots for the location are in the list. The other option, Apply the Rules in the Options Tab, will apply the rules you set up so that Fusion can automatically manage this list. Normally these rules are applied each night, but you can use this option to test that the rules are working right when you first set them up. These rules are described more later in this topic.

To remove a lot, select it in the list and click the - button.

When you select a lot, the Owner list to the right of it will list the lot's current owners. By default, Fusion includes information for each owner in the file. If you would prefer that this information is not sent for certain owners, you can uncheck them in this list. It is also possible that the service that is consuming this information may have an account ID for each owner of a lot. If that is the case, select an owner and enter their ID in the Owner Account for This Destination field. Fusion will remember this ID for that owner so if the same owner has ownership in a different lot at this location, you won't have to enter it in every lot.

Auto Adding Lots

These options can be used to have Fusion automatically manage the list of lots that will be included in the export each night. Fusion will run these rules each night before creating the file, adding and removing lots based on the rules. This frees you from having to manage the included lots list manually. Be aware, though, that if you have to remove certain owners from each lot, you should still do this manually as Fusion will assume all owners should be included when it automatically adds a lot.

  • Automatically Add New Lots When They Open. If this option is turned on, Fusion will add new lots to the list when they are created. This is useful if the service needs information about lots while they are open
  • Automatically Add New Lots After. If this option is turned on, Fusion will add lots after they have been closed for the number of days you entered. This is useful if the service only wants information about lots after they have closed. If they only want information about lots once all the billing has been figured out, you might enter a larger number here (maybe 14 or 21 days) to ensure that everything has been entered before it is added to the list.
  • Automatically Remove Lots After. You don't want lots to stay in the list forever. The file size becomes too large and, once the lot has been closed for a while, Fusion would continue to send the exact information for the lot every night forever. So lots should be removed from the list after a time. If you turn this option on you can specify that lots are automatically removed after they have been closed for a certain number of days.

If you have a lot that Fusion keeps trying to automatically add that you don't want in the list, go to the Included Lots tab, find the lot in the list, and Right-Click it and choose Don't Auto Add This Lot. Fusion will now ignore this lot when it applies these rules each nigh.

Auto Send Setup Tab

This tab is used to tell Fusion where these files should be sent each night. The files can be sent to an FTP site or (if using the legacy format) sent as an email. You will need to learn from the service you are dealing with which option you should use and what you should enter in each setup field.

  • File Format. Two file formats are supported. The Legacy format was the first one Fusion supported and continues to work, although no new changes will be made to it. The Second Generation format was introduced in Fusion 3.5 and has the ability to export a greater amount of information. You will need to ask the service consuming these files which format they need. See the File Format section below for more information if you are a service developer.
  • Filename/Folder Name. If you are using the legacy format, enter the name that will be used for the file that is created each night. For the second generation format, you should name the folder that will contain all the exported files. For either format, if you need a name that is somewhat different each night, you can enter <date> as part of the name and it will be replaced with the date of the export in this format: YYYYMMDD. You can also enter <time> as part of the name and it will be replaced with the time the files are created in this format: HHMMSS. Note that this name is usually supplied by the service you are connecting to. (Don't use and / characters in this field.)
  • Zip File. This option only appears when the legacy format is chosen. The legacy file can become very large, especially if a lot of animal level data is included. If the service supports it, we strongly recommend turning this option on. Fusion will then compress the file using the common ZIP format before sending it. This is especially important on slower internet connections. (The second generation format always zips files before uploading them.)

If the service wants the file to be uploaded to an FTP site each morning, check the Upload to destination via FTP every morning checkbox and then fill in the associated fields using information the service supplies. The URL field will be something like ftp://ftp.somedomain.com or ftps://25.25.25.25 and should not end with a / character. The Path field can either be blank or be just a / character if the export will be at the top level of the FTP site. To place the export in a subdirectory, use this pattern in the field: /Directory1/Directory2/Directory3 (note there is no trailing / character).

If you check the Use SSL checkbox, please be aware that Fusion will use FTPS (FTP over SSL/TLS). Don't confuse this with SFTP which is a different protocol related to SSH.

If the service wants the file to be emailed instead, check the Send to destination via email attachment every morning checkbox and then fill in the Send To Address with the email address the file should be sent to. (Note that this option is only available if you have chosen the legacy format.) When the email is sent, it will be from Fusion Auto Email <autoemail@ssgfusion.com>

Manually Export Tab

If you need Fusion to generate the files and send them immediately, you can do so in this tab. This can be useful for testing the files or that different delivery methods work. It may also be necessary if errors occurred making it impossible for Fusion to deliver the files during the night. If the errors have been corrected and it is necessary that the files be sent before the next morning, they could be sent manually here.

  • Save As A File…/Save As Files…. This option can be used if you want to see the file(s) contents yourself. You will be asked where to save the file(s) and Fusion will generate them and save it to that location using the file/folder name you specified in the Auto Send Setup tab. This option can also be used if the FTP and email options are not working. You could save the exported files to your Desktop and then email them to the service yourself.
  • Send via FTP. Fusion will generate the files and the attempt to FTP them using the FTP settings you set up in the Auto Send Setup tab.
  • Send via Email. Fusion will generate the files and the attempt to email them using the email settings you set up in the Auto Send Setup tab. (Emailing is only available when the legacy format is being used.)

Options Tab

In this tab you can decide what information is included in the export. The exact options will be different depending on which file format you have chosen. Normally you will need to find out from the service which blocks they require and turn them on.

The Automatic Export and Error Handling

Each morning, shortly after midnight, Fusion cycles through each location you have included in each destination, creating an export based on the information you want included for each and sending it to the destination. If all goes well, the service will see the file and use the information in the file to update their service. If Fusion runs into an error (for example, if the internet is not working), Fusion will send a system message to you explaining the upload couldn't work and include the error message. In most cases this isn't a big deal because Fusion will just try again the next night. However, if timing is sensitive, or if you keep getting the same error several days in a row, you will need to figure out what is causing the error and correct it. You may also need to manually send the information from the Manually Export tab.

The most common causes of errors are:

  • Incorrect setup in the Auto Send Setup tab.
  • Incorrect setup for receiving the file on the service's end.
  • Your internet not working at the time Fusion tries to send the file.
  • The service's internet not working at the time Fusion tries to send the file.

Known Public Services

We are aware of the following public services that can receive Lot Export Files from Fusion:

Please note that it is possible to use these files for yourself as well. If you have software (or can create software) that will read in the exported files, you can then use it to do further analysis on your own data.

Getting Here

You can open this window by going to Fusion Office → Yard Reports → Lot Info Export.

Third Party Service Developer Information

The following information is for developers who need to consume the files Fusion exports. As mentioned above, two file formats are supported. If your service is using the Legacy format, details on the internal format can be found in this PDF. However, please note that while we continue to support this file format, we will not be enhancing it in the future.

If your service will be using the Second Generation format, please see the details below.

Second Generation Format Developer Information

File Structure

An export is broken into multiple files. This makes it easier to create and parse an export in an environment where resources may be limited and makes it easier to add new types of information to the export in the future. Each file is a JSON file (.json). If the files are being uploaded to an FTP site, each file will be zipped first so the file extension will become ".json.zip" for each file. The meta file (Meta.json)is always created and uploaded last, so if you are sweeping an FTP folder for a new export, you can check for the presence of the meta file to determine if all related files have been uploaded.

The type of most of the keys described below is self explanatory. In the raw JSON, boolean fields will be "true" or "false". Date fields will be in the format "YYYY-MM-DD" and an empty date will be "0000-00-00". Time fields are in the format "HH:MM:SS" and an empty time will be "00:00:00". Timestamps will be in the format "YYYY-MM-DDTHH:MM:SS". All UUIDs are 36 characters in this form: "C33897AD-A5D6-4BF2-BB10-2C3E7F6D2555".

Each type of file that can be exported is described below, including each of the keys in the file.

Meta File

The meta file will be named Meta.json. This file contains general information about the export, lists of all associated files in the export, and additional meta data for objects that are referenced from other files such as contacts and ingredients. It is always created and uploaded last.

Following is a list of keys and subkeys found in the file:

  • FileCollectionUUID. Since there are a group of files which are all part of the same export, a UUID is used in this key for every file to keep them together.
  • Creator. The name of the software used to create the files. It will always be "Fusion".
  • CreatorVersion. A string version of the software used to create the files.
  • FileDefinitionVersion. A number representing the version of these files. Currently 1.
  • CreateTimestamp. When this file was created.
  • SnapshotTimeStamp. The moment in time that the data in the file is valid for. Usually midnight of the previous day.
  • YardName. The user entered name for the feedlot or feedlot location if multiple locations are owned by the same entity.
  • YardUUID. A way of uniquely identifying a yard even if the YardName is changed.
  • DestinationYardAccount. Used to coordinate your service with the feedlot software. If you give each yard an ID of some type, this element can contain that ID for your reference.
  • Units. These subkeys express what units the values in the files will be in.
    • AnimalWeightUnit. “lb” or “kg”. Used for animal related weights.
    • FeedingWeightUnit. “lb” or “kg”. Used during feeding including making loads and delivering rations.
    • CommodityPricing. “t” (metric tonne) or “tn” (short ton). Rations and commodities are billed in this unit.
    • CommodityDelivery. “lb” or “kg”. Reserved for future use.
    • NetEnergyNumerator. “Joule”, “ThermoCalorie”, "BritishThermalUnit", "KiloCalorie", or "MegaCalorie". For the NEM and NEG of ingredients.
    • NetEnergyDenominator. “lb” or “kg”. For the NEM and NEG of ingredients.
    • TempUnit. “F” or “C”. The unit an animals' temperature is taken in during a chuteside job.
    • AnimalPricing. “lb” or “kg” or "cwt". Applies to animal pricing and is "currency per this unit".
    • HeightUnit. “in” or "cm" or "mm". Applies to animal hip height.
    • BackfatThicknessUnit. “in” or "cm" or "mm". Applies to animal backfat thickness for ultrasound and carcass.
    • RibeyeAreaUnit. “sqin” or "sqcm". Applies to ribeye area for ultrasound and carcass.
    • PenDensityUnit. “ft” or "m". Pen density measurements will be in "animals per this unit".
    • BunkDensityUnit. “in” or "cm". Bunk density measurements will be in "animals per this unit".
  • AssociatedFiles. There can be many files that are part of this export. The following subkeys contain arrays of filenames that are part of the export so you can check to make sure they are all there. Note that if the filenames listed here are as they were when they were created. If they were zipped before being uploaded, the ".zip" that was appended will not be in these lists. We recommend either unzipping all files first, stripping the ".zip" extension, or just coding with this understanding if you want to look at them in their zipped state.
    • Lots. Each lot included in the export will have its own file. The filename will be based on the lot's UUID in this pattern: LotUUID.json. An example filename would be: C33897AD-A5D6-4BF2-BB10-2C3E7F6D2555.json. This key is an array of filenames.
    • Pens. Each pen included in the export will have its own file. The filename will be based on the pen's UUID in this pattern: PenUUID.json. An example filename would be: E33297BD-B5D6-4BF2-CA10-2C3E7F6D2472.json. This key is an array of filenames.
    • FeedLoads. If the user is exporting feeding loads, there will all be in a file named FeedLoads.json. If this file exists, this key will be true. Otherwise it will be false.
    • IngredientAttributes. If the user is exporting attribute history for ingredients, there will all be in a file named IngredientAttributes.json. If this file exists, this key will be true. Otherwise it will be false.
    • DrugAttributes. If the user is exporting attribute history for ingredients, there will all be in a file named DrugAttributes.json. If this file exists, this key will be true. Otherwise it will be false.
    • InputAttributes. If the user is exporting attribute history for ingredients, there will all be in a file named InputAttributes.json. If this file exists, this key will be true. Otherwise it will be false.
  • AssociatedItems. The main export files often have keys in them that simply reference something else. For example, a lot file will have ownership keys that describe who owns the lot. The lot file itself will simply reference an owner using the owner's contact UUID. If the feedlot chooses to include contact information in the export, any contact that is referenced in any of the exported files will also be included in this meta file with additional information about the contact. This is true of ingredients, rations, etc. It is guaranteed that the UUID of an item in any of the export files will never change. Note that the feedlot can choose to include or exclude any of the groups of associated items.
    • AnimalCustomIDs. If animals are included in the export, a mapping for the custom ID field labels is included here.
      • CustomID1. The label the feedlot has assigned the first custom ID field.
      • CustomID2. The label the feedlot has assigned the second custom ID field.
      • CustomID3. The label the feedlot has assigned the third custom ID field.
      • CustomID4. The label the feedlot has assigned the fourth custom ID field.
      • CustomID5. The label the feedlot has assigned the fifth custom ID field.
    • Contacts. An array of contacts which are referenced in other places in the export, each with the following keys.
      • UUID. The contact's UUID.
      • DestinationAccount. Used to coordinate your services’ ID code for this contact if it is an owner and if you have one.
      • Name. The name of the contact as entered by the user.
      • Address. The address of the contact. Can be multiple lines.
      • City. The city of the contact.
      • State. The state of the contact as entered by the user. Not necessarily limited to just two characters.
      • Country. The country of the contact.
      • ZipCode. The zip or postal code of the contact.
      • PrimaryPhone. The contact’s phone number.
      • PrimaryEmail. The contact’s email address.
    • Ingredients. An array of ingredients/commodities which are referenced in other places in the export, each with the following keys.
      • UUID. The UUID of this ingredient.
      • Name. The name of this ingredient
      • CurrentAttributes. These subkeys contain the current (as of SnapshotTimeStamp) values of various attributes associated with the ingredient.
        • DM. The dry matter percentage (0-100).
        • NEM. The NEM value in NetEnergyNumerator per NetEnergyDenominator units.
        • NEG. The NEG value in NetEnergyNumerator per NetEnergyDenominator units.
        • Protein. The protein percentage (0-100).
    • Rations. An array of rations which are referenced in other places in the export or are considered current rations, each with the following keys.
      • UUID. The UUID of this ration.
      • Name. The name of this ration.
      • Versions. A ration will have several versions as the composition changes over time. This is an array of this ration's versions that are referenced in other places in the export or are the current ration version, each with the following keys:
        • UUID. The UUID of this ration version.
        • VersionDate. A ration version is known by its date. There can only be one ration version per day for each ration.
        • Basis. "DM" or "AF" depending on whether the formulation is on a dry matter or as fed basis.
        • Formulation. An object array specifying the ration formulation. Each object has the following keys:
          • IngredientUUID. The UUID of the ingredient.
          • Percent. The percentage of the ration for this ingredient (0-100).
    • Drugs. An array of drugs and implants which are referenced in other places in the export, each with the following keys.
      • UUID. The UUID of the drug.
      • Name. The name of the drug.
      • Units. The units of this drug. Possible units are: cc, ml, liters, bolus, implant, package, dose, and unit.
    • Inputs. An array of inputs which are referenced in other places in the export, each with the following keys.
      • UUID. The UUID of the input.
      • Name. The name of the input.
      • DistributionUnit. The unit this item is distributed in. The feedlot defines the possible units.
      • BillingUnit. The unit this item is billed in. The feedlot defines the possible units.
    • Diagnosis. An array of diagnoses which are referenced in other places in the export, each with the following keys.
      • UUID. The UUID of the diagnosis.
      • Name. The name of the diagnosis.
    • Pens. An array of physical pens which are referenced in other places in the export, each with the following keys.
      • UUID. The UUID of the pen.
      • Name. The name of the pen.
    • Trucks. An array of trucks which are referenced in other places in the export, each with the following keys.
      • UUID. The UUID of the truck.
      • Name. The name of the truck.
    • Users. An array of users which are referenced in other places in the export, each with the following keys.
      • UUID. The UUID of the user.
      • Username. The username of the user.
    • FeedingProtocols. An array of feeding protocols which are referenced in other places in the export, each with the following keys.
      • UUID. The UUID of the protocol.
      • Name. The name of the protocol.

Lot Files

All the information for a lot is contained in one file, so there will be multiple lot files, one for each lot being exported. The name of each file is referred to in the Meta.json file and will be in the form Lot-<uuid>.json (ex. Lot-C33897AD-A5D6-4BF2-BB10-2C3E7F6D2555.json). The lot file can have the following keys in it:

  • FileCollectionUUID. All files that are exported together have the same UUID in this key so the consuming service can know they belong together.
  • Lot. The basic information available about a lot is found in this key.
    • UUID. The UUID of the lot.
    • Name. The name of the lot as defined by the user. The user can change this, so use the UUID attribute instead of the name for the primary key.
    • LotStatus. Open or Closed.
    • Sex. Male, Female, or Mixed.
    • CattleType. The user can define any number of cattle types so you may need to map their choices to your internal list if necessary. Common cattle types are Yearlings, Fall Placed, Winder Placed, etc.
    • BreedLabel. The default breed for this lot. The user can define the list of breeds.
    • ColorLabel. The default color for this lot. The user can define the list of colors.
    • BuyerUUID. A link to the buyer’s contact UUID.
    • OriginatingHerdUUID. A link to the originating herd’s contact UUID.
    • FirstDateIn. The date the first animal was placed in this lot.
    • AvgDateIn. The average date of all the animals placed in the lot.
    • LastDateOut. The day the last animal left the lot and the lot closed. This will be a blank date (0000-00-00) until the lot closes.
    • AvgDateOut. The average date of all the animals leaving the lot. This includes death out cohorts.
    • LotDays. The number of days the lot has existed, starting from the average date in.
    • WithdrawalDate_Drugs. The lot’s withdrawal date, based on drugs.
    • WithdrawalDate_Feed. The lot’s withdrawal date, based on feed.
    • WithdrawalDate_All. The lot’s withdrawal date, based on drugs and feed.
    • TargetSlaughterWeight. Target slaughter weight which is entered by the user.
    • TargetSlaughterDate. Target slaughter date which is entered by the user.
    • CustomField1. The user can define up to five custom fields for whatever they want to track.
    • CustomField2.
    • CustomField3.
    • CustomField4.
    • CustomField5.
    • Note. Any notes about this lot.
    • TotalInCount. Total in count of animals.
    • TotalInWeight. Total in weight of animals (AnimalWeightUnit).
    • TotalInDollars. Purchase dollars.
    • InCohortsAreOverriden. The in count, weight, and dollars should normally be the same as the same of these values from the InCohorts section (if included). However, the user has the ability to override the in cohort values if they want. This field will be True if they are overriden or False if not.
    • TotalDeadCount. Animals that have died.
    • TotalDeadWeight. Total weight of animals that have died (AnimalWeightUnit). Usually this is an estimate of their weight at the time of death.
    • TotalOutCount. Animals that have left the lot, not including deaths.
    • TotalOutWeight. Total weight of animals that have left the lot, not including deaths (AnimalWeightUnit).
    • TotalOutDollars. Total dollars the animals have been sold for.
    • OutCohortsAreOverriden. Similar to InCohortsAreOverriden, the out cohort values can be overriden.
    • CurrentCount. The number of animals currently in the lot. This will be zero if the lot is just starting or if it is closed.
    • CurrentTotalWeight. The estimated total weight of the animals currently in the lot (AnimalWeightUnit). This will also be zero if the current count is zero.
    • TotalHeadDays. The total number of head days for the lot.
    • TotalDMConsumed. The total units of feed, on a dry matter basis, consumed by the lot (CommodityPricing units). It will be in the same units specified in the FileInformation block.
    • TotalCostToDate_Feed. Total dollars billed toward feed by the lot.
    • TotalCostToDate_Drugs. Total dollars billed toward drugs by the lot. This includes implants.
    • TotalCostToDate_Inputs. Total dollars billed toward inputs by the lot. Inputs include things like salt, bedding, chute charges, etc. and are defined by the user.
    • TotalCostToDate_Yardage. Total dollars billed from yardage for the lot.
    • TotalCostToDate_OtherItems. Total dollars billed from any items that don’t fit in the above categories.
    • TotalCostToDate_Interest. The interest attributed to the lot so far, based on individual owners’ interest rate and ownership percentage.
    • CurrentBreakEvenPerUnit. The actual break even to date (per AnimalWeightUnit).
    • TotalCost. This is the total dollars into the animal during its stay in the feedlot, but without tax or interest.
    • TotalTax. The total tax calculated for the lot while in the feedlot.
    • GrandTotal. This is the total dollars into the animal during its stay in the feedlot, including tax, but without interest.
    • Billing_Unit_Feed. These are the total costs while in the feedlot, broken down by unit (AnimalWeightUnit).
    • Billing_Unit_Drugs.
    • Billing_Unit_Inputs.
    • Billing_Unit_Yardage.
    • Billing_Unit_Other.
    • Billing_Unit_Subtotal.
    • Billing_Unit_Tax.
    • Billing_Unit_GrandTotal.
    • Billing_Animal_Feed. These are the total costs while in the feedlot, broken down by animal.
    • Billing_Animal_Drugs.
    • Billing_Animal_Inputs.
    • Billing_Animal_Yardage.
    • Billing_Animal_Other.
    • Billing_Animal_Subtotal.
    • Billing_Animal_Tax.
    • Billing_Animal_GrandTotal.
    • Billing_Day_Feed. These are the total costs while in the feedlot, broken down by headdays.
    • Billing_Day_Drugs.
    • Billing_Day_Inputs.
    • Billing_Day_Yardage.
    • Billing_Day_Other.
    • Billing_Day_Subtotal.
    • Billing_Day_Tax.
    • Billing_Day_GrandTotal.
    • InterestPerHeadSold. Profit/head sold (w/interest)
    • InterestPerHeadPurchased. Profit/head purchased (w/interest)
    • PurchasePrice. Purchase price (per AnimalWeightUnit)
    • SalePrice. Sale price (per AnimalWeightUnit)
    • TotalProfit. Total profit
    • ProfitHeadSold. Profit/Head Sold
    • ProfitHeadPurchased. Profit/Head Purchased
    • CostHeadDay. Cost/Head/Day
    • CostGainDeads. Cost of Gain dead weight in (per AnimalWeightUnit)
    • CostGainNoDeads. Cost of Gain dead weight out (per AnimalWeightUnit)
    • AnnualizedROI. Annualized return on investment
    • TotalProfitInterest. Total Profit (w/interest)
    • ProfitHeadSoldInterest. Profit/Head Sold (w/interest)
    • ProfitHeadPurchasedInterest. Profit/Head Purchased (w/interest)
    • CostHeadDayInterest. Cost/Head/Day (w/interest)
    • CostGainDeadsInInterest. Cost of Gain dead weight in (per AnimalWeightUnit with interest)
    • CostGainDeadsOutInterest. Cost of Gain dead weight out (per AnimalWeightUnit with interest)
    • AnnualizedROIInterest. Annualized return on investment (with interest)
    • AvgInWeight. Average weight in (AnimalWeightUnit).
    • AvgDeathWeight. Average death weight (AnimalWeightUnit).
    • AvgOutWeight. Average out weight (AnimalWeightUnit).
    • TotalWeightGainDeads. Total weight gain with dead weight in (AnimalWeightUnit).
    • TotalWeightGainNoDeads. Total weight gain with dead weight out (AnimalWeightUnit).
    • AvgGainDayDeads. Average daily gain with dead weight in
    • AvgGainDayNoDeads. Average daily gain with dead weight out
    • DeathLossPercent. Death loss percentage
    • FeedEfficiencyDeads. Feed efficiency with dead weight in
    • FeedEfficiencyNoDeads. Feed efficiency with dead weight out
    • DaysOnFeedDeads. Head days ÷ in count
    • DaysOnFeedNoDeads. Head days ÷ out count
    • AvgDMHeadDayDeads. Average dry matter consumed per head day including deads (FeedingWeightUnit).
    • AvgDMHeadDayNoDeads. Average dry matter consumed per head day including deads (FeedingWeightUnit).
    • AvgPenDensity. The average pen density (ex. sq ft/animal) for all the pen’s this lot was in during its history, weighted by count. Will be in PenDensity units.
    • StdDevPenDensity. The standard deviation of the all the pen densities.
    • AvgBunkDensity. The average feed bunk density (ex. in/animal) for all the pen’s this lot was in during it’s history, weighted by count. Will be in BunkDensity units.
    • StdDevBunkDensity. The standard deviation of the all the feed bunk densities.
    • ProjectedInDate. If the user used Fusion’s Projections Calculator, this is the in date they used in the calculations.
    • ProjectedInWeight. If the user used Fusion’s Projections Calculator, this is the in weight they used in the calculations. Per animal in AnimalWeightUnit.
    • ProjectedPurchaseDollars. If the user used Fusion’s Projections Calculator, this is the in price they used in the calculations. Per animal.
    • ProjectedAvgOutWeight. If the user used Fusion’s Projections Calculator, this is the out weight they used in the calculations. Per animal in AnimalWeightUnit.
    • ProjectedSaleDollars. If the user used Fusion’s Projections Calculator, this is the sale price they used in the calculations. Per animal.
    • ProjectedFeed. If the user used Fusion’s Projections Calculator, this is the feed cost they used in the calculations. Per animal.
    • ProjectedDrugs. If the user used Fusion’s Projections Calculator, this is the drug cost they used in the calculations. Per animal.
    • ProjectedInputs. If the user used Fusion’s Projections Calculator, this is the input cost they used in the calculations. Per animal.
    • ProjectedYardage. If the user used Fusion’s Projections Calculator, this is the yardage cost they used in the calculations. Per animal.
    • ProjectedOtherItems. If the user used Fusion’s Projections Calculator, this is the other items cost they used in the calculations. Per animal.
    • ProjectedAvgDailyGain. If the user used Fusion’s Projections Calculator, this is the average daily gain they used in the calculations. Per animal per day in AnimalWeightUnit.
    • ProjectedDeathLoss. If the user used Fusion’s Projections Calculator, this is the death loss they used in the calculations. 0-100%.
    • ProjectedInterest. If the user used Fusion’s Projections Calculator, this is the interest rate they used in the calculations. 0-100%.
    • ProjectedCostOfGainNoInterest. The projected cost of gain without interest (per AnimalWeightUnit).
    • ProjectedCostOfGainPerUnit. The projected cost of gain with interest (per AnimalWeightUnit).
    • ProjectedPurchaseBreakEvenNoInterest. The projected purchase break even without interest (per AnimalWeightUnit).
    • ProjectedPurchaseBreakEvenInterest. The projected purchase break even with interest (per AnimalWeightUnit).
    • ProjectedSaleBreakEvenNoInterest. The projected sale break even without interest (per AnimalWeightUnit).
    • ProjectedBreakEvenPerUnit. The projected sale break even with interest (per AnimalWeightUnit).
    • ProjectedProfitNoInterest. The projected profit without interest. Per head.
    • ProjectedProfitInterest. The projected profit with interest. Per head.
    • ProjectedDaysOnFeed. The projected days on feed.
    • ProjectedOutDate. The projected slaughter date.
    • CarcassAdjusted_LotBasePercent. The base dressing percent for the lot is used when calculating carcass adjusted information.
    • CarcassAdjusted_ActualOutCohortPercent. The actual dressing percent average across all the out cohorts for the lot.
    • CarcassAdjustedTotalOutWeight. Shows the carcass adjusted total out weight. Will be zero unless the lot has at least one non-death out cohort and all non-death out cohorts have a dressing weight entered. This field isn't meant to work with pre-Fusion information or lots that have had their out count/weight information overriden.
    • CarcassAdjustedADG_NoDeads. Shows the carcass adjusted average daily gain. This is on a deads out basis. Will be zero unless the lot has at least one non-death out cohort and all non-death out cohorts have a dressing weight entered. This field isn't meant to work with pre-Fusion information or lots that have had their out count/weight information overriden.
    • CarcassAdjustedFeedEfficiency_NoDeads. Shows the carcass adjusted feed efficiency. This is on a deads out basis. Will be zero unless the lot has at least one non-death out cohort and all non-death out cohorts have a dressing weight entered. This field isn't meant to work with pre-Fusion information or lots that have had their out count/weight information overriden.
    • CarcassAdjustedCostOfGain_NoDeads_NoInterest. Shows the carcass adjusted cost of gain. This is on a deads out basis and excluding interest. Will be zero unless the lot has at least one non-death out cohort and all non-death out cohorts have a dressing weight entered. This field isn't meant to work with pre-Fusion information or lots that have had their out count/weight information overriden.
  • InCohorts. An in cohort is a group of animals that are purchased into a lot. This is an array of in cohort objects, each with the following keys:
    • UUID. The in cohort's UUID.
    • Identifier. A user entered identifier for the cohort.
    • InDate. The date this cohort of cattle entered the lot.
    • InTime. The time they entered.
    • InCount. The number of animals that entered as part of this cohort.
    • TotalNetWeight. The total net weight of the cohort on arrival.
    • TotalGrossWeight. The total gross weight of the cohort on arrival.
    • TotalPayWeight. Users can choose whether the pay weight will be the net or gross, so this will be the same as one of those.
    • TotalDollars. Total purchase dollars for this cohort.
    • AreWeightsFinal. Often the true weights and dollar values are not known until after the animals first arrive. This will be true or false, depending on whether the user has specified that the weights are now accurate.
    • AreDollarsFinal. See above, but for dollar values.
    • BuyerContactUUID. The UUID of the buyer contact involved.
    • SourceContactUUID. The UUID of the source contact involved.
    • InitialPenUUID. The UUID of the initial pen the cohort was created in.
  • OutCohorts. An out cohort is a group of animals that are sold, died, or otherwise removed from a lot. You can distinguish a death from other types of out cohorts because the OutReason will be "Death". This is an array of out cohort objects, each with the following keys:
    • UUID. The out cohort's UUID.
    • Identifier. A user entered identifier for the cohort.
    • OutDate. The date this cohort of cattle left the lot.
    • OutTime. The time they left.
    • OutCount. The number of animals that entered as part of this cohort.
    • TotalNetWeight. The total net weight of the cohort on leaving.
    • TotalNetWeight. The total net weight of the cohort on leaving.
    • TotalGrossWeight. The total gross weight of the cohort on leaving.
    • TotalPayWeight. Users can choose whether the pay weight will be the net or gross, so this will be the same as one of those.
    • TotalDressingWeight. The total dressing weight of the cohort.
    • TotalDollars. Total selling dollars for this cohort.
    • OutReason. Slaughter, Further Feeding, Cull, Death, Own Use, or Other.
    • AreWeightsFinal. Often the true weights and dollar values are not known until after the animals are gone. This will be true or false, depending on whether the user has specified that the weights are now accurate.
    • AreDollarsFinal. See above, but for dollar values.
    • BuyerContactUUID. The UUID of the buyer contact involved.
    • DeathCause. The death cause (if the OutReason was Death), from a list defined by the feedlot.
    • DidPostMortem. True if a post mortem was performed to determine the death cause.
    • PostMortemVetContactUUID. The UUID of the contact of the vet who did the post mortem.
    • PenUUID. The UUID of the pen the out cohort was created from.
  • DrugEvents. A drug event occurs each time a drug or implant is given to an individual animal or a bulk vaccination is recorded for a lot. This key is an array of drug event objects. Each has the following keys:
    • UUID. The drug event's UUID.
    • DrugUUID. The UUID of the drug which will be in the meta file.
    • AnimalUUID. If this drug was given to an individual animal, the animal's UUID will be here.
    • DiagnosisEventUUID. If this drug was given as part of a treatment associated with a diagnosis, this will be the UUID of the diagnosis event.
    • TreatEventUUID. If this drug was given as part of a treatment associated with a diagnosis, this will be the UUID of the treat event.
    • Date. The date the drug was given.
    • Time. The time the drug was given.
    • Amount. The amount of the drug given in the drug's units which will be expressed in the meta file.
    • BillingCategory. A user defined category for billing purposes.
  • InputEvents. An input event occurs each time an input is given to an individual animal or by a bulk method to the lot. This key is an array of input event objects. Each has the following keys:
    • UUID. The input's UUID.
    • InputUUID. The UUID of the input which will be in the meta file.
    • AnimalUUID. If this input was given to an individual animal, the animal's UUID will be here.
    • Date. The date the input was given.
    • Time. The time the input was given.
    • Amount. The amount of the input converted to the input's billing units which will be expressed in the meta file.
    • BillingCategory. A user defined category for billing purposes.
  • OtherBillingItems. A lot can have additional line items (positive or negative) that can be billed against it for things that don't fall under the pre-defined categories. This is key is an array objects for those items, each with the following keys (note that a billing item does not have a unique UUID):
    • Date. The date for the line item.
    • Description. A description of the line item.
    • Amount. The dollar amount (either positive or negative) of the line item.
  • Ownership. This is an array of objects which describe the current ownership of the lot. Each object in the array will have the following keys:
    • OwnerUUID. The owner's contact UUID.
    • PercentageOwned. The percentage of the lot that this owner owns.
    • InterestRate. This owner’s interest rate (if any) if money is borrowed against the lot.
    • OwnerEquity. This owner’s equity in the lot. In other words, this is the non-financed portion of the in dollars from this owner.
  • UsageCalculations. This key shows the pre-calculated usage of a lot in several different ways.
    • ByIngredient. An array of ingredient objects that have been part of any ration given to the lot. Note that because of rounding, if you add the totals of this information it may not line up exactly with, for example, the lot TotalDMConsumed. The TotalDMConsumed value will be more accurate.
      • IngredientUUID. The UUID of a feed ingredient that has been given to the lot.
      • TotalDM. Total dry matter amount of this ingredient expressed in CommodityPricing.
      • TotalAF. Total as fed amount of this ingredient expressed in CommodityPricing.
      • TotalCost. The total cost value of this ingredient.
      • TotalBillAt. The total bill at value of this ingredient.
    • ByRation. This is the same type of usage breakdown as ByIngredient, but it shows the rations instead. Note that this includes all ration versions used within the ration.
      • RationUUID. The UUID of a ration that has been given to the lot.
      • TotalDM. Total dry matter amount of this ration expressed in CommodityPricing.
      • TotalAF. Total as fed amount of this ration expressed in CommodityPricing.
      • TotalCost. The total cost value of this ration.
      • TotalBillAt. The total bill at value of this ration.
    • ByRationVersion. A ration can change over time. These changes are captured as ration versions. This breakdown is similar to ingredients and rations, but is broken down by each ration version.
      • RationUUID. The UUID of a ration that has been given to the lot.
      • RationVersionUUID. The UUID of a ration that has been given to the lot.
      • TotalDM. Total dry matter amount of this ration expressed in CommodityPricing.
      • TotalAF. Total as fed amount of this ration expressed in CommodityPricing.
      • TotalCost. The total cost value of this ration.
      • TotalBillAt. The total bill at value of this ration.
    • ByDrug. Drugs and implants allocated to a lot are shown here both rolled up by category (a drug can be in more than one category, depending on the situation it was used in) as well as for individual drugs.
      • DrugCategory. Each category is represented in an array of objects which each have these keys:
        • Category. The name of the category.
        • TotalCost. The total cost of drugs given in this category.
        • TotalBillAt. The total bill at value of drugs given in this category.
        • Drugs. An object array of drugs that fell within this category, each with these keys:
          • DrugUUID. The UUID of the drug (see the meta file for more information on it).
          • TotalQuantity. The quantity of the drug as given in this category.
          • TotalCost. The total cost of the drug given in this category.
          • TotalBillAt. The total bill at value of the drug given in this category.
    • ByInput. Inputs allocated to a lot are shown here both rolled up by category (an input can be in more than one category, depending on the situation it was used in) as well as for individual inputs.
      • InputCategory. Each category is represented in an array of objects which each have these keys:
        • Category. The name of the category.
        • TotalCost. The total cost of inputs given in this category.
        • TotalBillAt. The total bill at value of inputs given in this category.
        • Input. An object array of inputs that fell within this category, each with these keys:
          • InputUUID. The UUID of the input (see the meta file for more information on it).
          • TotalQuantity. The quantity of the input as given in this category. This number is converted to the input's billing units.
          • TotalCost. The total cost of the input given in this category.
          • TotalBillAt. The total bill at value of the input given in this category.
  • Animals. Each animal that currently belongs to this lot will be in the array of objects. Each object in the array will have the following keys:
    • UUID. The animal's UUID.
    • RFID. The RFID of the animal (if there is one).
    • CustomID1. Users can define up to five custom IDs for animals.
    • CustomID2.
    • CustomID3.
    • CustomID4.
    • CustomID5.
    • IsAnimalCurrent. True or False.
    • CurrentPenUUID. If the animal is current, this will show the pen the animal is currently in. Remember that if you are not linking animals during moves and cohorts properly, this field may not be correct.
    • HomePenUUID. If the animal is current, this will show the home pen for the animal. Remember that if you are not linking animals during moves and cohorts properly, this field may not be correct.
    • Sex. Female or Male (or blank if not known))
    • Breed. The breed of the animal. Comes from a user defined list.
    • Color. The color of the animal. Comes from a user defined list.
    • CattleType. The cattle type of the animal. Comes from a user defined list.
    • SourceContactUUID. The UUID of the source contact of this animal.
    • Birthdate. The birthdate (if known) of the animal. This often comes from the CCIA.
    • HipHeight. In the units specified by the HeightUnit element.
    • FrameScore. User defines how this works, but it is an integer.
    • ThriftinessScore. User defines how this works, but it is an integer.
    • TemperamentScore. User defines how this works, but it is an integer.
    • EstimatedCurrentWeight. The weight Fusion calculates the animal to be right now (AnimalWeightUnit).
    • EstimatedSlaughterDate. The user can enter an estimated slaughter date for each animal.
    • AvgPenDensity. The average pen density (PenDensityUnit per animal) for all the pen’s this animal was in during its history. Will be in PenDensity units.
    • StdDevPenDensity. The standard deviation of the all the pen densities the animal experienced during its history.
    • AvgBunkDensity. The average feed bunk density (BunkDensityUnit per animal) for all the pen’s this animal was in during it’s history. Will be in BunkDensity units.
    • StdDevBunkDensity. The standard deviation of the all the feed bunk densities the animal experienced during its history.
    • InTreatment. True or False, depending on whether the animal is currently being treated for something.
    • LastTreatDate. The date of the animal’s last treatment.
    • CurrentDiagnosisEventUUID. The UUID of the diagnosis event for which the animal is currently in treatment (if any).
    • DiagnosisCount. The number of times the animal has been diagnosed with something.
    • TreatmentCount. The total number of treatments the animal has had over all diagnoses.
    • WithdrawalDateDrugBased. The withdrawal date based only on drugs.
    • WithdrawalDateFeedBased. The withdrawal date based only on feed.
    • WithdrawalDateOverall. The withdrawal date based on both drugs and feed.
    • AgeInCCIAMonths. The age of the animal at the time the file was created, but calculated using the algorithm CCIA requires.
    • AgeVerifiedStatus. Yes, No, Unchecked. Yes means the animal is age verified.
    • CCIAMoveInDate. The date a CCIA move in event happened for this animal.
    • CCIAMoveOutDate. The date a CCIA move out event happened for this animal.
    • CCIARetiredDate. The date a CCIA retired event happened for this animal.
    • CCIAImportDate. The date a CCIA import event happened for this animal.
    • CCIAExportDate. The date a CCIA export event happened for this animal.
    • TotalFeedDollars. The estimated cost of feed this animal has consumed.
    • TotalTreatDrugsDollars. The cost of drugs given during treatments.
    • TotalOtherDrugsDollars. The cost of all other drugs.
    • TotalInputDollars. The cost of inputs given to this animal during chuteside jobs.
    • TotalYardageDollars. The total yardage charge for this animal.
    • TotalDryMatter. The estimated quantity of feed on a dry matter basis this has consumed. In the FeedingWeightUnit units.
    • DaysOnFeed. The number of days this animal has been in the feedlot.
    • LastADG. The animal’s average daily gain based on the in weight and the most recent scale weight (AnimalWeightUnit).
    • FirstSeenDate. The date the animal was processed.
    • InWeight. The weight of the animal when it was processed (AnimalWeightUnit).
    • CustomWeightDate1. The user can define up to five events where Fusion records the date and weight (AnimalWeightUnit) of the animal.
    • CustomWeight1.
    • CustomWeightDate2.
    • CustomWeight2.
    • CustomWeightDate3.
    • CustomWeight3.
    • CustomWeightDate4.
    • CustomWeight4.
    • CustomWeightDate5.
    • CustomWeight5.
    • LastSeenDate. The date the animal was last see in a chuteside job.
    • LastSeenWeight. The weight on that date (AnimalWeightUnit).
    • ImplantDate1. When animals are given implants, the date, weight (AnimalWeightUnit), and product (the UUID of a drug listed in the meta file) of the first five implants are recorded here.
    • ImplantWeight1.
    • ImplantProductUUID1.
    • ImplantDate2.
    • ImplantWeight2.
    • ImplantProductUUID2.
    • ImplantDate3.
    • ImplantWeight3.
    • ImplantProductUUID3.
    • ImplantDate4.
    • ImplantWeight4.
    • ImplantProductUUID4.
    • ImplantDate5.
    • ImplantWeight5.
    • ImplantProductUUID5.
    • GeneticTest1. The user can define up to five genetic test fields.
    • GeneticTest2.
    • GeneticTest3.
    • GeneticTest4.
    • GeneticTest5.
    • CustomField1. The user can define up to five custom fields. These are free form text.
    • CustomField2.
    • CustomField3.
    • CustomField4.
    • CustomField5.
    • UltrasoundBackfatThickness. If the feedlot is ultrasounding animals, these fields will reflect that data. This one will be in the BackfatThicknessUnit unit.
    • UltrasoundRibeyeArea. Will be in the RibeyeAreaUnit unit.
    • UltrasoundProjectedYieldGrade.
    • UltrasoundMarblingScore.
    • UltrasoundProjectedQualityGrade.
    • OutDate. The date the animal left the lot, usually for a death or to slaughter.
    • LinkedInCohortUUID. The UUID of the in cohort this animal was linked to when it arrived at the feedlot (if any).
    • LinkedOutCohortUUID. The UUID of the out cohort this animal was linked to when it left the feedlot (if any).
    • CarcassKillDate. The feedlot can also track carcass data for animals and these fields will reflect that data.
    • CarcassPlant. Test
    • CarcassID. The plant’s carcass ID.
    • CarcassHotWeight. Will be in the AnimalWeightUnit unit.
    • CarcassDollars.
    • CarcassYieldGrade.
    • CarcassLeanYieldPercent.
    • CarcassRibEyeArea. Will be in the RibeyeAreaUnit unit.
    • CarcassFatThickness. Will be in the BackfatThicknessUnit unit.
    • CarcassMarblingScore.
    • CarcassQualityGrade.
    • Note. Any notes the feedlot has entered about this animal.
    • PenMovements. An array of objects representing the known pen movements for this animal. These are only valid if the feedlots practices good animal linking during pen movements.
      • UUID. The UUID of the animal movement record.
      • Date. The date of the movement.
      • Time. The time of the movement.
      • FromPenUUID. The UUID of the pen the animal is coming from. It can be blank if the previous pen is unknown or this is the first movement for the animal.
      • ToPenUUID. The UUID of the pen the animal is moving into at this moment. It can be blank if the animal is leaving the feedlot.
      • Type. A bit of extra information explaining why the move was made. Possible values include "Pen Move", "Chuteside Job", "Out Cohort", "Lot Closed", "Bulk Change Pen Change", "Bulk Change Current Status Change", "User Edit", "Grid Edit Pen Change", and "New Animal On Linked In Cohort".
  • DiagnosisEvents. Each time an animal is diagnosed, a diagnosis event is created. This is an array of those objects, each with the following keys:
    • UUID. The UUID of the diagnosis event.
    • DiagnosisUUID. The UUID of the diagnosis. See the meta file for more information.
    • AnimalUUID. The UUID of the animal diagnosed.
    • UserUUID. The UUID of the user who made the diagnosis.
    • PulledFromPenUUID. The UUID of the pen the animal was pulled from when diagnosed. Note that this is a new field in Fusion 4.0 and that Fusion has backfilled diagnoses that were made prior to the feedlot using Fusion 4.0 with its best guess.
    • Date. The date of the diagnosis.
    • PullNumber. The pull number associated with the diagnosis.
    • Weight. The weight of the animal when diagnosed (AnimalWeightUnit).
    • Temp. The temperature of the animal when diagnosed (TempUnit).
    • LungScore. The lung score of the animal when diagnosed.
    • DayCount. The number of days in the treatment. It is only calculated when the treatment is finished.
    • LastTreatDate. The date of the last treatment. It is only calculated when the treatment is finished.
    • EarlyTermination. True if someone terminated the treatment early.
    • DeviatedFromDefaultProtocol. True if the user overrode the treatment protocol Fusion initially suggested (if any).
    • DeviatedFromInitialProtocol. True if the protocol was changed later on in the treatment.
    • TreatEvents. This is an array of objects, each of which represent a treatment associated with this diagnosis. Note that you can look in the DrugEvents section if you need to know which drugs were administered during a treatment as each drug even will include the treat event UUID if it was associated with a treatment event. Each treat event has the following keys:
      • UUID. The UUID of the treat event.
      • Date. The date of the treatment.
      • Time. The time of the treatment.
      • DayNumber. The day number within the treatment protocol.
      • Weight. The weight of the animal when treated (AnimalWeightUnit).
      • Temp. The temperature of the animal when treated (TempUnit).
      • LungScore. The lung score of the animal when treated.
      • DeviatedFromDefaultDrugs. True if the drugs given are different than what the protocol suggested for this day.
  • DaySummaries. The following information is available for each day the lot is open. If lots are spread across multiple pens, the information is rolled up for each day to the lot level. This key is an array of objects, one for each day, with the following keys:
    • Date. The date this information is for.
    • Count. The headcount of the lot at the end of the day.
    • Weight. The average weight of the lot at the end of the day (AnimalWeightUnit).
    • Yardage. The total yardage charged against the lot for this day.
    • TotalDM. The total dry matter consumed by the lot on this day (FeedingWeightUnit).
    • Pens. The animals in a lot may be spread across multiple pens on any particular day. There can also be multiple lots in a pen. This key is an array of objects, each of which represent what happened in a pen the lot was in on this day. If multiple lots were in a pen, the information here has been calculated to only show this lot's portion of what happened in the pen on this day. Each pen will have the following keys:
      • PenUUID. The UUID of the pen.
      • Count. The number of animals from this lot in this pen at the end of the day.
      • Weight. The average weight of the animals in this pen from this lot at the end of the day (AnimalWeightUnit).
      • FeedingProtocol. The name of the feeding protocol associated with the pen at the end of the day.
      • ProtocolStep. The step number of the feeding protocol the pen was on at the end of the day.
      • ProtocolIsSuspended. True if the protocol was suspended at the end of the day.
      • RationUUID. The final ration assigned for the entire pen for this day.
      • BunkScore. The final bunk score given the pen for this day.
      • BunkCall. The final bunk call (FeedingWeightUnit of dry matter per animal) for the entire pen for this day.
      • TotalDM. The total dry matter consumed by the animals from this lot in this pen on this day (FeedingWeightUnit).
      • BunkCalls. This is an array of objects that describe the bunk calls that were made throughout the day for this pen.
        • BunkCallUUID. The UUID of the bunk call that was made.
        • Time. The time the bunk call was made.
        • PreviousFeedingProtocol. The name of the feeding protocol assigned the pen before this call.
        • NewFeedingProtocol. The name of the feeding protocol assigned the pen after this call.
        • PreviousProtocolStep. The protocol step the pen was on before this call.
        • NewProtocolStep. The protocol step the pen was on after this call.
        • PreviousProtocolIsSuspended. True if the protocol was suspended before this call.
        • NewProtocolIsSuspended. True if the protocol was suspended after this call.
        • PreviousRationUUID. The UUID of the ration assigned the pen before this call.
        • NewRationUUID. The UUID of the ration assigned the pen by this call.
        • PreviousBunkScore. The bunk score for the pen before this call.
        • NewBunkScore. The bunk score for the pen after this call.
        • PreviousTarget. The target value (FeedingWeightUnit of dry matter/animal) before the call.
        • NewTarget. The target value (FeedingWeightUnit of dry matter/animal) set by the call.
      • FeedDeliveries. This is an array of objects that describe this lot/pen combination's portion of each feed delivery that was made to the pen.
        • UUID. The UUID of this feed delivery.
        • LoadID. A human readable identifier assigned to the load this delivery came from.
        • RationUUID. The UUID of ration that was delivered.
        • RationVersionUUID. The UUID of the ration version that was delivered.
        • Time. The time the feed was delivered.
        • TargetAmount. The total target amount to be delivered to the animals in this lot/pen combination, in FeedingWeightUnit units. Note that this is a calculated value which the user can change and doesn't always reflect a true target. For example, Fusion may calculate that the driver should drop off 1000 lb of feed, but there may only be 300 lbs left on the truck.
        • ActualAmount. The actual amount delivered, in FeedingWeightUnit units.
        • Ingredients. This is an array of objects representing the actual ingredients associated with this delivery and to the animals in this pen/lot combination. It is actual in the sense that it is based on the actual ingredients and amounts put into the load the delivery is coming from, regardless of what the ration actually called for.
          • IngredientUUID. The UUID of the ingredient.
          • Amount. The amount of this ingredient, in FeedingWeightUnit units.

Pen Files

All the information for a pen is contained in one file, so there will be multiple pen files, one for each pen being exported if pens are included in the overall export. Pen's that physically exist in the feedlot location are exported. The name of each file is referred to in the Meta.json file and will be in the form Pen-<uuid>.json (ex. Pen-C33897AD-A5D6-4BF2-BB10-2C3E7F6D2555.json). The pen file can have the following keys in it:

  • FileCollectionUUID. All files that are exported together have the same UUID in this key so the consuming service can know they belong together.
  • DataDayCount. Some of the information for each pen is different each day. In those cases, this key represents how many days worth of data the user choose to include in the export.
  • Pen. The basic information available about a pen is found in this key.
    • UUID. The UUID of the pen.
    • Name. The name of the pen as defined by the user. The user can change this, so use the UUID attribute instead of the name for the primary key.
    • DisplayOrder. An integer representing the sort order for this pen from a display perspective. The user sets this.
    • DriveOrder. An integer representing the sort order for this pen from a feeding truck driving perspective. The user sets this.
    • IsTemporaryPen. Will be true if this is a temporary pen. Temporary pens are pens like receiving pens, sick pens, cronic pens, etc. and are treated slightly different in some places in Fusion.
    • PenLength. The length of the pen, in PenDensityUnit units.
    • PenWidth. The width of the pen, in PenDensityUnit units.
    • BunkLength. The length of the feed bunk, in BunkDensityUnit units.
  • BunkCalls. A list of bunk calls given to this pen in the past x days, where x is defined in the DataDayCount key above. There can be 0..n bunk calls made each day.
    • UUID. The UUID of the bunk call.
    • Date. The date the bunk call was made.
    • Time. The time the bunk call was made.
    • UserUUID. The UUID of the user who made the bunk call.
    • NewRationUUID. The UUID of the ration assigned the pen after the bunk call was made.
    • NewTargetDMI. The target amount to feed (dry matter basis, per animal) after the bunk call was made, in FeedingWeightUnit units.
    • NewBunkScore. The bunk score (1-5) after the bunk call was made. 0 means a bunk score wasn't made and does not affect the current bunk score of the day.
    • NewProtocolUUID. The UUID of the feeding protocol associated with the pen after the bunk call was made.
    • NewProtocolStep. The protocol step the pen was on after the bunk call was made.
    • NewProtocolSuspended. True if the feeding protocol is suspended.
  • FeedDeliveries. A list of feed deliveries given to this pen in the past x days, where x is defined in the DataDayCount key above. There can be 0..n feed deliveries made each day.
    • UUID. The UUID of the feed delivery.
    • LoadUUID. The UUID of the load that was on the truck when the feed delivery was made.
    • RationUUID. The UUID of ration delivered. Keep in mind that loads can have blended rations, so this is the primary ration of the load.
    • RationVersionUUID. The UUID of the ration delivered. Keep in mind that loads can have blended rations, so this is the primary ration of the load.
    • Date. The date the feed delivery was made.
    • Time. The time the feed delivery was made.
    • UserUUID. The UUID of the user who made the feed delivery.
    • TargetQuantity. The target quantity of the feed delivery, in FeedingWeightUnit units.
    • ActualQuantity. The actual quantity of the feed delivery, in FeedingWeightUnit units.
    • TargetDMI. Same as TargetQuantity, but shown on a dry matter basis.
    • ActualDMI. Same as ActualQuantity, but shown on a dry matter basis.
  • NormalDaySummaries. Fusion keeps track of the state of each pen as it was at the end of each day, referring to these records as day summaries. There will be 0..1 day summaries for each pen on any particular day. This is an object array of these day summaries for the pen for the past x days, where x is defined in the DataDayCount key above. Note there is a distinction between NormalDaySummaries and BunkGraphDaySummaries. NormalDaySummaries are the summary records associated with this physical pen where BunkGraphDaySummaries are the summary records associated with the cattle currently in the pen—if the cattle have been moved, the actual summary records may come from other pens that the cattle have been in over time. The following are the NormalDaySummaries summary records.
    • UUID. The UUID of the day summary.
    • Date. The date of the summary record.
    • Count. The head count at the end of this day.
    • Weight. The average weight of animals in this pen at the end of the day, in AnimalWeightUnit units.
    • RationUUID. The ration assigned the pen at the end of the day.
    • TargetDMI. The target amount to feed (dry matter basis, per animal), in FeedingWeightUnit units.
    • ActualDMI. The actual amount fed to the pen today (dry matter basis, per animal), in FeedingWeightUnit units.
    • BunkScore. The bunk score (1-5) or 0 for no bunk score at the end of the day.
    • ProtocolUUID. The UUID of the feeding protocol assigned the pen at the end of the day.
    • ProtocolStep. The protocol step assigned the pen at the end of the day.
    • ProtocolSuspended. True if the protocol was suspended at the end of the day.
    • BunkCallWasMade. True if at least one bunk call was made during the day.
    • WithdrawalDate. This is the feed based withdrawal date based on ingredients fed to the pen on this date. It does not take into account feed that was fed to the pen on previous days. Keep in mind that this information is useless if feedlots users are not correctly linking animals.
    • PenDensity. The pen density based on the size of the pen and the number of animals in the pen at the end of the day, in PenDensityUnit units.
    • BunkDensity. The bunk density based on the length of the pen's feed bunk and the number of animals in the pen at the end of the day, in BunkDensityUnit units.
  • BunkGraphDaySummaries. See note for NormalDaySummaries above. BunkGraphDaySummaries will include all day summaries from when the pen began which will likely be more than DataDayCount. Temporary pens, however, are capped at 30 days and all pens are capped at 365 days.
    • UUID. The UUID of the day summary.
    • PenUUID. The UUID of the pen. This is included because the day summary may actually be coming from a different pen if the cattle where in a different pen on this date.
    • Date. The date of the summary record.
    • Count. The head count at the end of this day.
    • Weight. The average weight of animals in this pen at the end of the day, in AnimalWeightUnit units.
    • RationUUID. The ration assigned the pen at the end of the day.
    • TargetDMI. The target amount to feed (dry matter basis, per animal), in FeedingWeightUnit units.
    • ActualDMI. The actual amount fed to the pen today (dry matter basis, per animal), in FeedingWeightUnit units.
    • BunkScore. The bunk score (1-5) or 0 for no bunk score at the end of the day.
    • ProtocolUUID. The UUID of the feeding protocol assigned the pen at the end of the day.
    • ProtocolStep. The protocol step assigned the pen at the end of the day.
    • ProtocolSuspended. True if the protocol was suspended at the end of the day.
    • BunkCallWasMade. True if at least one bunk call was made during the day.
    • WithdrawalDate. This is the feed based withdrawal date based on ingredients fed to the pen on this date. It does not take into account feed that was fed to the pen on previous days. Keep in mind that this information is useless if feedlots users are not correctly linking animals.
    • PenDensity. The pen density based on the size of the pen and the number of animals in the pen at the end of the day, in PenDensityUnit units.
    • BunkDensity. The bunk density based on the length of the pen's feed bunk and the number of animals in the pen at the end of the day, in BunkDensityUnit units.

FeedLoads File

If feed loads are being exported, all the loads will be in this file, named FeedLoads.json. It will have the following keys in it:

  • FileCollectionUUID. All files that are exported together have the same UUID in this key so the consuming service can know they belong together.
  • DataDayCount. This key represents how many days worth of feed load data the user choose to include in the export.
  • Loads. This will be an array of objects, one for each load included in the export. Each object can contain the following keys:
    • UUID. The UUID of the load.
    • UserUUID. The UUID of the user who made the load.
    • TruckUUID. The UUID of the truck associated with the load.
    • RationUUID. The UUID of ration chosen when making the load.
    • RationVersionUUID. The UUID of the ration version chosen when making the load.
    • LoadID. The human readable load ID.
    • Date. The date the load was made.
    • BeginTime. The time the load started to be made.
    • EndTime. The time the load was finished being made.
    • TargetQuantity. The target quantity of the entire load, in FeedingWeightUnit units.
    • ActualQuantity. The actual quantity of the entire load, in FeedingWeightUnit units.
    • TargetMixCount. The target mixing count for the load which can be in seconds or revolutions, depending on how the user uses it.
    • ActualMixCount. The actual mixing count.
    • OverallDryMatterPercent. This is the actual dry matter percentage of the load based on actual ingredient quantities and ingredient dry matter percentages at the time the load was made (0-100).
    • MergedFromLoadUUID. If part of a previous load was blended into this load, this will be the UUID of the previous load.
    • MergedFromQuantity. If part of a previous load was blended into this load, this will be the quantity of the previous load that was blended into this one.
    • MergedIntoLoadUUID. If this load was not fully empty after delivering feed and was blended into the next load, this will be the UUID of the load it was merged into.
    • MergedIntoQuantity. If this load was not fully empty after delivering feed and was blended into the next load, this will be the quantity that was merged into the next load.
    • Ingredients. This will be an array of objects, one for each ingredient that is part of the load. Each object can contain the following keys:
      • IngredientUUID. The UUID of the ingredient.
      • TargetQuantity. The target quantity, in FeedingWeightUnit units.
      • ActualQuantity. The actual quantity, in FeedingWeightUnit units.
      • QuantityFromPreviousLoad. If a previous load was blended into this load, and this ingredient was in the previous load, this will be the amount of this ingredient that came from the previous load.

IngredientAttributes File

If the ingredient attribute history is being exported, all the attributes for ingredients that are referenced elsewhere in the export will be in this file, named IngredientAttributes.json. It will have the following keys in it:

  • FileCollectionUUID. All files that are exported together have the same UUID in this key so the consuming service can know they belong together.
  • Attributes. This will be an array of objects, one for each attribute included in the export. Each object can contain the following keys:
    • ItemUUID. The UUID of the ingredient the attribute belongs to.
    • Attribute. The attribute itself. Possible values include DM, NEM, NEG, Cost, Market Value, Bill At, and Tax Rate.
    • Date. The date of the attribute change.
    • Value. The new value of the attribute.

DrugAttributes File

If the drug attribute history is being exported, all the attributes for drugs that are referenced elsewhere in the export will be in this file, named DrugAttributes.json. It will have the following keys in it:

  • FileCollectionUUID. All files that are exported together have the same UUID in this key so the consuming service can know they belong together.
  • Attributes. This will be an array of objects, one for each attribute included in the export. Each object can contain the following keys:
    • ItemUUID. The UUID of the drug the attribute belongs to.
    • Attribute. The attribute itself. Possible values include Cost, Market Value, Bill At, and Tax Rate.
    • Date. The date of the attribute change.
    • Value. The new value of the attribute.

InputAttributes File

If the input attribute history is being exported, all the attributes for inputs that are referenced elsewhere in the export will be in this file, named InputAttributes.json. It will have the following keys in it:

  • FileCollectionUUID. All files that are exported together have the same UUID in this key so the consuming service can know they belong together.
  • Attributes. This will be an array of objects, one for each attribute included in the export. Each object can contain the following keys:
    • ItemUUID. The UUID of the input the attribute belongs to.
    • Attribute. The attribute itself. Possible values include Equivalency, Cost, Market Value, Bill At, and Tax Rate.
    • Date. The date of the attribute change.
    • Value. The new value of the attribute.

Change History

FileDefinitionVersion=1; CreatorVersion=3.5
  • Initial Version

In this Topic