"Allen Browne" wrote:
> I'm not an accountant, but...
[Snip!]
> In a double-entry accounting system, it gets more complex as you close off
> financial periods and start again with an opening balance, designing so that
> no entries in a closed-off period can be altered.
Time for your accounting lesson, Allen. (Grin!)
Just FYI, balance sheet accounts (including accounts receivables) are
"perpetual" accounts that don't "close" at the end of a fiscal period. The
balance at any given time is the balance, whether or not the period is open
or closed. The "ending balance" for one fiscal period is always the "opening
balance" for the next period.
On the other hand, revenue and expense accounts "close" at the end of a
period. The "opening balance" for any period is always zero. On August
31st, I may have "X" dollars in revenues for the August accounting period,
but on September 1st my "balance" of revenues for September starts at zero
again. Of course, one doesn't actually "close" each month (i.e. zero out the
revenue and expense accounts and transfer the net balance to equity). The
actual physical "closing" of revenue and expense accounts only occurs at the
end of a fiscal year.
You are correct in stating that it's not acceptable to alter entries in a
closed-off accounting period. In fact, it's generally not acceptable to
alter *any* transaction. Rather, one should record an "adjusting entry" to
correct an accounting error or reverse a transaction that should never have
been recorded. "Adjusting entries" are "usually" recorded in the current
fiscal period with an appropriate notation documenting which fiscal period
(and transaction) the adjustment applies to.
However, there is *one* exception to the above principle... If the entry
requiring adjustment is "significant" such that failing to correct it in the
same fiscal period misrepresents the financial status of the accounting
entity at that time, then it *is* appropriate to apply a "prior period
adjustment" in a closed fiscal period. Of course, doing so means that the
financial statements for that period (and possibly all other periods up to
the present time) must be "restated" in order that the financial statements
are accurate.
It should be noted that "prior period adjustments" and restatement of the
financial statements are rarely required. And, when this does happen, the
accountant in charge of the financial accounts is usually in pretty hot water
for not catching a significant error before the books were closed.
Anyway, that's your accounting lesson for the day. (Another GRIN!) Now, I
have a question for you...
Assuming that the company's policy is that oldest outstanding balances get
paid off first, irrespective of the wishes of the payor, how would one design
that from a database point of view? My thinking is that you'd merely need a
Yes/No field called "Paid" and a "BalanceDue" field in the A/R table. When
payments are received, an algorithm applies the payment amount starting with
the oldest "BalanceDue" amounts and toggles the "Paid" flag if an invoice is
paid off. This continues until the amount of the payment is exhausted. If
the last "BalanceDue" is not totally paid off, the "Paid" flag is left at
"False" and the "BalanceDue" is reduced to the outstanding amount owing.
Thoughts? Comments?
Thanks for helping to educate me regarding database/systems design!
Regards, Chris
>
> --
> Allen Browne - Microsoft MVP. Perth, Western Australia
> Tips for Access users - http://allenbrowne.com/tips.html
> Reply to group, rather than allenbrowne at mvps dot org.
>
> "Wahab" <(E-Mail Removed)> wrote in message
> news:0CFCA163-FC36-4D1A-8DF6-(E-Mail Removed)...
> >
> > Please help me to sort out this. I have big list of InvoiceNo, InvDate,
> > Amount in CustDue Table, my customers are paying against the invoices, I
> > want to find out bunch of invoice(s) for paid amount. If more
> > possibilities
> > then based on InvDate atleast 3 sets. If I received 40 from following due
> > invoices then which invoices i will mark as paid?
> > InvDate InvoiceNo Amount
> > 01-Jan 1001 10.500
> > 01-Jan 1005 4.500
> > 01-Jan 1050 10.000
> > 05-Feb 1100 15.000
> > 10-Feb 1250 15.000
> > 15-Feb 1500 50.000
> > 18-Feb 1501 15.000
> > 20-Feb 1510 75.000
> > 25-Feb 1518 22.500
> > 03-Mar 1520 17.500
> > 05-Mar 1525 90.000
>
>