As a farmer I want to be able to add, use, and remove types of expenses that are useful for my particular operations so that I can accurately mirror and understand my operations financially
Screens
https://www.figma.com/file/96NZ02oYe3jpet1roUp0s0/Mockups?type=design&node-id=1712-37203&mode=design (see Finances tab, Manage custom expense types section)
Requirements
Must have
Updated multi-select expense type view
Including ability to add / manage custom expense types
View custom expense types (tile view)
View custom expense type (individual view)
Read-only view
Add custom expense type flow
Only user editable attribute is “Custom expense type name”
Retire custom expense type (see https://lite-farm.atlassian.net/wiki/spaces/LITEFARM/pages/1341259816/Manage+custom+expense+types#Other-context)
Nice to have
Spotlight for managing expense types on updated multi-select expense type view
Edit custom expense type
Customize an icon for a custom expense type
Migration of all expense types of type “Other” to be custom expense types
Whomever takes this, if we get this far, please check with David Trapp before completing.
Shouldn’t have
Other context
Closely follows the pattern for custom task types - check that functionality out first!
We’ve eschewed the term “categories” in favour of “types” throughout finances. Any time you see “categories”, it’s out of date and should be replaced. Logic for this:
Types is shorter than categories in most of our supported languages
farmExpenseType table already exists - reducing tech debt
Changes to the model are hopefully minimal in this epic (though this isn’t the case for Manage custom revenue types - so take note of the structures for that upcoming epic). farmExpense and farmExpenseType tables already exist in the database.
For farmExpenseType, should use the existing convention around NULL or populated farm_id as to whether the type belongs to a specific farm or is universal
Discussion on -
For purposes of this discussion “Misc” and “Other” are equivalent. David feels strongly that “Miscellaneous” is better.
When a user clicks to add a “Misc” expense, we highlight
For retaining “Other” or “Misc” | For removing “Other” or “Misc” |
|---|---|
Makes user experience for one-off expenses simpler | Makes data messy and difficult to categorize for the user |
Feels right | Makes data messy and difficult to categorize for the researcher |
Users may end up with a large list of one-off expense types that aren’t re-used | Will reduce usage and efficacy of configurable expense types |
If there is a single “Misc” category for all users, this makes it easier for scientists to review | Users can create their own “Miscellaneous” if they wanted |
For a future integration with Quickbook like tool, they will likely have a “Miscellaneous” |
Against adding legacy “Other” entries to custom expense types | For adding legacy “Other” entries to custom expense types |
|---|---|
Assumes the Note entered is a re-usable type (which is only partially supported in the data) | Introduces user to new feature automatically |
M | |
V1.0 has an “Other” type that should be removed in favour of documenting custom expense types. Ideally, each of these would be migrated to be custom expense types for the farm where they are created.
SELECT DISTINCT note FROM "farmExpense" WHERE expense_type_id = '7ce971b4-1590-11ea-9019-22000b628b95'
For retired expense types:
Retiring is a soft delete
Retired expense types must…
Not be selectable on the multi-select expense type view for new expenses created post-retirement
Still appear as a potential filter (with some sort of visual treatment, e.g. “Mechanical (retired)”) elsewhere in Finances V1.5
Continue to show up as a category in reports, lists, tables elsewhere in Finances V1.5
Previously created expenses of the retired type must…
Be visible in lists and tables elsewhere in Finances V1.5 (per filter criteria)
These treatments☝️ are not in scope for this epic, but are helpful in framing future work in the Finances V1.5 module.
When creating a new expense type, we should …
Check if the exact name and farm_id exist in the database and if so, don’t POST a new one but just set delete = FALSE
Should we have a separate section for retired expense types where they can be “un-retired”?
Not initially. We’ll do a check a few months after releasing this feature to see if that is a use case we need to support.