Prices are not filled in at invoices

we had a change in VAT at the beginning of this year, so I took the chance to reorganize some things, especially in terms of article categories.

When now creating or changing positions in sales, prices are no longer inserted.
What could be the reason?


If you have an empty value on the sale line is because you have an empty price list for the product.
This may be the case if you created a new company because the product prices are company dependent so they are only stored on the previous company.

If this is not the issue, you should explain what was your reorganization about.

In the end I noticed that only one single order was affected, orders to come in newly were not. So I decided not to dig into this more deeply and fill in prices manually in that order.
Thank you anyway for your valued attention!

Sorry, I’ve been too early pleased… ):
Actually, I didn’t at all understand my problem. This is an updated version:

  • prices are filled nicely when I create an order (sales) - and are handled correctly in the corresponding invoice.
  • When already having an order (maybe from woocommerce - or created on my own) and try to add or change an item in the corresponding invoice - then I’m missing the price.

Is that a feature - or a misconfig at my side?


Invoice does not fetch price, you need to write it manually, only sales do that.

Allright, thank you very much for that insight. I never know whether it’s my ridiculous config - or it’s a feature. So I checked it with a “invoice only” (without an underlying sale), and it’s all the same.

But now, I’d like to know for what reason it is designed like that? - AFAIK, in an “invoice only”, all data will be collected (correct name of item, VAT rate, accont, unit) - but not the price? - Actually, I CAN fill in the price (have to subtract VAT before ): ) - so that seems not to do real harm…
To me it feels as if the price should be grabbed - but of course I respect experts’ good reasons to do it like this.


See Issue 4857: Don't set default unit price on invoice - Tryton issue tracker

Thank you very much. I took quite some time to follow @ced’s argument, but couldn’t in the end. What I understood it that mistakes can occur when the page collects price data from the wrong source. True?

What I cannot understand is the solution choosen. Is it really more safe to collect prices manually? - In my case, I have brutto prices in my mind, but need to subtract VAT from that and then type in numbers with 4 decimal places correctly. Well - at least I’m too sloppy to do that correctly more than 3 items…

I understood that it’s the safer way to generate invoices from orders. But this does not always work. In my case, orders can be created at a web shop - but I often need to do adjustments, which I cannot do within the order.

To sum it up:

  • Behaviour is unexpected. We needed 6 messages in this thread to figure out what the actual problem is: Invoice forms do not provide prices as order forms do, allthough they nearly completely look the same. This is very confusing to the user - who is much likely to suspect a misconfiguration at his system. (I wasted many hours to find out about that)
  • Fetching prices manually is highly subject to mistakes
  • Creating / changing the underlying order is not always possible

So - in case it’s really dangerous to automatically collect the price, is it possible to provide a button which does it in a semi-automatic way? - Thus, the user’s attention will be drawn to the price filled in and he can check for correctness. Or are there any better ideas?


We only implement all the sale prices machinery at sale level. This means using price_list, discounts, promotions, free_products and probably more to come. We do not want to duplicate it on invoices, so instead of giving a wrong price we let the user decide.
This is ok for most of the cases as the user will rarerly do invoices.

Doing adjustments does not mean that you need to create new lines. Just update the prices of existing ones.

Yes, you can do whatever on custom module.

Thank you for all your effort. I cannot understand your arguments - but I guess, that is how it is.