Hi! Thanks for the suggestions.

While I agree that the last suggestion is a valid issue, I suppose that first two bullets in the list are not.

> * When adding an item below the microbes (add table row below), it is missing
> the sum formula, and consequently, this item is missing in the net amount sum.
> * Moreover, with removing an item (delete table row), all summing formulas
> are invalidated, and have to be redone.
This one is because the sum formula in your Net Amount lists individual cells. In this case, the program has no way of knowing that adding a row requires to modify the arguments to a formula. If you use simply `=sum(<D2:B7>)` instead of `=sum(<D2|D3|D4|D5|D6|B7>)`, it will work as expected. Well - you could have valid reasons to not include the last line (Shipment) into the range; then you could simply add an empty row below the Microbes, assign it a minimal height, remove inner borders (so it would look like simply double-border), and include it into the range formula (in that case, it would look like `=sum(<D2:D7|B8>)`). Then adding rows below Microbes would work fine, and removing rows also would work (except for the rows explicitly mentioned in the formula).

Dear Mike,

thanks for your quick response and valuable suggestions.
I've no idea, why I stuck with the silly sum formula. Most probably by simulating the ∑ method... 

'=sum(<D2:B7>)' is almost fixing 2 of the 4 issues mentioned.
I say almost, because, it doesn't work for removing the first item, but then
'=sum(<D1:B7>)' is doing fine for that case, too. 

Thank you very much, will incorporate such adjustments to all invoice and offer templates in a second.

What's remaining is the third bullet, and the first half of the first. I'm sorry for not describing the first bullet properly, and for not splitting this topic in two issues, which it deserved. Here is the first part, which wasn't formulated properly:

 * Adding a row of another issue is missing to clone the sum formula for the new row (amount * unit price).

I've attached an updated version of the test file, incorporating the changes, you suggested for further discussion and hopefully, to support somebody, who might want to tackle the remaining issues.

Created attachment 145801 [details]
A Writer document with an improved invoice table

Grrr:

 * Adding a row for another item is missing to clone the sum formula for the new row (amount * unit price).

(In reply to Hans-Peter Jansen from comment #4)
>  * Adding a row for another item is missing to clone the sum formula for the
> new row (amount * unit price).
I don't understand what you would like. Clone what, row where cursor is? 
We need steps, with Experienced and Expected result. But, that must be a new request.

This bug with multiple issues is Invalid report. 
But we can convert it to a proper bug for this:

(In reply to Hans-Peter Jansen from comment #0)
>  * Another minor issue lurks in the VAT field (A9), if simply editing the
> VAT value, and leaving the field, it is loosing its special VAT value
> format. 

Looks like a bug. Please explain what's value format here. So that we can understand what happens with s simple change, let's say from 12,3% to 17%.

Thanks Timur, for your reply.

(In reply to Timur from comment #5)
> (In reply to Hans-Peter Jansen from comment #4)
> >  * Adding a row for another item is missing to clone the sum formula for the
> > new row (amount * unit price).
> I don't understand what you would like. Clone what, row where cursor is? 

Done: https://bugs.documentfoundation.org/show_bug.cgi?id=122763

> We need steps, with Experienced and Expected result. But, that must be a new
> request.
> 
> This bug with multiple issues is Invalid report. 
> But we can convert it to a proper bug for this:

Okay, understand. Lesson learned.

> (In reply to Hans-Peter Jansen from comment #0)
> >  * Another minor issue lurks in the VAT field (A9), if simply editing the
> > VAT value, and leaving the field, it is loosing its special VAT value
> > format. 
> 
> Looks like a bug. Please explain what's value format here. So that we can
> understand what happens with s simple change, let's say from 12,3% to 17%.

The value format is '0,0%" VAT"'. If you load the attached document, put the cursor in the VAT field (A10), and edit the value to say "13,2", and tab out of the field, the format is lost (-> Text '@'), the new value is displayed left aligned, although the field is still right aligned(!), and the calculation in B10 fails (-> 0,00 €). I wasn't able to recover from this without reassigning the specific %-format (0,0%" VAT"), and *enter* the plain value again. The only proper way to change the VAT value for an experienced user is selecting the whole value, and replacing it with a plain number.

I would expect the field A10 to keep the assigned format, and just accept the new value. Then, the calculation in B10 wouldn't fail as well, I bet.

I change the title and confirm since this looks like a bug. Repro 6.3+.
We still need an explanation why this happens and a check for being a duplicate.

Replicated with 7.0.3.1 (openSUSE TW 20210113)

Load attached document, edit VAT field, and see calculation failing.

One cannot restore from this state with ^Z anymore.

To recover, either reload document, or reassign the custom number format to the cell, which takes these steps: select VAT cell of table, assign custom VAT format (no context menu available: Table -> Number format -> Custom formats -> Select VAT format -> OK), select the text of the cell, replace with a number (eg.: 10), tab out of the cell, é voila, the new VAT is calculated correctly.

The last step is the *only* way available today to edit a cell with a custom number format without breaking stuff.

Hopefully, anybody can imagine, why this procedure isn't going to fly.

Hi,

I was able to reproduce the issue with 7.4.3.2 from openSUSE Tumbleweed.

A successful edit of A10 requires selection of whole field, replace it with a new plain number (e.g. 12,5) and leave the field. You still cannot just edit the value without losing the format.