About removing journal from accounting

From this discussion, I started to have the idea that journal in an ERP is not really useful. This is a legacy from manual booking to organize physically the writings.
For now in Tryton, the journals are used for very few things:

  • provide the sequence for numbering the moves (as default value) which is fixed by XML to the same sequence for all standard journals.

  • provide a way to close partially a period per journal. This is a quite advanced feature for large setup with multiple accountant.

  • provide a report for cash journal. But Cash flow forecast is probably a better solution.

  • provide a criteria for analytic rules.

Of course, we have journal field scattered all over the accounting modules just to get a value when a procedure needs to create a move.

My proposal would be to move all the journal references to a specific module (e.g. account_journal). This module will add the journal on the move and customize the filling of the number with criteria (like Allow different invoice sequences on the same period propose for invoice). It will also add journal for others modules.
Another advantage for this separation would be that we do no more need to create default journals by XML to get a working system out of the box. But this will be a manual operation if and only if this new module would be activated.

Another point is that the invoice for now choose randomly a journal when the invoice is created. This is for manual but also generated invoices.
In case of moving to a dedicated module, we could have a rule engine to set the journal or simply make it required only for posting.

Indeed I’ve have been asked several times about what’s a journal and which is it’s usage. On which I normally give this answer:

Having said that I think it will a very nice feature to be able to activate or deactivate the journal feature. For my experience I see that the journals are ignored from basic usage as it works out of the box with the default created values.

I agree that the cash flow forecast will be a good replacement. Personally I’ve never found the current cash journal usefull, so I don’t have any problem about removing this feature until the forecast is implemented.

That sound good to me, but I’m a little bit worried about the “Type” field of Journal which restricts the usage of the journal. Do you think we should keep this restriction on the new module? For me it makes sense to at least relax this constraint allowing several usages for the same journal. This can be achieved by using the new multiselection field.

I like this idea as the journal is only used when posting the invoice.

I think we could use the same design as for account type: a list of check boxes.

Personally, at first glance, this could be problematic… guess it depends on where it really changes desired outputs.

Accounting is always based upon journals. It is a simple matter of organization.

For example, today our public auditor asked for our works sales journal for january to september.
I am amazed that we cannot even [out-of-the-box] generate a standard report to do this!
Also, we’re getting ready to split out a couple of journals to in order to simplify things more, at the same time allowing us to split the sequences which [French] law allows us to do in these cases.

BTW, if currently ‘random’ journals are chosen, it is a bug and should be resolved.
It is nearly equivalent to randomly choosing accounts, which I doubt any public accountant or auditor would accept.

For the Spanish case, I fail to see any indication that these entries must be made in the same journal.
My hunch is that the cases are similar as in French law where using distinct journals is more than useful in getting things done in a standard, reliable and explicable manner (NB: in case of audit).

Please tread softly and research thoroughly. 2cts.

I totally agree with Richard. In Italy, for example, there is no journal requirement, but you have VAT journals, usually built as report from financial accounting. But for other accounting environments they are mandatory or required in the entry process. That’s the reason ERP usually organize data in journals. If you eliminate them you still need categories in which group documents/entries.

Which information is shown on VAT journals? Is it something similart to Allow to export book of issued and received Invoices (#8701) · Issues · Tryton / Tryton · GitLab ?

The information is similar to the spanish:

  • sales VAT journal: number, date, taxable amt, tax with breakdown per tax
  • purchases VAT journal: number, date, legal identification of the seller, taxable amt, tax with breakdown per tax
    For the latter, there should be a sequential number, that’s optional with the electronic invoice.
    But my point is that journals should NOT be kept just because they are legally -or for tax purposes- required (for cash and bank you have no legal obligation to do so) but because they are a powerful tool for accounting.
    Marco

I do not see what the accounting journal of Tryton has to do with such report. For example, the EC sales list is implemented without using at the journal.

I was just answering to Sergi. I clearly stated that accounting journals should NOT be kept for tax reporting. They are an ERP functionality. If you take them away your accounting will be driven by your documents. That will need to be grouped, or classified an so on. My advice is to keep the accounting journals to manage different accounting uses.

Indeed we do not plan to remove them, but to make them optional by moving it to a separate module. This way the users who need this functionality can activate them but we remove the need of having journals for uses that do not need them.

Yes, I get it. I only say that, just like you are saying, it’s a matter of what kind of business application you want.
Should be the journal a “native” and mandatory feature of the entry or should it be optional?
In the present approach, if I state that the sales in cyprus go to the “sales in cyprus journal” all the entries must stick to this rule.
Of course there could be infinite ways to group and classify the sales afterwards…
Now, let’s put in another way: one of the most important topic among finance managers today is fast closing, and one of the requirements is an “enterprise class accounting system”.
Fast closing needs a clean, ordered, and rigid procedure.
Well, optional journals would be more “flexible”, but would they meet the requirements a finance manager actually needs (in today’s accounting world) to fast-close financial statements?

I think so. Indeed this topic is a good place to start describing this requirements so we can implement it as part of the new module.

Ok. To classify the accounting moves you use pre-determined information like accounts and analytical accounts you assign to your numeric values when you record the entry.
Then you’ll have all the use cases that require you to classify entries.
Several ERP software aim to classify processes, and create something like GL-category, and so on.
Tryton has journals.
If you remove journals then you’ll have to think to a new way to classify entries.
For example you could retrieve information from documents, then tryton would be a little like a CMS…
But, definitely, why complicate things? Journals simply work…

Let’s try to have a comprehensive view. Considering that tryton is meant to be an enterprise class software, let’s take into consideration the auditing principles.
The International Standard on Auditing 315, about risks of misstatement, indicates levels at which to identify such risks. Well, they are:

  • financial statement level
  • class of transaction level
  • account level
  • disclosures.

Classes of transactions can actually be identified in tryton with journals/ groups of journals, making tryton fully compliant for auditing purposes. Journals are nothing else than classes of transactions.
Of course we could make something more “flexible”, but auditing requires a minimum of stability.

This is no more the case since Better way to set default journal (#11884) · Issues · Tryton / Tryton · GitLab

So I’m wondering if instead of removing the journal, we should not simply:

  • convert type into check boxes (like in account type)
  • remove the requirement for sequence (with fallback to a configured sequence)

This will makes the journal usage almost transparent for small companies.

I will prefer to make it optional to a separate module instead of making it transparent.
For people that do not want to use it having a journal field in most of the accounting models causes confusion. Sometimes people will try to fill it despite not beeing required and this adds complexity that can be removed when making it optional.

For me the main problem to make it optional is that the activation of the journal later can not be managed smoothly.

So having good default that makes it transparent seems the best option just like for example we keep currency field even for companies dealing with only one currency.

But the main problem now is that we require a journal for everything and a different type should be used.

For example, when creating a WriteOff method, a new journal of type write-off is needed and that causes confusion to the users.

How should we manage such process? By creating a generic journal that will be used for everything or by just using a default journal as fallback?

We can have a default journal created for write-off.