Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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:

    • Name / Description / Item / Whatever (requiredCustomer (Required)

    • Date of revenue (required) [default to day of creation and shown]

    • Category Type (required) [selected via tile on previous screen and not shown on creation]

    • “Is the revenue associated with agricultureagricultural activities?” (required)

      • “Yes” (default), “No”

    • “Would you like to associate this revenue with crop(s)any crops?” (optional) [multi-select]

      • User should be able to select any number of active of crop plans

      Customer(s) (optional)
    • 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

...

Question

Answer

Date Answered

Should we call money coming into the farm “Revenues” or “Income”?

Revenues

Are there other revenue types we’re not tackling now? Why?

Yes! Per user meeting on .

Then there were several that they mentioned, but I think we'll handle them once we add the relevant functionality:

  • CSA (out of scope for now)

  • Seeds: The production of seeds, while similar to crops, has some different factors and tasks that shift this. I think at some point, we'd like to have additional depth to the crop plan flow to manage this. At that point, we'll probably integrate it with seed sales. There is a huge tracking of product component and certification process as well. 

  • Animal production: both primary (milk) and secondary/processed (cheese)

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

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?

Kevin’s proposal (to be debated)

Defined by revenue type:

Defined at creation:

  • Customer

  • Date

  • Type (on previous screen)

  • “Is the revenue associated with agricultural activities?”

  • “Which crops would you like to associate this revenue with?”

  • Notes

Duncan Brain + Joyce Sato-Reinhold + Sayaka Ono + David Trapp

What attributes should be shown for each revenue type? (e.g. Crop sales, Event hosting, Tourism, Consultations, Crafts)

Crop sales:

Shown:

  • Customer

  • Date

  • “Which crops?”

  • Notes

Assumed, and therefor not shown:

  • Type (on previous screen)

  • “Is the revenue associated with agricultural activities?” (Assumed “Yes”)

All others (including custom):

Shown:

  • Customer

  • Date

  • “Is the revenue associated with agricultural activities?” (Assumed “Yes”)

  • “Which crops would you like to associate this revenue with?”

  • Notes

Assumed, and therefor not shown:

  • Type (on previous screen)

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”.

...