When starting with tryton, you need to know which modules you need to activate according to your specific requirements. I could find a little description of some modules, but not a checklist, which briefly describes what every module does / for what it’s useful. Please let me know if such a checklist exists and I just could not find it.
Please dont argue module names are self-explaining. They may be to the experienced user. They are NOT AT ALL to the newbie.
Here I created a list of modules available in 5.4. I tried to create a editable table in dropbox, but failed. Could someone be so kind and provide a good solution, dropbox certainly is not the optimum?
My suggestion for columns is (comments welcome):
name | description | type of enterprise it’s typically used | frequency of occurence (*, ** or ***)
Esp contents of column 3 and 4 are debatable, but bare in mind:
This table should mainly give an orientation to the beginner, “soft facts” are very useful here.
The last column (e.g. filled with * “rarely”, ** “often” or *** “essential for nearly any enterprise”) could be an indicator whether the newbie is likely to need the module or not.
If everybody who reads this just fills a handful of modules, we’re done quite quickly.
Cheers,
Wolf
(the strange guy with the docu fetish,
who was appointed “user of last month” my the system… )
(guess just for the fact of annoying everyone with yelling “I don’t find it in the docs”…)
Yes, I found that. My problem is that I cannot place it side-to-side near the module list, identify each module one by one and choose it or not. And the latter is what the beginner has to do.
Actually, I do not understand the order in the docs. In the web app, it’s strictly alphabetical, which I think is a good thing. In the docs, it seems to be half/half. So it’s complicated to find the explanation. A tiny bit is that the module name prefix in the app often, but not always corresponds with the headline in the docs.
Another example:
There is a module called “ir”. How should I know what it is? - It’s not listed. I have to search the docs to find that it’s the very essential basic module. Confusing…
In addition, contents are a little sparse, my “columns 3&4” are not covered at all.
AFAIK, the IR stands for Information Repository. There is also the res module which stands for Resources. Both are internal ‘modules’ of the Tryton server, shipped with it and both are always activated in a Tryton database.
Their functionality can be seen at least in the Administration-menu entry.
The “type of enterprise a module is typically used” is hard to answer in Tryton.
The modules are developed for a general purpose. They usually solve a problem in a generic way. I can not imagine one module which can be used typically in one enterprise. For me this information would be
at least misleading, but mostly wrong.
The “frequency of occurence” is hard to answer, because we as a project can’t have a clear view, where, why and how often a module is used. All distribution channels of Tryton can be used anonymous.
@josesalvador
I’m well aware that “columns 3&4” are very hard to answer precisely. It’s “soft facts”, giving you an impression. If I know “used rarely” - then my really small business is not likely to need it. It’s not about numbers, just about sharing the experience “module abc” is discussed very often, “module xyz” occasionally and “module ghi” hardly ever.
Please always bare in mind:
the beginner knows very little. Every bit of info is helpful.
The beginner does not setup one ERM, but quite likely has been on a journey with quite some ERMs to evaluate. Tryton may be his #12 (it’s #6 for me - count only the serious attempts). So he needs to achieve a quick overview.
@ced
Great you’re acting so quickly.
I’d highly appreciate if the list of modules in the app and the docs do correspond.
The docs come from the doc directory inside each of the standard modules, this means that they should correspond.
I can see what you are trying to do with the list of modules, but I am not sure this is the best way of looking at the problem of which modules are needed.
The reason I am saying this is because, for example, the currency module is almost certainly used by every company that uses Tryton, but practically no one will need to decide to activate it. It will get activated automatically when you activate one of the modules that depend on it. So it would be a *** in column 4, but when choosing which modules to activate, you’d just ignore it.
However, having said that here is a list of the first two lines of the docs for each optional module, which may get you closer to the list you are looking for.
account | The account module defines fundamentals for most of accounting needs.
account_asset | The account_asset module adds the depreciation of fixed assets.
account_be | The Belgian account module defines the standard chart of account.
account_cash_rounding | The account_cash_rounding module allows cash amounts to be rounded using the cash rounding factor of the currency.
account_credit_limit | The account_credit_limit module manages credit limit of parties. A "Credit Limit Amount" is added on Party. The module allows to check for a party:
account_de_skr03 | The German account module define the SKR03 chart of account.
account_deposit | The account_deposit module adds support for deposit accounting. A deposit is an amount paid by the customer prior to the company providing it
account_dunning | The account_dunning module adds dunning for receivable move lines.
account_dunning_email | The account_dunning_email module sends a dunning email to the party email contact after the process of dunnings for those which are at a level with *Send
account_dunning_fee | The account_dunning_fee module allows to generate accounting moves as fees when processing dunning which are at a level with a *Fee* defined.
account_dunning_letter | The account_dunning_letter module generates a dunning letter after the process of dunnings for those who are at a level with *Print on Letter* checked.
account_es | The Spanish account module defines the following charts of account:
account_eu | The account_eu module implements common accounting requirements in Europe. It includes:
account_fr | The French account module defines the standard chart of account
account_fr_chorus | The account_fr_chorus module allows to send invoices through the `Chorus Pro <https://chorus-pro.gouv.fr/>`_ portal.
account_invoice | The account_invoice module adds the invoice, payment term.
account_invoice_correction | The account invoice correction module adds a wizard on invoice which allows select lines for which the unit price must be corrected.
account_invoice_history | The account invoice history module activates the historization of the invoice and its related fields.
account_invoice_line_standalone | The account invoice line standalone module allows to create invoice line not linked to an invoice.
account_invoice_secondary_unit | The account invoice secondary unit module adds a secondary unit of measure on invoice line.
account_invoice_stock | The account invoice stock module adds link between invoice lines and stock moves.
account_payment | The account_payment module allows to generate grouped payments for receivable or payable Account Move Lines.
account_payment_clearing | The account_payment_clearing module allows to generate account move when a payment is succeeded between the receivable/payable account to a clearing
account_payment_sepa | The account_payment_sepa module allows to generate SEPA files for a Payment Group.
account_payment_sepa_cfonb | The account_payment_sepa_cfonb module adds CFONB flavors to SEPA messages.
account_payment_stripe | The account_payment_stripe module allows to receive payment from `Stripe`_. It uses `Stripe.js and Stripe Elements`_ in a checkout form to handle `Setup
account_product | The account product module adds accounting on product and category.
account_statement | The account_statement module allows to book statements. Statement can be used for bank statement, cash daybook etc.
account_statement_aeb43 | The Account Statement AEB43 module implements the import of the `Norm 43 <https://downloads.tryton.org/standards/aeb43.pdf>`_ of the Spanish banks
account_statement_coda | The Account Statement Coda module implements the import of the `CODA <https://www.febelfin.be/sites/default/files/files/standard-coda-2.5-en.pdf>`_
account_statement_ofx | The Account statement OFX module implement the import of the `OFX <http://www.ofx.net/downloads/OFX%202.2.pdf>`_ file as statement.
account_statement_rule | The account_statement_rule module allows rules to be defined to complete statement lines from imported files.
account_stock_anglo_saxon | The account_stock_anglo_saxon module adds anglo-saxon accounting model for stock valuation.
account_stock_continental | The account_stock_continental module adds continental accounting model for stock valuation.
account_stock_landed_cost | The account_stock_landed_cost module allows to allocate landed cost on *Supplier Shipments* after their reception.
account_stock_landed_cost_weight | The account_stock_landed_cost_weight module adds an allocation method based on weight of each line. (The *Weight* is taken from the *Product Measurements*)
account_tax_cash | The account_tax_cash module allows to make tax report on cash basis.
account_tax_rule_country | The account_tax_rule module extends the tax rule to add origin and destination countries and subdivisions as criteria.
analytic_account | The analytic account module adds the fundamentals required to analyse accounting using multiple different axes.
analytic_invoice | The analytic invoice modules allows to set analytic accounts on invoice line.
analytic_purchase | The analytic purchase module allows to set analytic accounts on purchase line.
analytic_sale | The analytic sale module allows to set analytic accounts on sale line.
authentication_sms | The `SMS <https://en.wikipedia.org/wiki/Short_Message_Service>`_ authentication module allows to authenticate users via SMS. There are two authentication
bank | The bank module defines the concept of bank and account.
carrier | The carrier module defines the concept of carrier.
carrier_percentage | The carrier percentage module adds a cost method based on percentage.
carrier_weight | The carrier weight module adds a cost method based on weight. The price is computed by finding the line for which the weight is greater or
commission | The commission module allows to manage commission for sale's agent. A commission move is created when posting the invoice, following the agent's
commission_waiting | The commission_waiting module allows to generate account move for each commission between the expense/revenue account to a waiting account defined on
company | The company module defines the concepts of company and employee and extend the user model.
company_work_time | The Company Work Time module adds 4 new fields (Hours per Work Day, Hours per Work Week, Hours per Work Month, Hours per Work Year) on the
country | The country module defines the concepts of country and subdivision and comes preloaded with the ISO 3166 list of countries and subdivisions
currency | The currency module defines the concepts of currency and rate.
customs | The customs module allows to define customs duty based on the tariff code.
dashboard | The dashboard module allows user to configure his dashboard.
edocument_uncefact | Implement electronic document from UN/CEFACT:
edocument_unece | The module adds many codes from the UNECE:
google_maps | The Google Maps module add a new URL field on the party addresses. This link open the Google Maps page on the default browser
ldap_authentication | The LDAP authentication module allows to authenticate users via a LDAP server.
marketing | The marketing module defines the fundamentals for marketing modules.
marketing_automation | The marketing_automation module allows marketing actions to be automated. It is based on scenarios and activities that are executed on selected records.
notification_email | The notification email module allows to define email templates which will be sent to a list of recipients when a trigger is fired on a record event.
party | The party module defines the concepts of party, identifier, category and contact mechanism. It also comes with reports to print labels and letters and a
party_relationship | The party relationship module allows to define different types of relations between parties.
party_siret | The party siret module adds the SIREN and SIRET on party and address.
product | The Product module defines the following models: Category of Unit of Measure, Unit of Measure, Product Template, Product and Product
product_attribute | The Product Attribute module defines the following models: Attribute and Attribute Set.
product_classification | The Product Classification module defines the tools for other modules to create classifications of products.
product_classification_taxonomic | The Product Classification Taxonomic module adds the taxonomic classification to the products.
product_cost_fifo | The Product Cost FIFO Module add a *FIFO* option in the Cost Method field of the product form.
product_cost_history | The Product Cost History Module adds a *Cost History* relate on the product form showing the cost price evolution of the product. The history is based on
product_measurements | The Product Measurements module adds this following measurements to Product:
product_price_list | The product price list module provides formula to compute prices per product or category.
product_price_list_dates | The product_price_list_dates module adds *Start Date* and *End Date* conditions to the *Price List Lines*.
product_price_list_parent | The product_price_list_parent module adds a *Parent* to the price list and the keyword `parent_unit_price` for the formula which contains the unit price
production | The production module defines basics for production management: Bill of material and production order.
production_outsourcing | The production outsourcing module allows to outsource production order per routing. When such outsourced production is set to waiting, a purchase order is
production_routing | The production routing module defines the routings for production: Routing, Step and Operation.
production_split | The Production Split module adds on the production a wizard that allows to split it.
production_work | The production work module allows to manage work order for each production. It also adds in the production cost for the work cost.
production_work_timesheet | The production work timesheet module allows to enter timesheet for production works.
project | The Project module provides the concepts of project and task and the basis for simple project management.
project_invoice | The Project Invoice module adds invoice methods on project. The methods are:
project_plan | The Project Plan module adds planning features on top of the Project module.
project_revenue | The project revenue module computes revenue and cost per task and project. The revenue uses the list price of the product. If the product's unit of
purchase | The purchase module defines the Purchase model.
purchase_amendment | The purchase amendment module allows you to change purchases that are being processed and keep track of the changes.
purchase_history | The purchase history module activates the historization of the purchase and adds a revision counter which increases each time the purchase is reset to
purchase_invoice_line_standalone | The purchase invoice line standalone module makes purchase to generate invoice lines instead of invoices.
purchase_request | The Purchase Request module introduces the concept of Purchase Requests which are central points to collect purchase requests generated by other process from
purchase_request_quotation | The Purchase Request for Quotation module allows users to ask quotations from selected purchase requests to different suppliers.
purchase_requisition | The Purchase Requisition module allows users to create their purchase requisitions.
purchase_secondary_unit | The purchase secondary unit module adds a secondary unit of measure on purchase lines.
purchase_shipment_cost | The purchase_shipment_cost module adds shipment cost to *Supplier Shipment*.
sale | The sale module defines the Sale model.
sale_advance_payment | The sale_advance_payment module adds support for advance payment management on the sale.
sale_amendment | The sale amendment module allows you to change sales that are being processed and keep track of the changes.
sale_complaint | The sale_complaint module defines Complaint model.
sale_credit_limit | The sale_credit_limit module adds confirmed sale but not yet invoiced to the "Credit Amount" of the Party and check the credit limit of the party when
sale_extra | The sale_extra module allows to add extra line on sale based on criteria.
sale_history | The sale history module activates the historization of the sale and adds a revision counter which increases each time the sale is reset to draft.
sale_invoice_grouping | The ``sale_invoice_grouping`` module adds an option to define how invoice lines generated from sales will be grouped.
sale_opportunity | The sale_opportunity module defines the lead/opportunity model.
sale_payment | The sale_payment module extends *Sale* to allow payments prior to the creation of any invoice.
sale_price_list | The sale price list module adds support for price list on sale. A price list can be set per party or as default.
sale_product_customer | The sale_product_customer module defines customer's names and codes for products and/or variants.
sale_promotion | The sale_promotion module allows to apply promotions on sale based on criteria.
sale_promotion_coupon | The sale_promotion_coupon module adds coupon to the promotions.
sale_secondary_unit | The sale secondary unit module adds a secondary unit of measure on sale lines. The secondary quantity and unit price are kept synchronized with the quantity
sale_shipment_cost | The sale_shipment_cost module adds shipment cost for sale.
sale_shipment_grouping | The ``sale_shipment_grouping`` module adds an option to define how stock moves generated from sales will be grouped.
sale_shipment_tolerance | The sale_shipment_tolerance modules adds under and over shipment tolerance on the sale.
sale_stock_quantity | The sale_stock_quantity module check the stock quantity of the products when quoting a sale. The check will warn the user if the forecast quantity at the
sale_subscription | The sale subscription module defines subscription, services and recurrence rule models.
sale_subscription_asset | The sale subscription asset module adds the notion of asset to the sale subscription module.
sale_supply | The Sale Supply module adds a supply on sale option on product. If checked, it will generate a purchase request for each sale line of this
sale_supply_drop_shipment | The Sale Supply Drop Shipment module adds a drop shipment option on product supplier if "supply on request" is checked. When checked, the purchase request
stock | The stock module defines fundamentals for all stock management situations: Locations where products are stored, moves between these
stock_consignment | The stock consignment modules allow to manage consignment stock from supplier or at customer warehouse.
stock_forecast | The stock forecast module provide a simple way to create stock moves toward customers with a date in the future. This allow other stock
stock_inventory_location | The Stock Inventory Location Module add a new wizard *Create Inventories* under the *Inventories* sub-menu.
stock_location_move | The stock location move module allows to define some *Locations* as movable (like palette).
stock_location_sequence | The stock location sequence module adds ordering to location.
stock_lot | The stock lot module defines lot of products.
stock_lot_sled | The stock_lot_sled module adds two fields on lot of products:
stock_lot_unit | The `stock_lot_unit` module allows to define a unit and quantity on stock lot.
stock_package | The stock package module allows to store packaging information about customer and supplier return shipments.
stock_package_shipping | This module is the base module required to interact with shipping service providers.
stock_package_shipping_dpd | The Stock Package Shipping DPD module allows you to generate the DPD label using the DPD webservices.
stock_package_shipping_ups | The Stock Package Shipping UPS module allows you to generate the UPS labels per package using the UPS webservices.
stock_product_location | The Stock Product Location Module adds on the product form a list of preferred location by warehouse. This list is used when a supplier
stock_secondary_unit | The stock secondary unit module adds a secondary unit of measure on the stock move.
stock_shipment_measurements | The Stock Shipment Measurements module adds weight and volume on shipments and packages.
stock_split | The Stock Split module adds on the stock move a wizard that allows to split them. The move is split into moves of *Quantity*. If *Counts* is set, it will be
stock_supply | The Stock Supply module add automatic supply mechanisms and introduce the concepts of order point.
stock_supply_day | The Stock Supply Day module adds a Week Days list on the Product Supplier form. This allow to restrict the supply week days for each
stock_supply_forecast | The stock supply forecast module takes forecast into account to compute purchase requests.
stock_supply_production | The Stock Supply Production module adds automatic supply mechanisms via production request.
timesheet | The timesheet module allow to track the time spent by employees on various works. This module also comes with several reports that show
timesheet_cost | The timesheet cost module adds cost price per employee.
user_role | The user_role module allows to assign roles to user instead of groups. A *Role* is defined by a set of groups. When a role is added to a user, it
web_shortener | The web_shortener module allows URLs to be shortened. It counts the number of times the URL is accessed and optionally triggers action.
web_user | The web_user module provides facilities to manage external user accessing from the web.
Yes, I took the first two lines after the title from the doc/index.rst files.
Yes, as long as it isn’t going to be a problem, I think it would be quite nice to have the module description accessible from the form view for each module. Maybe we could add a notebook with the dependencies on one tab, and the contents of the index.rst file in the other?
The doc folder is not installed by Python packages because there is no standard for it. Also I will be wrong to put it in the site-packages folder because it is not code.
This is the main reason why we removed any documentation or description from the ir.module model because we can not manage it properly. Instead we created docs.tryton.org to use as reference.
Thanks for providing this. I’m just working on a German translation (to learn about the contents - and to be published if required) and found that the whole (uncropped) contents would be helpful.
I browsed github, found several doc/index.rst files, but non containing the whole bit.
There is a doc/index.rst file in each module. If you have mercurial installed, then the easiest way of getting them is to use mercurial to clone the tryton-env repository, this will contain a module directory that has all the modules in it, e.g.:
hg clone https://hg.tryton.org/tryton-env
ls tryton-env/modules/*/doc/index.rst
An alternative is to pull them from readthedocs, in bash run:
for MODULE in $( curl -Ss https://downloads.tryton.org/modules.txt ); do
curl -Ss -o "${MODULE}.rst" "https://docs.tryton.org/projects/modules-${MODULE//_/-}/en/latest/_sources/index.rst.txt"
done
