Issue:
-------------------
When creating invoices for two sales orders with the same customer the field amount_to_invoice is wrongly calculated and it shows a negative value when it should be zero
Steps to reproduce:
-------------------
1. Go to Sales -> sale orders
2. Create two sale orders with the same customer
3. Confirm the SO’s and delivery the items
4. Create the invoices for both SO’s
5. The field amount_to_invoice is negative
Cause:
-------------------
The method _compute_amount_to_invoice considers the value of all sale orders without any filter, but in this case we have two different sale orders and we only have to consider the value for the respective SO.
OPW-3437237
closesodoo/odoo#132859
X-original-commit: e2ec9e6c86949f5781d03a7dbb1065ef8af3196a
Signed-off-by: John Laterre (jol) <jol@odoo.com>
The salesperson is not added to the following list of invoice that is generated from a sales order.
1. Create a sales order by assigning a salesperson.
2. Confirm the order and generate the invoice.
Current Behavior:
The salesperson is not added to the message following list of invoice.
Expected Behavior:
The salesperson should be in the message following list of invoice.
OPW-3439198
closesodoo/odoo#130930
X-original-commit: d9cb66e22fc9f8cfa1c00a2808294fe1178ffaa1
Signed-off-by: Hamza Islam (hisl) <hisl@odoo.com>
The "fees" or "extra fees" or "customer fees" feature was meant to make
customers pay for the processing fee charged by the payment provider
they choose to make their payment. The fee was also displayed on the
payment form to deter customers and encourage them to choose another,
cheaper, payment provider.
In practice, it didn't hold up because:
1. the provider's API must allow sending the fee as a separate amount,
and PayPal was the only supported provider to do it;
2. charging extra fees is highly discouraged by providers, and forbidden
in Europe;
3. the final fee amount depends on the customer, country, payment
method, risk profile... rendering charging the actual fees amount
infeasible;
4. most of the time, only one payment provider is enabled at a time,
thus alienating customers who would have no other choice than paying
the fee;
task-3358581
closesodoo/odoo#132104
Related: odoo/documentation#5517
Related: odoo/upgrade#5053
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In this commit, all usages of env._t() are replaced by _t().
In templates files, env._t() didn't work because terms used
in attributes where not extracted into the translation files.
Only string are exported from .xml files to translation files.
So, to make it works, we set a variable that is then used
in attributes.
For example :
<t t-set="string_to_translate">String to translate</t>
<Dialog title="string_to_translate>...</Dialog>
task-3292454
closesodoo/odoo#131390
Related: odoo/enterprise#45631
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
These changes are made as a result of simplifying attrs and 'states' in
views.
Before applying the migration script, it is necessary to fix some views.
These views are erroneous and either work by chance or are simply
untested. We have for example wrong domains, elements used by modifiers
but not present in the view, obsolete domain operators, inherit views
not targeting the right views, xpaths using attributes as target, the
use of %(...)s in views, false attribute value types in python.
Part-of: odoo/odoo#104741
These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
A new way to add products in sale orders, through a catalog, was
introduced in commit 216fa84fbe. The precision of the price shown in the
catalog was the currency's precision, but the product price precision
should have been used.
closesodoo/odoo#132046
X-original-commit: 37b5626f58284e13ecfe113842134fe5006f5517
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Since the new Relational Model (PR 114024), it was no longer possible to
remove a product from the Product Catalog view. This commit adapts the
ProductCatalogModel to the new model.
closesodoo/odoo#131734
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
Before this commit, calls to record[fieldname][value/raw_value] in
the arch of a kanban view did not take into account updates on the Record
Datapoint. So if any data in the Record changed, the [raw_value/value]
was not modified.
In a custom KanbanRecord, you should never use the record containing the
value and raw_value. We will therefore replace this call by using the
datapoint record directly.
How to reproduce:
- Have a kanban view with a record.my_field.value and a widget allowing
you to modify the value of my_field.
- Click on the widget
Before this commit:
The value of my_field does not change
After this commit:
The value of my_field has been updated.
closesodoo/odoo#131165
Related: odoo/enterprise#45413
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
In this commit, _t import from import { _t } from
"@web/legacy/js/services/core" and from
web/static/src/legacy/js/core/translation.js are replaced by
@web/core/l10n/translation.js.
task-3292454
closesodoo/odoo#130865
Related: odoo/enterprise#45270
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Users are not able to reorder lines on order having more
than 40 lines as only 40 lines are shown by default.
In some advanced flows, new lines are automatically added to the
end of the lines and the user has no way to move them back in
the first ones (or in a specific section if it's not on the same
page).
opw-3437983
closesodoo/odoo#130956
X-original-commit: b316cd61bff1c05f8b07d036e9c0409998982a69
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
before this commit, in the sale.report tree
view, the product field was not added.
* sales -> reporting -> switch to pivot
* click on any row to open the tree
after this commit, the product field will
be added in the sale.report tree view.
closesodoo/odoo#129303
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
before this commit, if there is multiple sale order for a
customer, and if we try to create new invoices for this
orders from the tree view, it creates one invoices for
all the orders.
there will be cases, where we have to create separate
invoices for each orders.
after this commit, a boolean will be introduced in the
wizard, by which user can decide one invoice or multiple
invoice by grouping sale order.
closesodoo/odoo#128351
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Summary
-------
Currently, the credit limit feature does not correctly take currencies
into account.
Steps to reproduce
------------------
* install `sale_managment`
* enable 'Sales Credit Limit' in the settings
* on a partner's form view, in the accounting tab, enable
`Partner Limit` and set a limit of 50
* have a currency `C` that's weaker than your company currency (we'll
call it `Q`). Let's say that here, `1 Q = 10 C`.
* have a price list in currency `C`
* create a quotation using the partner and price list mentioned above
* add a product with a price of 5, and no tax.
You should be met with a warning indicating that the customer has
reached his credit limit.
opw-3441361
closesodoo/odoo#130652
X-original-commit: f57653a6dcea04f0bca4e5ca73df3e1075e0fe98
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
To reproduce:
- Create a Distribution model, with an analytic distribution
and an effect on Partner A
- Create a Sale Order, for Partner A
- Confirm it
- Add a line on this Sale Order
=> The new line does not get the distribution of the model
It couldn't be done before 16.0 because a compute would trigger when posting the sale order, because date_order was used for the default rules, and so would trigger it at wrong times.
Distribution Models don't use this date anymore, so the compute won't happen at wrong times.
task-3355886
closesodoo/odoo#130597
X-original-commit: 22fd34b0d8b944a7afd031b894d750a8291d0aba
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Simplify model custom code when dealing with phone and sms by using helpers
and standard behavior defined on all models.
'_sms_get_partner_fields' was introduced at odoo/odoo@bdebcab0ce to have a generic
implementation of finding partners on a record. Since then another version
has been added directly in 'mail' module, using '_mail_get_partners'.
'_sms_get_number_fields' was introduced at the same time to have a generic
implementation of finding numbers on a record. Since then a generic and
improved version has been added directly in 'phone_validation' module, see
'_phone_get_number_fields'.
Those method can therefore be removed, and replaced by the generic ones
available on BaseModel.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130468
The test test_product_quantity_rounding fails when the currency
of the company rounds to the unit (decimal places = 0).
This commit makes sure the test doesn't fail with that setup.
Cf runbot build error 20612
closesodoo/odoo#130285
X-original-commit: fae7beacd950fcc349728f98681b6aa281572aa4
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The test verifying the values of the sale report in a multi-comp & multi-curr
environment relies on the fact that the main company is by default in USD.
Nevertheless, the test fails when a localization is installed (if it changes
the currency of the main company).
This commit makes sure the tests always works, and resurrects the right tool
for that, which was dropped in commit 3752b3166e.
Cf runbot build error 22351
closesodoo/odoo#130201
X-original-commit: a73b5fce4fb02eefc681c55eab8f57cd35105226
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In a previous commit 8bfa76a, _lt() returns _t().
So, in this commit, all usages of _lt() are replaced by _t().
task-3292454
closesodoo/odoo#130179
Related: odoo/enterprise#44906
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Since the relational model was rewritten (PR 114024), the record id is
no longer present in data by default. The correct way to access the id of
a record is to do record.resId.
closesodoo/odoo#130061
Related: odoo/enterprise#44785
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Public users do not belong to "feature" groups, so anonymous users
downloading their SO report thanks to the access_token won't ever see
the discount column as the user of the request doesn't belong to the
"Discount" group.
opw-3322583
closesodoo/odoo#129962
X-original-commit: 369d71b9fb013dc87c311da6fbad47692bfcbdaa
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
For sale orders, if the invoice status is set to "Fully Invoiced", the mount to invoice is forced to zero.
task-3347812
closesodoo/odoo#124777
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
This commit fixes a really old grammar error in the help message of the
message_needaction_counter field.
Before this commit: “Number of messages which requires an action”
After: “Number of messages requiring action”
The subject of “require” is “messages”, which is third-person plural, so
it can't take the -s suffix.
closesodoo/odoo#129468
X-original-commit: 0d10cfeaa56d5df23df05f436d353978043f4a71
Related: odoo/enterprise#44509
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
A recent trend in report design in Odoo has been to dynamically set the
report template to call using a python method. This was used e.g. to
detect that a document should use an alternative report layout created
by a localization package.
Unfortunately, doing so 'breaks' the new report editor, as it runs
without an underlying record, and therefore cannot call python methods
to determine what the template id to call actually *is*.
This commit removes this mechanism from the Sales app and the Brazilian
localization, relying instead on 'normal' qweb directives and
inheritance to generate the proper layout.
This commit does not introduce any functionnal changes, it simply makes
the templates compatible with the new report editor. No visible change
should occur.
X-original-commit: cd26f77adecc7036c845ed1d7c7094b63987a1a1
Part-of: odoo/odoo#129492
Includes several modifications to better work with the new editor:
- add placeholders on t-field/t-out nodes
- add several div.oe_structure containers in key places for easier user
edition
- add branching options for several t-if directives without a t-else to
display for users (e.g. displaying the payment QR code if the value is
set vs. when the value is not set). These branching options are set to a
default value (the t-if node) which is what users see by default in the
report editor; the t-else node is a version they can manually toggle if
they wish)
- avoiding 'naked' t nodes as child of table/thead/tbody/tr elements, as
these break the table layout in chomium-based engines (that we know of);
instead, try to have foreach loops on tr or td nodes directly, or hoist
t-set directives above the table node
- replace several div or p (block) nodes by span or other inline nodes
to make it easier for users to insert content in their vicinity
X-original-commit: ddace177b9512657e3dee854309835b4b2f9af28
Part-of: odoo/odoo#129492
Setup:
------
1) Install website_sale module
2) Product:
One product with:
- Sales Price: 100
- Customer Taxes: 10% included
3) Fiscal position
Two fiscal positions:
- Country: France - 10% included --> 20% excluded
- Country: Netherlands - 10% included --> 15% included
Steps to reproduce:
-------------------
- without being logged in, go to ecommerce;
- add the produt to cart;
without information on the tax position, we have:
90.91 + 9.09 = 100 --> this is correct
- process checkout;
- Enter an address with the country France;
France:
90.91 + 18.18 = 109.09 --> this is correct
(100 : (1 + 10%)) * (1 + 20%) = 109.09
- edit the billing address;
- use the country Netherlands;
Netherlands:
104.55 + 20.91 = 125.46 --> this is wrong
instead of:
90.91 + 13.64 = 104.55
(100 : (1 + 10%)) * (1 + 15%) = 104.55
(This is just one example)
Issue:
------
There is inconsistency in the application
of taxes according to tax position.
Cause:
------
To calculate the product's price unit, we apply
tax position mapping via the
`_get_tax_included_unit_price` method.
Modifying the `price_unit` field in the
sale order line will trigger the
compute method `_compute_amount`.
This recalculates the amounts,
but without taking into
account the tax position mapping.
We therefore use a value for the `price_unit`
field which is not in line with the taxes.
Solution:
---------
Recompute sales order line taxes
when a change in fiscal position is detected.
opw-3318971
closesodoo/odoo#129440
X-original-commit: cdb9819b0e199f95d489e8cfe4217cf6de6362b3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Feyensv <vfe@odoo.com>
Have a field x2many without relation_field.
Before this commit, a server error was raised because, we send changes
for the non-existing field (relation_field).
Now, we only send to the server the changes for relation_field only if
they exist.
Note that, this commit will also add an exception on the server mock
onchange if we sent changes for non-existings fields.
Part of task~3179751
Part-of: odoo/odoo#114024
This commit adapts the code in addons w.r.t. the introduction of
the RelationalModel.
Main changes that were requested are:
- record datapoints no longer always have an "id" key in their
data (they still do if the id field is in the view), so we use
record.resId instead
- the new model is based on fined-grained reactivity, so several
components that previously relied on onWillUpdateProps to update
their internal state no longer worked. Typically, using the hook
"observeRecord" is the way to go now.
- specialdata are no longer handled in the model, so the components
needing specialData can use the hook "useSpecialData"
- more generally, all overrides of models (RelationalModel or
KanbanModel) needed to be reworked.
Part of task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Steps to reproduce:
- Install website_sale, contact, l10n_ch
- make sure your company is in Switzerland and has all the address information
- in settings, activate QR
- in Accounting/Journals/Bank:add a bank account (iban: CH4431999123000889012; qr-iban: CH11 3000 5228 1308 3501 F)
- install and enable the provider "Wire Transfer"
- From the Website, create an order and make sure the customer set an Invoicing address in Switzerland (address + Country)
- Validate the order
- In Website/unpaid orders: select your order and Confirm the order
- Create and confirm the invoice
- Print the invoice
Issue:
User Error is raised
Cause:
With Swiss QR code you need to have a valid payment reference. That is, an ISR reference such as in
https://github.com/odoo/odoo/blob/c6631df1c5b0b6d4c2268a826ca150edd0ca653e/addons/l10n_ch/models/account_invoice.py#L90
But when you create an order from the website, it creates an automatic reference "SO0001" which, when converted to an invoice, stays the same.
Since the reference is prepoluted, the `_compute_l10n_ch_isr_number` will not be triggered and therefore will raise an error when trying to print the invoice.
Solution:
Check if the Customer Invoice Journal uses the swiss reference model, then we know that the swiss loca is installed and can call the correct function to compute the reference/
Note:
In the test we check that `payment_custom` is installed. It is because the `_set_pending` method checks taht the payment_provider.code is "custom"="wire_transfer" in which case the sale order reference is computed
https://github.com/odoo/odoo/blob/b4ed9537895ecee48ed146add4257af0aebeb3f4/addons/sale/models/payment_transaction.py#L54-L56
opw-3334534
closesodoo/odoo#127338
X-original-commit: dfa4844e57b67d16b181e1e58813cdbbc7efa956
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Co-authored-by: flvr-odoo <flvr@odoo.com>
This commit makes hotkey uses more coherent throughout the entire
codebase by setting alt+q as main shortcurt for confirm and default
actions and alt+x for cancel actions.
task-3370463
closesodoo/odoo#127469
Related: odoo/enterprise#43694
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
The Reserve Bank of India (RBI) issued a directive (amended subsequently
in December 2020 and March 2021) that introduces additional security
measures for recurring payments on India-issued cards. These measures
include:
- Banks must register cardholders and create an e-mandate through a
one-time process, using additional factor authentication (AFA)
like 3D Secure (3DS).
- Banks must alert cardholders at least 24 hours before charges take
place and give them the ability to opt out of transactions.
- Recurring transactions over 15,000 INR (or equivalent in other
currencies) must go through AFA each time.
Stripe has worked with a partner platform to support that, but we must
manipulate the PaymentIntent and SetupIntent objects directly through
their dedicated API, which the Checkout API does not allow. Therefore,
we must now integrate with the Elements API and implement a direct
payment flow instead of the current payment with a redirection flow
powered by the Checkout API.
After this commit, Stripe will create an e-Mandate for every
Indian-based card newly saved in Odoo.
task-3322020
closesodoo/odoo#123573
Related: odoo/documentation#4719
Related: odoo/upgrade#4748
Related: odoo/enterprise#42196
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit: Body content is the same as tmeplate
After: Body content is the same as the template
*: hr_recruitement, sale, survey, website_slides
closesodoo/odoo#128953
X-original-commit: 388e340a52fd5775c1702f8952a1e959fa5cef48
Related: odoo/enterprise#44309
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Each order does necessarily have the same confirmation template.
And `_get_confirmation_template` is `ensure_one` so it raises when self holds multiple records.
closesodoo/odoo#128743
Forward-port-of: odoo/odoo#128551
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Previously, customers were not allowed to sign a draft quotation.
We consider that if the customer has access to the quote, he should be able to sign/pay it (instead of getting some strange feedback that the order is not in a state requiring signature/payment)
task-3340541
closesodoo/odoo#124486
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When creating a Vendor Bill, the default Sales Team & Person of the company is
assigned to the Vendor Bill. The field isn't even displayed, it's hidden, you
can only display it with Studio and can't even change it.
The fact is : purchases and sales are two completely different roles and
business in companies. This has the indirect consequence that any user that
follows the default Sales Team will get notified of any new Vendor Bill created
in Accounting, which he very likely does not need/want to see.
This PR correct that by adding a condition on the filling of these fields. These
fields will be filled when the move is a sale document.
closesodoo/odoo#120628
Task-id: 3279233
Related: odoo/enterprise#44034
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Since 7bd93cc64b, we add the amounts to
invoice from sales order to the credit limit warning. When looking at
the credit amount on a partner from an accounting perspective, it is
not correct though that sales orders to invoice are considered as well.
In this change we split the credit amount from invoices and from sales
orders to invoice. On the partner we only show the credit amount from
invoices. In other places we add both.
task-3375260
closesodoo/odoo#128158
X-original-commit: 94eae9b73995dbf2175ecee65548ace5a382f5f8
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Issue:
The `_compute_amount_to_invoice` computation wasn't taking
into account the fact that invoices have a direction (i.e. either
going outbound(+) or coming inbound(-) (cf. `_compute_direction_sign`)).
This, in turn, makes the value of `amount_to_invoice` incorrect
for sales order with a credit note.
Solution:
In `_compute_amount_to_invoice`, multiply the value of
`invoice_amount_currency` with the opposite of the
`direction_sign` of the invoice, to account for the invoice direction.
opw-3360439
X-original-commit: 06ef17f2eefe89abfca64721185ac053fa8de820
[FIX] sale: fix amount to invoice for credit notes
Issue:
The `_compute_amount_to_invoice` computation wasn't taking
into account the fact that invoices have a direction (i.e. either
going outbound(+) or coming inbound(-) (cf. `_compute_direction_sign`)).
This, in turn, makes the value of `amount_to_invoice` incorrect
for sales order with a credit note.
Solution:
In `_compute_amount_to_invoice`, multiply the value of
`invoice_amount_currency` with the opposite of the
`direction_sign` of the invoice, to account for the invoice direction.
opw-3360439
closesodoo/odoo#127914
X-original-commit: d258774f120fb470d969e68c05cf0d8da0c4557a
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Since odoo/odoo@2b1e2abda3 user need at least 'Account / Billing'
access to read payment.transaction, that not the case for most salesman.
So for user that don't have 'Account / Billing', this commit do:
- compute the 'amount_paid' as superuser
(fixing "Generate Payment Link" wizard access errors)
- hide "Payment Transaction" smart-button on invoice
closesodoo/odoo#127835
X-original-commit: ad2c3a873a926ac8c94d014af24ed400b493493e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
Matheus Leal Viana (malv)