This file is outdated. IT may be deprecated in the future.


Program Organization and Architecture

The organization of the program centers around the fact that one person or tax entity may have more than one company to control. In addition one person may be controlling more than one tax ID as well. The tax ID information and all businesses, personal, etc… associated with it are kept in a ledger. The program allows for multiple ledgers. Hence, multiple tax IDs are supported.

Each ledger is kept in a separate database in order to keep data manageable and keep tables using standard names, but still providing separate tables for separate entities. The program itself must keep track of certain data and the ledgers share this data. (In version 2, we may give the ability to keep an entity from sharing with the others.) The database will undergo changes so in version_tb we are keeping version to let us know explicitly which version we are working with. A flag that by default is true and is set to false only after the program is installed and setup is never_run.

The next thing the program needs to know is what ledgers it is working with. entity_tb holds the KEY field name and the database_name that the ledger is stored in. Both fields are unique. Cannot have two pointers to the same database.

account_tb holds the names of all the ledger accounts that the system uses. Unfortunately, all ledgers will see all accounts when working with them but that is the way the system is written in order to keep things synchronized. In most cases this is a good thing. Each account is a label that explains what assets, liabilities, and equity, are and how they are being used. Obvious… name. Though the name can be changed, number will be user specified upon creation of a new account and cannot be changed. type is required so that accounts can be grouped correctly and to check that assets always equal liabilities + equity. Once created an account cannot be deleted if the required field is true. In order to delete an account the program must first search though every debitcredit_tb in every ledger to make sure that it is not being used. If so, then the account cannot be deleted.

acct_type_tb contains the types of accounts the system knows about. num is used as the key field and for lookup of a name. To aid in determining how debits and credits affect accounts, each type keeps a debit_increases field that if true, indicates that a debit to the account increases it and a credit decreases it. In the accounting trade, the standard is that the first_digit of the account number is descriptive of its type. The list goes as follows: 1 for assets, 2 for liabilities, 3 for equity, 4 for revenues, 5 for expenses. This system contains more types than this but that is only because these standard types are being broken down even further. The same convention is being used for first_digit. The types are differentiated by different numbers, which is the key in the type table.

sub_acc_tb is where subsidiary ledger accounts are stored. Each ledger account can be a subsidiary ledger (this is simply a naming convention; this does not mean that the account gets special treatment) by sorting its entries into sub accounts. sub_acc_name and sub_acc_number are obvious again. These are not unique to the system. They are only unique to a parent account. When creating a new sub_account, the system should not let the user create two sub_accounts with the same name under the same parent. Lastly, parent is the parent account that a sub account points to. The same sub accounts are sometimes duplicated under different parents.

The system has the ability to remind a user at login of specified tasks. current_reminder_tb holds the data in description and the date in date_of of the reminders which have come due. reminder_tb holds the reminders themselves within each ledger. A reminder can recur if the recur field is not zero. description describes. X_days_b4 tells how many days before the reminder is critical to post it to the current reminders. orig_date is the original critical date of the reminder and the only date if the reminder does not recur. nextdate is the calculated field for the next time the reminder is to be posted. This should be calculated by using the periodic functions that are also being used for payroll calculations. module should point to a script or something to let the user go directly to where he/she can perform the task needed. If recur = 0 then the reminder can be removed after being posted to the current table. If recur < 0 then the next date will need to be calculated based on the period and the current date. Else the reminder should be posted accordingly and the next date field should be set to current date plus recur days.

business_type_tb is little more than a label in this version. name, default values are sole proprietor, partnership, limited liability company, corporation. num, values are arbitrary.

Ledgers are organized with a couple tables that contain descriptive information. ledger_tb contains the name of the ledger as well as the ledger code and color. The program will need to know if the entity is on cash_or_accrual basis, business_type, and fiscal year month, fy_mo, and day, fy_day.

variables_tb will keep track of certain data that are constantly changing based on what the user is doing. The user will have the ability to work with specific years in the ledger. The default should be the last one used, but when the ledger is opened the working year should be compared to the current data and the user asked to close out the books. This is optional and the user can say no and do it later. Manually or next time prompted. When the user wants to edit a different year the working_fy is set to that year. ss_cap, ss_rate, med_cap, med_rate, futa_cap, futa_rate, suta_cap, and suta_rate are also set to the tax rates in the tax_tb.

Closing Out is the process by which the entity resets its ledger for the next tax year. The program will perform some of the functionality needed for this process automatically. The first thing to do is to generate a temporary income summary account by debiting each revenue account by its current balance (making it zero), crediting this to income summary, crediting each expense account (not depreciation) with its current balance, and debiting that to income summary. Whichever balance income summary has, debit or credit, post the same to retained earnings, and do the opposite to income summary. If this were a corporation that paid dividends, dividend expense accounts would also have to be zeroed out and transferred to retained earnings. ( Note: The income summary account is not real or necessary. The calculations can just be done so that retained earnings gets debited or credited with the proper figure.) Closing out should be available at any time with an explanation of what it is. The program should note the working year when it opens a ledger and compare it to the current year. If they differ by one year, offer to automatically close the books for last year. If they are more than one year different, give a warning and open to the earlier year. known_yr_tb contains the years that have been edited out. closed is set to true when a year is closed out. When a user goes back to a different year we must check to see if they make changes, if so then closed out flag needs to be reset to false and a warning given.

In whatever system the program is running in, there should be a module that cleans up the database and checks to make sure everything is ok. When no one else is on, the database needs to be checked to make sure there are no empty records. Any record with only a reference number should be removed. Every record should have a date, but some of the other fields are optional. Also, the program should check to make sure the balance_tb contains the correct balances by starting at the beginning of them and running through all the transactions for each account.

sub_entity_tb is to store the name and code of each sub entity that the ledger contains. The codes may pertain to different departments that the ledger contains or could even be different companies.

acct_bal_tb keep the balances of accounts in balance. acct_num is the account number and the date is stored in bal_date. This table is necessary to hasten the calculation of account balances and to enter account beginning balances. Instead of looking through every transaction the system contains, the program can find the last balance in the table and then calculates from there.

local_accounts_tb filters the global accounts so that only locally used accounts show up, links the sub entities with the accounts, and tracks which are taxable/tax deductible. For each account (acct_num) there is a default entry made when the account is used by the ledger. If the user assigns the account to a sub entity then an entry for each sub entity-account pair is made. Each entry contains the field taxable that, if true, means this account should be included on the tax/tax deductible reports.

Data Entry and Storage

In this system all data is stored in a set of tables that make up a journal. The user interfaces directly with a journal or a front-end interface that automatically updates the database and therefore is reflected in the journal tables. The tables used are described here with explanations for the fields.

journal_tb stores the names of the journals. A user can create new journals because the codes are merely filters to the data that are stored in the tables. Journal codes are used to group types of transactions.

journal_entry_tb is where the first half of a transaction is stored. In order to keep the transactions unique and to be able to reference one, a KEY, ref_num, is kept. This key is automatically generated by the system when entering a transaction into the database. When a user starts to enter a transaction, the next available ref_num is calculated and displayed. When the user submits the transaction, the system checks and recalculates the number until an available one is reached. After 50 tries the system should give an error if it could not find an available number and should set the number to the last one tried and let the user try again if so desired. journal_code is used as a filter and is looked up in journal_tb. The date is stored in trans_date. Most transactions will be checks and deposits and will need to be labeled as such. This will be accomplished by typing in payee_payer which could also be used for a description but that goes in memo.

The second half of the transaction is variable in size and so must be stored in a different table, debitcredit_tb, with reference, parent_num, to the unique ref_num KEY in the first table. Each debit and credit in the transaction pertains to an account, account_num, in the ledger, but this system also allows each to be labeled with a sub entity code, sub_e_code, in order to break them down further. As stated before, each account can label postings as sub accounts with sub_account_num. The amount of the posting is in amount. Each entry must be a debit or credit. If dorc is true then it is a debit, false means a credit. To assist with bank reconciliations, a cleared field is kept. If it is set to 'y', this posting has cleared the bank. 'n' means that it has not cleared and an 'r' means that the entry has been reconciled to the bank statement. counter will be used to identify the individual debits and credits in the group that has the same parent_num.

The java applet will read in a transaction from the database on an edit. It will then find all entries in debitcredit_tb that contain parent_num equal to the transaction number. As it reads each one it will store the counter so that it can properly update when finished. If a new debit or credit is added to the transaction, the counter should be set to –1. When the transaction is updated in the database, all but the –1 entries should be updated. These entries must be inserted with the counter incremented for each one starting with 1 higher than the highest entry in the table.

The html interface can be used to do all data entry. There will also be the option to enter through a java applet. If html only is used then a form with all blank entry fields will open for a new entry. Submit will validate and enter the data then bring up a new form. If this is an edit then the fields will be filled in with the data from the proper journal reference number. Submit will validate and update the record and revert back to the journal view.

In the Java interface there is only one button (Enter). The user types into an edit field with a drop down list. The item in the list that matches what the user has typed so far should be selected and displayed while still allowing the user to continue typing. As the user tabs off of the entry field, if the user has typed something different than what is in the list, nothing happens, but if the item in the field matches a remembered transaction payer_payee, then all data from that transaction should be filled into the entry fields with the exception of the ref_num and date. The user remembers a transaction by checking the remember option in the edit/entry applet.

Similar to the above feature in Java, the user should also be less burdened when entering account info. Both the account name and account number entry locations will be displayed. Both should contain a listing of the possible entries to lookup and match as the user enters into one of them. As the user enters, the item in the list that matches what the user has typed so far should be selected and displayed, still allowing the user to type. As the user tabs off of the entry field, if the user has typed something that is not in the global account list, the program should ask about creating a new account, but if the item in the field matches an existing account, the other account entry field, whether name or number should be updated to match. One more thing, if the user chooses a bank account, then the sub account name is skipped and in the sub account number box will be put a c for check, d for deposit, e for electronic transfer, or b for bank charge. The appropriate debit or credit column should be disallowed since deposits can only be debited and checks can only be credited. If that is not the case the sub accounts should be filled the same way as the accounts, with a list that the user can choose from.

If the interface is html then the sub entity and account fields should be drop down lists and the sub account should be an edit field.

known_years_tb keeps track of which years a user has closed out. When data is entered for a specific year that year is entered into year and closed is set to false. When the year is closed out, closed is set to true. Since closing out calculates balances and those balances are used for other years, it is important to know if a year which was closed out has changed. If this is so then the closed flag needs to be changed from true to false. Change the working year by clicking that link and the program will enter the year into variables_tb. When the user enters data for that year the program automatically enters the closed flag in known_years_tb as false.


Investment

//see investments.html


Assets

Asset valuation is very similar to investments because investments are assets. The main reason for keeping them separate is because assets generally depreciate and investment in particular should appreciate (if you're any good at investing).

To purchase an asset, just transfer money to an asset account and label the sub account of the transaction with a number that corresponds to a particular asset or group of assets.

D C___

Cash Y |

Asset Acct – Sub Acc | Y

When selling the assets the entry should look like this to properly show capital gains/losses for the year.

D C___

Cash X |

Asset Acct – Sub Acc | Y

Capital G/L– Sub Acc | X – Y

or D C___

Cash X |

Asset Acct – Sub Acc | Y

Capital G/L– Sub Acc Y-X |

Note: there should probably be an automated front end to the sale of assets.

The user has the option to create a different account for each asset or group many assets into one account and divide them up using sub accounts.

When an asset depreciates, a depreciation expense account is affected as well as the accumulated depreciation account. The entry looks like this:

D C___

Depreciation Y |

Accum Depr – Sub Acc | Y

Depreciation schedules can be setup so the program knows what to expect and can automatically update the correct accounts. These schedules will also be used in the budget feature. A depreciation schedule is the expected amount of depreciation and when each expense should happen. Very similar to a loan amortization schedule that one gets for payments on a loan. (may want to implement that in the future)

The format of the schedule should be tabular. Date, Amount. Heading = Account, sub account. This also makes for easy entry into a database table. dep_sched_tb account, sub account, date, amount. A schedule is calculated in a couple of different ways. This program will support 2 different calculations: straight-line and declining balance. The formula for straight-line is (cost – salvage value)/life of asset. The life of the asset will determine when and how often the depreciation expenses are posted. The unit of the life will be in months, quarters, half years, or years. (Note: we made need some date functions to schedule stuff like this and can be used in the reminders module. And the billing module)

The other method is declining balance. The first step is to take 1/(life of asset). Use this percentage to calculate the depreciation by multiplying it by the book value of the asset. Book value is Cost – Accumulated Depreciation. If the expense + accumulated depreciation > cost – salvage value, then the expense can only be the maximum of (cost – salvage – accumulated depr, or 0)

Asset_tb stores information about assets. The salvage_price is the amount of money expected when the asset is sold at the end of its useful life. If the asset belongs to a particular sub entity it is in sub_e.


Budget

A budget should be stored in a tab delimited text file and should have a header row. The screen shots are fairly adequate in determining layout. The budget will be created based on user input. Empty or from an earlier period. The user can specify to budget by month, qtr, etc…


Billing

Invoices will be kept to track bills. invoice_tb will keep the header information for an invoice. The system will automatically generate an invoice number based on the last invoice. Each will be unique so the field invoice is the KEY. The client being billed is referred to in client_num. The period for which this bill is pertaining starts in start_period and ends in end_period. statement contains the date the bill was created (and hopefully printed). The date the next payment is due and when that payment becomes delinquent are in the last two.

invoice_items_tb contains the variable number of items that make up the invoice. Each item refers to the parent invoice. A description is stored along with the cost, amount, for that description. The quantity is how many of that item are being billed for.

To make it easier to bill large groups of clients without having to create each invoice by hand billing_tb can be used. A basic invoice must first be created that this billing group will have something to bill. An invoice number will be reserved for the invoice items in base_invoice and the group2bill points to the group table. group_tb can be used to look up all the correct clients to be billed and create an invoice for each one. These billing groups are often repeated and period stores how often. Like with reminders the next_date is calculated based on period and the original date which is on the invoice. If the client does not pay by the delinquent date, a late_fee will be added to the next invoice. The user can edit the invoice and take this off if needed. The layout of the invoice is referred to by form.

As stated before group_tb is used to lookup which clients are in a group. num being the key field is the referring lookup value. name is simply a name for the group.

client_group_tb links the groups to the clients. Each entry contains a group_num and a client_num.

client_tb stores info about the clients such as the corresponding sub account number each client receives in client_num. First name in fname and last name in lname text. Middle initials can be placed in fname. The address of the client may have two lines. address1, address2 Obvious…city, state, zip


Payroll

The purpose of this module is to aid in tax calculations for payroll payments. The employees will also have to claim tips if you are in that type of business. The tips table is used for this. Since the user for Ruppert accounting does not need this feature it will be implemented in version 2. employee_tb keeps track of the name of the employee as well as social security number, ssn. Each employee is given a sub_acct_num to identify payments and withholdings pertaining to that employee. The employee’s wage is stored in units of wage_unit. These units are looked up in wage_unit_tb. Other important data address1,

address2, city, state, zip, phone, hired, severed. If the employee has tips to report it can be done though the time sheet module to be completed in ver. 2. tips_tb with empl_id, job, tips.

Also time_sheet_tb keeps track of the actual hours worked by employees. empl_id keeps track of the employee id and links it to a job_num and task_num. The date (when), when_start, and when_stop keep the times and date.

Job_tb

task_tb

payrate_tb

Name text

name text

empl_id text

Client int

num int

job_num int

Num int KEY

parent_job_num int

wage float

Billrate


wage_unit int






Reports

Most reports are fairly complex. When a report is generated in print view, it should be opened in a new window. The window should be titled the same as the report.

It would be nice to have the option to treat a set of sub entities as one sub entity for reports.

Each type of account will be hard-coded into certain places on reports

Taxes

Over and Underpayments from prior quarters. How would you know? Because you corrected stuff and then the payments will show up as too much or too little and the tax calculations will reflect that. The reports must remember to look at year to date. There will be a tax_loss_tb that keeps track of tax losses in order to carry them forward to a new year. year, amount, account, sub_acc


Archive

When a user wants to archive data, the data between the specified dates should be saved to a file. This is a static file that cannot be added to or deleted from. It can only be recreated. If the user wants to import that data back in, they will use the import feature and tell it where the file containing the data is.

The archive option will also have the ability to remove the data after archiving it. NOTE: Memorized transactions will not be removed from the database.


Misc

Inactive accounts will not show up in ledger account lists, but are not restricted from use. If a user edits a transaction containing an inactive account or types one in manually, then a warning should be given that the account is inactive and continue.

Java Plug in control Panel

Cache jars in memory should be selected.


Tests

Compile statement of cash flows using income statement and balance sheet

Compare to directly calculated from raw data cash flow


2B Dealt with

Shorb formats

Tax table generation etc..


Copyright (c) 2001 HLR
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1; A copy of the license is available at http://www.gnu.org/licenses/licenses.html#FDL.

Updated: $Id: notes.html,v 1.1.1.1 2001/08/09 19:02:33 moreejt Exp $