Trying to configure tryton for UK accounts


#10

Thanks for the feedback.

I was rather hoping that these account files used generic python code that would be contained in the ‘account’ module and would be maintained to work with the latest builds of tryton and would then be utilised by the other country modules, with just user editable xml files that would change the way each country accounted for their taxes etc.

I have misunderstood that each module needs new python coding to make them country specific.


(Sergi Almacellas Abellana) #11

Indeed for a basic accounting module your hope is right. The chart of accounts normally include only xml files which contains the configuration for accounts and taxes templates. They may include some specific reports for that are required for the country but for starting point you can start with only the xml definition.

After a review of the module I see that it includes and Abbreviated accounts reports which I don’t know if it’s a specific requirement for UK or it can be removed. Probably the same information can be exported by Using the Trial Balance option of the General Ledger Report.


#12

Thanks for your continued help, it is appreciated :slight_smile:

Initially getting trytond_accounting_uk working would be a good start, which appears to be intended to be the basic accounting structure for the uk?

The decimal exchange rates are available, so presume can be manually edited to give the current rates.


(David Harper) #13

I am going to start work on upgrading / creating an initial UK accounting module. Do you think it is best to open an RFC on the bug tracker for a account_uk module?


(Sergi Almacellas Abellana) #14

If you have somethink that is working and it can be installed on the latest trunk it will be a good step.
But please explain which is the source of the chart of accounts, including a link on the docs folder of the module will be very welcome.


(Sergi Almacellas Abellana) #15

I’m cuirious why the module includes the exchanges rates.
Is there any legal requirment to use the ones included on the module?
Why the historical data is required?


(David Harper) #16

The rates are published by HMRC (the UK Tax Authority) and are one method that can be used when converting transactions in foreign currencies to Sterling for VAT purposes.


(Sergi Almacellas Abellana) #17

I see that this is not the only option as it also accepts the rates published on the newspaper. That makes me think that we should not include the rates on the account_uk module and it should be manually managed by the user by entering the desired exchange rates in the application.

I see there is also a webservice for downloading the rates, maybe we can include some cron job to download the rates but I don’t think they should be hardcoded on xml.


#18

Excellent news and thank you.

Downloading the rates would be great rather than having to manually enter them at any point; hard coded or otherwise.


(David Harper) #19

I am making steady progress, and have been doing quite a bit of learning and research. I have some notes, and questions.

I fully agree that the exchange rates should not be included in a uk accounts module.

The Abbreviated Accounts format has been abolished with changes in 2015 to uk law and can no longer be used when filing accounts.

Looking at the accounting_uk module README by lampmantech, he correctly points out that in the UK there could be many different legal charts of account. Each of these made for a different business sector (service, manufacturing, etc), and/or type of company (sole trader, partnership, limited company, etc).

Based on this I am wondering what is the best way of structuring the account_uk module? I can see a few alternatives:

  • A single account_uk module that includes everything for as many types of company and business as possible.

    I don’t think this is a great solution because it will mean that companies have accounts and reports that they will then have to ignore or deactivate, and is not in keeping with the modular approach of the rest of Tryton.

  • Many different account_uk_* modules, each of which would contain the chart of accounts, data, reports and code for a specific business sector and company type.

    I don’t think this is a good idea because with separate charts of account for each sector and company type, things like common accounts would then have to be duplicated in each module. Also with separate charts of account I don’t think there will be much that could be shared between these modules, as I think taxes for example, are be linked to an account.account.template.

  • An account_uk module that contains any common reports, taxes and a basic chart of accounts, and then additional modules that add additional accounts and reports that are specific to the company type or business sector.

    The idea is that multiple account_uk_* modules would then be installed to provide the appropriate functionality. e.g. a UK limited company that provides services and also does some manufacturing could then install the account_uk, account_uk_limited_company, account_uk_service, and account_uk_manufacturing modules.

    This is my preferred option. One disadvantage may be for multiple company setups, from what I can see they would end up with the same type of charts of account for each company, even when each company may ideally have a different setup.

I welcome any feedback or comments.


(Cédric Krier) #20

To be able to advise, we should know what are the differences between those charts.
Do they have incompatible accounts like two account with the same code but different purpose? If no, for me, there should be only one chart of account with everything strictly needed.
We have an example with Spain where there are two charts (for small and large business) which are incompatible together because the some accounts with the same code do not have the same purpose. But this is a solution that should be avoid if possible because it is more complex.
I do not see any problem to have more complete chart for a company with accounts that it does not use.

I do not understand who reports could be different. The general legder, balance sheet, income statement etc. should not be that different and neither the tax reporting. Could you point what are the differences?


#21

Speaking for me personally, I am utilising the micro accounts discussed here for a services company, so I like the last option you mention ->

That said, I don’t fully know the differences between full accounts and micro/small.so its hard to comment more than that.

I am guessing after seeing previous company corp accounts its the level of detail required and the need to be audited.

I am not aware (but may be wrong) of differences between service lines, as isn’t it about the overall profit and loss + balance sheet, which might have different revenue/income lines but they are all still income.

I would be fine with one account that can have items removed if it is a micro or small business, but I’d really appreciate knowing that these type of options are available, so I don’t get swamped with detail of a full company account that I do not need to know at that point.

For non limited companies I guess it is again down to the differences, but I understood it is differences in tax bands and the classes of national insurance that are applicable. As well as different reporting requirements but they are not financial.


(David Harper) #22

Thanks for the feedback.

There is no official chart of accounts defined, so it is possible to create a chart of accounts that does not have duplicated codes.

From what I can see, the differences in the balance sheet and income statement for Small Companies and Groups, and Large and Medium-sized Companies are only in the arabic numbered items, and furthermore general rule 4 states that these numbered items should be adapted where the nature of the business requires it. Also, it looks like small companies could use the the formats defined for large and medium-sized companies - See 3. (3). So I see no obstacle for having a single module here.

However, for Banking Companies, and Insurance Companies, the allowed formats for the balance sheet and income statement are quite different.

If there was a single module then it is possible to deactivate items that you are not interested in. Accounts and account types can be updated to have an end date sometime in the past, this would then mean you would not see them. Then if in the future you needed them, you could re-activate them.

I would be great to get an idea of what kinds of revenue/income lines you would be expecting to see for a service company, so I can compare it with what I have found out so far.


(Cédric Krier) #23

To summarize there are 4 types: small, large and medium, banking and insurance companies.
So I seems that 4 charts of account are required (but banking and insurance could probably be skipped for now). And as small can use the large and medium, I think the best is to implement the last one.


(David Harper) #24

There are also sole traders and partnerships, but these do not have to file accounts with a public body, only maintain proper accounting records. They could also use the same chart of accounts and format of balance sheet and income statement.

So, I agree its probably best to base the module on the Large and Medium-sized company formats.


#25

Sure, but it may be some time.

Those service lines would depend on the service being offered wouldn’t they. Perhaps Service 1,2, 3 etc

There would also be the addition of partial payments as its unlikely you would be paid for all of the service in advance and you would want payment on milestones to ease your cashflow for example.


(David Harper) #26

I have a question that I hope someone can help me with.

On the balance sheet formats there are several “payments on account” items. From what I understand a payment on account is a payment where there is no invoice to allocate it to. This payment is then allocated to an invoice at a later date.

In Tryton I expected payments without an invoice would be posted to the appropriate payables or receivables account, and then at a later date simply reconciled using the Reconcile Accounts wizard? If this is the case then on the balance sheet these payments would show up as part of the amount from that payables or receivables account.

So how should these payments on account be split out? Is it best to have some “payment on account” accounts, which any outstanding payments on account can be moved to at year/period end, and then moved back at the next year/period start?


(Cédric Krier) #27

I would say do not use those accounts if it is not strictly required.
Tryton manages payable and receivable through reconciliation which is a much more powerful way.


(David Harper) #28

I’ve now got an initial module that can be tested. It includes a chart of accounts, balance sheet and income statement. It also includes UK taxes.

There are some things that I have not included (yet) such as reports to output the balance sheet and income statement in an appropriate format for filing, or a model to show the data that must go in each of the boxes on the VAT Return, or any support for MTDfVAT.

However I have created issue7770 so I can hopefully get some feedback before I do too much more.


#29

Congrats on getting to this point. It sounds very promising.

Is it at a point to have a try and if so what is the best way of installing?

Thanks