Some 2-3 years back a discussion started on agricultural applications…
I see now in GitHub that codingcoffee is working on it…CodingCoffee is Ameya Shenoy who works for Erpnext if I am not wrong…So the Mumbai team seems to have taken this up…
Just creating a large series of docs will not do the job , I am afraid…
Many other development will benefit from this as well… The datatype should be OGC (Open Geospatial Consortium) compliant to assure exchange with other systems…
An other component that may need some thought are time-series…
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…??
There exit considerable literature on agricultural production systems…the same for environmental Information Systems (soils, water, meteorology, landuse/land cover…)… I am working on the latter myself see:
I am a geologist, who stopped coding when Pascal 5.0 came out…But at my employer (www.itc.nl) we do have the required expertice in house…spatial software specialist, agronomist, environmental, soil/water/meteo, etc …who could advise on matters related to ErpNext for Agri overall design.
@revant_one has created a map doctype that will be pulled into the core in a matter of days or weeks. (And I’m very excited about it!)
And I disappointed with this list: “spatial software specialist, agronomist, environmental, soil/water/meteo, etc …” because you have omitted customer and/or farmer.
I am in active consultation with farmers who are planning on using ERPNext. The things they care about are not the things that you seem to think they care about. In conversation, I mentioned that I really wanted to app mapping to my Field Crops application and this farmer said that he wouldn’t likely use it. Pulling on this thread some more, the thought is that the things the ERPNext does already (HR, accounting, website… NOT farming) are the things that farmers need help with, which is upside-down to the use case that most manufacturers see (EG more features and more detail).
And I don’t think it’s fair for you to criticize or denigrate a development in process with your characterization “Just creating a large series of docs will not do the job.” That just not cool.
I have been active on the github issues that the Frappe Team has been working on and they are being very responsive to my concerns. They’re obviously not done. And I still worry that they’re overbuilding the whole thing with a level of detail that would intimidate farmers, but that’s more of a problem with ERPs in general than this specific effort.
Robert, your attitude towards this project is one that I see often, where people try to tell farmers what they need, rather than asking them. As a farmer, I can tell you that I don’t need a geologist to tell me how to run my farm.
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…
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…
“Just creating a large series of docs will not do the job.” That just not cool. Sorry I may have been a bit to direct. What I mean to say is that we should consider the overall design, before we make new Docs…
By know means it is my intension to tell u how to run your farm…But there is nothing against an open discussion how the agricultural module should look like. Not all farms are the same. I have visited many farms in Africa, both subsistance and high-tech…Visitors to ITC often want to see a high-tech Dutch diary farm, where basically everything is computerized…Some thinking ahead of what is general enough to satisfy the maximum number of farmers can not be harmful. I think the list of people @xxxxx in my original message could make a good start…
I agree with this sentiment and it is also the root of my concerns about the current design. In general the direction I’d like to see it take is for something less complex that leverages the existing features of ERPNext, rather than try to reinvent a lot of things.
The design has been based on the wiki specification that’m personally not in love with because I think it’s too much and I don’t care for the terminology (that is also likely a US versus where ever the author is from). Also, I have never seen this person with this handle (“retroneo”) post on the forum or on github and this spec was last updated over a year and a half ago. I think the approach of asking the community (and including farmers) is likely to yield a better result.
This is another point that I see for an MVP-style implementation, rather than the “kitchen sink” that’s included in the wiki spec. Like most of the other features in ERPNext, it’s enough to work with and be built upon, but generic enough to serve as a guide for customization. I am an advocate for customization because it will better meet the customer needs, but if they don’t need much, or their needs are highly standardized (like accounting), what ships with ERPNext should be good enough.
We have been using some custom doctypes for our farming operation that essentially track fields, harvests and inputs added. Despite being an organized farming company, we have had significant challenges training people to use our ERPNext implementation at the farm level and I see that being the biggest barrier to adoption in India specifically. A farming/Agri module should have use cases and users defined clearly and explicitly. The company in India that is doing fairly well in this regard is CropIn. I would suggest you at least check it out. Putting it on a mobile is in fact far more practical for Indian farmers since desktop penetration in the farm sector is abysmal. Just some thoughts.
Haven’t read the whole topic but I want to join the party.
I am hydrologist !!! On the side I work on an open source project where we have an Irrigation Advisor. Basically, the user adds his/her agrifield coordinates and we run a soil water balance model.
Pilot area is somewhere in Greece http://arta.irrigation-management.eu
The model and advisor are all open source. The problem is the meteorological data that aren’t available for more general implementation.
Also, I have a minor frappe weather app crawling openweathermap.org data for an area (my home coordinates)
Currently, I have designed a raspberry weather sensor to post data to a frappe instance using Frappe Client…
and of course, Batman is based on me… I am Batman.
Sure. Also like Robert mentioned the automated dairy farms with milking robots and that kind of modern approach.
In my market area, the are many (most?) farmers who direct market their products to consumers, so they have a need for a POS, website, HR modules. There are lots of things that make sense in that scenario too and I think the vertical integration aspect is a strength of ERPNext in general.
Seems like there is a lot of interest in the agri module. Would be great if someone takes leadership of this and organizes a sprint. Maybe list out 20 things to do and lets call for a sprint that can happen virtually over IM ?
@tmatteson I just show you app. I will contribute on it
Basically i will try to 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.
Overall like @rmehta said this needs leadership!!! For example your app name at_field_crops is not suitable for generic namespace.
Are you all up to arrange and initial web session? (we could ask @rmehta to join and give up pointers )
Also I think weather forecast should be separate module in ERPNext.
e.g. When I am developing some stuff on ERPNext, it will give update to me on current temperature in Current Location and Hometown. If raining start then it will send alert its normal raining or heavy raining.
I have implemented ERP in food processing sector, at that time I come across Food Traceability Requirement. In traceability user want to track Food in various cycle production using food as raw material, processing, transporter of food product, Farmer, whether record at harvesting and different cycle. Food and Soil Record.
To gather this data mostly they have RFID, GPS, Barcode, Infrared and Biometric device. We can integrate this device in ERPNext to auto capture data.
That’s great! I have also used the openweather api and the thing I think it offers over others is its easy integration with local weather station hardware. What is your use case for weather integration (outside of agriculture?)
On the namespace topic - understood that it would be appropriate to refactor this if it is pulled in to the core. I don’t want to undermine the progress of the ERPNext team that is working on this. They’re way ahead of me on some things, I’m working on this on the nights and weekends and they’ve implemented some stuff that I really like.
@rmehta and @chandra others interested - perhaps we can have a conference call/ scrum to organize? Talk through the action items.
I don’t have any specific use case other than food traceability.
I am just thinking, what happen when ERP start sending notification for delivery and purchase receipt or someone plan their journey in ERPNext using fleet app and get notifications for whether. Like we usually hear such announcement in Railway Station and Airport.