Invoice workflow improvement

[Cédric Krier]

Hi,

I'm working on improving the invoice workflow especially when the
cancellation when users make mistakes.

Here is the thoughts:

- It should be possible to cancel an opened supplier invoice by doing a
cancel move.

- Cancelling a customer invoice is done via credit note (already
implemented).

- It should not be possible to delete a cancelled invoice if it has
a number (which means it was opened).

- The proforma of supplier invoice should create the account move in
draft. This allow a 2 steps validation for supplier invoice.

Any comments are welcome.
--
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/

[Dominique Chabord]

hi

Le 24/10/2012 11:17, Cédric Krier a écrit :

>
> - The proforma of supplier invoice should create the account move in
> draft. This allow a 2 steps validation for supplier invoice.

As you know, French localization will disable this, since pro-format
means draft in France and doesn't generate account moves.
regards

--
Dominique Chabord - SISalp

[Cédric Krier]

On 24/10/12 11:17 +0200, Cédric Krier wrote:
> Hi,
>
> I'm working on improving the invoice workflow especially when the
> cancellation when users make mistakes.
>
> Here is the thoughts:
>
> - It should be possible to cancel an opened supplier invoice by doing a
> cancel move.
>
> - Cancelling a customer invoice is done via credit note (already
> implemented).
>
> - It should not be possible to delete a cancelled invoice if it has
> a number (which means it was opened).
>
> - The proforma of supplier invoice should create the account move in
> draft. This allow a 2 steps validation for supplier invoice.
>
> Any comments are welcome.

Here is the review: http://codereview.tryton.org/583002/

[Cédric Krier]

I don't get you. What is a proforma for a supplier invoice?
Why draft move will not be allowed? If you know you will receive an
invoice, it is good to book it in advance in draft like that you have a
better picture of your accounting/budget/cash flow etc.

[Dominique Chabord]

Le 24/10/2012 13:08, Cédric Krier a écrit :
> On 24/10/12 13:04 +0200, Dominique Chabord wrote:
>> Le 24/10/2012 11:17, Cédric Krier a écrit :
>>> - The proforma of supplier invoice should create the account move in
>>> draft. This allow a 2 steps validation for supplier invoice.
>>
>> As you know, French localization will disable this, since pro-format
>> means draft in France and doesn't generate account moves.
>> regards
>
> I don't get you. What is a proforma for a supplier invoice?
> Why draft move will not be allowed? If you know you will receive an
> invoice, it is good to book it in advance in draft like that you have a
> better picture of your accounting/budget/cash flow etc.
>

"The proforma of supplier invoice" is not something we are used to.
nevertheless, you cannot anticipate account moves.

regards

--
Dominique Chabord - SISalp

Logiciel libre pour l'entreprise : Gestion OpenERP et Tryton
18 avenue Beauregard 74960 Cran Gevrier
145A rue Alexandre Borrely 83000 Toulon
tél +33(0)950274960 fax +33(0)955274960 mob +33(0)622616438
http://sisalp.fr

[Cédric Krier]

On 24/10/12 13:29 +0200, Dominique Chabord wrote:
>
>
> Le 24/10/2012 13:08, Cédric Krier a écrit :
> > On 24/10/12 13:04 +0200, Dominique Chabord wrote:
> >> Le 24/10/2012 11:17, Cédric Krier a écrit :
> >>> - The proforma of supplier invoice should create the account move in
> >>> draft. This allow a 2 steps validation for supplier invoice.
> >>
> >> As you know, French localization will disable this, since pro-format
> >> means draft in France and doesn't generate account moves.
> >> regards
> >
> > I don't get you. What is a proforma for a supplier invoice?
> > Why draft move will not be allowed? If you know you will receive an
> > invoice, it is good to book it in advance in draft like that you have a
> > better picture of your accounting/budget/cash flow etc.
> >
>
> "The proforma of supplier invoice" is not something we are used to.
> nevertheless, you cannot anticipate account moves.

So what is the usage of draft move (comptabilité brouillard) in France?

[Raimon Esteve]

2012/10/24 Cédric Krier <cedric...@b2ck.com>:

> - Cancelling a customer invoice is done via credit note (already
> implemented).

I think in spain don't use credit note. Account Spain people are
confirm about it.

Las meet in Barcelona, we told about cancel invoices
Nan designed a module to cancel invoice and reopen.
A lot of users done a invoice and after need to change some
information (payments, date, ....)

https://bitbucket.org/zikzakmedia/trytond-account_invoice_cancel/src/7515a6d7864c41a3e3d374f4b52978fafd538ef9/invoice.py?at=default

[Dominique Chabord]

Le 24/10/2012 13:35, Raimon Esteve a �crit :

> A lot of users done a invoice and after need to change some
> information (payments, date, ....)

In France all elements which are printed on the invoice are definitive
and cannot be changed once the document is sent. We have to chack and
make it final before we assign a sequence number. Printing different
documents with the same sequence number would be a "sign of fraud".
Maybe these aspects should be configured in the localization module.

[Udo Spallek]

Hi,

Wed, 24 Oct 2012 11:17:38 +0200
Cédric Krier <cedric...@b2ck.com>:

>I'm working on improving the invoice workflow especially when the
>cancellation when users make mistakes.
>Here is the thoughts:
> - It should be possible to cancel an opened supplier invoice by
> doing a cancel move.
> - Cancelling a customer invoice is done via credit note (already
> implemented).

AFAIK at least in Swiss, Austria and Germany accounting
*cancellation* and *credit note* are two different conceptions.

A cancellation move is a move which completely neutralize another move.
The result of a cancellation is the same as a deletion of the
record in the database, but documenting this incidence.
Cancellation is used AFAIK for correcting mistakes only or if no
money changed hands.
The cancellation move is set up identical as the original move, but
debit and credit amounts of the lines are negated (* -1), but not
change their sides like in credit notes.
AFAIK the accounting date of a cancellation is the same as
the accounting date of the original move, to neutralize the original
move the same date it is created.
The amount of the original move added to the cancellation move amount is
zero.
The total balance amount after the cancellation is the same as the
original move has never been made.

Credit note moves are setup identical as the original move, but change
the sides of debit/credit amounts of the lines. A credit note
always shows a difference in the balance to document a business case and
money changed hands. The sum of the original amounts with the credit
note amount will always raise the total balance.

For both cancellation and credit note it is good to have a reason
documented, especially for customer invoices because the enterprise
owe the government the VAT. Reasons could be like this[1]:

* Party returned goods,
* Party overcharged,
* Replaced by invoice No XYZ,
* Invoice prepared in error.
* Other

While a tax audit, the enterprise could be requested for the reasons of
cancellations years ago. Years later it is good to have some
documentation why cancel or credit note specific invoices to not raise
suspicion for money laundering or tax fraud.

Regards Udo

[1] http://www.uwo.ca/finance/people/ar/cancel.pdf
--
_____________________________
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

[Raimon Esteve]

2012/10/24 Dominique Chabord <dominiqu...@sisalp.org>:

> In France all elements which are printed on the invoice are definitive
> and cannot be changed once the document is sent. We have to chack and
> make it final before we assign a sequence number. Printing different
> documents with the same sequence number would be a "sign of fraud".
> Maybe these aspects should be configured in the localization module.

A cached report?

In OpenERP v5 we designed account_invoice_historical_partner.
This module fix partner data from invoice. If you change values from
partner, no reload partner data from invoices created.

Raimon

[Dominique Chabord]

Le 24/10/2012 13:34, Cédric Krier a écrit :

>
> So what is the usage of draft move (comptabilité brouillard) in France?
>

I think we are mixing several things.

Regarding documents :
Draft invoice is ok
Proforma sale invoice is equal to a draft invoice with "pro-forma"
mention. Different in other countries.
A supplier invoice is not an official document. It is a easy way to
encode invoices from suppliers for non-accountant people. It can be a
draft, waiting for receiving the final document. proforma is not known
for supplier invoices.

regarding accounting :
Draft move is ok
A draft move is not registered yet in journals
"Brouillard" is when you can edit the moves of an open-period. Move
sequence numbers are not definitive until you close the period.
The opposit of Brouillard is "closed period".

hth

[Dominique Chabord]

Le 24/10/2012 14:59, Raimon Esteve a �crit :

> 2012/10/24 Dominique Chabord <dominiqu...@sisalp.org>:
>> In France all elements which are printed on the invoice are definitive
>

> A cached report?
It could be a solution. History data as Tryton does is better.

>
> In OpenERP v5 we designed account_invoice_historical_partner.

openerp V5 and followings cache the pdf but only for invoices.

[Udo Spallek]

Wed, 24 Oct 2012 13:35:10 +0200
Raimon Esteve <raimon...@gmail.com>:

The way this module implements cancellation would not be allowed in
Germany at least. Once an invoice is opened, it is not allowed to set it
back to draft and modify it.

Regards Udo

[Jordi Esteve]

On 24/10/12 13:04, Dominique Chabord wrote:
> hi
>

> Le 24/10/2012 11:17, C�dric Krier a �crit :

>
>> - The proforma of supplier invoice should create the account move in
>> draft. This allow a 2 steps validation for supplier invoice.
> As you know, French localization will disable this, since pro-format
> means draft in France and doesn't generate account moves.
> regards

The same in Spain, pro-forma means draft in Spain and should not
generate any account move. Moreover, proforma is not used for supplier
invoices, only for customer invoices.

In Spain, from the accounting point of view, Proforma invoices are
identical as draft invoices, Proforma is only an intermediate step to
put the invoice fields in readonly and print the invoice with "Proforma"
text instead of "Draft invoice" text.

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

Zikzakmedia SL
Dr. Fleming, 28, baixos
08720 Vilafranca del Pened�s
Tel 93 890 2108

[Okko]

The same in Spain, pro-forma means draft in Spain and should not
generate any account move. Moreover, proforma is not used for supplier
invoices, only for customer invoices.

In Spain, from the accounting point of view, Proforma invoices are
identical as draft invoices, Proforma is only an intermediate step to
put the invoice fields in readonly and print the invoice with "Proforma"
text instead of "Draft invoice" text.

I agree pro forma is only used for customer invoices. My suggestion is to rename "Pro Forma" to something like "Validate" for supplier invoices. In this state the draft move is made and it is allowed to go back to draft to change the invoice.

regards,

Okko

 

[Cédric Krier]

On 24/10/12 17:52 +0200, Jordi Esteve wrote:
> On 24/10/12 13:04, Dominique Chabord wrote:
> >hi
> >
> >Le 24/10/2012 11:17, Cédric Krier a écrit :
> >
> >> - The proforma of supplier invoice should create the account move in
> >> draft. This allow a 2 steps validation for supplier invoice.
> >As you know, French localization will disable this, since pro-format
> >means draft in France and doesn't generate account moves.
> >regards
>
> The same in Spain, pro-forma means draft in Spain and should not
> generate any account move. Moreover, proforma is not used for
> supplier invoices, only for customer invoices.
>
> In Spain, from the accounting point of view, Proforma invoices are
> identical as draft invoices, Proforma is only an intermediate step
> to put the invoice fields in readonly and print the invoice with
> "Proforma" text instead of "Draft invoice" text.

This is exactly my point. As proforma is not used for supplier invoice,
let use it as pre-validation.

[Jordi Esteve]

On 24/10/12 15:29, Udo Spallek wrote:
> Wed, 24 Oct 2012 13:35:10 +0200
> Raimon Esteve <raimon...@gmail.com>:
>

>> 2012/10/24 C�dric Krier <cedric...@b2ck.com>:

>>> - Cancelling a customer invoice is done via credit note (already
>>> implemented).
>> I think in spain don't use credit note. Account Spain people are
>> confirm about it.
>> Las meet in Barcelona, we told about cancel invoices
>> Nan designed a module to cancel invoice and reopen.
>> A lot of users done a invoice and after need to change some
>> information (payments, date, ....)
>> https://bitbucket.org/zikzakmedia/trytond-account_invoice_cancel/src/7515a6d7864c41a3e3d374f4b52978fafd538ef9/invoice.py?at=default
> The way this module implements cancellation would not be allowed in
> Germany at least. Once an invoice is opened, it is not allowed to set it
> back to draft and modify it.
>

Yes, I know that in Germany and other countries is not allowed to cancel
an open invoice. In Spain also it is not allowed for big companies, but
the small and medium companies have the bad costume to fix minor errors
in a open invoice and they don't want to cancel it via credit note.

I correct Raimon, in Spain also we have credit notes. But as I said, we
must offer the capability to cancel an invoice and reopen it to fix
minor errors. If we don't offer this feature, it will be impossible to
install tryton to small and medium Spanish companies. Openerp offers
this feature optionally, depending of a check box in the journal to say
if posted moves in the journal can be cancelled. But if tryton doesn't
not allow this feature, we must provide it with the
account_invoice_cancel module that Raimon has mentioned.

[Jordi Esteve]

On 24/10/12 17:57, Cédric Krier wrote:
> On 24/10/12 17:52 +0200, Jordi Esteve wrote:
>> On 24/10/12 13:04, Dominique Chabord wrote:
>>> hi
>>>
>>> Le 24/10/2012 11:17, Cédric Krier a écrit :
>>>
>>>> - The proforma of supplier invoice should create the account move in
>>>> draft. This allow a 2 steps validation for supplier invoice.
>>> As you know, French localization will disable this, since pro-format
>>> means draft in France and doesn't generate account moves.
>>> regards
>> The same in Spain, pro-forma means draft in Spain and should not
>> generate any account move. Moreover, proforma is not used for
>> supplier invoices, only for customer invoices.
>>
>> In Spain, from the accounting point of view, Proforma invoices are
>> identical as draft invoices, Proforma is only an intermediate step
>> to put the invoice fields in readonly and print the invoice with
>> "Proforma" text instead of "Draft invoice" text.
> This is exactly my point. As proforma is not used for supplier invoice,
> let use it as pre-validation.

Ok, then, to no confuse users, rename "Pro Forma" to something like
"Pre-Validate" for supplier invoices as Okko has suggested.

--
Jordi Esteve
Consultor Zikzakmedia SL
jes...@zikzakmedia.com

Mòbil 679 170 693

Zikzakmedia SL
Dr. Fleming, 28, baixos

08720 Vilafranca del Penedès
Tel 93 890 2108

[Cédric Krier]

On 24/10/12 18:09 +0200, Jordi Esteve wrote:
> On 24/10/12 17:57, Cédric Krier wrote:
> >On 24/10/12 17:52 +0200, Jordi Esteve wrote:
> >>On 24/10/12 13:04, Dominique Chabord wrote:
> >>>hi
> >>>
> >>>Le 24/10/2012 11:17, Cédric Krier a écrit :
> >>>
> >>>> - The proforma of supplier invoice should create the account move in
> >>>> draft. This allow a 2 steps validation for supplier invoice.
> >>>As you know, French localization will disable this, since pro-format
> >>>means draft in France and doesn't generate account moves.
> >>>regards
> >>The same in Spain, pro-forma means draft in Spain and should not
> >>generate any account move. Moreover, proforma is not used for
> >>supplier invoices, only for customer invoices.
> >>
> >>In Spain, from the accounting point of view, Proforma invoices are
> >>identical as draft invoices, Proforma is only an intermediate step
> >>to put the invoice fields in readonly and print the invoice with
> >>"Proforma" text instead of "Draft invoice" text.
> >This is exactly my point. As proforma is not used for supplier invoice,
> >let use it as pre-validation.
>
> Ok, then, to no confuse users, rename "Pro Forma" to something like
> "Pre-Validate" for supplier invoices as Okko has suggested.

This is not possible without messing the code of invoice.

[Cédric Krier]

On 24/10/12 18:12 +0200, Cédric Krier wrote:
> On 24/10/12 18:09 +0200, Jordi Esteve wrote:
> > On 24/10/12 17:57, Cédric Krier wrote:
> > >On 24/10/12 17:52 +0200, Jordi Esteve wrote:
> > >>On 24/10/12 13:04, Dominique Chabord wrote:
> > >>>hi
> > >>>
> > >>>Le 24/10/2012 11:17, Cédric Krier a écrit :
> > >>>
> > >>>> - The proforma of supplier invoice should create the account move in
> > >>>> draft. This allow a 2 steps validation for supplier invoice.
> > >>>As you know, French localization will disable this, since pro-format
> > >>>means draft in France and doesn't generate account moves.
> > >>>regards
> > >>The same in Spain, pro-forma means draft in Spain and should not
> > >>generate any account move. Moreover, proforma is not used for
> > >>supplier invoices, only for customer invoices.
> > >>
> > >>In Spain, from the accounting point of view, Proforma invoices are
> > >>identical as draft invoices, Proforma is only an intermediate step
> > >>to put the invoice fields in readonly and print the invoice with
> > >>"Proforma" text instead of "Draft invoice" text.
> > >This is exactly my point. As proforma is not used for supplier invoice,
> > >let use it as pre-validation.
> >
> > Ok, then, to no confuse users, rename "Pro Forma" to something like
> > "Pre-Validate" for supplier invoices as Okko has suggested.
>
> This is not possible without messing the code of invoice.

I mean if someone has a good name to replace “Proforma“ for customer and
supplier invoice, I will be happy.

[Okko]

> > Ok, then, to no confuse users, rename "Pro Forma" to something like
> > "Pre-Validate" for supplier invoices as Okko has suggested.
>
> This is not possible without messing the code of invoice.

I mean if someone has a good name to replace “Proforma“ for customer and
supplier invoice, I will be happy.

I feel that pro forma on customer invoices is just a report based on invoice with a title "Pro Forma invoice". Why do we need a separate state for this on the invoice?

[Cédric Krier]

You need a state to say: this invoice is readonly because I sent it as
proforma to the customer so any changes should be done with customer
aknowlegde.

[Guillem Barba Domingo]

El 25/10/2012 10:02, "Cédric Krier" <cedric...@b2ck.com> va escriure:

Use "Pre-validate" with a help text saying that it is ProForma state in customer's invoices, and the report print ProForma.

[Cédric Krier]

I don't understand what you mean.

[Guillem Barba Domingo]

2012/10/30 Cédric Krier <cedric...@b2ck.com>

On 30/10/12 20:38 +0100, Guillem Barba Domingo wrote:
> El 25/10/2012 10:02, "Cédric Krier" <cedric...@b2ck.com> va escriure:
> > On 24/10/12 18:12 +0200, Cédric Krier wrote:

> > I mean if someone has a good name to replace “Proforma“ for customer and
> > supplier invoice, I will be happy.
>
> Use "Pre-validate" with a help text saying that it is ProForma state in
> customer's invoices, and the report print ProForma.

I don't understand what you mean.

You asked for a string to show in the state currently named 'Proforma'.

After read the messages, the "Proforma" state is exactly the same concept than "Pre-validate". So, I think we can use this text and specify in the help text of 'state' that "Pre-validate" corresponds to "Proforma" (to help users which are searching "Proforma" invoices). In the same way, in the Customer Invoice form, the button to change to "Pre-validate" state could be named "Proforma".

--
Guillem Barba
http://www.guillem.alcarrer.net

[Cédric Krier]

On 24/10/12 14:50 +0200, Udo Spallek wrote:
> Hi,
>
> Wed, 24 Oct 2012 11:17:38 +0200
> Cédric Krier <cedric...@b2ck.com>:
> >I'm working on improving the invoice workflow especially when the
> >cancellation when users make mistakes.
> >Here is the thoughts:
> > - It should be possible to cancel an opened supplier invoice by
> > doing a cancel move.
> > - Cancelling a customer invoice is done via credit note (already
> > implemented).
> AFAIK at least in Swiss, Austria and Germany accounting
> *cancellation* and *credit note* are two different conceptions.

What I mean here is that you can not cancel a customer invoice once it
is opened. You have to cancel the operation by editing a credit note.
It is a little bit too restrictive because there are cases where it could
be cancelled like the invoice was not sent to customer etc. but it
depends of information the system could not have.
In such cases, if a credit note is not what the user wants to do, he can
still create an invoice with all negative amounts (using the copy
method). This will have the same result as the cancel functionnality
available on supplier invoice.

[Cédric Krier]

I updated the patch to rename "proforma" into "validated" with a tooltip
on "Validate" button that says "Also known as Pro Forma" and the report
still show "Pro Forma" for customer invoice and "Validated" for
supplier.

[Cédric Krier]

On 24/10/12 11:17 +0200, Cédric Krier wrote:
> Hi,
>

> I'm working on improving the invoice workflow especially when the
> cancellation when users make mistakes.
>
> Here is the thoughts:
>
> - It should be possible to cancel an opened supplier invoice by doing a
> cancel move.
>
> - Cancelling a customer invoice is done via credit note (already
> implemented).
>

> - It should not be possible to delete a cancelled invoice if it has
> a number (which means it was opened).
>

> - The proforma of supplier invoice should create the account move in
> draft. This allow a 2 steps validation for supplier invoice.

- Rename Invoice Proforma state into Validated

I would like to add also the rename of the state "Opened" into "Posted".
I think it is more generic and understand all over the world. A more
over it is what happens at this state, the accounting move is posted.

[Okko Huisman]

On Thu, Nov 15, 2012 at 3:11 PM, Cédric Krier <cedric...@b2ck.com> wrote:

I would like to add also the rename of the state "Opened" into "Posted".
I think it is more generic and understand all over the world. A more
over it is what happens at this state, the accounting move is posted.

I agree

[Mathias Behrle]

* Betr.: " Re: [tryton] Invoice workflow improvement" (Thu, 15 Nov 2012
15:11:39 +0100):

> On 24/10/12 11:17 +0200, Cédric Krier wrote:
> > Hi,
> >
> > I'm working on improving the invoice workflow especially when the
> > cancellation when users make mistakes.
> >
> > Here is the thoughts:
> >
> > - It should be possible to cancel an opened supplier invoice by doing a
> > cancel move.
> >
> > - Cancelling a customer invoice is done via credit note (already
> > implemented).
> >
> > - It should not be possible to delete a cancelled invoice if it has
> > a number (which means it was opened).
> >
> > - The proforma of supplier invoice should create the account move in
> > draft. This allow a 2 steps validation for supplier invoice.
>
> - Rename Invoice Proforma state into Validated
>
> I would like to add also the rename of the state "Opened" into "Posted".
> I think it is more generic and understand all over the world. A more
> over it is what happens at this state, the accounting move is posted.

-1

The according state for an invoice would be 'Invoiced' or 'Billed'.

I would say, that module account_invoice is not generic depending on account.
There are existing use cases, where users only want to print invoices without
doing any accounting. Accounting stuff shouldn't be an argument to name an
invoice state.

--

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

[Cédric Krier]

On 15/11/12 18:32 +0100, Mathias Behrle wrote:
> The according state for an invoice would be
> 'Invoiced'

I find it confusing to use the same root as the Document.

> or 'Billed'.

It doesn't work well for supplier invoice.

> I would say, that module account_invoice is not generic depending on account.

Generic doesn't mean: no dependencies.
It is generic also because it reuse what already exists.
Invoices are relying on the account module for many aspects:

- tax computation
- payment status
- payable/receivable
- tax rules

And more over, making an invoice is making accounting (even if it is
just a small part).

> Accounting stuff shouldn't be an argument to name an
> invoice state.

Ok, my explain is perhaps a little bit too short.
I think "posting" is more relevant than "opened" because "opened"
depends of the way your are looking the transaction.

[Mathias Behrle]

* Betr.: " Re: [tryton] Invoice workflow improvement" (Thu, 15 Nov 2012

18:45:39 +0100):

> On 15/11/12 18:32 +0100, Mathias Behrle wrote:
> > The according state for an invoice would be
> > 'Invoiced'
>
> I find it confusing to use the same root as the Document.

It is just the state, that an invoice enters when it will be a legally binding
document. It is obvious, that this state will be named like the purpose of the
document.

> > or 'Billed'.
>
> It doesn't work well for supplier invoice.

So just keep 'Opened' as a generic name... It is all I want to say. No need to
rename...

> > I would say, that module account_invoice is not generic depending on
> > account.
>
> Generic doesn't mean: no dependencies.
> It is generic also because it reuse what already exists.
> Invoices are relying on the account module for many aspects:
>
> - tax computation
> - payment status
> - payable/receivable
> - tax rules
>
> And more over, making an invoice is making accounting (even if it is
> just a small part).

Perhaps you have to do accounting, if you write invoices, but writing invoices
is not part of doing accounting. It is an advantage to combine both, but they
can very well exist one without the other.

> > Accounting stuff shouldn't be an argument to name an
> > invoice state.
>
> Ok, my explain is perhaps a little bit too short.
> I think "posting" is more relevant than "opened" because "opened"
> depends of the way your are looking the transaction.

Of course we will always run into those problems when trying to find generic
terms. 'Posted' is for me as wrong or right as 'Opened'...

[Cédric Krier]

On 15/11/12 19:12 +0100, Mathias Behrle wrote:
> * Betr.: " Re: [tryton] Invoice workflow improvement" (Thu, 15 Nov 2012
> 18:45:39 +0100):
>
> > On 15/11/12 18:32 +0100, Mathias Behrle wrote:
> > > The according state for an invoice would be
> > > 'Invoiced'
> >
> > I find it confusing to use the same root as the Document.
>
> It is just the state, that an invoice enters when it will be a legally binding
> document. It is obvious, that this state will be named like the purpose of the
> document.
>
> > > or 'Billed'.
> >
> > It doesn't work well for supplier invoice.
>
> So just keep 'Opened' as a generic name... It is all I want to say. No need to
> rename...

But "Opened" doesn't work well for supplier invoice neither.

> > > Accounting stuff shouldn't be an argument to name an
> > > invoice state.
> >
> > Ok, my explain is perhaps a little bit too short.
> > I think "posting" is more relevant than "opened" because "opened"
> > depends of the way your are looking the transaction.
>
> Of course we will always run into those problems when trying to find generic
> terms. 'Posted' is for me as wrong or right as 'Opened'...

At least, "Posted" will be more consistant with the Statements (and
probably with the coming Payment or any other similar documents).

[Mathias Behrle]

* Betr.: " Re: [tryton] Invoice workflow improvement" (Thu, 15 Nov 2012

19:22:01 +0100):

> On 15/11/12 19:12 +0100, Mathias Behrle wrote:
> > * Betr.: " Re: [tryton] Invoice workflow improvement" (Thu, 15 Nov 2012
> > 18:45:39 +0100):
> >
> > > On 15/11/12 18:32 +0100, Mathias Behrle wrote:
> > > > The according state for an invoice would be
> > > > 'Invoiced'
> > >
> > > I find it confusing to use the same root as the Document.
> >
> > It is just the state, that an invoice enters when it will be a legally
> > binding document. It is obvious, that this state will be named like the
> > purpose of the document.
> >
> > > > or 'Billed'.
> > >
> > > It doesn't work well for supplier invoice.
> >
> > So just keep 'Opened' as a generic name... It is all I want to say. No need
> > to rename...
>
> But "Opened" doesn't work well for supplier invoice neither.

It worked until now.

> > > > Accounting stuff shouldn't be an argument to name an
> > > > invoice state.
> > >
> > > Ok, my explain is perhaps a little bit too short.
> > > I think "posting" is more relevant than "opened" because "opened"
> > > depends of the way your are looking the transaction.
> >
> > Of course we will always run into those problems when trying to find generic
> > terms. 'Posted' is for me as wrong or right as 'Opened'...
>
> At least, "Posted" will be more consistant with the Statements (and
> probably with the coming Payment or any other similar documents).

It must not be consistent, because an invoice is not a bank statement neither a
payment.
If you want find a generic overall term for the final invariable state of
objects (closed, posted, confirmed), you could use 'Completed'. But for me it
is not necessary to find a generic overall naming for all objects, because it
will be inappropriate for users to encounter some strange combinations of
objects and states. At least for the german translation I have to say, that it
will not change, whether the state will be named 'Opened' or 'Posted', because
those terms must be translated any way to corresponding business terms.

[Cédric Krier]

On 15/11/12 20:44 +0100, Mathias Behrle wrote:
> > At least, "Posted" will be more consistant with the Statements (and
> > probably with the coming Payment or any other similar documents).
>
> It must not be consistent, because an invoice is not a bank statement neither a
> payment.

They have a similar workflow:
- a draft state
- a validate state where record is readonly, waiting for final approval
- a "posted" state where things are recorded in the accounts
…

> If you want find a generic overall term for the final invariable state of
> objects (closed, posted, confirmed), you could use 'Completed'. But for me it
> is not necessary to find a generic overall naming for all objects, because it
> will be inappropriate for users to encounter some strange combinations of
> objects and states.

No, I don't try to find a generic term for all final states even if
"posted" sounds well for many similar objects.
I try to find the best term for this invoice state which is not by the
way the final one.
The word "Opened" is incomplet to describe the state of the invoice and
confusing. It is "opened" for who? For the accountant, for the
customer… What does it mean for a supplier invoice because since you
receive it, it is "opened".

> At least for the german translation I have to say, that it
> will not change, whether the state will be named 'Opened' or 'Posted', because
> those terms must be translated any way to corresponding business terms.

That's a pity. One day or an other, such behavior of translators will
have to be fixed to follow the main terms.
I already see that the "Opened" state of Invoice in the German
translation is not following the English but use the term "Invoiced"
(since 1.2).
So here, clearly it was already found by the German translators that
"Opened" was not good enough but they did not talk about it. That's not
team playing.

[Mathias Behrle]

* Betr.: " Re: [tryton] Invoice workflow improvement" (Thu, 15 Nov 2012

21:10:26 +0100):

> On 15/11/12 20:44 +0100, Mathias Behrle wrote:
> > > At least, "Posted" will be more consistant with the Statements (and
> > > probably with the coming Payment or any other similar documents).
> >
> > It must not be consistent, because an invoice is not a bank statement
> > neither a payment.
>
> They have a similar workflow:
> - a draft state
> - a validate state where record is readonly, waiting for final approval
> - a "posted" state where things are recorded in the accounts

For me the correct approach is to project business logic on the program, not
the other way. It may be fine for you to detect common workflow steps in
different models and that you want a uniform naming. This must absolutely not be
the case for the user.

The user just wants/has to work with the program and he has to find the
accustomed and usual steps of tasks to manage his everyday business. If
he won't find them or they are too strange, he won't get familiar with your
program and refrain from using it.

For which audience do you want to write the program? If it is just for yourself
it is no problem to name steps like you understand the logic of your code. If
you want your program to be attractive for business users, you should
preferably take into account their perspective.

> > At least for the german translation I have to say, that it
> > will not change, whether the state will be named 'Opened' or 'Posted',
> > because those terms must be translated any way to corresponding business
> > terms.
>
> That's a pity. One day or an other, such behavior of translators will
> have to be fixed to follow the main terms.

That's a deep misunderstanding of the translation process and ignores the fact
of different cultures and their languages.

> I already see that the "Opened" state of Invoice in the German
> translation is not following the English but use the term "Invoiced"
> (since 1.2).

Correct. We want the users to understand the application (s.above) and try to
stick to well known business terms as generic as possible, as detailed as
necessary.

> So here, clearly it was already found by the German translators that
> "Opened" was not good enough but they did not talk about it. That's not
> team playing.

If you read carefully my statements you will be able to detect, that
almost no other term than 'Invoiced' will meet the requirements of a direct
translation for Germany. (JFTR: 'Invoiced' could be translated to several
different terms as well). You don't want this term for your reasons.
Nevertheless I am not accusing you of not being a team player, despite the
fact, that you will take your decision based very strongly on your own opinion,
not a team opinion.

This thread is an example of how complex and time-consuming contribution to
Tryton can be. At a certain point of discussion investing time changes to losing
time. I have reached this point for this subject.

[Cédric Krier]

Please Mathias don't read to not lose your time.

On 16/11/12 13:52 +0100, Mathias Behrle wrote:
> * Betr.: " Re: [tryton] Invoice workflow improvement" (Thu, 15 Nov 2012
> 21:10:26 +0100):
>
> > On 15/11/12 20:44 +0100, Mathias Behrle wrote:
> > > > At least, "Posted" will be more consistant with the Statements (and
> > > > probably with the coming Payment or any other similar documents).
> > >
> > > It must not be consistent, because an invoice is not a bank statement
> > > neither a payment.
> >
> > They have a similar workflow:
> > - a draft state
> > - a validate state where record is readonly, waiting for final approval
> > - a "posted" state where things are recorded in the accounts
>
> For me the correct approach is to project business logic on the program, not
> the other way.

As you can see in my explaination, I don't speak at all about the code,
program or techniques but only on the workflow (when I say workflow, I
don't mean the "workflow engine"). I describe what happens for the user
when he performs an action, and the action/result should be named base
on that. This is the discoverability of the software, a very important
feature.

> It may be fine for you to detect common workflow steps in
> different models and that you want a uniform naming. This must absolutely not be
> the case for the user.

(Here again, workflow means user process not the workflow engine)
This is exactly what eases the adoption of Tryton, using the same design
approch for all the aspect of the business. Once you learn how the
invoice works (draft, validate and posted), you will directly understand
the statement because it is the same logic that is used and it is the
same for any similar document that will be developed in the future.

> The user just wants/has to work with the program and he has to find the
> accustomed and usual steps of tasks to manage his everyday business. If
> he won't find them or they are too strange, he won't get familiar with your
> program and refrain from using it.

There are no such standard. What you have are users who know one program
and want the same but it is not possible. In such case, it is better
that the users keep the one he knows.

> For which audience do you want to write the program? If it is just for yourself
> it is no problem to name steps like you understand the logic of your code. If
> you want your program to be attractive for business users, you should
> preferably take into account their perspective.

That what I do when I make a proposal, I do a lot of search and thought
before making a proposal. I compare with other existing solution like
Openbravo, SAP etc. And clearly all those programs have their own vision
about business and their own terms.
But it seems that I'm seen as a coder only and nothing else because I do
codereview. But to reminde to everyone, the current design (business
workflow) of the application has been done by Bertrand and Me 5 years
ago and it is still there. According to new comers it is a key aspect of
Tryton.

> > So here, clearly it was already found by the German translators that
> > "Opened" was not good enough but they did not talk about it. That's not
> > team playing.
>
> If you read carefully my statements you will be able to detect, that
> almost no other term than 'Invoiced' will meet the requirements of a direct
> translation for Germany.

It doesn't because of the supplier invoice.
But more over, changing the sense of a field with translation is a really
bad idea and weaken the solution because it breaks the modularity.
For example, you can have a module that extend the module to add new
concept on it. So the developer base his work on the english terms and
what they describe. But if the sense is changed in a language then the
new concept could be incomprehensible.

People must understand that translation is just about translate and not
about customization of the solution for their country.