I have found and fixed the problem..
It's not to do with Ajax & Session...
Rather the gl_closing_date in the sys_prefs table had got miss set (how I have no idea) to the end of an open fiscal year. This thoroughly confused the system. Having edited the database to set this back to the end of the last "closed year" everything worked OK again..

Have done some debug.
The problem appears to be with the changing of $_SESSION['supp_trans']->tran_date.
The initial value is todays date (e.g. 30/08/2019) The changed value should be 30/05/2019 - i.e. the previous fiscal year)
The copy_to_trans function changes this date successfully. But when the trans date is picked up and passed to is_date_in_fiscalyear it is the 30/08/2019. This causes the problem - this date isn't in the required previous active fiscal year.

I wonder whether the problem is that the ajax call that submits the purchase invoice is trying to change $_SESSION that was set by the browser making its request. I'm suspecting the two connections don't necessarily share the same session ?? This rest of the check functions check the date format rather than the specific date value for correctness.

Any thoughts?

Hi @Apmuthu.

Thanks.. forgot to mention I had already done that... It still picks up the current date rather than the date in the form as the input for the tests! This must surely be wrong whatever the setting of fiscal year,,

I upgraded to 2.4.6 having operated frontaccounting for a number of years without problems. I now find that the supplier invoice file isn't picking up an altered transaction date.

So for example - current date : 21/08/2019     which is in my tax year started 01/06/2019 to 31/05/2020

Date of transaction I wish to enter 08/05/2019            in my previous tax year 01/06/2018 to 31/05/2019 - set to active

both tax years open - and SA_MULTIFISCALYEARS set enabled.

The transaction entry fails with "The entered date is out of fiscal year or is closed for further data entry."

having added some debug I find that the transaction date being picked up is 21/08/2019 NOT 08/05/2019... which fails the test "correctly" as it isn't in the active year.

I wonder how this problem can be rectified?

Help ??

Thanks in anticipation.


(24 replies, posted in Setup)


Found https://developer.service.hmrc.gov.uk/api-documentation/docs/api/service/vat-api/

The API is fairly simple. There would appear to be 2 issues. One that front accounting needs to have OAuth2 embedded in order to authenticate the HMRC - and the chart of accounts will need to specifically identify those transactions and VAT that relate to other EU countries. So the current Tax Report isn't quite comprehensive enough.


OK. But I think we are looking at different ways of using the software. The date shortcuts you describe don't help in the scenario I'm working with.

If you are looking at results - moving through the financial years - you want to alter the years - but leave the starting day / month and ending day/month the same.

Whilst I imagine that could be provided by sensing the change in year and keeping the day & month values the same - this seems awkward.

Hence the idea about "nicknames" and effectively a pick list of these names. I could imagine that might need to be a separate entry field to ease the programming.

One thing that would make Frontaccounting much easier to use would be the addition of "date shortcuts" via a dropdown when selecting reports - especially if leaping between different periods.

So in the company setup one would be able to create a number of tags - e.g. Start 11/12 and a corresponding date e.g. 01/08/2012. When asking for any report  - apart from being able to enter a date - or use the datepicker one would be able to select a "date shortcut". This would make it much easier to drag off reports for say 1 financial year vs year or use standardised dates for certain transactions - e.g. journal entries when doing corrections at the end of a financial period.

Hope this makes sense

Using 2.3.10 there seems to be a bug in entering a new supplier and NOT checking the prices include VAT.

error message : Incorrect integer value: '' for column 'tax_included' at row 1
sql that failed was : UPDATE 1_suppliers SET supp_name='Printed.com', supp_ref='Printed.com', address='Unit 2\nArcot Court\nNelson Road\nCramlington\nNorthumberland\nNE23 1BB', supp_address='', gst_no='621141690', website='www.printed.com', supp_account_no='', bank_account='', credit_limit=0, dimension_id='0', dimension2_id='0', curr_code='GBP', payment_terms='5', payable_account='2100', purchase_account='', payment_discount_account='5000', notes='', tax_group_id='6', tax_included='' WHERE supplier_id = '49'

If the checkbox is ticked - then no problem - but that isn't good if the suppliers prices do NOT contain VAT.


I would like to suggest some of improvements to the recurrent invoice functionality.

We would like to use it to create invoices for VAT purposes for payments made on credit card - so dates have to do with tax periods and historical records.

It seems that the current date is always used - rather than allowing the user to enter a date and then let the system work out whether any recurrent invoices are due. Furthermore the current date is used as the invoiced date - so one can't set the date to the taxpoint (e.g. for invoices relating to subscriptions).

More seriously if say a monthly recurrent invoice set was last created in January - and it is end March when the user next operates the functionality the system deduces that the recurrent invoices are overdue - but will only create 1 set ( dated March ) before saying that no invoices are due.

I believe the system should work along the following lines:
Enter taxpoint date...
Work out whether recurrent invoices are due - and if so how many sets according to the frequency set.
Use the day of the month set with the appropriate month to calculate the date for the invoices in each set.
Loop until the number of sets required have been created.

What do people think ?

Thanks in anticipation....


I'm getting an error trying to create a new recurrent invoice

DATABASE ERROR : The recurrent invoice could not be updated or added
error code : 1366
error message : Incorrect integer value: '' for column 'debtor_no' at row 1
sql that failed was : INSERT INTO 1_recurrent_invoices (description, order_no, debtor_no, group_no, days, monthly, begin, end, last_sent) VALUES ('Fast Forward Monthly Membership', '276', '', '4', 0, 1, '2010-12-01', '2010-12-31', '2005-12-01')

Will report as bug on Mantis as I I think I can see the reason for this bug is confirmed...

Thanks Joe,

These reports together almost deal with the issue I had in mind but not quite.

It would be really useful to bulk print invoices for a particular customer in order by entry date or due date. For instance a common request is to provide copy invoices for VAT purposes for the last tax year / quarter for a particular customer.

In both reports the print invoices / credit notes and customer transactions

The order appears more related to the date of entry to FA - than due or transaction date

In the print invoices report :
the reference appears to the left of the customer name so searching by customer name isn't as easy as it might be

However It does have the useful bulk print facility ( the from / to combo boxes )

In the customer transactions report :
you get to see individual invoices per customer - but you have to print them one by one

Thanks Vernon

As the list of invoices & customers gets longer the ease of finding particular invoices decreases dramatically.

A common task is making sure that the list of invoices for a particular customer is complete, printing them as they have asked for copies etc.

So a filter combobox would be really great

Comments & other ways to achieve this ?


(12 replies, posted in Modules/Add-on's)

I am beginning to get repgen to work ( v2.1.5 of FA ). I needed to fix :

A) Security Level in module install
- security level on inst_module.php. As installed it is set to $page_security = 20;;however the  whilst security level in config.php as installed are
and despite logging in as administrator ( and the screen showing administrator it refused me access
correcting this to $page_security = 16; allowed the installation routine to work.

Have I discovered a bug or a feature? as I understood these arrays related to inquiries,accountant,administrator respectively and therefore the admin should have security level 20.

B) Test of sql statement in repgen_create.php. On line 204 I added ?sql=$sql to the url to get rid of a SQL Statement is empty error. I note that the OpenWindow php function didn't set the method to GET or POST prior to the submit -

Enough for now...



Thanks for the explanation...

I will work through this example... and ensure I've got the intersections set up correct...

I think there is a problem with the tax handling on direct sales invoices. In the event of a mismatch between the item tax percentage and the customer branch tax percentage it appears that the tax is calculated as zero - with no warnings...

This came to light handling the changes in VAT percentage across the December 2008 boundary - and will occur again when they have to put it back up again.


(38 replies, posted in Modules/Add-on's)

Can't find anything about the VTiger integration - is there an alpha release as promised ?



(4 replies, posted in Wish List)

On reflection ... I wonder whether introducing the concept of the "working month / week" would help...

Currently the system assumes the user is entering transactions for the current month / date...

For instance people will tend to go through and enter transactions periodically... so having the option to set a constraining period that would be the default that appears for the date picker would be ideal... So one sets March 09 and then the picker will show that month....


(1 replies, posted in Accounts Payable)

Hi there,

I think there is a minor bug - in 2.1RC when entering a new supplier...

I one tries to enter 1000.00 as the credit limit - which would fit with the field type of double, the user interface inserts a comma ( making 1,000.00 ) and a sql data truncation error is generated.

Keep up the good work...


Many thanks...

Works a treat now...

Having done some experiments... one I find works well for entering expenses that were subject to VAT and were booked to a personal credit card.

Create a quick entry :
Label it Gross Amount
Put the Gross Amount into the default base amount field

Line 1 : amount -100% book to the credit card ( minus sign so it is credited to the liability )
Line 2 : Taxes included, reduce base - books the tax amount to the appropriate tax account
Line 3 : Remainder - to the appropriate GL account for the expense.

using this makes the entry fairly quick.. I set up a few like this with common descriptions so I didn't have to edit them all...

Important realisation was that the rules are applied in order and that the remainder takes the base amount that is left after applying ALL prior rules in sequence.

I find the following behaviour, and am unsure if this is what was intended.

Create 2 Quick entries for journal entries,
Quick Entry 1
Base Amount £200
Put in Taxes included, reduce base
Remainder to some GL account

Quick Entry 2
Base Amount £300
Put in Taxes included, reduce base
Remainder to some GL account

If one now goes to the journal entry page the 2 quick entries are in the drop down.. so far so good.

The input field to the right of this ( base amount ) shows the first quick entry - £200 and doesn't change if the second quick entry is chosen.

If amount is chosen in the Quick Entry setup it appears the tax calculation uses the input field on the journal entry page whilst the amount itself is taken from that entered  when setting up the quick entry fields... This appears to be a serious bear trap for the unwary user....

I suspect that this needs a javascript function to change the input field when the drop down changes...

I had expected the situation to function like this...


(6 replies, posted in Installation)

Had the same problem as Alvin...

I solved it with the help of the PmWiki install instructions... i.e. in particular replacing the local/config.php with the copied version docs/sample_config.php renamed to local.config...


(4 replies, posted in Wish List)

Minor gripe...

It would be great to have an option so the date picker remembered the last date used. This might be much closer to the next date required than today's date !

If entering transactions a couple of months after they happened it's very easy to forget and create transactions on the wrong date :-(