Best practice shipment costs?


I do not yet have a good solution for this.

I have a few “shipment products”, depending on the size of the parcel, When the order comes in, I do not know how big the parcel will be, so I put in best guess. Sometimes this guess is wrong, so I have to change the parcel. But now (for 1-2 weeks, cannot say for sure),

  • I can no longer delete items from a non-posted invoice, they re-appear after saving the invoice. I CAN change the number to 0,
  • furthermore, it seems as if “shipment items” now do appear in an invoice, although those items not yet have been sent; this looks new as well.

Probably, I did not understand how the process is meant to happen, so I’d be very grateful for some advice.


Could you explain which is the problem you have and what do you want to update?
You need to update the shipment cost/change the carrier or what do you need to do in case the guess is wrong? This will make it easier to give a proper advice

In my products, I have several “shipment items” - 35cm, 50cm, 70cm etc. parcel, which have different prices. I need to change e.g. from 50 to 70cm parcel, that’s how I’m handling it now. But my overall approach may be stupid.

I looked at the docu of “shipment~” and “carrier~” modules - but could not really find out whether it would be better to use some of those instead of my casual approach.

You should use the sale_shipment_cost module and create carriers from different products for each shipment cost.

It is also possible to modify the shipment cost manually for each sale.

Hope it helps!

Thanks for your effort.

Problem is that I do not understand the basic concept and basic usage of sale_shipment.

And I did not find it explained anywhere, neither in the docs of, nor in kopen / tryton-documentation · GitLab, and Sale Shipment Cost Module — trytond_sale_shipment_cost latest documentation as well does not tell me anything.

Did some fellow ever write down the very basics about usage?


It is really frustrating. Having been a Tryton user now for nearly 3 years, I still have no idea about some important basic ideas and concepts. And even worse - no idea how I should achieve that basic knowledge.

I can understand your frustration, most of the time the best docs is the code itself. So for a user it can be difficult.

But… with having basic knowledge of python or none I’m sure you can read a test scenario, let me explain.
When we develop a module apart from the docs folder where we write what you can see on, we create some tests on the tests folder of the module. Inside that folder you can find some .rst files containing what it’s called scenarios.

Normally, a scenario is a workflow we want to test in our application. It’s a sequence of actions performed by different actors, reflecting a real-life use case of the software. A scenario can help you understand the behavior of the software and its intended use.

Even with minimal programming knowledge, this scenario is quite readable. It describes a series of actions and expected outcomes, which helps you understand the functionality of the module. You’ll see different scenarios for different workflows that the module is expected to handle. This can be a valuable resource for understanding what a piece of software is supposed to do.

For example, normally at the start of the scenario we first create all the meaningless things that we will need to work with:

Create customer::

    >>> Party = Model.get('')
    >>> customer = Party(name='Customer')
    >>> customer.sale_shipment_cost_method = 'shipment'

Create account category::

    >>> ProductCategory = Model.get('product.category')
    >>> account_category = ProductCategory(name="Account Category")
    >>> account_category.accounting = True
    >>> account_category.account_revenue = revenue

Create product::

    >>> ProductUom = Model.get('product.uom')
    >>> ProductTemplate = Model.get('product.template')
    >>> unit, = ProductUom.find([('name', '=', 'Unit')])

    >>> template = ProductTemplate()
    >>> = 'Product'
    >>> template.default_uom = unit
    >>> template.type = 'goods'
    >>> template.salable = True
    >>> template.lead_time = dt.timedelta(0)
    >>> template.list_price = Decimal('20')
    >>> template.account_category = account_category

And latter we perform the actions:

Sale products with cost on shipment::

    >>> Sale = Model.get('')
    >>> sale = Sale()
    >>> = customer
    >>> sale.carrier = carrier
    >>> sale.payment_term = payment_term
    >>> sale.invoice_method = 'shipment'
    >>> sale.shipment_cost_method
    >>> sale_line =
    >>> sale_line.product = product
    >>> sale_line.quantity = 5.0
    >>> cost_line = sale.lines[-1]
    >>> cost_line.product == carrier_product
    >>> cost_line.quantity
    >>> cost_line.amount
    >>> sale.state
    >>> sale.untaxed_amount

You should notice:

  • Every time a Model is using like Sale() means we are working with a new record, so we can define the properties
  • When on the line there is no >>> or … means that is a result, so for example, this validates that the product is the correct we expect and the quantity, so True and 1.0 are responses from the system to our questions:
    >>> cost_line.product == carrier_product
    >>> cost_line.quantity
  • We can make actions like a user would:'confirm')

While it’s true that these tests are written to ensure the software works as expected, they also provide a sort of “living documentation” for the system. However, keep in mind that test scenarios alone may not give you a complete understanding of the module’s functionality, especially if it’s complex or has a lot of different features. They’re best used in conjunction with other forms of documentation.

You can check those scenarios for sale_shipment_cost on the tests folder of the repository.


Dear fellow friend Adrià,

thank you so much for taking the time to explain this to me. Now after 3 years, I at least have an idea how you experts find your way through Tryton - nobody ever told me before. Bthw: Your message came in at my birthday yesterday, funny that…
Well - now I’ll see what I actually can find out. With barely any python knowledge, it’s not so easy, even with that piece of knowledge you kindly passed over to me.

This brings me back to a question I asked back in 2020: Is Tryton for me?. With today’s knowledge I honestly have to confess: No, it’s not for me. It is for programmers, IT specialists, coders, geeks etc. NOT for an entrepreneur who’s just looking for a tool, willing to tinker, experiment, read a lot etc.