Profitability and Cost Management

Get Involved. Join the Conversation.

Comments

  • Erik De Rouck

    There are a couple of things that impact the design setup of your allocations. First and most important is the output: you should obtain what you need for your reporting. Or in case the data analysis is also done in another system, you should have enough data detail available to successfully load the data in that other system. Secondly keep an eye on your volumes of data. PCM is a layered allocation system, so an additional allocation could use all prior allocated data. Meaning that design decisions could have a exponential impact on data. Otherwise said, if you will never do an analysis on detailed GL accounts, then you could build an allocation that distributes your cost accounts in the necessary cost account "buckets" (or even more simple, do this during the import upfront). From the calculation speed point of view, putting the "Same as source" option is faster (but potentially creates more data).

    Hope this helps

    Erik

     

  • Ayeshan Peiris

    Hi Don,

    Thanks for your response. It is so much helpful. As you mentioned, I'm currently using the Other Option's 2nd Option. (i.e. Create a currency dimension, load data to the local currency, load exchange rates vs a common currency, use custom calculation rules to convert to a common currency prior to any allocation executions.).

    Typically what we do is, We load in LKR and Reporting is done with USD. (No other currency translation is involved, Only LKR to USD). I have created more than 30+ rules and each rule contains a currency translation custom calculation before the allocation. However I wanted to do the source currency translation to entire database outline with one currency translation custom cal rule involved, but I couldn't do it as my account dimension has shared members and rule is failed due to that. can you suggest any method to do the currency translation (LKR to USD) prior allocation to entire database outline from a single custom cal rule?

    Thank You.

  • Don Bean

    Currency can be handled a number of ways in PCM.  The reporting end output will drive how best to handle it.

    Allocation rules in PCM provide a great deal of power and breadth but they also introduce the possibility of allocating funds from one currency location across many other currency locations.  PCM allocation rules are currency blind.  For example; if allocating expenses from an entity member for a Euro region shared service center (HR or IT for example) to entities using USD or other currencies PCM will not automatically convert currency nor will it store in the source currency on the target entity.   The creates the possibility of mixing values form different currencies and will invalidate your results.

    Best practice (and the one most users follow) is to convert to a common currency before the allocation process starts and convert back to local currency only if required by reporting requirements.  Typically both conversions are done outside of PCM.

    However - there are other options:

    1- create a currency dimension, load data to the local currency, create allocation rules that always use the 'Same as Source' destination option for the currency member.  This will move funds through the allocation model and always preserve the original currency.  However this can make your database grow a great deal larger than if you had used a common currency.

    2 - create a currency dimension, load data to the local currency, load exchange rates vs a common currency, use custom calculation rules to convert to a common currency prior to any allocation executions.

  • Ayeshan Peiris

    Hi, Don

    When provides fully qualified name it works fine.

    Thanks..

  • Ayeshan Peiris

    Hi Don,

    thanx a lot.

  • Ayeshan Peiris

    Thanx a lot. Hope this will be helpful.

  • Don Bean

    Ayeshan

    You need to provide the Fully Qualified Name of the member in the syntax.  

    [Dimensionname].[Gen2parent].[Gen3parent].....[membername]

  • Lisa Alexander

    Your syntax may not be qualifying the duplicate member correctly. You can specify duplicate member names a few different ways:

    Hope that helps!

  • Wayne Paffhausen

    Ross,

    I have reached out to Oracle; but have not heard back at the time of this posting.

    Thank you,
    Wayne

  • R Sax

    Hi Wayne,

    Thanks for replying.  Do you have any idea if metadata integration for DM/PCMCS is on the roadmap?

    As we're using both PBCS and PCMCS I'd like to use the same solution so may need to use on prem FDMEE if it isn't going to come for PCMCS

    Thanks,
    Ross

  • Wayne Paffhausen

    Hi Ross,

    Unfortunately as you have noted that functionality does not exist yet.  You could potentially use a custom solution if you have access to FDMEE (on-premise).

    Thank you,
    Wayne

  • Malan Jayanka

    Thank you for the reply

  • Shyam Santhanam

    I guess this belongs to inventory costing. Can you post this under SCM--> Costing? You can always view the transaction cost from 'Review cost accounting distributions' UI. Transaction costs are not stored as part of item cost record.