Comments (8)
btw those journals are just one approach, the could just as easily be
On delivery
Account | DR | CR | Segment |
---|---|---|---|
Inventory | 100 | S1 | |
Xfer Margin (P & L account) | 10 | S1 | |
Inter OU Debtors (or balancing) | 110 | S1 | |
Stock Output | 110 | S2 | |
Inter OU Debtors (or balancing) | 110 | S2 |
To record delivery of goods with a cost of $100 on behalf of S2
On invoice
Account | DR | CR | Segment |
---|---|---|---|
Stock Output | 110 | S2 | |
COGS | 110 | S2 | |
Sales | 200 | S2 | |
Debtors | 200 | S2 |
To record invoice of goods by S2
Which is cleaner from a transaction perspective, but more difficult from elimination. It also introduces an issue in relation to costing.
from operating-unit.
from operating-unit.
Hi Jordi,
Just an FYI I'm mocking up a final version of the above, and trying to keep it all compatible, but in doing so have found that the entire Odoo 11 stock valuation is essentially broken, so awaiting on bug fixes as how they fix it will change the code a lot.
from operating-unit.
from operating-unit.
Jordi,
Check this bug report, they are fixing a lot of valuation things right now so its a good chance to get those requests in, but oh my reading some of the changes there have been some big oversights.
from operating-unit.
@jbeficent Below is the document I sent into senior management with the final approach that got signed off. As you can see, it is possible to do, without the warehouse restrictions and this is the way I am going. In essence we have 2 self balancing accounts rather than one. One is on the P&L, the other is a Payable in current liabilities (I chose payable because otherwise if a KPI was on ROA or ROE for an operating unit they could in theory massage the number if it was a receivable).
---Begin mail
I spoke briefly about these during the meeting, and the deeper I get, the answer to more and more problems they are. But they are really hard work to get just right.
For the most part our segments will be geographic, with a Head Office segment as well to handle recharges, rebates, royalties etc.
Using operating units we can for example have Christchurch only see Christchurch customers, only Head Office and Waikato see Waikato's centrally billed customers. Same goes for things like delivery orders, possibly even production lots etc.
By going geographic we can assign ownership of a warehouse to an operating unit. and in any case our segments are geographic.
But this gave me a problem, and in trying to resolve it, I think I've come up with an elegant solution to both it and another problem. The 2 problems relate to what happens when one Operating Unit, sells goods 'belonging' to another operational unit i.e. out of their warehouse. For this example I use Wellington and Central.
Wellington sells $100/$200 of goods (cost/sale) out of Centrals warehouse. So centrals stock reduces by $100, but the corresponding sale goes on Wellingtons P&L.
At first I thought this was a selfmade problem, but when I looked deeper it revealed a second problem. Not only is Wellington not paying for the goods, but their P&L is also not reflecting all the other P&L expenses they take advantage of at Central (e.g. Factory Labour, Depreciation, Freight etc).
So in order to resolve this in a Balance Sheet and P&L neutral way (not to mention stock costing), I thought about emulating the way we handle current intercompany and apply a transfer price, while keeping top level balances identical (IOW you can't profit just from selling stock to each other).
So in this scenario we'll assume intercompany pricing (as good as any to use for transfer pricing) and we end up with a journal entry that looks like this.
DR | CR | BU | ||
---|---|---|---|---|
Inventory | 100 | Central | Asset | |
Inventory | 100 | Wellington | Asset | |
Inter OU Contribution | 10 | Central | Cost of Sales – Factory Cost or split | |
Inter OU Contribution | 10 | Wellington | ||
Inter OU Balances | 110 | Central | (effectively combined Debtor Creditor) | |
Inter OU Balances | 110 | Wellington | (effectively combined Debtor Creditor) |
Note the effect of this transaction - Internally Wellingtons inventory increased by $100, Central's decreased by $100 but externally stock didn't change.
Externally the other 2 accounts will always balance to zero, but Wellington has paid $10 towards Central's overheads, and owes Central $110 for the stock it took.
Periodically (say end of month) the internal OU Balance account could be reset to zero for each OU with either an internal subvention or cash/bank transaction, something like (assuming a single bank account and no actual payment made) although it is strictly unnecessary but useful for reflecting actual cashflow.
DR Bank 110 Central
CR Bank 110 Wellington
DR IOU Balances 110 Wellington
CR IOU Balances 110 Central
As for the rest of the related transactions they look the same - all against the Wellington OU
Delivery
DR Stock Output 100
CR Inventory 100
Invoice
CR Stock Output 100
DR Cogs 100
Sales CR 200
GST CR 30
Debtors DR 230
Payment
DR Bank / CR Debtors
So the benefits we have.
- More accurate P & L better reflecting the operating units actual costs
- No balance sheet or P & L effect at top level
- No cost effect (i.e. average cost doesn't change)
- 100% IFRS 8 Compliant with no required adjusting entries for reporting.
The only real downside I saw is you could possibly say is that COGS doesn't reflect the transfer price, in terms of measuring customer profitability at an OU level but when you think about it (and I did for a very long time), it shouldn't. The extra $10 would have not been reflected if Central had sold directly, and Wellington has paid for that $10. So from an entity accounting perspective I'm pretty sure we are straight.
Have I missed anything?
-- End mail
In addition, if you apply this concept right through to all the things that happen from both a segment and multicompany reporting perspective the you can have journal entries like such.
Management Fees CR 100 Head Office, DR 80 Wellington, DR 20 Central
IOU Payable DR 100 Head Office CR 80 Wellington, CR 20 Central
Essentially provided we keep the net balances of an account unchanged we can reallocate cost anywhere. In the management fees case it is a gross simplification, because there would be a corresponding set of entries which are allocating the costs plus a contribution margin if any.
from operating-unit.
@gdgellatly it is great! I played a bit with this concept in v7, but finally did not pursue the topic futher.
from operating-unit.
@jbeficent I have a working alpha implementation. It is very basic and has some mocked out methods but it works for the sale from one ou, with shipping from another. https://github.com/gdgellatly/operating-unit/tree/operating_unit-ng . I was going to change name to avoid conflict, but realistically no one but me uses my repos anyway, and I don't put at apps so just reverted those changes.
from operating-unit.
Related Issues (20)
- Operating unit for Point Of Sale HOT 2
- how i can transfer products between different OU 2 location or warehouse HOT 6
- Inventory adjustment and operating unit / Analytic account HOT 2
- Operating Unit overwrite incorrect in purchase operating unit - uses previous operating unit HOT 5
- journal Sequences error in vendor payment (account_operating_unit) HOT 2
- [14.0] account_operating_unit compatibility with sale_advance_payment HOT 4
- [14.0] operating_unit - Default operating unit for new public user template ignored HOT 2
- stock_account_operating_unit -Account entry lines bug HOT 5
- [14.0] operating_unit - access restrictions is not applied
- repo readme.md HOT 6
- [12.0] Compatibility with account_payment_order HOT 1
- Migration to version 16.0 HOT 11
- Configure Document Layout in Settings Error HOT 1
- User access not working for reports ? HOT 4
- [12.0,14.0] product_operating_unit: change default behaviour of 'product.template'._get_default_category_id() HOT 1
- Default branch in operating-unit repo HOT 8
- account_operating_unit: inter ou balance lines are displayed in the invoice HOT 4
- 16.0-operating_unit: All OU addes to res users when groups_id change. HOT 1
- Migration to version 17.0 HOT 12
- [17.0][RFC] Challenge: replace operating units by Odoo branches HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from operating-unit.