IRC logs of #tryton for Monday, 2012-01-30 #tryton log beginning Mon Jan 30 00:00:01 CET 2012
-!- plantian( has left #tryton06:43
-!- udono( has left #tryton08:19
naviscedk: hi, would you consider including in tryton a module with the "tax included prices" modifications discussed here on 26/01 with grasbauer ?11:32
navisbegins at 16:3911:32
cedknavis: I'm not sure to understand11:37
naviscedk: 4 days ago we discussed a solution for businesses who need to sell with "all taxes included" prices11:40
naviscedk: grasbauer said that they had made it for a customer by calculating everything based on a sale_price, which is tax included, and retro computing the net price from that11:41
naviscedk: for example so that prices like 9,95 are respected on invoices11:42
naviscedk: this is a requirement if one wants a pos solution later on11:42
naviscedk: my question is would such a functionnality be considered for inclusion in tryton ?11:43
cedknavis: I can not say because I don't understand what you want to do12:00
naviscedk: ok, I need to sell with taxes included12:01
cedknavis: I understand the requirements, but not the solution12:01
naviscedk: that means that prices like 1€ should appear like that on invoices, and all calculations should be done with that price, and not the 0,83 approximation12:02
naviscedk: ah ok12:02
naviscedk: the solution is to modify the sale object so that all calculations are done using the tax included price12:02
naviscedk: and at the end the net (tax excluded) prices are retro computed from that12:03
cedknavis: I'm against such solution12:03
naviscedk: why ?12:03
cedknavis: because it is not the role of sale to do that, it is pos12:04
naviscedk: no, this is independent from pos12:04
naviscedk: pos needs this, but others too12:04
naviscedk: consider a retailer web site, selling b2c and not b2b12:04
cedknavis: it is a pos12:05
cedknavis: sale module is b2b and pos should be b2c12:05
naviscedk: a web site like amazon is a pos ?12:05
naviscedk: a pos has much more requirements than that12:05
naviscedk: and is absolutely not adapted to web sales12:06
naviscedk: pos is a sales canal, like any other one12:07
naviscedk: it is independent of your target client12:08
naviscedk: tax included or excluded is dependent on your target client, not the sales canal12:08
naviscedk: you can sell with prices tax included or excluded at a pos and on the web, it depends on your client, not where you sell12:09
cedknavis: I don't agree12:10
naviscedk: you mean a web site selling to end users must use a pos ???12:11
naviscedk: and you can't sell to businesses at a pos ?12:12
cedknavis: I don't care about the name pos12:12
cedknavis: sale is b2b and b2c is something else12:13
naviscedk: ok, so if I understand correctly, you prefer a new object, same as sale but with tax included logic12:15
naviscedk: like a sale_b2c12:16
cedknavis: yes12:16
naviscedk: could that be included in tryton when done ?12:18
cedknavis: why not12:20
naviscedk: just a question, why do you prefer a different object ?12:22
naviscedk: I mean, sale_b2c can also be used to sell to businesses, it is just using a different base to calculate prices12:26
cedknavis: because from experience mixing taxe included with tax excluded doesn't work12:26
naviscedk: I didn't plan to mix, by activating the tax included module, you switch to tax included calculations12:28
naviscedk: with t12:29
naviscedk: with two objects, we will have to make them mutually exclusive12:29
naviscedk: is this possible in tryton ? declaring a conflict between two modules ?12:30
bechamelnavis: why do you want to makes them exclusive12:31
navisbechamel: because they would make the same product have a different price for the same client12:32
navisbechamel: 1€ tax included is not 0,82 tax excluded12:33
navisbechamel: it would be very illogical to use both12:33
bechamelnavis: what if you sell tax included to some of your customers and tax excluded to others ?12:33
navisbechamel: it is not selling tax included or excluded, it is just basing the calculations on the tax included or excluded amount12:35
navisbechamel: you can calculate on the tax included prices, and still sell tax excluded12:35
navisbechamel: to some clients12:35
navisbechamel: when I sell to french business clients, they receive their invoices tax excluded12:36
navisbechamel: but their calculation is the same as any of my belgian clients12:36
bechamelnavis: ok but the modified calculation is especially usefull for tax included prices, isn't it ?12:37
navisbechamel: we sell to end users, so we have to use round tax included prices12:38
navisbechamel: that doesn't mean that we do not sell to businesses12:38
navisbechamel: take a simple example: let a product be 1€ vat included12:39
cedknavis: you can not use tax included if you sell in b2b12:39
cedknavis: because your net price will change depending on the quantity12:39
naviscedk: we announce prices vat included, to businesses too12:40
cedknavis: I will not buy to you if you don't tell me you vat excluded price12:41
naviscedk: if as a business you buy on amazon, your net price is based on a tax included price12:41
naviscedk: believe me, many business do :-)12:41
cedknavis: I don't know if amazon has a pro section12:43
naviscedk: it can just generate rounding errors for businesses who want vat excluded prices12:43
naviscedk: they usually don't care12:43
bechamelnavis: anyway, I don't see how "one sale model vs two sale model " change anything for you12:43
naviscedk: but try to sell a rounding error to a retail client, and see what happens12:44
navisbechamel: I didn't think about it, but why not...12:44
bechamelnavis: the "same product with different prices for the same client" is nit solved12:44
navisbechamel: I don't understand, can you be more specific ?12:46
cedkI don't see where I can put a VAT number on amazon, so not a good example12:46
bechamelnavis: it was about mutually-exclusive modules12:48
bechamelnavis: you want to make the modules mutually-exclusive but you also say that you have both business and non-business customers12:49
navisbechamel: yes, I have business customers, their price is the same as non-business12:51
navisbechamel: I of course have base, vat, and base+vat on my invoices12:51
navisbechamel: but all calculations are based on vat included prices12:52
navisbechamel: that only change the rounding, really12:52
navisbechamel: which is important to retail (10x1€ = 10€, not 10,04), but less to businesses12:53
cedknavis: it is not possible to have the same price for b2b and b2c12:53
cedknavis: what you do is manage b2b as b2c12:54
naviscedk: I do sell to plenty of businesses, and have never had any problem12:55
naviscedk: of course they know us as a retailer12:56
naviscedk: but after reflection, I have nothing against both modules coexisting12:56
naviscedk: and now I see the problem in mixing everything in sale12:57
naviscedk: that would not be a problem in our case, but could be for others12:57
meanmicioHello all !13:01
meanmicioI'll be working in implementing QR as IDs in GNU Health. If anyone has done something already in Tryton let me know, so we don't duplicate efforts13:02
cedkmeanmicio: you should take a look at
meanmiciocedk : thanks. I'm  working with qrcode (
meanmiciocedk : It looks quite nice, but is preliminary. This one generates easily a PNG from the argument. Just testing it.14:13
meanmiciocedk : now is a matter of embedding the resulting graph to Libreoffice14:15
cedkmeanmicio: which one?14:15
meanmiciocedk : the QR png graph generated with this qrcode lib14:16
meanmiciocedk : So we can use them in the reports.14:16
cedkmeanmicio: hubarcode also generate png14:18
meanmiciocedk: Yes. I will test both, since they both are in pypi. qrcode seem quite light.14:29
meanmiciocedk : Now is a matter of passing the data as an argument from Tryton, then embedding into Libreoffice.14:31
cedkmeanmicio: depends if you really will only need qr14:38
naviscedk: I'm looking at the sale_b2c (name is not set in stone :-) implementation discussed earlier today16:22
naviscedk: wouldn't using a new object mean that we have to reimplement all extensions made to sale ?16:22
naviscedk: like opportunities, price_lists, shipment,... and later pos, reservations,...16:23
naviscedk: all these apply to both objects16:24
naviscedk: reimplement is a big word, duplicating is more appropriate16:26
naviscedk: but still, «duplicating» sounds very bad in an it project...16:28
cedknavis: I don't see how opportunity could be used for a b2c16:29
cedknavis: I don't how shipment is a prequel to sale16:29
naviscedk: sale_shipment_cost16:30
cedknavis: price_list is generic and should work on any kind of Model16:30
naviscedk: it is sale_price_list, it specifically modifies sale and depends on it16:31
naviscedk: why would opportunity be irrelevant for non business clients ?16:32
naviscedk: I can get non business leads16:32
cedknavis: I will say for the last time, sale tax included is only for b2c16:37
-!- bdunnette(~dunn0172@2607:ea00:101:3c4c:5e26:aff:fe7a:3ea3) has left #tryton16:37
naviscedk: yes ok, I agree with that16:37
naviscedk: but all extensions made to sales are also relevant in b2c16:38
naviscedk: now maybe there is what is needed in tryton to make those extensions generic, I don't know it enough16:39
naviscedk: but there is no reason why opportunities, price_lists,... are not relevant for the b2c case16:40
cedknavis: sorry, but using price tax included is not relevant in an ERP16:41
cedknavis: so you can have a document that can work with it but it will never completly integrated in the system16:41
cedknavis: working with tax included has sense for b2c which is a pos16:42
naviscedk: I can see that you have much resistance to it, I don't understand why, but I will stop bothering you with it16:43
naviscedk: sorry to have lost your and my time16:43
cedknavis: I have because OpenERP has such feature that is broken since day 1 and will never work16:43
naviscedk: I know that this is broken in openerp, and i don't care, openerp is broken in so many ways that it is irrelevant now16:44
cedknavis: I worked on it during months without succeed16:45
naviscedk: but that doesn't mean that the functionnality has to be a broken hack16:45
cedknavis: so I'm sure we can not mix both in one document16:45
naviscedk: I'm ok with that16:45
naviscedk: and I'm ok with a separate object16:45
naviscedk: I'm just thinking about it and finding gotchas before I commit to it16:46
naviscedk: and one gotcha is that it duplicates functionnality16:46
cedknavis: I really prefer duplicate code than complex and buggy16:47
naviscedk: now if that functionnality (all extensions to sales) can be made to work on sale and sale_b2c, then no problem16:47
cedknavis: have you an example of software with such fonctionnalities?16:52
naviscedk: yes, I use it internally16:52
naviscedk: but every software which can sell to non businesses must have it in some form16:53
naviscedk: in the free o16:53
naviscedk: in the free world, I guess every web shop engine must have it16:54
cedknavis: come on every webshop can not even manage taxes correctly16:54
cedknavis: you mean your current software can work both way16:55
naviscedk: :-) ok ok for web shops :-)16:56
naviscedk: yes, but one has to decide one way or the other at initial configuration16:56
naviscedk: we manage all sales in tax-included calculation mode16:56
cedknavis: the software can work in one or other way out-of-the-box?16:57
cedknavis: more over, the more we talk the more I think you need a pos16:58
naviscedk: out of the box is a big word, it came fully installed with a contract16:58
naviscedk: but it can work both ways16:59
naviscedk: frankly I do need a pos, but it is not my priority right now16:59
-!- pjstevns( has left #tryton17:00
naviscedk: and that functionnality is not stritcly limited to pos17:00
naviscedk: if I make it, I'd like to make it right17:00
bechamelnavis: does your current software allows to "tweak" tax rounding (iirc, it's the main issue with tax included prices).17:08
naviscedk: no, it is just that I define sale prices tax included for belgium, and other values are calculated from there17:10
navisoups, that was meant for bechamel...17:10
naviscedk: I just checked, can use both ways of calculating17:11
bechamelnavis: so when you sale to other countries, your prices are not rounded anymore ?17:11
naviscedk: go to, put 10x C6657GE in a basket, and you can see it ttc or hvat17:12
naviscedk: which is not the same amount17:12
navisbechamel: if business users, thats right17:12
navisbechamel: to take the same example, ldlc has the same way of doing things17:13
bechamelnavis: and for non-business customer? if I understand correctly you remove the 21% vat and the re-add the foreign vat17:13
navisbechamel: prices on and are the same, except for the difference in vat17:14
navisbechamel: no, non-business customers in the eu have 21% vat17:14
navisbechamel: and out of eu have no vat17:15
bechamelnavis: I see17:16
navisbechamel: this does not depend on the way prices are calculated, non business customers in eu pay the vat of the seller17:17
bechamelnavis: it looks likes it's easier to build a software that works with tax-included prices by default and handle tax-excluded as an exception than the other way around17:21
navisbechamel: yes, it seems so17:22
navisbechamel: if I take the plunge and implement a second sale object for b2c case, do you think it would be possible to make the other «sale enhancing» modules generic ?17:23
cedknavis: quantity is limited to 99 :-)17:24
naviscedk: on ldlc ? I had the same problem, that's why I said 10 :-)17:24
cedknavis: of course if you limit the quantity, you can not reach the issue17:25
naviscedk: yes, 10x C6657GE gets the issue17:25
naviscedk: vat included = 161,40; vat excluded = 133,4017:27
cedknavis: any way, I'm pretty sure they have define a price TTC and a price HTC17:27
naviscedk: 133,40 x 1,21 = 161,4117:27
bechamelnavis: if we want disctinct sale models and keep all the feature provided by extra modules, we need at least a common api and I think a common generic sale that will be inherited by both sale model17:27
cedknavis: of course, but what is their invoice?17:28
bechameland this means that all related modules must be adapted17:28
naviscedk: no idea, I guess they respect what is in the basket, that would be too gross17:28
cedknavis: so they have 2 objects17:29
bechamelcedk: "I'm pretty sure they have define a price TTC and a price HTC" -> is it an issue ?17:29
cedkbechamel: no but it will requires 2 objects to store both kind of command17:30
navisbechamel: the only difference is the way a sale_line and sale_total is calculated17:30
-!- bdunnette(~dunn0172@2607:ea00:101:3c4c:5e26:aff:fe7a:3ea3) has left #tryton17:30
cedknavis: not only calculated but also stored17:30
naviscedk: a sale line doesn't store all amounts ?17:32
naviscedk: yes it does, unit_price and amount are sufficient17:33
naviscedk: for sale you store net prices, for b2c you store ttc prices17:35
naviscedk: for sale, untaxed is the sum of amounts and total is computed17:37
naviscedk: for b2c total is the sum, and untaxed is computed17:37
cedkfor info:
naviscedk: what is it ?17:47
cedknavis: an old module to import sale line from a pos17:47
naviscedk: I'm a bit out of time today, I will come back tonight or tomorrow morning, I'd like to discuss this further to see if something nice can be done17:50
-!- bdunnette(~dunn0172@2607:ea00:101:3c4c:5e26:aff:fe7a:3ea3) has left #tryton19:02
meanmicioIt looks like there's an issue with relatorio/genshi when dealing with binary fields19:24
udonomeanmicio: hi, paepke has worked on barcode with Tryton. Maybe he has some ideas. You can find him on #tryton.de19:36
meanmicioudono : thanks19:38
meanmiciouduno : but unrelated to that, the binary fields are having issues when rendering19:39
udonomeanmicio: are you on tip?19:40
udonomeanmicio: or better ask: Which version of Tryton you use?19:41
meanmiciouduno : nope. Working on stable 2.219:41
meanmiciouduno : will check with the latest19:42
udonomeanmicio: It could be the change in 2.2 with the buffer, let me take a look...19:43
cedkmeanmicio: what is the issue?19:47
udonomeanmicio: the type for binary data changed in Tryton from base64 to buffer:
gltrippcedk: i didn't submit an issue19:48
cedkgltripp: why?19:49
meanmiciocedk : when trying to render/display a binary field (ie, patient picture) I get a traceback error (unicodedecode) at genshi/template/directives.py19:50
cedkmeanmicio: what do you put as directive?19:52
meanmiciocedk : just the field name (ie,
cedkmeanmicio: it can not work19:55
meanmiciocedk : of course, when is null it works (None) :-)19:56
cedkmeanmicio: image must be at least (bitstream, mimetype)19:57
cedkmeanmicio: where bitstream could be another relatorio report or file object19:57
cedkmeanmicio: it could also be (bitsream, mimetype, width, height)19:58
navis /j #tryton-fr20:00
cedkgltripp: if you don't submit issue, it will never be fixed20:00
meanmiciocedk : Sure, actually when the report template has an embedded picture works, but the idea is to be able to render the binary field (when is a pic of course)20:01
gltrippi know - i think i will do it in the next time20:01
gltrippthats strange20:22
gltrippi tried to upgrade from 1.8 to 2.020:23
gltrippand got...
meanmiciocedk : when using the object within a frame, it won't crash, but it does not render the pic either. I noticed that relatorio tries to identify the type for each field (__relatorio_guess_type).20:30
cedkmeanmicio: I don't understand20:33
cedkgltripp: I don't understand how you can have now this issue when yesterday you go until the migration of stock module20:33
gltrippyesterday: migration from 1.8 db to 2.220:36
-!- bdunnette(~dunn0172@2607:ea00:101:3c4c:5e26:aff:fe7a:3ea3) has left #tryton20:36
gltripptoday: (same DB-snapshot) 1.8 to 2.020:36
cedkgltripp: I don't understand how it is possible to have such error21:01
cedkgltripp: indeed, I understood it21:12
cedkgltripp: it seems you have the sequence ir_model_field_id_seq not sync21:13
cedkgltripp: which means that you have record in ir_model_field that has an id greater than the one in ir_model_field_id_seq21:13
cedkmeanmicio: image can only be display in a frame21:14
gltrippw'll examine that21:22
cedkgltripp: I created the issue of yesterday
meanmiciocedk : I'm using the format in the frame as in the relatorio documentation instructs image : object.field , but it won't render it.21:37
-!- bdunnette(~dunn0172@2607:ea00:101:3c4c:5e26:aff:fe7a:3ea3) has left #tryton22:55
cedkmeanmicio: it can not work, you must use: image: (object.field, 'image/png')23:53

Generated by 2.11.0 by Marius Gedminas - find it at!