[GNC] UK VAT and "Making Tax Digital"

[Christopher Lam]

Oops realised that recording the capital purchase as expense then
immediately create a kludge txn from expense to capital-asset won't work:
it would be classed as a 'refund'. I have no other workaround.

Just wondering what exactly are the parameters for your reports?

On Tue, 30 Apr 2019 at 15:08, Christopher Lam <christopher.lck at gmail.com>
wrote:

> Hi Maf
>
> I agree your asset purchases are not going to be accounted for in the
> current iteration. This was not thought of during the design.
>
> A short workable answer is to record this asset purchase as an expense,
> and immediately create an expense->asset transaction which will satisfy
> your VAT requirements and still use the report as it stands. I'm sorry this
> is clunky, and the next para explains why
>
> The longer answer was that every VAT/GST related transaction ie.
> sales/purchases, record VAT, and periodic submission would need a
> transaction of at least 3 splits... moreover we'd need to determine, as
> simply as possible, whether it is a purchase or a sale. Hence the decision
> made to consider Income split as sales and Expense split as purchases, and
> determine vat/gst-split  as asset/liability as well. This allowed a complex
> 5-split transaction involving both
> sales/purchase/vat-collected-on-sales/vat-paid-on-purchases as illustrated
> in https://wiki.gnucash.org/wiki/Alternate_Australian_GST_setup and
> https://www.gnucash.org/docs/v3/C/gnucash-guide/rpt_standardrpts.html#rpt_gst_statement
> .
>
> An alternate strategy *could* be used to determine sales vs purchases, vat
> collected vs paid; e.g. use Business Features (which would then force the
> user to use invoices/bills for *all* vat/gst purchases, IMHO undesirable!).
> The difficult part is to determine a consistent strategy which is
> acceptable to users worldwide, and does not inconvenience too much.
>
> Sorry for long answer, hope is informative. If you have a better strategy
> to offer, to account for your Asset:Bank -> Asset:CapitalAssets +
> VAT:Paid-on-Purchases use cases, I'm all ears! Meanwhile the short
> workaround above *may* be an acceptable solution for the current reports...
>
> (w.r.t. CSV output: the following replacement .scm files can produce
> something similar)
> https://raw
> .githubusercontent.com/christopherlam/gnucash/maint-export-csv/gnucash/report/standard-reports/transaction.scm
> https://raw
> .githubusercontent.com/christopherlam/gnucash/maint-export-csv/gnucash/report/standard-reports/income-gst-statement.scm
>
> On Tue, 30 Apr 2019 at 13:37, Maf. King <maf at chilwell.net> wrote:
>
>> Hi Christopher.
>>
>> Finally got round to completing my final quarter VAT return with the
>> manual
>> error-prone process of typing 7 numbers into boxes on the HMRC website.
>>
>> I'm now trying to make the Income & GST report give me sensible numbers
>> that
>> match my existing saved transaction reports and struggling with one thing.
>>
>> It may well be how I've got my tree set up that's causing my problem.
>> The GST
>> report doesn't allow to  include transactions to asset accounts.
>>
>> Under UK tax law, if I buy something of lasting value, eg some machine,
>> for
>> example, it is not an expense but a transfer to Asset:CapitalEquipment.
>>  But
>> the VAT is claimable straight away and so the transaction (for the VAT
>> return)
>> should be included in the Net Purchases & Tax on Purchases column.
>>
>> any advice?
>>
>> is your CSV output intending to be made from the GST report codebase in
>> some
>> way?
>>
>> The bridging spreadsheet I have will be quite happy to read from
>> ~/somewhere/somefile.csv
>>
>> my test file is just :
>> Box1,1234.56
>> Box2, 0.00
>> (box 3 is calculated from box1+box2 so not included)
>> Box4, 321.98
>> etc to include box 6,7,8,9
>>
>> and the spreadsheet will read that and populate new data into the fields
>> each
>> time it is run.
>>
>> the only other thing that might be nice to include in the CSV output is
>> the
>> date period, but I haven't tested that for format etc yet.
>>
>>
>> I'm not signed up for the -devel list, can do so if you'd prefer to keep
>> this
>> off -user for now.
>>
>> thanks & best regards,
>> Maf.
>>
>>
>>
>> On Thursday, 11 April 2019 11:08:27 BST Maf. King wrote:
>> > On Thursday, 11 April 2019 04:48:31 BST Christopher Lam wrote:
>> > > 3.5 is out and I promised to offer CSV output. Has anyone confirmed
>> the
>> > > exact CSV (or JSON)  format desired by their *bridging* software?
>> > >
>> > > Please be aware that direct communication to HMRC is best done by
>> bridging
>> > > software outside gnucash. It'll be a nice project for anyone to do in
>> > > python or similar.
>> >
>> > Hi Christopher,
>> >
>> > Thanks for looking at this again.
>> >
>> > I'll probably be looking at this next week or so.   I'll have to
>> complete my
>> > lasts "traditional" VAT return by around the end of the month.  For the
>> > quarter ending 30th June, I'll report to HMRC towards the end of July,
>> and
>> > be in the first tranche of submittors.
>> >
>> > I plan to use a spreadsheet bridge that I found for Libre office.
>> >
>> > seems that the sheet as presented requires linking cells from a source
>> > report spreadsheet.
>> >
>> > User guide is here explaining how to do it
>> >
>> > http://www.chm-software.co.uk/userguide/
>> >
>> > (no relationship or recommendation implied)
>> >
>> > I'm thinking that I might be able to adapt their sheet to directly take
>> a
>> > CSV input to named cells in some way.  It is only about half a dozen
>> > numbers that are needed.
>> >
>> > Of course, if any other users have come across a more elegant solution,
>> feel
>> > free to chime in!
>> >
>> > Maf.
>>
>>
>> --
>> Maf. King
>> PGP Key fingerprint = 8D68 A91F 733B 2C1F 43B7  2B7C E591 E8E1 0DE7 C542
>>
>>
>>
>>
>>
>>