Salut Jonathan, I agree with Mathieu. Using the value within aqinvoices is a better idea. I will update the wiki and yup, you have my word that I will test this one! ;^) Thanks! François François Charbonnier, Bibl. prof. / Chef de produits Tél. : (888) 604-2627 francois.charbonnier@inLibro.com <mailto:francois.charbonnier@inLibro.com> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com> Le 2014-07-25 06:13, Jonathan Druart a écrit :

Bonjour François,

On the koha-fr ML, Mathieu Saby asked me why I use the shipmentcost field in aqorders. And I think he is right, We should use the one in aqinvoices. I added an entry 'questions/notes' to the wiki.

If you update the wiki with the different cases/values, I could take into account on refactoring/rewriting the code. If you promise me to test the patches, it is a good deal :)

Cheers, Jonathan

2014-07-24 19:57 GMT+02:00 Francois Charbonnier <francois.charbonnier@inlibro.com>:

...

Hello Jonathan, hello all,

Thank you for the RFC. I haven't checked the values but the calculations look good to me!

I would like to point out that we have, here in Canada, libraries who manage shipment cost before taxes. So, when they enter the shipment cost (tax excluded), the invoice total is wrong since this cost is added to the total which includes taxes.

Recently, inLibro submitted a patch waiting for signoff to fix this issue (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11062). This patch allows librarians to set up new values on the vendor page. They define if shipment costs are tax included or excluded and what the default tax rate is for the shipment cost. It updates the invoice total calculation as well.

In the end, the invoice still shows the total tax included but this patch allows librarians to enter the shipment value before taxes and calculate the shipment cost including taxes before adding it to the invoice total.

To all, are Canadian libraries the only one having this issue? Any thoughts on the way to fix it? Has what I have suggested look good to you?

Jonathan, is it possible to add this feature in your development (and avoid conflicts withs our patch in the future)? I'm ready to update the RFC, answer your questions and, ultimately, test your development! ;^)

I'm waiting for your go to update the wiki page.

Thanks!

François

François Charbonnier, Bibl. prof. / Chef de produits

Tél. : (888) 604-2627 francois.charbonnier@inLibro.com

inLibro | pour esprit libre | www.inLibro.com

Le 2014-07-21 11:32, Jonathan Druart a écrit :

Hello,

As promised, I have just finished to translate the spec for the VAT/GST rewrite.

You can found them on the wiki: http://wiki.koha-community.org/wiki/GST_Rewrite_RFC

Note that I am waiting for some feedbacks before starting the development. I really would like to know if the logic is good for all of you/your customers/use cases and if you agree on the values calculation.

Regards, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

Note that the bug report exists, if you want to follow it: Bug 12825 - GST / VAT rewrite Some preliminary works will be done on Bug 12826 - GST / VAT rewrite - plumbing Patches have already been submitted, feedbacks needed... 2014-08-28 11:58 GMT+02:00 Jonathan Druart <jonathan.druart@biblibre.com>:

Thanks to Katrin and Colin for their questions/notes on the wiki page (http://wiki.koha-community.org/wiki/GST_Rewrite_RFC#Questions_.2F_notes)

We need some pov on the following points: 1/ The DB field/variables names Colin suggested not to truncate the names. But, for instance, rrp_it would become recommended_retail_price_including_tax, not convenient. Any thought? 2/ Rounding I suggest to add a new pref to define the decimal to get for price calculation. So we need to change all the price DB fields to something like decimal(13,4). Does it make sense for everyone? 3/ Unified the "vat", "gst" and "tax" terms into "tax". Which is more generic.

Please express yourself if you disagree.

Regards, Jonathan

2014-07-21 17:32 GMT+02:00 Jonathan Druart <jonathan.druart@biblibre.com>:

...

Hello,

As promised, I have just finished to translate the spec for the VAT/GST rewrite.

You can found them on the wiki: http://wiki.koha-community.org/wiki/GST_Rewrite_RFC

Note that I am waiting for some feedbacks before starting the development. I really would like to know if the logic is good for all of you/your customers/use cases and if you agree on the values calculation.

Regards, Jonathan

On Thu, Aug 28, 2014 at 08:06:06AM -0400, Philippe Blouin wrote:

So, splitting hair, I'd say rrp_incl_tax, if rrp is commonly used. But that's just me. :)

That is the point it is not a commonly used term (in all countries) and historically there has been some confusion within the Koha community as to what rrp actually is an abbreviation for and what this variable does/should represent. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 800 756 6803 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com