Plugin: Budgetary Control

• MAINTAINER: Red1 (talk) - RED1.org
• SPONSOR: SYSNOVA
• COPYRIGHT: red1 (the novelty of the technical specifications are the original idea of the author(s) stated in later details.)
• OTHER CONTRIBUTORS: Steven Sackett, ADAXA for Budget Accounting Rules
• VERSION: 1.0 ALPHA (DUE END-MARCH, 2014)
• LICENSE: GPLv2 - Free as in Freedom not Free Lunch
• PRICE: (to be determined later for non-contributor commercial users only)
• GUIDE: (to be published later)

INTRODUCTION

• THIS IS A WORK IN PROGRESS - EARLY RELEASE DUE END MARCH.
• 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.

GENERAL SPECIFICATIONS

Business Convention

• The Budgetary Control 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

STATUTORY SPECIFICATIONS

• 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.

TECHNICAL SPECIFICATIONS

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 http://wiki.idempiere.org/en/NF001_ImportCSV
• A template should be defined and documented for such use, which directly imports the CSV to GL Journal.

HOWEVER 'ADempiere' MAY BE EXTRA MAINTENANCE:

• 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)

ACCOUNTING SPECIFICATIONS

• 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

REFERENCES

• INC.COM
• BBRT.ORG/Forecasting Budget

IDEAS

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.

DEVELOPMENT

Proof Of Concept (POC)

• NF1.0_ImportCSV#CORRECT_SALES_ORDER_CSV proves that this feature works, and to do an actual test for GL Journal.
  • The GL Journal will post to Fact_Acct table as a new record.
  • Subsequent editions to the budget can result in a new Fact_Acct set of lines with the old ones deleted.
    • If the GL Budget process does not delete then we have to think whether an additional process to remove previous Fact_Acct is needed.