enhancement: add "printed" phase to order

[carchrae]

when our food co-op gathers to distribute food, we do not have access to a printer, so instead we print out 'order_by_groups' (we call this bin sheets and is given to members) and 'order_matrix' (we call this split sheet for accounting, and we mark any changes on it).

before we meet, the person who has ordered the food will typically hear from the supplier about any shortages or changes in the order, and can update the order using the received page. however, after the ordering person has printed the sheets we want to lock the received function. in the case that someone did change an item on the received page, now all the printed sheets may be out of date (yes, they could be printed again, but this is not always practical).

it is the case that sometimes, changes are needed after the food is distributed (items do not arrive, or less arrives), but all of those changes are done on the account balancing page. they should never be handled by the received function.

my proposal is to add a 'printed' phase to the order, which will then turn off any automatic distribution which happens on the received pages. it may be fine to denote that less of an item was received and that can be reconciled during the 'balancing' phase.

however any new distribution is dangerous, since it leaves the co-op in a dangerous state where the paper being used to allocate food is not in sync with the website (and ultimately, what people are charged). to date, i have handled this with warning messages on the receive page, but i think it would be better to have this baked in.

[wvengen]

Hmmm that sounds like a useful addition. We'll need to make sure that it works clearly both for people using printed sheets, and for people not using them.

I wonder if we could have a more descriptive name, something indicating no automatic distribution. Or maybe distributing (you wouldn't want automatic changes once you've started distributing). Or maybe even when you've received something, you wouldn't want to do that again.

At some point, it would be useful if someone would gather all kinds of different foodcoops 'state' flows, and see how to make something that would cater for most of them. But not having done that, I think adding a state like you mention is a good idea. Preferably somewhere in the UI where it is good to find for those who need it, and not in the way for those not using it. If that's hard, a configuration option may be necessary.

[carchrae]

this is a good point. and indeed, handling all the different situations are tricky when developing a general purpose e-commerce system. several years ago, i was working with spree who have a DSL for the steps in the checkout https://guides.spreecommerce.org/developer/customization/checkout.html#the-checkout-flow-dsl that said, it was not great to customise because if you don't consistently apply the state machine pattern (they did not), the code becomes horrible and easy to have bugs.

i will keep thinking about a clean way to implement this that doesn't impact other cases. i'm really curious about @paroga's co-op with their printers and so on. our co-op is all paper and pens when we distribute the food. it isn't ideal since there is more data entry when things change, but it is an easy process for everyone in our co-op to use.

i guess you guys have some stats on the hosted foodsoft co-op sizes, like ordergroups, and so on. our co-op is around 25 ordergroups, and orders around 50-100 articles every two weeks (plus other specialised orders).

(an aside, i would love to change these terms, they aren't good english - ordergroup => account, article => product or item - i know i18n, but there are so many changes. i'll get to it someday!)