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