Plugin: Budgetary Control

From iDempiere en

If you want to provide additional comments, please use the Discussion page.


  • Please contact maintainer to forward any requests, specifications or ideas to make this a success.
  • Any work stated here can be reused by other projects as long as the licensing, credits and link-back to this page are provided at its web-page header or main footer.


Business Convention

  • The Financials based Module shall be made in accordance to published international standards and well structured in an OSGi plugin user environment
  • The plugins shall be backward compatible and not impact any core processes unless explicitly specified.

Naming Convention

  • Plugin Name: org.idempiere.budgetBase, org.idempiere.budgetProcess, org.idempiere.budgetStd
  • Package Name: org.budget.*, i.e. org.budget.base, org.budget.client, org.budget.process
  • No company name allowed except in copyright statement
  • No other project name allowed except in license statement


  • The module shall allow compliance and auditing requirements by statutory law and bodies. It shall be made adaptable in most countries via a locale selection.


Design of Plugin

  • This module should be only for a single specific purpose. Any further purposes shall be made in another set of plugins and they should be equal citizens with no interdependency unless explicitly specified.
  • The module shall not modify core models such as Accounting Schema. This is possible because the plugin is self aware that it is for Budgetary usage. Uninstalling it shall remove such awareness naturally. Thus a checkbox to CheckBudget, or System Configurator with core code introduction is not needed anywhere.
  • The module shall not be specific to any document. This is achievable with lesser code in a single Document-Event validator that checks for Trxn status rather than DocType. This can be in another plugin
  • A base plugin can be the building of the Budgetary Control/Lines containing no processing logic.
  • Processing logic be in a separate plugin for easier maintenance and deployment as well as variety of settings.
  • The Java classes must be easy to read and well documented

Design of Master Input

  • Input should be in an Accountant-friendly environment such as the use of a spreadsheet as in
  • A template should be defined and documented for such use, which directly imports the CSV to GL Journal.


  • An alternative template that is backward compatible for old Compiere/ADempiere importer in iDempiere.
  • That importer process is an extra step to a window model to be designed to embed the ImportProcess logic.

Design of ImportProcess Logic

  • Source of Java class: (to be submitted later)
  • General description of logic: (to be submitted later)


  • The budgetary amounts are stored in the Budget accounting type which was designed in Compiere ERP (1999-2006).
  • The accounting event dimensions are also designed in Compiere ERP (1999-2006):
    • Accounts ID,
    • Product,
    • BPartner,
    • Sales Region,
    • Period,
    • Org and
    • 2 other user defined elements
    • Project
    • Campaign
    • Activity



Balanced Business Plan Concept

  • A balanced budget plan will have both sides covered, i.e. Income vs Expense.
  • This can be used to cover planned or target achievements such as amount of Sales of the Organisation.
    • The budget Fact_Acct element should be the Sales accounting element and happens only if IsSOTrx is true.
  • For this a plugin can give a prompt of whether the sales is far from the target.
  • This also means granular approach, i.e. if the Sales falls under Org, BPartner or Product criteria, all that exist in the Fact_Acct table.

Combi elements

  • What if a budget line has multiple values and in combis? I.e. there is a line for Org, and there is a line for Org and Product and there is a line for just that same Product? Or there is a Project budget, an Activity campaign and also a Project/Activity budget?
    • Firstly this rule has to be exclusive i.e. you cannot put a same budget amount twice in two places.
      • For example $500 for South Org (for all products), %400 for Seeder product (for all Orgs), it would mean you allocated 500 to spend for that Org and another 400 for purchasing that product.
      • If you put $600 for Project A and $700 for Activity B then a requisition for Project A/Activity B is wrong and the creator has to decide if it is A or B.
      • A non-match can be flagged as 'No Budget Match' by the plugin.
    • However there can be a combi budget for A/B in which only an exact requisition for that is matched.
      • The creator can make in jointly inclusive for their parent categories ie A/B allowed $300 which is taken from both Project A and Activity B' budgets.
      • This just means that A/B is allowed just no more than 300. If you wish more then just decide either Project A or Activity B
      • In the case of ie South/Seeder = $200, then you can only spend 200 max at South for purchasing Seeder, and if purchased, it is minus from both South and Seeder budgets the amount.
    • This allows for further budgetary control.


Proof Of Concept (POC)

Using Import Loader

  • For more elaborate lines.
  • NF1.0_ImportCSV#CORRECT_SALES_ORDER_CSV proves that this feature works, so we can test now for GL Journal.
    • The GL Journal will post to Fact_Acct table as a new records according to each line in Excel table.
    • Subsequent editions can use merge feature.

Using Direct GL Journal

  • The simpler will be to use the GL Journal directly.

GL Journal (Budget)

  • Following is the sample for GL Journal table to be posted into the Accounting Facts table as Budget
  1. Set sample GL Journal (budget) : (i and ii are hard set for fixed costs)
    1. Project, Amt
    2. Period, Campaign, Amt
    3. Activity, Percent(%)
  • Percent is new field and can reuse GL Journal and Fact_Acct's UserElement1 fields.
  • New table to store settings stated above and: budget reached, override, override with other surplus

Budget Configurator

  • The following derive the Sales - Expenses in the Docs of specified Acitvity against the percent set for that activity
  1. Forecast years: (if 0 then present, if 1 then last year. correspond to number of previous years)
  2. Forecast for this year: (if 1. no value, you can set here directly your own figure)
  3. No pro-rata: (base on total year budget balance. If checked, 4. will not display.)
  4. Month on Month: (if checked, will take from same months in previous years for rolling forecast concept. If not, it will take pro-rata)
  5. Formula Trend: Average/Progression/
  6. Forecast months: (if 1 then last month, correspond to number of previous months.)
  7. Forecast for this month. (if 6 no value, you can set based on own analysis).

Another process can do the sample GL Journal (budget) by processing the previous years (param1) and derive according to the formula (param2) for any set of Accounting Element (param array or sub table) And it can use the GL Journal.budget set to 'forecast' where a set is already made

Killer Features

  • As can be seen in the forum link above, I have completed some killer features
  • Dynamic choice of Revenue reference for Percentage Base
    • Each budget rule can have preferred percentage base or else default to revenue base
  • Debug Mode to throw every event regardless if excess or not
  • Writing to Notice table for logging purpose in the background
  • Code logger at FINE and FINER levels for reporting every method executed in the class
  • MonthToMonth Budget Generator
  • Sales Target use besides Budget Control
  • Full documentation
  • Accounting Fact populating process for testing purpose. Populates data backwards for number of years to use on budget historical process.

New contributors

Cookies help us deliver our services. By using our services, you agree to our use of cookies.