-
Notifications
You must be signed in to change notification settings - Fork 0
General Design and Workflow
The POS application will consist out of two parts: the client application (Electron app) and the server application (Django app).
The client software can be run from any location (with a connection to the server). On start, a terminal needs to be registered. This can be done by entering a "code" that can be generated in the admin area. The admin area has the ability to crud terminals (with a name and other relevant properties).
Products can be managed through the admin area. Products can be placed in product categories.
The terminals can retrieve products via the API. The idea is that category switching and searching get done on the client side, since the data is relatively static. Periodic updates can be done to ensure new products and changes to existing products are made visible on the client. Can optionally also be done using sockets, or only by pressing a manual update button.
Once a terminal is configured (has to be done once, see terminals), a session opening screen is shown on the terminal every time it starts. Users have to enter their name and select the correct event (see events). Once they press the next/start button the main POS screen for active sales will be shown.
This screen will feature a button to close the session as well. The closing user has to enter their name, as well as the total amounts of the PIN terminals (currently haven't thought out how to make this more generic than just two fixed inputs (specific to our case)). When the user presses close, a ticket is printed with all totals.
Sessions can be reviewed and exported in the admin area.
Orders will at least have the following fields:
- Session ID
- Payment Method
- Order lines
+ Product lines (but with a copy of the price/description etc.)
+ Custom product lines
All interactions for creating orders is done on the client side. Only the complete order, including the payment method, gets sent to the backend.
Maybe we need to add an undo last order method or something, to allow for corrections. However, this can be done in a later stage.
Events can be managed through the admin area. Events can be retrieved by the client using the API. Examples of events are: EatingOUT, movie night, Outsite, MIXUP, etc.
Payment methods can be managed through the admin interface. For now, these payment methods will be very trivial and have no special behavior. They are only used to see what money went were (PIN, cash, staff, etc.).