1 Topic by Plutoo (edited by Plutoo 01/28/2011 12:05:32 pm)

  • Registered: 01/25/2011
  • Posts: 11

Topic: Call for new development in Banking and General Ledger

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 smile ?

DS

  • Registered: 12/25/2007
  • Posts: 2,448

Re: Call for new development in Banking and General Ledger

While our application is named FrontAccounting, larger part of its functionality should be classified as ERP related rather than strictly accounting. Most of the features does not need any accounting knowledge to be successfully used in everyday activity, but it is naive assumption that any business application could used without any specialized accounting knowledge at all. 

Main FrontAccounting advantage (at least how I see it) is that the real skilled accountant is necessary only at first stage, when all the application is configured, tax system is set and GL parameters for various operation are settled for later use. In properly configured application  all sensitive configuration settings are not accessible for non-skilled persons doing everyday registration job. The same rule applies to generic Journal Entry interface which should be accessible only to guys who know what they are doing (there are always situations, when some more advanced business operation have to be registered manually using knowledge at higher level than common ability to distinguish costs and income).

I can agree with some of your remarks regarding bank payments. Having separate entry points for deposits, payments and transfers is a little unhandy. In fact bank transaction registration is in most cases done using real bank statement in hand, where deposits interlaces with payments and charges, so it would be more convenient to have ability to register batch of various bank transactions in single run.

Regarding 'self learning'  algorithm which would suggest previous postings to be reused, this seems to be in contradiction to the program philosophy described above (accountant configures/everybody uses). (Another problem is effective implementation of such autosuggest  feature, which works well on Google superservers, but average ISP hosting is quite another story. Tried wink).

Finally keep in mind we have  to provide backward compatibility with previous FA versions - this is why some suboptimal  design solutions still exists in FA database scheme (gl_trans structure is one example of this).

Anyway thank you very much for your kind interest in making FrontAccounting even better business solution for SME. While we are all the time short with programming resources, we really appreciate all new ideas and code contributions smile.

Janusz

  • ed10
  • Senior Member
  • Offline
  • From: USA
  • Registered: 08/26/2010
  • Posts: 132

Re: Call for new development in Banking and General Ledger

Regarding autosuggest, you mention it being slow given an ISP.  What is the performance hit if FA is running just on a lan and not thru the internet?  How much longer would the queries take compared hitting enter and scrolling down?  Is the code already in place for autosuggest since you have tested it?  Would it be possible to give the use a choice or using or not using it just like using or not using search?

Thanks,
Ed

  • Registered: 12/25/2007
  • Posts: 2,448

Re: Call for new development in Banking and General Ledger

I have tried a couple of autosuggest solutions some time ago, but none was working smoothly enough to decide to integrate it in FA. Smoothness is necessary in autosuggest - unpredictible delays on every key press is much more distracting  than single delay on searchable list.

Yes, using autosuggest in FA installed on your box should be usable, but when taking into account server random response delays which are normal on shared servers, using it became a pain. I guess FA is used in most cases via internet, so IMO adding it was not worth the time needed for implement it.

But of course if anybody would find acceptable autosuggest solution I see no reason to not include it in FA at least as an option.

Janusz

  • Registered: 01/25/2011
  • Posts: 11

Re: Call for new development in Banking and General Ledger

Thanks, Janusz and Ed for your respond.

Janusz, I can see that you have experience of accounting to a larger degree than I and a clear image of the idea and position of FA. I do not however shear your philosophic view on the  automatic suggestion function, why not see it as part of accountant configures as everything origins there? It is not the accountant that is automatized, it is the running daily registration work that is automatized by the automatic suggestion function. 

As it seems to me, I could a bit ruff summarize your scepsis towards an auto suggest function as concern with the responds time. For main function the automatic suggestion will have the same performance as present Quick entry function. Your concern is as I understood it for the description prediction functionality. 

Generally response time could be improved by “smart” programming ahead. By having an  programming function preparing the result ahead, the respond time could be minimised.
SQL databases are in my experience astonishingly fast, but off course performance can vary in an shared environment. The operation at the time of prediction can as a start be limited to one keyed read to an prediction table. Further the prediction table – if necessary – could be sent to the client prior to registration. The description prediction information does not change significantly under a day or so. This should in my mind give lighting performance.

About the access to the Journal entry, I am not sure that I understand your objection, my point is just that there should – as an option - be only one user interface for registration of transactions, with preferably only one account serie. Different account series is seldom used in Sweden, and rarely in companies that generally would be interested in FA, maybe it is different international.

It is assuring that you are aware of the structural problem in GL tables. In my fast test I already noted that information is lost, and that different persons have made different types of work-arounds to handle this problem, witch sooner or later will lead to new problems. Sooner or later you will have to correct the database, why not make it sooner? If you are concerned about backwards comparability, you could off course have an conversion program that reads the present GL trans table and update the information in the new GL trans tables, as a part of a new release to achieve backward comparability in the database.   

I do not want to abolish specialized accounting knowledge people in companies. My view is also that you need skilled accountant person to initially set up the system. Maybe there is a difference that I can see that mayor part of initiation could be done as standardisation, in the same way as we have standardized accounting charts. Anyhow, in my experience even in large companies, the actual registration of transaction is done by persons without prior qualified economic education or insights in accounting. However they need off course from time to time consult people skilled in accounting and skilled economic people is needed to control the operation of the company. And whatever operation you are trying to automatize you should not expect to get to 100%, if it is at all technical possible, it would likely be economical to expensive.

Please take some time to reflect on my thoughts. I see an automatic accounting suggestion function as an desirable function, that would give high value per work our and without conflict with present FA system or philosophy.

  • Registered: 01/25/2011
  • Posts: 11

Re: Call for new development in Banking and General Ledger

Just want to clarify that there are several technical possibilities available to make the description prediction function fast in an ISP environment, different ways to prepare the auto suggestion in advance. Also even if there should be occasional delays, you do not have to wait for the suggestion. If you are uncertain about the transaction I don't think any reasonable delay would distress you.

Finally even if I have not done tests on ISP, I notice that there are fast development in ISP technology. ISP's offer larger traffic volume, at lower cost. Presently – over here - most ISP seems to have upgraded there server structure so they are independent of individual servers for uptime and performance and they also use several Internet providers on an ISP account. In other words several backup systems both for server and communication that react instantly and distribution of load on an net of servers.