Definition/Specification #3

5 Functional Requirements OS, Drivers, Low Level Overview of required functions

Added by Juergen Weber over 2 years ago.

Start date:
Due date:
% Done:


Estimated time:


(Section 5 of EVENTOS eco-system with Self-Service-Kiosk)

The functional requirements describe the core functionality of the application. This section includes the data and functional process requirements. REMARK. Functions described in setup with a EVENTOS Self-Service Kiosk. Besides Kiosk Front-End, our Middle-Ware and the Backend must serve also SELFI and INTELLI-FRIDGE.

5.1 User Inter-Action at Kiosk: Scan a good/ or goods for purchase
Input: User may scan his goods, or a single product; identifies himself with ID card (NFC) or by smartphone (NFC/Bluetooth LE/Wi-Fi) /or proceed as a guest (unregistered)
Output: trigger payment terminal, print receipt or send receipt by email or load into App database | Update ERP database about products sold and store the transaction data
5.1.1 A customer shall be able to scan his goods he wants to purchase at the Datalogic Magellan 3200vsi scanner, which is a build in module in the self-check-out kiosk
5.1.2 The customer shall be able to scan the barcode or manually enter a code number instead – optional he shall enter the shown weight & code number which is printed on the label of a fresh packaged good.
5.1.3 He must be able to read nutrition information and description of the good, presentation in pop up window on screen.
5.1.4 He must be able to scan up to 20 different products (#.t.b.d) Limitation by the software is not needed.
5.1.5 He must be able to choose his language, English, French, German, eventually later other languages. Language package must be easy to add on by the admin. Also all other ocuntry specific settings.
Must The user must choose EAT-IN or EAT-OUT . The background for this choice is, that we do have in Germany two different VAT sales tax rates for food and drinks (non-alcoholic) to be consumated in the premise 19%, versus when takenout it is the lower rate of 7%
Depending on the customers entry-point he will have to opt as one of the first screens (03 EAT-IN/EAT-OUT wireframe) or if entered direct to scan page (07 wireframe) then he can change the default version when reviewing the cart, while checking out. (08 cart review). Database fields required accordingly.
5.1.6 The customer shall be able to click on Help button to get connected to Help Service (t.b.d) Help button shall be on same position on all screens.
In a phase to be defined, customer will have the chance for vidoe/or audio communication with a help agent
5.1.7 Once the Language of choice has been selected, all operations and results on the website shall be for the same language. Back end must also be Multi-language
5.1.8 When the customer searches for the various information after choosing the appropriate fields, the UI shall fetch the details from eVentos backend.Transactions for speed reasons shall take the data out of the local database, only when not stored locally, application shall fetch data from ERP back end.

SEARCH: Most probably only applies when a lunch meal is searched.

PUSH info of changed info to all or selected kiosk or other front-end devices.
Only entry point to make price changes is done in the ERP module!
5.1.9 The user must see the tax and the bottle deposit within the billing info before he will have to pay.

When his employer subsitutes his purchase, this amount must also shown.
5.1.10 By clicking on checkout and pay button, he will be presented all available payment options. Those depends on location/kiosk or user (registered or guest)
5.1.11 When cash-less option is taken, in case of all Credit- and Debit-Cards, no matter which standard the execution will be done via the payment terminal, which is to be handled accordingly to EMV requirements and in Germany also accordingly to the banking association, ZVT protocolls and requirement

5.1.12 We may handle directly without the payment processor (external supplier) the billing process for the employees, to be deducted from the payroll, also we may execute our own Wallet Prepaid/loyality card [Vitalitycard/-app] solution internally, but may follow strict PCI requiremens.

Phase II
5.1.13 The result rendered on the kiosk display or App shall be sortable by class, price or name (class= beverage cold/hot, Snacks, Food, Special Food. Not applicable for scan product string. Sort only needed when Food pre-oder is active.
5.1.14 The customer shall be able to choose to get a receipt: a) as print out at kiosk; b) sent to e-mail address; b) sent to his App; t.b.d integration of we-chat or what´s up
5.1.15 A customer will have in some kiosk location the option to pay in cash. However the intention is, that a transaciton can not be paid in cash, as we have no technical feature to return the change!


Banknote Acceptor will be in a separate unite called “The Side-kick”. Our standard kiosk will have no banknote accpetors build in. User may load on the Side-kick his Vitality NFC Card or Vitality APP as such.

Optional the “Side-kick” will have a dispensor for Vitality-un-registered guest cards. He may obtian in one-transaction of XX EUR a card, which is charged with the amount he has choosen. Return of such card must be analyzed how to realize a possible return.
Using acceptance hardware for return process is costly! (May be return by mail!?!)
5.1.16 All information shall be stored locally and on the Server based Business Logic. All local data will be erased after xx hours (t.b.d). local storage shall be encrypted and only used for speed transaction (See for reference Catapult ECRS) Sync Process to be discussed!
5.1.17 Options on the kiosk are My Account . Enrollment possible on Kiosk or on dedicated responsive Web Formular. Enrollment not possible on Rush Hours!
Enrollment of the fingerprint sensor must be on the kiosk itself- as the smartphones sensor cant be used.

Enrollment process may take time? Preferrably not during lunch break…..

May be we need to use a Notebook of Operator to do a face-by –face entrollment.
Further investigation is reguired.

Use is not
Within MVP
5.1.18 Further option to pre-order special meals…… contray quick transactions within rush hours
Phase 2
5.1.19 In case the customer abandons a transaction half-way through the process, the lock on the record shall be released after 5 minutes.
5.1.20 While doing the check-out, a picture will be made of consumer and stored in encrypted way.

ATTENTION: We must be comply with new Privacy Rules in EU.

Storage of such in the ERP or in the Video Suveilance Files??
5.1.21 Cancellation process to be defined when good(s) shall be given back.
Entire Business Case must be role defined

IN Software and Physically
5.1.22 Type of goods as above: Beverages, hot and cold, Snacks packaged, Food standard offerings, Food fresh daily, Special pre-order Food, others…

SEE user-story: Colombia for Hot Drinks

5.1.23 After the personal details are collected from the customer by the use of his workplace ID card or the Vitality Wallet ID card, the browser shall be redirected to the payment screen.


User can pre-register online on a website/app. First use he can enter a PIN at the kiosk for verification. APP can be used directly. Physical card must be send to him by mail (picked up at agreed time from local operator (franchise partner)
5.1.24 Registered users or guests can start scanning without identification!

This is a gread advantage of the kiosk version in opposite toall other autmated ways of retail shopping!
5.1.25 For mobile app based reservations, All payments shall be done through HTML/web based screens and not through in-line payment. This will ensure that EVENTOS doesn’t pay heavy commission to Apple or Google.

Verification required with payment provider when we accept Credit Card or Debit Card Payment, otherwise than loading the Vitaltiy Account.


Inquiry made with BaFIN to learn regulation of new PSD2!
5.1.26 The change from mobile app to the web based payment screen shall be seamless.
5.1.27 On successful completion of payment, all transaction data with time stamp codes shall be stored and made accessible for further use within ODOO ERP software, preferable stored in one common db.
5.1.28 The session can be started in a multi-way approach. See Image: Image 05: Start-System Wake-up and Entry Screens

 By Finger, when touching the display in stand-by mode.
 By Barcode on a product, when moved in front of the scanner
 By NFC card/Android App when registered user
 By Bluetooth LE and iPHone when registered user
 By barcode, when the employees ID card has a barcode printed on card

Any of those methods may bring the customer to either a dedicated side or the SCAN GOODS page directly.
5.1.29 In Germany employees may get a tax free grant as substitute by their employer. This must be settable at the proper check-out step. Tax rules apply and must be managed in the general settings.
5.1.30 Database and Setting fields for the different options in tax saving plans for employee´s
Phase 2
5.1.31 Must
5.1.32 Must
5.1.33 Must
5.1.34 Must

Also available in: Atom PDF