Message Image  

Open Forum

View My Drafts

Back to discussions
Expand all | Collapse all

Running Allocation Processor "automatically"

  • 1.  Running Allocation Processor "automatically"

    TOP CONTRIBUTOR
    Posted Aug 07, 2020 11:49 AM

    We are, once again, pondering whether we could/should run allocation processor "automatically".    As you can see in the documentation below copied from "Help", allocation processor can run in either Batch Selection Mode or Auto-started mode.

    Is anyone out there running Allocation Processor in either Batch Selection Mode only or with Auto-started mode?   What is your experience?    What are the pros/cons you've found in using this option?   Do you find it stable?  What if you have a large number of transactions?  Does that make any difference?   How much does it slow down system performance?   Does it increase SQL blocking?

    Any insight would be appreciated!!

    Best regards,

    Gail J-N


    Allocation Processor (PA.PRO.00) can operate in three modes:

    ·         Regular Mode – In this mode, Allocation Processor (PA.PRO.00) runs online via the screen and the user selects all projects or a subset of projects (by subaccount, method code, or project prefix). Table PJTRAN is used to read the unallocated transactions. This mode is appropriate when a small number of projects and transactions need to be allocated, either weekly or monthly.

    ·         Batch Selection Mode – This mode is activated by selecting Selection by Batch in Project Controller Setup (PA.SET.00). In this mode, Allocation Processor (PA.PRO.00) also runs online using the screen, but it is possible to select by individual source posting batch. Table PJTRANWK is used to read the unallocated transactions and all allocations are considered recalculations (to avoid any possibility of duplicate posting). This mode is most useful during implementation when the ultimate intent is to run in Auto-Started Mode (3) but it is desirable to run Preliminary allocations so that Method Codes and rates can be reviewed and debugged. This mode is not normally used in a production environment.

    ·         Auto-Started Mode – This mode is activated by selecting Auto-Started Allocations in Project Controller Setup (PA.SET.00). In this mode, Allocation Processor (PA.PRO.00) runs in the background automatically whenever a process such as Financial Transaction Transfer (PA.TRN.00) or Time Review and Approval (TM.TRA.00) creates project actual transactions (as opposed to budgets or commitments) in the Project Management and Accounting tables. All batches are processed as Final but no reports are produced (they may be run after the fact, from the Allocator Reports menu, if desired). Since the process that initially creates the allocable PJTRAN records then proceeds to allocate them automatically, this screen is only used in Recalculation mode (allocation recalculation is still run online from the screen for situations in which rate or method code errors and need to be corrected). This mode is appropriate when many transactions are being allocated and transaction volume is high, or when allocations need to be expedited (e.g., for billing purposes).




    Selection by Batch

    This check box determines whether the batch release process for the source transaction runs Allocation Processor (PA.PRO.00). If the check box is selected, all programs that create and post batches (actual transactions only, not budgets or commitments) to the Project Management and Accounting tables also write the batches to the Allocations work/input table (PJTRANWK). The Allocation Processor (PA.PRO.00) then reads this table by source batch number when performing allocations. See the documentation for the Allocation Processor (PA.PRO.00) for more information.

    Auto-started Allocations

    This check box is enabled only if the Selection by Batch check box is selected. If selected, each release process that creates and posts an actuals batch to the Project Management and Accounting tables automatically starts the Allocation Processor (PA.PRO.00) in the background immediately following the release process. Please see the documentation for the Allocation Processor (PA.PRO.00) for more information.



    ------------------------------
    Gail Jones-Nemeth
    Financial Systems Analyst
    Creative Associates Int'l
    Washington DC
    ------------------------------


  • 2.  RE: Running Allocation Processor "automatically"

    GOLD CONTRIBUTOR
    Posted Aug 10, 2020 09:13 AM
    ​Gail,
    We have a large amount of transactions daily and have had allocation processor turned on for 5+ years without issue.
    It really has saved our finance group a lot of time.
    Even though it is set to auto-allocate it can be run manually at any time.

    Here is our setup, hope you can see it, it is really small for me.
    Allocator Setup

    The Selection by Batch option is for great for when there are network issues and a batch doesn't process the whole way through.  You can go into Allocation Processor and post each batch.
    There is a report that was in a KB article can download and put as report option in Alloc. Proc/GL Positng Audit Report -PA.450 to run to see these batches - Unposted Allocations KB933082 | PA450C.  Our finance group does this throughout the month so month end goes quicker.

    Hope this helps!!

    ------------------------------
    Karla Johnson
    System Architect
    Schneider Electric
    Carrollton TX
    ------------------------------

    Original Message


  • 3.  RE: Running Allocation Processor "automatically"

    Posted Aug 11, 2020 10:50 AM
    We are looking into turning on auto-allocator as well. I admit to feeling a little bit cautious about it because I'm concerned that we will run into data locking issues on Mondays when we post our timecards from the prior week. We have about 700 timecards that get posted by office, so they are not being posted at the same time.

    For those that have auto-allocate turned on......do you post your timecards all at once, or sporadically like we do? If you do not post them all at once, have you experienced any data locking issues? It doesn't sound like it from the folks that have responded, but wanted to get a sense of how you post your timecards.

    Thank you,


    ------------------------------
    Shannon Bratton
    Project Accounting Manager
    David Evans and Associates Inc.
    ------------------------------

    Original Message


  • 4.  RE: Running Allocation Processor "automatically"

    SILVER CONTRIBUTOR
    Posted Aug 10, 2020 05:12 PM
    Will second the pro's of turning on auto allocator - turning on this option was a big turning point in our process workflow at the time. We do have a lot of time and expense transactions hitting daily across 7 active SL DB's.

    For allocation errors, we depend on getting those errors resolved promptly, so we have an automated alert that runs hourly and sends results to appropriate users for troubleshooting as time permits (if errors present in the table).

    Our strategy at the time was fairly cautious/reserved ("we'll turn it on and monitor for a week and inactivate if problems...") - never did turn it off. I posted a mini-write up of my experience 5 years ago on the old board, copy / pasted below w/ a few tweaks, most of it still sticks, wouldn't go back!

    ------------------------------------------------------------------------------------------------

    1. Auto-allocator is much more time efficient process than running manual allocator

    • It is also a key process to enable real-time project reporting as transactions hit the project as soon as posted (in prior practice we used to allocate in bulk manually a few times a week/day. A ~20 min exercise * the # of entities)

    2. Turning on auto-allocator means only "Recalc" mode is available for selection within Allocation Processor

    • Recalcs are a much more batch or project/task/date range specific exercise than allocating for all projects

    3. Errors are captured in PJTRANWK table, which can be read using the add on report from the SL user group section

    • If a single transaction in a batch encounters an error, all transactions are held up until it's been fixed

    • Install default SL Report PA450C: KB 933082 to view unposted transactions (Location in SL: Project> Allocator> Alloc.Proc/GL Posting Audit (PA.450.00)> Report Format: Unposted Allocations

    • We wrote a basic query to better read the table across multiple databases which was turned into a report / alert to notify appropriate users if results in the error table (alert runs and sends results hourly)

    • When troubleshooting a batch, recalc the specific batch in Allocation Processor

    • Select the Fiscal Period, System Code, and Batch Number

    • If you have many transactions within the error batch, run a general Recalc against the batch, and you will be given a traditional "event log" highlighting the details of the encountered error, which you can then troubleshoot in detail

    • When this table is clear, there are no errors to troubleshoot

    4. (Minor consideration) All project transactions auto-allocate as soon as the batches are posted; think about existing project reports that might not be period sensitive

    • Some of our internal reports were based on transactions posted, not necessarily the period or thru date range, so it forced us to revisit some older reports to add tran date or period posting to the select criteria (very few)

    Activating this feature helped us push ahead with creating more real-time project reporting data and saved a lot of processing time by removing the need for manual allocation runs. It's hard to imagine looking back!



    ------------------------------
    Justin Fishwick
    Manager of Business Analysis
    The Brattle Group
    ------------------------------

    Original Message


  • 5.  RE: Running Allocation Processor "automatically"

    TOP CONTRIBUTOR
    Posted Aug 13, 2020 11:42 AM
    Thanks to both of you. This is extremely helpful. I still have more questions.

    What steps did you take to be ready to turn it on to test? E.g. did you have to add access rights to run allocator for anyone releasing/posting batches? I think we were a bit leery about giving that right to everyone….

    I'm interested in how you handle the Allocator reports. As we know, once the month closes and the Project Closing process clears out the PJALLSRT table, then it's no longer possible to run allocation reports for the period. So we have always made it a point to print our allocation reports to PDF files and store them. That's easy to do when they generate automatically as a result of actually running the allocator process. However, with auto-allocation they don't generate automatically – hence the need to generate them from the Allocation Processor Audit report (PA450).

    How do you make sure to get the allocation audit report each month? Who in your organization is tasked with making sure that the month-end allocation audit report is run?

    I've been testing which period the auto-allocate uses to post to. The question was whether the allocation batch would post to the source transaction fiscal period, or to the period the project module was in. What I found was that if the project module was in period 10, the AP module was in period 11, and I released an AP batch in period 11, then the allocation batch was in period 11. Sweet – just what I wanted.

    However, when the GL and project modules were in period 10 and I released a GL batch to period 09, then the auto-allocate batch created PJTran records for period 09. That's probably livable, but no Batch record was created for the auto-allocation batch!   i.e. the batch was damaged and would have to be repaired in order to release it. Have you ever experienced an issue like that?

    I would also like to echo Shannon's question about locking.    Have you run into any issues with locking/blocking at the SQL level due to running auto-allocaiton?

    Any additional insight would be appreciated!!

    ------------------------------
    Gail Jones-Nemeth
    Financial Systems Analyst
    Creative Associates Int'l
    Washington DC
    ------------------------------

    Original Message