If money is withdrawn, we can't tell if it's a transfert to the bank account or if some money has been withdrawn to pay an invoice or some expense.
We then assign the suspense account in order for the accountant to go through the reconciliation widget process in order to dispatch/assign the amount to the right account(s).
This allows all the accounting process to go smoothly without any needs for the accountant to manually create a miscellaneous entry.
Introduced by:
closesodoo/odoo#82616
Pr: https://github.com/odoo/odoo/pull/82123
Commit: https://github.com/odoo/odoo/commit/336656e0e9677ccb2f43935b6f267fa83ed153df
X-original-commit: 04396e0627fd36d28b047e0e122ffb55a3a12ebc
Signed-off-by: Florian Gilbert <flg@odoo.com>
Issue: When closing a PoS session, the user can Cash In/Out of the
register but it requires Accounting/Billing group or Purchase/User
group. However with Purchase/User group, there was an access right
error (not allowed to create account.move.line
Steps to reproduce :
1) Install PoS Module
2) PoS > Your Shop > Settings and enable Advanced Cash Control
3) As administrator and in debug mode go to
Settings > Users & Companies > Users
4) Remove Accounting, Inventory and Purchase group of [User A]
5) Log in with [User A], open a PoS Session, close it, and in Cash
Control form, click Cash In/Out
6) Remove or add money
-> Access right error, you need to be Accounting/Billing or
Purchase/User
7) As administrator, add the User group to Purchase for [User A]
8) As [User A], click Cash In/Out, removed or add money
-> Still access right error
Why is that a bug:
The first warning asks us to give the Purchase/User group to the user
if we want to Cash In/Out but even when doing that, the access rights
are still not enough to allow the creation of the entry
opw-2611298
closesodoo/odoo#75156
X-original-commit: a28c9c1dd773f26151d6734d476e7f8d5a3d971b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
When you have a cash journal, you have the opportunity to use a wizard
to easily create the statement. There are two wizards, one to add money
in the journal, and one to remove money.
To simplify the code and remove some duplication, we are now using only
one wizard, that will allow to add and/or remove money from the cash
journal.
TASK-ID: 1934784
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
It is not possible to take money out or put money in for a PoS since it
leads to a traceback.
The decorator `@api.one` returns a list, which is something we don't
want when the method returns a dictionary.
opw-681417
In Accounting > Bank and Cash > Cash Registers, when clicking in "More" button
on 'Put Money In' or 'Take Money out', the date used for the bank statement line
created must be the date of the bank stattement(same behaviour then when clicking
on "Add item" in edit mode). It's forbidden to put/take money in/out for a bank
statement which is not open.
opw:647631
When a account.bank.statement.line is created by clicking on "Put Money In"
(Accounting(Menu)>Bank and Cash(Menu)>Cash Registers(Menu)>More(Button)>"Put Money In"),
the account.bank.statement linked to this line must be updated(by passing in the write of
this model) to compute the real closing balance. This fix allow to have the same
behaviour than when a line is manually added (with "Add Item) in an account.bank.statement.
opw:647631
Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
This is needed to solve an inheritance problem when adding a superclass
`base.model` (I guess this is related to the fact some code in the orm
does a copy from the class to the instance).
bzr revid: vmt@openerp.com-20130416132621-xo0lckimczqpvyos
[REF] point_of_sale: Review the code for the Take Money Out and Push Money In.
[FIX] point_of_sale: Can post a session with an order in the invoiced state.
bzr revid: stw@openerp.com-20120905150538-v9ex7wehyebft7tu
Improved layout of "PoS orders", "PoS Sessions" and "PoS Config" for useability
Apply new design layouts for web client v7.0
Rename PoS by Point of Sale everywhere
Some typos, improved views
Reviewed menu structure
"Default Point of Sale" field accessible through users preferences
PoS Config:
Sequence is readonly
Removed the "Draft" state --> easier, you do not need to active a PoS Config
Default values on Shop and Journals
PoS Orders:
Changed shop_id & journal_id on PoS Orders --> from normal fields to related field, depending on the session
Open Session:
Fixed the wizard
Several bugfixes and useability improvements
Accounting Transactions posted at the close (not at the control)
Cash Registers:
Lots of cleanups and bugfixes
Pos Sessions:
Fixes and improved layout
Better computation of all fields
removed unused object "pos.config.journal"
PoS Orders:
Default session_id
bzr revid: fp@openerp.com-20120512223743-b1vvbbybo8xq7e54
Laurent Smet