I like that idea a lot.
1 Like
I like @tmatteson current design and he is on the right from my perception. I have had the chance to work with many farmers and this would work for them.
Small correction…I was a geologist 
Specialized in hydrology/hydrogeology/ remote sensing/water management So it seems we have two hydrologist on board…Speculate that i met @kickapoo in Frankfurt…
I visited the http://www.meteorologicaltechnologyworldexpo.com last week in Amsterdam…I met the guys from www.meteoblue.com…They also allow ftp access …and the have 30 years of historical data…all modelled but that is also the case for openweather…Very detailed farming info https://content.meteoblue.com/en/products/sectors/agriculture
Of course they are commercial…no idea how they charge… Further @tyler would have loved this place…Agrimeteorologcial stations of all kinds and prices…
Hi Tyler…
Had a look at the GitHub link…
Acerage: Used in the case as a synonym to ‘field’, ‘cropland’, ‘vineyard’ or ‘orchard’, used to represent a an area where crops are grown. Because fields is effectively a reserved word in ERPNext referring to form and/or input fields,…
I would suggest accepted term Land Cover Land Use Unit (LCLU) or just Land Unit…
I have several goals for the next version of this app.
Aerial Photos/ Map Integration: I’d like to incorporate a mapping functionality and add it to the “Acreage” doctype. Ideally, this would have multiple pins that could be used to calculate area, which should be captured in its own docfield.
That would be nice…and brings met back to the title of this tread…Location is everywhere and the are so many other business processes one can think of that have spatial dimensions…I still believe that making Docs “spatially enabled” , OGC compliant description of points, lines and polygons would fuel many other applications in Erpnext.
A further enhancement would be to integrate it with an infrared satellite photography service link Cornerstone Mapping or TerrAvion or others as appropriate, though these are typically a subscription service.
Half of our department is working on this kind of stuff ( not me…)…A lot is availble public domain…be it not on a scale suitable for precision farming…
There are dozens of opensourse GIS and Remote Sensing products (QGIS, Ilwis…) that can be used…would not integrate it in Erpnext
Weather Integration: I am a particular fan of tracking degree days for crops and would love to integrate it further here and have done some of the preliminary work to do so. I would like to find a weather service that doesn’t require an API key but I’m not sure it exists. Also, it would be great to integrate it with any of the off-the-shelf hardware weather stations that are on the market.
No API…have a look at meteoblue.com
I still do not really see the use case for weather data…Maybe you can explain how u see it…Most important is that the key variables are availabel…then degreedays are easily calculated…They work fine in temperate climate but perform lousy in the tropics…
I am leaving for Namibia tomorrow so will leave this exiting discussion for a while…
I have had an interesting two or three days of adjusting to “return jet lag” after a wonderful experience in Mumbai for the ERPNext conference. I have some wits to continue the work we began in earnest regarding AgriNext. After reading the entire thread so far, let me begin with a quote by an Economist:
Section 5 (V)
If we can agree that the economic problem of society is mainly one of rapid adaptation to changes in the particular circumstances of time and place, it would seem to follow that the ultimate decisions must be left to the people who are familiar with these circumstances, who know directly of the relevant changes and of the resources immediately available to meet them. We cannot expect that this problem will be solved by first communicating all this knowledge to a central board which, after integrating all knowledge, issues its orders. We must solve it by some form of decentralization. But this answers only part of our problem. We need decentralization because only thus can we insure that the knowledge of the particular circumstances of time and place will be promptly used. But the “man on the spot” cannot decide solely on the basis of his limited but intimate knowledge of the facts of his immediate surroundings. There still remains the problem of communicating to him such further information as he needs to fit his decisions into the whole pattern of changes of the larger economic system.
The quote is by Mr. Friedrich Hayek, recipient of the Nobel Memorial Prize in Economic Sciences in 1947.
We are obviously not going to solve every farmers specific problem, but I believe we can safely attempt to empower a number of farmers to promptly use (benefit from) the knowledge of the particular circumstance of time and place that they face. As time goes on and modifications are made to the software, more farmers will benefit from this.
I grew up in a farm in a country outside the United States, and have studied farming in the US. I have experienced large scale farming and production processes and have also witnessed first-hand subsistence farming and its delivery processes to market, both in my latin american country of origin, and by speaking with farmers in USA, Africa, Asia, Europe and the Caribbean. Yes, I know about many crops, but will never know about all crops and all circumstances of every farmer anywhere, nor will never pretend to know everything there is about agriculture.
What I have learned so far is that every farmer aims for at least one goal:
- To have a successful crop that will at the very least, put food on his table for himself and his family.
A secondary and obviously more enriching goal, is to have enough surplus production to sell to a buyer.
So if we can agree with these goals, and the fact that all centralized solutions will never solve all problems, we can then agree that what the initial proposal for the AgriNext module is aiming for is to aid in this matter.
@rmehta, at the ERPNext Conference 2017 clearly asked the community to work on incremental modifications to the core. The model proposer is an initial exercise and clearly this will need improvement. Your opinions will be taken into consideration. The point is to start with something basically useful.
I now proceed to quote and voice my opinion on some items that have stood out:
Just creating a large series of docs will not do the job, I am afraid…
Of course not! However, this is an initial exercise, consulted with someone who is a farmer (that would be people from the Center for Sustainable Agriculture in India, @ravigokhale, and myself ). I sat down on monday with Ameya for at least 6 hours and showed him how I approach farming. He showed me some of the work proposed by the CSA and we were delighted to agree on many areas, thus we are proceeding.
Of course farmers should be at the first place to guide this process…However, an individual farmer may concentrate on what he needs, and may forget the needs of an other farmer. There farming business is no different then any other business…
Understand, no one, including me is perfect. I will surely overlook the needs of other farmers of crops I don’t even know about. But as this is a collaborative project, it is perhaps best to propose something useful, and then those farmers who have specific needs are responsible for proposing improvements or customizing their implementation to their needs.
Why do we all use and love ERPNext? We perceive the benefits of using it to be more than the defects it might have out of the box. It’s highly customizable architecture allows us to implement things we want for ourselves on the fly. Furthermore we have hope that as time goes by, things will improve to our liking. But expecting ERPNext to do everything for us as we exactly like it, without contributing the solution ourselves, is pure folly. How can the software do what I want it to do, if I don’t program it myself?
The list that has disappointed you is refering to collegues inside the building…That never have been farmers but do have ideas how farmers produce…
Yes, many programmers inside the building do not know about what happens in the field. This is why I placed the quote above. We are well aware of this. And, as a farmer myself, I cannot be expected to know what every other farmer on the planet will be doing. It is impossible! I was not aware of your specific work in Kenya, until you shared it. It would be great to incorporate some of this knowledge that can be used by farmers in general, in their localization.
It should be defined what exactly we want to achieve…Just archive farm environmental & production data, do better accounts by taking into consideration all production cost, or manage the farm better…??
In my opinion, all goals are important. And there is an order I believe and have theoretical and empirical proof that works, regardles of the industry you operate in:
- All farmers at some point will want some economic benefit from their farming enterprise.
- To get this benefit, the farm must be managed in the necessary and sufficient manner to accomplish this economic benefit.
- Having sufficient data at the right time and in the right manner, will help make better decisions that enhance the probability (but not guarantee it!) of an economic profit. (This obviously includes gathering and reviewing such data with mobile devices)
A small farmer may use traditional or ancestral methods of gathering information about his environment to correctly manage his crops. (For example, here in Guatemala, 40 days before rainy season begins, migratory falcons fill the skies as they fly north. Local farmers or farm caretakers use this as empirical evidence of the approaching rain, and adjust farming activities accordingly). A large farmer uses more “sophisticated data” such as temperature, dewpoint, PAR light, etc.
Should I impose my “migratory bird sighting metric” on the whole ERPNext community? no! it is irrelevant for many. Sure, I can customize a field and gather this data in a “scientific” manner, but this is a particular piece of information for me. Perhaps others might benefit in the region, but still, not all farmers use this. Ultimately, I am responsible for its implementation. ERPNext gives us this capability.
Should we use some standard farming metrics such as Temperature, Humidity, rain amount, PAR light, and other metrics (soil saturation, etc.)? I believe the scientific measurements are crucial, but then again not all of them are common: I have only begun using PAR sensors recently, for example.
Starting with a basic set of fields to gather, as observed from other farming activity software and agricultural engineers, is necessary, but the basic fields we choose will never be sufficient to all. Clearly, most of the users of ERPNext in our business don’t use ALL of the DocTypes and fields. Accounting (so far) is not interested nor understands how to prepare a planting matrix for crops. And Sales does not care or does not use our Accounting module (in our case). So, the problem of “adoption” is solved by which DocTypes those in the field use. Perhaps only a rain measurement or date of measurement are easy to understand and capture for someone in the field, but expecting all field operators to manage the data analysis of moving averages and probabilistic data for historical rain measurements that he has written down manually for 10 years is a tall order. Instead, this person who manually captures rain data can be expected to access the DocType where he simply writes the numbers down like if calling a number on his smartphone (and almost 95% of the population where I live now has a smartphone!).
The beauty of ERPNext is that with the functionality built in, a user can figure out how to customize it for his specific application with the basic data types to be captured. This, I believe is where the line is drawn between what the core does, and what users and implementers do.
I propose that instead of getting into traditional farmers arguments, the old topic of “farming is different everywhere” and “no one will tell me how to run my farm” or “farmers will not adopt this”, we focus on the basic aspects common to all, adding those aspects which have proven successful in the long run.
I was pleased to see many similarities stand out in our discussion with @codingCoffee and the needs proposed from the CSA in india. As an example, India and Guatemala commonly do tests such as
-
Water analysis
-
Soil texture analysis
-
Soil Nutrient Analysis
-
Plant or foliar analyisis
Some might argue that the “small farmer” will never have access to this. But CSA and cooperatives here in Guatemala routinely provide these services in a cost effective manner to farms that supply produce to them. This is why we considered them important to keep track of.
Proposal for a disciplined approach
I personally proposed that ERPNext include a disciplined approach to this: being able to register test results for specific dates. Think about how we do most of the things in ERPNext: We have a series of N doctypes with a date stamp, this is extremely useful for finding patterns in data. Thus, the same should be done with analysis. Even if the farmer, out of his own individual independent will, has only done one or none of these. If the farmer does not want to be told by a program how to do things, then he should just ignore it. But for those who want to see an alternative that might work, this disciplined approach has worked for me and others I know.
During my years working in a medium scale farming operation, I saw that these tests were done at random. The confusion about what fertilizer to apply, in which amount, or which labor activities to do when, was rampant. I stopped this by setting dates to routinely do these analyses, and in the same areas. We monitored closely the changes to the crop, soil and water (Increase or decrease in specific parameters). The results, after 4 years of quarterly data, led us first to reduce fertilizer application without sacrificing the nutrients (a $400K savings per year!!!). Then, each analysis cycle, we made a decision of how to modify the application quantities, methods, cycles in such a way that we stabilized critical factors in the soil such as pH, and crop specific nutrients and balances. This data was thus graphed, and decisions were made much more confidently and easily, maintaining crop health, while reducing cost. These methodologies were taught to the managers and sub-managers in the field, and they know how to graph this. Field operators capture the data in the format they are given.
So, gathering analysis data is necessary, but not sufficient. You must also consider yields for the crops, and yield per logical area of production is one key driver. Sure, you can produce increased amounts of, say, corn each year at a farm level. But what if your entire farm is divided into four plots? How each plot performs due to location, slope, etc. is crucial. Any farmer will tell you that no plot is the same. What if you work each one differently? What if plot A requires a bit more Nitrogen fertilizer than plot B. What if you discover that adding Gypsum to one plot increases its yield, but the other plot does not benefit from such application? Registering this data is crucial. You can make decisions that impact your production amount, and thus your economic profit, considerably. It is important to keep track of what happens to the parcel, plot or whatever you call the physical area that contains soil or other substrate material where you grow your crop or feed/work with your livestock.
(While we are at it, may I ask that we please stop taking offense of the names of data fields or our “physical areas that contain soil or other substrate material where we grow our crops, or feed/work with our livestock”? It is obvious that we all call them differently in our corner of the world, but the fact remains that some plant or animal material is placed in some sort of growth substrate, be it soil or inert material and that we expect this to increase in weight or change its characteristics from a seed to a full grown mature plant from which we expect to harvest something of economic benefit for the owner or caretaker of said material)
So, if we take a disciplined approach to data gathering, sophisticated (Raspberry Pi, sensors, etc.) or empirical (bird sightings, manual rain gauge observation and recording, we all agree that some data should be gathered, it should be in ERPNext, and it should have the flexibility (which it already does) to create these DocTypes. The trick then is to configure some basic reports to provide an instant analysis of this data, and then at some point in the future be able to correlate with tasks to be done for the crop cycle or plot of land.
In my experience, whether it is on a paper notebook by hand, or a computer or mobile device, those farmers who are aware of what goes on by writing down environment data, tasks done to crops or animals, and profit and loss information, usually thrive, because they can see patterns and their relationships: It is obvious that after intense rainfall, many small farmers might lose their crops. They know the economic impact. A larger operation, such as a medium sized business or a cooperative, begins to lose some track of this. AgriNext can help small farmers and larger ones alike by providing something that integrates this data and presents it to them so they can make decisions based on more and hopefully sufficient data available.
4 Likes
I am on my way to Kenya. The last 20 years I have worked in Naivasha where on 4000 Ha a revenue of some 0.5B$ is generated…95% high cash crops for export…Flowers (roses), french beans etc…I tried during 4 years to implement ErpNext at the local Water Resources Management Authority…It became a failure…I many countries transparency in government organisations is not appreciated…I know that all (or most farms) use an ERP system…I will ask around if there exist interest in this project…I have a collegue (a meteorologist) working for ITC but living in Naivasha. He lives on a large farm where his wife is farm manager…
This would be an interesting use case…they know, contrary to most farms in Africa all there inputs…All water abstraction points are daily recorded (volume), they know exactly the water application per field (greenhouse) and the amount of agrochemicals applied,…almost all farms do have a meteostation…Will be continued…Robert
Hi All,
Great discussion and so excited to see the interest in developing a agric module within ERP.
I suggested that module some years back and I have helped create the wiki page with @rmehta also some years back. It came from a Google Doc I shared at the time.
In my regards, the wiki still represents my needs. But in a nutshell:
I want to know easily all inputs that goes into a field: that is all agro-chem (super important for traceability, some insecticides are not allowed after certain time due to residues, etc.), labor, fuel, etc.
As input, I means costs, quantity, labor who used the machine, machine used, etc.
for each field, I want to know exactly what yield I got.
Meteorological records important, soil, leaf and water analysis important.
Again, more importantly, i want to be able to calculate easily the total costs of my crop with all the indirect costs associated.
I mentioned in a previous post, I would try to app on a separate server. I still intend to do it. Things are being hectic at the moment.
best and super excited to be able to try an agric module soon within the Frappe / ERPNext framework.
@tmatteson @codingCoffee Have you guys checked each other project?
Aren’t there some opportunities for you to collaborate together?
@tmatteson it would be great if you add on your github page some commands on how to install your module. I would like to try it (within a few months once things slow down a bit here).
We have been working together on the github side of things, I’ve been trying to help there, though because it’s reactive instead of planning, it could be better.
My application installs the same as any other application in the Frappe ecosystem
bench get-app etc
No, not as of yet, but I will surely check it out…
I am realizing that a lot of the machination on this topic relates to terminology. (There’s another argument going on about scope, I think they are separate from each other.)
Let me explain what I mean by way of a story: I reached out to MN Technique for some help with my project earlier this year. We passed some specification-flavored docs back and forth and it became clear that we had different terminology in mind but were talking about the same things: in the US the term “milch cow” in not used, it’s always “dairy cow”. Similarly, a “chicken coop” or “chicken house” is the same concept as a “laying battery”. We moved past it, with the MN Technique team picking up the terminology I was using because I was the customer. I was “right” in US terminology and “wrong” in Indian parlance.
This leads me to a couple of ideas:
- The terminology used should be the most common terms in India, not anywhere else.
- The ERPNext North America Group needs to get its act together with a US English translation. Agriculture is an area where the terminology differs more than others, but it’s not the only one.
- I would encourage developers worldwide to adopt this mindset, at least in pull requests or public-facing third-party modules. This limits the amount of context switching for the largest group of people contributing to the core.
1 Like
@codingCoffee @vishal - Are you guys available for a call in the next week or so? I’d like to limit the competition between our approaches and try to pick out in the best ideas. Anybody else is welcome to join, but it would seem we’re the ones actively developing here and it would be good to share some ideas directly.
3 Likes
Count me in please. I have no development experience with ErpNext but am a practicing farmer.
1 Like
@tmatteson Would you like to see our basic implementation of how we are recording our farm data? If so, I can arrange a demo.
Just my two cents on this discussion - I came across this GitHub - Wirelessinfo/FOODIE-data-model: FOODIE data model , it seemed to be something the community might want to consider.
My family is into large scale farming from generations (I am a farmer too!). Here is my opinion about this project with relation to Indian market -
I am of the opinion that this module will have very very very less demand in the Indian market. For those who don’t know, Agriculture is the predominant sector in India. Majority of the farmers have couple of acres of land at max and they do not have money to pay for the ERP nor the knowledge of mobiles/computers to make use of an ERP.
Even someone like me who have double or triple digit acres of farm land in India are unlikely to be interested in this. Most of us have regularly consulted various govt departments and agriculture universities for decades in the matters related to scientific/modern farming techniques. Considering the shortage of labour, reduction in yield due to the so called scientific farming techniques and the price we get for selling produce,a good number of farmers are moving to Zero Budget Natural Farming by Masanobu Fukuoka / Subash Palekar.
Each of us have our own ancient techniques as well as some jugaad which may or may not work for farmers in the next village.Some of the large scale farming companies may be interested in this, but they are probably 0.1% of the market. So I feel that this would be one extremely difficult, time and money consuming project which may not be worth the time of ERPNext developers. And you guys are better off concentrating on other sectors.
Hi Harold
Nigeria also has hundreds of thousands of farmers of which 99% are subsistence farmers just like in India. But we still have thousands of farmers (am NOT talking about the biggest farmers with thousands of acres) who are willing to use modern techniques and modern business management tools to run their farms.
That’s the market. And I believe that market exists in every country.
And ERPNext is now being used in many many countries all over the world in almost every continent. Some markets will obviously need this feature more than others.
Regards