Budget vs Actual 2009 NAV (RTC)

irnbruirnbru Member Posts: 7
edited 2015-06-09 in NAV Three Tier
Morning,

I appreciate this is quite a complex question for my first post but I'm a bit stuck with trying to get a development plan and solution in place.

Our IT department has been asked to have a control in NAV that blocks orders exceeding the allowed budget on job task lines for individual items (cost and revenue).

The MD has also asked for a tiered structure where a job has a main task line that shows totals with all of the others lines being our projects (essentially child lines to the main parent line) that collate up to to the main line, i.e. there would be a overall budget on the main line with all of the task lines checking against this as projects are surveyed then worked on but combined they shouldn't exceed the overall main budget line budget. He's looking for a 'remaining' figure to be shown, i.e. the budget on the main line minus the total budget on each of the task lines and actual on main line minus total of actual on each of the task lines as they continue to get added over the course of the contract

The link between each task line related service orders would be similar with each of these posting their allocated task line and showing total budget vs actual from all of these collated on the task line.

It would be along the lines of this for costs and revenue:

Task Line | Overall budget | Remaining Budget | Overall Actual | Remaining Actual
MAIN 100 000 45 000 2000 98000
1 50 000 5000 1000 49000
2 5 000 1000 4000
* If on task line 3 someone tried to budget for 75000 then it wouldn't allow this
** This would be the same for actuals from service order to task line to main line

We're just scoping this at the moment so any pointers or suggestions would be appreciated (or alternative ideas on how to get similar outputs!).

Thanks in advance.

Comments

  • Rob_HansenRob_Hansen Member Posts: 296
    NAV doesn't have these kind of controls out of the box as you know. So, custom development is one option, especially where the scenarios are very specific like yours. We are in the process of releasing an add-on (BudgetPath) that implements similar controls to this. I'll tell you a bit about how the product is structured, more because you may want to approach it similarly if you go the custom route. Our product is (currently) focused only on controlling the cost side against budgets - not revenue. It's an area we'll be looking to expand to.

    Our product is heavily structured around Dimensions...so we support budget checks by dimension. The product also adds the 8 global dimensions to the G/L Entry and Budget Entry tables. There is a configuration area to define the budget rules. For example, a rule can be set up to "check the budget for accounts 50000..50099 by global dimension 3" (or whatever dimension(s) are budgeted). The configuration then ables the user to specify how to handle an overrun (firm block or allow with an email notification). There are also warnings (for example, send a notification email when actuals are within 15% of budget).

    In your case, i'd suggest looking at leveraging dimensions as opposed to adding custom fields and processes all over the place. Dimensions are a great base for MANY things, not just analysis and reporting. You'd be looking at creating a dimension value to use for each main task, as you describe it, and the budget controls would then be set to work based on that. If you just need to control/restrict budgets based on the overall task, that should do it. If you need controls at the sub-task level, that would become a second dimension to use for budget checks.

    We built our controls to trigger at the time of posting, and also at the time of releasing a purchase order. Again, we wanted to avoid extensive custom code to go out and look at other open documents. Finding the most efficient approach is always our goal when designing products. So again, we leveraged dimensions here. We use another dimension to categorize transaction types (ACTUAL, ENCUMBRANCE). At the time of releasing a PO, we post encumbrance entries for the outstanding amounts on the lines tagged with the ENCUMBRANCE dimension value. If these trigger a budget issue, our existing code will handle it. Once the entries post, they are in the G/L so that all other actions throughout NAV consider them for budget checks. We also added pre-posting budget check functions to make life easier for users. The ENCUMBRANCE entries can easily be filtered out when looking at the chart of accounts, account schedules, etc., so they don't pose an issue for standard financial reporting.

    This is an area where NAV definitely doesn't have much to offer out of the box...hence our decision to build and release a product around it.

    I hope these thoughts are helpful as you plan out how to tackle this. It is a fun one to dig into!
  • Rob_HansenRob_Hansen Member Posts: 296
    Also, if you're using Jobs in NAV then obviously some of the job planning line budgeting comes into play...but in the context of how we approach this we would still look at creating synchronized dimension values for each job task (linking the sub-tasks to the main task dimension). In case you can't tell, I really love my NAV dimensions. :)
  • irnbruirnbru Member Posts: 7
    Rob Hansen wrote:
    Also, if you're using Jobs in NAV then obviously some of the job planning line budgeting comes into play...but in the context of how we approach this we would still look at creating synchronized dimension values for each job task (linking the sub-tasks to the main task dimension). In case you can't tell, I really love my NAV dimensions. :)

    Thanks for this - gives me something to think about over the next few weeks!

    We really need to start making better use of dimensions so this can be our starting point :)
Sign In or Register to comment.