Community archivi mailing list
Naviga tra gli archivi
Re: Intermediate Costing in MRPda
David why don't you ise analytical plan/distribution? It worked fine after adding oca and vauxoo plan modules and some homebrewed modules.By the way, you can hackety hack allocations leveraging the fact that analyticals have some integration with products and units of measurement. This is not very recommendable and goes something around this:Configure a fantom product, with your UOM of special "analytical distribution", then configure the base unit and configure the UOM which is the sum of distributable points in any given situation, for example 100, if you would be working with integer percentage, or the total square meters in the case of housing company, etc. Then at least you can "ease" distribution by setting the cost of the product to what your distributable account gives at the end of the given period, and after that you will proceed with allocation based on the number of units. The benefit: you might make less mistakes as you can work in your own distribution unit instead of it's money value representation. Clearly you need one fantom product for every analytical you want to allocate and eventually also one UOM for every base unit pool (eg total square meters of building x, total square meters of building y, etc).You see, how bad things are... :DOleg, I had a quick look at your links:With Noviat's approach, you probably can beat AlphaGo :) Refreshing, although probably of doubtful practical usefulness in the mid-range.Operating Units implemented through a dropdown like the new V10 company selector, would be indeed an interesting UX. Then however, I would have to ask, why not use company hierarchies altogether and rather forego the last 10% optimization, if we are talking about this conceptual level of isolation. Wouldn't it be much probable that each OU would want to use their individually adapted chart of accounts /user base/ client base/ etcetera pp anyway? Slightly modifying res_company with the best of breed ideas from this approach could be the most beneficial strategy, while keeping conceptual shades to a minimum...In Onestein's modules, to me and at first sight, conceptual depth and conciseness seems overthrown by a very specific use case in mind.Best, DavidI think, there is certain point about double entry versus filters, which are pure antagonists, if you can secure consistency by other means. I opinion, that single entry logic should be maintained for analytics as this is the only way to possibly implement multidimensional analytical charts in an otherwise flat and simple manner. Consistency can be well enough ensured by the templating effect of a BAB, as annexed.Ceterum censeo, a base framework should include a company-like department implementation penetrating existing move.line and reporting frameworks. This is what most people are most interested after all, and we already have a perpendicular source of information in the hr application.David,This feature is missing since beginning of OpenERP/Odoo and there are many attempts by community to bring it in in different ways.I can say even Analytic Distributions in Odoo 8 where not working properly in standard Odoo and not enough (not corresponding to business reality). I think that the most successful attempts to move in this direction are:1) https://github.com/Eficent/operating-unit (Allow to define operating units with possibility to build financial reporting among them). OU can act like Cost and Profit Centers. Still missing feature is re-distribution of costs/profits.2) https://github.com/onesteinbv/addons-onestein (look at account_cost_* modules). I personally never tested them, so cannot judge. One thing I see -they are focused on invoices only, so not covering all business needs3) https://github.com/OCA/server-tools/pull/275 - another fundamental work initiated by Noviat (active repo is here https://bitbucket.org/xcg/analytic_structure/overview ) that is not yet finished. And seems is designed for Odoo 8 only. I think one of the implementations that is most promising. Seems to me quite technical to configure it (but if having needed amount of predefined modules for defining analytic structure for typical Odoo objects even functional consultant can do everything from web interface). Also here I'm not sure about redistribution capabilities at the end of period. I think there are not.My personal resolution on this is that until Odoo itself decides to include this type of functionality into core Odoo, there will be only custom solutions for this type of problems that most likely:1) will outdate from version to version and become not usable (with release cycle of Odoo every 6 month, impossible to migrate to latest version in reasonable period of such fundamental functionality)2) will be designed for specific customers (for those who are paying for it). Not universal solution.So I would say that as this topic is hanging in the air for long period (just google for "Cost Centers" in Odoo forum), will it be reasonable to discuss with @Fabien this topic for Odoo 11/12?If we get official confirmation from Odoo, we can gather together and create specification/contribute to Odoo best of what we have either from private repos/or from Community.I think it is only valid way to go. Without Odoo support we will be loosing everything we do from version to version.What you think?Are you talking about possibility to have in Odoo mature and usable functionality of Cost and Profit centers? With possibility to re-distribute costs and profit dynamically at any period of time whenever company decides to do that?Exactly, this is what I'm missing upstream. There is another one: "Investment Center", but that's a rather easy one. I just was scratching a bit on the surface of this topic these days.El lun., 2 ene. 2017 a las 4:26, Oleg Kuryan (<firstname.lastname@example.org>) escribió:
Thank you for your thoughts. Can I ask you differently to keep your story a little bit shorter.
Are you talking about possibility to have in Odoo mature and usable functionality of Cost and Profit centers? With possibility to re-distribute costs and profit dynamically at any period of time whenever company decides to do that?On Mon, Jan 2, 2017, 11:51 AM David Arnold <email@example.com> wrote:Continuing thoughts... Kick in, if you want.Maybe I'm wrong and Odoo's future stance (since V9 accounting with tags) is focused on compilation at the moment of retrieving as opposed to compilation at the moment of registering. (This is also what the docs on analytic pivot table looks like)This however, in the case of analyticals, would rapidly lack of time dynamics, as distribution of costs from overhead towards the centers might potentially have a validity date range. In the end, probably the thing is just not to touch this topic too much and leave it to what comes after the xls-export button. However, then, a standard path to center controlling would be very much appreciable.By the way, as we are among disruptive folks, I guess a department implementation (through hr app) just as elegant as the new company implementation, penetrating into the move line concept and PL standard reporting, is nothing to discard. On the accounting level this would just zero out (="streamline") the single most common use case of analytics, where often time, we see folks building a secondary department structure in analytics, or now, even worse "analytic tags". (Whatever that might actually be, it's so much arbitrary that using it might be a future migration risk.) On the business level this might incentive people to marginally spread out administrative interaction with Odoo into the departments, which drives both, more license revenue for Odoo and greater hinted-on efficiency benefit for the Client. Think paradigmatic: "value in the system should be moved by the same user who moves it in reality".And once we think that pattern in a streamlined manner, if it's acceptable on the db query level performance wise, I'd appreciate an analytic ttype, so that each application can keep hijacking this concept, yet in a little more civilized way. This would pave the way for yet more hijacking and eventually splitting it up, although the different depth drill down in the pivot view mixing a lot hell of concepts is a nice feature. Why not a dedicated app called "Controlling" to enlighten a bit the conceptual jungle for everyone?Best Regards,David ArnoldHi,If you don't agree, please veto and correct me.I opinion that there is one functionality missing in Odoo which would pave the way for intermediate (& elegant) cost controlling.Given that we accept and acknowledge well known center concepts, the lack of a simple possibility to encode cost allocation from different auxiliary cost centers to their final bearers is astonishing. As far as I know, it even has been dropped while some hardly usable implementation existed in prior versions! Germans call this allocation sheet BAB or Betriebsabrechnungsbogen and it's such a commonplace concept, that I pretty much doubt that it would be less common place amongst controllers (not accountants!) around the world. The possibilities of the new interface, see ex. Timesheets, should open the possibilities to solve this attribution definition in a UX optimized manner.While I guess a PR to upstream should be sincerely discussable with responsible persons at Odoo HQ, I also noticed a second flaw in the activity based costing approach of the new MRP application:While general ledger is affected correctly (!) on every consumption activity, be it material or cost of an activity, the analytical entries (here used as auxiliary entries to be able to identify and manually cross the general ledger difference on the production account caused by the valuation increase on it's credit side due to activity costs) are only affected at the time of finishing the production.While valid for the stable use case, it provides inconsistencies in the unstable use case where work centers do not obey a constant cost structure (think of agricultural work centers such as a harvesting squadron). In the case of changing work center cost structure it can produce the inconvenient situation, where costs are correctly accounted for on the general ledger while analytic entries are produced based on the cost registered at time of termination of the production, not the activity.I guess this is a flaw or even a functional bug in the system and it seems it hasn't been accounted for yet.Any opinions? Someone Wang's to join a PR effort to upstream?Some time ago, seasoned implementers recommended phantom products, but given the principle that cost controlling is not general leader's business and given the new activity based approach through analytical accounts, this recommendation has become less valid.BestDavid
Technical Director, XPANSA Group | ERP, BI, E-commerce, Data Mining and DMS consulting