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

This is a multi-part message in MIME format.
--------------LTadiMoDAqtL9YawLwIcUCU2
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi, Karsten! Thanks to your explanations, I understand the wording difference!!
I think it was a language-barrier issue, from my part.

> 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.

This specifically cleared a lot of my doubts!! "Invoice" is _only_ the PDF file.
The rest is "bill".

Also, now that it is clear for me that the PDF *is* the invoice,
I've got to admit that I've never been able to generate any invoices...
I'm told there's a generation error, and to take a look at the log...
which I've never done... Will do so and report back with any news...

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

Noted...

> 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 :-)

I don't think any major changes of wording are necessary, now that I understand...
The also-updated Spanish translation makes sense, too, thanks to your explanations.

Maybe, an explanation for the whole billing process in the updated user manual
would be enough for clearing any doubts.

About the user manual! I recently understood that the website's pages are also on
the github repo! Would you mind if I submitted pull requests with some updated pages
for the website? Following the same formatting as the ones already on the repo?

Say, for example, one of the broken links currently is...

https://www.gnumed.de/documentation/GmManualGuiElements.html

... so I would submit a pull request with my proposal for a new, up-to-date file...

gnumed/gnumed/doc/website/GmManualGuiElements.adoc

... which I think would then "fix" the broken link on gnumed.de?

I could do that, a little bit at a time, from some recovered info I've got on a big
writer doc where I've put all the old docs I could find on github and also through
archive.org from the old wiki. I have updated some parts, not all of it. I would
have liked to advance a bit more on updating info, however I think _some_ updated
user manual information is better than nothing, however little it might be.

> After all, the invoice is (should) not be editable ;-)
> (and, in fact, it isn't as it only ever exists as a PDF in
> the archive).
>
> Maybe the workflow warrants improvement ?

Up until recently, I neglected the whole billing process from my tests,
but I'll be playing around a lot more, report back on anything...
For now, aside from the language-barrier-issue and the invoice generation
loophole, I've not found much else that didn't make sense.

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

Could I submit a slight change for that pop-up dialog's title string?
Instead of ...

'GMd: Showing bills. | patient | [user]'

... use:

'GMd: Showing closed bills. | patient | [user]'

or even

'GMd: Closed bills. | patient | [user]'

... ?

That would also include a slight change to the 'Bills' button
tooltip, from...

'Browse bills of this patient'

... to...

'Browse closed bills of this patient'

Of course, all of this as long as it is not redundant in English.
I could always just add the equivalent of 'closed' in Spanish to
these particular translations.

> 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.

Where I live, the "hiccup" -- if They find out the software I am using
for invoice generation lets me, in any way, duplicate invoices --
could equal to a huge fine or even jail :-D

After I get the invoice generation working on my machine, I'll be sure
to test this edge case! Feel like a rebel "defying" the law mwahaha

>   All is not
> lost, however, because bill.bill is audited, and thusly
> audit.log_bill still contains a record of the previous
> invoice_id.

So the audit trail would show what was actually billed, and any
actual attempts at tax fraud would be very easy to tell?

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

Makes a lot of sense...

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

I would love that. Through the translation strings, found
out about gmAuthWidgets.get_dbowner_connection(). Would that simply
be called when pressing the 'delete invoice' button?

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

Will write back if when using more the whole process anything
pops-up ...

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

Indeed not :-D

María

--------------LTadiMoDAqtL9YawLwIcUCU2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><span style="white-space: pre-wrap">
</span></p>
    <pre><span style="white-space: pre-wrap">Hi, Karsten!

</span>Thanks to your explanations, I understand the wording difference!!
I think it was a language-barrier issue, from my part.

</pre>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">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.
</pre>
    </blockquote>
    <pre>This specifically cleared a lot of my doubts!! "Invoice" is _only_ the PDF file.
The rest is "bill". 

Also, now that it is clear for me that the PDF *is* the invoice,
I've got to admit that I've never been able to generate any invoices...
I'm told there's a generation error, and to take a look at the log...
which I've never done... Will do so and report back with any news...

</pre>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">Here, "to invoice" is a verb ;-)</pre>
    </blockquote>
    <pre>Noted...

</pre>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">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 :-)</pre>
    </blockquote>
    <pre>I don't think any major changes of wording are necessary, now that I understand...
The also-updated Spanish translation makes sense, too, thanks to your explanations.

Maybe, an explanation for the whole billing process in the updated user manual
would be enough for clearing any doubts.

About the user manual! I recently understood that the website's pages are also on
the github repo! Would you mind if I submitted pull requests with some updated pages
for the website? Following the same formatting as the ones already on the repo?

Say, for example, one of the broken links currently is...

<a class="moz-txt-link-freetext" href="https://www.gnumed.de/documentation/GmManualGuiElements.html">https://www.gnumed.de/documentation/GmManualGuiElements.html</a>

... so I would submit a pull request with my proposal for a new, up-to-date file...

gnumed/gnumed/doc/website/GmManualGuiElements.adoc

... which I think would then "fix" the broken link on gnumed.de?

I could do that, a little bit at a time, from some recovered info I've got on a big
writer doc where I've put all the old docs I could find on github and also through 
archive.org from the old wiki. I have updated some parts, not all of it. I would
have liked to advance a bit more on updating info, however I think _some_ updated
user manual information is better than nothing, however little it might be.

</pre>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">After all, the invoice is (should) not be editable ;-) 
(and, in fact, it isn't as it only ever exists as a PDF in
the archive).

Maybe the workflow warrants improvement ?</pre>
    </blockquote>
    <pre>Up until recently, I neglected the whole billing process from my tests,
but I'll be playing around a lot more, report back on anything...
For now, aside from the language-barrier-issue and the invoice generation
loophole, I've not found much else that didn't make sense.</pre>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">Ah, no, it lists "closed" bills :-)  Not quite the same ...</pre>
    </blockquote>
    <pre>Could I submit a slight change for that pop-up dialog's title string?
Instead of ...

'GMd: Showing bills. | patient | [user]'

... use:

'GMd: Showing closed bills. | patient | [user]'

or even

'GMd: Closed bills. | patient | [user]'

... ?

That would also include a slight change to the 'Bills' button
tooltip, from...

'Browse bills of this patient'

... to...

'Browse closed bills of this patient'

Of course, all of this as long as it is not redundant in English.
I could always just add the equivalent of 'closed' in Spanish to
these particular translations. 

</pre>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">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.</pre>
    </blockquote>
    <pre>Where I live, the "hiccup" -- if They find out the software I am using
for invoice generation lets me, in any way, duplicate invoices -- 
could equal to a huge fine or even jail :-D

After I get the invoice generation working on my machine, I'll be sure
to test this edge case! Feel like a rebel "defying" the law mwahaha

</pre>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre"> All is not
lost, however, because bill.bill is audited, and thusly
audit.log_bill still contains a record of the previous
invoice_id.</pre>
    </blockquote>
    <pre>So the audit trail would show what was actually billed, and any
actual attempts at tax fraud would be very easy to tell?

</pre>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">We need to change this, probably be unsetting invoice_id
when the link to the invoice PDF (bill.bill.fk_doc) is
unset.</pre>
    </blockquote>
    <pre>Makes a lot of sense...

</pre>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">We may also need to consider restricting deletion of invoice
PDFs to the database admin or some such.</pre>
    </blockquote>
    <pre>I would love that. Through the translation strings, found
out about gmAuthWidgets.get_dbowner_connection(). Would that simply
be called when pressing the 'delete invoice' button?

</pre>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">Any other things the *really* need to be changed ?</pre>
    </blockquote>
    <pre>Will write back if when using more the whole process anything
pops-up ...

</pre>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">We don't want to get nicked off to the States at the whim of
whoever so wills.</pre>
    </blockquote>
    <pre>Indeed not :-D

María</pre>
  </body>
</html>

--------------LTadiMoDAqtL9YawLwIcUCU2--