Peter Stevens continued on 12-Jul-99 on the same NG:

---

Quote:

Oh dear, Shumie crashed. Oh well...it's an idiotic sport.

The previous post was an attempt to structure the thing more or less as I see it. So, I presume there'll be some responses soon....in the meantime here's something on the modules.

If you want to build something like Quickbooks, a 'quick and easy' system, you still have to grapple with all the user interface issues, accounting rules, and produce a comprehensive working system. People don't buy quickbooks and then buy an Accpac module. They use it to do all their bookeeping tasks. I don't think it would be any less difficult to write a Quickbooks, in fact it would be more difficult.

It would have to be finished with all the 'modules' built in before you could use it. You'd have a whole lot of people sharing one code base. The procedures to complete tasks would be no less difficult to code.

If you create a modular system you can put in only those modules your client requires. You can get experts focusing on each module. You can wrap it up in a system manager shell (which could ultimately have custom menus and task lists, just like Quickbooks, but designed the way your client works).

The system manager could start off as a simple window, perhaps using Ken's custom classes as per the tutorial. As modules get completed they could be added to the shell. You'd probably want to launch an exe for each module though, (don't know what that implies yet)

One discussion we will need to have is which components of the database can be managed by this shell, and which have to remain in the modules. For example, if you do use departments, then you'd want to be able to access them from any module where required.

The shell would manage users and passwords, companies, and a list of installed modules. It would provide info so that each module would know where to find data from other modules.

Each module should be able to work stand alone, or integrated. I'm going to go over Accpac and see how it works. You can buy any one Accpac module, but you have to get the system manager to run it.

Taking the next obvious module, AR, if you use it stand alone you can set up account no's to allocate transactions, or you can look them up in the GL if integrated. Standalone system just print reports in detail or summary form which then get manually captured into another system.

Each module should have an 'export' option so that month end data can be exported to another system.

In Accpac when a month is closed you can optionally consolidate transactions. This will create a unique posting entry for each account in the GL, as opposed to an entry in the GL for each entry in your sub-ledger.

I think we should always consolidate, and just find a good way of getting back to the original entries from the GL. In Accpac 'drill downs' don't exist.

So before we start on the GL we just have to be aware of what implications there will be when consolidating up from the sub-ledgers.

In the GL you should be able to see the following journal entry in a batch:

Dr Accounts Receivable 200,000 (AR Consolidation for July 99)
Cr Sales - Toys 80,000 (AR Consolidation for July 99)
Cr Sales - Hardware 90,000 (AR Consolidation for July 99)
Cr Sales Tax 30,000 (AR Consolidation for July 99)

This entry would have been created when the AR module was closed for the month. Do you agree with this principal?

I refer extensively to a cashbook module. It would work the same way:

Dr Rent Paid
Dr Salaries
Dr Fixed Assets - Cost
Cr Cash

Putting in modules makes the GL very clean and simple.

But if you didn't have all the modules, and you only had a small no. of transactions, there would be nothing stopping you from entering all the transations directly in the GL.

Regards
Peter

---

Peter Stevens posted to NG "dbase.open-source.accounting" of "news.dbase2000.com" the following proposal, on 11-Jul-99:

---

Quote:

The idea is to start off with a general ledger that recognises accounting principles, but allows for various ways of interpreting them.

It's a dBbase system so it must use database and coding techniques that make it more powerful and flexible than other systems.

It must be scalable, allowing one to start off with a mom and pop store, and expand to an additional three tiers if necessary. (The debate on this must be resolved)

The target market is small to medium size businesses. (Medium means quite big, but not IBM and Fortune 500 companies)....(yet!)

Here's how I see the files required:

File - Accounts: A list of accounts
Acno (3 or 4 digits?)
Type (B,R, or I)
Description
Segments: No of segments required for this account. (default value overwritten where required)
RepGrp: Reporting group for this account
Subledger: If the account is a control account you need to know which subledger to go to.

File - Segments:
Seg1Def: A definition of segment/tier 1
Seg2Def: Definition of segment 2
Seg3Def: Definition of segment 3

File - Segment1: A list of departments or cost centres or whatever
SegCode: A code
SegDesc: A description

File - Segment2, as above
File - Segment3, as above

AcctChart: A Chart of accounts built up from combinations of the above. No of segments is number of tiers plus one. Account is the first segment.

Descriptions are not stored here, as each segment of the account no is a separate field whcih links to the descriptions in the accounts and segments/tiers files. (Anyone got a better name for tier/segment?)

In a single level system the chart of accounts is a repeat of the accounts file.

In a multi segment system you could have the following method for setting up the chart:

Copy accounts file to chart of accounts file, with default values for the segments. Allow editing of segments. Allow copying of ranges accounts with another default segment. These get
appended to the chart of accounts. It looks like overkill, but it's only done when you have the need. Most medium size firms have quite a large chart of accounts, and they have to do this anyway. We could put in techniques to speed up the process.

Acctchart structure:
AcNo
Segm1
Segm2
Segm3
Accesslevel
OpenBalCur - Always 0 for 'I' accounts, Last year's closing balance for 'B' and 'R' accounts
OpenBalLY - Last year's opening balances
OpenBalYBL - Year before last's opening balances (allowing for 2 years' history)
Mth1AmtCur..Mth13AmtCur - Net of debits and credits posted to that account for that month in this year
Mth1AmtLY..Mth13AmtLY - Same for last year (13th period for year end adjustments)
Mth1AmtYBL..Mth13AmtYBL - Year before last
Mth1Bud..Mth12Bud - Budgeted figures for the current year
Comment

What else is needed? Let's discuss.

Anyway, once you have your chart of accounts you have to work on entering transactions.

Let's assume it's a batch based system.

File - BatchCtrl: Controls sequential batch no's and whether they've been posted and printed.
BatchNo (Unique)
Posted? (Editing allowed until true)
Printed?
BatchTot (Absolute value)
BatchQty (No of entries in the batch)
Source (more on this later when discussing sub-ledgers, AP, AR etc)
Period (accounting period)

File - Batches:
BatchNo (repeated)
EntryNo (Increment by one starting with 1 for each unique reference)
Reference (Repeated - eg Check no.) (bit of a discussion here)
Account (Picked up from chart of accounts)
Amount (+ for debit, - for credit)
Description (Comment)

In Accpac for Dos, each batch is a separate file. When the batch is posted to the G/L Posting file you can no longer do anything with the
batch, in fact I think it is deleted.

So we need to discuss this issue, because you could have all your batches in one file, or keep them separate. In a one file system your batches _are_ the GL posting file.

When you've finished entering all the batches you close the period. Totals are generated for each account in the chart, and entered in the
correct MthxAmt in the chart.

The easiest part is designing queries and reports once you have your basic system of entering data.

I don't think there's much more to designing the GL, conceptually speaking.

I'm going to post part 2, a discussion on sub-ledgers, (after the F1 Grand-Prix!)

---