Re: Translation question: "bill" VS "invoice"

Am Sun, May 24, 2026 at 05:57:58PM -0300 schrieb Mar=EDa Scappini:

> I need some help distinguishing the usage differences between "bill" and=
 "invoice" on
> GNUmed...

This warrants clarification.

> My main concern is that, in Spanish, one term (bill=3Dcuenta/prefactura)=
 is not a
> fiscally-binding document, and the other (invoice?=3Dfactura) does have =
fiscal value and
> is much more regulated in a lot of aspects (cannot be editable, numberin=
g should be
> unique, etc).

There are similar regulations here.

In GNUmed the intent is this:

invoice:

	A generated document containing all the fiscally
	required data needed for legally telling a payor:
	pay this amount

	exists as a PDF in the document archive, linked to a ...

bill:

	A data structure (bill.bill) aggregating the details
	necessary to properly effect invoice generation.

>    - bill (noun) =3D a detailed account of the items, their number, and
>    total amount.
>=20
>        - It can be edited after generation
>        - Does not hold legal value (?), thus not used to calculate taxes
>        - Does not need to have specific numbering or unique ID

I believe this corresponds to the above.

>    - invoice =3D=A0 the confirmed, final account of items, their number,
>    and total cost of services/sales.
>=20
>        - Cannot (or should not) be edited after generation
>        - Does hold legal, accounting, value, used to calculate taxes
>        - Is specifically numbered and identified, cannot be generated
>        twice with the same number.

Yes, so we do.

bill.bill.invoice_id holds the unique (enforced by the
database) ID which is generated by

	DEFAULT_INVOICE_ID_TEMPLATE =3D 'GM%(pk_pat)s / %(date)s / %(time)s'

	client/business/gmBilling::generate_invoice_id(...)

		No template given -> generate old style fixed format invoice ID.

		Placeholders:
			%(pk_pat)s
			%(date)s
			%(time)s
				if included, $counter$ is not *needed* (but still possible)
			%(firstname)s
			%(lastname)s
			%(dob)s

			#counter#
				will be replaced by a counter, counting up from 1 until the invoice id=
 is unique, max 999999

That allows us to be quite sure we've generated a unique
identifier (c'mon, 1 million attempts ?)

> Do these definitions match with the ones intended for GNUmed's UI?

Yes.

> Or is usage of these terms not as rigid, used interchangeably on purpose=
?

No, they shouldn't be.

> Here below some examples of 'bill' and 'invoice' usage on the Billing pl=
ugin:
>=20
>    Trying the 'Invoice selected items' button,

Here, "to invoice" is a verb ;-)

>    two things happen simultaneously:
>=20
>         =A0 =A0 - pop-up dialog appears, title "GMd: Editing bill | pati=
ent
>        | [user]".

Yep, the bill (used to *generate* an invoice) is edited.

>         =A0 =A0 - the selected items disappear from the charge list in t=
he
>        billing plugin's UI

After an invoice has been generated, the items included in
the invoice are not invoicable anymore and thusly are not
shown in the charge list any further.

>        The pop-up dialog's contents show: invoice ID, close date,
>        address, if VAT is applicable, etc. Clicking 'OK', GNUmed tries
>        to generate an invoice pdf, and the dialog closes.
>=20
>        My translation concern: The dialog title mentions 'bill',
>        however the UI button and content mention 'invoice'.

I understand the possibility for confusion. I do think it is
technically correct but I agree other wording may create
less confusion even if not quite correct :-)

After all, the invoice is (should) not be editable ;-)=20
(and, in fact, it isn't as it only ever exists as a PDF in
the archive).

Maybe the workflow warrants improvement ?

>    Now back on the Billing plugin's tab, trying the 'Bills' button:
>=20
>        Another pop-up dialog appears, title 'GMd: Showing bills. |
>        patient | [user]'.
>=20
>        However, this dialog is listing *invoices* by close date and ID,

Ah, no, it lists "closed" bills :-)  Not quite the same ...

>        also lets one 'unbill' items part of an invoice, delete whole
>        invoices (and lets you 'unbill' their items if you'd like), and

If one unbills items it will not change the invoice (a PDF
in the archive) in any way, shape, or form. It'll edit the
"bill" structure previously used to generate that invoice.

>        access PDF files for said invoices and generate the PDFs if they
>        are not found.

Point in case: not "PDF file *for* said invoices" but rather
"invoice PDFs for said bills". Yeah, it's tricky. Now, there
seems to be a loophole (and there *is* a shortcoming as I
now realize): One might create an invoice (an invoice ID
will be generated), unbill its items, delete the invoice
PDF, add/remove items *to/from* the *bill*, and regenerate
the invoice PDF which now:

- contains different charge items
- contains the very same invoice ID

That may cause hiccups under some legislations. All is not
lost, however, because bill.bill is audited, and thusly
audit.log_bill still contains a record of the previous
invoice_id.

We need to change this, probably be unsetting invoice_id
when the link to the invoice PDF (bill.bill.fk_doc) is
unset.

We may also need to consider restricting deletion of invoice
PDFs to the database admin or some such.

Any other things the *really* need to be changed ?

Marc ?

>        My translation concern here: the button in the main plugin tab
>        mentions 'bills', however the dialog's content lists 'invoices'
>        and lets you manage them instead. (In latin america, altering
>        invoices is illegal, even.)

See, that's why we are editing bills ;-)

We don't want to get nicked off to the States at the whim of
whoever so wills.

Regards,
Karsten
=2D-=20
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B