Add revenues flow V2.0
User story
As a farmer I want to be able to easily document all the sources of revenue* coming into the farm so that I have a complete picture of my financial situation
* Note that not all sources of revenue need come from the farm. It is very common for farmers to have income from jobs outside the farm.
Why?
We know that for many farmers, especially smaller scale and family run farms that there are typically many sources of revenue beyond just selling raw produce that keep the operation afloat. Without providing enough flexibility to document this, we fail to:
Give users the tools they need to accurately manage their operations and financial situation
Fail to capture the true picture with regards to small scale agriculture
Fail to provide implicit guidance on ways of generating revenues that farmers might be able to take advantage of to increase their financial success
Assumptions
Functional Requirements:
Must-have:
Maintain or expand the ability to document a crop sale
Several common categories of incomes / revenues
Crop sales
Event hosting
Tourism
Consultations
Crafts
A standard flow for adding a new instance of revenue that covers at least the following attributes:
Customer (Required)
Date (required) [default to day of creation and shown]
Type (required) [selected via tile on previous screen and not shown on creation]
“Was this revenue generated on the farm?” (required)
“Yes” (default), “No”
“Would you like to associate this revenue with any crops?” (optional) [multi-select]
User should be able to select any number of active of crop plans
Notes (optional)
Ability to easily add several revenues back to back (but not within the same flow)
Saved revenues must correctly attribute revenue categories and crop types
Nice-to-have:
Ability to add several revenues in the same flow
Ability to mark a revenue as repeating
Filters to be able to view ag related and non related revenues (Nice to have)
Filters to be able to view crop and non crop related revenues (Nice to have)
Non-functional Requirements:
Must-have:
Most basic revenue flow shouldn’t take more than 10 seconds to complete
Nice-to-have:
User interaction and design
Questions and answers
Question | Answer | Date Answered |
---|---|---|
Should we call money coming into the farm “Revenues” or “Income”? | Revenues | Sep 19, 2023 |
Are there other revenue types we’re not tackling now? Why? | Yes! Per user meeting on Sep 20, 2023. Then there were several that they mentioned, but I think we'll handle them once we add the relevant functionality:
Processed goods: As discussed in the past, we might want to wait on this as there is additional complexity to this. Probably need to add a "processing" task | Sep 20, 2023 |
Should the attributes of revenues be defined at the “template” level or the “instance” level? If defined at the “template”, can users overwrite at the instance? Are there some of each?
Current expected implementation is at the template level we ask if the revenue should be associated with crops or not. If the answer was yes then at the instance level we ask, “which crops?” | Kevin’s proposal (to be debated) Defined by revenue type:
* Custom revenue types are uneditable once created.
Defined at creation of instance:
Refactors to be undertaken:
| Sep 22, 2023 |
What attributes should be shown for each revenue type? (e.g. Event hosting, Tourism, Consultations, Crafts) | None! We decided to:
| Sep 22, 2023 |
Should we guide users not to create livestock related revenue types? | No! We should review what types users create after 3 months and use this to guy the types we create for livestock. | Sep 22, 2023 |
Out of scope
Documenting “CSA boxes” as a revenue source; reasoning is the complexity of documenting new CSA boxes each period. Should likely be implemented as a “template”.