fresh workflow: receive different weight than ordered

[Cor-Jan]

At the moment we can only add the exact amount to the bill based on the price of a product and quantity of that product that it has ordered.
We want to sell vegetables and fruits, and later also other products we will sell without packages with fixed weight. The issue is that it is not possible to get the exact weight as ordered because carrots or pumpkins are never the same size/weight.

Solution proposal:
With products (like veggies/fruit) sold per kg without fixed quantity packaging, add functionality that the person dividing the veggies/fruit can enter the amount of a product that he/she has allocated to a certain member.
Foodsoft currently keeps track of the amount that members ordered as well as the amount they received. To make this work, the system has to accept irrational numbers (e.g. 0.8 kg, 3,67 kg) (#101). Members still can have ordered in pieces (like pumpkin) or weight (like cherries) - both need to have the ability to bill by weight.

The amount ordered by the member is an indication to allocate a certain amount of the amount that is delivered of that product to that member. The member who divides the veggies needs to see what is ordered, puts an amount of the right veggies on the scale until it is near what the ordering member has ordered. Then he enters the amount in the system, if it is different.

[wvengen]

It would be useful to split the current "balancing" screen (in foodcoop-adam also called "receive") into a number of different screens. Let's look at the workflow (for fresh products):

• After the order was placed with the supplier, he might respond with a bill. This may be different from what was ordered, depending on availability. It would be useful to enter this before the pickup day. When this is entered into the system, the member orders are updated (perhaps with an explicit note and/or notification).
• On the pickup day, everything is weighed, and weights are put into the system. If it differs from the bill (if any), products need to be re-distributed over members according to what they ordered.
• Then veggie setup distributes everything over the members. For us this typically happens per product. The veggie setup person takes all tomatoes, for example, and then weights the amount allocated to each member. If the amount end up being different that indicated (e.g. when the tomatoes are very big), he enters the real amount into the system, so that he member is properly billed.
• Different teams may work at the same time, though usually it is on different fresh products.
• When everything is finished, some stuff may be left, which can go for direct sale. It'd be useful to check if the total weight of all products incl. direct sale is equal to what came in.

This would be possible with the following screens:

• receive - used when bill comes in, as well as on weighing the amounts received; member orders will be updated; with the option to send a notification to the members that have their order changed as a result (not used on pickup day, though)
• distribute - used by veggie setup to distribute products; could be a list of products with member orders with the option to enter the amount; even better, probably, a screen (also usable on mobile), showing a member order for a product with the amounts ordered, allocated, and received (the last to be filled in).
• checkup (or something) - used after veggie setup to check total amounts and provide a way to detect and fix errors; perhaps this one is not necessary - let's focus on the other two first!

[wvengen]

So there's the user-interface side (see previous comment), as well as the data model. The latter entails supporting fractional amounts (like 0.6), and possibly as well supporting different units for distribution (like ordered in units, distributed and billed in kgs).

Before checking in changes that affect the product distribution code, I'd like to have (unit) tests in place. That's work in progess (see foodcoops#120 and tests-rspec). But we can start on the fresh flow anyway - just before merging it into master, I'd like to be really sure that existing functionality does not break.

[Cor-Jan]

i love the proposal; would change 1 thing.
differentiate between entering invoice (probably done by finance) and entering the actual weights of the delivered products in the system (probably done by the people doing the distribution)

[wvengen]

@Cor-Jan does this need different screens, or could both people (invoice and receive delivery) use the same screen for that?

[Cor-Jan]

i would prefer different screens. to make shure there is no mixup in data ! and that the tasks are easily seperated; also for showing them sepererately in task area on dashboard

[wvengen]

The question is: is it necessary to have both the amount ordered, the amount billed and the amount received as different numbers in the system? Currently there is no difference between those numbers. Is that desirable? Irregardless of whether that data is needed, we can provide different links and displays from the dashboard.

This would require adding these amounts to the data model.

[Cor-Jan]

these numbers are all relevant for contact with suppliers and accounting.
account billed and amount recieved are very relevant for paying suppliers,
to communicate what to pay
about ordered amount: sometimes suppliers send different products than
ordered. if this happens structural, i would like to see it in the system.

On Fri, Jul 19, 2013 at 11:41 AM, wvengen [email protected] wrote:

The question is: is it necessary to have both the amount ordered, the
amount billed and the amount received as different numbers in the system?
Currently there is no difference between those numbers. Is that desirable?

This would require adding these amounts to the data model.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-21240640
.

[wvengen]

Ok - let's put this in too. So we'd like to have the following quantities in the system ( (*) = currently in foodsoft):

• Each member's ordered quantity + tolerance (*)
• An order's total quantity (+ tolerance, but that's not really relevant) (*) - fixed when order is closed
• Amount ordered at supplier (we could use total the previous one for this, but those might be different)
• Amount billed by supplier
• Amount received (*)
• Each member's received quantity (*)

[Cor-Jan]

perhaps we could set the interface like #98

[wvengen]

work moved to branch fresh-flow, so that we can easily merge it into upstream

[wvengen]

Quantities are being tackled in foodcoops#222. Fractional units for member ordering are found in #101. Then this ticket is for entering kgs in the receive screen. Probably involves changing integer -> numeric in the database. Need to check if this affects performance.