Small visual changes that should improve the user experience.
The loading demo data popup has been moved to the backend.
Created an Alert Popup that is less aggressive than an Error Popup
closesodoo/odoo#83780
Task-id: 2485062
Related: odoo/enterprise#26104
Signed-off-by: Masereel Pierre <pim@odoo.com>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Before this commit: If a fixed tax is used for a product with the price
of zero, the tax line sign would be positive and lead to an unbalanced
move. The solution is to use its sign in its context for correct
calculation.
Also, in the PoS front-end, when you want to return a zero amount
product with a fixed tax, its sign would be positive, which is
incorrect.
Steps to reproduce the first issue:
- Install 'Point of Sale' module
- Create a new 'Tax' X with a fixed price (e.g.: 1 $)
- Create a new 'Product' with zero Sales Price
- Create a PoS session
- Add the product to the order
- Close the session
It creates a line for the "Difference at closing PoS session," and
doesn't prevent closing. But the problem is that the tax capture as
debit is incorrect. The tax for the invoice must be credit.
Steps to reproduce the second issue:
- Install 'Point of Sale' module
- Create a new 'Tax' X with a fixed price (e.g.: 1 $)
- Create a new 'Product' with zero Sales Price
- Create a PoS session
- Add the product to the order
- Change the quantity to -1 (refund)
The final amount is positive, while it should be negative.
Solution
The sign must be sent in the context, and for the PoS front-end, it
should consider zero amount cases.
opw-2833590
closesodoo/odoo#95067
X-original-commit: c5fb4f778db95fb33845b9a5e0c2190d4d9037ee
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This change removes the `barcode_nomenclature_id` in the `pos.config`.
Each pos session now starts based on the company's barcode nomenclature.
closesodoo/odoo#93072
Task-id: 2849415
Related: odoo/upgrade#3575
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
When you are in anglo saxon accounting with posting stock changes at the
end of the session, we get an issue by using the refund feature in
backend.
If you have an order invoiced, and want to refund it, it'll create the
picking of the order immediately, which is not normal as it should only
be done when there is an invoice.
The problem is that the value of the field 'to_invoice' from the
original order is copied to the refund, and so act as the invoice is
made for the return.
To avoid this behavior, we are avoiding to copy it.
OPW-2848356
closesodoo/odoo#93645
X-original-commit: e8ef74397c0b02d051823142c3457413aabfeb21
Signed-off-by: Masereel Pierre <pim@odoo.com>
When you are shipping later from POS and have a multi-step
configuration, you get an error saying that you cannot unreserve more
than what is reserved. It comes form a bad filtered list of move.
Now as we are correctly filtering the move on their product_id it
correctly works.
OPW-2854159
closesodoo/odoo#93336
X-original-commit: 93e0509d0ba7302ecdf5d0f6dbc2dbe90e98229d
Signed-off-by: Masereel Pierre <pim@odoo.com>
Purpose:
- Move PoS settings in general settings to be consistent with the rest
of Odoo (PoS being the only app where settings are split in two locations)
- Clean settings by enabling obvious settings or dropping unnecessary ones.
closesodoo/odoo#84719
Task-id: 2753430
Related: odoo/upgrade#3260
Related: odoo/enterprise#24425
Signed-off-by: Masereel Pierre <pim@odoo.com>
After a fix made in rev:bd621fd456811e7f3ce646e3ecade5e9e4a826e8
It was not possible to generate an invoice from the POS when you have a
fixed tax included applied on a base amount with tax included.
As it was not detected by a test, we are now creating a test with this
use case.
closesodoo/odoo#92106
X-original-commit: 291b564ffebaf8b8708072c981d1072b8bb33677
Signed-off-by: Masereel Pierre <pim@odoo.com>
Forward-port of PR odoo/odoo#86643.
Add a unittest for multi_step route on Ship Later warehouse to
ensure that the fix 5959d77f344 is not unintentionally reverted.
closesodoo/odoo#89595
X-original-commit: d5fb77e9d4716dd509e2e98ff39f7e1cb91ddaca
Signed-off-by: Masereel Pierre <pim@odoo.com>
Steps to reproduce:
1. pos.config is in company1
2. create a partner with company = company2
3. change pos.config to limited partners loading
4. open the pos ui (to call load_pos_data)
old behavior: access error
closesodoo/odoo#89013
Now: method is called without error
X-original-commit: eade911354dac775b3b96212698dbb7e2d644390
Signed-off-by: Masereel Pierre <pim@odoo.com>
revert commit https://github.com/odoo/odoo/commit/5f25be8eef9a9efc18a995f2c6405d08a657ac96
Goal:
- Gives the expected tag to the account move line created by the PoS.
- Add tests to the PoS regarding the created account move line
Before this commit:
If the configuration was set to round_globally, a pos.order.line was processed
as a refund only if all order.lines were a refund.
This leads to unexpected results in the tax report. Indeed,
since commit https://github.com/odoo/enterprise/commit/46769076526701d96ee4f2653e44b57604cc0b7a
"Negative" line in PoS (debit) are processed as positive to give a
correct results.
This means that if a line is set as debit and is suppose to lower a
line, it makes it bigger.
Example:
aml from PoS: debit: 10 tags: +03
---> report.line [03] is suppose to make a -10 but will do a +10.
As a result, report line [03] is false.
After this commit:
PoS never use "invoice_repartition_line" to create a refund line.
closesodoo/odoo#85461
Ticket: 2718998, 2714310, 2746890
Community-pr: https://github.com/odoo/odoo/pull/85149
X-original-commit: e4dedaf08b41cf3d80bfb01e70de714c9a84167d
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
This commit gives the possibility to create pos_order_line with discount
This is needed in order to reproduce real usecase.
X-original-commit: 49bfb576a76e2ad4449326c4b12ebf57bece7069
Part-of: odoo/odoo#85461
This commit accomplishes multiple objectives:
1. Loading of model data for the POS UI is now done in single
request (with some exemptions).
2. Backbone.js is removed and is replaced by reactivity.js
authored by the js framework team.
3. Better organization of assets in the `__manifest__.py`
Data Loading
------------
One request per model -- that's always been how the data is loaded
in POS UI. Now, we move the aggregation of data to the backend which
simplified the data loading. In the frontend, data loading is
initiated in `load_server_data` which makes the single rpc call
to the `load_pos_data` defined in `pos.session` model.
There remains some rpc calls during loading but the number is
greatly reduced.
This change result to faster loading of the POS UI. However,
there is no more progress bar during the loading.
Notable entry points:
- .js: `PosGlobalState.load_server_data`
- .py: `pos.session.load_pos_data`
It is possible to make customizations in the loading, but is done in
several steps:
1. Override `_pos_ui_models_to_load` to include the new model to load.
2. Define `_loader_params_<model_name>` to define the `search_params` and
optional `context`.
3. Define `_get_pos_ui_<model_name>` to return the data that will be
included in the full `loaded_data`. Perform the organization in this method
whenever necessary.
4. Override `_pos_data_process` for further post processing. The final
form of `loaded_data` in this method will be sent to the frontend.
Removal of Backbone.js
----------------------
POS is no longer dependent from `Backbone.js`, but it's replaced by a
new dependency -- `reactivity.js`. It's invented by the js framework
team which will be available in owl v2.
The consequences of this change are the following:
1. The old `PosModel` is renamed to `PosGlobalState`.
2. The name of the other models are kept (except Paymentline which
is renamed to Payment).
3. The name `PosModel` is now used as the base model of the data models.
This is symmetric to our use of `PosComponent`.
4. The instance of `PosGlobalState` is made reactive in `Chrome` (the
root component). As a result, whatever mutation made in that instance,
`Chrome` will rerender. But rendering is batched so multiple mutations
in a single sychronous function call will only result to a single
render call.
5. `PosModel`s can be extended in the `Registries` the same way as we
extend the `PosComponent`s.
```js
// E.g.
Registries.Component.extend(Chrome, PosResChrome);
Registries.Model.extend(Order, PosResOrder);
```
Reorganization of assets declaration
------------------------------------
This is a simple change that replaced the explicit enumeration
of loaded .js and .xml files. Also, we now have regions in the
manifest separating:
1. Augmentations of dependencies
2. Assets for `point_of_sale.index`
3. Assets for the qunit test (soon will be improved)
Other notable changes
---------------------
- Automatic call to `Order.save_to_db` is batched.
- Instances of `devices.DeviceProxy` (`proxy`), `devices.JobQueue`
(`proxy_queue`) and `BarcodeReader` (`barcode_reader`) are moved
to `point_of_sale.env`. Together with `posbus` and `posMutex`
(previously `flush_mutex`).
- `ActivePrograms` is now passed a props.
- `cashier` is no longer saved to `localStorage`.
- `pos_cache` is overhauled.
- `cache` is taken out from `PosDB` to prevent infinite rendering
loop whenever `cache` is mutated. It's now called `CACHE` in
the `db.js` file.
- reactive version of `posmodel` is exposed globally when in debug mode.
This means that calling when calling a mutator, the UI will react.
- Added control buttons in the `ProductScreen` is sorted during `Chrome`
setup. As a result, we don't need to worry on the loading order of the
control buttons components.
- Model can be simply instantiated using `BaseModel.create(obj)`. This
takes into account the extensions.
- `pos_coupon`: rewards are now updated whenever set_order is called.
- Component unit tests were removed. It wasn't useful and it just blocks
the development. We'll be introducing better unit testing later.
closesodoo/odoo#82461
Related: odoo/enterprise#23344
Signed-off-by: Masereel Pierre <pim@odoo.com>
Co-authored-by: Jacky (trj) <trj@odoo.com>
In case the product is tracked and the "Ship Later" feature is enabled,
the lots defined on the POS order are not the same that the ones on the
SMLs of the associated picking
To reproduce the issue:
(Use demo data)
1. Create a product P:
- Type: Storable
- Tracked by lots
- Available in POS
2. Update P's quantity:
- 2 x Lot01
- 2 x Lot02
3. Edit the existing POS:
- Enable the "Ship Later" feature
4. Start a POS session
5. Add some products:
- 1 x P (Lot01)
- 1 x p (Lot02)
6. Process the order with the option "Ship Lated" selected
7. Open the associated delivery order
Error: The reserved lots are incorrect: 2 x Lot01 instead of 1 x Lot01 +
1 x Lot02
When creating such a POS order, if the feature "Ship Later" is used, a
method creates a procurement for each POS order line thanks to
`_launch_stock_rule_from_pos_order_lines`
https://github.com/odoo/odoo/blob/72d6431eb26654b697fc0379f4b6d7e305bb79fc/addons/point_of_sale/models/pos_order.py#L677-L680
Then, these procurements are managed by the standard process, which does
not consider the defined lots. This is the reason why it simply uses the
available quantity in the first lot.
OPW-2704352
closesodoo/odoo#81888
X-original-commit: bc59c4eb7ef6bc216474f39ef8e2634b4ab5ff42
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Purpose
=======
The fields are not used, don't work correctly and there is a specific
report to generate the product prices according to the pricelist and
the ordered quantities
* Do not rely on context, everything should be cleary specified through
parameters
Catch context keys in an unique targeted place to improve code clarity
* Drop strange old API
* do not provide unused partner parameter anymore
* do not provide products, qty as a list of tuple, we only request the
same qty for all products anyway
* Clear methods, add/adapt comments and docstrings
* Reduce potential side-effects of context content.
* remove `component_extension_tests`, that's a test from web and
already tested by web, no idea why it's rerunning in POS
* remove all failfast specs, after discussion with ged, seb, and
xdo it was considered not useful: it's mostly for the runbot but
turns out to be pretty minor as far as positives go, and it makes
fixing errors much harder
Part-of: odoo/odoo#77735
Since changes made in currency rate default value made in this PR
https://github.com/odoo/odoo/pull/76513 the date is stored based on user
timezone, and so doesn't work if the test runs around midnight with the
belgian timezone on the servers.
closesodoo/odoo#78480
X-original-commit: 0dc9a2d47833f2a13dce9891e7710815b4d27584
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The opening cash control has been refactored and the closing of the session is now happening in the POS UI. This also leads to a cash control in the UI during the closing.
The advanced cash control is no longer a setting to activate in the config by the user but a computed field based on the presence of a cash payment method. We force the user to always have it now.
The opening cash control has been revamped with the addition of a new money calculator (`MoneyDetails`) allowing the user to easily compute how much money does he have based on his bills.
The closing control has been converted into a popup which allows the users to get an overview of his session details (about orders, payments, payment methods, cash moves, ...). If the `cash_control` has been set to `True`, the user still needs to count his money by introducing it or using the new calculator.
When trying to close the session, if it fails, depending on the error the user get, he can be redirected to the back end to manually close the session. At this point, the user is not able to open the POS UI.
(In order to fully bring the closing of the session in the front end, all the error handlings need to be brought to the front end as well which takes a lot more time.)
Rescue session can only be closed through the back end and the closing cash control is automatically being computed without the user's involvement. This avoid any cash profit/loss in the journals.
The session chatter is being logged with all the details regarding the opening and closing. This give the user a better view of his cash flow in a specific session.
task-2456424
closesodoo/odoo#73464
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
We are referring to TicketScreen and OrderManagementScreen.
The two screens almost serves the same purpose. There is not much reason
to keep them separate. We combine the two in this commit. Basically,
we remove OrderManagementScreen and its components. Some are kept and
moved to the TicketScreen.
Task-id: 2481404
Part-of: odoo/odoo#75322
When selling a tracked product, if the latter has already been sold
once, the source location of the associated stock move will be
incorrect.
To reproduce the error:
1. Create a product P
- Product Type: Storable Product
- Available in POS: True
- Inventory: By Lots
2. Update P's quantity > 0 with lot L
3. Start POS session
4. Sell one P with lot L (Register payment + Validate)
5. Repeat 4
6. Go to Inventory > Reporting > Product Moves and apply one filter:
- Product: P
Error: There are 3 product moves:
- One from Inventory adjustment to Stock
- One from Stock to Customers
- One from Customers to Customers
The third one is incorrect and should be from Stock to Customers.
Because of the first sale, a `stock.quant` is created and indicates that
one P from lot L is at location "Customers". When selling the second
one, because of the OR-condition, this `stock.quant` is selected. The
condition should be an AND-condition.
This fix is an improvement of #69750. The new test checks the above flow
and the one described in the related PR.
closes#71435closesodoo/odoo#71573closesodoo/odoo#75265
X-original-commit: e0921851a1f1a636169e62f47b4d4c32255f98ed
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Automatically activate `group_multi_currency` if there is more than one active currency,
deactivate it if there is only one active currency
retain sale/pos feature of activating group_product_pricelist
adapt tests accordingly
Task 2610735
closesodoo/odoo#74396
Related: odoo/enterprise#20106
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Margin has been added to both Order and OrderLine allowing the user to have a better view on his profitability. Margin also has been added to the order report as a measure.
Related task id: 2455794
closesodoo/odoo#66689
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
In some use cases, the seller in point of sale needs to add a note on an
order line that has to be displayed on the receipt. So we've added a
field on the order line to set a note.
The note is also set on the invoice if the order is invoiced.
closesodoo/odoo#71598
Task-id: 2556994
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When having several POS with cash control, if at least one POS already
has a closed session with cash in box, the first session of the other
POS may have an incorrect opening amount
To reproduce the error:
(Let POS01 be the existing point of sale)
1. Edit POS01's settings:
- Enable "Advanced Cash Control"
2. Duplicate POS01 (-> POS02)
3. Start a session with POS01
4. Sell one product, payment in cash (Let P be the product's price)
5. Close POS01's session (correctly set the closing cash)
6. Start a session with POS02
Error: On opening cash control, the opening amount is P, it should be 0
OPW-2574096
closesodoo/odoo#72803
X-original-commit: ba86192043ad014a0e13867a66816acede64c897
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
This commits is about two problems. The first one is a undesirable
warning message displayed when closing the POS session
To reproduce the error:
1. In POS settings, enable "Advanced Cash Control"
2. Start a POS session
3. Make an order of 70$, payment in cash
4. Close the POS session (correctly set the closing cash)
Error: When clicking on "Close Session & Post Entries", a warning is
displayed: "There is a difference between the expected and actual
closing in cash. Are you sure [...] ?" However the actual cash is equal
to expected cash so the message does not make sense
The error has been introduced with commit 7252350d35c6e8e7f47458c3aedcf05d92e71afa,
so the current commit reverts it.
However, the reverted commit was a solution to a second problem: When
cash control is disabled, if the user opens and closes a POS session
(without any order), the ending balance of the associated cash register
will always be 0. Here are the explanations: if cash control is enabled,
when the user sets the closing cash, it creates a record:
https://github.com/odoo/odoo/blob/80c28189ae6b10ad17c4de2a781233a8ffe663a6/addons/account/models/account_bank_statement.py#L82-L98
and therefore, thanks to `_validate_cashbox`, `balance_end_real` will be
defined with its correct value. However, there isn't anything to define
the ending balance when there isn't any order and when cash control is
disabled.
OPW-2580699
closesodoo/odoo#72763
X-original-commit: 550e7280212b740bfce72331f6d0aef99b7aadb6
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Acronyms:
SRL : receivable lines in the session's account move that balances
the receivable lines in the session's invoices
IRL : receivable lines of the invoices in the pos session
When closing a pos session, a single account move is created to capture
all the transactions, but, invoices are kept (each is an account move).
During the construction of this single account move, SRLs are
reconciled with IRLs.
Prior to this commit, when closing a pos session, SRLs are grouped
by `property_account_receivable_id` of the partners in the invoices.
Because of this, SRLs are blind of the partners that they are linked
to. This causes issues on tracking the 'due' in the partners that are
invoiced using the pos application.
To fix the issue, we now group the SRLs by partner before reconciling
them the the IRLs.
Same concept is employed for receivable lines generated from split
cash payments, we also assigned partner to them if applicable.
closesodoo/odoo#70662
X-original-commit: 861612baf57caa67afb32ab904fb8aa26a353dd7
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Beforehand, if two users independently opened a draft
invoice on their respective sessions, then both of them
clicked on the "Post" button, then the invoice was
posted twice.
On a more general aspect, the view currently "prevents" users
from posting moves several times, but technically speaking,
nothing stops users from posting moves several times.
Now, after checking that the user indeed has the right to post
a move, the next check is about verifying that the move is
not already posted.
opw-2479201
closesodoo/odoo#69178
X-original-commit: b7db7db283d7b9d167201b791e6282b022d59c40
Related: odoo/enterprise#17658
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Julien CHEVREAU <Julien-CHEVREAU@users.noreply.github.com>
1. Have a [DEMO] product in stock with an owner
2. Make a PoS order with [DEMO]
The system will use the stock without owner.
opw-2480341
closesodoo/odoo#68951
X-original-commit: eaa9c6cc9481fb97d8c44aa057fc97accfc4d649
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This commit removes stock.inventory(.line) and moves its general
functionality into stock.quant. Some features are lost during this
switch as well.
Feature Additions:
- New single list view for inventory adjustments (no more multiple
inventory adjustment records to keep track of!)
- Improved cyclic counts (annual inventory day setting) + next inventory
dates are immediately viewable in view (vs auto-generated inventories
based only on location)
- Specific quants (i.e. counts) can be assigned to users for more
flexibility (vs only able to restrict by location + product
combinations)
- Counts can be requested (i.e. bulk assigned to user/for a specific
inventory date)
Feature Removals:
- Can no longer look at previous inventory adjustments linked to a
specific record. Each quant has a history button to show inventory
related moves. [relevant account moves are also now harder to see via
stock as well]
Other changes:
- Bulk of changes were for demo/test
- Some changes were done to ensure "Update Quantity"/"Inventory Report"
views still mainly function the same as before with the exception of a
new column added to support updating quant quantities in these views.
Task: 2440026
ENT PR: odoo/enterprise#17329
Upgrade PR: odoo/upgrade#2326closesodoo/odoo#68409
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Part of task 2124952
By using AccountTestInvoicingHttpCommon, we have a setup independant
from the demo datas. This also prevents running tests with incompatible
localization: the tests for l10n with another currency than USD failed
because of the demo datas preventing the change of currency.
When closing pos.session and it turned out that during the creation
of journal entry the move lines are not balanced, pos automatically
balances the lines by crediting the amount to balance and recording
it to the default pos receivable account.
In this commit, we are changing the behavior by allowing the user
to choose which account the imbalance amount be recorded. So the
workflow becomes:
1. Close pos session fails.
2. Wizard shows the amount to balance and asks which account to
record it.
3. Confirm the wizard to successfully close the session.
closesodoo/odoo#62425
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Instances like deleting a tax used in a pos.order before closing a
session is allowed but it renders error when closing the session
because of imbalance move lines. In this commit, we are adding
a 'balancing' line in the move before it is created. This ensures
the closing of pos session. The introduced move line is named
'Difference at closing PoS session' and is a receivable making it
easy to find and can be reconciled.
closesodoo/odoo#62308
X-original-commit: 7b9545387962981b5729318e2bbc5714dcbac68c
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
Tours with `step_delay` potentially hide errors because of missing tour steps.
This is mainly caused by unfinished renders within the `step_delay` between
two steps. It is possible that the render after the 1st trigger is not yet
finished but the 2nd step trigger already existed in the screen. Because the
render result of 1st step is late and the 2nd step is already triggered, the
3rd step will fail. Note that the 3rd step will occassionally fail because
render of the 1st step is most of the time faster than step_delay but
there is no guarantee that the render is always faster because of occassional
cpu slow downs.
Runbot will eventually catch these tour errors which it did with the ticket
screen tour.
In this commit, we removed the `step_delay` in the pos tours. We also
supplemented the missing step in the ticket screen tour which was the cause
of random runbot error when there was `step_delay`.
We also figured that value property of input element is not observed by the
tour service's mutation observer, which result to an indeterministic error
in a step in tip screen. To fix this, we introduce an attribute to the input
element which is used in the step trigger.
closesodoo/odoo#56961
X-original-commit: 2ef73bb64cd0730d1e078a47f2ea9e1290b0df6c
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
HTTPS had been disabled on SaaS to allow the use of the IoT Box that
had no valid SSL certificate. As of V13.0, IoT Boxes connected to
Enterprise DBs have a valid certificate. POS can then use HTTPS.
Nginx is configured to redirect all requests to `/pos/web` to HTTP,
so we change the POS URL to `/pos/ui`, except when using a Six
payment terminal as it only works in HTTP.
closesodoo/odoo#56933
Taskid: 2191878
X-original-commit: 8aee4992778fee5e2f146c4cff8b35e83c7f56b3
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
Aside from new look, we also move the email option from payment
screen to receipt screen. This allows emailing the receipt to a
customer that is not in the contact list.
We also removed invoicing in the receipt screen during failed invoicing
from payment screen as it is removed in here: bc48e0033eclosesodoo/odoo#55868
Related: odoo/enterprise#12395
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The following changes are made in this task:
1. Remove order tabs and replace with ticket list.
2. Top bar color change.
3. Search bar in the product screen is moved in the top bar.
4. List of sub-categories are now in the same line as the category
breadcrumbs.
closesodoo/odoo#55100
Task-id: 2276678
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
Jacky (trj)