IRC logs of #tryton for Tuesday, 2012-01-31 #tryton log beginning Tue Jan 31 00:00:02 CET 2012
2012-01-31 00:44 <meanmicio> cedk : thanks. I will be including the method for qrcode in trytond
2012-01-31 00:46 <meanmicio> cedk : so we can call it like qrgraph (party ssn number) or similar to have it for all the modules, in addition to GNU Health
2012-01-31 00:51 <cedk> meanmicio: I don't understand
2012-01-31 00:56 <meanmicio> cedk : I will create a method in to generate qrcode
2012-01-31 00:57 <meanmicio> cedk : in trytond
2012-01-31 00:58 <cedk> meanmicio: why?
2012-01-31 01:00 <meanmicio> cedk : so anyone can use it for other purposes. Products for example
2012-01-31 01:02 <cedk> meanmicio: it is just a matter of calling a method
2012-01-31 01:03 <meanmicio> image: (object.field, 'image/png') still does not render the image... weird
2012-01-31 01:03 <meanmicio> cedk : no error, but no image either
2012-01-31 09:22 <gueux> hi
2012-01-31 09:31 <gueux> how can I change the way IDs are given to sales? instead of 1,2,3,..., I'd like to give something like: ${year}${month}${day}${number with increments}
2012-01-31 09:50 <gltripp> moin
2012-01-31 09:57 <bechamel> gueux: you can defined it in the sale sequence, accessible trough Sale > Sale Configuration
2012-01-31 10:08 <gueux> bechamel: and then? "open a record" -> "prefix"?
2012-01-31 10:10 <bechamel> gueux: yes
2012-01-31 10:12 <gueux> I tried to put ${year}${month}${day} as prefix, but it does not seem to change the "reference" on the "sales" view...
2012-01-31 10:14 <bechamel> gueux: this only work with new sale, it will not change previous ones
2012-01-31 10:14 <gueux> ok
2012-01-31 10:14 <gueux> I'd just realized that :)
2012-01-31 10:14 <gueux> thanks
2012-01-31 10:18 <gueux> I have another question: I have to display something like "no tax (art 123a)" on every invoice. Is putting a footer on my company's configuration the best way to do that?
2012-01-31 10:21 <gueux> and a last one (I hope :)): is it possible to output something more beautiful than a libreoffice document for invoices? (a pdf file generated with latex code :))
2012-01-31 10:22 <bechamel> gueux: IMO the best way would be to create a module that allows to define it in the sale configuration form, and then put it automatically in the Comment field of each sale
2012-01-31 10:22 <bechamel> gueux: but changing the report is probably easier
2012-01-31 10:24 <bechamel> gueux: to support latex report you will have to inherit the Report class in report/
2012-01-31 10:29 <gueux> bechamel: do you have an example of how to achieve that? maybe someone has already done a latex export module?
2012-01-31 10:30 -!- navis(~user@ has left #tryton
2012-01-31 10:35 <bechamel> gueux: I think it's just a matter of inheriting Report and overwritting the parse method to return the latex result
2012-01-31 10:36 <bechamel> gueux: but I don't know any example, you should ask the mailing list
2012-01-31 10:41 <gueux> ok, thanks a lot :)
2012-01-31 10:44 <navis> bechamel: cedk: I'm back to discuss the tax-included calculation possibility
2012-01-31 10:45 <navis> do you prefer to discuss in French ? (I'm french speaking myself)
2012-01-31 10:45 <cedk> navis: I don't have time now
2012-01-31 10:46 <navis> cedk: when do you prefer ?
2012-01-31 10:46 <cedk> navis: I don't know
2012-01-31 10:49 <bechamel> navis, cedk : what about a blueprint to sum up the situation ?
2012-01-31 10:49 <cedk> bechamel: yes of course
2012-01-31 10:50 <navis> bechamel: I'm not familiar with that, that's on the wiki ?
2012-01-31 10:51 <bechamel> navis: yes
2012-01-31 10:52 <navis> bechamel: ok, as I'm familiar with the requirements, I can sum them up and propose a solution
2012-01-31 10:53 <bechamel> navis: great
2012-01-31 10:53 <navis> bechamel: how do I write there ? :-)
2012-01-31 10:54 <bechamel> navis: you don't have access to the wiki ?
2012-01-31 10:55 <navis> bechamel: it seems I can comment on pages, but I don't see how to create a new one, or modify an existing one
2012-01-31 10:56 <navis> bechamel: note that I'm new to all that google stuff, I might have missed it :-)
2012-01-31 10:57 <bechamel> navis: I think we must allows you to edit it, give us the mail address you use for your google account (here or by private chat if you prefer)
2012-01-31 11:06 <gltripp> cedk: it seems that i've migrated my database successfully :-)
2012-01-31 11:07 <gltripp> i had to fix some database records
2012-01-31 11:07 <gltripp> 1. delete some "dead" records from model_field
2012-01-31 11:08 <gltripp> 2. fix one entry in stock_move which belongs to service (why is it possible to add stock movings for services, if this raises an error on a migration?)
2012-01-31 11:10 <cedk> gltripp: it should not
2012-01-31 11:19 <cedk> gltripp: it is perhaps because of this
2012-01-31 11:25 <gltripp> :-)
2012-01-31 12:23 <navis>
2012-01-31 12:23 <navis> can you comment ?
2012-01-31 12:29 <bechamel> navis: nice summary
2012-01-31 12:30 <navis> bechamel: thanks, tried to be as clear as possible
2012-01-31 12:32 <bechamel> I was working with cedk on the first attempt to do a tax-included module for tinyerp, and I don't remember what exactly was the real problem
2012-01-31 12:33 <bechamel> iirc the constraints were that we add to do it on the same object trough (only) a separated module
2012-01-31 12:33 <navis> bechamel: you tried the same logic ? (calculating on tax included prices)
2012-01-31 12:33 <bechamel> and the sale model is made (was?) of big methods difficult to inherit/extend
2012-01-31 12:34 <bechamel> maybe with a "friendlier" base model it will be doable without an extra model
2012-01-31 12:35 <bechamel> navis: I don't remember
2012-01-31 12:36 <navis> bechamel: I'm a very beginner programmer, but I have looked at sale, and the bulk of the work seems to be in on_change_lines and get_*_amount
2012-01-31 12:37 <navis> the logic just has to be decided depending on a true/false switch
2012-01-31 12:39 <bechamel> navis: the main problem is that we choose to work tax included or excluded based on the customer, so for each product we need one tax included price and one tax excluded price (plus a constraint that check if those are consistent)
2012-01-31 12:41 <navis> bechamel: is it possible to define a new field b2c_price in product, and make a constraint for list_price ?
2012-01-31 12:42 <navis> bechamel: so that only b2c_price is editable, and list_price is computed from this value ?
2012-01-31 12:43 <bechamel> navis: yes, but both must be editable
2012-01-31 12:43 <navis> bechamel: why ?
2012-01-31 12:43 <bechamel> navis: because it's not possible to compute the other in all the case
2012-01-31 12:43 <navis> bechamel: can you give an example ?
2012-01-31 12:44 <bechamel> navis: it is exactly what you explained in the blueprint
2012-01-31 12:44 <bechamel> in the "Issue" section
2012-01-31 12:45 <navis> ok, of course it must be rounded
2012-01-31 12:45 <cedk> I really don't care if list_price and list_price_tax_included are not consistant
2012-01-31 12:45 <navis> but that doesn't mean that it cannot be computed and rounded
2012-01-31 12:45 <bechamel> navis: for some product you care about rouding the tax-included price, but for some other you care about the tax_excluded price
2012-01-31 12:46 <navis> bechamel: I would say for some clients, not products
2012-01-31 12:47 <navis> bechamel: but I see your point
2012-01-31 12:48 <navis> bechamel: so both can be editable, with a button to calculate one way or the other
2012-01-31 12:48 <bechamel> cedk: actually, I think it's impossible to check if they are consistant, because it will depends of the context
2012-01-31 12:49 <bechamel> navis: or maybe a check-box that say which one is "important"
2012-01-31 12:49 <cedk> bechamel: but why do you want such constraint?
2012-01-31 12:49 <cedk> bechamel: both will be used in different context
2012-01-31 12:49 <navis> bechamel: yep, was just thinking the same
2012-01-31 12:49 <bechamel> cedk: yes
2012-01-31 12:49 <cedk> bechamel: also it must be defined what is tax included?
2012-01-31 12:50 <cedk> I mean which taxes?
2012-01-31 12:50 <navis> cedk: yes, the «default scenario» has to be defined
2012-01-31 12:50 <bechamel> cedk, navis: so maybe the best is one field and a check-box that says if it is tax-included or not
2012-01-31 12:50 <cedk> bechamel: WTF
2012-01-31 12:50 <navis> bechamel: I like it
2012-01-31 12:50 <bechamel> :)
2012-01-31 12:50 <navis> lol :-)
2012-01-31 12:50 <bechamel> cedk: you have a better idea ?
2012-01-31 12:51 <cedk> bechamel: nothing!
2012-01-31 12:52 <bechamel> cedk: so my idea is the best one :)
2012-01-31 12:52 <cedk> bechamel: we don't have a constraint that check if cost price is lower than list price
2012-01-31 12:52 <cedk> bechamel: no I mean do nothing
2012-01-31 12:52 <bechamel> cedk: yes ok to remove the constraint
2012-01-31 12:52 <navis> cedk: changing the way the sale is calculated should only change the rounding, not the whole amount
2012-01-31 12:53 <bechamel> cedk: I ask if you prefer two field and a checkbox or one field and a checkbox
2012-01-31 12:53 <cedk> bechamel: any one
2012-01-31 12:56 <gltripp> hmm
2012-01-31 12:56 <bechamel> what about invoicing and account move creation ? it will also breaks
2012-01-31 12:57 <gltripp> account_invoice_disount does not work for 2.2 ?
2012-01-31 12:57 <navis> bechamel: they do not take amounts from sale ?
2012-01-31 12:58 <cedk> navis: yes the net price
2012-01-31 12:59 <navis> so that has to be adapted too, will look how it works now
2012-01-31 12:59 <cedk> That's why I said it can not be managed in sane way inside the sale module
2012-01-31 13:17 <navis> ok, so if I understand correctly, all the logic to calculate taxes is in invoice
2012-01-31 13:17 <navis> sale just uses that code
2012-01-31 13:19 <navis> so the real modifications are in invoice
2012-01-31 13:20 <navis> to add the possibility to reverse the logic in invoice
2012-01-31 13:20 <gltripp> is there an option to make discounts in tryton 2.2. ?
2012-01-31 13:20 <navis> and then a bit in sale to make it use that new code when appropriate
2012-01-31 13:23 <cedk> gltripp: I have wroten account_invoice_rebate
2012-01-31 13:23 <cedk> gltripp: I don't know if it is what you are looking for
2012-01-31 13:26 <gltripp> what i need: i got an invoice from a creditor with a term "x % off if paid within y days"
2012-01-31 13:26 <navis> cedk: bechamel: I updated the blueprint to take into account that invoice also has to be adapted
2012-01-31 13:30 <cedk> navis: also the unit price of stock move
2012-01-31 13:32 <navis> cedk: isn't this the cost_price from product ?
2012-01-31 13:33 <navis> cedk: cost_price is unaffected by all this
2012-01-31 13:33 <cedk> navis: unit price
2012-01-31 13:36 <navis> cedk: where is unit_price defined ?
2012-01-31 13:38 <cedk> navis: on stock move
2012-01-31 13:38 <cedk> navis: it must be the unit price involved in the move
2012-01-31 13:38 <navis> cedk: I see unit_price = product.cost_price, then a bunch of calculations on it
2012-01-31 13:39 <cedk> navis: for incoming move it is the purchase price and outgoing move it is the sale price
2012-01-31 13:40 <navis> cedk: ok
2012-01-31 13:45 <navis> cedk: so the stock is decremented of the sale price when a product is sold ?
2012-01-31 13:59 <jcm> navis: iiuc, the stock accounts are impacted by moves only if account_stock_continental module is installed
2012-01-31 14:07 <jcm> navis: the problem I see in you b2c computation is that you need to have tax and prices*qty rounded on each line, and not on totals. But the system of rounding in invoices must be, as far as I know, chosen once per fiscal period and may not vary depending on the client
2012-01-31 14:15 <navis> jcm: rounding is not changed, only the base for calculation is changed
2012-01-31 14:15 <navis> jcm: b2b uses prices without taxes, b2c uses prices with taxes
2012-01-31 14:16 <navis> jcm: in b2b you calculate totals without taxes, and add taxes
2012-01-31 14:17 <navis> jcm: in b2c you calculate totals with taxes, and remove taxes to get total without tax
2012-01-31 14:18 <jcm> on a fiscal point of view, what matters is the total without tax (the basis you take to compute the taxes)
2012-01-31 14:18 <jcm> navis: in what you describe, how will you compute the total without tax for each tax rate ?
2012-01-31 14:24 <navis> I haven't looked at it, but I guess the current behaviour is conserved
2012-01-31 14:27 <navis> jcm: I haven't looked at it, but I guess the current behaviour is conserved
2012-01-31 14:27 <navis> jcm: what I propose just modifies the base on which rounding is applied
2012-01-31 14:27 <navis> jcm: all other behaviours should stay unaffected
2012-01-31 14:28 <navis> jcm: in particular, invoice lines still have a net untaxed price
2012-01-31 14:30 <jcm> navis: I'm pretty sure that if you dig deeper into this problem, you'll find that you cannot have the computations on vat included prices be always exact without rounding taxes by lines instead of by totals. And imho it's a choice that must be done for fiscal period and not per invoice.
2012-01-31 14:31 <jcm> navis: an alternative I read (about mobile phone rounding in invoices, see recent discussions in France) would be to make a second computation based on vat included tax prices, then compare with the result obtained from b2b (current method in tryton)
2012-01-31 14:33 <jcm> and then add the difference (< 0,01 * nlines) to an account like Various Expenses or Products (in French Accounting Chart, 658, 758)
2012-01-31 14:34 <navis> jcm: can you provide a practical example of a problematic situation as a comment in the wiki ?
2012-01-31 14:34 <navis> jcm: I'm afraid I don't understand exactly what you mean
2012-01-31 14:43 <jcm> navis: I'll try ;-)
2012-01-31 14:46 <navis> jcm: I think I understood: considering the amounts without tax, the sum of lines could be different from the total
2012-01-31 14:47 <navis> jcm: due to calculating the total based on the total with tax
2012-01-31 14:47 <navis> jcm: which is a problem if different lines have different tax codes
2012-01-31 14:51 <jcm> navis: just retested. Fiscal problem is to compute tax correctly (ie, as it's done currently in tryton). Communication problem: don't show rounding problems on vat included prices to client
2012-01-31 14:53 <jcm> navis: for a VAT incl. price of 10€, with a tax rate of 19,6%, quantity=4 : list_price (tax excl.) is 8,36 € if you round it ; then the line total tax is 6,55 €, whereas the tax excl. total is 33,44€
2012-01-31 14:53 <jcm> DIfference with vat incl. total is 0,01 €
2012-01-31 14:54 <jcm> navis: imho everything is solved f you choose a better precision to express you list_prices (ie without tax)
2012-01-31 14:55 <jcm> navis: if you usually sell quantities < 1000, a four digits precision list-price leads to no rounding error on vat incl totals
2012-01-31 14:56 <jcm> navis: my accountant told me I can choose more than two digits precision for list prices, as soon as I do it consistenty for all products and clients
2012-01-31 15:01 <navis> jcm: I have a db with prices at 4 decimals, and I had rounding errors in sales while testing
2012-01-31 15:02 <jcm> navis: with small quantities ?
2012-01-31 15:03 <navis> jcm: yes
2012-01-31 15:03 <navis> jcm: but maybe tryton calculates on rounded values, I'll have to check that
2012-01-31 15:03 <jcm> do you have an example (list_price, tax_rate, qty) ?
2012-01-31 15:04 <cedk> navis: it depends what you name rounding errors
2012-01-31 15:04 <jcm> navis: see account/ line 1547 : rounding made on total of the line
2012-01-31 15:04 <navis> cedk: the price was not round as it should have been
2012-01-31 15:06 <jcm> navis: "rounding error" = rounding not done correctly ; "rounding difference" = rounding of total tax excl. + rounding of tax != qty * vat incl. price
2012-01-31 15:06 <navis> ok not errors, but not b2c safe :-)
2012-01-31 15:10 <cedk> I already said, it is not possible to have an invoice out-of-the-box with an expected total amount
2012-01-31 15:11 <jcm> cedk: sure. Why not only do cosmetic: when needed (per client basis), compute the difference to be offered by the company to have the "expected vat incl. total from the client point of view" ?
2012-01-31 15:12 <cedk> jcm: that's why the tax amount computed is editable on invoice
2012-01-31 15:13 <jcm> cedk: I'm not sure the fiscal authority would agree on a tax amount being reduced
2012-01-31 15:13 <jcm> navis: if expected total > computed one : increase tax amount ; else offer the difference
2012-01-31 15:14 <cedk> jcm: it will depend of the rounding method
2012-01-31 15:18 <cedk> this module do the job but only with account move no invoice
2012-01-31 15:18 <cedk>
2012-01-31 15:37 <jcm> cedk: is there a report to print inventory sheets ? would list all references, one per line, with code and title, and an empty rectangle to write quantity
2012-01-31 15:39 <cedk> jcm: I don't think
2012-01-31 15:40 <jcm> should I build a class InventoryReport inspired from InvoiceReport ? is there a simpler example ?
2012-01-31 15:40 <cedk> jcm: yes
2012-01-31 15:43 <jcm> cedk: when I find translation or typo errors in client, should I add them to a single issue (named 'client fr translation') ?
2012-01-31 15:45 <cedk> jcm: don't know it depends on how much time to fix
2012-01-31 15:49 <jcm> cedk: I cannot run trunk client version, didn't find how to do it on mac (many packages to tweak again in gtk on macport), so I canno submit patches to trunk for this :/
2012-01-31 17:19 <cedk> bdunnette: could you fix your connection?
2012-01-31 17:41 -!- pjstevns( has left #tryton
2012-01-31 18:27 -!- scrapper(~scrapper@ has left #tryton
2012-01-31 18:37 <meanmicio> Hi all ! Just implemented the initial QR code identification for GNU Health. It can be of course used in any context.
2012-01-31 20:29 -!- Timitos(~kp@ has left #tryton
2012-01-31 21:12 -!- bdunnette(~dunn0172@2001:468:1910:3c06:a11:96ff:fe29:26d4) has left #tryton
2012-01-31 21:19 <navis> jcm: tried the solution to augment the precision of numbers, by putting rounding at 0.0001
2012-01-31 21:20 <navis> jcm: it works at the sale level, but then I cannot invoice
2012-01-31 21:20 <navis> jcm: The field "Amount" on "Invoice Tax" has too many decimal digits.
2012-01-31 22:59 -!- Telesight( has left #tryton

Generated by 2.17.3 by Marius Gedminas - find it at!