i need this functionality only to manage warehouse restrictions, why there is in dependencies also account_operating_unit, why not use only operating_unit?

I was looking at security in relation to #104 and I think I have found a major mistake in the way this has been constructed.

If you take any record rule file you will notice an entry not unlike

    <record id="ir_rule_invoice_allowed_operating_units" model="ir.rule">
        <field name="model_id" ref="account.model_account_invoice"/>
        <field name="domain_force">['|', ('operating_unit_id','=',False), ('operating_unit_id','in',[g.id for g in user.operating_unit_ids])]</field>
        <field name="name">Invoices from allowed operating units</field>
        <field name="global" eval="True"/>
        <field eval="0" name="perm_unlink"/>
        <field eval="0" name="perm_write"/>
        <field eval="1" name="perm_read"/>
        <field eval="0" name="perm_create"/>
    </record>

Now ir.rule is kind of the opposite of assigning permissions. In other words, perm_read = 1 translates as - when a user tries to read an invoice, disallow it. So in this case you are effectively saying a User who is not part of an operating unit cannot read it, but can write to it, delete it and create it.

This is a bad example, as actually it might be desirable for users not to be able read another users invoices, but I think this code just end up copy pasted everywhere, with people thinking it gave read access. Or maybe its by design?

@jbeficent Looks like I'm gonna join this effort and drop https://github.com/odoo/odoo/pull/19839/files

I might do kind of a intense sprint during the next few days while ensuring existing features of my solution and hope I can give some serious amount of valuable input. Hope stars are aligned and things can be merged quickly...

I'll be working on v12. Please ping the people who should take not of this and otherwise close, once acknowledged.

Anything I should know / take into account?

Best Regards,
David

Dependencies: operating_unit, project
License: AGPL

This module adds operating unit information to projects and tasks.

Usage

• Go to Project
• You only see the projects and tasks of your operating units
• Create a new project. It is assigned to your default operating unit.
• Create a task within a project. It inherits the operating unit of the project

Technical Specifications

project.project

• Add a many2one field "Operating Unit" (operating_unit_id) to operating.unit
• Set the default value to the OU of the connected user
• Add the global record rules to separate fsm orders by OU. If a fsm order is not assigned to a OU, it is visible by all OU.

project.task

• Add a related many2one field "Operating Unit" (operating_unit_id) to project_id.operating_unit_id.
• Add the global record rules to separate tasks by OU. If a task is not assigned to a OU, it is visible by all OU.

Should we auto set the OU on Account move from current user's OU same as what we have on the account invoice ?

For ex. in this case bank stmts will generate account moves with OU set on it instead of empty OU .

Create receipts (stock picking) directly (not from PO) will show error

Open Inventory Dashboard then create new transfer from receipts

Will show error

Testing using this runbot https://runbot.odoo-community.org/runbot/213/10.0

Install DDMRP
Error while validating constraint
Configuration error
The Stock moves must be related to a location (source or destination) that belongs to the requesting Operating Unit.

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-13.0

Modules to migrate

• account_operating_unit - By @alan196 #229
• analytic_operating_unit - By @alan196 #228
• crm_operating_unit - By @alan196 - PR #250
• hr_contract_operating_unit
• hr_expense_operating_unit - By @alan196 - #251
• mrp_operating_unit - By @BT-nstuder - #243
• operating_unit - By @alan196 #223
• purchase_operating_unit - By @BT-nstuder - #232
• report_qweb_operating_unit - By @alan196 - #255
• sales_team_operating_unit - By @alan196 #224
• stock_account_operating_unit - By @alan196 - #254
• stock_operating_unit - By @BT-nstuder - #231
• sale_operating_unit - By @alan196 - #252
• sale_stock_operating_unit - By @alan196 - #253

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

I'm trying to migrate this module. Apparently the migration is direct from 10.0 with few changes.

Is it necessary for all locations to have an operational unit? It seems that if they do not have any unit configured gives read permission error.

(Document type: stock.picking.type, Operation: read)

The locations without operating unit should not be seen by the whole company? If not, how would these be configured?

Hi,
Error keeps croping up while installing Accounting with Operating Units;

"
Traceback (most recent call last):
File "/odoo/odoo-server/odoo/http.py", line 640, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/odoo/odoo-server/odoo/http.py", line 677, in dispatch
result = self._call_function(**self.params)
File "/odoo/odoo-server/odoo/http.py", line 333, in _call_function
return checked_call(self.db, *args, **kwargs)
File "/odoo/odoo-server/odoo/service/model.py", line 101, in wrapper
return f(dbname, *args, **kwargs)
File "/odoo/odoo-server/odoo/http.py", line 326, in checked_call
result = self.endpoint(*a, **kw)
File "/odoo/odoo-server/odoo/http.py", line 935, in call
return self.method(*args, **kw)
File "/odoo/odoo-server/odoo/http.py", line 506, in response_wrap
response = f(*args, **kw)
File "/odoo/odoo-server/addons/web/controllers/main.py", line 889, in call_button
action = self._call_kw(model, method, args, {})
File "/odoo/odoo-server/addons/web/controllers/main.py", line 877, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/odoo/odoo-server/odoo/api.py", line 689, in call_kw
return call_kw_multi(method, model, args, kwargs)
File "/odoo/odoo-server/odoo/api.py", line 680, in call_kw_multi
result = method(recs, *args, **kwargs)
File "/odoo/odoo-server/addons/base/module/module.py", line 410, in button_immediate_install
return self._button_immediate_function(type(self).button_install)
File "/odoo/odoo-server/addons/base/module/module.py", line 484, in _button_immediate_function
modules.registry.Registry.new(self._cr.dbname, update_module=True)
File "/odoo/odoo-server/odoo/modules/registry.py", line 82, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/odoo/odoo-server/odoo/modules/loading.py", line 339, in load_modules
loaded_modules, update_module)
File "/odoo/odoo-server/odoo/modules/loading.py", line 237, in load_marked_modules
loaded, processed = load_module_graph(cr, graph, progressdict, report=report, skip_modules=loaded_modules, perform_checks=perform_checks)
File "/odoo/odoo-server/odoo/modules/loading.py", line 156, in load_module_graph
_load_data(cr, module_name, idref, mode, kind='data')
File "/odoo/odoo-server/odoo/modules/loading.py", line 95, in _load_data
tools.convert_file(cr, module_name, filename, idref, mode, noupdate, kind, report)
File "/odoo/odoo-server/odoo/tools/convert.py", line 845, in convert_file
convert_xml_import(cr, module, fp, idref, mode, noupdate, report)
File "/odoo/odoo-server/odoo/tools/convert.py", line 915, in convert_xml_import
obj.parse(doc.getroot(), mode=mode)
File "/odoo/odoo-server/odoo/tools/convert.py", line 799, in parse
self._tags[rec.tag](rec, de, mode=mode)
File "/odoo/odoo-server/odoo/tools/convert.py", line 707, in _tag_record
id = self.env(context=rec_context)['ir.model.data']._update(rec_model, self.module, res, rec_id or False, not self.isnoupdate(data_node), noupdate=self.isnoupdate(data_node), mode=self.mode)
File "/odoo/odoo-server/addons/base/ir/ir_model.py", line 1229, in _update
record = record.create(values)
File "/odoo/odoo-server/addons/base/ir/ir_ui_view.py", line 362, in create
return super(View, self).create(self._compute_defaults(values))
File "/odoo/odoo-server/odoo/models.py", line 3828, in create
self._fields[key].determine_inverse(record)
File "/odoo/odoo-server/odoo/fields.py", line 1041, in determine_inverse
getattr(records, self.inverse)()
File "/odoo/odoo-server/addons/base/ir/ir_ui_view.py", line 220, in _inverse_arch
view.write(data)
File "/odoo/odoo-server/addons/base/ir/ir_ui_view.py", line 380, in write
return super(View, self).write(self._compute_defaults(vals))
File "/odoo/odoo-server/odoo/models.py", line 3554, in write
self._write(old_vals)
File "/odoo/odoo-server/odoo/models.py", line 3705, in _write
self._validate_fields(vals)
File "/odoo/odoo-server/odoo/models.py", line 1077, in validate_fields
raise ValidationError("%s\n\n%s" % (("Error while validating constraint"), tools.ustr(e)))
ParseError: "Error while validating constraint

Field bank_reference does not exist

Error context:
View account.payment.form
[view_id: 1280, xml_id: n/a, model: account.payment, parent_id: 537]
None" while parsing /odoo/odoo-server/addons/account_operating_unit/views/account_payment_view.xml:47, near

account.payment.form
account.payment

"

Running;
Odoo 10 Community Edition
Multiple Company
Error shows during installation of Freight Management and/or Accounting with Operating Units.
Hosted on Ubuntu 16

Regards

@OCA GitHub reviews labels, such as "Needs Review" are missing.

@aheficent Hello Aaron!! Request Operating Unit in the stock picking does not seems to work, the OU is initially set on the picking_type onchange but when you then try to save the picking it disappears. Is this behavior normal?

Below I have attached two screenshots before and after saving the record.

While performing an inventory adjustment, operating unit is not set properly in journal entries. User's default operating unit is being used as OU in journal entry. Can be resolved by taking the OU if present in Stock Location.

Hi,
Is there any development/intention related for OU in POS? I could not find any in this repo but maybe some other repos might be looked into?

If not we might plan to use OU in one of our project and would need OU in POS. AFAICS, we would need to add the field/ACL in the following objects:

• pos.session
• pos.order

I am wondering about the payment methods and POS Product Categories.
Besides we will need to be careful with:

• the journals set up
• potential conflicts with accounting OU?

Any other idea/feedback?

Do you have a plan to migrate account_operating_unit module to odoo v12?

The lambda function of the default param in operating unit models exceds 79 columns (80 specifically). I see in the other modules that it is not corrected. Is it correct to omit that error?

Dear All,
I've tried to create a manual consume stock movement; by evaluating the picking type a short dump occurred (the related log is reported below). I've noticed also this doesn't occur by removing the app stock operating unit.
thanks in advance
claudio candito
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/odoo/http.py", line 638, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/usr/lib/python2.7/dist-packages/odoo/http.py", line 675, in dispatch
result = self._call_function(**self.params)
File "/usr/lib/python2.7/dist-packages/odoo/http.py", line 331, in _call_function
return checked_call(self.db, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/odoo/service/model.py", line 101, in wrapper
return f(dbname, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/odoo/http.py", line 324, in checked_call
result = self.endpoint(*a, **kw)
File "/usr/lib/python2.7/dist-packages/odoo/http.py", line 933, in call
return self.method(*args, **kw)
File "/usr/lib/python2.7/dist-packages/odoo/http.py", line 504, in response_wrap
response = f(*args, **kw)
File "/usr/lib/python2.7/dist-packages/odoo/addons/web/controllers/main.py", line 885, in call_kw
return self._call_kw(model, method, args, kwargs)
File "/usr/lib/python2.7/dist-packages/odoo/addons/web/controllers/main.py", line 877, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/usr/lib/python2.7/dist-packages/odoo/api.py", line 681, in call_kw
return call_kw_multi(method, model, args, kwargs)
File "/usr/lib/python2.7/dist-packages/odoo/api.py", line 672, in call_kw_multi
result = method(recs, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/odoo/models.py", line 5494, in onchange
record._onchange_eval(name, field_onchange[name], result)
File "/usr/lib/python2.7/dist-packages/odoo/models.py", line 5392, in _onchange_eval
method_res = method(self)
File "/usr/lib/python2.7/dist-packages/odoo/addons/stock_operating_unit/model/stock.py", line 126, in onchange_picking_type
res['value']['operating_unit_id'] = unit.id
TypeError: 'NoneType' object has no attribute 'getitem'

Dependencies: sale_operating_unit, product_operating_unit, res_partner_operating_unit
License: AGPL-3

This module allows a user in an operating unit to request internal quote to another operating unit.

Usage

• Go to Sales
• Create a quotation for one of your OU customer
• Enter lines using products from your OU catalog
• Go to the "Internal Quotes" tab and enter the list of products and quantity that you need to quote from the other OU
• Send the internal quote

As a user in the other OUs

• Go to CRM
• A new lead has been created for the internal customer
• The description contains the delivery address and the list of products and quantity to quote
• Create a sale order from the lead, add your products, quantity and price
• Send the quote to the internal customer

Technical Specifications

res.company

• Add a text field "Lead Description Template" (crm_lead_template) with a default value

{%% partner_shipping_id %%}
{% for line in line_ids %}
{%% line.name: line.qty line.uom_id.name %%}
{% endfor %}

sale.order.quote.line

• Add the object
• Add a required char field "Description" (name)
• Add a many2one field "Internal Quote" (quote_id) to sale.order.quote
• Add a many2one field "Product" (product_id) to product.product. Filter the list of product with the one that belongs to the selected operating unit.
• Add a float field "Quantity" (qty)
• Add a many2one field "Unit of Measure" (uom_id) to uom.uom. Only show the field to the uom group.
• Add a float field "Unit Price" (price_unit)
• Add a float field "Subtotal" (subtotal)
• Add an onchange on the product to set the name and uom_id like on the sale order line

sale.order.quote

• Add the object
• Add an invisible char field "Name" (name)
• Add a required many2one field "Operating Unit" (operating_unit_id) to operating.unit
• Add a many2one field "Sale" (sale_id) to sale.order
• Add an onchange method on the Operating Unit and Sale to set the name as "Name of the Sale - Name of the OU" like "SO0032 - NOC"
• Add a readonly many2one field "Lead" (lead_id) to crm.lead. The field is invisible if not set.
• Add a one2many field "Products" (line_ids) to sale.order.quote.line using quote_id
• Add a selection field "State" (state) with New, Sent, Received and a clickable statusbar. When clicking on "Send", a CRM lead is created (if not already done) for the selected OU with the mapping provided in the solution section above.
• Use the Lead Description Template of the company to generate the lead description
• Add a constraint to have a unique quote per sale and per operating unit

sale.order

• Add a one2many field "Internal Quotes" (quote_ids) to sale.order.quote using sale_id
• Add a tab "Internal Quotes" with the request_ids field

Why is the operating unit on account journal visible only on bank and cash journals?

Would there be any drawbacks to show it on all journals?

I have a configuration error in quotation confirmation. I set the Product in Make To Order and raise the quote and I set the OU warehouse in Quote, then I confirm the quote "Configuration error. The Quotation / Purchase Order and the Warehouse of picking type must belong to the same Operating Unit." this error will come. Anyone can know the solution please suggest.

Dear All,
When conforming a quotation for creating a purchase order a following error has occurred:
Error while validating constraint
Configuration error
The Stock moves must be related to a location (source or destination) that belongs to the requesting Operating Unit.

this sounds strange because for the time being only the default main OU has been set and the input location has been assigned to it.
Regards
claudio candito

This issue summarizes the development of the migration to v9 of priority 1 modules.

• operating_unit
• procurement_operating_unit - https://github.com/Eficent/operating-unit/tree/9.0-procurement_operating_unit. Pending PR to OCA.
• purchase_operating_unit - WIP https://github.com/Eficent/operating-unit/tree/9.0-purchase_operating_unit. Pending PR to OCA.
• account_operating_unit
• account_voucher_operating_unit - WIP https://github.com/Eficent/operating-unit/tree/8.0-account_voucher_operating_unit. Assigned to @aheficent
• stock_operating_unit - WIP https://github.com/Eficent/operating-unit/tree/9.0-stock_operating_unit
• stock_account_operating_unit - WIP https://github.com/Eficent/operating-unit/tree/9.0-stock_account_operating_unit
• sale_operating_unit - Branch in v8: https://github.com/Eficent/operating-unit/tree/8.0-sale_operating_unit. Assigned to @aheficent
• sale_stock_operating_unit - Branch in v8: https://github.com/Eficent/operating-unit/tree/8.0-sale_stock_operating_unit. Assigned to @aheficent
• crm_operating_unit - Branch in v8: https://github.com/Eficent/operating-unit/tree/8.0-crm_operating_unit. Assigned to @darshan-serpent
• sale_crm_operating_unit . Assigned to @darshan-serpent

Trying to migrate account_operating_unit from 10.0 it seems that view_move_line_form2 does not exist, view_move_line_form yes:

  File "/home/odoo/odoo11/odoo/addons/base/ir/ir_model.py", line 1312, in xmlid_lookup
    raise ValueError('External ID not found in the system: %s' % xmlid)
odoo.tools.convert.ParseError: "External ID not found in the system: account.view_move_line_form2" while parsing /home/odoo/odoo11/devel/operating-unit/account_operating_unit/views/account_move_view.xml:17, near
<record id="view_move_line_form2" model="ir.ui.view">
        <field name="name">account.move.line.form2</field>
        <field name="model">account.move.line</field>
        <field name="inherit_id" ref="account.view_move_line_form2"/>
        <field name="arch" type="xml">
            <xpath expr="//field[@name='account_id']" position="after">
                <field name="operating_unit_id" options="{'no_create': True}" groups="operating_unit.group_multi_operating_unit"/>
            </xpath>
        </field>
    </record>

Could be removed in 11.0?

Can we have a feature for capturing sale / cost price at operating unit level. Or in general can we have an operating unit dependent field similar to company dependent field?

Dear All,

I have installed OU in Odoo 10 and I have created a user and granted him access to Sales User:All Documents group and assigned one OU to him then I created a Quotation and I didn't see any OU field in quotation and after creation,I checked the quotation from Admin account, I was able to see the OU field in the form and tree view but it was empty.
I think the OU field should be visible and filled with default OU of the user and a user should able to select the OU if he has access to more than one OU.

After that, I have selected the checkbox of "Multi Operating Unit" and I was able to see the OU field but the default OU is not selected by default during the creation and the quotation created with empty OU. Is the normal and this quotation under which OU will be?

Please advise.

When you have several companies, the default organizational unit for a user is always the default of the first company created in all companies. I do not know if it is intentional but it seems a bug.

Following up this comment: #94 (comment)

I was able to reproduce it on runbot: http://3323845-11-0-eca13e.runbot2.odoo-community.org/web?debug=#menu_id=75&action=86&active_id=channel_inbox

The problem is when the non-admin user creates a OU it is not assigned to the OU recently created so the access error appears. Not sure how to solve this. Maybe assign the user to the OU recently created?

I would like to propose adding the OUs as a dropdown as the multi-companies or within the multi-companies below the company associated with the OU.

This functionality had been thought?

Does anyone have that need or see it as useful?

Dependencies: operating_unit, agreement_serviceprofile
License: AGPL

This module adds operating unit information to agreements and service profiles.

Usage

• Go to Agreements
• You only see the agreements of your operating units
• Create an agreement. It is assigned to your default operating unit.

Technical Specifications

agreement

• Add a many2one field "Operating Unit" (operating_unit_id) to operating.unit
• Set the default value to the OU of the connected user
• Add the global record rules to separate agreements by OU. If an agreement is not assigned to a OU, it is visible by all OU.

agreement.serviceprofile

• Add a related many2one field "Operating Unit" (operating_unit_id) to agreement_id.operating_unit_id.
• Set the default value to the OU of the connected user
• Add the global record rules to separate service profiles by OU. If a service profile is not assigned to a OU, it is visible by all OU.

Continuation from sidetrack at #94

@jbeficent I've spent a good chunk of the weekend reviewing current practice, rewriting code and matching it to the requirements under IFRS 8 for segment reporting. IFRS 8 is quite nice in that it focuses on the internal information used by management, so in that sense we can make operating_unit IFRS compliant (although then I would use the term operating_segment). I think the main difference between where this repo currently stands and IFRS 8 is the focus on the CODM under IFRS.

So we have issues to cover like an operating segment must generate revenues etc etc but the actual accounting requirement for operating segments is not full IFRS compliance. Indeed at its most basic it is arguable that a P&L only is sufficient if that is the information used for decisions, but even then in a shared resource environment (bank accounts, warehouses, inter OU trade) we have an allocation issue.

The light bulb moment was realising we have this same issue in a multicompany environment, and companies have long had to deal with this issue. So if we summarise the primary issue in multicompany consolidated reporting it is fundamentally one of eliminating any transactions which have not left the combined entity, and if we treat operating_segments the same we can acheive this outcome without the needs for the restrictions on bank and cash journals or warehouses.

• An operating segment is responsible for a warehouse as its primary user.
• Beyond COGS we need to consider depreciation, direct labour, freight, etc etc all attributable the operating segment responsible for that warehouse.
• The way we do that in a multicompany environment is of course transfer pricing to cover those costs, and we can apply the same to operating segments (specifically mentioned in IFRS 8 as allowable)

So here is how the journals would look for an MTO sale under anglosaxon where S1 is the stocking segment and S2 is the selling segment, with a self balancing balance sheet. The goods sold cost $100, and are sold for $200
Apoligies for the messy journals, markdown didn;t make this easy.

On delivery

To record delivery of goods with a cost of $100 on behalf of S2

On invoice

To record invoice of goods by S2

Now at this point life goes on as normal. Payments etc. On a periodic basis there may be transaction that looks something like (either cash or an inter ou subvention account). Obviously this would be aggregate but you get the idea

To record settlement of inter OU balances at end of period

Now of course this is a fairly complex example with the inclusion of xfer pricing, but the principle remains the same. In this case the transaction behaves like a dropship from S1 to S2's customer, but the entries are fairly similar regardless of whether it goes into S2's stock or direct to customer.

What do you think? I think that gets us a self balancing balance sheet without the restrictions on operating units only supplying out of their own warehouses.

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-12.0

Modules to migrate

• account_operating_unit - By @bjeficent - #149
• analytic_operating_unit - By @sudhir-erpharbor - #146
• crm_operating_unit - By @ageficent - #160
• hr_contract_operating_unit - By @ageficent - #161
• hr_expense_operating_unit - By @bjeficent - #184
• operating_unit - By @ageficent - in #144
• res_partner_operating_unit - By @Dangar-Serpentcs - in #220
• sales_team_operating_unit - By @bjeficent - in #145 By @bjeficent - #147
• sale_operating_unit - By @bjeficent - in #151
• stock_operating_unit - By @bjeficent - in #150
• purchase_operating_unit - By @bjeficent - in #152

Hi;

When i attach a user to his own UO and i connect with hiw account to make a quotation i got this error :

Odoo Warning - Access Error
The requested operation cannot be completed due to security restrictions. Please contact your system administrator.

(Document type: crm.team, Operation: read)

We previously tried to make the default_operating_unit_id a company dependant field but upon further testing it was discovered that this feature created issues. For more details see the PR where we roll back this change here: #247. The requirement that we have not satisfied yet is for users who may belong to one OU in Company 1 and another in Company 2. Currently, the default_operating_unit_id stays the same for users regardless of which company they are logged in under.

After installing and configuring this module, the contacts list is pretty slow (~45 sec with 115 k records).

From Odoo's support comment below, a record rule on a many2many field is not good a idea:

Many2many fields security rules on big tables are indeed sub-optimal compared to a subselect or join done in SQL directly. This is unfortunate for your case, but this is the expected behaviour of Odoo at this time. Improving this is something we keep in mind for the future, but using joins or more efficient subqueries comes with its own problems, and at the moment we have no real incentive to make this a priority - security rules based on m2m fields are not present in standard modules for a reason; the same way that searching on big tables by followers or by tags could be rather lengthy. It's not really a problem when it's a search - for security rules, since it's added to every query, the impact is indeed more important.

Any idea or suggestion? I want to make sure we are not forgetting a good solution.

Thanks

When we install this add on, odoo stops generating automatic accounting entries while purchase and sale of products, even when inventory valuation is selected to Automatic in product category in odoo 11.

Dependencies: operating_unit, fieldservice
License: AGPL

This module adds operating unit information to Field Service orders.

Usage

• Go to Field Service
• You only see the FSM orders of your operating units
• Create an order. It is assigned to your default operating unit.

Technical Specifications

fsm.order

• Add a many2one field "Operating Unit" (operating_unit_id) to operating.unit
• Set the default value to the OU of the connected user
• Add the global record rules to separate fsm orders by OU. If a fsm order is not assigned to a OU, it is visible by all OU.

I am trying to migrate the purchase_operating_unit module. This module depends on procurement_operating_unit, an this depends on the procurement module, which no longer exists in v11, but is integrated into inventory. Is this correct?

If it no longer exists, would procurement_operating_unit be removed and the permissions integrated into inventory?

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-10.0

Modules to migrate

• account_operating_unit
• crm_operating_unit
• operating_unit
• mis_builder_operating_unit #67
• stock_operating_unit #51
• sales_team_operating_unit #47
• account_voucher_operating_unit #46

PO/SO/Invoice lines link the operating unit to parent document's OU.

If I prepare PRs to allow selecting OU at line level, would be accepted?
Default behavior would be preserved, as document's OU will be applied by default to every line, but user will be able to select a different one if needed...

Regards,
-Mario

@jbeficent In account_operating_unit there is a section of code around line 106 of account_move.py that does not seem to match the comment

            # If all move lines point to the same operating unit, there's no
            # need to create a balancing move line
            ou_list_ids = [line.operating_unit_id and
                           line.operating_unit_id.id for line in
                           move.line_ids if line.operating_unit_id]
            if len(ou_list_ids) <= 1:
                continue

To my mind this statement is wrong in 2 ways.

1. If there was more than one line with the same ou, it would fail the test despite all pointing to the same ou.
2. If one line doesn't have an ou (is this possible?) and one does, it would pass the test despite not all lines pointing to the same ou.

Sorry its a bit hard for me as I'm doing static code review on v11 ports. Once it runs I might be able to work out myself, but which is correct, the comment or the code?

This issue summarizes the development of the migration to v9.

Priorities:
P1 - Urgent
P2 - Not urgent

[x] operating_unit
[ ] procurement_operating_unit (P1)
[ ] purchase_operating_unit (P1)
[ ] account_operating_unit (P1)
[ ] account_voucher_operating_unit (P1)
[ ] stock_operating_unit (P1)
[ ] stock_account_operating_unit (P1)
[ ] sale_operating_unit (P1)
[ ] sale_stock_operating_unit (P1)
[ ] crm_operating_unit (P1)
[ ] sale_crm_operating_unit (P1)
[ ] purchase_requisition_operating_unit (P2)
[ ] account_entries_report_operating_unit (P2)
[ ] hr_expense_operating_unit (P2)
[ ] mis_builder_operating_unit (P2)
[ ] mrp_operating_unit (P2)
[ ] purchase_request_operating_unit (P2)
[ ] purchase_request_procurement_operating_unit (P2)
[ ] purchase_request_to_requisition_operating_unit (P2)
[ ] purchase_request_to_rfq_operating_unit (P2)
[ ] hr_payroll_account_operating_unit (P2)
[ ] hr_contract_account_operating_unit (P2)

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-11.0

Modules to migrate

• account_operating_unit - By @grindtildeath - #140
• account_voucher_operating_unit
• analytic_operating_unit - By @gdgellatly - #101
• crm_operating_unit
• operating_unit - By @gdgellatly - #99
• procurement_operating_unit
• purchase_operating_unit
• sale_operating_unit - BY @bjeficent - #163
• sale_stock_operating_unit
• sales_team_operating_unit - By @gdgellatly - #100
• stock_operating_unit - By @meigallodixital - #132

Problem:
We have workflows that have multiple OU's sharing the same warehouse but currently that functionality is not supported in OCA/operating-unit

Solution:
Instead of converting operating_unit_id from Many2one to Many2many, we can make the option to allow all OU's to use a warehouse if the OU on the warehouse is not set. When we handle error checking, just add the criteria 'if warehouse_id.operating_unit_id'. This way, if the OU is not set on the warehouse, none of the ValidationErrors will be raised.

So when we pull up a product template, odoo calls the function _get_default_category_id(). In this method it checks to see if there is a category in the context, if not then it references the "All" Category that comes in the product module. Only if that is not found does Odoo search the remaining product categories.

Reference: https://github.com/odoo/odoo/blob/bf7d76a7127521ba17f29bc470c3d551cc9988d5/addons/product/models/product_template.py#L23

The issue here is if someone assigns the "All" Product Category an Operating Unit, then anyone trying to create a product outside of that OU will get an access rights error because Odoo will always set "All" as the default Product Category.

I make migration of operating_unit module in PR #223

Originally posted by @alan196 in #200 (comment)

Issue reported on the Merged PR: #223 (comment)

I have create 1 user for default OU "Main Operating Unit"

and create journal customer invoice for OU "B2B" and customer invoices2 for OU "Main Operating Unit"

I create customer invoice from sale order, the system show error "The OU in the Move and in Journal must be the same."

I think when create invoice the system pull journal customer invoice (B2B) and OU Main Operating Unit which OU not match

Can someone help for this ?

• purchase_requisition_operating_unit (P2) - Branch in v8: https://github.com/Eficent/operating-unit/tree/8.0-purchase_requisition_operating_unit. Assigned to @darshan-serpent
• mis_builder_operating_unit (P2) - WIP https://github.com/Eficent/operating-unit/tree/9.0-mis_builder_operating_unit. Assigned to @darshan-serpent => PR #38
• mrp_operating_unit (P2). Assigned to @darshan-serpent => PR #39
• purchase_request_operating_unit (P2) - Branch in v8: https://github.com/Eficent/operating-unit/tree/8.0-purchase_request_operating_unit. Assigned to @darshan-serpent
• purchase_request_procurement_operating_unit (P2) - Branch in v7: https://github.com/Eficent/odoo-operating-unit. Assigned to @darshan-serpent
• purchase_request_to_requisition_operating_unit (P2) - Branch in v7: https://github.com/Eficent/odoo-operating-unit. Assigned to @darshan-serpent
• purchase_request_to_rfq_operating_unit (P2) - Branch in v7: https://github.com/Eficent/odoo-operating-unit. Assigned to @darshan-serpent
• hr_payroll_account_operating_unit (P2) - Branch in v7: https://github.com/Eficent/odoo-operating-unit. => PR #25
• hr_contract_account_operating_unit (P2) - Branch in v7: https://github.com/Eficent/odoo-. Assigned to @darshan-serpent
• hr_expense_operating_unit (P2) - Branch in v8: https://github.com/Eficent/operating-unit/tree/8.0-hr_expense_operating_unit. Assigned to @darshan-serpent => PR #30
• crm_claim_operating_unit (P2) - Branch in v7: https://github.com/Eficent/odoo-operating-unit. Assigned to @darshan-serpent => PR #27
• account_budget_operating_unit (P2) - Branch in v8: https://github.com/Eficent/operating-unit/tree/8.0-account_budget_operating_unit. Assigned to @darshan-serpent => PR #37

How to reproducte:

• create an invoice with operating unit
• validate the invoice
• the operating unit field is still modifiable

Expected behaviour:

• the operating unit should not be modifiable on a validated invoice

The same rule as other invoice fields must apply

I would like to refer to the following line:
https://github.com/OCA/operating-unit/blob/12.0/stock_account_operating_unit/model/stock_move.py#L56

saying that:

Generate accounting moves if the product being moved is subject to real_time valuation tracking

Well, this is exactly not the case. The module throws an technical error as soon as you try to move more than 1 product (for instance in an internal transfer from one location to another)

On runbot you can reproduce the error / bug:
Create a product and assign it to a category that's Inventory Valuation is set to "real time". (On runbot it's set to "manual" as default, that's why it's working first).

But as soon as you switch the product category to "real time", you can only move one single product. If you try to move more than 1, following error is thrown:

File "/path/stock_account_operating_unit/model/stock_move.py", line 87, in _action_done 'stock_move_id': self.id, File "/path/odoo/fields.py", line 2888, in __get__ raise ValueError("Expected singleton: %s" % record) ValueError: Expected singleton: stock.move(113, 114)

@AaronHForgeFlow