| chat.freenode.net #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 report.py 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/report.py | ||
| 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@91.180.23.57) 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 http://bugs.tryton.org/issue2430 | ||
| 2012-01-31 11:25 <gltripp> :-) | ||
| 2012-01-31 12:23 <navis> http://code.google.com/p/tryton/wiki/SaleB2c | ||
| 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 http://codereview.tryton.org/206005/ | ||
| 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/invoice.py 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> http://www.b2ck.com/~ced/hg/hgwebdir.cgi/modules/sale_import | ||
| 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(~paul@a83-163-46-103.adsl.xs4all.nl) has left #tryton | ||
| 2012-01-31 18:27 -!- scrapper(~scrapper@88.117.159.6) 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@88.217.184.172) 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(~chatzilla@s537751a5.adsl.wanadoo.nl) has left #tryton |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!