Point of sales

[maxky]

Stock takings seem to be very cumbersome. I'd like to have a fool proof point of sales, that can be operated with only a bar code scanner. I am willing to put development effort into that.
Is already any development on the way in that direction? If not so, is anyone interested in joining me?

Yours, Max

[maxky]

There is a discussion on stock takings here: http://foodsoft.51229.x6.nabble.com/How-to-work-with-stock-articles-td1458.html

Does it still reflect the state of the art?

[paroga]

How much work are you willing to put into development? What is your exact use-case? Maybe I can give you some hints and tell you the missing/existing parts, if you give more information.

There are multiple things to consider a "correct" solution, since stock management isn't a strength of foodsoft yet. My current vision includes handling for stock-order independent stock-takings and management of price changes.

[maxky]

Use case: I want equip a small closed room with about 100 different
stock articles. Members can enter at any time and take whatever they want.

Here's my vision for the basic check out work flow:

  * Switch on computer
  * Scan the bar code on your member card
  * Scan the bar code of every item you have taken
  * Review list shown by the computer
  * Accept by scanning a bar code labelled "Accept"
  * Switch off computer

After that, the total amount spent must be debited from the account of
the ordergroup of the member.

Additionally there should be a bar code around for cancellation (and
maybe some for numbers, for the case of taking larger quantities). The
computer can be small, it must be capable of running a lightweight
browser. It should boot very quickly or have low standby power consumption.

Yes, we need stock-order independent stock-takings for this. What is the
problem with price change management? The stock articles could just be
sold for the latest price.

I am willing to spend a considerable amount of work, but it is a low
priority project.


Am 02.05.21 um 18:15 schrieb paroga [via foodsoft]:

> How much work are you willing to put into development? What is your
> exact use-case? Maybe I can give you some hints and tell you the
> missing/existing parts, if you give more information.
>
> There are multiple things to consider a "correct" solution, since
> stock management isn't a strength of foodsoft yet. My current vision
> includes handling for stock-order independent stock-takings and
> management of price changes.
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the
> discussion below:
> http://foodsoft.51229.x6.nabble.com/Point-of-sales-tp7462p7465.html
> <http://foodsoft.51229.x6.nabble.com/Point-of-sales-tp7462p7465.html>
> To start a new topic under foodsoft-dev, email
> [hidden email]
> To unsubscribe from foodsoft-dev, click here
> <
> NAML
> <http://foodsoft.51229.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

[maxky]

Hi @paroga,

we are dedicating a little hackathon  this tuesday (Okt 25) till thursday to the point of sales project.
So every information/idea you can give us will be appreciated.

yours, max

[paroga]

I'd suggest to avoid a special piece of hardware (computer with barcodescanner) and suggest to implement this as an Progressive Web App instead. This has the big benefit that everybody can use it on their personal device, which is directly connected to the correct ordergroup and can be used in parallel. For people without a personal smartphone, e.g. a shared smartphone/tablet could be available at the pickup place.

Your UI implementation should be able to work seamlessly with orders too. If you ordered something upfront your UI should show you your ordered items, which you then acknowledge with the correct received amounts. See the self-checkout-implementation in foodsoft issue #766. But I don't see that as a must in a first step, just to be aware what should be possible.

> What is the problem with price change management? The stock articles could just be sold for the latest price.

NO! If the foodcoop is legally not allowed to sell articles with a different price, you need to track the price of every stock item. Old items with e.g. a lower price must be sold with the lower price, while when the old items have been sold the new stock items must be sold with the new e.g. higher price. It's possible that identical items in the same "order" have different prices.

I did already some work to support that more easily in the data model in commit 785313a. The data model should get a new `OrdergroupStockTaking` as a subclass of `StockEvent`, which links it directly to a `FinancialTransaction`.

I'd suggest to try to make the changes to the data model (with the corresponding model tests) first and then create a PR for that. Then create a PR for fitting API endpoints (with tests) and then add some UI.

Another thing to consider is the ability to track rottened/expired stock articles. E.g. if you have a box of apples and some need to be thrown away that must be tracked somewhere, to sell them for correct price.