There needs to be multiple views for entering data. This technology might be good for payee fields JS Combo Box

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.

[ Bank Account drop down | \/ ]
 | 4777 |
Ledger Date
|_______________|
Pay to the order of |______________________________________________________|
$|_______________|
 two hundred million dom changed text field------------------------------------------------------------------------  DOLLARS
Memo |_edit field                                                                                        |  Rem[ ]
Sub Entity [________| \/ ]


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.

[ Bank Account drop down | \/ ]         Deposit# | 200 |
Date |_______________|
Description |______________________________________________________________| [ ] Rem.
Ledger
$|_______________|
Memo |_edit field                                                                                             |
Sub Entity [______| \/ ]

Account
SubAccount Amount SubE Comment
|____     _|\/] [____________|\/] [____22______| [___|\/] | edit field                  |
X
 

This view is not very different from the check except that the amount on a deposit is a debit into the bank account and the Amounts on the lower table are credits if positive and debits if negative.

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 Deposit will automatically use CSR for the journal code

Transfer View

Ex.

Ledger
Date |___________|  Description |______________________________________________________________|
Memo |_edit field                                                                                             |  Rem [ ]

Account SubAccount Amount SubE Comment
[____________|\/] [__________|\/] |____2.22_| [___|\/] | edit field                  | X
[____________|\/] [__________|\/] |____2.22_| [___|\/] | edit field                  |
X

Only Bank accounts should show up in the Account Fields which of course affects the sub account fields.
When the first row amount is filled in onChange should automatically change the second row.  There should always be an empty row at the bottom for the user to add more data.  Start with two or three rows; play design with design ideas here.

If someone needs to transfer between other types of accounts they can use the DE view.

The transfer view will use TX for the journal code

Credit Purchases

The Credit Purchases (CDP journal) will be similar to a check but will have Liability accounts.

Ex.
Ledger

[ Liability Account drop down | \/ ] Date |_______________|
Pay to the order of |______________________________________________________|
$|_______________|
 two hundred million dom changed text field------------------------------------------------------------------------  DOLLARS
Memo |_edit field                                                                                        |  Rem[ ]
Sub Entity [________| \/ ]


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


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 $