This window is where you define a chuteside job. There are a lot of options which allow you to create just about any kind of job you want. These job definitions are saved and can be chosen before starting a job. At that stage there is usually some final setup to take care, essentially customizing the job definition for a particular job instance.
Each job definition needs to have a name associated with it. This is how you pick it when starting a job instance. It must be unique among all the job definitions.
If you have multiple locations, you might want to set up certain job definitions that can only be used at specific locations. If you want to restrict this job definition to a certain location, choose it here. Or leave it set to Any Location for it to be available to all locations.
When you first defined drugs and inputs you may have associated a billing category with each one. Invoices and closeouts can show a cost breakdown based on these categories. If you enter a default billing category here, all inputs and drugs associated with this job will default to the entered category. If you leave this blank, they will default to whatever you defined when you created the item.
Typical billing categories might be Induction, Processing, and Treatment. While you are free to enter anything you like, you will probably want to pre-define several categories to be more consistent when entering them. You can define this pick list at Fusion Admin → Setup → Billing Category Pick List. This is the same list that is used when defining inputs and drugs.
It is possible to override the billing category for specific subjobs within the job definition, giving you fine grained control if you need it. This is true for the Give Drug, Give Input, and Treat subjobs. If you leave the billing category field blank for these subjobs, they will use the default type for the entire job. But if you enter something in, it will be used just for the subjob itself. Similarly, you can set an override for these subjobs when added on the fly.
If this checkbox is not checked, the job definition will not show up in the list of available jobs to start a new job instance with.
You can think of an ID stack as a stack of pre-numbered tags ready to give to animals. You can have as many stacks as you want and you can have multiple stacks associated with the same animal ID field. For subjobs that change a custom ID, you will have the option of using one of the ID stacks. Fusion will then manage the stack whether it is being used from a normal subjob or a subjob in a sort protocol.
To add a new ID stack, click the + button. Click the - button to remove a stack. With a stack selected, you can change its attributes:
As you make changes to the ID stack attributes, an example of several tags in sequence will be shown below so you can see what kind of numbers Fusion will create.
A subjob is an action or event that is recorded as part of the job. There are several kinds of subjobs, some of which are required and some of which can be added multiple times to the job—each time doing something a little different. The subjobs you add are what really define what will happen during the job and what will be recorded in Fusion.
During the job, when an animal first enters the chute Fusion assumes that all the subjobs will be associated with the animal. However, you can tell Fusion to skip certain subjobs and you can also add new subjobs on the fly just for that animal.
To add a new subjob, click the + button. You will be given a choice of possible subjobs to add. Click the - button to remove a subjob. You can also drag the subjobs in the list to reorder them. They will appear in the job in the same order as they appear here.
Following is a list of the possible subjobs and information about associated settings.
There are a few settings that are shared by all subjobs.
This subjob must exist in every job. It is used to let Fusion know what animal is in the chute. Normally, Fusion will recognize the animal by its RFID tag. If this fails, you will be prompted to identify the animal through one of the custom IDs. If the animal cannot be recognized or if it is a new animal, a new animal will be created and assigned to the job's default lot and pen.
This subjob can be used to get the animal's weight from the scale. If getting the weight from the scale fails, the weight will be estimated from the animal's lot average or the animal's estimated current weight. The weight can also be manually entered.
Use this subjob to get the animal's temperature. If you have a temperature probe connected, Fusion will read the temperature automatically. You can also enter it manually for each animal.
Use this subjob to get the animal's lung score from a Whisper Veterinary Stethoscope. If you have a Whisper device connected, Fusion will listen for new lung scores from the device and update this value. You can also enter it manually for each animal, but only if you have the correct permissions. Entering the score manually is not recommended.
This job checks with CCIA (or Symmetry) to see if the animal is age verified. This is normally done by sending a message to Fusion Server to age verify the animal in the background. The advantage to this is that the job will not be slowed down if there are connection problems with CCIA. However, it also means that Fusion won't know the age verification status during the job itself (unless the animal was previously checked).
| Many people set up their induction jobs to have Fusion Server age verify in the background. Then the animal is already age verified for later jobs. |
This subjob is useful if you have animals that have lost their RFID tag. It is usually added on the fly for an animal that has lost its RFID tag. Once you have identified the animal by some other means (in the Identify Animal subjob), add this subjob and scan the new tag to associate it.
| If you are inducting new animals that don't have RFID tags and you have set the job up so that Fusion is automatically detecting animals entering the chute based on the tag reader associated with the RFID field, it is best to just let the animal into the chute, give it an RFID tag and scan that tag. You don't usually want to use this subjob in that case. |
Use this subjob to change any of the animal's custom IDs. Custom IDs can be used for management tags, recording tag colors, or even other grouping of animals. (Keep in mind that you can use the custom fields for similar non-ID related groupings.)
This subjob allows you to change any (or all) of the following attributes: sex, breed, color, hip height, frame score, thriftiness score, temperament score, cattle type, and source. For new animals, these values will default to the values you set here or, if left blank, to similar values from the animal's lot where available. You can then change them as you see fit. Defaults are only applied to new animals. They will not be applied to existing animals, even if the fields are blank for those animals.
This subjob is used to record that a drug or implant was given an animal.
When the job is processed a drug event will be created for each drug subjob. However, if the amount given is zero, it will be treated as if the subjob was skipped.
This subjob is used to record that an input was given an animal. Inputs can be anything from actual product given an animal to simply recording a billing entry.
| Consider hiding inputs that are for billing purposes only. They will still be part of the job, but won't clutter up the subjob list during the job. |
This subjob is used for diagnosing and treating animals. When an animal first gets this subjob, you will be asked to choose a diagnosis. Based on that, a treatment protocol will be set up. Each day the animal comes back, this subjob will recognize where it is in the treatment protocol and tell you what the animal needs for the day.
Use this subjob to let Fusion know an animal is moving to another pen. You can also use it to set the animal's home pen.
| It is possible to set up a job where Fusion is expected to relocate an animal to more than one place. You should be careful that this does not happen. If it does, Fusion will basically randomly choose one of them and go with it. |
Use this subjob to either manually set an estimated slaughter date for each animal or to have Fusion automatically calculate one.
button to insert variables into the formula.It is important to make sure the formula makes sense. For example, you can't add two dates together. You can subtract dates to get the number of days in between, but that would only make sense if you were then adding or subtracting it to another date. You can also enter an actual date if you do it in this format: !12/25/2013! Note the exclamation marks around it. Also, Fusion expects the month, day, and year to be entered in the same order as your computer's system preferences are set up for. If you do this on one computer, and then Fusion runs the formula on another computer with different settings, the date will be read incorrectly.
Here are some examples of correct formulas:
Fusion has five custom fields for each animal that you can enter anything you like into. This subjob allows you to change one of these fields.
Fusion has five fields used to record genetic tests. Normally you would import this information from an outside source, but this subjob allows you to enter the data during a job if you like.
This subjob give you a place to enter the ultrasound values for an animal.
Use this subjob to flag an animal under certain condition. It can only be added to a sort group's subjobs, not the normal subjobs.
This tab is used to set up sort protocols. A sort protocol allows you to have Fusion perform different actions for different groups of animals during the job. Animals can fall into different groups based on criteria that you define for the sort protocol. It is possible to have more than one sort protocol, each with it's own set of sort groups with associated actions. For example, if you had three sort protocols, each animal would be part of three different sort groups. Notice that one sort protocol is set to be the primary one. When the job is done and the animal information is updated, there is a field that shows what sort group the animal was in during its last job. Since it can only show the sort group from one sort protocol, it will show the one from the primary sort protocol.
Click the + button to add a new sort protocol. The Sort Protocol Edit window will open where you will tell Fusion how many sort groups there will be, what criteria to use, and which sort group will belong to each protocol variation. There are some other options you can set as well. For more information, see the documentation for Sort Protocol Edit Window. To remove a sort protocol, select it in the list and click the - button.
You can also use the button to have Fusion automatically add some common sort protocols which you can then edit to fit your exact needs.
Once you have created a sort protocol, the Sort Group list will show each sort group associated with it. Select a sort group to see a list of subjobs that will become part of the job if an animal falls into that sort group. You can add more subjobs by clicking the + button and remove subjobs by clicking the - button. It is possible to have a sort group that doesn't have any subjobs associated with it.
Not all of the normal subjobs make sense to be used in a sort group. These are the ones that are available here:
| You want to be careful to not let Fusion get into an endless loop where it changes the same value that the criteria is based on. Fusion will not let you add a subjob to a sort group if the subjob changes one of the same values as the sort protocol's sort criteria is based on. You can do this across multiple sort protocols, but we encourage you to carefully think this out if it is necessary. Don't expect that one sort protocol will change some value which another sort protocol will then be evaluated on—this idea is not supported and there is no guarantee that the sort protocols will be evaluated in any particular order. If you manage to set up a scenario where Fusion could get into an endless loop, Fusion will stop evaluating after one round. |
When you create a job definition from scratch, you can ensure that every action is being billed for. For example, you may add "inputs" along side other subjobs to represent the billing for the subjob (and hide them so they aren't in the way). However, sometimes you want to make sure billing occurs when subjobs are added on the fly. This tab allows you to set up how this will work as well as other rules that come into play for subjobs that are added on the fly.
The window shows a list of subjobs that can be added on the fly. When you select one, you can see the inputs associated with it in the list on the right. To add more inputs, click the + button and then enter the input and amount. To remove an input, select it and click the - button. You can change the amount and the billing category for each input that will be created as a result of a subjob added on the fly. If the billing category is left blank, the job's default will be used.
Remember that these associated inputs only apply to these subjobs when they are added on the fly during a job. They do not apply for subjobs that are part of the job definition.
If one of these subjobs is added during a job, there won't be any visible indication that there are associated inputs. Instead, they will be added when the job is processed.
If a Give Drug, Give Input, or Treat subjob is selected, you can also enter a Billing Category that will apply to any drugs or inputs created from that subjob. When left blank, the job's default billing category will be used, but you can enter a different billing category to override it here.
When a job is running, several windows are all working together to show you the information you need and allow you to make necessary changes. Fusion even allows you to create one or more HUD (Heads Up Display) windows customized with exactly what you want displayed. With different monitor sizes, different numbers of windows for each job, and different sizes for each window Fusion needs to provide a way to organize these windows on the screen so they are most efficient for you during the job. That is what this tab is for.
On the left is the window list. Any windows in this list will be opened when the job is run. You can add as many windows as you want, including any HUD windows that have been defined. It is possible to add the same HUD window multiple times.
On the right are the positioning options for the window. Since it can be difficult to move windows on a touch screen, the Horizontal Position and Vertical Position areas let you precisely define where the windows will open when the job starts up. Each window can be opened at a spot that is relative to the screen itself or relative to other windows that have already been opened. (Note that the pixel fields can have negative values—positive values move to the right and down while negative values move to the left and up.)
If you are positioning a window relative to another window, the other window must already be opened. Fusion will open the windows in the order they are listed and you can drag and drop the windows to rearrange them in the list as necessary.
In the Other Options area, there is an option to use the window positions from the last time the job ran. Each time a job finishes running, Fusion records the position of each window on the chuteside computer. If this checkbox is checked, and if Fusion can find position information for this job on the chuteside computer, the window will be opened in the remembered position rather than the position defined here. If this checkbox is not checked, Fusion will always open the windows as defined here.
If the Subjob List window is selected, you can also define its height by telling Fusion how many subjobs you want to see. There must be at least three.
After the windows have been opened in the defined positions, Fusion will check to make sure each window is fully on the screen. If it is not, Fusion will override the defined position and move it just enough to be on the screen.
If one of the windows in the list is a HUD that has been deleted, it will show up in the list in red. You should remove it from the list. If you do not, it will simply be ignored when the job is started and any windows that are positioned relative to it will be positioned relative to the screen instead.
The Job Definition window is normally used to create and edit job definitions. However, it can also be used to view a job batch and chuteside events to see how they were actually setup at the time of the job. Of course, in this mode nothing can be edited. In addition to seeing how the job was defined, you can see what actually happened with the Inspector tab which is only available in this situation.
The inspector shows a list of subjobs that were active for an animal. This will include normal subjobs, subjobs from active sort groups, and any subjobs that were added on the fly. This will include subjobs that would have been hidden during the job itself. If the user skipped a subjob you can still see it in the list, but Fusion identifies it as a skipped subjob.
When a subjob is selected, information related to it is shown on the right hand side. Above the list is a note letting you know where the subjob came from—normal subjobs, added on the fly, or which sort protocol and sort group. Some items in the list have a blue dot beside them. This indicates that you can Double-Click on the line to be shown more information. For example, if the item is "Default Lot", double-clicking it will open the lot's edit window.
The subjob list always has an extra subjob labeled "<General Info>" which is used to show information that doesn't belong with a specific subjob.
Note that information from before Fusion 2.6 will be converted to the new system, but it cannot always be done with 100% accuracy. Billing and the main information will not be lost, but Fusion didn't used to keep track of as much information as it does now during jobs.
You can open this window by creating or editing a job definition from the Job Definition List window.
