At one point there was discussion about generalizing log based transactions. This change would make the this module easier build and frankly more effective.
I believe this is the discussion @WHFarms was referring to: Generalizing Log-based Asset Attributes
To echo what @Farmer-Ed said: I wouldnāt wait around for changes to be made before you start using farmOS @WHFarms. Either help them be implemented or find a workaround (or a different system).
We are currently working towards farmOS v4, but there is no budget to implement the log-based attributes feature. Perhaps someone will offer to help in the future (v5? v6?)ā¦ or perhaps they wonāt. 
2 Likes
I like your @Farmer-Ed listing so far. Your farm_reference_animal is spot on. Here is what I am considering but I think multiple people and some with more data knowledge of the org could help for best place to put itā¦
logs
farm_animal_sale - add animal sale logs
- relationship to animal ID, sale price, weight, date
- retire this animal in FarmOS for archive purposes
- retire this animalās medical logs to archive
- possibly move it into the farm_reference_animal class for any replacement
cows
farm_animal_purchase - add animal purchase logs
- create a new animal record
- relationship to new animal record with animal ID, purchase price, weight,
date
- option to add farm_reference_animal information
farm_animal_death - add animal death logs
- archive animal(s) selected - move to farm_refernce_animal if dependents
- retire animal(s) medical logs to archive
Status should be automarked ādoneā
The first 2 should be group assignable.
Medical Logs - need to be tied to group if desired, choose what to administer to what Animal. Select what medication. Record Animal(s), doage, should auto-link withdrawl time, and post a date for next booster.
Wean-Vax program implementation. In the states we have a boosted, weaned program for calves that brings more money at the barn.
Medicine - how do we treat this? Need to record cost, manuf, lot, serial, withdrawal time, expiration date, date purchased(received), qty.
Same thing with add a Vet with contact info etc, that way if you have employees itās easily accessible. Iām not large but thinking certain use cases.
Flags
farm_cattle_flags - Bull, Cow, Heifer, Maiden, Cull - like it.
farm_material_flags - I think this should be an input log for fields or linked to the rotational grazing module which will need to come out of this as well.
Each Animal ID needs to know the current location (pasture field), rest can be stored as logs. I think the āis movement?ā needs to be removed or hidden and applied to the rotational category and a log for grazing movement added and we can organize our herd into groups.
Do we want weaning records? weights, body condition scores, etc. We can calculate adj weaning weights and such using the formulas for CRUD reports.
Use predertmined calculations for gestation and calving. Have a registered and unregistered setups for users.
Breeding Flag or Log - turning the bull out/ai to calculate breeding/calving dates. Option to record heats. I donāt have time for this and will just turn a bull out but some might. AI inventory as a medicine type record for those that do.
We will have to make the rotational grazing module work as well. I can see @mstenta smiling.
For displays we need to add a menu item for Ranch or Cattle on left ā pop out menu for different CRUD options (think filterable actionable reports) - Inventory (filterable by type), could add some fields with totals and weights and ages etc. , and Bred/non bred as a another one, Cattle in what pastures - also allows for making groups or adjusting quickly, Financials.
Please adjust, discuss, tell me a better way that is easier.
Sidebar to extend this to sheep/goats/pigs we would need that info and decide if it should be more object oriented over specifity.
2 Likes
@tool172 I presume you are self hosting and have a development instance? Were you planning on doing much of this yourself?
I can finish off much of what Iāve started to add the necessary Asset and Log types or extend existing ones.
My plan for much of the logic you describe is to be built into the external App Iām developing that will interact with farmOS via the API. But if that is not something youād be interested in then some quick forms might be a good starting point, there is also an existing module for terminal logs to archive assets for sales/deaths etc. created by @wotnak that may interest you.
I donāt think there should be much need for a sidebar for different species in logs or assets as the fields will be the same but a species selection in quick forms would make sense to apply different calculations for gestation periods or similar.
We need to think about feeder and fat cattle also. The biggest gripe about cattlemax is that it supports cow calf operation then just stops. So when we want to move our calves into the growing or finishing pens we canāt track them any longer.
A look at Cattler should give a person some reference to what we are attempting to achieve.
Also Tags! Not ear tags either but class/group/type/color/sex/diversity/whatever. It would be ideal to be able to tag an animal with any number of tags like a tag cloud so you can group and cut and organize animals in lots of ways.
1 Like
I also agree that the interface needs to be addressed. A grid layout that allows record sorting and filtering would be much more convenient when numbers of animals get larger.
30 cows I could make it work. 600 cows and Iām still on cattlemax
1 Like
What would you want to see for growing and finishing?
Tags - Iām thinking just filtering options by field. the tags would just be another column in the sheet or view. Otherwise could you elaborate please?
I sell to backgrounders so I donāt do any of that or care too. If I finish itās to go in the freezer 
For growing and finishing a few critical peices are feed and meds.
You need to take an animal, add it to a āpenā/pasture (back to my comment we are all rotational grazers in my first post) and create a group of animals. From that point on a person needs to track feed/bedding/inputs for the group. Typically profitbility is measured at the group level.
Individual animals still need to have meds monitored. With the new USDA requirment we may start getting yeild data back in the future that would be valuable.
When I was thinking about tags and how I would design it an animal would get a GUID in the DB that matches nothing in the world except in the DB. Then from there I would have a TagType/Value/DefaultTag table that a person could enter as many tags for an individual animal as they wanted. Id probable have archive also and wouldnt a tag from history but rather archive it when the retag function was used. This would allow us to put USDA Tags, Registration, Ear Tag, Brand, Tattoo, and whatever else somone wanted to put as a ātagā.
If you are refereing to my TagGroup comment then it needs to be called something different for this program as it is to easy to mix with ear tags, but have you ever seen a Tag Cloud. Basically you have a table that allows you to tag animals into groups. So you may set up a group that says possible 2025 replacements and tag a bunch of heifers, or potential culls and tag animals with that. Maybe marked not tagged but identified. Or something. I do belive most of the time sorting and filtering solves the problem but this feature would get used a bunch by the planners and trackers in the world.
All of my Animals are imported and exported (archived) via the API and I generate a UUID based on the Tag Number which is also the EID Number. The Number includes Country Code, National Herd Identifier and the animals number. Perhaps not the intended use of a UUID but it ensures I always have an up to date Herd register that is easily synced with the National DB without fear of creating duplicates. The EID numbers are just 12 digits so I just apply leading zeros. Other tags, jumbos and freeze brands etc can be recorded against the animal but the 12 digit EID number is unique to the animal from the day it is born to the day it dies and beyond.
// Create Asset Object
return {
"action": action,
"body": {
"data": {
"type": "asset--animal",
"id": "00000000-0000-0000-0000-" + tag.slice(-12), // Animal UUID generated from animal tag
"attributes": {
"name": tag.slice(-5), // Name is last 5 digits of tag number
"status": status,
"id_tag": [{
"id": tag,
"type": "ear_tag",
"location": ""
},
{
"id": brand || tag.slice(-5),
"type": "brand",
"location": ""
}],
"data": animalICBF,
"birthdate": newdob + "T00:00:00+00:00", // Formatted Date @ midnight
"sex": gender.charAt(0), // Reduce Male/Female to M/F
},
"relationships": {
"animal_type": {
"data": {
"type": "taxonomy_term--animal_type",
"id": breedUUID,
}
}
}
}
}
};
}
The initial Birth/Purchase Sale/Death logs also get similar treatment except I change some of the leading zeros so they can easily be tracked with the animals too as they enter / leave the farm (They are also created by the API)
const logData = {
"action": 'create',
"body": {
"data": {
"type": 'log--birth',
"id": "00000000-0000-0000-1111-" + animal.animal_id.slice(-12),
"attributes": {
"timestamp": formatDate(animal.birth_date),
"status": 'done',
"name": `[Birth] ${animal.animal_id}`,
"notes": {
"value": `Animal ID: ${animal.animal_id}, Sire: ${animal.sire_name}, Dam: ${animal.dam_number}`
}
// Add other attributes as needed
},
"relationships": {
"asset": {
"data": [
{
"type": "asset--animal",
"id": "00000000-0000-0000-0000-" + animal.animal_id.slice(-12),
}
],
},
"mother": motherUUID ? {
"data": {
"type": "asset--animal",
"id": motherUUID
}
} : undefined
// Add relationships as needed
}
}
}
};
msg.req.push(logData);
});
1 Like
I had originaly though about using USDA numbers, but it only works for Americans and USDA tags are not needed in animals less thn 18 months old, not intact, not used in the rodeo or fairs and a few other Unoited States Govt jargin.
One of the reasons I finally concluded a GUID to the DB would be maybe the best and then whoever and whereever and whatever can be a tag.
1 Like
All cattle here in Europe have to be tagged within 30 days of birth and the tag number stays with them for life.
Thank you for that explanation. Iāll think on it some more.
We donāt sell across state lines or I would need the EID tags. Iām hoping that we donāt have to go into that system because of the costs for smaller operations.
I am in agreeance on the grouping for rotation grazing and that has to be a module with this module in FarmOS. A simple group option and a number for those animal assets would work. Medical records would remain with each animal.
Feed/input now - Is this measured on a group basis or broken down to cow/steer level? Just thinking how to bunk this into the individual animal and use sum columns in groups or store by group?
Feed and Inputs are done by the group in my experiacance then a report is done that divides it out evenly or by day for the animal. Huge feedlots are going to use software designed for huge feedlots but our audiance the less than 500 cattle annually I belive would benifit fom a simple group input.
Maybe it is even a bit rigid at first. You can assign an animal only 1 āfeeding Groupā and as you enter batches of feed you assign it to that feeding group. Then all animals in that group split the batch evenly by day its fed. If you move an animal to a different feeding group then the batch is prorated.
Something is better than nothing, the idea is that we can keep a close eye on our cost and understand if groups of animals are profitable or not profitable.
Iām an agile type of guy so I always like to build something that does a few things and then let createivity just let it explode into this ultimate product.