If this is about the text displayed in the invoice window and the tooltips for the buttons then I agree these need fixing.  I've made a start but 2.5 development version is in string freeze so I cannot submit the changes yet.

I cannot reproduce your second issue in either 2.4.13 or the development 2.5 versions.  If I have a invoice tab selected and I do File->Duplicate Invoice I get another Invoice, not a bill.  Same result when using the buttons.  Some of the labels are wrong but I still get the correct form.

I assume then that this bug concerns the text/labels in each tab or dialog?

I can't reproduce this behaviour on my system either. When the active tab is a vendor bill, the new invoice and duplicate invoice will both create a new bill for the same vendor (in the former case a completely new invoice, in the latter case a copy of the existing one).

So assuming this is about the names, I will drop severity.

Finally, as for the names to use in the future: I'd love to simplify the name usage in GnuCash. I started this discussion once on the mailing list on why one should be called a bill and the other an invoice. There was no urgent reason for this. Both could equally have been called invoice and where necessary, a disambiguation could be made by including customer/vendor in the name ("Customer Invoice" vs "Vendor Invoice"). In most contexts it's clear by itself already which type is meant. For example in the new bill/invoice dialog the user is asked for a vendor or customer. That clearly gives the distinction. In that case I'd only make the window title explicitly "New Customer/Vendor Invoice".

And with the introduction of credit notes, this title may even be too specific...

Just some food for thought on the matter :)

> Finally, as for the names to use in the future: I'd love to simplify the name
> usage in GnuCash.

Yes, I'm all for this, too.

Created attachment 262933 [details]
Creen cap current progress.

Looking in src/business/business-gnome/gnc-plugin-page-invoice.c I realised that changing Invoice to bill or Voucher was going to be more "interesting" than I'd intially thought.  I started on the top right box in the invoice window without difficulty.  Then looked further and it, gets complicated.

Simplifying the name usage is a better may to go.

The existing names were chosen (over a decade ago) for numerous reasons:

1) Differentiation.  There were some languages for which an Invoice you send to a customer is a different word than a Bill you receive from a vendor.  And at the time there was no "differentiation" method in gettext (or if there was nobody told me about it).

2) Brevity.  The phrase "Customer Invoice" and "Vendor Bill" is long, too long for icon labels ("Delete Customer Invoice" anyone?) so the names needed to be shorter.

The code is supposed to choose the label based on the underlying type.  I think there is one place where that might not have been possible, but I agree that the code should be checked to make sure that it's consistent.

And yes, the Invoice does have a section called "Billing Information".  That was done on purpose, because "Invoicing Information" is not correct.

(In reply to comment #5)
> The existing names were chosen (over a decade ago) for numerous reasons:
> 
> 1) Differentiation.  There were some languages for which an Invoice you send to
> a customer is a different word than a Bill you receive from a vendor.  And at
> the time there was no "differentiation" method in gettext (or if there was
> nobody told me about it).
> 
I did ask about this once on the mailing lists, but nobody was able to give me an example language for which this was the case. Do you remember which language this request came from ?

> 2) Brevity.  The phrase "Customer Invoice" and "Vendor Bill" is long, too long
> for icon labels ("Delete Customer Invoice" anyone?) so the names needed to be
> shorter.
> 
IMO the icon label can simply be "Delete Invoice". The delete button is on top of an invoice window, which has plenty of other indicators this is about a Customer invoice and not a vendor invoice. I didn't do a full study on this one yet, but from initial investigations there were only very few locations where it was necessary to specify an extended name to disambiguate.

Created attachment 262955 [details] [review]
Fixes labels in the window and dialog.

The patch fixes the labels in the dialogs and windows when it isn't an invoice.  It introduces a singe string "Bill Information".  

It doesn't fix the mouseovers for edit, duplicate etc. or any menu texts, but go some way to clearing up user confusion.

This patch is for the devel,2.5, branch.  This could possibly be backported to 2.4 (?)

(In reply to comment #6)
> (In reply to comment #5)
> > The existing names were chosen (over a decade ago) for numerous reasons:
> > 

> I did ask about this once on the mailing lists, but nobody was able to give me
> an example language for which this was the case. Do you remember which language
> this request came from ?

I do not recall offhand.  Sorry.  It's been a decade.  ;)

> > 2) Brevity.  The phrase "Customer Invoice" and "Vendor Bill" is long, too long
> > for icon labels ("Delete Customer Invoice" anyone?) so the names needed to be
> > shorter.
> > 
> IMO the icon label can simply be "Delete Invoice". The delete button is on top
> of an invoice window, which has plenty of other indicators this is about a
> Customer invoice and not a vendor invoice. I didn't do a full study on this one
> yet, but from initial investigations there were only very few locations where
> it was necessary to specify an extended name to disambiguate.

Again, I wanted consistency.  Perhaps I should have used "New" instead of "Delete", where it wouldn't have been quite as obvious what it was referring to.

Mike E's comment: "If this is about the text displayed in the invoice window and the tooltips for the buttons then I agree these need fixing."

My report is not about that.

I'am not native speaker English. I supposed that the difference between 'Invoice' and 'Bill' as between Customer Invoice and Vendor Invoice was English common knowledge. The comments make clear that both terms are more or less synonym.
In the Dutch version of Gnucash the distinction between both documents is translated into 'Verkoopfactuur' and 'Inkoopfactuur', back translated respectively 'Sale Invoice' and 'Purchase Invoice'. That difference is clear.

I have attached the relevant window when editing a Purchase Invoice in version 2.4.13 Dutch. You see 4 pictograms: New Sale Invoice ..., New Sale Invoice [mouseover: for the same customer], Edit Sale Invoice and Duplicate Sale Invoice [mouseover: for the same customer].

Admit: very confusing, when editing a purchase invoice.

The second, third and fourth pictogram refer --- despite the name -- to a Purchase Invoice for the same vendor. When I am working with different vendors, editing their purchase invoices, I expect in analogy that the pictogram New Sale Invoice ... can be used to make a new Purchase Invoice for a new vendor. But no, the result is a new sale invoice for a new customer. 

For a new Purchase Invoice for a new vendor I have to return to the Main Menu, Business, Vendor, New Purchase Invoice.

In this context (and only in this context) I wrote:
"A more consequent use of the terms Invoice and Bill and a context driven menu would be appreciated."

On my laptop I have made a guest login with American locale and English as standard language. With the purpose to communicate with the English speaking community.

Surprise, surprise: the pictogram 'New Invoice ...' is missing in version 2.4.13 English! 

That explains that you cannot reproduce the behaviour on your systems.

The choice to make a new purchase invoice for another vendor within one click in the menu is in my view obvious in every language. 

Also a bug in the Dutch version and a wish in the English.

On the terminology topic I come back in a separate report.

Created attachment 262989 [details]
Screenshot of the Dutch version of the window Edit Bill

Refers to my comment 2013/11/28.

Re languages: Using
> grep -i -E -A1  '^msgid( "bill")|( "invoice")$' *.po
either in po/glossary/ or in po/ does not give a uniform picture. Most languages seem to have chosen two different strings, but without knowing the language, it is not possible to tell whether the strings could have chosen equal just as well. As for German (similar to Dutch), there are no two words for customer and vendor invoice, so the distinction sounds rather artificial in the translation and just using one single term would help there a lot.

@John: To have a look at the English version, on Linux you can open a Terminal and type "LANG=C gnucash" in one line, then press enter. This will run gnucash in English language. ("LANG=nl_NL.utf8 gnucash" or similar will run it in dutch, "LANG=de_DE.utf8 gnucash" in german and so on.)

@John: Also, we don't do any development on the 2.4.13 versions anymore. We're developing 2.5.8 and following right now. In your particular case, the text labels next to the buttons have disappeared in 2.5.8 anyway (to be precise: They depend on the system-wide setting about "buttons with text" vs. "only buttons"), so these particular button labels are probably not a problem in 2.5.x anymore.

I can confirm that if you have a bill focused and click on the "new invoice" button, the leftmost of the group of 4, you get a new invoice.  I believe this is intended behaviour.

@john you're saying that you should get a new Purchase Invoice (bill) if you have a bill tab focused, yes?

Using LANG=en_GB or LANG=C  I see 4 buttons (pictograms) including the "new invoice" button are you seeing 3 buttons?

I'm thinking that this button should not be there at all and new invoice/bill/voucher should be created through the business menu.  Changing this button's action depending on context doesn't seem right.

Comment on attachment 262955 [details] [review]
Fixes labels in the window and dialog.

This patch fixes what I *thought* was the OPs issue.  There should be a new bug report for the labeling issues.

@Mike: Re 4 or 3 buttons: The leftmost button appears if you switch on the preference "Business -> Extra business button". IIRC, it was a user proposal/request to add that leftmost button (and our developer got paid by the user to do this), hence a potential removal needs to be discussed very well.

> @Mike: Re 4 or 3 buttons:

Ah!  I missed that.  It's making sense, slowly.

I see the commit (80e4847f2a8) says: '"New Invoice" for now' does that mean we should add buttons for bill and voucher as well?

I see your point about removing it.

@Mike:
>>I believe this is intended behaviour.

Alas, I don't agree. Working on Purchase Invoices (bills) for different vendors takes a lot of more action than working on Sale Invoices for different customers. For me that's not user friendly. 

>>Changing this button's action depending on context doesn't seem right.

But the other buttons do behave context depending!

Christian Stimming's answer returns to the terminology discussion. My report is
not about that. 

>>As for German (similar to Dutch), there are no two words
>>for customer and vendor invoice, so the distinction sounds rather artificial in
>>the translation and just using one single term would help there a lot.

No, in Dutch the distinction between 'Sale Invoice' and 'Purchase Invoice' do
not sound artificial. Introducing a single term in that language would be very
artificial. Eskimo's have 10 single terms for snow, we just one.

@ Christian: In OSX the tip for changing the language doesn't work.

I do understand that version 2.4.13 wil not be maintained anymore.
I am afraid that in the new 2.5 release my problem (a button for a new Purchase
Invoice for another vendor in the Purchase Invoice editing mode in stead of a
button that results in a new Sale Invoice) will not be solved.

(In reply to comment #16)
> @Mike:
> >>I believe this is intended behaviour.
> 
> Alas, I don't agree. Working on Purchase Invoices (bills) for different vendors
> takes a lot of more action than working on Sale Invoices for different
> customers. For me that's not user friendly. 
> 
It *is* intended behaviour. It's pointless to disagree with that. We can discuss whether it's *desirable* behaviour.

The thing is, this button was added with another use case in mind: someone that interacts mostly with customers directly and needs an easy way to create invoices for customers.

I understand this is not your primary use case, and hence the button is in the way for you. The easiest solution is to disable "Business->Extra business button" in your configuration. It's not intended for you.

(In reply to comment #17)
> Christian Stimming's answer returns to the terminology discussion. My report is
> not about that. 
> 
> >>As for German (similar to Dutch), there are no two words
> >>for customer and vendor invoice, so the distinction sounds rather artificial in
> >>the translation and just using one single term would help there a lot.
> 
> No, in Dutch the distinction between 'Sale Invoice' and 'Purchase Invoice' do
> not sound artificial. Introducing a single term in that language would be very
> artificial. Eskimo's have 10 single terms for snow, we just one.
> 
"Verkoopfaktuur" and "Inkoopfaktuur" are technically correct terms, as are Invoice and Bill. But in all the business accounting I do I rarely use the full names. I will almost always use "Faktuur" and the context makes is clear whether it should be interpreted as "verkoop" or "inkoop". Let me say it differently: what for you is a sales invoice is a purchase invoice for your customer. The document is simply an invoice. Whether it's for sales or purchase depends on which side of the transaction you look at it. All invoices only carry the name "Invoice", whether I receive them from a vendor or I make one for a customer.

Calling it a sales invoice or a purchase invoice can be useful for disambiguation, but calling the document an invoice is not artificial.

> @ Christian: In OSX the tip for changing the language doesn't work.
> 
> I do understand that version 2.4.13 wil not be maintained anymore.
> I am afraid that in the new 2.5 release my problem (a button for a new Purchase
> Invoice for another vendor in the Purchase Invoice editing mode in stead of a
> button that results in a new Sale Invoice) will not be solved.

I don't get your worry. 2.5 has that button already. When you have 4 buttons enabled, it's the second one. The button that always creates a "sales invoice" is redundant and not for your use of GnuCash. So again, you could just disable it.

Comment on attachment 262955 [details] [review]
Fixes labels in the window and dialog.

@Christian: you marked this patch as ready for commit. But it introduces new strings. Shouldn't that wait until after 2.6 then ?

Geert:

>>It *is* intended behaviour. It's pointless to disagree with that. We can
discuss whether it's *desirable* behaviour.

Yes, that is what I was trying to say.

I have disabled the extra buttons. That confusion is gone now. Pfff.. 
The confusion of the Dutch translation of 'Invoice' (in the general meaning) into 'Sale Invoice' on the buttons remains. In the English version 'Invoice' has two definitions: in opposite with Bill it means "Sale Invoice", in other context it includes both kinds of an Invoice. The localization in other languages will always fail with homonym terms. That's a problem in the source language.

Mike_E:
>>and new invoice/bill/voucher should be created through the business menu.

I have just discovered I can use the button 'New Invoice' or 'Duplicate Invoice' and then alter the vendor by editing the Vendor Field in the tab. The long way of the Business Menu is not necessary, in other words.

Also, drop my reported bug. And solve the problem in the localization.

(In reply to comment #21)
> Geert:
> 
> >>It *is* intended behaviour. It's pointless to disagree with that. We can
> discuss whether it's *desirable* behaviour.
> 
> Yes, that is what I was trying to say.
> 
> I have disabled the extra buttons. That confusion is gone now. Pfff.. 
Good. I think we should keep this as a reminder that our documentation needs updating.

> The confusion of the Dutch translation of 'Invoice' (in the general meaning)
> into 'Sale Invoice' on the buttons remains. In the English version 'Invoice'
> has two definitions: in opposite with Bill it means "Sale Invoice", in other
> context it includes both kinds of an Invoice. The localization in other
> languages will always fail with homonym terms. That's a problem in the source
> language.
> 
Agreed. We have a localization issue here.

> Mike_E:
> >>and new invoice/bill/voucher should be created through the business menu.
> 
> I have just discovered I can use the button 'New Invoice' or 'Duplicate
> Invoice' and then alter the vendor by editing the Vendor Field in the tab. The
> long way of the Business Menu is not necessary, in other words.
> 
I was about to write another comment to point you in this direction. I'm glad you found it yourself.

> Also, drop my reported bug. And solve the problem in the localization.

Your bug brought up the localization problem (albeit after some discussion). So it should only be closed when that issue is fixed :)

(In reply to comment #17)
 
> @ Christian: In OSX the tip for changing the language doesn't work.

http://wiki.gnucash.org/wiki/Locale_Settings#Changing_the_Language_on_OSX

(In reply to comment #20)
> @Christian: you marked this patch as ready for commit. But it introduces new
> strings. Shouldn't that wait until after 2.6 then ?

I'm fine with those few strings that fix a bug or at least a strong misunderstanding in the labels.

As mentioned somewhere else: We have ~1000 new strings anyway. I don't care too much about a handful of extra ones during the string freeze...

Patch applied as r23458.  This only fixes the text labels in the interface.

Contrary to the commit message this introduces only 2 new strings.

If I understand well, the problem is that the English version 'Invoice' has two definitions: in opposite with Bill and Voucher it means "Sale Invoice", in other context it is a term that can refer to a more general product. Localization in other languages will always fail with homonym terms. The problem is not the translation, but the definition of the term in the source language.

The tabs 'Edit Invoice', 'Edit Bill' and 'Edit Voucher' suggest that you can edit the content of a product. In fact you can edit more. You can make steps in the administration of a transaction: Enter, Post, Print, Pay. It concerns not a product, but more a process.

Is 'Transaction' (already used in the Schedule Module) not a better term in the buttons above: also 'New Transaction', 'Edit Transaction', 'Duplicate Transaction'. The user that has enabled "extra buttons", can see the difference: 'New Invoice ...' refers to a new Sale Invoice. In translations the terms can refer to unique terms in the source language.

Comment on attachment 262955 [details] [review]
Fixes labels in the window and dialog.

This has been committed as r23458 by Mike.

Reassign version to 2.4.x so that individual 2.4 versions can be retired.

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=715184. Please update any external references or bookmarks.