Tryton - Issues

 

Issue6830

Title Add retention on different receivable account
Priority feature Status chatting
Superseder Nosy List ced, risto3
Type feature request Components account_invoice
Assigned To Keywords
Reviews

Created on 2017-10-07.19:11:27 by risto3, last changed by ced.

Files
File name Uploaded Type Edit Remove
p7_Compta_et_Retenues_de_garanties_0812.pdf risto3, 2017-10-07.19:11:26 application/pdf
Messages
msg36278 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-13.21:51:28
On a second thoughts, I guess you tried to point that the retention amount may not be just a percentage of the invoice. And I can understand if you have create invoices for advance payment and you deduct them on the final invoice, the percentage should be based on the amount before the advance payment deduction.
As we can not know what is an advance payment or not, the payment term could not be used.
So I think the best solution is to create a new module 'account_invoice_retention' which adds a retention amount, account and duration on the invoice. This amount will be used to modify the move by deducing it from the total (before calling payment term) and add a line to the account at the computed date (using the duration and the invoice date).
msg36277 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-13.20:47:55
I do not care how you manage it. You can use sale_advance_payment if you like it, you can make manual invoice if you prefer. It is really not the point of Tryton.
What we care about is to support most common business practices like the retention for guarantee. To support it in a generic way, we need to implement msg36271.
Now I have spent enough time on this topic, I will only review patch.
msg36276 (view) Author: [hidden] (risto3) Date: 2017-10-13.20:39:04
If I understand correctly, you wish that the sale is made and that the 5% RG is simply a condition on the total. Then use the due date tool to fix up the due date.

But this seems to only work with extremely short term projects having a single full invoice. 

That is, once processed it's all or nothing. Also, it appears to actually generate two invoices. There should only be a single invoice generated for this case.
msg36274 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-13.15:56:28
You make a full invoice with negative line for previous advance payments like sale_advance_payment does.
msg36273 (view) Author: [hidden] (risto3) Date: 2017-10-13.15:26:56
> The only missing part is a way to define a different account than the default 
> receivable of the invoice. It will require to change the API of the compute 
> method to return the account for each term. The only difficulty is that payment 
> term are not company specific but the account is, so it should probably use a 
> MultiValue field or a configuration option…

How to treat for the restitution of the RG...

Simple example, a project is halfway into its second year with advancement at 80% so the company decides to replace the RG with a bank guarantee for liquidity purposes.

The total RG applied on the previous invoices (say 8 monthly invoices have been issued so far, all with RG) needs to be restituted.

That is, this is not a percentage of the current invoice but a percentage of the previous emitted invoices.
msg36272 (view) Author: [hidden] (risto3) Date: 2017-10-13.15:09:01
Perhaps I omitted mentioning, the French accounts for suppliers are 4017xx (typical for subcontractor-type suppliers) and 4047xx which is necessary for the suppliers of assets to be immobilised (such as for the company's personal construction works)
msg36271 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-13.14:59:02
You only need on payment term with 2 lines:

- first: 5% in 1 year
- second: remaining today (or what ever)

The only missing part is a way to define a different account than the default receivable of the invoice. It will require to change the API of the compute method to return the account for each term. The only difficulty is that payment term are not company specific but the account is, so it should probably use a MultiValue field or a configuration option…
msg36270 (view) Author: [hidden] (risto3) Date: 2017-10-13.14:49:02
Guess I'm myopic as I only see where one payment term can be stipulated.
Do you mean it's feasible to make these one2many and have the terms be attached to a class 4 account? Seems somewhat convoluted...

I believe it is more intuitive to treat these as an additional 'other_info' on the invoice where an RG can be retained on the current invoice or previous RG's liberated as the case may be.
msg36269 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-13.13:16:45
I do not agree with you. The proper solution is to extend payment term.
msg36268 (view) Author: [hidden] (risto3) Date: 2017-10-13.13:07:01
My first observation on sale_advance payment is that advance payment terms seem to limit as well the account to revenue accounts (class 7) so this seems not to advance things at all. (maybe I misunderstood your proposal?)

However, it does look like an appropriate basis that we can use to deal with the interim monthly situation invoices, though, as long as we can create them on the fly and are able to deal with partial quantities as well... but that's out of scope for this particular issue.

So, in the meanwhile, I see https://bugs.tryton.org/msg36159 as the only currently viable solution (at least for France).
msg36267 (view) Author: [hidden] (risto3) Date: 2017-10-13.10:36:17
I was not aware that the sale_advance_payment module would do anything like that as the name implies something more like a down payment which is somewhat the opposite of the subject at hand.

As long as the movement can be made including the RG account, then that might work. That is legally necessary and cannot be avoided.

I'll look into it this weekend, but any hints as to your reasoning would be appreciated.
msg36264 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-13.09:56:20
I see nothing that can not be managed by the proposed solution and the sale_advance_payment or account_deposit module.
msg36262 (view) Author: [hidden] (risto3) Date: 2017-10-13.02:25:46
I believe you should refer to a certified accountant to explain to you public works projects (and similar) where these holdbacks (or retention guarantees) may be involved.

There are monthly advancement invoices (in France they are typically called situations) so if the project is for example roughly 18 months long, at the reception there is finally a fixed date from which 12 months later the RG's will be eligible for liberation (providing there are no remaining unresolved reserves upon the work delivered).

There is also the case where sometime between the first monthly invoice and the final comprehensive invoice that the contractor decides to replace the RG with a guarantee backed by a financial institution, whereupon he can make the total amount so far retained exigible again.

The RG's link with the invoice is the amount retained as guarantee which is always a percentage, typically 5% TTC, and naturally the invoice's amount payable is reduced by that RG.

BTW, there are other temporary contractual retentions possible, but these are resolved as potential financial penalties whereas only the RG can extend beyond the general and definitive settlement of accounts, aka DGD (which also recaps the amount in RG if any).
msg36258 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-13.00:27:58
I do not see any explanation here.
Also I do not agree that the retention has no link to the invoice, to reclaim you must know for which work it is so you need to know which invoice.
I do not understand why you are talking about a unknown date because it is specified that a maximum of 1 year is allowed.
msg36257 (view) Author: [hidden] (risto3) Date: 2017-10-12.19:33:13
Unfortunately this is insufficient, at least for France.
Once the retention has been made, it really has no longer any specific connection with the invoice, as it is a financial guarantee for the project deliverables.
If it were an unknown date or unrelated to a specific contract, it would be  immobilised perhaps in 2761xx
msg36161 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-09.10:06:48
We have already a tool to define due date on receivable lines, we should use it and extend it. There is no need to add another concept on the invoice for it.
About the taxes, the feature [1] should make it work correctly.

[1] https://discuss.tryton.org/t/tax-report-on-cash-basis/15
msg36159 (view) Author: [hidden] (risto3) Date: 2017-10-09.07:29:55
Let's calm down and separate the issue... 
invoice/lines and subsequently move/lines generated.

What about adding an optional relation such as 'retention account' to Invoice which must be the same kind as the invoicing account, plus a field 'retention percentage'.

This would preserve the invoice model and existing domains.

The move lines generated could then be as indicated in the previous messages.

This can be implemented in a separate module.

The migration needs a bit of logic, but I don't expect any real difficulty.
I'll try this out during the week.

What I do prefer about this approach is that the TVA on the retention can be more easily isolated and managed separately.
msg36158 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-09.01:00:08
On 2017-10-08 23:36, richard wrote:
> >On 2017-10-08 18:30, richard wrote:
> >> I don't believe so.
> >> 
> >> In the French PCG, 411xx is exigible. 4117 is not.
> 
> >It is but 1 year later.
> 
> One year from a future reception date. There may be dozens of invoices
> issued in between. But that is not the point. It is a legal
> withholding for guarantee purposes as provided by law (civil and
> contract) as well as by the French PCG.  It's even in the Lefebvre I
> provided to the tryton association.

I do not see the point at all.

> >> It's like an immobilisation for a portion of the invoice, that extends
> >> (in the case of construction projects) 12 months from the date of the
> >> formal delivery of the project. 
> >
> >So it is just a receivable with a due date 12 months later.
> 
> Yes, but the invoice lines only accept 'revenue' (for clients) or
> 'expense' (for suppliers).  Are you saying that 'receivable' should be
> added to the domain list instead of a new type?

Not at all. I already said that it should not be an invoice line. One
more reason it should not is that the hold-back is on the amount tax
included.

> >> At that point it is possible to move the holdbacks back into 411xx
> >> (typically when sending the reminder that the sum total of holdbacks
> >> operated is becoming exigible).
> 
> >I do not see the point to move it back, just claim it due at the right
> >date using the due date.
> >This may be needed for manual accounting but with a system like Tryton,
> >it can follow a due date.
> 
> I don't follow you here and I believe you may misunderstand the
> operation being discussed...

I do not think. As I said it is almost like a payment term except that
it needs to have a different account.

> >> I'd like to see the simple patches I have come at least into
> >> account_fr if you don't want global integration yet. It is minimal but
> >> necessary, and only those account plans that have an account kind ==
> >> 'holdback' is affected. (ps I sorta like the 'retention' term as used
> >> in the EC document too)
> >
> >I'm against adding a new kind because it adds complexity for a special
> >case that should be configured any way by an accountant once.
> 
> I don't follow you here either... this is not a special case. 
> It is currently no more than an anomalous situation where tryton is
> not permitting importation of audited accounting records established
> following generally accepted accounting principles used in France
> without 'fixing' something.

You are wrong. You try to make a wrong importation of an invoice using
the wrong data model. Tryton is correct to refuse you to do so.
You must not use an invoice line with hold-back.
You must create a move between the two receivable accounts.
msg36157 (view) Author: [hidden] (risto3) Date: 2017-10-08.23:36:26
>On 2017-10-08 18:30, richard wrote:
>> I don't believe so.
>> 
>> In the French PCG, 411xx is exigible. 4117 is not.

>It is but 1 year later.

One year from a future reception date. There may be dozens of invoices
issued in between. But that is not the point. It is a legal withholding for guarantee purposes as provided by law (civil and contract) as well as by the French PCG.
It's even in the Lefebvre I provided to the tryton association.

>> It's like an immobilisation for a portion of the invoice, that extends
>> (in the case of construction projects) 12 months from the date of the
>> formal delivery of the project. 
>
>So it is just a receivable with a due date 12 months later.

Yes, but the invoice lines only accept 'revenue' (for clients) or 'expense' (for suppliers).  Are you saying that 'receivable' should be added to the domain list instead of a new type?

>> At that point it is possible to move the holdbacks back into 411xx
>> (typically when sending the reminder that the sum total of holdbacks
>> operated is becoming exigible).

>I do not see the point to move it back, just claim it due at the right
>date using the due date.
>This may be needed for manual accounting but with a system like Tryton,
>it can follow a due date.

I don't follow you here and I believe you may misunderstand the operation being discussed...

>> I'd like to see the simple patches I have come at least into
>> account_fr if you don't want global integration yet. It is minimal but
>> necessary, and only those account plans that have an account kind ==
>> 'holdback' is affected. (ps I sorta like the 'retention' term as used
>> in the EC document too)
>
>I'm against adding a new kind because it adds complexity for a special
>case that should be configured any way by an accountant once.

I don't follow you here either... this is not a special case. 
It is currently no more than an anomalous situation where tryton is not permitting importation of audited accounting records established following generally accepted accounting principles used in France without 'fixing' something.
msg36145 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-08.20:09:25
On 2017-10-08 18:30, richard wrote:
> I don't believe so.
> 
> In the French PCG, 411xx is exigible. 4117 is not.

It is but 1 year later.

> It's like an immobilisation for a portion of the invoice, that extends
> (in the case of construction projects) 12 months from the date of the
> formal delivery of the project. 

So it is just a receivable with a due date 12 months later.

> At that point it is possible to move the holdbacks back into 411xx
> (typically when sending the reminder that the sum total of holdbacks
> operated is becoming exigible).

I do not see the point to move it back, just claim it due at the right
date using the due date.
This may be needed for manual accounting but with a system like Tryton,
it can follow a due date.

> I'd like to see the simple patches I have come at least into
> account_fr if you don't want global integration yet. It is minimal but
> necessary, and only those account plans that have an account kind ==
> 'holdback' is affected. (ps I sorta like the 'retention' term as used
> in the EC document too)

I'm against adding a new kind because it adds complexity for a special
case that should be configured any way by an accountant once.
msg36144 (view) Author: [hidden] (risto3) Date: 2017-10-08.18:30:22
I don't believe so.

In the French PCG, 411xx is exigible. 4117 is not.

It's like an immobilisation for a portion of the invoice, that extends (in the case of construction projects) 12 months from the date of the formal delivery of the project. 

At that point it is possible to move the holdbacks back into 411xx (typically when sending the reminder that the sum total of holdbacks operated is becoming exigible).

NB: The work *has* been invoiced, it is just part of the sum that is retained for guarantee. 

Also, it can be replaced by a bank guarantee, but the timing of if/when to do that is left up to the [sub]contractor and cannot be imposed.

BTW, this is also becoming more generalised (at least in Europe). In particular I checked The Netherlands and Belgium, primarily concerning government contracts, but can indeed be stipulated in private contract terms and conditions as well.

This doesn't mean the national accounting plans have specifically made provisions for this such as the case with France.

Here is an EC link:
http://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX%3A32015R2462
(I added 'en' for this discussion)
"(26) It is necessary to provide for the option of a performance guarantee in relation to works, supplies and complex services in order to guarantee compliance with substantial contractual obligations and to ensure proper performance throughout the duration of the contract. It is also necessary to provide for a retention money guarantee to cover the contract liability period, in line with customary practice in these sectors."

(note the above last phrase, then drop down to Article 165 bis)

I'd like to see the simple patches I have come at least into account_fr if you don't want global integration yet. It is minimal but necessary, and only those account plans that have an account kind == 'holdback' is affected. (ps I sorta like the 'retention' term as used in the EC document too)
msg36143 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-10-08.14:34:31
I do not know what you have done but an hold-back should be very similar to the payment term. For me, it will be wrong to put it as an invoice line so the kind should not be a revenue.
Also it should stay as receivable to be part of the amount to receive from the party.
I mark it as a feature request because it is possible to manage those operations manually (if not done when invoicing).
msg36142 (view) Author: [hidden] (risto3) Date: 2017-10-08.13:31:08
I quickly prototyped this and it seems to work okay for my particular case.
Patches available upon request.
msg36135 (view) Author: [hidden] (risto3) Date: 2017-10-07.19:11:26
I'm getting a domain exception in validate_relation_domain when
trying to import invoices with holdbacks (retenue de garantie or RG in French).

  File "/home/richard/src/openerp2tryton/baou/migration.py3", line 1208, in migrate_invoice
    invoice.save()
  File "/usr/lib/python3.6/site-packages/proteus-4.4.1-py3.6.egg/proteus/__init__.py", line 101, in newfunc
    return self.func(owner, [instance], *args, **kwargs)
  File "/usr/lib/python3.6/site-packages/proteus-4.4.1-py3.6.egg/proteus/__init__.py", line 758, in save
    ids = proxy.create(values, context)
  File "/usr/lib/python3.6/site-packages/proteus-4.4.1-py3.6.egg/proteus/config.py", line 172, in __call__
    result = rpc.result(meth(*args, **kwargs))
  File "/opt/trytond/trytond/model/modelsql.py", line 595, in create
    field.set(cls, fname, *fargs)
  File "/opt/trytond/trytond/model/fields/one2many.py", line 217, in set
    Target.create(to_create)
  File "/opt/trytond/trytond/modules/account_invoice/invoice.py", line 1935, in create
    return super(InvoiceLine, cls).create(vlist)
  File "/opt/trytond/trytond/model/modelsql.py", line 604, in create
    cls._validate(sub_records)
  File "/opt/trytond/trytond/model/modelstorage.py", line 992, in _validate
    validate_domain(field)
  File "/opt/trytond/trytond/model/modelstorage.py", line 951, in validate_domain
    validate_relation_domain(field, sub_records, Relation, domain)
  File "/opt/trytond/trytond/model/modelstorage.py", line 974, in validate_relation_domain
    error_args=cls._get_error_args(field.name))
  File "/opt/trytond/trytond/error.py", line 74, in raise_user_error
    raise UserError(error)
trytond.exceptions.UserError: <unprintable UserError object>

The RG account root for clients is 4117xx in the French account plan and is not a 'revenue' account but is currently defined as 'receivable' thus generating an exception during invoice line validation

        <record model="account.account.template" id="4117">
            <field name="name">Clients - Retenues de garantie</field>
            <field name="code">4117</field>
            <field name="type" ref="creances_clients"/>
            <field name="deferral" eval="True"/>
            <field name="kind">receivable</field>
            <field name="party_required" eval="True"/>
            <field name="reconcile" eval="True"/>
            <field name="parent" ref="411"/>
        </record>
 
Holdbacks (or RG's) are commonly recorded directly in invoices or demands for advances in construction and other services industries in France where specified by the contract being executed.

I attach a representative example from tissot:Comptabilité et Retenues de garanties, Livre blanc 2012.

Perhaps a 'holdback' type should be created that could be used for these accounts in order to specifically allow for holdback accounts to be included in invoice domain...
History
Date User Action Args
2017-10-13 21:51:29cedsetmessages: + msg36278
2017-10-13 20:47:55cedsetmessages: + msg36277
2017-10-13 20:39:04risto3setmessages: + msg36276
2017-10-13 15:56:28cedsetmessages: + msg36274
2017-10-13 15:26:56risto3setmessages: + msg36273
2017-10-13 15:09:01risto3setmessages: + msg36272
2017-10-13 14:59:03cedsetmessages: + msg36271
2017-10-13 14:49:02risto3setmessages: + msg36270
2017-10-13 13:16:45cedsetmessages: + msg36269
2017-10-13 13:07:01risto3setmessages: + msg36268

Showing 10 items. Show all history (warning: this could be VERY long)