Best practice shipment costs?

Hello,

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.

Cheers,
Wolf

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 tryton.cloud, nor in kopen / tryton-documentation · GitLab, and Sale Shipment Cost Module — Tryton module for sale shipment cost as well does not tell me anything.

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

Cheers,
Wolf

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 docs.tryton.org, 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('party.party')
    >>> customer = Party(name='Customer')
    >>> customer.sale_shipment_cost_method = 'shipment'
    >>> customer.save()

Create account category::

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

Create product::

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

    >>> template = ProductTemplate()
    >>> template.name = '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
    >>> template.save()

And latter we perform the actions:

Sale products with cost on shipment::

    >>> Sale = Model.get('sale.sale')
    >>> sale = Sale()
    >>> sale.party = customer
    >>> sale.carrier = carrier
    >>> sale.payment_term = payment_term
    >>> sale.invoice_method = 'shipment'
    >>> sale.shipment_cost_method
    'shipment'
    >>> sale_line = sale.lines.new()
    >>> sale_line.product = product
    >>> sale_line.quantity = 5.0
    >>> sale.click('quote')
    >>> cost_line = sale.lines[-1]
    >>> cost_line.product == carrier_product
    True
    >>> cost_line.quantity
    1.0
    >>> cost_line.amount
    Decimal('3.00')
    >>> sale.click('confirm')
    >>> sale.click('process')
    >>> sale.state
    'processing'
    >>> sale.untaxed_amount
    Decimal('103.00')

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
    True
    >>> cost_line.quantity
    1.0
  • We can make actions like a user would: sale.click('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.

2 Likes

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.

Cheers,
Wolf

Hallo,

beim Testen von Tryton stehe ich an folgender Herausforderung:

Beim erstellen der Kundenrechnung sollen „Nebenleistungen“ auf der Rechnung aufgeführt werden. Nebenleistungen sind in der Regel Portokosten. In meinem einfachen Szenario sind es einfach 3. verschiedene pauschale Preise für das Land Deutschland.

Ich bin dem Leitfaden von https://www.tryton-dach.org/tryton-buch-details/ gefolgt.

Nun kann ich zwar im Feld welches als „Versanddienstleister“ (sic!) betitelt eine der angelegten Versanddienstleistungen für das entsprechende Land auswählen. Dies wird aber nicht als Posten der Rechnung hinzugefügt.

Jetzt zweifle ich gerade, ob es überhaupt das Ziel des Modells trytond-sale-shipment-cost ist derartige Rechnungspositionen zu erzeugen.

Kann es sein, dass es sich hier mehr um kalkulatorische Kosten geht für die Ermittlung des Deckungsbeitrags eines konkreten Artikels?

Sicherlich ist auch möglich, dass ich an irgend einer Stelle eine Einstellung noch nicht richtig gesetzt habe. Etwa kann ich derzeit unter Versand/Versanddienstleister nur „Artikelpreis“ bei Versandkostenmethode auswählen. Unter Zuordnungsmethode beschränkt sich die Auswahl auch auf nur eine Option: „Kosten“.

Habe ich die Installation von einem weiteren Modul vergessen?

Derzeit bin ich leicht ratlos!?! Über sachdienliche Hinweise freue ich mich. Danke.

Ich habe noch keine Lösung. Jedoch tauchen sporadisch, jedoch nicht reproduzierbar, die Portokosten bei Erstellung des Angebots auf. Allerdings verschwinden sie wieder, wenn das Angebot weiter geführt wird zur Rechnung.

Daher habe ich derzeit zwei Probleme. Was sind die richtigen Angaben unter Verkauf/Einstellungen und dem Reiter “Verkauf” bei den “Parteien”? Sind Änderungen dann sofort aktiv nach dem Speichern?

Falls die Lieferkosten zuverlässig im Angebot auftauchen: Wie gehen sie nicht verlohren im weiteren Bearbeitungsprozess bis zur festgeschriebenen Rechnung?

When the shipment cost of a sale is invoiced depend on the “Shipment Cost Method” defined on the sale order, see Sale Shipment Cost Module — Tryton module for sale shipment cost

So, ich habe meine Fehler gefunden:

Bei der Anlage des Artikel ist darauf zu achten, dass unbedingt auch der ‚Listenpreis‘ ausgefüllt ist. In meinen Testdaten stand nur ein Wert bei ‚Bruttopreis‘. ‚Listenpreis‘ war leer. Der Inhalt 0,00 funktioniert. Das Feld ‚Listenpreis‘ darf aber nicht leer sein.

Dann noch ein Hinweis: Bei ‚Verkauf Lieferkostenmethode‘ ‚pro Lieferung‘ werden die Versandkosten immer in separaten Rechnung aufgeführt. Falls man seinem Kunden nur eine Rechnung schicken möchte ist die Methode ‚pro Lieferung‘ ungeeignet. Achtet auch darauf, dass ihre eure globale Einstellung nicht überschreibt, weil ihr in den Stammdaten des Kunden im Reiter ‚Verkauf‘ etwas abweichendes (unbewusst) hinterlegt habt.

Danke für eure Unterstützung

Then you need to use the sale_invoice_grouping module.