Inserting item in a receipt from a list of items (Page 3 of 4)

Hello to both of you and sorry for the delay but "fortunately" they put my son's class in quarantine and now I have it all day at home, together with the other and it is not easy to do something with both of them at home 24 hours .
I understand, I didn't think there should be an order in the instructions, now I know, thank you very much to both of you.

Caio Fabio,
There are a couple of ways to do this but for me, the easiest is to add another calculated field (cfinventoryvalue) and use that in your report.
Because 'calculated fields' are not saved in the database and only calculated when your program runs, it won't affect your existing data.
Regards,
Derek.

Hi Fabio,
It's not a problem.
The structure of the tables hasn't changed - calculated fields are not 'proper fields' and NEVER get saved to the database.  I often think if they were simply called 'calculations' rather than 'calculated fields', it might be less confusing for people.
Have a look at the two screen shots (before I made the change and after I made the change - the structure hasn't changed). 
Also, have a look at either of the structures - you will not see any of the calculated fields because they are not fields, they are just temporary calculations.
Derek.

Hi,
I used SQLiteStudio but I imagine that DB Browser for SQL does a very similar job.
Don't forget to backup your sqlite.db before you start anything - LOL!
Derek.

Caio Fabio,
There are a number of things to note;
1.  Frmprincipale.comInventarioestate has an associated action = REPORT.  But you are also calling the report from your script (Line 252).  This is why it is running twice.  Change it to action = 'No Action' (see screenshot1).
2.  You do not need separate versions of the inventory report for 'estate' and 'inverno';  you are already filtering the data to show just 'estate' or 'inverno' in your program before you run the report.  Report Inventario.fr3 uses the filtered data in the hidden tablegrid - ergo you only need the Inventario.fr3 report for all instances.   
3.  Your data is incorrect - if you look at the 'articoli' table, id_stagione is blank and this is why the 'estate' and the 'inverno' reports show all data.  See screenshot2.  If you correct the data (frminserimentoarticoli), this will fix the problem.
4.  I am not sure I understand the problem you had with copying the live database.  All you need to do is:
4.1  delete sqlite.db from the latest program that has your report changes
4.2  copy sqlite.db from your 'live' system.  As there have been only changes to the program and no changes to the data structure, you should not get any errors.  You don't need to do any 'importing' of data at all.
I have made changes (as per the comments above) and these are in the attachment (Moon5c) together with the screenshots.
I've also attached an alternative way of approaching it (attachment Moon5d) which lets you select any season, rather than using a script and hard coding the selected seasons.  Just a thought.
Hopefully this gets you moving forward,
Derek.

a me lo da bene

Ciao Domenico,
buon anno! Il problema è persistente dalla prima edizione, me l'ha fatto notare la mia amica per cui ho fatto il programma. Hai visto nel database che è quello che ha riempito lei, che in molti c'è 22 a prescindere dal costo di acquisto inserito?
Ad esempio fai l'inventario Inverno e prendi l'ottavo, il prezzo di acquisto è 19,90 e l'IVA 22 e ce ne sono molti così. Gli articoli che non hanno 22 hanno la cifra corretta o almeno credo, quelli di cui ho fatto il calcolo erano corretti ma ovviamente non l'ho fatto di tutti.
La cosa spiazzante è che non lo fa con tutti.
È pieno!!!

663055 SCARPA DONNA 28,90 € 22,00
663045 SCARPA DONNA 26,90 € 22,00
641025 SCARPA DONNA 28,50 € 22,00
643325 SCARPA DONNA 24,90 € 22,00
650255 SCARPA DONNA 24,90 € 22,00
650175 SCARPA DONNA 24,50 € 22,00
650185 SCARPA DONNA 24,50 € 22,00
451111 SCARPA DONNA 24,50 € 22,00
421060 SCARPA DONNA 24,90 € 22,00
643196 SCARPA DONNA 24,50 € 22,00
451097 SCARPA DONNA 26,90 € 22,00

Grazie Derek
Infatti ora funziona

Thanks Derek
In fact now it works

Hello everyone
I'm here I overwritten the database with the one containing the data and this other problem came up: in all the items disappeared on the 22nd in the "Aliquota Iva Acquisto" field. Nevertheless if I make an inventory the vat is calculated but on many items returns 22, which is the percentage and not the exact calculation, as from previous post.
I also tried with the "Fix VAT problem" button which, if I have understood correctly from the instructions, should update the field to 22.
Thank you and excuse this umpteenth disturbance.
As always, I re-enter the project with the database completed.

Ora è ok, praticamente il campo era CURRENCY è invece deve essere INTEGER dato che non e un campo di valuta

Ciao Fabio, Domenico,
It sounds as if 2 things may have happened.
1)  you might have clicked the 'Fix VAT Problem' button but the relevant lines in the script (Line 4 and Line 6) were still commented out.  Remove the '//' from the start of Line 4 and Line 6 before running the 'Fix VAT Problem'.  In the attachment, the comment marks ('//') have now been removed.
2)  you might have changed the definition of VAT from 'CURRENCY' to 'INTEGER' (personally, I use 'REAL' but here in England, VAT is 17.5% so 'INTEGER' wouldn't work).  Whenever you change the definition, it will lose whatever values were previously in there, in which case you need to run the 'Fix VAT Problem' again.
What I often do is add a simple form to my project when I'm still developing it so that I can see what values are actually in the relevant tables.  I've added this to your project (frmdatabasecheck) but you can then remove it once you have checked everything is okay).
Derek.

Ciao di nuovo Fabio,
I made a small change to the 'Fix VAT Problem' button so that the script should update a bit faster.
Hope everything is working okay now.
Derek.