How do I change a salesperson's permissions so he can't modify sales prices in OpenERP - odoo

We have an OpenERP instance set up but there is some tweaking to do still.
The most important one is that our salespersons have access to modify the product's base sales price and we need to prevent this from happening.
I can see the Users section on the left and see each user. That particular user appears as:
Sales Management: Manager
Project Management: Manager
Warehouse Management: User
Accounting Finance: Accountant
Purchase Requisition: Manager
Purchase Management: Manager
Human Resources: Employee
Administration: Access Rights
Which needs to be eliminated of modified such that the salespersons are not able to modify Base Sales Prices?

Related

what is the difference between billing account and financial account in tmforum open-api account management service specs

I am just trying out the open-API specs provided by tmforum https://www.tmforum.org/open-apis/ and cannot seem to figure out the difference and actual purpose of the financial account resource mentioned in account management API specs. Can someone please elaborate?
The financial account aggregates the amounts of one or more billing accounts owned by a given party. For example, as a customer, I may have multiple billing accounts (e.g. for broadband services for multiple properties) - the financial account is the aggregation of these billing accounts.

How to convert Open invoices into Paid state in odoo9 after doing payment?

I have exported invoice data from odoo7 and imported into odoo9.
When I go for register payment for those imported data of Open invoices, payment for those invoices can be done successfully but invoices state still remain same(i.e.Open) instead of Paid state.
I have already checked all configuration like checked on Allow Reconciliation in account, set income account etc. All configuration are proper as per requirement.
Can any one help me regarding it?

enable visual totals in SSAS multidimensional not giving desired output

We have implemented row level security in our SSAS database. In our business case we have property level security and account level security. In property level security user should be able to see data for only those properties which are assigned to him, and in Account Level security a user should be able to see data of only those accounts for which he is authorized to access.
After security implementation we noticed a problem due account level security implementation, users were not able to see correct totals for those hierarchies which were having some accounts which were not accessible to the user due to security restriction. e.g. if a user is head of purchase department he is having access to sales accounts only, but when he browse cube for net profit he is seeing wrong net profit, as the net profit only calculates based on sales department accounts.
I want to know for the possible solution to sort out this issue.

Need to delay credits after a debit in Balanced Payments

Background: The website is designed for property managers and tenants to do the following -
1. Property Manager registers for the site
2. Property Manager creates their Tenant users
3. Property Manager and Tenant verify their own bank accounts using Balanced Payments from our site
4. Once verified, the Tenant logs in, enters an amount to pay to the Property Manager and submits payment
5. Amount entered by Tenant is debited from their account using ACH and placed in Marketplace
6. Marketplace automatically credits rent amount to Property Manager (minus a $7.50 transaction fee).
The problem I have is when the Tenant pays, the debit is created in the log, but the credit has a 409 error "insufficient marketplace funds"; does anyone know how to remedy this error? Should I/Can I put a delay on the issuing of the credit until the debit is actually received in the Marketplace? I have several screenshots if it would help..
Thank you in advance for the assistance,
Jake
Founder, RentEater.com
You're using ACH, or bank account, debits here. Due to the asynchronous nature of the ACH network, these debits don't succeed immediately, like credit card debits do. They are batch-settled once per day, and take around 3 business days to succeed. This page has some more information on this process:
https://www.balancedpayments.com/ach-debits
One way to work around this is to keep a reserve of funds in your marketplace's escrow account, so that you can pay out credits immediately after creating a debit. The credit will come from this reserve, which will be replenished when the debit succeeds.

Do I have to create an Account, Merchant Account, or just a customer to Credit a Balanced Bank Account?

Balanced payments documentation is unclear about debits and credits. You have merchants, customers and accounts. It now says accounts are deprecated and to use customer. Can someone shed light on any corrections I have in my workflow:
Form with CC fields tokenizes card.
Create customer for buyer and add card.
Debit buyers card.
Create another Customer object.
Add a bank account to the Second customer object.
Credit Second Customer object
Do I need the merchant fields on the second customer object (dob, postal code, etc)?
Do I need to do underwriting to second customer object?
Your workflow is correct.
The Customer resource abstracts away from you the pain the Account resource had when dealing with underwriting a merchant. Underwriting is required as part of the KYC (Know Your Customer) operation requirements Balanced needs to follow. Each Customer has an attribute named is_identity_verified where you can know if the Customer's identity was verified. Ideally you want to make sure the identity is verified for each Customer to which you will be crediting. While you can still perform credits (I believe up to a certain limit) to Customers whose identity is not verified, you run the risk of increased fraud and there may eventually be consequences to your marketplace.
Also, feel free to stop by #balanced on IRC. You'll probably get much faster answers to your questions there directly from developers.