Check
view
The screen should like like a check with the opposing (double) entries
underneath. The Bank Accounts are listed in a drop down box in
the
lower left corner above the memo. These are all edit
fields: check number, Payee, Amount, Memo. The Date is a
Portal Date Widget. The text version of the amount will be
generated on the fly (amount.onChange).
Ex.
|
Account | SubAccount | Amount |
SubE | Comment | |
[____________|\/] | [__________|\/] | |____2.22_| | [___|\/] | | edit
field
| |
X |
For the first version of this view all
of these fields will stay editable--unless someone can come up with
better ideas. A future version might leave
all of this as text and the user will click on a column heading to edit
the rows in only that column or click on a row to edit only that
row. The last row in the set will always be empty and editable to
allow the user to continue adding more rows. When the user fills
in both an Account and Amount, a new row is created.
The fonts should probably be smaller
than normal and the style should be flat instead of 3d. We need
to conserve as much screen space as possible. We need to start
using styles throughout the entire app.
The amount on a check is a credit into
the bank account and the
Amounts on the lower table are debits if positive and credits if
negative.
There will be a default Bank Account
that will be automatically set in the drop down. Of course the
check number will be the next available check for that account.
In this view each Account, Sub Account
pair will automatically fill in
the amount on a subAccount.onChange. This means a big internal
storage
will be kept with said data.
The Check view will set the Journal code to CP (cash purchases) When a transaction is editing, the Journal code can identify which view to use.
If there are NO sub Entities created,
then SubEntity.onEnter() should place the focus in the next column.
Clicking on the X will delete the
row. If there are 0 rows then create a blank one.
Recalled
Data: When the user chooses a Payee, Remembered and
Recalled Data will be filled into the screen. Obviously we
do NOT want to submit to the back end for this lengthy
process.
When there is only one row in the bottom
table, then the onChange event for Amount in the check should also
change the one row amount.
Sub Entity columns should not show
unless SubEs are defined.
Deposit
View
This view will allow the User to make deposits.
Ex.
|
Account |
SubAccount | Amount | SubE | Comment | |
|____ _|\/] | [____________|\/] | [____22______| | [___|\/] | | edit
field
| |
X |
Ex.
|
Account | SubAccount | Amount | SubE | Comment | |
[____________|\/] | [__________|\/] | |____2.22_| | [___|\/] | | edit field | | X |
[____________|\/] | [__________|\/] | |____2.22_| | [___|\/] | | edit
field
| |
X |
Ex.
Ledger
|
Account | SubAccount | Amount |
SubE | Comment | |
[____________|\/] | [__________|\/] | |____2.22_| | [___|\/] | | edit
field
| |
X |
Credit Receipts
The Credit Receipts (uses CDR journal) dont make sense.
This is probably better served as a Sales entry.
Double Entry
This view will be the traditional Debit/Credit view. Any
other view can actually be expressed as this view. They should
each have a button that allows them to be displayed as the DE
view. Use a Refresh or something.
We should try to reuse js code as much as possible. Each of
these views has the ability to add a new row. We should have a
function called addRow(double|check|deposit|transfer) which calls the
appropriate sub functions to do the actual work. This allows
all screens to use the same API for adding rows. Most of the
views have the same row layout. The double entry view is
different because it requires both a debit and a credit field.
In the case of deleting a row we can simply walk the rows from the
current one setting this row's entries equal to the next row's
entries. When on the last row, set them all to empty.
Data: The
selectable and recall data should NOT require a submit to the
backend. To facilitate this all data must be sent to the
client. The types of data to be sent are:
XML for export makes sense
for recall data . . . in fact, xml make
sense for most data. The js code must dynamically generate the
sub
account array--why not the account and subEntity arrays at
onload? The italics in
the above list will come from xml.
Beggining
Balances
an additional state that allows the creation of Initial Balance entries into the Journal Entry tables in the database
this state will generate an equity account line
this line will be used to store and display the updated calculated values for balancing the entries on the page
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: Journal.html,v 1.1.1.1 2001/08/09 19:02:21 moreejt Exp $