I have read about future plans for Frontaccouinting. Several nice intentions but I miss the no 1 development target.
The typical FA user, as I see it, works in a small company or small organisation. The person responsible for the running operation of accounting, that makes the registration of transactions, has often no prior knoll age of accounting. Registration is a part time job that often is viewed as something necessary evil that takes up to much time.
My No 1 development target for Frontaccounting is a simpler user interface.
If I – for simplicity - see FA from the perspective of an small business that uses it mainly for just accounting. FA has four registration pages, Payments, Deposits, Bank account transfer and Journal Entry. These can as a start be replaced by one page and a drop list with the mentioned options. But even the drop list is unnecessary. If you take an simple transaction as Phone it is for most business always an payment transaction, if there should be an risk for misunderstanding one could call it phone payment.
So the different pages – and different number series – could be replaced by one Page, “primary” just containing one field, The Description.
( You do not need to have different transaction types for payments, deposits, bank account transfers and others, one type is sufficient and if you prompt want it, you could add the drop list with transaction type. In Swedish practise the FA type several transaction series, is just used in some large companies. )
The Description is an predictive input search field. That is as you type the description, the system presents a drop list with suggestions. In the Phone case you would likely just type “P” to get Phone at the top of the list. You then off course just click the Phone option from the drop list, next an suggested amount is presented after the description witch you edit or leave as is. After the amount is given the “Journal Entry” page is presented with transaction fields filled out for you to confirm. All done with minimum choices, minimum typing and without the need to now accounts numbers or the difference between credit and debit for the person making the registration.
So, what has happened behind the scene?
The predictive search has been done over
1. The existing made transactions the last - for example - two years, presenting the suggestions in falling order of frequency. The amount suggestion is fetch from the last made transaction.
2. Quick Entry Description. Suggestion and amount is fetched from the quick entry data.
The Journal Entry Page is presented with the amount allocated on transaction rows, after the last made transaction or the Quick Entry data. That is the "allocaton key" is calculated from last made transaction or from Quick Entry data.
Thats it. Easy, clean and simple. If you do not like it you can use the present pages, this function can exist as an parallel option.
Well, if God forbid no suggestion is found in prior transactions or Quick entries you would off course have to manually enter the “Journal Entry” form. Even then the process could be simplified but I save that for the moment, as it is not essential to the work flow.
Something that could occur from time to time is that you want to change savings account in the journal entry page, this I think should be done with a date picker like function, listing all existing saving accounts. An alternative – if this is common - is to tag Description like Phone Pg and Phone Bg (Pg and Bg may be Swedish but it stands for different bank accounts). Same kind of function could be used for changing VAT type, (no problem in Sweden but may be an issue international).
There are also some programming choices to be made, for example if the search list of descriptions should be pre prepared and sent to the client. Description is not stored today in FA's database, so the backward comparability my be an obstacle. The memo_ field – first 30 letters or something - could be presented as description if description data is blank in gl_trans to achieve some backward comparability. An expert user could before start up update memo_ field in existing database in order to get an jump start. But question is if it is stored today, see below remark.
I am looking for someone with programming skills in Front accounting to implement this with. Everyone are off course welcome with views, suggestions and other participation.
PS
Glancing at the database it seems to lack an gl_trans_head table. In a data model, description, trans date, person id, type, type number and dimension belongs to an gl_trans_head, amount and account belongs to gl_trans_row and memo fields occurs on both levels as implemented in FA. For me it is a bit surprising that there are no description field in Journal Entry already. There are an head level memo field that can correspond to an description in Journal, Deposits and Payments, also To the order of in Payment and Name in Deposits can correspond to an description as can description in Quick entries, and so on.
However, despite careful research I have not found that, Name, Order of or Memo head level in Journal is saved anywhere in the database. Quick entry description is saved on all rows in row level memo field, head level memo in Deposits and Payments is saved on the bank account row level memo field.
Maybe someone can enlighten me 
?
DS
