Audit compliance?

[Pa Wa]

Hello Tryton Developers,

Hello Tryton Users!

From the legislator standpoint of view, wherever it may be, bookkeeping has to be 'audit safe'. Regulations may vary from country to country, but the character may be the same.

That is to prevent fraud by manipulating the bookkeeping itself, I guess.

The main question here: Does Tryton have measures implemented that track any changes made to any data Tryton stores or keeps track of?

Background: in Germany since 2015 (GoBD) any digital handling of business process related data has to be, in essence, unchangeable, or safe from being manipulated. Therefore requirements to an ERP from the legislator/regulator standpoint of view are now stricter.

These requirements are:

  * book entries or records must not be changed in such a way that their original content cannot be retrieved or determined any more,

  * later changes are to be made in such a way, that the original content as well as the fact that changes were made, are recognizable,

  * when master data is changed, the distinct meaning in the according transaction data has to be recognizable afterwards.

These are just those requirements touching an ERP, but not limited to.

Thank you.

[Korbinian Preisler]

Hi,

On 04.10.2016 13:51, Pa Wa wrote:
> Hello Tryton Developers,
> Hello Tryton Users!
>
>
> From the legislator standpoint of view, wherever it may be,
> bookkeeping has to be 'audit safe'. Regulations may vary from country
> to country, but the character may be the same.
>
> That is to prevent fraud by manipulating the bookkeeping itself, I guess.
>
> The main question here: Does Tryton have measures implemented that
> track any changes made to any data Tryton stores or keeps track of?

You can track any change of a record by activating the history table on
the model [1]
On relations you can define a datetime_field[2]. It will be used to
retrieve the content of the related model by the date given by the
datetime_field.

>
>
> Background: in Germany since 2015 (GoBD) any digital handling of
> business process related data has to be, in essence, unchangeable, or
> safe from being manipulated. Therefore requirements to an ERP from the
> legislator/regulator standpoint of view are now stricter.
>
> These requirements are:
> * book entries or records must not be changed in such a way that
> their original content cannot be retrieved or determined any more,
> * later changes are to be made in such a way, that the original
> content as well as the fact that changes were made, are recognizable,
> * when master data is changed, the distinct meaning in the according
> transaction data has to be recognizable afterwards.

I think that these 2 features should meet the legal requirements but
maybe except for the requirement that is defined by 'unchangeable'. All
the data is stored in a database and i do not see any proper technical
way how to make the content of it 'unchangeable'. For me the GoBD are
are quite vague about this term.


[1]
http://doc.tryton.org/4.0/trytond/doc/ref/models/models.html?highlight=history#trytond.model.ModelSQL._history
[2]
http://doc.tryton.org/4.0/trytond/doc/ref/models/fields.html?highlight=datetime_field#many2one

[Cédric Krier]

On 2016-10-04 14:48, 'Korbinian Preisler' via tryton wrote:
> > Background: in Germany since 2015 (GoBD) any digital handling of
> > business process related data has to be, in essence, unchangeable, or
> > safe from being manipulated. Therefore requirements to an ERP from the
> > legislator/regulator standpoint of view are now stricter.
> >
> > These requirements are:
> > * book entries or records must not be changed in such a way that
> > their original content cannot be retrieved or determined any more,
> > * later changes are to be made in such a way, that the original
> > content as well as the fact that changes were made, are recognizable,
> > * when master data is changed, the distinct meaning in the according
> > transaction data has to be recognizable afterwards.
> I think that these 2 features should meet the legal requirements but
> maybe except for the requirement that is defined by 'unchangeable'. All
> the data is stored in a database and i do not see any proper technical
> way how to make the content of it 'unchangeable'. For me the GoBD are
> are quite vague about this term.

Indeed what does Tryton is to prevent any change on posted move. But
this is an application constraint so it is always possible to overrule
this constraint by hacking the system. Indeed guarantee the immutability
of records will need to sent the data (or a hash) to a trusted party.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Pa Wa]

Thank you for your reply.

Am Dienstag, 4. Oktober 2016 14:49:20 UTC+2 schrieb Timitos:

> These requirements are:
>   * book entries or records must not be changed in such a way that
> their original content cannot be retrieved or determined any more,
>   * later changes are to be made in such a way, that the original
> content as well as the fact that changes were made, are recognizable,
>   * when master data is changed, the distinct meaning in the according
> transaction data has to be recognizable afterwards.
I think that these 2 features should meet the legal requirements but
maybe except for the requirement that is defined by 'unchangeable'. All
the data is stored in a database and i do not see any proper technical
way how to make the content of it 'unchangeable'. For me the GoBD are
are quite vague about this term.

According to the GoBD Guidlines [1], pages 28-29, 'unchangeable' (that is how I've translated) means:

'The electronic data processing procedure must guarantee, that all information (programs and data stock), which has been introduced once into the data processing process (receipt, entry, etc.), cannot be aborted/suppressed or rewritten without an identification as such, deleted, edited or falsified/manipulated, too. Already inserted information into the data processing procedure is not allowed to be replaced by new data without proper identification.' 

Measures to prevent such manipulation can be on the hardware and on the software side.

Software measures listed there are: 'Safeguarding or backup (depends on the translation and intention of the guideline itself), blocking, locking up, erase marker, automatic logging, versioning, historicizing.'

This is to be regarded as a 'should'-requirement.

The guideline comments on this as follows, p. 32:

By using of additional internal safety measures (checksums, validity check, system protocols/logs, technical authorisation, etc.) attempts of manipulation of data "bypassing the planned process" can be prevented in most cases or at least be detected.'

I have never had the pleasure of a tax audit, so I have no experience at all with the tax auditors/inspectors in Germany. Penalties can be very considerable if you are a small and medium-sized company.

[1] https://www.psp.eu/media/allgemein/GoBD-Leitfaden_Version_2_0_FINAL.pdf

[Korbinian Preisler]

I agree that this is an option.

[Korbinian Preisler]

On 04.10.2016 16:00, Pa Wa wrote:

[1] https://www.psp.eu/media/allgemein/GoBD-Leitfaden_Version_2_0_FINAL.pdf
>
This is a nice document. Thx for the link.
But be careful. This is not a legal document but a personal
interpretation of the GoBD by the authors which are tax advisors. So the
interpretation may or may not match the interpretation of the jurisdiction.

[Pa Wa]

Thank you all for your replies.

Of course are those guidelines just a mere interpretation from a group of lawyers. However, their guidelines are the most comprehensive ones I've seen on this topic.

By the way, are there comparable requirements in countries other than Germany where Tryton is used? What experience do you have?

[Cédric Krier]

On 2016-10-05 07:20, Pa Wa wrote:
> By the way, are there comparable requirements in countries other than
> Germany where Tryton is used? What experience do you have?

For what I know. French in 2017 will introduce also similar requirements
but there is discussion about the interpretation. In Belgium, there is a
requirement for POS but it is solved with a black box.