[Advacs-discuss] Prepayments

[Helmut Wollmersdorfer]

Oliver Elphick wrote:
> On Tue, 2004-08-31 at 13:32, Helmut Wollmersdorfer wrote:
> 
>>Oliver Elphick wrote:
>>
>>>   I think that control
>>>accounts need an extra flag to say whether balances on different
>>>accounts should be netted off or should be accumulated into separate
>>>debit and credit totals.  In the GL schema, this flag belongs on the
>>>ctrl_ac_type table.)
>>
>>I think, that this can be solved by two different control accounts for 
>>the sales ledger:
>>- customer accounts with debit balance go to "customer" control account, and
>>- customer accounts with credit balance go to "prepayment" control account

> The control account entry is an attribute of the individual posting line
> (at least in the current design) and you cannot have that switching
> according to thecurrent account balance.

Then the method will be to post prepayments to an prepayment account
       bank, customer, prepayment control
and normal payments to customer control
       bank, customer, customer control

right?

> I think it is better to assign
> the control account to 2 general ledger subheadings and have a flag to
> say that individual accounts under a control account cannot have their
> balances aggregated.  

But sum of customer balances must equal sum of grouped control accounts.

>>>An accrual of this type can be regarded as an ephemeral journal entry -
>>>it applies at the period end and is automatically reversed the next day.

>>O.k. This is another possibility to manage prepayments correctly. Maybe 
>>this is a more convenient method.

> I always found it so.

It's a typical example, that different cultures should exchange 
experiences and methods.

>>What I have in mind are such typical contracts as I know them from 
>>building and construction:
[...]
>>This means:
>>- prepayments
>>- accrual of earnings (e.g. accruals for expected cash discounts)
>>- accrual of expenditures
>>- work in progress
>>- discounting of long term receivable open items (e.g. quality deposits)
>>- bank guaranties as "eventual liability" in the financial report
>>
>>Discounting of long terms can be an extra module (or script, plug in, 
>>etc.), as this usually results in a list, where you only need to enter a 
>>simple transaction with the sum, and reverse it in the next period.
>>
>>But all other things of the work flow should be supported in daily business.

> This requires a separate projects module; it is too much detail for
> companies that are merely buying and selling goods.  We should try to
> separate detailed requirements like that out from the standard modules,
> so that they don't cause confusion to people who neither need nor
> understand them.

Don't be afraid. With your method of accruals and control accounts the 
above will be easy for a skilled accountant. Your design seems to avoid 
the pitfalls and restrictions (and necessary work-arounds) of 
german-style ledgers.

I only try to apply more complex cases to the design. In my opion and 
experience the core architecture is the most important thing for the 
success of software developement. It should be as abstract and easy as 
possible to cover all possible cases without restrictions. I think, we 
are very near to the 3rd stage = easy, and left out most of the 
preceding stages (1st = primitive, 2nd = complex). SQL-Ledger did it the 
hard way, beginning with only one business model in mind, the small box 
moving company which sells from stock, "fire & forget". They experienced 
incremental requirements and hard redesigns in the last two years and 
seem to be somewhere in the stage "complex".

>>In this case the Tax-Offices work like a bank, but no real payment happens.

> I can't imagine HM Customs & Excise being willing to undertake any such
> thing!

They are not willing here too - but they must, because it is law.
Companies also dislike to receive money from customers in this way, 
because it receives very late, and you do not see on the 
tax-account-statement from which customer this money comes.
Sometimes this needs some hours of investigation.

[...]

> So we have:
> 
>    person  ........................... addresses
>      |
>      +-------------+
>      |             |
>   customer      supplier

Yes, if person is defined as

       a legal personality with an external relationship to our company.
       SAP uses the term "partner". In the ledger of the Austrian
       government they use the term "person account"[1].
       In the scope of a ledger an external relationship is everything,
       where money, service, goods and rights cross the border of the
       company.
       Persons that need extra accounts can be in the role of
       - customer
       - supplier
       - employee
       - bank
       - others (e.g. governmental bodies, which robb or spend money)
       - share holder
       - member of the board

       I define this for avoidance of doubts, because most ledgers let
       you only define customers, suppliers and general accounts. And
       general accounts usually cannot have address attributes, bank
       account etc. And usually open items can only be applied to person
       accounts.

[1] They do not distinguish between customers, suppliers and other 
persons. The general transaction entry looks like this:

text, document reference, phase[2] from, to, account1[3], account2,
      cost-center, cost-unit, person-account[4], unit[5], tax-code,
      currency, amount

[2] phase accounting is double entry and reflects the legal state of a 
transaction, 0 = budget, 1 = monthly budget, 2 = order, 3 = delivery, 4 
= invoice, 5 = payment, e.g. a cash purchase is phase 2 -> 5.

[3] accounts have hierarchical numbers, which includes departement logic 
like control accounts on certain levels.

[4] As you see, there are additionally to the person account the _two_ 
accounts - account1 and account2, one of them is a control account.

[5] Units are for stock and material accounting.

Helmut Wollmersdorfer