1 (edited by dls 02/05/2015 06:43:55 am)

Topic: 0-VAT again

HI
I'm still getting my head around the table structures etc. However in an attempt to get the 0-VAT UK BOX7 transactions from a Banking and GL payment/Deposit.....

If I ensure by quick entry that the 0-VAT is entered with and after the relevant associated transaction, is there any reason that

SELECT amount, counter, account FROM `1_gl_trans` WHERE counter IN (SELECT counter-1 FROM `1_gl_trans` WHERE account=2206)

will not work all the time and pull all the required transactions out? (2206 is my 0-VAT account) It is rough and ready but is a temporary fix until I can organise something else. It has worked for my test data, but I would be interested if anyone has an amount of previous data they can test it against.

Also any comments as to if there is a better way to link to the transaction.

Many thanks
David

2 (edited by apmuthu 02/05/2015 09:18:09 am)

Re: 0-VAT again

Your SQL will not work as it will only pull out the immediately prior transaction alone and we cannot rely on an auto-increment field when multiple users will use it and many records per transaction will occur even if it is restricted to quick-entries since other transactions too may use the accounts in question.

Try the following in the en_US-demo.sql Training Company and compare it with the actual data in the 1_gl_trans table (2150 is Sales Tax):

SELECT amount, counter, account FROM `1_gl_trans` 
    WHERE counter IN (SELECT counter-1 FROM `1_gl_trans` WHERE account=2150);

There are some errors in the standard UK CoA (as also the Canadian one) in the schema and unless you created your own CoA probably based on the en_US-new.sql CoA or any other proper one, chances are that some FA operation will fail and no one would be the wiser.

The corrected standard UK CoA is in my GitHub repo.

The project devs are busy with getting FA v2.4 out the door, the pkg repo remains to be updated.

Re: 0-VAT again

Do you really need an account for 0-VAT? Wouldn't it make more sense with a separate sales account for those items? 4000-something.

Re: 0-VAT again

If you want stastitics for your VAT report, you must have an account for zero vat.

Joe

Re: 0-VAT again

A sales account, yes. Of course. But his 2206 looks more like a liabilities account.

Re: 0-VAT again

You need a vat account for the 0 vat. This way it is possiblee to calculate income/purchase for the tax report period also for the 0 vat.

If you don't need this statistics you could just skip using any tax for the sales.

Joe

7 (edited by dls 02/05/2015 07:50:51 pm)

Re: 0-VAT again

Many thanks for the info. Understood.

I haven't looked closely at the code but somehow thought it would be concurrency safe if the 0-VAT was effectively attached immediately after the 'Net' value, given that the payment/deposit appears to go through as a transaction when processed. ( This was just for a temporary fix to allow me to start using FA 'live')

Will look into the info sent. I really need to start using FA in earnest and this seems to be the only major issue I have.

Is v2.4 likely to have a solution to this issue ?

Once again many thanks.

Re: 0-VAT again

Amended SQL query to pull all associated 0-VAT transactions

Select t2.*
   From 0_gl_trans as t2
   Join 0_gl_trans on ( t2.type = 0_gl_trans.type and t2.type_no = 0_gl_trans.type_no )
  Where 0_gl_trans.account = '2206'
   // And t2.account ='5000'         -- optional for specific purchase accounts

Re: 0-VAT again

That is indeed a nice expose on the ERD lacunae in FA.

@joe: In FA 2.4, we need to replace the primary key "counter" in gl_trans table with one containing 2 new fields - "Transaction_No" and "Transaction_Line_No".

Currently, the gl_trans table's field named 'type' can have more than one 'type_no' and 'type_no' can have more than one 'type'.

Using 'type' for a field name!

Re: 0-VAT again

I've been trying to input 0-VAT purchases via supplier invoices using quick entries for non inventory items -ie utility payments etc. These do not show up on the tax report. Is this a bug? Or have I not set the tax up properly? - I have no problems with tax specifically associated with items. 

I have found by using the statement below that the net amounts can be shown in the report. Is there a better way of achieving this?

UPDATE 0_supp_trans as strans, 0_trans_tax_details as tax
SET tax.net_amount = strans.ov_amount
WHERE strans.type = tax.trans_type AND strans.trans_no = tax.trans_no AND strans.tran_date = tax.tran_date AND tax.tax_type_id = '4' AND
strans.ov_amount<>'0' AND
tax.net_amount='0'


Are the current 0-VAT issues likely to be improved in 2.4?

Many thanks for the great work

Re: 0-VAT again

The problem with 0 VAT is only a GUI problem. First you can't enter a 0 amount corresponding to the 0-VAT GL line.
Then you can't deduce the net amount corresponding to this 0 line.
The solution is to add a column in the Payment/Deposit UI corresponding to the net amount of the transaction.
This way, let's say you have a payment for £5 + 0 VAT, you'll enter two lines, one of £5 and the other of £0 with a net amount of £5.

With this, FA can save properly the information in the gl_trans table and everything works fine.

I made a patch with modify the GUI this way, with some javascript to automatically calcul the net amount on VAT account.
I submitted it and thought it has been merged but it hasn't. I'm not sure why.

/Elax

Re: 0-VAT again

Thanks for the quick reply elax.
Would it be possible to get a copy of the patch?

Re: 0-VAT again

Having looked closer I see the problem more clearly and now realise why it has not been addressed very quickly. The trans_tax_details are not uniquely associated with the relevant gl_trans line making the direct assignment of the net amount a problem. The problem then becomes how to implement this satisfactorily. It would probably be neater to implement it automatically with QE when a zero rate tax is applied as this links the application of tax to the specific gl entry?

Re: 0-VAT again

It's easier and more complicated than that.
You can't deduce automatically the net amount from a 0 Vatted transaction, so there is no point to try to do something automatic.
However, if you know the net amount, it's super easy.

The solution is therefore to ask the user (somehow) what is the net amount. What can be automatically is prefill the net amount which is what my patch does. I'll send it to you but I'm really busy at the moment.
Alternatively, you can ask itronics or Joe the patch, I sent it to them a while ago.

/Elax

Re: 0-VAT again

Yes sure, my thoughts were - when the quick entry works and adds the VAT (in this case) 0VAT I was that would be the time the net amount was registered?? Otherwise the net amount would have to somehow be manually attached to the VAT would it not? Which doesn't seem very neat!

Thank you in advance very much for sending me the patch.

Re: 0-VAT again

At the moment the net amount is attached to every transaction in the database, so there is no problem record it.
However, there is indeed a problem for Quick Entry. The way my patch work at the moment is, you'll have to enter manually the 0 VAT line (with the required amount). You could indeed forget, but my patch ask you confirmation before commiting an "unbalanced" VAT transaction (ie if all the non-VAT items amount, doesn't match the VAT items net amounts).

/ELax

Re: 0-VAT again

OK so another approach to this 0VAT reporting problem

(I haven't coded PHP much - most in RT robotics using C. - also I'm very new to frontaccounting so very much finding out how it works. The code below is more a concept and would need to be tidied etc --But constructive feedback from those who know would be great)  I'm also snowed under with other work so don't have much time to spend on this - but would really like to get it sorted as it's holding my accounts back.


Use of SESSION variable just for OVAT gl entry.

By adding the code below in includes/ui/ui_view.inc

display_quick_entries()

            switch (strtolower($qe_line['action'])) {
                case "=": // post current base amount to GL account
                    $part = $base;
                    break;
                case "a": // post amount to GL account and reduce base
                    //Hack fix for 0VAT reporting
                    if ($qe_line['dest_id']==2206)
                    {
                $_SESSION['zero_tax_net_amount']= $base;
                    }

I can transfer the net amount associated with gl 0VAT QE input straight into the trans_tax_details table. This is where the standard tax report gets its data from.

(The 2206 relates to my 0VAT gl_account this could be set in the config file as 0VAT account for tax reporing purposes)

The modification to the function below in includes/db/gl_db_trans.inc deals with the data insertion to the table.

function add_trans_tax_details($trans_type, $trans_no, $tax_id, $rate, $included,
    $amount, $net_amount, $ex_rate, $tran_date, $memo)
{

//Hack fix for 0VAT reporting
if ($_SESSION['zero_tax_net_amount'] != 0)
$net_amount = $_SESSION['zero_tax_net_amount'];

           
    $sql = "INSERT INTO ".TB_PREF."trans_tax_details
        (trans_type, trans_no, tran_date, tax_type_id, rate, ex_rate,
            included_in_price, net_amount, amount, memo)
        VALUES (".db_escape($trans_type)."," . db_escape($trans_no).",'"
                .date2sql($tran_date)."',".db_escape($tax_id).","
                .db_escape($rate).",".db_escape($ex_rate).",".($included ? 1:0).","
                .db_escape($net_amount).","
                .db_escape($amount).",".db_escape($memo).")";

//Hack fix for 0VAT reporting
if ($_SESSION['zero_tax_net_amount'] != 0)
$_SESSION['zero_tax_net_amount']=0;


    db_query($sql, "Cannot save trans tax details");

}


Currently by using quick entry I can get proper tax reporting by just using this code - no other modification. This can be extended to  gl payment /deposit by similar code to the first snippet and appropriate insertion in the payment /deposit areas.

I wish to keep my FA system in line with the official development so ask for advice and thoughts as to any reason this will not work or is a bad idea.
Does this make any sense. Any comments please and thanks in advance.

Re: 0-VAT again

I pushed my patch there https://github.com/elax/frontaccounting/tree/gl_tax_support. It's based on FA 2.3.17 so might want to rebase it to the current version, however, to see how it looks and what it does, you can just use as it is.

This patch, as well as allowing 0-VAT transaction, allows to modify net amount if needed, and check that EVERY transaction is properly VATed :ie that the total amount of non-tax account, matches the sum of net amount of tax account.

The way is works, is by adding a new column in payment/deposit/journal entry which correspond to net amount.
For non tax account, nothing change (and the cell in the new column is empty). For tax account, you can specify the amount (as before) AND the net amount (or taxable amount). Both values are automatically prefilled depending on the VAT rate and the total of net amount, already entered in the form.

For example, let's say you buy some stationary for £100 (ex VAT).
the first GL line is

Account          | Amount | Net Amount |
Stationanry     | 100.00  |                   |

When you enter the line corresponding to the VAT account, it will be automatically prefilled to 20 and 100 (this can be modified) so you'll end up with
Account          | Amount | Net Amount |
Stationanry     | 100.00  |                   |
VAT 20%         |  20.00  |         100.00|

If you select a 0 VAT account, it will be prefilled with 0, 100.  etc ...

At the moment, it doesn't work with quick entry but only for normal payment/deposit and journal entry.
Modifying the way quick entry work to have a 'net amount' option shouldn't be a problem.
At the moment, when I use 0-VAT quick entry, I just add manualy the 0-VAT line (because the validation tells me that I forgot
to "balance" the VAT) and everything is fine.

Disclaimer: I just pulled on old branch from by repository, so It might not work. If it doesn't just ask me. I use it on production every day and it works well (but I can't push my production branch, because it contains other patches)


/Elax

Re: 0-VAT again

Is the FA v2.3.19 patch in the attached file sufficient to now port to FA v2.3.22+?

Post's attachments

elax_tax_support.zip 89.4 kb, 2 downloads since 2015-03-07 

You don't have the permssions to download the attachments of this post.

Re: 0-VAT again

I've had a little play with a file gl_tax_support of the repo and it does what you indicate,  but it still doesn't seamlessly report using the current tax report. This seems to pull the required data from the net_amount column of the trans_tax_details table.

The patch needs to include this data as a matter of course. Surely the net amount needs tobe stored in the same table as the rest of the reported tax data?

Re: 0-VAT again

What do you mean ? The data (amount + net_amount) are stored in the in the trans_tax_details which are then used for the tax report . Of course, you need to enter the GL line corresponding to the 0-VAT account.

I remember having to change something to allow 0 amount line to be valild, but I'm pretty sure it's included in the patch.

/Elax

Re: 0-VAT again

apmuthu wrote:

Is the FA v2.3.19 patch in the attached file sufficient to now port to FA v2.3.22+?

What do you mean ?

Re: 0-VAT again

I'll have another look, but rep709 pulls the Net amount from the x_trans_tax_details table does it not? When I tried the patch -if it was the correct one rep709 didn't report any 0VAT Net transaction.

Does the patch just affect these files?

config.default.php
gl/gl_bank.php
gl/includes/ui/gl_bank_ui.inc
includes/ui/items_cart.inc

Re: 0-VAT again

Ok I just got the files from

http://devel.frontaccounting.com/git/?p=fa-stable.git;a=commit;h=481038ba4817907d494aa66fb6a888f1493221b2



I'm running 2.3.22 Do I just copy files from the zip file over my current files?  (backing up current prior)

Re: 0-VAT again

It does save the net amount in the 0_trans_tax_detais but affect all of those files

config.default.php
gl/gl_bank.php
gl/gl_journal.php
gl/includes/db/gl_db_banking.inc
gl/includes/db/gl_db_trans.inc
gl/includes/ui/gl_bank_ui.inc
gl/includes/ui/gl_journal_ui.inc
includes/ui/items_cart.inc
js/inserts.js