On Periods, Reports, and Cash v. Accrual Accounting

[Dan Means]

No, on the contrary -- I see open source as my future and
salvation......l M$ bought Great Plains and Solomon a couple years
back...the proverbial 500 lb gorrilla of our business - and all the
other little guys I used to sell for are now part of other big
conglomerates like CA...you think M$ are difficult, try dealing with
CA......we're old FoxBase / FoxPro / SBT Accounting system lost
souls....but we've always sold source systems....just made sense to us
that the customer should always be protected...

This is my first real pass at using a LInux box as a daily driver,
although I've had the experience of supporting a bunch of old SCO Xenix
& Unix boxes -  but things are a  lot easier now with the graphical
interfaces than the 80's....

There's a huge number of business in this 5 - 20 user market...literally
thousands of potential consultants, serving hundreds of thousands of
clients... 

So, I see a terrific opportunity -- figuring out how to add flexibility
to the reporting engine, how to "bolt on" additional functionality or
modules...



On Fri, 2003-05-23 at 22:18, Derek Atkins wrote:

> Dan,
> 
> Thank you again for your comments.  I'm glad you like my cash
> v. accrual explanation.  Perhaps that can be pulled into the
> documentation at some point?  I do want to try to hide as much
> as possible from those who want to keep it hidden.  Isn't the
> point of using a program to reduce the amount of work required?
> 
> Actually, there is already a "date entered", which is completely
> invisible, and "date posted", which is the date you see.  But as I've
> shown that's not sufficient; we need a third one, (at least to handle
> cash-accounting).
> 
> And for the record, I do see gnucash as hitting the 1-20-person
> company (from the business side at least).  I hope we don't put you
> out of business. ;)
> 
> -derek
> 
> Dan Means <dkmeans at srsconsulting.net> writes:
> 
> > Sorry -- thout I hit "reply all"...my bad...
> > 
> > Just for reference, I'm coming at this from a slightly different angle
> > -- I've been selling, modifying and supporting commercial accounting
> > applications in that 5 - 20 user "space" the big guys ignore for more
> > years than I should admit......
> > 
> > But the whole "cash vs. accrual" and "date driven" deal is where most of
> > the real people who use these systems get totally lost. The explanation
> > of cash vs. accrual was excellent.
> > 
> > It's extremely common in my world, that the folks who operate accounting
> > systems, are generally not accountants....so this whole transaction /
> > posting date did I close yet? stuff is the bane of my world -- they just
> > don't get it. 
> > 
> > So, at worst there might be 2 dates -- record the date that somebody
> > really recorded the transaction which may or not be equal to the
> > "posting" date -- the date the transaction really occured. (Audit trail
> > don't ya know -- how'd this entry get here?)....then the reporting
> > engine can sort out what's a "closed" year etc.
> > 
> > 
> > 
> > 
> > On Fri, 2003-05-23 at 21:28, Derek Atkins wrote:
> > 
> > > Hi,
> > > 
> > > Thanks for the reply.  It should have gone to the list, so I've
> > > forwarded it there.  In the future please be sure to CC the list
> > > when you reply to messages.
> > > 
> > > And yes, I acknowledge that a "13 period year" is something that we
> > > should handle for end-of-year processing.
> > > 
> > > I'm not at all convinced that date-driven reporting is cleaner, unless
> > > you mean Fiscal-date-driven (in which case I agree).  My point is
> > > that we need some sort of transaction effective-date and search under
> > > THAT date rather than the posted-date.  Yet once we start talking
> > > about effective dates, we might as well talk about Periods.
> > > 
> > > -derek
> > > 
> > > Dan Means <dkmeans at srsconsulting.net> writes:
> > > 
> > > > The period approach is how commercial packages handle this -- you can
> > > > define some number ot annual periods, and then attach a calendar date to
> > > > it. 12 is not always the correct number -- you might want monthly (12),
> > > > quarterly (4), or the infamous 5-4-4 (makes for even quarters even
> > > > though the months are off -- which could also mean 13 accounting periods
> > > > in a year...
> > > > 
> > > > There just needs to be a function that understands the dates.  Most
> > > > packages also have some sort of "adjustment" period -- the place where
> > > > all the year end tax mumbojumbo can be entered, which is not an
> > > > operational in nature, but usually things like depreciation expenses
> > > > etc. for tax returns -- but you have to keep your books in the U.S. the
> > > > same as your taxes....
> > > > 
> > > > But if you could build a reporting engine that just used the periods,
> > > > all would probably be okay, and if you messed up your period definitions
> > > > -- well then you could get odd reports...
> > > > 
> > > > Date driven reporting is usually just cleaner. A balance sheet is a
> > > > snapshot in time -- as of the close of business at a particular day. The
> > > > P&L should be representative of activities over a defined period of
> > > > time, perhaps a month or year. The balance sheet should be able to
> > > > determine the balance for accumulated retained earnings from the P&L
> > > > accounts...
> > > > 
> > > > Most commercial packages use some sort of metaphor for the "Year end
> > > > close" to get clean cutoff for retained earnings vs. current year profit
> > > > or loss...things can get dicey when people decide to "un-close"...or
> > > > change their definition of a fiscal year...which is very common...so
> > > > you'd need to add a "recalc" the period balances if it gets edited..
> > > > 
> > > > 
> > > > 
> > > > -- 
> > > > Dan Means	
> > > > SRS Consulting, Inc.
> > > > www.teamsrs.com
> > 
> > -- 
> > Dan Means	
> > SRS Consulting, Inc.
> > www.teamsrs.com

-- 
Dan Means	
SRS Consulting, Inc.
www.teamsrs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20030523/4a63e82e/attachment.htm