Comments

  • 1-10 of 10
  • Mathieu Kamp

    Alphabetically is not really smart....most clients would like to have the most used LE on top. Legal entity identifier would be more logical in my opinion.

    But thanks for the feedback,

    best regards mathieu

     

     

     

     

  • Mathieu Kamp

    Hi Diego,

     

    Thanks for your reply. How did you change the parameters of the print program? As far as we can see we cannot change the parameters to set it to an XML print (instead of pdf etc... as in the screenshot above). Or are you using an on-premise version of Fusion? Would you be able to help us a bit further? Any help is much appreciated.

    Best regards Mathieu

  • Mathieu Kamp

    Hi Diego,

    Just wondering whether you found a way for this in the end? We are facing the same issue. Client wants to send out an e-mail with the XML invoice file as attachment? Just changing the output format from the BIP template into XML results in the invoice print program erroring out.

    Any help is much appreciated!

    Best regards Mathieu Kamp

  • Mathieu Kamp

    Thanks for the information and replies,

    best regards Mathieu

  • Mathieu Kamp

    Hi Neil and Seamus,

    Thanks for the extensive replies. I would like to give a bit more information on the specific case so you might understand a bit better why we are setting it up as described. It's not that we do not want to go for a ledger in local currency per country but we are afraid this will overcomplicate things as their corporate structure is already quite complicated.

    There are a couple of things why we think a single primary USD ledger still looks like a good option

    - this client has lots (around 90)  of companies/LE's in lots of countries (tax and liability reasons mainly). Bottom line the company is managed in USD and NOT in all the local currencies in the countries where they have companies.

    - Their is a lot of inter company recharging taking place from one company (for example in the UK) to other companies (in for example Singapore). When the primary book of the UK is in GBP and the primary book of Singapore is in SGD you will always have exchange gains and losses in your primary book while it is far more easy if both companies have USD as their base currency. Intercompany recharging is required in a number of ways (via automatic i/c balancing in GL, via I/C AR and AP invoices from one company to another for non project related recharging and via PPM for project related recharging)

    - Another point is that the corporation is not ran at company/LE level. Their is another dimension called 'Management Group' on which level the company is managed. A part of a company (for example company 101) can be managed by 'Management Group'  'A' and a part is management by Mgt Grp 'B'.  We actually require both a balance sheet and p&l at company/LE level and at Mgt Grp level (but as in the example Mgt Grp is not the sum of a number of companies, unfortunately). To achieve this we are testing the use of a secondary balancing segment (initial balancing segment is 'company/legal entity', secondary balancing segment is 'mgt grp'). A senior mgr is held responsible for a mgt grp and not for a company, the company is just their for tax/liability/contracting reasons.

    Company/LE can be related to a country (so to an individual ledger when using a ledger per country) but mgt grp goes across country. For the secondary balancing segment we will need automatic balancing but as far as I know this cannot be achieved 'over' multiple ledgers??

    - Business Unit is another thing. The 'out of the box' way is to setup a business unit per company/LE but that would lead to lots of business units while we actually only need 1 business unit. In each country the business processes are more or less the same and they are all using the same suppliers and customers (with some exceptions). So ideally 1 business unit. With 1 ledger per country you would at least have a business unit per country. (although we are facing an issue within PPM where PPM requires a business unit per company/LE because inter company billing out of PPM does not seem to work on LE level but only on Business Unit level).

    At the moment there has been a test system configured with 1 primary USD ledger and secondary ledgers around it for country specific statutory reporting with 1 business unit underneath. It is a test drive to 'check' whether that's the right way forward.

    Hopefully this clarifies the case a bit more,

    Best regards Mathieu

  • Mathieu Kamp

    Hi Neil,

    Thanks again for the quick reply. What is the reasoning behind a ledger per country? It will also not tackle the issue of sequentially numbering documents as there are in most cases multiple companies per country. So for them having sequential numbering per legal entity would be the best option (which comes with R9 as far as I understood?)

    In this specific case this would mean quite a lot of ledgers and business units as well. There are a number of reasons why have multiple ledgers would make things more complicated in the case of this client and for them having 1 single USD primary ledger has really lots of significant benefits.

    Anyway we are a bit getting away from the question. Is there a way to restrict the companies being posted to a secondary ledger? Do you have a suggestion how to achieve this?

    Thanks in advance,

    best regards Mathieu

  • Mathieu Kamp

    Hi Neil,

    Thanks for the quick reply. It seems the best solution is to have 1 primary USD ledger for all 90 companies. The 90 companies are mostly non US companies and will need in a lot of countries a local ledger in local currency. So though they have the same CoA, the base currency needs to be different.

     

    So it will be 1 primary ledger with USD as base currency with 90 companies and around 20 secondary ledger around it with  GBP, EUR etc.. as base currency.

     

    Ideally you would only like to have the relevant companies in the applicable secondary ledger and not all...

     

    How would you be able to filter this with SLA rules?

     

    Regards Mathieu

  • Mathieu Kamp

    This was indeed the issue. So be aware when using table validated value sets ;-)

  • Mathieu Kamp

    Hi David,

    The patch which you are referring to cannot be found by us with a 'normal'  Oracle support login. Also the URL you are referring to seems to be an 'internal' Oracle URL.

    Could you help us out to get this patch?

    Thanks and regards,

    Mathieu Kamp

  • Mathieu Kamp

    But that means re-defining all the seeded SLA accounting rules for something which was standard in R12. Is there really no way of achieving this by a personalisation? Does anybody know if setting a dynamic default is planned in any future release?

    Regards Mathieu