What it does
Base module for the Viindoo Point of Sale suite. It:
- Adds one activation page inside Point of Sale Settings to turn each Viindoo POS
feature module on/off (with an upsell link when a module is not available).
- Provisions, with zero configuration, exactly one analytic account per Point of
Sale (in the POS' own company) and stamps every POS invoice / session journal
line with that account at 100%, merged into any customer-configured analytic
distribution so other-plan entries are preserved.
- Enforces an offline-safety authoring convention for every Viindoo POS module so
the till keeps working through a mid-session network drop.
- Adds the human-readable bank name / account number / account holder next to the
QR on the native Point of Sale payment popup for a qr_code payment method
(a graceful no-op on any other method).
Editions Supported
- Community Edition
- Enterprise Edition
Viindoo Point of Sale
viin_pos is the base of the Viindoo Point of Sale suite. It auto-installs with
point_of_sale and provides:
- an activation page in Point of Sale > Settings to turn each Viindoo POS feature
module on/off (with an upsell link when the module is not available);
- always-on, zero-configuration POS analytic accounting - one analytic account per
Point of Sale, in the Point of Sale's own company, stamped at 100% onto every POS
invoice / session journal line;
- the offline-safety authoring convention below;
- readable bank name / account number / account holder next to the QR on the native
payment popup for a qr_code payment method (a graceful no-op otherwise).
Offline-safety convention (mandatory for every Viindoo POS module)
"Offline" here means surviving a mid-session network drop (a network blip while a
live POS tab is open), not cold-boot offline (a hard reload with zero connectivity
cannot boot the POS - core has no catalog/config IndexedDB fallback).
Reaching the till with a new field
A model that adds a field the POS JavaScript reads MUST make it reach the till by ONE of:
- inheriting pos.load.mixin and overriding _load_pos_data_fields(config_id)
(call super() and append the field name) for its own fields; and if it adds a
brand-new loadable model, ALSO override
pos.session._load_pos_data_models(self, config_id) (super() then append the
model name); OR
- relying on the wide-open-model exception below.
The wide-open-model rule
pos.config and pos.order have no field allow-list in core, so a plain new
field on either reaches the till automatically with no override. Every OTHER loadable
model (pos.order.line, pos.payment.method, product.product,
delivery.carrier, product.return.reason, ...) DOES need the explicit override,
and a forgotten one fails silently (the field reads undefined, no error is
raised). Defensive recommendation: add an explicit _load_pos_data_fields
super() + append even for pos.config / pos.order fields, as cheap insurance
against core adding an allow-list later.
Forbidden dead 17-era loaders
The following silently no-op on Odoo 18 and MUST be deleted, never carried:
_loader_params_*, _get_pos_ui_*, _pos_ui_models_to_load, _load_model,
_pos_data_process, load_pos_data().
ConnectionLostError fallback (enforced, not just documented)
Every catch branch handling ConnectionLostError / ConnectionAbortedError in
POS static/src MUST return a value shaped identically to the try-block's success
return whenever the call site destructures the result - NEVER a bare return; /
swallow (which yields undefined and makes the caller's destructure throw). This rule
is enforced mechanically (a lint / CI gate over */static/src/**/*.js), because the
one class that actually crashed the till offline was previously guarded only by prose.
Feature-activation availability - transitive-dependency limitation
The Settings toggle for each feature shows a checkbox when its module is available and an
upsell link otherwise. Availability is a presence check on the module's own
ir.module.module record
(bool(env.ref('base.module_<name>', raise_if_not_found=False))); it does not
check whether the module's transitive dependencies are installable. So a chained-dependency
toggle - POS BIDV Bank QR (needs payment_bidv_viin + viin_pos_qr) or
POS Online Payment QR Code (needs pos_online_payment) - can show as available yet
fail to install when a transitive dependency is missing, surfacing a raw dependency error
on save. This cannot raise (the lookup uses raise_if_not_found=False); it is a
UX-honesty gap, not a crash. Install the paid / base dependency first.
This software and associated files (the "Software") may only be
used
(executed, modified, executed after modifications) if you have
purchased a
valid license from the authors, typically via Odoo Apps,
or if you
have
received a written agreement from the authors of the
Software (see the
COPYRIGHT file).
You may develop Odoo modules that use the Software as a library
(typically
by depending on it, importing it and using its
resources), but
without
copying any source code or material from the
Software. You may distribute
those modules under the license of your
choice, provided that this
license
is compatible with the terms of
the Odoo Proprietary License (For
example:
LGPL, MIT, or proprietary
licenses similar to this one).
It is forbidden to publish, distribute, sublicense, or sell
copies of the
Software or modified copies of the Software.
The above copyright notice and this permission notice must be
included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT
SHALL THE
AUTHORS OR COPYRIGHT HOLDERS
BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN
ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING
FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE
SOFTWARE.
