Toolbox

The purpose of this document is to describe the Functional Specifications for an extension module to be developed in OB ERP version 2.50 called Accruals and Deferrals.

This function is required by HIS.

Scope

"Accruals and Deferrals" is intended to correct periodization of expense or income.

This function is required in Germany, but is also generally useful in other countries.

Justification

Normal use of periods

In every booking of expense or income ( for example in invoices ) there is usually entered a period which is referred by the expense or income. This is an information needed by controling management and budgeting.

So the periods will be entered in any way, but only if the period fields are entered as discribed in the following, accruals and deferrals module should run.

The relationship between accounting date and period dates causes selection of accruals or deferrals accounts as it is described in the business scenarios.

Special use of periods

There is a requirement to distribute a cost which occurs over more than 1 year. This is to ensure that the cost is matched to the periods in which the benefit is received. In Germany, this distribution is required by law.

Example:

A subscription for a journal is invoiced and paid in 2009 (€ 200). The subscription is for 2 years (2010 and 2011). So the delivery of the journal is in 2010/11.

There is a disbursement of € 200 in 2009:

2009, actual period

Journals - VaLL, 200.00

VaLL - Bank, 200.00

But the effort or consumption is in 2010 and 2011:

2009, end period

ARA - "Journals", 200.00

2010, starting period

"Journals" - ARA, 100.00

2011, starting period

"Journals" - ARA, 100.00

ARA is a special account for prepaid expenses on the assets side of the balance sheet.
VaLL is the account of the business partner for liabilities.
"starting period" and "end period" are special periods (not january nor december) indicating the year into which the cost should actually be posted.

All these bookings could be done manually. But also automatically, if the systems know the periods for distribution.

New definitions and acronyms

"Rechnungsabgrenzung" = accruals and deferrals
"Aktiver Rechnungsabgrenzungsposten" = prepaid expenses
"Passiver Rechnungsabgrenzungsposten" = deferred income
"Sonstige Verbindlichkeiten" = other liabilities
"Sonstige Forderungen" = other receivables

CAUTION:
'accruals' has 2 translations in german: "Rückstellung" and "passive Rechnungsabgrenzung"

"Accruals and Deferrals" can be subdivided into

transitory: The expense or income refers to the booking period of next fiscal year.
anticipatory: The expense or income refers to the booking period of previous fiscal year.

Reference point for this decision is the booking period of the invoice.

In the following graphic

prepaid expense
deferred income
other liabilities
other receivables

are special accounts to be booked

IB = invoice booking

BD = balancing day
 
Purchase invoice:

<---- other liabilities -------- BD <------- expense ----------IB      anticipatory
IB----- expense ---------------> BD ----- prepaid expense ------>      transitory (active)


Sales invoice:

IB------- revenue -------------> BD ----- deferred income ------>      transitory (passive)
<----- other receivables ------- BD <--------- revenue --------IB      anticipatory

Transitory "Accruals and Deferrals" include:
- Disbursements before the balance sheet date, provided that they have a certain expense for a period after this date => Accounting on the asset side (§ 250(1) section 1 HGB), Example: Pre-paid rent or insurance premiums.
- Receipts prior to the balance sheet date, provided that they have a certain income for a period after this date => Accounting on the liability side (§ 250(2) HGB), Example: In advance rental payments received.

Anticipatory "Accruals and Deferrals" is not allowed under the designation "Prepaid expenses" or "Deferred income" (§ 250 HGB / § 5(5) EStG).
They will be referred to as
- Other liabilities: Expenses of the fiscal year, which occurred after the balance sheet date disbursements lead. Example: still paying rent.
- Other receivables: Revenues of the fiscal year, which occurred after the balance sheet date receipts lead. Example: outstanding interest of a customer.

Summery:

	accruals	deferrals
transitory	prepaid expenses	deferred income
anticipatory	other liabilities	other receivables

Examples

"Aktiver Rechnungsabgrenzungsposten" = prepaid expenses

see above "Justification" and "User Goals"

"Passiver Rechnungsabgrenzungsposten" = deferred income

A tenant pays the rent of 4.000 for october 2009 to january 2010 on the 1.10.2009

The accountant books (according to the accruals and deferrals plan and the example in "User Goals"):

In 10/2009:
dr: bank 4000
cr: revenues for rent 4000

In 10/2009:
dr: revenues for rent 3000
cr: deferred income 3000

In 11/2009:
dr: deferred income 1000
cr: revenues for rent 1000
In 12/2009:
dr: deferred income 1000
cr: revenues for rent 1000
In 1/2010:
dr: deferred income 1000
cr: revenues for rent 1000

"Sonstige Verbindlichkeiten" = other liabilities

In March 2009 an invoice is received from a lecturer. He charge the lecturs from Oct. 2008 to March 2009. The total amount is 720.00

In 2008 the attendant has no information about the amount of this invoice or the expenses invoiced for the current year. So he is not able to book an accrual.

The accountant books (according to the accruals and deferrals plan):

In 10/2008:
dr: expense for lecturers 120
cr: other liabilities 120
In 11/2008:
dr: expense for lecturers 120
cr: other liabilities 120
In 12/2008:
dr: expense for lecturers 120
cr: other liabilities 120

In starting period of 2009:
dr: other liabilities 360
cr: liabilities of the BP 360

In 01/2009:
dr: expense for lecturers 120
cr: liabilities of the BP 120
In 02/2009:
dr: expense for lecturers 120
cr: liabilities of the BP 120
In 03/2009:
dr: expense for lecturers 120
cr: liabilities of the BP 120

If only the end period of 2008 is open, the accountant books
In end period of 2008:
dr: expense for lecturers 360
cr: other liabilities 360
instead of the first 3 entries

If all periods of 2008 are closed, he must book the total amount in 2009
In current period of 2009:
dr: Out of period expenses 360
cr: liabilities of the BP 360
instead of the first 3 entries and we don't need the 4. entry from above

"Sonstige Forderungen" = other receivables

An income of interest for 2008 about 1.300 ins received late on 15. January 2009.

The accountant books (no invoice was booked):

In end period of 2008:
dr: other receivables 1300
cr: income of interest 1300

In 1/2009:
dr: bank 1300
cr: other receivables 1300

If all periods of 2008 are closed, he must book the total amount in 2009
In current period of 2009:
dr: bank 1300
cr: out of period revenues 1300
instead of the above entries

If we are booking an invoice to charge somewith in the last year, we will book the account of the BP instead of 'bank'.

Design & Technical consideration

Design consideration

Datasets for invoices (sales + purchase) must include two new fields

"period_from"

"period_to"

The accounting schema must include four new classifications for default accounts:

"DEFAULT_PREPAID_EXPENSE" = "Aktive Rechnungsabgrenzung" = prepaid expenses for incoming (purchase) invoices

"DEFAULT_DEFERRED_INCOME" = "Passive Rechnungsabgrenzung" = deferred income for outgoing (sales) invoices

"DEFAULT_OTHER_RECEIVABLES" = "Sonstige Forderungen" = other receivables

"DEFAULT_OTHER_LIABILITIES" = "Sonstige Verbindlichkeiten" = other liabilities

"DEFAULT_OUT_PERIOD_EXPENSES" = Out of period expenses

"DEFAULT_OUT_PERIOD_REVENUES" = Out of period revenues

>>> In other functional specifications we need more classifications for default accounts

These names are from the current system, feel free to invent new ones ...

The posting process must be enhenced to evaluate the new fields "period_from" and "period_to".

The distribution of the invoice amount is done on a monthly basis.

There are no accruals and deferrals when booking on asset accounts.

In the german balance sheet,

only transitory accruals and deferrals are shown under the heading "Deferred Income " or "Prepaid Expense" accounts.
Anticipatory will be summerized as "Other receivables" or "Other liabilities".

Posting of allocations to multiple schemas must be by transaction date in order for the allocated value to be correctly posted into schemas with different calendars.

Technical constraints

Technical Requirements

Plausibility checks:

"Period from" <= "Period to"
The distance between "Actual period" and "Period from" is 0 or 1. (else => error)
If transitory, the distance between "Period from" and "Period to" could be more then 1 year.
If anticipatory, the distance between "Period from" and "Period to" must be 0 or 1 year. (else => error)

Anticipatory accruals and deferrals are allowed only, if the last (must be a special) period in the last financial year is open for booking. If not, see above in Examples - "Sonstige Verbindlichkeiten" = other liabilities

Transitory accruals and deferrals should be possible, never mind the future periods are created or open.

Calculation on a monthly basis has one technical problem: rounding errors. The correction of these errors must be distributed uniformly over the periods. This is not a trivial task (if calculating with java or c++ doubles). HIS have developed an algorithm and implementation in C++ and they are willing to share this algorithm with us.

Users & business process description

User goals

This feature supports an automatic distribution of an invoice amount, replacing the need for a manual booking.

An example of the manual process that this feature replaces is as follows:

On 18th June, a university receives an invoice of 4,000 EUR for the rental of a university office for the period 1st June to 30 September.

The accounting objective is to spread the expense of the invoice over the four months in order to match:

the timing of the cost recognition
the timing of the actual benefit received (the pleasure of having an office to work in from June to September).

Deferral functionality should therefore allow us to enter the transaction on any appropriate date and then allocate the cost over the appropriate accounting periods.

Soooo....if we were doing this completely manually we would probably do the following:

1. On 18th June (for example) we book the total amount of the invoice as follows:

Dr: Rental expense    4,000
Cr: Accounts Payable  4,000

2. At the same time, we recognize that, of the 4,000EUR, we will recognize only 1,000EUR as an expense in June. We therefore need to reverse 3,000EUR out of the expense account and post it to a prepayment account. This is an asset account in the balance sheet.

Dr: Prepayments: 3,000
Cr: Rental expense.3,000

3. On 1 July, we would recognize the July portion of the rent by posting the following transaction:

Dr: Rental Expense: 1,000
Cr: Prepayments: 1,000

4. On 1 August and 1 September, we would repeat step 3. leaving the balance on the prepayment account as 0.

So, manual transaction entry would give us a transaction structure looking something like this:

What I would expect Openbravo to be able to do during event a) in order to automate this process is allow the user to select the expense line (Dr Rent Expense 4000) and in an area of the header highlighted as “Match cost to periods” the user should be able to enter a “From Period” and a "To Period" (see "User interface change" section below). If a period range is defined for the matching of cost to periods then the system should automatically assign the selected cost to the defined period range.

There should also be an additional "Accruals and Deferrals Plan" tab visible that allows the user to edit the distribution across the selected periods. The default allocation will be linear, so a user needing a linear distribution should not need to access this tab. A user needing a non-linear distribution could, however, enter the tab and change the distribution.

The distribution will be an "Accruals and Deferrals Plan" (along the same lines that Depreciation is currently proposed as a Depreciation Plan in asset management). This allows the distribution to be created for periods that may not yet be open or created in the system.

The "Accruals and Deferrals Plan" should look something like this (subject to normal OB UI design criteria):

If the user wishes to adjust the plan they can do so by editing the values.

Please note that in the initial version the account to be used for deferred costs should be predefined and not editable. In future versions we may wish to allow the selection of a schema and the editing of the account to be used, but this is not in scope in the initial version.

This would result in accounting transactions like this (assuming 4400 is the accounts payable account, 6030 is the expense account, and 1310 is the accrual account):

booking date	year	text	debit	credit	amount
18.06.2009	2009	text	6030	4400	4000.00
18.06.2009	2009	text	1300	6030	3000.00
01.07.2009	2009	text	6030	1300	1000.00
01.08.2009	2009	text	6030	1300	1000.00
01.09.2009	2009	text	6030	1300	1000.00

User Roles and Personas

Accountant: Stamps a paper document (for example a Purchase Invoice) and indicates how that document should be booked, including the periods.

Purchase Administrator: Entering Purchase Invoices into Openbravo using the information on the Booking Control stamp.

Business process diagram

To be added.

Business scenario/s

In brief, the process is as following (using a purchase invoice as an example).

a) Purchase invoice has been received and stamped with the booking control stamp by the Purchasing Administrator.

b) The invoice has been reviewed by the accountant who indicates the expense account that should be booked and the split across finacial periods.

c) The Purchasing Administrator enters the invoice. If the expense account proposed by the system is different from that proposed by the accountant then this must be resolved (manual action) before the document is posted.

d) The Purchasing Administrator posts the transaction and the system returns the reference number according to the sequences described in the requirements document). Accruals and deferrals is done automatically.

e) The Purchasing Administrator writes (manual action) the reference number into the correct box on the booking control stamp on the paper document.

Examples of booking with accruals and deferrals

Definition of cases

ID	Dialog	Booking date	Period from	Period to	Months in period
1A	Purchase	24.09.2009	01.11.2009	30.04.2010	6
1B	Purchase	24.09.2009	01.11.2009	30.04.2012	30
1C	Purchase	24.09.2009	01.01.2010	31.03.2011	15
1D	Purchase	24.04.2010	01.11.2009	30.04.2010	6
1E	Purchase	24.04.2010	01.11.2009	31.12.2009	2
2A	Sales	24.09.2009	01.11.2009	30.04.2010	6
2B	Sales	24.09.2009	01.11.2009	30.04.2012	30
2C	Sales	24.09.2009	01.01.2010	31.03.2011	15
2D	Sales	24.04.2010	01.11.2009	30.04.2010	6
2E	Sales	24.04.2010	01.11.2009	31.12.2009	2

Datasets created by posting function

Accounts involved:

Account for expense: 6030
Account for income : 5310
Account for accruals : 2900
Account for deferrals: 4900
Other receivables: 2495
Other liabilities: 4890
Accounts Receivable: 2400
Accounts Payable: 4400

Total amount on invoice: € 600.00, public sector => no VAT booking

Datasets in G/L after posting:

booking date is the financial period of booking, not the date of doing it manually!

In text you will find the ID and case of transitory (T) or anticipatory (A) This would result in accounting transactions like this (assuming 4400 is the accounts payable account, 6030 is the expense account, and 2900 is the accrual account):

booking date	year	text	debit	credit	amount
24/09/2009	2009	1A (T)	6030	4400	600.00
24/09/2009	2009	1A (T)	2900	6030	600.00
01/11/2009	2009	1A (T)	6030	2900	100.00
01/12/2009	2009	1A (T)	6030	2900	100.00
01/01/2010	2010	1A (T)	6030	2900	100.00
01/02/2010	2010	1A (T)	6030	2900	100.00
01/03/2010	2010	1A (T)	6030	2900	100.00
01/04/2010	2010	1A (T)	6030	2900	100.00

booking date	year	text	debit	credit	amount
24/09/2009	2009	1B (T)	6030	4400	600.00
24/09/2009	2009	1B (T)	2900	6030	600.00
01/11/2009	2009	1B (T)	6030	2900	20.00
01/12/2009	2009	1B (T)	6030	2900	20.00
01/01/2010	2010	1B (T)	6030	2900	20.00
01/02/2010	2010	1B (T)	6030	2900	20.00
and all periods up until
01/04/2012	2010	1B (T)	6030	2900	20.00

booking date	year	text	debit	credit	amount
25/09/09	2009	1C (T)	6030	4400	600
30/09/09	2009	1C (T)	2900	6030	600
01/01/10	2010	1C (T)	6030	2900	40
01/02/10	2010	1C (T)	6030	2900	40
01/03/10	2010	1C (T)	6030	2900	40
01/04/10	2010	1C (T)	6030	2900	40
01/05/10	2010	1C (T)	6030	2900	40
01/06/10	2010	1C (T)	6030	2900	40
01/07/10	2010	1C (T)	6030	2900	40
01/08/10	2010	1C (T)	6030	2900	40
01/09/10	2010	1C (T)	6030	2900	40
01/10/10	2010	1C (T)	6030	2900	40
01/11/10	2010	1C (T)	6030	2900	40
01/12/10	2010	1C (T)	6030	2900	40
01/01/11	2011	1C (T)	6030	2900	40
01/02/11	2011	1C (T)	6030	2900	40
01/03/11	2011	1C (T)	6030	2900	40

Note
The following example does not use a transitory account.

booking date	year	text	debit	credit	amount
25/04/10	2010	1D (A)	6030	4400	600
30/04/10	2010	1D (A)	2900	6030	600
01/11/09	2009	1D (A)	6030	2900	100
01/12/09	2009	1D (A)	6030	2900	100
01/01/10	2010	1D (A)	6030	2900	100
01/02/10	2010	1D (A)	6030	2900	100
01/03/10	2010	1D (A)	6030	2900	100
01/04/10	2010	1D (A)	6030	2900	100

Note
The following example uses a transitory account.

booking date	year	text	debit	credit	amount
25/04/10	2010	1D (A)	6030	4400	600
30/04/10	2010	1D (A)	2900	6030	600
01/11/09	2009	1D (A)	4890	2900	200
01/11/09	2009	1D (A)	6030	4890	100
01/12/09	2009	1D (A)	6030	4890	100
01/01/10	2010	1D (A)	6030	2900	100
01/02/10	2010	1D (A)	6030	2900	100
01/03/10	2010	1D (A)	6030	2900	100
01/04/10	2010	1D (A)	6030	2900	100

Note
The following example does not use a transitory account.

booking date	year	text	debit	credit	amount
25/04/10	2010	1E (A)	6030	4400	600
30/04/10	2010	1E (A)	2900	6030	600
01/11/09	2009	1E (A)	6030	2900	300
01/12/09	2009	1E (A)	6030	2900	300

Note
The following example uses a transitory account.

booking date	year	text	debit	credit	amount
25/04/10	2010	1E (A)	6030	4400	600
30/04/10	2010	1E (A)	4890	6030	600
01/11/09	2009	1E (A)	6030	4890	300
01/12/09	2009	1E (A)	6030	4890	300

booking date	year	text	debit	credit	amount
25/09/09	2009	2A (T)	2400	5310	600
30/09/09	2009	2A (T)	5310	4900	600
01/11/09	2009	2A (T)	4900	5310	100
01/12/09	2009	2A (T)	4900	5310	100
01/01/10	2010	2A (T)	4900	5310	100
01/02/10	2010	2A (T)	4900	5310	100
01/03/10	2010	2A (T)	4900	5310	100
01/04/10	2010	2A (T)	4900	5310	100

booking date	year	text	debit	credit	amount
25/09/09	2009	2B (T)	2400	5310	600
03/09/09	2009	2B (T)	5310	4900	600
01/11/09	2009	2B (T)	4900	5310	20
and for all periods up to
30/04/12	2012	2B (T)	4900	5310	20

booking date	year	text	debit	credit	amount
25/09/09	2009	2C (T)	2400	5310	600
30/09/09	2009	2C (T)	5310	4900	600
01/01/10	2010	2C (T)	4900	5310	40
and for all periods up to
31/03/11	2011	2C (T)	4900	5310	40

booking date	year	text	debit	credit	amount
25/04/10	2010	2D (A)	2400	5310	600
30/04/10	2010	2D (A)	5310	4900	600
01/11/09	2009	2D (A)	4900	5310	100
01/12/09	2009	2D (A)	4900	5310	100
01/01/10	2010	2D (A)	4900	5310	100
01/02/10	2010	2D (A)	4900	5310	100
01/03/10	2010	2D (A)	4900	5310	100
01/04/10	2010	2D (A)	4900	5310	100

Comment
These bookings are also good test cases for the booking control number: in every case each dataset with a different year must have it's own booking control number. E.g. in case 1B the first and second share the same number, the other have their own and different numbers, because they belong to different years. But for the auditor there must be a way to see that these five datasets belongs to the same business process (=> booking the invoice).

Functional Requirements

Configuration

N/A

Persona based scenarios

To be added.

Assumptions & Dependencies

Assumptions

To be added.

Dependencies

To be added.

User interface

New User Interface

The "Accruals and Deferrals Plan" should look something like this (subject to normal OB UI design criteria):

If the user wishes to adjust the plan they can do so by editing the values in the white boxes.

“Number of periods to allocate to” drives the structure of the “Year” table in the lower part of the screen.

The number of “Year” columns is based on the “Allocation from Period” value and the “Number of Periods to Allocate to” value.

In the above example, if the “Number of Periods to Allocate to” value was “8” then I would expect to see periods 6 – 12 in 2009 with 500, and 2010 with a period 1 value of 500.

The number of rows is driven by the number of normal financial periods associated with the schema. Special periods must not be shown.

Last mock-up proposed for the tab design (not all fields might be needed in the final version):

User interface change

All "Invoice" dialogs (purchase, sales) need 2 new fields on the header tab.

Invoice Header mock-up

Financial Period from

Financial Period to

Input on a monthly basis.

Default value for both is the actual period/month.

Free selection with calender buttons.

If 'Period from' and 'Period to' are in different years, accruals and deferrals is done automatically in the posting process.

License

License code desription

Openbravo Public Key

Functionality enabled by the license code

Accruals and Deferrals Function

Discussion items

Open discussion items

Closed discussion items

Checks on the plan
Some checks on the validity of the plan have to be done
1. Amount (grand total amount) has to be fully allocated. This means that the sum of all the amounts of the plan have to be equal to the grand total amount of the invoice.
2. All accounting dates of the plan have to be between From Date and To Date of the of the invoice header.
In order to separate the creation of the plan (which happens before completing the invoice) and the checks, these will be done before posting the plan lines. This way, the user will be allowed to change the plan proposed but will not be able to post any line of the plan if it is not a valid plan (if it does not complies the checks). These checks will be done no matter the lines have been created manually, generated by the process or modified after being generated by the process.
This has to be implemented and is mandatory.
Usability improvement in invoice header
Nowadays one has to make an extra click in order to specify that an invoice needs an AD plan by ticking Accruals and Deferrals check-box (see new user interface). In order to avoid this extra click, the following change is proposed
1. From Date, To Date and AD Type drop-down are ALWAYS visible and NOT mandatory.
2. Let's assume that if From Date AND To Date AND AD Type drop-down are empty, this invoice does not need an AD Plan.
3. If any of those 3 fields has a value, this invoice will require an AD Plan.
4. First check done when creating the plan is ensure that all 3 fields are filled.
5. Then we do the regular checks that are already implemented and we create the AD plan.
This is a should have in order to improve the usability.
FACT_ACCT_RESET external point
External point inserted in the FACT_ACCT_RESET function has to be moved up, before the un-posting and deletion of accounting entries of the invoice start. The logic should be like this
1. FACT_ACCT_RESET function starts.
2. Jump to the external point.
3. If external point returns TRUE (AD lines have being un-posted successfully), FACT_ACCT_RESET performs the deletion of accounting entries.
4. If external point returns FALSE (AD lines have not being un-posted), FACT_ACCT_RESET DOES NOT performs the deletion of accounting entries.
5. This boolean value is stored in the variable v_DeleteFact which is TRUE by default: v_DeleteFact BOOLEAN :=TRUE;
This is a nice to have in order to improve the code.

Background process has to post the AD plan lines
This is not happening now and Raj is debugging it in order to discover why.
Posting of plan lines from AP/AR Credit Memo invoices has to be reversed
This has already being implemented by Raj.

In the example of "Passiver Rechnungsabgrenzungsposten" = deferred income. The deferred income is transitory, so, shouldn't be the payment on 2009? Are the accounts correct? I'd expect for 2009 debit entries the deferred income account instead of the bank, and having just one entry for the bank on the date of the payment, just asking.-- gorkaion 31/07/2009 18:50

I'm sorry, the date for the payment was not correct, should be 1.10.2009 mgerke 08/03/2009 06:23

Yes, you are right. What a crap. I was in a hurry to get my train ... mgerke 08/03/2009 06:48

I'm having doubts on how are we going to manage the special periods of the beginning and end of the year from a technical point of view. gorkaion 31/07/2009 18:50

We need these special periods for othe reasons also (bookings of the auditor etc.) mgerke 08/03/2009 06:48

We need English acronyms for the default accounts "ARA", "PRA",... Richard? gorkaion 31/07/2009 18:50

see in the text. mgerke 08/03/2009 06:48

All accruals and deferrals are done by period? It is not possible to do it by fiscal year? gorkaion 31/07/2009 18:50

That's for Richard. mgerke 08/03/2009 06:48

Technical Requirements, 2th plausible check. I suppose that we are talking about transitory accruals and deferrals, and that with anticipatory ones the same distance has to be checked with Period To. gorkaion 31/07/2009 18:50

If transitory, the starting period could be this year or the next, if anticipatory, the starting period must be the last year, but no more in the past. mgerke 08/03/2009 06:57

Technical Requirements, 4th plausible check. I suppose that the distance can't be more than 1 year but yes shorter. gorkaion 31/07/2009 18:50

Yes you are right, if both periods are in the last year. mgerke 08/03/2009 07:02

Is the table at the end of the User goals section correct? I think that the booking dates are not correct, and neither the last year. gorkaion 31/07/2009 18:50

I will check it after some meetings ... mgerke 08/03/2009 07:02

There was a confusion in the date format. I have changed it now to dd.mm.yyyy. mgerke 08/03/2009 09:15

According to the New User Interface section, the tab designed would have to be a manual window. I suggest to change the design so the window can be generated by wad. We'll have to decide if the Account for allocation is defined in the header or for each allocated period. gorkaion 31/07/2009 19:07

Design changes gorkaion 07/08/2009 10:25

In the Examples of the new New definitions and acronyms and in the Design Consideration is included the case when all periods of previous year are closed including the special one with the default accounts of out of date revenues and expenses. But in the Technical Requirements is set that if all the periods are closed an error has to be raised. gorkaion 03/08/2009 17:50

Thank you for reading the document so attentive. The examples section was written later and the Technical Requirements were not adjusted. Now it's done mgerke 08/04/2009 07:03

The examples of booking with accruals and deferrals have been updated to reflect posting to periods rather than years. However these need to be reviewed by HIS, in particular those examples where a transitory account is used. ...rmorley 03/09/09 17:17 BST

Closed ...rmorley 10/09/09 18:17 BST

New dated on September 3rd:
I raised a clarification on reverse account entry in forge [1] - Thanks suresh

I raised a clarification about Acc & Deff type field in Forge [2] - Thanks suresh

New dated on August 26th:
What should happen in the case an end-user tries to un-post a purchase/sales invoice which has posted deferral lines associated to it.

A posted invoice can't be unposted - it's not possible! In case of a storno there must be a storno-posting and an storno-document. A storno is a posting with reversions in the pre-sign. Anja 26.08.09

28th August: Thanks Anja, can you please add storno scenario to the current Specs so we know exactly how accruals and deferrals feature should work in case of a storno scenario? Thanks, Patricia.

I've added two examples: 1F and 2F Anja 31.08.09

Feedback dated on 20th August: As a general comment, It would help a lot if before each scenario you briefly explain what it is about. It would be also great if you list all the accounting entries (=>accruals or deferrals plan lines) required to be posted, as sometimes this is confusing, please see below.

What do you mean with plan lines? Anja 21.08.09 12:58

1.- Purchase invoices scenarios => Transitory Accruals (=prepaid expenses). Period from <-> Period to >1 year

the period must be beyond one fiscal year, means: one part of the amount belongs to one fiscal year and an other part belongs to another fiscal year Anja, 25.08.09

1A - clear. OK.

1B - not 100% clear. The part I do not understand is the part explained in the Note section which says: "the following transactions need to be corrected to support the posting of the deferred amounts to each period."

both examples of booking 1B do the same, the first on a monthly basis, the second on a yearly basis. I think you can choose how to post. All of the following examples are posted on a yearly basis. Anja 25.08.09

Does "period" mean year (just confirm)?

Period means here the period of the invoice: rent for 6 months Anja 25.08.09

Why use case 1A do not have that particulary (correction particularity)?

it is only an example Anja 25.08.09

Why the correction for 2009 year points to end of the year (31/12/2009) as date but 2010, 2011 and 2012 corrections point to begining of the year (01/Jan)?

they recognize that there is a deferred income while doing the annual financial statements. Anja 25.08.09

it seems to me that this kind of "year" accounting entries are the summary of the monhtly accounting entries per year, is that right? which one do you want in the system, montly ones or year/summary ones?

see above Anja 25.08.09

Last thing: why do we need 2 equal accounting entries dated on 24/09 and 25/09 (debit:6300 - credit:4400 = 600), can you please explain? 25/09 one is after 24/09 debit:2900 - credit 6030 = 600.

see above / 25.04. is a mistake by copying - I've corrected it Anja 25.08.09

1C - not 100% clear. What about monthly accounting entries per 600/15 periods = 40 amount? I guess we do need them, right?

That's booking on a yearly basis. We have to dicuss this theme with Michael. I never would prefer the monthly posting. Anja 25.08.09

1.- Purchase invoices scenarios => Anticipatory Accruals (=Other liabilities). Last period in the last fiscal year open. Period from <-> Period to = 0 or = 1 year.

s.a.

1D - not 100% clear. Why accounting entry dated on 01/01/2010 has 200 as amount and not 400? same doubt as above, regarding montly/summary accounting entries..

it is only the posting for the two month in 2009 Anja 25.08.09

1E - not 100% clear. same doubt as above, regarding montly/summary accounting entries..

s.a.

2.- Sales invoices scenarios=> Transitory Deferrals (=deferred incomes). Period from <-> Period to >1 year

s.a.

2A - not 100% clear. same doubt as above, regarding montly/summary accounting entries..

s.a.

2B - not 100% clear. same doubt as above, regarding montly/summary accounting entries..

s.a.

2C - not 100% clear. same doubt as above, regarding montly/summary accounting entries..

s.a.

2.- Sales invoices scenarios=> Anticipatory Deferrals (=Other receivables).Last period in the last fiscal year open. Period from <-> Period to = 0 or = 1 year.

s.a.

2D - not 100% clear. Account 4900 is not the right one, I guess we should use other receivables account = 2495, right?

yep!

Why accounting entry dated on 01/01/2010 has 200 as amount and not 400? same doubt as above, regarding montly/summary accounting entries..

posting only for the two month in the last year Anja 25.08.09

2E - not 100% clear. Account 4900 is not the right one, I guess we should use other receivables account = 2495, right?

yep!

I'm sorry, the date for the payment was not correct, should be 1.10.2009 mgerke 08/03/2009 06:23

Yes, you are right. What a crap. I was in a hurry to get my train ... mgerke 08/03/2009 06:48

I'm having doubts on how are we going to manage the special periods of the beginning and end of the year from a technical point of view. gorkaion 31/07/2009 18:50

We need these special periods for othe reasons also (bookings of the auditor etc.) mgerke 08/03/2009 06:48

We need English acronyms for the default accounts "ARA", "PRA",... Richard? gorkaion 31/07/2009 18:50

see in the text. mgerke 08/03/2009 06:48

All accruals and deferrals are done by period? It is not possible to do it by fiscal year? gorkaion 31/07/2009 18:50

That's for Richard. mgerke 08/03/2009 06:48

If transitory, the starting period could be this year or the next, if anticipatory, the starting period must be the last year, but no more in the past. mgerke 08/03/2009 06:57

Technical Requirements, 4th plausible check. I suppose that the distance can't be more than 1 year but yes shorter. gorkaion 31/07/2009 18:50

Yes you are right, if both periods are in the last year. mgerke 08/03/2009 07:02

Is the table at the end of the User goals section correct? I think that the booking dates are not correct, and neither the last year. gorkaion 31/07/2009 18:50

I will check it after some meetings ... mgerke 08/03/2009 07:02

There was a confusion in the date format. I have changed it now to dd.mm.yyyy. mgerke 08/03/2009 09:15

Design changes gorkaion 07/08/2009 10:25

Thank you for reading the document so attentive. The examples section was written later and the Technical Requirements were not adjusted. Now it's done mgerke 08/04/2009 07:03

Appendix

N/A

Retrieved from "http://wiki.openbravo.com/wiki/Accruals_Deferrals/Functional_Documentation"

This page has been accessed 1,410 times. This page was last modified on 26 March 2018, at 08:26. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.

Toolbox

PDF Books

Search

Participate

Accruals Deferrals/Functional Documentation

Contents

Overview & Justification

Purpose

Scope

Justification

Normal use of periods

Special use of periods

New definitions and acronyms

Examples

"Aktiver Rechnungsabgrenzungsposten" = prepaid expenses

"Passiver Rechnungsabgrenzungsposten" = deferred income

"Sonstige Verbindlichkeiten" = other liabilities

"Sonstige Forderungen" = other receivables

Design & Technical consideration

Design consideration

Technical constraints

Technical Requirements

Users & business process description

User goals

User Roles and Personas

Business process diagram

Business scenario/s

Examples of booking with accruals and deferrals

Definition of cases

Datasets created by posting function

Functional Requirements

Configuration

Persona based scenarios

Assumptions & Dependencies

Assumptions

Dependencies

User interface

New User Interface

User interface change

License

License code desription

Functionality enabled by the license code

Discussion items

Open discussion items

Closed discussion items

Appendix