Export accounting to dedicated software

Rational

It is common to use Tryton only for management accounting and to export some document into a dedicated accounting software to make pure accounting processes (like tax and fiscal year declaration etc.).
So it will be good to have an unified mechanism to prepare the export with a set of dedicated modules that targets specific software.

Proposal

The best basis to manage the export is to use the posted account moves.
Each export should be stored in an account.export model with the date and the company.

The export can be created at anytime so it can be run very frequently if needed. It is created by a wizard which select all the posted moves up to a date. An export can not be deleted.
The export record stores the generated files (for the exports that generate files).

On the posted account.move a link to the account.export is added to keep track of which moves are included to the export. Once the field is filled it can’t be modified and it can only be filled for posted moves.

On the account.configuration a selection field is added to define which format is currently used for the export. An export_<name> method must be implemented on account.export for each format which is responsible of generating the files and to store them.

New export files can be re-generated if it was not yet imported by the account administrator on demand (ex: if the initial one contains errors) but the former files are kept for history.

The account.export has a simple workflow with 2 states Pending and Done.

A cron task is added to create export at specific frequency if there are non-exported account moves.

Implementation

2 Likes

What is the benefit of having such base module with no export implementation?

Why do we need to save the exported file on a record? Which is the usage?

We have some code to export accounting to external formats and most of the time its a mather of just generating a report with the current version of the data and showing them to the user. We’ve never needed to store the generated files nor know where a move have been exported.

Normally the user exports the data based on some periods (or even between some dates), imports the data to the other software and that’s it.

Also nowadays it is fair common that accounting software have an API which allows to post the accounting moves each time an invoice is posted. Such API normally returns the external id which can be stored on tryton. We have implented this export to XERO for example.

Implementing integration with other accounting software.

To keep track of what was imported.

So it is not safe as you could export multiple times the same move or not import some others.

There is no reason to have such constraint. And for what I have seen people prefer usually to have at least one export every week.

I do not think it will be a good design to have synchronous export because it will be a bottleneck and a single point of failure. Neither to base the export on invoice document because there are many other things that can generate account move which will be missing.

But we could provide a cron task that create an export record to automate the process.
And some export_ implementation may use an API instead of generating a file.

1 Like

This topic was automatically closed after 14 days. New replies are no longer allowed.