Bank statements are now optional in accounting. The users add statements directly and can assign statements for control reasons.
The users can enter end date and end balance real for the statements and attach the bank statement scan.
The system checks if there is a gap (lines without statement) before current statement and warns the user
with decoration, also we check if the ending balance match the accumulated balance of the last line.
Bank statement lines now show an accumulated balance and can be sorted by drag and drop in the same date, if the user drags a line
to a position with lines of another date, it simply doesn't have any effect.
Rename accumulated balance to cumulative balance, a better name
closesodoo/odoo#99092
Task: 2879904
Related: odoo/upgrade#3906
Related: odoo/enterprise#30824
Signed-off-by: Laurent Smet <las@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
When the admin installs an app, he should see it directly, without having
to give himself the app rights on his user form.
Finetuning of #91909
Task ID - 2936569
Part-of: odoo/odoo#98542
This commit adapts account's model to the new report engine introduced for v16, and updates the data files accordingly.
account.report model is now declared in community, together with the other models used by the reporting. This is done so that the tax tags can properly be created by the tax report and used on tax templates. All the actual computation logic stays in enterprise.
See enterprise commit for full details.
Task 2524389
Part-of: odoo/odoo#94125
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>
It seems most accounting tests relied on the fact that the "accountman"
test user has both the user AND manager groups (but previously, the
manager group was given by the implied group relation "Settings" ->
"account manager")
Part-of: odoo/odoo#91909
For bugfix purposes, app administration groups have been given to
(implied by) the "Settings" group because without those rights,
opening/saving the settings crashed.
1) Do not load hidden view content
This commit uses the conditional inheritance of views
(depending on user groups) to avoid loading unnecessary view
& record content client-side.
This improves performance for admins without the specific application
admin rights, but also fixes the main bugfix problem,
caused by the webclient querying name_get for the records in relational
fields content.
Example:
sale_management adds a res.config.settings field to specify
the default sale.order.template for the current company.
If a 'Settings' user without 'sale.group_sale_manager' opens the
settings, he won't see this setting, but if a default template is
specified for the current company, the webclient will still request
the name_get of this template to the server, because the field
was present in the view, only hidden with a groups attribute.
With this commit change in sale, the field won't be in the view unless
you have the Sale manager group, avoiding the error/traceback/bug.
2) Remove implied application administration groups
Do not force the specific application groups on all 'Settings' user,
they globally do not need those rights, and if they need it, they
can add it to their account themselves.
3) Add a test to make sure settings user are able to manage settings.
4) Enforce 'settings' -> 'access rights' -> 'internal user' groups
As the previous test highlighted some 'false positives' because
it considered a settings user unable to read `crm.team`
and `stock.warehouse` records, we also took the opportunity to enforce
the fact that 'Settings' & 'Access rights' users must be internal users.
It makes no sense for a portal/public user to have access to the
settings, and didn't work anyway.
Part-of: odoo/odoo#91909
The goal is to remove confusion between Invoicing and Accounting.
The current setting "Show Full Accounting Features" is confusing
and leads users to believe they have a full accounting package
in community, which is not true.
closesodoo/odoo#73977
Task: 2578997
Signed-off-by: William André (wan) <wan@odoo.com>
Accrued liabilities, or accrued expenses, occur when you incur an expense that you haven’t been billed for (aka a debt).
For example, you receive a good now and pay for it later (e.g., when you receive the invoice). The same opposite approach for sales.
Why do accountants need such entries ?
- Accounting must give a fair view of the financial situation of a company. The loss/profit must be booked regarding the effective deliveries of goods/services, not on the paperwork only.
- On a fiscal point of view, if you want to be allowed to deduct a loss from your taxable basis, it has to be in the right period. If you didn't announce it on time, the loss might be rejected by fiscal authorities. Same goes for the augmentation of the taxable basis, it has to reflect real deliveries and not only paperwork.
was Task: 2555642
was PR #73707
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Users may want to be able to have transactions coming from multiple
payment acquirers to be registered in the same journal.
This will allows that.
Task id #2414749closesodoo/odoo#67331
Related: odoo/upgrade#2500
Related: odoo/enterprise#17258
Signed-off-by: William André (wan) <wan@odoo.com>
In belgian accounting, some tax lines in the tax report must be carried
over to the next period if they are negative.
If the balance for the next period is positive, it will be deduced by
the maximum possible amount that is carried over. If it is negative,
the negative balance will simply be added to the carried over balance.
This process repeats itself from one period to the other endlessly,
until the carried over balance come back to 0.
This is done by putting the carried over balance in dedicated analytic
accounts.
task id #2271978
If a user has no access to Invoicing module, he can not send and print his invoices.
To reproduce the error:
(Need sale_management,account)
1. Connect with admin account
2. Settings > Users & Companies
3. Create/Edit a salesman
- Remove access rights to Invoicing module
4. Connect with this user
5. Create & Confirm a SO
6. Edit the SO and fill in the "Delivered" field, Save
7. Click on "Create Invoice", "Create Invoice"
7. Connect with admin account
8. Invoicing > Go to the previously created invoice
9. Confirm it
10. Connect with the user account
11. Sales > previously created SO > "1 Invoices"
=> The user can read the invoice, but he can not send and print it. This is an error.
OPW-2389428
closesodoo/odoo#64508
X-original-commit: f64f7ca309f9228e58b1487a286f2302ff8f035e
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
This reverts commit 7e3e99adb4.
Usability of that new wizard was too poor. We revert it for now; it'll make a comeback eventually.
closesodoo/odoo#63436
X-original-commit: 1d75786b8b45fd4f6b08d726165b60875b62b1e7
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Task 2005940
account:
* Use stored compute methods instead of default for
{out,in}bound_payment_method_ids
* Track is_move_sent in the chatter
* Split 'Invoices' and 'Bills' in the smart button of payment form
* Because account.payment.method can be shown on the res.partner form,
we need to relax the security level to readonly for all users
account_check_printing:
* Add the preferred payment method for partners, with a related on
account move allowing to do a group by and doing payments in batch
* Add a constraint to forbid twice the same check number in the same
journal
* The amount in words is now readonly to prevent typos and mismatches
with the amount in digits
* Remove the field `check_number_int`. The check number is kept as Char
so that '000012345' is not displayed (and printed) as '12,345' but it
is parsed so that comparison and incrementation are possible.
closesodoo/odoo#56179
Related: odoo/upgrade#1669
Related: odoo/enterprise#12527
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Task 2227389
The wizards for creating Accrual Entries and Transfer Entries are quite
similar. We are merging them as they share code and business logic.
Entries in the future should not be posted for both wizards, but set to
be auto posted instead.
- Make sure to have 'Billing' access rights
- Create an invoice
- Fully paid this invoice
- Try to unreconcile the newly created payment
=> You should have the access rights to do that
closesodoo/odoo#53785
X-original-commit: 5b2f9bac2a430b77637c28f4ee54ae66789ea116
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Purpose of this task is,lots of business flows can be crashed if
the field Private Address(address_home_id) is a private address instead
of a regular contact.
so in this commit,we change the demo data for employee and set the
private type address on employee for private address and also fix
the flows on which errors could occur.
Currently billing administrator does not have right for private address
and while creating payment from expense it was going to set the
customer from the employee's private address on payment so give the
private address right to the billing adminnistrator.
Also chaned admin/demo user's private address as 'private' instead of
regular contact.
and on hr_expense use the Sudo while accessing the home address this
method is used from payslip too.
TaskID:2170016
closes odoo/odoo#46628
Closes: #46628
Related: odoo/enterprise#8924
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Partner mapping is a new field defined on invoice matching reconciliation models. It allows defining a mapping between partners and regular expressions. When ran, on a statement line without any partner set, those rules use this mapping to assign a partner to statement lines without any one set, using the regular expressions to match the payment reference of the statement line.
It is important to note that the mapped partner will only be set to the statement line when the reconciliation is actually performed (so, when clicking the validate button, if the matching rule is not auto_reconcile = True), just like with the partner_map.
Task 2201948
*These actions were either unused or only used in enterprise modules.
The first ones have been deleted, and the second ones have been move to
the corresponding enterprise modules.
* account.fiscal.year: the whole model has been moved to enterprise
closesodoo/odoo#46110
Related: odoo/enterprise#8706
Related: odoo/upgrade#1083
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The model account.setup.bank.manual.config (menu "Add a Brank
Account") was with the group account.group_account_user ("Show Full
Accounting Features").
Since 65530dfd6a, transient models have ACL and are not accessible
if the user does not belong in the group.
The account.setup.bank.manual.config model is triggered via the server
action account.action_new_bank_setting instead of a classical
menu. It's also displayed in an onboarding step of account.
Because of this, the group must be relaxed (and not just adding a
group of a view/action)
In saas-13.2, 65530dfd6a made simply the wizard appears in readonly
but in saas-13.4, since 56a8c9e431, trying to display a model on
which we do not have access produces and access rights error.
closesodoo/odoo#51330
X-original-commit: a4a2b8198d5d2d368e279929a5cdbcca0376d8ef
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Merge account_analytic_default into account
Merge account_analytic_default_hr_expense into hr
Merge account_analytic_default_purchase into purchase
Prevent having to manually install default modules after activating analytics
closesodoo/odoo#50816
Task: 2182900
Related: odoo/upgrade#1186
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
In the same xml file (meaning one of the two rule is useless, or wrong
if giving less rights than the other).
Removing rules that had no impact will ease the understanding of
security problems, by reducing the number of interconnecting rules.
ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.
Purpose:
If the user is not using receipt functionality in his organization then it's can be hidden.
Current behavior before PR:
Sale and purchase receipt by default show when the account module is instaled.
Desired behavior after PR is merged:
Now users can activate Sale or purchase receipt from accounting settings.
closesodoo/odoo#44464
Task: 2028813
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The recently added group "Show Full Accounting Features - Readonly" was
shown in the selection of groups of accounting, but the "Show Full
Accounting Feature" wasn't. It was inconsistent and allowed to see the
features too easily (not debug mode needed)
closesodoo/odoo#45419
X-original-commit: ed3adb320c6680bb213965c84b6b7fd5654c8121
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Task 2146469
Rework the name computation:
* It doesn't use ir.sequence anymore
* It is an editable computed field
* Add a renaming tool
This allows the user to tweak the sequences more easily than having to
get through the ir.sequence settings.
The sequence depends on a parameter of the journal: continuous, montly
and yearly restart of the sequence. Everytime a new period is started,
try to make a pattern form another period.
The incrementing is done by taking the previous name, ordered
lexicographically, splitting it by taking the digits at the end, adding
1 and re contstruct with the prefix.
** This means there could be cases where the prefix has a big importance
on the next number. For instance, if you have
INVOICE/2019/0001
INVOICE/2019/0002
and then rename the last one to INV/2019/0002, don't expect the next
number to be INV/2019/0003. It will be INVOICE/2019/0002 (again) because
the highest number was INVOICE/2019/0001.
You will then end up with
INVOICE/2019/0001
INV/2019/0002
INVOICE/2019/0002
closesodoo/odoo#41485
Related: odoo/enterprise#7189
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value
account*: use account.group_account_user for all transient by default
remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
additional verifications are made to ensure they are executed
only on the documents the user has access to you
give portal access to mail.compose.message as portal still does
some actions like posting messages on the forum
add ir.rule to avoid reading somebody else messages
increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
partner manager for actions linked to partners
avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
event user inherit from sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
manager can set a plan according to group on button
anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
as the source is an account.move
keep the payment.acquirer.onboarding.wizard to system user
only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation
base: base.language.*: allow employee (cf lang_install)
change.password.user: can not read change password wizard of
other users
test.*: no access is needed
Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl
Without any access rights on the 'account' module, a salesperson should be able to
create a new invoice from a sale order.
Since the merge of account.invoice with account.move, we need to manage carefully the
access rights when dealing with invoices. A salesperson must not be able to manage the
journal entries except the one being an invoice created for a sale order.
To make such restriction on the journal entry's type, we need additional record rules
- in sale: to restrict the access to invoices.
- in account: to exit such restrictions when having billing access rights.
closesodoo/odoo#44023
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The recent refactoring made at 30cf7bc798 introduces a new object for the different writeoff lines that could be created from a reconciliation model. Unfortunately, Billing users were forgotten during that refactoring which made them unable to read/use the reconciliation models anymore.
This patch grants them the Read and Create permission on the new account.reconcile.model.line object, as they already have to the reconciliation model.
closesodoo/odoo#42009
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Task 2046908
Instead of having all the fields duplicated with second_*, we have now a
o2m allowing us to
* have more than 2 lines
* reduce duplicated code
* fix bugs and add features at only one place
We also remove the computation of writeoff and suggestions from the
client side as some code was 4-upled before (twice in in client and
twice in server side). The logic is now only at one place.
closesodoo/odoo#38119
Related: odoo/enterprise#6324
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Introduce a new account.tax.report object
> Tax report lines now refer to a tax report, and the tax report to a country
- Tax report lines can share tags accross reports within the same country
> To support the cases where some report is a simplified version of another one: some of its lines can be computed in the same way as the 'bigger' report.
> This is done by giving the same tag_name to the tax report lines, and the same country_id to their parent report.
> Full support for tag name modification, and the way it impacts the shared tags (sometimes, we can overwrite them all, sometimes we must delete them, sometimes, we create new tags to replace them on some report lines).
- Support copying tax report (and the lines/tags linked to it), so that it is possible to duplicate them and change the country set on the duplicate for use in another country (coopying is way better as replacing in place, as we don't keep any link to an xmlid, and still allow using the original report in the original country it was created for).
- Make all l10n* modules compatible with those changes
closesodoo/odoo#38964
Related: odoo/enterprise#6217
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Task 2092104
Accounts group Hierarchy should be automatically well done without to
have to specify the parent (based on the account group CODE)
Before, we had to set all the accounts in the correct groups manually
and it was cumbersome.
Now:
* No need to fulfill account group parent
* No need to fulfill account group id on account
We can still change the groups if there are exceptions; the groups are
only set at create and write time.
As the group_account_invoice doesn't have the access rights to unlink the
account.partial.reconcile/account.full.reconcile, there was impossible for
the user to undo a reconciliation.
closesodoo/odoo#40934
X-original-commit: 0288adb0c315a1da63fe7e2d9b1f586ad6c9555b
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
When the only app installed is 'invoicing', people were getting an error while trying to generate the account.reconcile.model from its template. Could have done it in sudo(), truth is: account.reconcile.model object is not security critical
closesodoo/odoo#37622
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Task 2072312
* Change the label "/" by "Draft <document type>" for draft entries (change name_get() of account.move)
* New left-bar menu for a chart of account & general ledger view: Take into account the company (for multicompany, avoid having the number 7 if the current company doesn't have 7xxxa accounts)
* New filter "Accounts With Entries" for the chart of accounts
Show only account which has at least 1 journal entry on it
* Show the move_id on the move line tree view
Task 2008956
* Add the root of an account (first 2 digits/char) as a searchable model.
* Create a custom searchpanel for this account root on account.move.line
* Add the account_root searchpanel to the account.account view too.
PoMa