Has anyone in the UK tested the extension - and how easy is it to sort out the liabilities etc.

Cheers,

bailey86

There are a few other quirks once you get down to the details but the trick is to start with the payment  and not the invoice.

Hope that makes sense.

PS. Australian GST is almost identical to UK VAT.

Gary that's exactly what I'm doing (in Aus). The UK VAT and GST systems are almost exactly the same, and for now, I'm pulling (via SQL and PHP scripts) the CASH transactions only as you describe.
These then get summed up for reporting on BAS.

By the way, a tip I found useful was to use the secondary code of the chart table to be the correct BAS item number. So, for instance, Office Expenses has G11 as its secondary ledger code. This helps when summarising.
(G11 means Non-capital purchases on the BAS statement).
My dream is to create a BAS report straight out of FA. This report would have a setup screen that allows you allocate each account to its relevant BAS report component.
The actual quarter-close transactions ie. paying your BAS etc. are being handled manually at the moment as its a bit difficult to get FA to 'code' a set of transactions, but this could be done too.

By the way, I also use e-record, and have written a script that takes the e-record transactions and turns them into the format required by 'Import Multijournal Transactions'. I can then import all my payments/deposits straight into FA. I've rewritten the Multijournal Transactions screens for FA 2.34 and will post soon. If anyone's interested in the (basic) e-record data translator, let me know in this post.

Pete

One of the requirements was for an application that could handle VAT cash accounting, and from my perspective it already does that indirectly. Sure you might feel you need an html wrapper around the result set and I will try to suggest a complete solution in the future, time permitting, by putting forward a php script. (Time is an issue at the moment however as I am out of work and trying to put together a business possibly around this software - i.e I am available for Bar Mitzvahs at an approriate rate)

Anyway this note might serve as a starter for anyone still toying with the Cash Accounting issue.
I did a quick test by entering a statment via phpMyAdmin and to be honest I only input a quick sample data set so a simplified "date" aspect was suitable, but of course it would actually need to be two seperate clauses >= periodStartDate AND <= periodEndDate
However this was oK for testing which was really about determining if the fields were to ambiguously named to get to the relevent data easily.

This test only takes account of Supplier Invoice and Customer Invoices but of course would need to take account of both types of credit note (trans_type 11 & 21) for anyone who needs to make the script useful. Please correct me if there are other transaction types that I have not considered which should also be included in the clause.

I have perhaps not thought it through in its entirity and certainly not in terms of some of the complications as mentioned above about exclusions from the scheme for imports for instance but this should not be a heavy issue. Of course you will want summery totals for each rate and turnover against inputs and outputs for your return. I will flesh this out further in the future for now its just a starting point and you can total these things easily in a spreadsheet template for now.

Obviously once you have your summaries that will also provide for a journal entry against your VAT libaility accounts when payments are made. Personally I dont see the need to record any data as to which items have had thier liability met as it is the total outstanding liability that is relevent. If you want to know which items are in the liability account that have never had a payment made in respect of them simply do a similar query with the table join reflecting no payment!!

SELECT ref, bank_trans.trans_no, type, trans_type, trans_date, tax_type_id, rate, net_amount,trans_tax_details.amount FROM bank_trans, trans_tax_details WHERE bank_trans.trans_no = trans_tax_details.trans_no AND (trans_type=10 OR trans_type=20) AND trans_date >= "2011-05-11"

However, cash accounting is actually very simple once you approach the reporting from the payment end and not the invoice end. Rather than selecting invoices that were raised during the 3 months, simply look at the payments made in the 3 months and select the invoices that they apply to. This also allows for the inclusion of sundry payments where invoices are not provided e.g. petrol.

By doing it this way, you can re-print the report if a late entered payment is discovered.

There are a few other quirks once you get down to the details but the trick is to start with the payment  and not the invoice.

Hope that makes sense.

PS. Australian GST is almost identical to UK VAT.

I am as Mike. Happy to help (have some PHP skills) but know nothing about FA (apart from whats on this thread).

Paul

I resigned myself to running my GST in an Accrual basis so I think this will be a good extension

Yes, this is good idea to place all the info on the development wiki. Currently we are more than busy with latest fixes before final 2.3 release, but after it is released we will have more time for cash/accrual VAT implementation. Good news is in the same time I'm involved in implementation of VAT related changes for Polish fiscal rules. As the rules are at least similar throughout EU some of them surely will go to core FA, and will be helpful during other local european VAT implementations.

It is up to you whether you will describe the matter directly on Wiki, or using GoogleDocs. To have write access to the wiki you simply need to log in via forum or wiki interface. I'm not sure about write access rules to specific wiki pages, so if you encounter any problems give me a note.

Thank you for helping us to make FA more friendly for european users .

Janusz

Just wondering if and how we might assist FA in getting this matter progressed...

For example...

The FA Wiki, "Wishlist" page [1], seems to be a master list of the items being addressed by the FA designers / developers / programmers? Would it be useful if we created a new section there, on this VAT matter? We should combine all the above points into one single coherent "spec", and, hopefully, get others - VAT experts, FA experts, etc - to review and edit it, until it forms a final useful spec for whatever tweaks are needed to FA to support this VAT option...

I've never tried logging in to the FA Wiki - I presume "we" can sign up, and log in. If not, perhaps we can create a shared document elsewhere (eg, Google-Docs), and let the authorised FA folks copy it to the Wiki, or link to it from the Wiki...

  - Mike

[1] - https://frontaccounting.com/fawiki/index.php?n=Devel.WishList

I have done nothing on this matter, nor had any contact with anybody about it - apart from what is in this thread.

As I stated already, I would be very glad to help in any way. However, I've no familiarity with the FA internals.

  - Mike

Just having a look at FA for use on our business. We are also UK based and use cash accounting. Is this issue still being followed up?
We are software development operation and could potentially contribute some coding effort . Seems like MJK and Roysharp have  a pretty good handle on what is required.

Paul

That paper is excellent. Happily, our posts above tie in extremely well with the official spec. Perhaps we should emphasise the following (mainly for lurkers here!):

1. The "Cash-Accounting" mechanism is permitted (in the UK) on Purchases (Crs/Payables), as well as Sales (Drs/Receivables).

2. There seems to be an exception, on Purchases, regarding some unusual purchases - eg, Imports. See points 5.5 and 5.6. The VAT on these transactions apply at the time of Invoicing. In FA, I assume these types of purchases would need to be tagged separately, and, therefore, treated separately in the VAT reports.

3. Our posts above have not covered the rules and processes involved in Joining the scheme, Leaving the scheme, Re-joining, Insolvency, etc. Presumably, most/all of these would be outside the scope of FA anyway?

4. I didn't see any advice re how best to handle national VAT-Rate changes. This can be traumatic! Maybe best to have VAT-codes, assign a new code to each new Rate, and start using the new code - as appropriate?

5. Auto-allocation of Credits: See point 5.7. I thought the book-keeper might have to manually allocate every credit against the relevant debits. However, 5.7 says otherwise, which greatly simplifies the user's actions, and makes FA EVER more beneficial!! As I mentioned, I already have implemented "Auto-Allocation" code, which we might be able to use in FA. A matter not mentioned in the HMRC spec is, eg, what to do if Invoice-123 is issued, and it's cleared later by Credit-456. Then Inv-123 is withdrawn... and Cr-456 is freed up, to be allocated against other debits. The automatic mechanism covers all this, and always re-allocates the remaining credits against the remaining debits - ALWAYS oldest first (as per 5.7). So, the VAT summaries emerging might show changes for previously closed VAT-periods, in which case the current VAT balances must be adjusted by the VAT Payments/Refunds made to-date, to arrive at the current VAT payable/refundable. (Hope this makes sense!).

6. I would, very respectfully, suggest that the official approach for handling part-payments against invoices with multiple VAT-rates, as per 8.2, is not as good as the mechanism in the above posts. They seem to be calculating/allocating VAT against the VAT-summary on the invoice (I don't know what would happen if they had MULTIPLE non-zero rates in the example!), rather than against the individual line-items - as I suggested. With the line-item approach, the VAT summaries should show all VAT amounts at the exact rates, and this can be useful in auditing, etc. With the HMRC approach (I think!), the VAT summaries might not reflect any of the standard rates. The overall result, obviously, is still exactly the same in both cases.

So... whereto from here!!

  - M.

That sounds very sensible to me - it would open up a significant number of new potential users too.

I agree.

Actually, Roy, I'm not! I should look it up - if you have a link, I'd appreciate it. Also, sometimes, the official "specs" of these types of procedures are more legal than technical, and might need some reduction, re-hashing, etc, to facilitate computerisation.

Agreed. Maybe very little work needed in FA...

Me too. I'll gladly knock up a few lines PHP, and/or a few SQL statements, but I'm also totally unfamiliar with the internals, and such a project would need to be directed by someone with an intimate knowledge of FA.

  - Mike

In db terms, like Mike, I would have thought that it was a case of maintaining a new table of posting detail relating back to invoices with VAT content (apologies if it's there already)

I am no PHP-er but I have a "few years" of design experience ;-) and I am happy to test if that helps.

Great!

If it's of any use to any of you, I'll be delighted to help on this matter. Only in recent weeks, I wrote a small add-on module in an A/cs system to AUTOMATICALLY allocate all Drs credits against all the debits (oldest first) and to extract the Cash-Accounting VAT summaries accordingly. However, that approach was "unique", and would not suit FA (IMO).

I agree that the overall "best" approach has to be adopted...

However...

AFAIK, this "Cash-Accounting" option is intended only to assist the trader's cash-flow, and with the monthly VAT returns. In annual A/cs, Mgt A/cs, etc, the VAT analyses still need to be done on the standard Accrual basis. In any case, over time, the Cash-A/c VAT reports end up with the exact same data as the Accrual data, except the timing is different...

So... maybe you should leave the Accrual system in FA exactly "as is", and the only tweaks might be:
  - Maybe have an additional system option: Cash/Accounting reports are needed [Y/N]. If Y, the remaining tweaks would be supported... (If possible, avoid this option in the first place!).
  - On Receivables, encourage the user to fully Allocate each Credit against the relevant Debits.
  - For each DB, it will probably be necessary to note which Credits have been allocated against it. The DATEs on the allocations define the VAT-periods.
  - And, on each Credit, note which DBs it has been allocated against. That identifies the relevant VAT-Rates.
  - Or, maybe a separate "Allocations" table could be maintained, and hooked to the parent DBs and CRs. (I know nothing yet about the FA internals, so perhaps all this allocation support is already in there).
  - Obviously, if transactions are edited, these allocations must be edited accordingly.
  - If the Cash-Accounting VAT also applies to the Payables, the do exactly the same with the CRs and DBs there.
  - Finally, and this might be the only "new" feature to be activated in FA, have a separate "Cash-Accounting" VAT report, to show all the VAT activity as discussed above and in the previous posts here.
  - I think all the current GL A/cs, VAT A/cs, etc, in FA would not be changed in any way - I certainly hope so!!

Mike.