Get Involved. Join the Conversation.


    Irina Feldesh, CPA, CGA
    Budget Transfers and Forecast Adjustment Entries
    Topic posted May 28, 2019 by Irina Feldesh, CPA, CGASilver Trophy: 7,500+ Points, last edited November 13, 2019, tagged Financial Planning, Integration, Public Sector, Reports 
    116 Views, 6 Comments
    Budget Transfers and Forecast Adjustment Entries
    Best practices for budget transfers and forecast adjustments for clients with EPBCS/PBCS (Cloud) and PeopleSoft On-Premise Application

    We are currently using custom built forms and business rules (CONSOL, PROJECT, and POSITION BSO cubes) to process revised budget transfers and quarterly forecast adjustments within the EPBCS application and then write back that data to our PeopleSoft On-Premise Application via a staging table that generates general journals during the nightly batch into the BUDGETS ledger.

    Our biggest challenge with this setup is dealing with multiple transactions to the same scenario in a particular year/period/version since only dimensions (our chartfields, i.e. department, account, fund, program, project, position, employee) are relevant as part of the unique combination in EPBCS (i.e. the cloud application does not appear to have been designed to handle journal line transaction detail).

    Our workaround for this was to setup scenarios suffixed by a number (i.e. RBGT_PTC_DBT_01, RBGT_PTC_DBT_02, etc.), but since the scenario dimension has a maximum of 75 members, this is not a sustainable practice as in some cases we start to get pretty close to running out of scenarios.

    We would like to get some ideas from other users as to how you are handling budget transfers (i.e. do you post these transactions in EPBCS / PBCS, how do you have the system configured to handle multiple journals to the same chartfield combination in a particular year/period, etc.).

    Any information you can provide to help us improve our existing process would be greatly appreciated.

    Irina Feldesh

    EPBCS 19.06.82 & PeopleSoft 9.2 FSCM PUM 19, HCM PUM 25, PeopleTools 8.56.06



    • Peter Nitschke

      G'day Irina, 

      It's interesting, that need to effectively do journal based budget updates is something very specific to the public sector (even down here in Australia!) 

      At a high level what we have done quite effectively is build out a BSO cube with 2 additional dimensions: 1 for Journal and 1 for Line item detail. All of the chart segments per journal per line are set using smartlists tied to the GL dimensionality, and then on save it uses datamaps to 'post' to the target ASO cube. 

      The key concern was not making the BSO cube horrifically large (government GL dimensionality was pretty big already, so adding two more dimensions is a risk) so some of the dimensions only live in the ASO cube while we keep only the core dimensions (entity \ department etc) in the BSO cube so we can utilise security. The Journal and line dimensions are also in the ASO cube so we can discretely report out on them as needed. 

      It allows for a fairly simple high level reporting model in ASO - but allows for some detailed process flows in the Planning layer including approvals, rejections, copying journals and positing validations (ie: a journal must balance before it's posted). Some of this is controlled in Groovy - which we're also using heavily for rule optimisation so we only have to calculate and post affected data. 

      Hope that helps some! 






    • Mark Rinaldi

      I sent you a DM with some information on how you can do this.

      • Cassandra Marcus

        Others may have benefited from your expertise... Just sayin'

        • Peter Nitschke


          I would love to hear what your guys thoughts and ideas on this are. It's definitely an area that is 'tricky' - because fundamentally it's not really the way businesses do forecasting \ budgeting.

          We found even things like workforce are different because of how cost allocations become an important reporting node rather than HR hierarchies (ie: who is paying for a resource versus who is managing) - and we've definitely had some struggles in that area due to the interactions of dimensional security. 

          That said, I think once you get your head around it, it's a really valuable use case of "Planning" as a product vs pure essbase because of it's ability to capture data in a specific way. 




          • Law

            Thirded !

            Would be useful to hear. These government specific requirements can be a performance nightmare, would be keen to hear what the official best practice would be.

      • Irina Feldesh, CPA, CGA

        Hi Mark,

        I received the white paper and per my understanding of Oracle's recommendation is that for budget adjustments, a revision member can be created in EPBCS to keep track of revisions, but once the data is sent to the ERP System (in our case PeopleSoft), then the revision details should be purged in EPBCS (because EPBCS was not designed as a transaction module). Unfortunately, in our installation of PeopleSoft 9.2 On-Premise, Position Number and Employee ID are not available to be used as chartfields in a PeopleSoft General Journal Entry nor are they included in our PeopleSoft Budgeting Ledger table. Therefore, there is no way for us to house this level of position budget/forecast detail in the ERP System the same way we could for project or non-position department budget and forecast adjustments at the most granular level and have it available for reporting, etc.

        How have other organizations been able to overcome this limitation?