Materials tracking

In order to clearly separate subjects on the Excise duties on alcohol, tobacco and energy topic (EN/FR):

:star: A new Materials module

Materials are Products that have physical Measures (Length, Height, Width, Surface, Volume, Weight).

A lot of materials are tracked (ethanol, gold, carbon dioxide, asbestos, etc.), and so can serve as physical components into multiple products (spirits, jewelry, greenhouse gases, fibre cement products etc.).

For legal obligations, many Materials MUST be tracked in separate Inventory accounts (tobacco, alcohol, energy products, cannabis, narcotics, unhealthy products, products harmful to the environment, etc.).

Economy-wide material flow accounts (EW-MFA), as an international standard, is a legal base statistical accounting framework recording material movement (flow) of physical measures over a given accounting period as they are crossing defined ‘crossing points’ or ‘points of measurement’. EW-MFA cover solid, gaseous, and liquid materials, except for bulk flows of water and air (the general purpose of EW-MFA is to describe the physical interaction of the national economy with the natural environment and the rest of the world economy in terms of flows of materials).

So the new Materials module describe here Tryton’s fundamentals needs for basic double entry materials accounting, following the EW-MFA standard :

  1. It MUST allow any product marked as Material to be associated with specific stock accounting, accounting properties such as taxes, charges, expense or income accounts.
  2. It MUST make it easy to manage these properties using accounting categories, like Account Product and Customs modules help us to do.

The goal at this point should be to convert concepts into rough interface designs: for Getting Real, we start with the interface, the real screens that people are going to use. It begins with what the customer actually experiences and builds Tryton backwards from there. I hope this lets us get the interface right before we get the software wrong. :slight_smile:

  1. « Materials » SHOULD be Goods Products with a Material checkbox checked


  2. The Materials module SHOULD add the following Materials tab on the Product model


    • On peut ajouter une Matière à la liste, en précisant :


      • Matière (editable required)
        • Seuls les Produits qui ont la case à cocher Matière activée peuvent être liés
        • Une Matière ne peut pas se contenir elle-même
      • Quantité (de Matière dans le Produit, editable) : vide = quatité nulle
      • Mesure (de référence du Produit, editable) : seule une mesure Produit de même type que l’UDM par défaut de la Matière est sélectionnable parmis:
        • Aucune (équivaut à une quantité nulle, sans avoir à supprimer cette matière)
        • Quantité (de Produit)
        • Longueur (Mesure)
        • Largeur
        • Hauteur
        • Surface (pourqoi n’est-il pas par défaut dans le module Product Measurements ?)
        • Volume
        • Poids
      • UDM (par défaut de la Matière) : modifiable, avec une Unité de même type que l’UDM par défaut de la Matière
  3. Les menus Lots containing Alcohol et Locations Alcohol Volume deviennent obsolètes
    • On passera par les liens du Produit (ces derniers sont éventuellement filtrés en standard, par exemple en ne sélectionnant que les produits de type Matière)


  4. Tout mouvement d’une quantité d’un Produit contenant des Matières, induit le même mouvement pour chaque Matière, selon la quantité listée sur ce Produit.

To be continued…

1 Like

I do not understand this statement. For me stock accounting is per “product” not divided by its composition.

I think I understood. Here “accounting” is not used to refer to the modules account but just as tracking.
I think we should avoid to use the term “accounting” for anything else than the modules account.

For me the main issue with this design compared to Draft: Manage ethanol in stock (!40) · Merge requests · Tryton / Tryton · GitLab is that it does not support (small) variations of the materials quantity per product.
The composition of each product is fixed so in some way it does not collecte any new data as they can be computed based on the product.
Also the material tab is mainly the same as a bill of material from the production module.

Finally from a point of view of development I do not see any benefit to make a generic solution for any material than implement a module for each kind of material. This is mainly because with a specific module per material we can easily enforce constraint because we have a concret field on the stock move. While a generic solution will impose EAV model or Dict fields for which the data integrity are much more difficult to enforce.

Nope. In our conception a Material is a Product like the others, but with the Material flag checked. So stock accounting “per product” is steel OK with all (Material) Products.

No. Accounting stand here like in the “Account Product” module name, witch “allows products to be associated with accounting properties such as taxes and expense or revenue accounts. It allows these properties to be easily managed using accounting categories.”

No. “Composition” (ie only materials you want to track) for each products depends on laws and on your own productions focus.

So composition is not fixed: composition is not the same from an organisation to another: since a long time we track ethanol, yesterday we started track THC with cannabis legalisation, tomorrow CO² for environnement deals, and all for a same product (the same pint of beer :beer: :-).

Come on man, have a kick look to Economy-wide material flow accounts (EW-MFA) international standard, “a legal base statistical accounting framework recording material movement (flow) of physical measures over a given accounting period as they are crossing defined ‘crossing points’ or ‘points of measurement’”…

Then I do not understand the goal of this proposal.

I did not read the 150 pages but as I do not understand the basic concept of the proposal, I do not think I should start reading.

So sorry, niether do I: you’re right… I overlooked functionnal capacities of the “Account Product” module ! :slight_smile:

OK, I understand that point, and I trust your core dev experience. :slight_smile:

You pushed me outo my entrenchments…

I think, finally, this was the main reason for my proposal: can we get more “user flexibility” by giving to him the possibility to point the product to track?

I mean, with alcohol actually tracked by stock_ethanol and production_ethanol modules:

  • Can we give user the possibility to set the Ethanol Product (as we can set Ethanol Product Adjustment)?

    (*) Ethanol Product, as Ethanol Product Adjustment, must be a Product that Contain Alcohol with Alcohol By Volume = 100
  • Where is the right place to set that configuration?

Refactored proposal

  • The module Stock Ethanol should add Ethanol Product and Alcohol Volume UOM fields on Products/Configuration:
    • Ethanol Product must be a Product that Contain Alcohol with Alcohol By Volume = 100
      • Since a product is selected as the Ethanol Product, his Alcohol By Volume cannot be modified
    • Alcohol Volume UOM is to “support (small) variations of the materials quantity per product”.
  • Les menus Inventory & Stock / Locations / Locations Alcohol Volume et Inventory & Stock / Lots / Lots containing Alcohol ne sont plus utiles: on peut passer par les liens standards du produit Ethanol Product (sinon, à terme, il devra y avoir deux fois autant d’entrées de plus dans le menu que de produits à suivre)
    image

I do not understand.

Why? We do not need such thing.

Why on product configuration, it is only needed for the stock (where it is already configured)?

[FR] (My english is poor…)

Le draft des modules Stock et Production Ethanol fait le job a minima, et c’est bien.

Mon problème c’est qu’en l’état, je me sens trop contraint (voir limité) pour les cas d’usages clients: je ne peux pas utiliser les fonctionnalités Tryton disponibles par défaut sur les produits.

Par exemple:

  1. Pour l’alcool: les distillateurs (et les Douanes surtout!) ont besoin de voir l’évolution du stock d’éthanol dans le temps, comme Tryton nous le permet déjà pour n’importe quel produit via le graphique Product Quantities By Warehouse.
    Or là, si on veut aussi afficher l’alcool (et les autres produits à venir) sur le graphique, il faut qu’on fasse un dév spécifique :frowning:

  2. Pour appliquer des droits d’accises sur l’ensemble des produits qui y sont soumis (je rappelle que 190 000 entreprises utilisent déjà le système EMCS en Europe et, c’est aussi ça le marché de Tryton), il faudra rajouter autant d’entrées dans les menus que de produits suivis.
    Or, il y a plus d’une dizaine de produits à suivre au même titre que l’alcool (le tabac, le sucre, le café, le chocolat, les produits agricoles, les produits pétroliers…).

Par contre, si on arrive à améliorer ces modules avec un meilleur compromis performance/généricité, de façon à ce que je ne sois pas bloqué face à ces cas d’usage, je pourrai vendre Tryton (quasiment) les yeux fermés (au développement spécifique près) comme solution sur de problématiques d’accise et de comptabilité matière…

C’est ça mon problème: ça marche, mais c’est trop spécifique et j’aimerais faire en sorte que les utilisateurs soient plus autonomes en termes de paramétrages (même si pour chaque nouveau produit à suivre il y aura des dév spécifiques).

Notre proposition du module Excise va dans ce sens (en complément du module Account Product).

L’information est déjà là mais dans un autre champs (il faudrait juste que compute_quantities_query puisse fonctionner sur un autre champs que internal_quantity).
Pour moi le manque d’une vue ne justifie pas la duplication de mouvement de stock pour just pouvoir réutiliser celle-ci.
En fait je pense que plus on poussera vers plus de fonctionnalité pour la gestion d’ethanol plus on améliorera la base qui permettra d’inclure d’autre gestion similaire plus facilement.

Je ne comprend pas.
Évidement il faudra créer les produits qui sont géré par la société et les configurer par rapport aux accises s’il le faut. Je suppose que la plus part ont une contenance fixe et donc un montant d’accise fixe par quantité. Pour les autres qui serait plus artisanal, il faudra une gestion de stock comme le module ethanol.

Ah, je comprends mieux: je n’avais pas capté qu’il n’y avait pas de véritable mouvements de stock pour l’alcool (et qu’en fait ce sont uniquement les Produits, qui eux contiennent de l’alcool, qui sont déplacés, et pas l’alcool en tant que Produit)…

C’est juste mais pas complète. En fait pour chaque mouvement de produit on stock aussi la quantité alcohol déplacé. Du coup on a 2 colonnes sur le mouvement internal_quantity et internal_ethanol_volume. Et rien n’empêche de faire les même calcule sur internal_ethanol_volume que ceux qu’on fait avec internal_quantity.

Donc, si je comprends bien, le graphique Product Quantities By Warehouse (compute_quantities_query) affiche l’historique du champ internal_quantity des produits sélectionnés, mais pas (encore) la colonne internal_ethanol_volume des produits sélectionnés, c’est ça?

Donc, pour l’alcool, il faudrait dire que

  • "le graphique Product Quantities By Warehouse compute aussi la colonne internal_ethanol_volume des produits sélectionnés,
  • si il y a au moins un produit Contain Alcohol dans cette liste".

Si c’est ça, alors OK.

Moi, je sais donc que quand on rajoutera l’or par exemple, ce sera la même logique (même si c’est un dév supplémentaire):

  • si j’ai sélectionné un produit contenant de l’alcool et un autre contenant de l’or,
  • sur le graphique Product Quantities By Warehouse,
  • j’aurai affiché par défaut l’historique du champ internal_quantity des produits sélectionnés,
  • mais aussi les champs internal_ethanol_volume et internal_gold_weight (qui ne sont des produits, mais seulement des quantités déplacées).

Et ça, je peux le vendre… :slight_smile: