# plenty - a buyers club module

This is a description of the minimal viable product needs for a system that is able to handle ordering and settle credit in a buyers club. The process and flows here are modelled to fit with how we work now in Röstånga.

In general anyone in the buyers club is free to start an order process from any supplier, gather what everyone wants to order from what is on offer with that supplier/producers and send that order to the producer.

The order is then delivered to the buyers club space and is checked and sorted for each member that has made purchases in that order. Once the order is checked the member is sent the final summarized price of the products they ordered and send the money *(this could change a little with the credit system)*.

The money is revieved and the invoice to the supplier/producer is paid. Everyone eats well.

### Learning from REA meeting - sept 22
Price is an intent - valueflows doesn't care what a resource is
a proposal would contain an intent around berries and one around crowns
proposal - I am offering x apples - includes intent for apples and intents for crowns (in crowns, put reciprical true)
- one intent has farmer as provider - intents get merried into commitments - Alice is provider of apples, Bob is provider of crowns

- thresholding - second order commitment - an intent for intents

### Future embedding
The next layer out that could be built with REA is the bioregional layer of producers where we enter to list and find things (lots of things that hylo are also doing)

### Functionality

#### Ordering
- Users should be able to add a supplier/producer
- Users should be able to add, update and delete products
- Products should have a supplier (supplier/producer), price & quantity
- Users should be able to initiate an order
- An order should have three state properties (**Open, Closed, Completed**)
- When initiating an order, the user should be able to set a threshold limit that must be exceeded for the order to be sent (defaults could be set to each supplier/producer)
- An order should be connected to **ONE** supplier/producer.
- The user creating an order should be able to set an end date for last entry into order
- Whoever initiates the order should be the order manager, unless the manager property is assigned to another user
- When an order is created, the creator should be able to select which products are included in the order (and add/remove products during the time until order is closed)
- The order manager should be able to close the order, so that users can no longer add purchases to the order.
- If the order manager deletes a product in an order in the "Open" state, all purchases made by users to that order should be deleted.
- The system should be able to export an order to PDF (also maybe JSON/XML/...)
- The system should also be able to export a view of an order with a line of each product and what user has ordered what quantities (for sorting)
- The system should also be able to export a view of each persons "part" of an order
- When an order is recieved, the order manager should be able to request to edit any purchases (deleting or adjusting quantities) connected to that order so that the order reflects what was deliverd accuratly in case of missing products etc.
- The users should be able to approve the requests for changes of their purchases.
- Once delivery is checked to accuratly reflect the order, the order manager should be able to set the order status to completed.
- When the order is completed, users should be debited credit based on their order.

#### Credit settling

- Users should have an internal credit and a view of their current credit
- Users should be able to submit that they have topped up their credit
- An assigned user (the organisational book keepers) should be able to confirm the credit submissions (by validating them on the bank account).
- Users should be able to make purchases through the orders and be automatically debited credit
- Users should not be able to go into negative credit (maybe later.)

#### Accounting needs
In order for the transactions to be easily handled by the organisations accounting software (legal) then it would need to be able to output summaries that are batched for last month. They would need to include:
- per user, money sent to the organization (the base for the internal credit), this will a credit for that persons account in bookkeeping
- per user, all the last months purchases, summed up (with correct VAT, in Sweden it differs between say food (12%) and soap(25%))
([SIE](https://sie.se/wp-content/uploads/2020/05/SIE_filformat_ver_4B_080930.pdf) is the filestandard for bookeeping that we would want to export in)

### Ordering flow

flowchart TD
    A[Alice initaties order and becomes order manager] --> B[All users can add/edit purchases]
    B -- At end date --> C[Alice closes order]
    C -- Alice communicates order with supplier --> D{ok, for delivery?}
    D -- no, availability/products edited, order re-opened --> B
    D -- yes --> E[Alice sends order to supplier]
    E -- order delivered and checked --> F{does delivery reflect order?}
    F -- no --> G[Alice edits user purchases to reflect order]
    G --> H
    F -- yes --> H[Mark order completed]
    H --> I[users debited amount of total purchases in order]

### Entries

- User (name, adress *(for mapping)*)
- Supplier (name, contact info, location)
- Products (supplier, name, article ID, quantity, price)
- Orders (orderstate, Supplier, Products[])
- Purchase (User *(in header?)*, Order, product, quantity, sum *(price * qty)*)
- Credit?

## Validation

**Order validation**
- All users should be able to add/edit/delete Products & Suppliers
- All users should be able to initiate an order
- Only the user that initiated an order (order manager) should be able to update what products are in an order
- Only order manager should be able to edit purchases for orders that are closed

**Credit validation**
- Any user should be able to appoint a book keeping role to another user
- Only users with book keeping roles should be able to validate credit additions
- Users should not be able to go into negative credit