I’m facing an issue where the Printed PDF Quote doesn’t match the actual quote.
The problem is with the TAX displayed on the PDF Quote.
I’ve found a similar topic, but I only have one language - English.
While on SuiteCRM, the quote is displaying the correct values.
After printing the PDF, comes like this:
By the way and before anyone asks, the first line is 10x (ten times) the product (priced at €52 so 10x is €520 without tax)
I wonder if the value is being saved correctly to the database. Can you check in table aos_products_quotes if the vat field is correct?
@pgr I would answer this before checking the database, if the VAT value wasn’t set, how would in the quote view (first screenshot of them all) show the correct values and correct calculations?
But to double-check:
mysql> use suite_crm;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show columns from aos_products_quotes;
+----------------------------------+---------------+------+-----+------------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------------+---------------+------+-----+------------+-------+
| id | char(36) | NO | PRI | NULL | |
| name | text | YES | | NULL | |
| date_entered | datetime | YES | | NULL | |
| date_modified | datetime | YES | | NULL | |
| modified_user_id | char(36) | YES | | NULL | |
| created_by | char(36) | YES | | NULL | |
| description | text | YES | | NULL | |
| deleted | tinyint(1) | YES | | 0 | |
| assigned_user_id | char(36) | YES | | NULL | |
| currency_id | char(36) | YES | | NULL | |
| part_number | varchar(255) | YES | | NULL | |
| item_description | text | YES | | NULL | |
| number | int(11) | YES | | NULL | |
| product_qty | decimal(18,4) | YES | | NULL | |
| product_cost_price | decimal(26,6) | YES | | NULL | |
| product_cost_price_usdollar | decimal(26,6) | YES | | NULL | |
| product_list_price | decimal(26,6) | YES | | NULL | |
| product_list_price_usdollar | decimal(26,6) | YES | | NULL | |
| product_discount | decimal(26,6) | YES | | NULL | |
| product_discount_usdollar | decimal(26,6) | YES | | NULL | |
| product_discount_amount | decimal(26,6) | YES | | NULL | |
| product_discount_amount_usdollar | decimal(26,6) | YES | | NULL | |
| discount | varchar(255) | YES | | Percentage | |
| product_unit_price | decimal(26,6) | YES | | NULL | |
| product_unit_price_usdollar | decimal(26,6) | YES | | NULL | |
| vat_amt | decimal(26,6) | YES | | NULL | |
| vat_amt_usdollar | decimal(26,6) | YES | | NULL | |
| product_total_price | decimal(26,6) | YES | | NULL | |
| product_total_price_usdollar | decimal(26,6) | YES | | NULL | |
| vat | varchar(100) | YES | | 5.0 | |
| parent_type | varchar(100) | YES | | NULL | |
| parent_id | char(36) | YES | MUL | NULL | |
| product_id | char(36) | YES | | NULL | |
| group_id | char(36) | YES | | NULL | |
+----------------------------------+---------------+------+-----+------------+-------+
34 rows in set (0.03 sec)
mysql> select currency_id,product_qty,product_list_price,vat from aos_products_quotes;
+-------------+-------------+--------------------+------+
| currency_id | product_qty | product_list_price | vat |
+-------------+-------------+--------------------+------+
| -99 | 1.0000 | 125.000000 | 23 |
| -99 | 10.0000 | 52.000000 | 23 |
+-------------+-------------+--------------------+------+
2 rows in set (0.03 sec)
Side note btw, is there ANY reason why the columns are named _usdollar when the price has nothing to do with USD ???
Was something like _basecur or _base, for example, out of fashion?
I’m not asking about the columns being there, I am asking about the value “23” being in the row that pertains to that invoice.
The reason that this might not be obvious is that it’s possible that the values shown on screen might not be getting saved correctly after being shown on screen. If I am sure that the problem is not when saving, then I can focus on the template rendering. I’ve seen both kinds of problems occur so I guess it helps to start looking for the problem in the right place.
I don’t know about the usdollar columns but if I had to guess, I’d say they keep both currencies there so they can add up invoices made in different currencies. So you keep the original currency because that’s what the invoice is about, but then you have a “common” currency (USD), and convert everything to that, so you can have totals and reports that make sense. I’ve never seen this used, so it might be an artifact from a previous incarnation of SugarCRM…
@pgr yes, I understood your question. I know you’re not asking me if the columns are there. If you scroll down a little on the code block, you’ll see the contents of the columns also.
I said one can infer that the value is correctly populated (db wise) by looking at the first screenshot and seeing that the calculations are correct, since the first screenshot is the Quote after saving. It’s a view pane not an edit pane. The problem is not regarding save.
But again, if you look at my code block and scroll down a little, you can see the contents of the columns (and that both VAT show 23). I just used the show columns to see which columns to select in my next command, and pasted the whole thing here.
About the _usdollar that was only a rant. I have my main currency set as EUR and on the _usdollar the value shown is just the base value in Euro. It’s the base value for the base currency I’ve selected as base currency. Hence my comment, but that’s a whole other thing.
Sorry, my bad, you are right that I didn’t scroll down to see the rest.
I had a look at the code, but couldn’t find the cause of the problem in my limited time. Sorry again 
All ok @pgr thank you for looking, I guess I also could have trimmed what I pasted here and omit the show columns part.
Now my question is, in order to use SuiteCRM this kind of should be working, should I open a Github issue directly for this?
Thanks
Yes, if it isn’t already there, I’d say it’s worth opening.
But before that, something came to my mind, can you just check in Admin / Dropdown Editor, which items you have in vat_list? Is “23” there? Can you also try adding “23.0”?
Alright gimme a minute I’ll check that thanks
EDIT:
Since I can’t edit the value via GUI, I was wondering I can edit directly on the database, but got me wondering since this is quite a complex piece of software, if editing the DB directly could have unintended results, and should I rather delete each option and re-create?
Follow up
Removed the “23” | “IVA PT - 23%” and added “23.0” | “PT 23%”.
Edited the invoice, when I pressed edit the TAX dropdown that previously had IVA PT 23% selected now was empty, so I selected the new PT 23% tax.
Upon save the calculations are correct and under Quote VIEW → Line Items appears correctly.
Tried printing a new PDF, the issue persists.
Those dropdown items are not stored in the DB, they are stored in files under custom dir. If you grep your filesystem you’ll find them.
I don’t see any special code for that field, so if it works with one field, it really should work with others. But maybe I am missing some detail. I’d have to go into full debugging mode but I am afraid it’s just not possible, I am afraid I am behind in my own work 
Holy … !
# less public/legacy/custom/include/language/en_us.lang.php
<?php
$app_list_strings['vat_list']=array (
'0.0' => '0%',
'5.0' => '5%',
'7.5' => '7.5%',
'17.5' => '17.5%',
'20.0' => '20%',
4 => 'IVA PT AZ - 4% (red)',
5 => 'IVA PT MD - 5% (red)',
6 => 'IVA PT - 6% (red)',
9 => 'IVA PT AZ - 9% (int)',
12 => 'IVA PT MD - 12% (int)',
13 => 'IVA PT - 13% (int)',
16 => 'IVA PT AZ - 16%',
22 => 'IVA MD - 22%',
23 => 'IVA PT - 23%',
);
$app_list_strings['vat_list']=array (
'0.0' => '0%',
'5.0' => '5%',
'7.5' => '7.5%',
'17.5' => '17.5%',
'20.0' => '20%',
4 => 'IVA PT AZ - 4% (red)',
5 => 'IVA PT MD - 5% (red)',
6 => 'IVA PT - 6% (red)',
9 => 'IVA PT AZ - 9% (int)',
12 => 'IVA PT MD - 12% (int)',
13 => 'IVA PT - 13% (int)',
16 => 'IVA PT AZ - 16%',
22 => 'IVA PT MD - 22%',
23 => 'IVA PT - 23%',
);
$app_list_strings['vat_list']=array (
'0.0' => '0%',
'5.0' => '5%',
'7.5' => '7.5%',
'17.5' => '17.5%',
'20.0' => '20%',
4 => 'IVA PT AZ - 4% (red)',
5 => 'IVA PT MD - 5% (red)',
6 => 'IVA PT - 6% (red)',
9 => 'IVA PT AZ - 9% (int)',
12 => 'IVA PT MD - 12% (int)',
13 => 'IVA PT - 13% (int)',
16 => 'IVA PT AZ - 16%',
22 => 'IVA PT MD - 22%',
'23.0' => 'PT 23%',
);
I mean … why?!? Is this supposed to be like this?
I would start on the part of this being written in files not on DB … I mean, why?!?
And each save just adds a whole block to the file?? lol
I’m figuring the guy who architectured this solution learned to code with FORTRAN.
I learned something new - this is dirty 
However - it also helped me pass through a roadblock 
- Thank you! 
Watching this post.
No, it shouldn’t be like that. There’s code to check duplicate entries (the many dropdown functions in public/legacy/modules/Administration/Common.php), it’s not just a simple append. That’s something that bugged up somewhere along the road, the funny part is that it works - the last change you made gets applied last, so it’s the effective one. This means the bug can be there for years and nobody notices it 
I am more concerned with the variations in the ways that the array keys are written, it seems too messed up and it must be confusing the code that outputs the values to the PDF.
Maybe try a simplified version like
$app_list_strings['vat_list']=array (
'0.0' => '0%',
'5.0' => '5%',
'7.5' => '7.5%',
'17.5' => '17.5%',
'20.0' => '20%',
'23.0' => '23%',
);
… just to check if it makes a difference for the PDF.
Well the weird presentation of data I’d say derives form values being introduced as whole numbers (eg 23 vs 23.0) where the whole number doesn’t need the quotes around.
Anyway I’ve just cleared this file, now it looks like this:
<?php
$app_list_strings['vat_list']=array (
'0.0' => '0%',
'5.0' => '5%',
'7.5' => '7.5%',
'17.5' => '17.5%',
'20.0' => '20%',
'4.0' => 'IVA PT AZ 4% (red)',
'5.0' => 'IVA PT MD 5% (red)',
'6.0' => 'IVA PT 6% (red)',
'9.0' => 'IVA PT AZ 9% (int)',
'12.0' => 'IVA PT MD 12% (int)',
'13.0' => 'IVA PT 13% (int)',
'16.0' => 'IVA PT AZ 16%',
'22.0' => 'IVA PT MD 22%',
'23.0' => 'IVA PT 23%',
);
Going to test the PDF and let you know
Problem persists with the above contents.
Bump
Don’t want this to be forgotten, seems like a clear bug in this module?
Should I report on GitHub?
@maverickws Yes, an issue on github would be good. I’d reference this thread and the other thread.
Done