About removing invoice/credit note type

[Cédric Krier]

Hi,

I was discussing about issue5016 [1] which is indeed a continuation of
issue4410 [2] and I came with the idea that we should remove the
invoice/credit_note type on the Invoice object.
Such types are really a big constraint that prevent us to generate mixed
documents (half invoice and half credit note).

So the idea will be to migrate the credit note to negate the quantity
and keep in type only 'in' / 'out' (aka 'supplier' / 'customer').

The only difficulty will be for the sequence. Until now, we have the
possibility to use different sequences for invoice and credit note. I
think the way to manage such change will be to warn early enough users
that such configuration will no more be possible in the future and so
people should configure the next fiscalyear by using unique sequence for
both types in prevision of the future migration.

So what do you think?

[1] https://bugs.tryton.org/issue5016
[2] https://bugs.tryton.org/issue4410
--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Albert Cervera i Areny]

2015-10-20 18:38 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> Hi,
>
> I was discussing about issue5016 [1] which is indeed a continuation of
> issue4410 [2] and I came with the idea that we should remove the
> invoice/credit_note type on the Invoice object.
> Such types are really a big constraint that prevent us to generate mixed
> documents (half invoice and half credit note).
>
> So the idea will be to migrate the credit note to negate the quantity
> and keep in type only 'in' / 'out' (aka 'supplier' / 'customer').
>
> The only difficulty will be for the sequence. Until now, we have the
> possibility to use different sequences for invoice and credit note. I
> think the way to manage such change will be to warn early enough users
> that such configuration will no more be possible in the future and so
> people should configure the next fiscalyear by using unique sequence for
> both types in prevision of the future migration.

We need both sequences in Spain as it is a legal requirement [1]. Yet,
it should not be all that difficult to choose the sequence depending
on the sign of the invoice.

> So what do you think?

It has some advantages and simplifies things. Specially makes
supporting the negative quantities/amounts from sales much simpler.


[1] http://www.agenciatributaria.es/static_files/AEAT/DIT/Contenidos_Publicos/CAT/AYUWEB/Biblioteca_Virtual/Manuales_practicos/Facturacion_y_libros_registro_IVA/manual_facturacion_2011_es_es.pdf

>
> [1] https://bugs.tryton.org/issue5016
> [2] https://bugs.tryton.org/issue4410
> --
> Cédric Krier - B2CK SPRL
> Email/Jabber: cedric...@b2ck.com
> Tel: +32 472 54 46 59
> Website: http://www.b2ck.com/

--
Albert Cervera i Areny
Tel. 93 553 18 03
@albertnan
www.NaN-tic.com

[Cédric Krier]

On 2015-10-20 19:07, Albert Cervera i Areny wrote:
> 2015-10-20 18:38 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> > Hi,
> >
> > I was discussing about issue5016 [1] which is indeed a continuation of
> > issue4410 [2] and I came with the idea that we should remove the
> > invoice/credit_note type on the Invoice object.
> > Such types are really a big constraint that prevent us to generate mixed
> > documents (half invoice and half credit note).
> >
> > So the idea will be to migrate the credit note to negate the quantity
> > and keep in type only 'in' / 'out' (aka 'supplier' / 'customer').
> >
> > The only difficulty will be for the sequence. Until now, we have the
> > possibility to use different sequences for invoice and credit note. I
> > think the way to manage such change will be to warn early enough users
> > that such configuration will no more be possible in the future and so
> > people should configure the next fiscalyear by using unique sequence for
> > both types in prevision of the future migration.
>
> We need both sequences in Spain as it is a legal requirement [1].

Could you point to which page?

> Yet,
> it should not be all that difficult to choose the sequence depending
> on the sign of the invoice.

I think if you have really this constraint, this means that you can not
mix positive and negative lines on the same document otherwise it is not
consistent.

> > So what do you think?
>
> It has some advantages and simplifies things. Specially makes
> supporting the negative quantities/amounts from sales much simpler.
>
>
> [1] http://www.agenciatributaria.es/static_files/AEAT/DIT/Contenidos_Publicos/CAT/AYUWEB/Biblioteca_Virtual/Manuales_practicos/Facturacion_y_libros_registro_IVA/manual_facturacion_2011_es_es.pdf

[Jordi Esteve]

El 20/10/15 a les 19:24, Cédric Krier ha escrit:

On 2015-10-20 19:07, Albert Cervera i Areny wrote:

2015-10-20 18:38 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:

Hi,

I was discussing about issue5016 [1] which is indeed a continuation of
issue4410 [2] and I came with the idea that we should remove the
invoice/credit_note type on the Invoice object.
Such types are really a big constraint that prevent us to generate mixed
documents (half invoice and half credit note).

So the idea will be to migrate the credit note to negate the quantity
and keep in type only 'in' / 'out' (aka 'supplier' / 'customer').

The only difficulty will be for the sequence. Until now, we have the
possibility to use different sequences for invoice and credit note. I
think the way to manage such change will be to warn early enough users
that such configuration will no more be possible in the future and so
people should configure the next fiscalyear by using unique sequence for
both types in prevision of the future migration.

We need both sequences in Spain as it is a legal requirement [1].

Could you point to which page?

Page 23:

====
Número y, en su caso, serie. La numeración de las facturas dentro de cada serie debe ser correlativa

Es obligatoria, en todo caso, la expedición en series específicas de las facturas siguientes:

- Las rectificativas.

====

As Albert has said, credit notes could be removed and replaced by different invoice sequences, like account_invoice_multisequence module [1] does.

Yet,
it should not be all that difficult to choose the sequence depending
on the sign of the invoice.

I think if you have really this constraint, this means that you can not
mix positive and negative lines on the same document otherwise it is not
consistent.

It depends, Spanish legal requirements for credit notes are strict (page 38); summarizing credit notes in Spain must come from previous invoices. But you can have negative amounts in sales/purchases and generate a single invoice with mixed positive/negative amounts.


[1] bitbucket.org/trytonspain/trytond-account_invoice_multisequence

-- 
Jordi Esteve
Consultor Zikzakmedia SL
jes...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

[Cédric Krier]

This doesn't say that invoice and credit note must have a different
sequence.
But of course, customization of the invoice numbering will still be
possible. But they will have also to merge the two types.

> >>Yet,
> >>it should not be all that difficult to choose the sequence depending
> >>on the sign of the invoice.
> >I think if you have really this constraint, this means that you can not
> >mix positive and negative lines on the same document otherwise it is not
> >consistent.
>
> It depends, Spanish legal requirements for credit notes are strict (page
> 38); summarizing credit notes in Spain must come from previous invoices. But
> you can have negative amounts in sales/purchases and generate a single
> invoice with mixed positive/negative amounts.

So I don't see that it is a requirement to have separated sequences
for each kind.

[Raimon Esteve]

2015-10-20 21:53 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> On 2015-10-20 21:17, Jordi Esteve wrote:
>> El 20/10/15 a les 19:24, Cédric Krier ha escrit:
>> >On 2015-10-20 19:07, Albert Cervera i Areny wrote:
>> >>2015-10-20 18:38 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
>> >>>Hi,
>> >>>
>> >>>I was discussing about issue5016 [1] which is indeed a continuation of
>> >>>issue4410 [2] and I came with the idea that we should remove the
>> >>>invoice/credit_note type on the Invoice object.
>> >>>Such types are really a big constraint that prevent us to generate mixed
>> >>>documents (half invoice and half credit note).

About <<la expedición en series específicas de las facturas
siguientes>> page 23, the "series especificas" talk about
"unique/different sequences".

I asked account people for legal requiriments in Spain. I'm waiting the answer.

Raimon

[Raimon Esteve]

Confirmed. Credit note has different sequence in Spain and Catalonia.

<<Bon dia , les factures rectificatives son les d'abonament, han de
tenir una sèrie diferent>> (catalan)

Raimon

[Albert Cervera i Areny]

It does. When it says that they need to be with specific sequences, it
means that they must be different from standard invoices. "Facturas
rectificativas" is the equivalent to credit notes.

> But of course, customization of the invoice numbering will still be
> possible. But they will have also to merge the two types.
>
>> >>Yet,
>> >>it should not be all that difficult to choose the sequence depending
>> >>on the sign of the invoice.
>> >I think if you have really this constraint, this means that you can not
>> >mix positive and negative lines on the same document otherwise it is not
>> >consistent.
>>
>> It depends, Spanish legal requirements for credit notes are strict (page
>> 38); summarizing credit notes in Spain must come from previous invoices. But
>> you can have negative amounts in sales/purchases and generate a single
>> invoice with mixed positive/negative amounts.
>
> So I don't see that it is a requirement to have separated sequences
> for each kind.
>

Indeed, in page 171 of the same document (and some other notes
elsewhere in the same document) it states that it is not possible to
have negative amounts in normal invoices if they are to invoice
returning goods. Those should always be in a "Factura rectificativa"
and should state the invoice of the goods that were delivered in the
first place.

It is my understanding that it would be possible to use a negative
amount on a line if that does not mean the returning of a good (for
example, when you have a deposit and you substract that amount on the
invoice which evantually is positive).

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

[Cédric Krier]

I think you are not looking at the important information.
In some way, we don't care how they named the document. What is
important is if there should be a clear separation between what we call
now invoice and credit note. If there is, what is the definition of an
invoice and a credit note?

[Cédric Krier]

"has" doesn't mean it is a strict requirement.
By the way, what is the definition of an Invoice and a Credit Note? If
you say they have to have a diffrent sequence, you have a way to say
which is one type and which is the other type.

[Raimon Esteve]

>> Confirmed. Credit note has different sequence in Spain and Catalonia.
>
> "has" doesn't mean it is a strict requirement.

It's strict difference between invoice and credit note.

> By the way, what is the definition of an Invoice and a Credit Note? If
> you say they have to have a diffrent sequence, you have a way to say
> which is one type and which is the other type.

1- User. 4 menus to create each invoice type.
2. Customers/Suppliers: When print an invoice report, the title change
about type invoice. Or if a party don't have a VAT (for example from
POS), the name of the invoice is "Simplified Invoice". (it's a custom
reports to legal Spain reports).

Regards.

[Nicolas Évrard]

* Albert Cervera i Areny [2015-10-20 19:07 +0200]:

>2015-10-20 18:38 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
>> Hi,
>>
>> I was discussing about issue5016 [1] which is indeed a continuation of
>> issue4410 [2] and I came with the idea that we should remove the
>> invoice/credit_note type on the Invoice object.
>> Such types are really a big constraint that prevent us to generate mixed
>> documents (half invoice and half credit note).
>>
>> So the idea will be to migrate the credit note to negate the quantity
>> and keep in type only 'in' / 'out' (aka 'supplier' / 'customer').
>>
>> The only difficulty will be for the sequence. Until now, we have the
>> possibility to use different sequences for invoice and credit note. I
>> think the way to manage such change will be to warn early enough users
>> that such configuration will no more be possible in the future and so
>> people should configure the next fiscalyear by using unique sequence for
>> both types in prevision of the future migration.
>
>We need both sequences in Spain as it is a legal requirement [1]. Yet,
>it should not be all that difficult to choose the sequence depending
>on the sign of the invoice.
>
>> So what do you think?
>
>It has some advantages and simplifies things. Specially makes
>supporting the negative quantities/amounts from sales much simpler.
>
>
>[1] http://www.agenciatributaria.es/static_files/AEAT/DIT/Contenidos_Publicos/CAT/AYUWEB/Biblioteca_Virtual/Manuales_practicos/Facturacion_y_libros_registro_IVA/manual_facturacion_2011_es_es.pdf

If I understand correctly this document in fact there is other cases
where different sequences are mandatory (rectifications, intragroup
invoices, something about the travel agencies, etc).

So wouldn't it be more clever to put the sequence on the invoice and
let the user decide what is the right sequence to use?

The question that arise is how can the system infer the correct
sequence when generating the invoice from another document. In your
case it seems to be linked both to the kind of operation
(rectifications) or party involved (intra group) or maybe even other
things (I saw a mention of "natural year" (año natural) but I don't
understand it) …

--
Nicolas Évrard - B2CK SPRL
E-mail/Jabber: nicolas...@b2ck.com

[Cédric Krier]

On 2015-10-21 12:59, Nicolas Évrard wrote:
> If I understand correctly this document in fact there is other cases
> where different sequences are mandatory (rectifications, intragroup
> invoices, something about the travel agencies, etc).
>
> So wouldn't it be more clever to put the sequence on the invoice and
> let the user decide what is the right sequence to use?
>
> The question that arise is how can the system infer the correct
> sequence when generating the invoice from another document. In your
> case it seems to be linked both to the kind of operation
> (rectifications) or party involved (intra group) or maybe even other
> things (I saw a mention of "natural year" (año natural) but I don't
> understand it) …

For sure, some countries are such mess in the requirements that probably
a generic module based on the MatchMixin to select the sequence to use
on an invoice will be welcomed.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com

[Cédric Krier]

This is not a definition. I doubt the definition talks about "4 menus".
You can not define something for Tryton based on Tryton model.

Indeed, I'm pretty sure that your requirement for different sequences is
not based at all on a distinction between invoice and credit note but
probably based on the journal (or a specific flag). The proof is that
you just introduce when trying to define invoice/credit note something
new which is "simplified invoice".

Back to the main topic, I think there are no problem for Spain that we
remove the distinction between invoice and credit note. Especially if we
keep using the right sequence based on the sign of the total amount
(different of my initial proposal).

[Jordi Esteve (Zikzakmedia)]

El 21/10/15 a les 13:05, Cédric Krier ha escrit:

> Back to the main topic, I think there are no problem for Spain that we
> remove the distinction between invoice and credit note.

Exactly, no problem to remove the distinction between invoice and credit

note.

> Especially if we
> keep using the right sequence based on the sign of the total amount
> (different of my initial proposal).
>

Your new proposal is about having two different invoice sequences, one
for positive amounts and one for negative amounts. Why?

I think the basic account_invoice module must be the most simple one, so
an unique sequence for customer invoices and another for supplier
invoices will be enough.

Take into account that in Spanish case not all the negative invoices are
credit notes. You can have normal invoices with negative amounts because
they are not returning of goods (they are not "rectifications" of
previous invoices).

[Cédric Krier]

On 2015-10-21 13:40, Jordi Esteve (Zikzakmedia) wrote:
> El 21/10/15 a les 13:05, Cédric Krier ha escrit:

> >Especially if we
> >keep using the right sequence based on the sign of the total amount
> >(different of my initial proposal).
> >
> Your new proposal is about having two different invoice sequences, one for
> positive amounts and one for negative amounts. Why?

To ease the migration because it is what we have now and I don't see how
to migrate without losing data/configuration. But if you have a
solution, please share it.

[Korbinian Preisler]

I try to write down that definition. I try to take texts from legal
documents where i was able to find the correct article. But we have to
consider that there are different definitions between commercial common
sense and tax law and this is the point where most of the confusion
comes from.

What is an invoice?

Article 220 (taken from [1])
Every taxable person shall ensure that, in respect of the
following, an invoice is issued, either by himself or by his
customer or, in his name and on his behalf, by a third party:
(1) supplies of goods or services which he has made to another
taxable person or to a non-taxable legal person;
(2) supplies of goods as referred to in Article 33;
(3) supplies of goods carried out in accordance with the
conditions specified in Article 138;
(4) any payment on account made to him before one of the
supplies of goods referred to in points (1), (2) and (3) was
carried out;
(5) any payment on account made to him by another taxable
person or non-taxable legal person before the provision of
services was completed.

So what is a credit note?

Article 224 (taken from [1])
Invoices may be drawn up by the customer in respect of
the supply to him, by a taxable person, of goods or
services, where there is a prior agreement between the
two parties and provided that a procedure exists for the
acceptance of each invoice by the taxable person supplying
the goods or services. Member State may require that such
invoices be issued in the name and on behalf of the taxable
person.

So an credit note is just an invoice, but this invoice is not created by
the company that is supplying the goods or services but from the customer.

Some more information about credit notes in:

Article 226 (taken from [1])
Without prejudice to the particular provisions laid down in this
Directive, only the following details are required for VAT
purposes on invoices issued pursuant to Articles 220 and 221:
...
(10a) where the customer receiving a supply issues the
invoice instead of the supplier, the mention
“Self-billing”;’; (taken from [2] which is an extension of [1])
...

This case is the only case where tax law is talking about a credit note.
You should look at the translations of your own country about the word
that is used for 'self-billing' there. In german it is 'Gutschrift'
which sound for me quite better translated into 'credit note' than
'self-billing'.

But now comes the interesting part. If this is the only case where tax
law talks about credit notes, how can we correct wrongly created invoice
documents?

And this is where we have to switch to commercial common sense. I you
want to correct such a document you have to create a 'cancelation'. The
german tax authority says that such a cancelation is not a credit note
in the sense of value added tax law [3](site 4 right at the beginning)

German tax authority also says that an invoice that contains lines for
goods supplied/services provided as well as goods/services that are
received from the other party the document must be called a credit
note.[3](at the end of site 3)

Please consider in your plans that a cancelation must create moves with
negative amounts instead of the positive amounts an invoice or credit
note creates.

Maybe these informations will help you to figure out if it is really
possible to remove the invoice and credit note type and only to keep the
out/in part.

I took a look into the SAP documentation and i found there the even 8
cases[4]:
ininvoice, outinvoice. increditnote, outcreditnote,
ininvoicecancelation, outinvoicecancelation, increditnotecancelation,
outcreditnotecancelation

I think we should investigate this topic really precise before making a
decision.

To your questions about the sequences i can say that it is common to
have different sequences for credit notes and invoices but that it is
(not yet) a legal requirement. But i think that if we would make a vote
about this topic i think that the vast majority of community members
would say: Please let us use different sequences for invoice and credit
note like it is now.

Cheers,
Korbinian

[1] http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32006L0112
[2] http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32010L0045
[3]
http://www.sis-verlag.de/archiv/umsatzsteuer/verwaltungsanweisungen/6724-bmf-umsatzsteuer-ausstellung-von-rechnungen-aenderungen-der-14-14a-ustg-durch-das-amtshilferichtlinie-umsetzungsgesetz-bmf-umsatzsteuer-ausstellung-von-rechnungen-aenderungen-der-14-14a-ustg-durch-das-amtshilferichtlinie-umsetzungsgesetz
(unfortunately i found this only in german docs)
[4]
http://help.sap.com/saphelp_erp60_sp/helpdata/de/0b/7e1c370246677be10000009b38f936/content.htm

--
___________________________________
virtual things
Preisler & Spallek GbR
München - Aachen

Windeckstr. 77
81375 München
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56

in...@virtual-things.biz
http://www.virtual-things.biz

[Cédric Krier]

On 2015-10-21 14:31, 'Korbinian Preisler' via tryton wrote:
> But now comes the interesting part. If this is the only case where tax
> law talks about credit notes, how can we correct wrongly created invoice
> documents?
>
> And this is where we have to switch to commercial common sense. I you
> want to correct such a document you have to create a 'cancelation'. The
> german tax authority says that such a cancelation is not a credit note
> in the sense of value added tax law [3](site 4 right at the beginning)
>
> German tax authority also says that an invoice that contains lines for
> goods supplied/services provided as well as goods/services that are
> received from the other party the document must be called a credit
> note.[3](at the end of site 3)
>
> Please consider in your plans that a cancelation must create moves with
> negative amounts instead of the positive amounts an invoice or credit
> note creates.

Cancellation already exists, it is not activate on the posted customer
invoice (but on supplier) because it is not allowed in every country.
Of course, a standard module that makes the fine tune to activate it is
welcomed.

> Maybe these informations will help you to figure out if it is really
> possible to remove the invoice and credit note type and only to keep the
> out/in part.
>
> I took a look into the SAP documentation and i found there the even 8
> cases[4]:
> ininvoice, outinvoice. increditnote, outcreditnote,
> ininvoicecancelation, outinvoicecancelation, increditnotecancelation,
> outcreditnotecancelation

As already stated having invoice/credit note distinction prevents to put
in the same document both kind of lines. And in case of such mixed
document it is name is not so trivial to determine. But we can keep the
numbering distinction using the total sign.
About the cancelation sub-type, I don't think we have to create a new
document (record in invoice table) for that. The current design is to
create a cancelation move linked to the invoice. If a specific number is
needed for customer cancelation, I guess the module (I talk above) could
add an other field to hold the number and the invoice report could be
customized to use this number.

> I think we should investigate this topic really precise before making a
> decision.
>
> To your questions about the sequences i can say that it is common to
> have different sequences for credit notes and invoices but that it is
> (not yet) a legal requirement. But i think that if we would make a vote
> about this topic i think that the vast majority of community members
> would say: Please let us use different sequences for invoice and credit
> note like it is now.

Yes it seems any way that we will have to keep for migration purpose the
two sequence field invoice/credit note. Just like we will have to keep
it for the taxes.

[Korbinian Preisler]

On 21.10.2015 15:08, Cédric Krier wrote:
> On 2015-10-21 14:31, 'Korbinian Preisler' via tryton wrote:
>> But now comes the interesting part. If this is the only case where tax
>> law talks about credit notes, how can we correct wrongly created invoice
>> documents?
>>
>> And this is where we have to switch to commercial common sense. I you
>> want to correct such a document you have to create a 'cancelation'. The
>> german tax authority says that such a cancelation is not a credit note
>> in the sense of value added tax law [3](site 4 right at the beginning)
>>
>> German tax authority also says that an invoice that contains lines for
>> goods supplied/services provided as well as goods/services that are
>> received from the other party the document must be called a credit
>> note.[3](at the end of site 3)
>>
>> Please consider in your plans that a cancelation must create moves with
>> negative amounts instead of the positive amounts an invoice or credit
>> note creates.
> Cancellation already exists, it is not activate on the posted customer
> invoice (but on supplier) because it is not allowed in every country.
> Of course, a standard module that makes the fine tune to activate it is
> welcomed.

I had a deeper look at the cancelation functionality. A legal
requirement for a cancelation is that you need to inform your customer
about the cancelation. So you need a document to do this. As the report
of the invoice is stored there is currently no way to create such a
cancelation report. But i found maybe a solution for this. See my
comments below.

>
>> Maybe these informations will help you to figure out if it is really
>> possible to remove the invoice and credit note type and only to keep the
>> out/in part.
>>
>> I took a look into the SAP documentation and i found there the even 8
>> cases[4]:
>> ininvoice, outinvoice. increditnote, outcreditnote,
>> ininvoicecancelation, outinvoicecancelation, increditnotecancelation,
>> outcreditnotecancelation
> As already stated having invoice/credit note distinction prevents to put
> in the same document both kind of lines. And in case of such mixed
> document it is name is not so trivial to determine. But we can keep the
> numbering distinction using the total sign.
> About the cancelation sub-type, I don't think we have to create a new
> document (record in invoice table) for that. The current design is to
> create a cancelation move linked to the invoice. If a specific number is
> needed for customer cancelation, I guess the module (I talk above) could
> add an other field to hold the number and the invoice report could be
> customized to use this number.

After some thoughts i agree that we do not need the cancelation sub-type
but my explanation is a little bit different to Cedrics one.
I think we already have the cancelation sub-type. I think that we just
use the currency credit note sub-type in a wrong way because it should
be the cancelation instead of the tax-law credit-note.

If we do like this many things will be possible or some others should be
done:
* Mixed documents will be possible
* The credit note like it is defined by tax law can be implemented with
a boolean field that marks the "self-billing" and that will switch the
layout of the report. As i noted in my last post there is no other
difference compared to a normal invoice.
* The Wizard 'Credit Invoice' should be renamed to 'Cancel Invoice' and
should multiply the quantities of the invoice lines with -1
* A constraint should be implemented that the total mount of an invoice
must be positive and the total amount of an cancelation must be negative

[Cédric Krier]

On 2015-11-09 16:00, 'Korbinian Preisler' via tryton wrote:
> On 21.10.2015 15:08, Cédric Krier wrote:
> > Cancellation already exists, it is not activate on the posted customer
> > invoice (but on supplier) because it is not allowed in every country.
> > Of course, a standard module that makes the fine tune to activate it is
> > welcomed.
> I had a deeper look at the cancelation functionality. A legal
> requirement for a cancelation is that you need to inform your customer
> about the cancelation. So you need a document to do this. As the report
> of the invoice is stored there is currently no way to create such a
> cancelation report. But i found maybe a solution for this. See my
> comments below.

The cancellation report is simply the invoice report as the state will be
showed as canceled (but it requires some tuning because of the report
cache, maybe an other report entry).

> > As already stated having invoice/credit note distinction prevents to put
> > in the same document both kind of lines. And in case of such mixed
> > document it is name is not so trivial to determine. But we can keep the
> > numbering distinction using the total sign.
> > About the cancelation sub-type, I don't think we have to create a new
> > document (record in invoice table) for that. The current design is to
> > create a cancelation move linked to the invoice. If a specific number is
> > needed for customer cancelation, I guess the module (I talk above) could
> > add an other field to hold the number and the invoice report could be
> > customized to use this number.
> After some thoughts i agree that we do not need the cancelation sub-type
> but my explanation is a little bit different to Cedrics one.
> I think we already have the cancelation sub-type. I think that we just
> use the currency credit note sub-type in a wrong way because it should
> be the cancelation instead of the tax-law credit-note.
>
> If we do like this many things will be possible or some others should be
> done:
> * Mixed documents will be possible
> * The credit note like it is defined by tax law can be implemented with
> a boolean field that marks the "self-billing" and that will switch the
> layout of the report. As i noted in my last post there is no other
> difference compared to a normal invoice.

I don't see the need of such field because cancellation is already
implemented.

> * The Wizard 'Credit Invoice' should be renamed to 'Cancel Invoice' and
> should multiply the quantities of the invoice lines with -1
> * A constraint should be implemented that the total mount of an invoice
> must be positive and the total amount of an cancelation must be negative

I don't see the point of having a constraint. It is not needed to work
correctly if the "type" is deducted from the sign of the amount.

[Korbinian Preisler]

On 09.11.2015 16:28, Cédric Krier wrote:
> On 2015-11-09 16:00, 'Korbinian Preisler' via tryton wrote:
>> On 21.10.2015 15:08, Cédric Krier wrote:
>>> Cancellation already exists, it is not activate on the posted customer
>>> invoice (but on supplier) because it is not allowed in every country.
>>> Of course, a standard module that makes the fine tune to activate it is
>>> welcomed.
>> I had a deeper look at the cancelation functionality. A legal
>> requirement for a cancelation is that you need to inform your customer
>> about the cancelation. So you need a document to do this. As the report
>> of the invoice is stored there is currently no way to create such a
>> cancelation report. But i found maybe a solution for this. See my
>> comments below.
> The cancellation report is simply the invoice report as the state will be
> showed as canceled (but it requires some tuning because of the report
> cache, maybe an other report entry).

If you want to do it that way another report entry will be needed.

>
>>> As already stated having invoice/credit note distinction prevents to put
>>> in the same document both kind of lines. And in case of such mixed
>>> document it is name is not so trivial to determine. But we can keep the
>>> numbering distinction using the total sign.
>>> About the cancelation sub-type, I don't think we have to create a new
>>> document (record in invoice table) for that. The current design is to
>>> create a cancelation move linked to the invoice. If a specific number is
>>> needed for customer cancelation, I guess the module (I talk above) could
>>> add an other field to hold the number and the invoice report could be
>>> customized to use this number.
>> After some thoughts i agree that we do not need the cancelation sub-type
>> but my explanation is a little bit different to Cedrics one.
>> I think we already have the cancelation sub-type. I think that we just
>> use the currency credit note sub-type in a wrong way because it should
>> be the cancelation instead of the tax-law credit-note.
>>
>> If we do like this many things will be possible or some others should be
>> done:
>> * Mixed documents will be possible
>> * The credit note like it is defined by tax law can be implemented with
>> a boolean field that marks the "self-billing" and that will switch the
>> layout of the report. As i noted in my last post there is no other
>> difference compared to a normal invoice.
> I don't see the need of such field because cancellation is already
> implemented.

Self-billing is not a cancelation.

>
>> * The Wizard 'Credit Invoice' should be renamed to 'Cancel Invoice' and
>> should multiply the quantities of the invoice lines with -1
>> * A constraint should be implemented that the total mount of an invoice
>> must be positive and the total amount of an cancelation must be negative
> I don't see the point of having a constraint. It is not needed to work
> correctly if the "type" is deducted from the sign of the amount.
>

Which "type" are you talking about?

[Cédric Krier]

Oops, yes I re-read your previous post. Indeed I see no need for such
boolean. You can consider all negative invoice as "self-billing".

> >> * The Wizard 'Credit Invoice' should be renamed to 'Cancel Invoice' and
> >> should multiply the quantities of the invoice lines with -1
> >> * A constraint should be implemented that the total mount of an invoice
> >> must be positive and the total amount of an cancelation must be negative
> > I don't see the point of having a constraint. It is not needed to work
> > correctly if the "type" is deducted from the sign of the amount.
> >
> Which "type" are you talking about?

You are talking about constraint on specific type of invoice so this
will require to put a type on the invoice. But I think it is not
necessary because the sign of the amount define the type.

[Korbinian Preisler]

I think this is a wrong approach. Self-billing is a change in process
but not a change in the document itself.

I will try to explain again the self-billing process. Consider a
supplier A delivering a product to company B. Company B is the company
that is manage by tryton.
Normally the supplier will write an invoice for this delivery. But A and
B can agree on a self-billing by the customer. The customer then will
write a 'credit note' to the supplier.
As the customer is writing the invoice for himself he does a
self-billing. But in the sense of tryton it is just an in-invoice. There
is no need to make the total amount negative.
It is just a supplier invoice. Only the process how the invoice is
written is different.

I would use the negative total amount to determine the document to be a
cancellation or not. It will make the document handling for a
cancellation easier as you only have
one report per record.

[Cédric Krier]

OK so nothing to do. Tryton already manages the manual creation of
supplier invoice.

> I would use the negative total amount to determine the document to be a
> cancellation or not. It will make the document handling for a
> cancellation easier as you only have
> one report per record.

I don't agree, negative amount is a credit note not a cancellation.
The cancellation of an invoice is managed the cancellation move. This is
the only way to ensure that the cancellation is really a cancellation.
The amounts can not be modified, the invoice can only be cancelled once
etc.

[Korbinian Preisler]

You did not yet convince me about this point. Maybe we did not yet
understand each other completely.

>> I would use the negative total amount to determine the document to be a
>> cancellation or not. It will make the document handling for a
>> cancellation easier as you only have
>> one report per record.
> I don't agree, negative amount is a credit note not a cancellation.
> The cancellation of an invoice is managed the cancellation move. This is
> the only way to ensure that the cancellation is really a cancellation.
> The amounts can not be modified, the invoice can only be cancelled once
> etc.
>

Could you please again define for me the credit note you are talking
about? What makes your credit note different from an invoice?

Could you explain me how you want to handle partial cancelation?

[Cédric Krier]

On 2015-11-09 18:21, 'Korbinian Preisler' via tryton wrote:
> > I don't agree, negative amount is a credit note not a cancellation.
> > The cancellation of an invoice is managed the cancellation move. This is
> > the only way to ensure that the cancellation is really a cancellation.
> > The amounts can not be modified, the invoice can only be cancelled once
> > etc.
> >
> Could you please again define for me the credit note you are talking
> about? What makes your credit note different from an invoice?

A "credit note" in the future design is just an invoice with an amount
negative.

> Could you explain me how you want to handle partial cancelation?

You don't because it is not possible to cancel partially an invoice
because of the rounding issue.
So you have to cancel the all invoice and create a new one with what you
did not want to cancel.
The goal of cancelling an invoice is to make like if the invoice was
never created (for the balance, the credit and the debit of accounts)
but with rounding issue of partial cancellation, this goal can not be
achieved.

[Korbinian Preisler]

Am 09.11.2015 18:45 schrieb "Cédric Krier" <cedric...@b2ck.com>:
>
> On 2015-11-09 18:21, 'Korbinian Preisler' via tryton wrote:
> > > I don't agree, negative amount is a credit note not a cancellation.
> > > The cancellation of an invoice is managed the cancellation move. This is
> > > the only way to ensure that the cancellation is really a cancellation.
> > > The amounts can not be modified, the invoice can only be cancelled once
> > > etc.
> > >
> > Could you please again define for me the credit note you are talking
> > about? What makes your credit note different from an invoice?
>
> A "credit note" in the future design is just an invoice with an amount
> negative

Can you please explain me the business case behind such a credit note? I ask this because i think that we are talking from different things and i really want to understand your plans as i think that the changes you plan are really important.

>
> > Could you explain me how you want to handle partial cancelation?
>
> You don't because it is not possible to cancel partially an invoice
> because of the rounding issue.
> So you have to cancel the all invoice and create a new one with what you
> did not want to cancel.
> The goal of cancelling an invoice is to make like if the invoice was
> never created (for the balance, the credit and the debit of accounts)
> but with rounding issue of partial cancellation, this goal can not be
> achieved.

This is not the only reason for a cancelation.

[Cédric Krier]

On 2015-11-09 19:34, 'Korbinian Preisler' via tryton wrote:
> Am 09.11.2015 18:45 schrieb "Cédric Krier" <cedric...@b2ck.com>:
> >
> > On 2015-11-09 18:21, 'Korbinian Preisler' via tryton wrote:
> > > > I don't agree, negative amount is a credit note not a cancellation.
> > > > The cancellation of an invoice is managed the cancellation move. This
> is
> > > > the only way to ensure that the cancellation is really a cancellation.
> > > > The amounts can not be modified, the invoice can only be cancelled
> once
> > > > etc.
> > > >
> > > Could you please again define for me the credit note you are talking
> > > about? What makes your credit note different from an invoice?
> >
> > A "credit note" in the future design is just an invoice with an amount
> > negative
>
> Can you please explain me the business case behind such a credit note? I
> ask this because i think that we are talking from different things and i
> really want to understand your plans as i think that the changes you plan
> are really important.

The usual usage of credit note is to correct mistakes made on invoice or
to cancel an invoice because it has no reason to exist.
This is because in many countries cancelling invoices are not allowed.

> > > Could you explain me how you want to handle partial cancelation?
> >
> > You don't because it is not possible to cancel partially an invoice
> > because of the rounding issue.
> > So you have to cancel the all invoice and create a new one with what you
> > did not want to cancel.
> > The goal of cancelling an invoice is to make like if the invoice was
> > never created (for the balance, the credit and the debit of accounts)
> > but with rounding issue of partial cancellation, this goal can not be
> > achieved.
>
> This is not the only reason for a cancelation.

Which are?

[Korbinian Preisler]

A self-billing is not a credit note you talk about. What you call a credit note is a correction of a wrongly written invoice.

But self-billing is something different. self-billing is not done to make a correction it is just a change in the process of writing an official invoice.
Instead of the supplier writing the invoice for his delivery the customer writes this invoice for himself on his own letter paper.

1. Normal case:
* Supplier delivers product
* Supplier writes invoice for this delivery

2. Self-billing case:
* Supplier delivers product
* Customer writes invoice for this delivery on his own letter paper in the name of the supplier.

This is a completely different thing than the credit note you talk about.

I think it is good to repost the part from the legal eu document:

Article 224 (taken from [1])
Invoices may be drawn up by the customer in respect of
the supply to him, by a taxable person, of goods or
services, where there is a prior agreement between the
two parties and provided that a procedure exists for the
acceptance of each invoice by the taxable person supplying
the goods or services. Member State may require that such
invoices be issued in the name and on behalf of the taxable
person.

And this article produces the current confusion:

Article 226 (taken from [1])
Without prejudice to the particular provisions laid down in this
Directive, only the following details are required for VAT
purposes on invoices issued pursuant to Articles 220 and 221:
...
(10a) where the customer receiving a supply issues the
invoice instead of the supplier, the mention
“Self-billing”;’; (taken from [2] which is an extension of [1])

Because in german "Self-billing" is translated into "Gutschrift" that is often retranslated to "Credit Note" what is wrong in our case as you are talking about the credit note in commercial common sense. To complete the confusion the credit note in commercial common sense is called "Storno" which is often translated in to "cancelation" which also does not match your understanding of a cancelation. I just want to show the difficulty what we have here with language interpretation.

 * The Wizard 'Credit Invoice' should be renamed to 'Cancel Invoice' and
should multiply the quantities of the invoice lines with -1
 * A constraint should be implemented that the total mount of an invoice
must be positive and the total amount of an cancelation must be negative

I don't see the point of having a constraint. It is not needed to work
correctly if the "type" is deducted from the sign of the amount.

Which "type" are you talking about?

You are talking about constraint on specific type of invoice so this
will require to put a type on the invoice. But I think it is not
necessary because the sign of the amount define the type.

Yes you are right. If you define the type by the sign of the amount a credit note (i call it a cancelation) will always have a negative total amount and an invoice will always have a positive amount.

I will try to sum up again the things that need to be done:
 * The invoice/credit note type will be removed
 * The self-billing like it is defined by tax law can be implemented with

a boolean field that marks the "self-billing" and that will switch the
layout of the report. As i noted in my last post there is no other
difference compared to a normal invoice.

 * The Wizard 'Credit Invoice' should should multiply the quantities of the invoice lines with -1 to produce the negative total amount
 * A credit note (which is defined by a record with a negative total amount) must produce move lines with negative amounts

For me the current cancelation functionality can be removed as it will now implemented by a credit note (which is defined by a record with a negative total amount). But i could live with it if it will be limited to the supplier side like it is now.



[1] http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32006L0112

[Timitos]

Am Montag, 9. November 2015 21:04:32 UTC+1 schrieb Timitos:

On 09.11.2015 20:18, Cédric Krier wrote:
> On 2015-11-09 19:34, 'Korbinian Preisler' via tryton wrote:
>> Am 09.11.2015 18:45 schrieb "Cédric Krier"

>>> On 2015-11-09 18:21, 'Korbinian Preisler' via tryton wrote:
>>>>> I don't agree, negative amount is a credit note not a cancellation.
>>>>> The cancellation of an invoice is managed the cancellation move. This
>> is
>>>>> the only way to ensure that the cancellation is really a cancellation.
>>>>> The amounts can not be modified, the invoice can only be cancelled
>> once
>>>>> etc.
>>>>>
>>>> Could you please again define for me the credit note you are talking
>>>> about? What makes your credit note different from an invoice?
>>> A "credit note" in the future design is just an invoice with an amount
>>> negative
>> Can you please explain me the business case behind such a credit note? I
>> ask this because i think that we are talking from different things and i
>> really want to understand your plans as i think that the changes you plan
>> are really important.
> The usual usage of credit note is to correct mistakes made on invoice or
> to cancel an invoice because it has no reason to exist.
> This is because in many countries cancelling invoices are not allowed.

Ok. Now we are talking. Everything is clear for me now. What you call a
credit note is a cancelation for me and the cancelation you talk about
is just a special case of your credit note for me.

This also explains why you do not care about the self-billing boolean as
it is not part of your concept. We can keep it out as it is not really
important for the removal of the invoice/credit note type.

I will try to answer your last posts again as you now solved my
misunderstanding.

Sorry for the wrong order of my answers. This one should be the first one of my last two messages.

[Vincent CARDON]

----- Le 9 Nov 15, à 21:11, Timitos timit...@googlemail.com a écrit :

--
Vincent CARDON, ingénieur commercial
TRANQUIL IT SYSTEMS
12 avenue Jules Verne
Bâtiment A (Alliance Libre)
44230 Saint Sébastien sur Loire (FRANCE)
tel: +33(0)240 975 755
site commercial: http://www.tranquil-it-systems.fr
site communautaire: http://dev.tranquil.it

[Cédric Krier]

On 2015-11-09 21:03, 'Korbinian Preisler' via tryton wrote:
> I will try to sum up again the things that need to be done:
> * The invoice/credit note type will be removed
> * The self-billing like it is defined by tax law can be implemented with
> a boolean field that marks the "self-billing" and that will switch the
> layout of the report. As i noted in my last post there is no other
> difference compared to a normal invoice.
> * The Wizard 'Credit Invoice' should should multiply the quantities of
> the invoice lines with -1 to produce the negative total amount
> * A credit note (which is defined by a record with a negative total
> amount) must produce move lines with negative amounts

I don't agree with this. In most countries having negative debit or
credit is at least suspicious or even forbidden. This must not be the
default behaviour of Tryton and at least it should be possible to have
a kind of invoice that inverse the debit/credit.
Negative debit/credit are done with the cancellation procedure.

> For me the current cancelation functionality can be removed as it will
> now implemented by a credit note (which is defined by a record with a
> negative total amount). But i could live with it if it will be limited
> to the supplier side like it is now.

It must stay as I said above we need to have a way to generate both kind
of move.

[Korbinian Preisler]

On 09.11.2015 23:01, Cédric Krier wrote:
> On 2015-11-09 21:03, 'Korbinian Preisler' via tryton wrote:
>> I will try to sum up again the things that need to be done:
>> * The invoice/credit note type will be removed
>> * The self-billing like it is defined by tax law can be implemented with
>> a boolean field that marks the "self-billing" and that will switch the
>> layout of the report. As i noted in my last post there is no other
>> difference compared to a normal invoice.
>> * The Wizard 'Credit Invoice' should should multiply the quantities of
>> the invoice lines with -1 to produce the negative total amount
>> * A credit note (which is defined by a record with a negative total
>> amount) must produce move lines with negative amounts
> I don't agree with this. In most countries having negative debit or
> credit is at least suspicious or even forbidden. This must not be the
> default behaviour of Tryton and at least it should be possible to have
> a kind of invoice that inverse the debit/credit.
> Negative debit/credit are done with the cancellation procedure.

Could someone point me to some information about this? I really
interested why this should be forbidden in some countries as i think
that this is a native feature of accounting and i do not see any reason
why this should be forbidden.

>> For me the current cancelation functionality can be removed as it will
>> now implemented by a credit note (which is defined by a record with a
>> negative total amount). But i could live with it if it will be limited
>> to the supplier side like it is now.
> It must stay as I said above we need to have a way to generate both kind
> of move.
>

As i said above some pointers to the reasons why this is really needed
would help me to understand this requirement.

[Cédric Krier]

On 2015-11-10 07:56, 'Korbinian Preisler' via tryton wrote:
> On 09.11.2015 23:01, Cédric Krier wrote:
> > On 2015-11-09 21:03, 'Korbinian Preisler' via tryton wrote:
> >> I will try to sum up again the things that need to be done:
> >> * The invoice/credit note type will be removed
> >> * The self-billing like it is defined by tax law can be implemented with
> >> a boolean field that marks the "self-billing" and that will switch the
> >> layout of the report. As i noted in my last post there is no other
> >> difference compared to a normal invoice.
> >> * The Wizard 'Credit Invoice' should should multiply the quantities of
> >> the invoice lines with -1 to produce the negative total amount
> >> * A credit note (which is defined by a record with a negative total
> >> amount) must produce move lines with negative amounts
> > I don't agree with this. In most countries having negative debit or
> > credit is at least suspicious or even forbidden. This must not be the
> > default behaviour of Tryton and at least it should be possible to have
> > a kind of invoice that inverse the debit/credit.
> > Negative debit/credit are done with the cancellation procedure.
> Could someone point me to some information about this? I really
> interested why this should be forbidden in some countries as i think
> that this is a native feature of accounting and i do not see any reason
> why this should be forbidden.

My accountant tells me in Belgium, nobody does it but he can not say if
it was forbidden.
Indeed it is the quite logical otherwise there will be any notion of
debit/credit because it can be replaced with positive/negative.
Also that's why the credit note is called a credit note because it does
credit.

> >> For me the current cancelation functionality can be removed as it will
> >> now implemented by a credit note (which is defined by a record with a
> >> negative total amount). But i could live with it if it will be limited
> >> to the supplier side like it is now.
> > It must stay as I said above we need to have a way to generate both kind
> > of move.
> >
> As i said above some pointers to the reasons why this is really needed
> would help me to understand this requirement.

It is needed otherwise I can not use Tryton in Belgium at least. More
over, it is been 7 years Tryton does credit without any complaint.
Negative debit/credit is the *special* case. In my accounting courses,
my teacher never spoke about negative debit/credit indeed if I had put
one in my exercise, I would have failed.

[Cédric Krier]

 For the record, the patch is ready for review and testing: https://bugs.tryton.org/issue5225