IRC logs of #tryton for Tuesday, 2012-01-31 #tryton log beginning Tue Jan 31 00:00:02 CET 2012
meanmiciocedk : thanks. I will be including the method for qrcode in trytond00:44
meanmiciocedk : so we can call it like qrgraph (party ssn number)  or similar to have it for all the modules, in addition to GNU Health00:46
cedkmeanmicio: I don't understand00:51
meanmiciocedk : I will create a method in to generate qrcode00:56
meanmiciocedk : in trytond00:57
cedkmeanmicio: why?00:58
meanmiciocedk : so anyone can use it for other purposes. Products for example01:00
cedkmeanmicio: it is just a matter of calling a method01:02
meanmicioimage: (object.field, 'image/png') still does not render the image... weird01:03
meanmiciocedk : no error, but no image either01:03
gueuxhow 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}09:31
bechamelgueux: you can defined it in the sale sequence, accessible trough Sale > Sale Configuration09:57
gueuxbechamel: and then? "open a record" -> "prefix"?10:08
bechamelgueux: yes10:10
gueuxI tried to put ${year}${month}${day} as prefix, but it does not seem to change the "reference" on the "sales" view...10:12
bechamelgueux: this only work with new sale, it will not change previous ones10:14
gueuxI'd just realized that :)10:14
gueuxI 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?10:18
gueuxand 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 :))10:21
bechamelgueux: 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 sale10:22
bechamelgueux: but changing the report is probably easier10:22
bechamelgueux: to support latex report you will have to inherit the Report class in report/report.py10:24
gueuxbechamel: do you have an example of how to achieve that? maybe someone has already done a latex export module?10:29
-!- navis(~user@ has left #tryton10:30
bechamelgueux: I think it's just a matter of inheriting Report and overwritting the parse method to return the latex result10:35
bechamelgueux: but I don't know any example, you should ask the mailing list10:36
gueuxok, thanks a lot :)10:41
navisbechamel: cedk: I'm back to discuss the tax-included calculation possibility10:44
navisdo you prefer to discuss in French ? (I'm french speaking myself)10:45
cedknavis: I don't have time now10:45
naviscedk: when do you prefer ?10:46
cedknavis: I don't know10:46
bechamelnavis, cedk : what about a blueprint to sum up the situation ?10:49
cedkbechamel: yes of course10:49
navisbechamel: I'm not familiar with that, that's on the wiki ?10:50
bechamelnavis: yes10:51
navisbechamel: ok, as I'm familiar with the requirements, I can sum them up and propose a solution10:52
bechamelnavis: great10:53
navisbechamel: how do I write there ? :-)10:53
bechamelnavis: you don't have access to the wiki ?10:54
navisbechamel: it seems I can comment on pages, but I don't see how to create a new one, or modify an existing one10:55
navisbechamel: note that I'm new to all that google stuff, I might have missed it :-)10:56
bechamelnavis: 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)10:57
gltrippcedk: it seems that i've migrated my database successfully :-)11:06
gltrippi had to fix some database records11:07
gltripp1. delete some "dead" records from model_field11:07
gltripp2. 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?)11:08
cedkgltripp: it should not11:10
cedkgltripp: it is perhaps because of this
naviscan you comment ?12:23
bechamelnavis: nice summary12:29
navisbechamel: thanks, tried to be as clear as possible12:30
bechamelI 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 problem12:32
bechameliirc the constraints were that we add to do it on the same object trough (only) a separated module12:33
navisbechamel: you tried the same logic ? (calculating on tax included prices)12:33
bechameland the sale model is made (was?) of big methods difficult to inherit/extend12:33
bechamelmaybe with a "friendlier" base model it will be doable without an extra model12:34
bechamelnavis: I don't remember12:35
navisbechamel: 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_*_amount12:36
navisthe logic just has to be decided depending on a true/false switch12:37
bechamelnavis: 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)12:39
navisbechamel: is it possible to define a new field b2c_price in product, and make a constraint for list_price ?12:41
navisbechamel: so that only b2c_price is editable, and list_price is computed from this value ?12:42
bechamelnavis: yes, but both must be editable12:43
navisbechamel: why ?12:43
bechamelnavis: because it's not possible to compute the other in all the case12:43
navisbechamel: can you give an example ?12:43
bechamelnavis: it is exactly what you explained in the blueprint12:44
bechamelin the "Issue" section12:44
navisok, of course it must be rounded12:45
cedkI really don't care if list_price and list_price_tax_included are not consistant12:45
navisbut that doesn't mean that it cannot be computed and rounded12:45
bechamelnavis: for some product you care about rouding the tax-included price, but for some other you care about the tax_excluded price12:45
navisbechamel: I would say for some clients, not products12:46
navisbechamel: but I see your point12:47
navisbechamel: so both can be editable, with a button to calculate one way or the other12:48
bechamelcedk: actually, I think it's impossible to check if they are consistant, because it will depends of the context12:48
bechamelnavis: or maybe a check-box that say which one is "important"12:49
cedkbechamel: but why do you want such constraint?12:49
cedkbechamel: both will be used in different context12:49
navisbechamel: yep, was just thinking the same12:49
bechamelcedk: yes12:49
cedkbechamel: also it must be defined what is tax included?12:49
cedkI mean which taxes?12:50
naviscedk: yes, the «default scenario» has to be defined12:50
bechamelcedk, navis: so maybe the best is one field and a check-box that says if it is tax-included or not12:50
cedkbechamel: WTF12:50
navisbechamel: I like it12:50
navislol :-)12:50
bechamelcedk: you have a better idea ?12:50
cedkbechamel: nothing!12:51
bechamelcedk: so my idea is the best one :)12:52
cedkbechamel: we don't have a constraint that check if cost price is lower than list price12:52
cedkbechamel: no I mean do nothing12:52
bechamelcedk: yes ok to remove the constraint12:52
naviscedk: changing the way the sale is calculated should only change the rounding, not the whole amount12:52
bechamelcedk: I ask if you prefer two field and a checkbox or one field and a checkbox12:53
cedkbechamel: any one12:53
bechamelwhat about invoicing and account move creation ? it will also breaks12:56
gltrippaccount_invoice_disount does not work for 2.2 ?12:57
navisbechamel: they do not take amounts from sale ?12:57
cedknavis: yes the net price12:58
navisso that has to be adapted too, will look how it works now12:59
cedkThat's why I said it can not be managed in sane way inside the sale module12:59
navisok, so if I understand correctly, all the logic to calculate taxes is in invoice13:17
navissale just uses that code13:17
navisso the real modifications are in invoice13:19
navisto add the possibility to reverse the logic in invoice13:20
gltrippis there an option to make discounts in tryton 2.2. ?13:20
navisand then a bit in sale to make it use that new code when appropriate13:20
cedkgltripp: I have wroten account_invoice_rebate
cedkgltripp: I don't know if it is what you are looking for13:23
gltrippwhat i need: i got an invoice from a creditor with a term "x % off if paid within y days"13:26
naviscedk: bechamel: I updated the blueprint to take into account that invoice also has to be adapted13:26
cedknavis: also the unit price of stock move13:30
naviscedk: isn't this the cost_price from product ?13:32
naviscedk: cost_price is unaffected by all this13:33
cedknavis: unit price13:33
naviscedk: where is unit_price defined ?13:36
cedknavis: on stock move13:38
cedknavis: it must be the unit price involved in the move13:38
naviscedk: I see unit_price = product.cost_price, then a bunch of calculations on it13:38
cedknavis: for incoming move it is the purchase price and outgoing move it is the sale price13:39
naviscedk: ok13:40
naviscedk: so the stock is decremented of the sale price when a product is sold ?13:45
jcmnavis: iiuc, the stock accounts are impacted by moves only if account_stock_continental module is installed13:59
jcmnavis: 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 client14:07
navisjcm: rounding is not changed, only the base for calculation is changed14:15
navisjcm: b2b uses prices without taxes, b2c uses prices with taxes14:15
navisjcm: in b2b you calculate totals without taxes, and add taxes14:16
navisjcm: in b2c you calculate totals with taxes, and remove taxes to get total without tax14:17
jcmon a fiscal point of view, what matters is the total without tax (the basis you take to compute the taxes)14:18
jcmnavis: in what you describe, how will you compute the total without tax for each tax rate ?14:18
navisI haven't looked at it, but I guess the current behaviour is conserved14:24
navisjcm: I haven't looked at it, but I guess the current behaviour is conserved14:27
navisjcm: what I propose just modifies the base on which rounding is applied14:27
navisjcm: all other behaviours should stay unaffected14:27
navisjcm: in particular, invoice lines still have a net untaxed price14:28
jcmnavis: 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.14:30
jcmnavis: 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)14:31
jcmand then add the difference (< 0,01 * nlines) to an account like Various Expenses or Products (in French Accounting Chart, 658, 758)14:33
navisjcm: can you provide a practical example of a problematic situation as a comment in the wiki ?14:34
navisjcm: I'm afraid I don't understand exactly what you mean14:34
jcmnavis: I'll try ;-)14:43
navisjcm: I think I understood: considering the amounts without tax, the sum of lines could be different from the total14:46
navisjcm: due to calculating the total based on the total with tax14:47
navisjcm: which is a problem if different lines have different tax codes14:47
jcmnavis: 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 client14:51
jcmnavis: 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€14:53
jcmDIfference with vat incl. total is 0,01 €14:53
jcmnavis: imho everything is solved f you choose a better precision to express you list_prices (ie without tax)14:54
jcmnavis: if you usually sell quantities < 1000, a four digits precision list-price leads to no rounding error on vat incl totals14:55
jcmnavis: 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 clients14:56
navisjcm: I have a db with prices at 4 decimals, and I had rounding errors in sales while testing15:01
jcmnavis: with small quantities ?15:02
navisjcm: yes15:03
navisjcm: but maybe tryton calculates on rounded values, I'll have to check that15:03
jcmdo you have an example (list_price, tax_rate, qty) ?15:03
cedknavis: it depends what you name rounding errors15:04
jcmnavis:  see account/ line 1547 : rounding made on total of the line15:04
naviscedk: the price was not round as it should have been15:04
jcmnavis: "rounding error" = rounding not done correctly ; "rounding difference" = rounding of total tax excl. + rounding of tax != qty * vat incl. price15:06
navisok not errors, but not b2c safe :-)15:06
cedkI already said, it is not possible to have an invoice out-of-the-box with an expected total amount15:10
jcmcedk: 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" ?15:11
cedkjcm: that's why the tax amount computed is editable on invoice15:12
jcmcedk: I'm not sure the fiscal authority would agree on a tax amount being reduced15:13
jcmnavis: if expected total > computed one : increase tax amount ; else offer the difference15:13
cedkjcm: it will depend of the rounding method15:14
cedkthis module do the job but only with account move no invoice15:18
jcmcedk: 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 quantity15:37
cedkjcm: I don't think15:39
jcmshould I build a class InventoryReport inspired from InvoiceReport ? is there a simpler example ?15:40
cedkjcm: yes15:40
jcmcedk: when I find translation or typo errors in client, should I add them to a single issue (named 'client fr translation') ?15:43
cedkjcm: don't know it depends on how much time to fix15:45
jcmcedk: 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 :/15:49
cedkbdunnette: could you fix your connection?17:19
-!- pjstevns( has left #tryton17:41
-!- scrapper(~scrapper@ has left #tryton18:27
meanmicioHi all ! Just implemented the initial QR code identification for GNU Health. It can be of course used in any context.18:37
-!- Timitos(~kp@ has left #tryton20:29
-!- bdunnette(~dunn0172@2001:468:1910:3c06:a11:96ff:fe29:26d4) has left #tryton21:12
navisjcm: tried the solution to augment the precision of numbers, by putting rounding at 0.000121:19
navisjcm: it works at the sale level, but then I cannot invoice21:20
navisjcm: The field "Amount" on "Invoice Tax" has too many decimal digits.21:20
-!- Telesight( has left #tryton22:59

Generated by 2.11.0 by Marius Gedminas - find it at!