chat.freenode.net #tryton log beginning Mon Jan 30 00:00:01 CET 2012 | ||
2012-01-30 06:43 -!- plantian(~ian@c-69-181-220-245.hsd1.ca.comcast.net) has left #tryton | ||
2012-01-30 08:19 -!- udono(~udono@ip-109-91-208-150.unitymediagroup.de) has left #tryton | ||
2012-01-30 11:32 <navis> cedk: hi, would you consider including in tryton a module with the "tax included prices" modifications discussed here on 26/01 with grasbauer ? | ||
2012-01-30 11:32 <navis> http://www.tryton.org/~irclog/2012-01-26.log.html | ||
2012-01-30 11:32 <navis> begins at 16:39 | ||
2012-01-30 11:37 <cedk> navis: I'm not sure to understand | ||
2012-01-30 11:40 <navis> cedk: 4 days ago we discussed a solution for businesses who need to sell with "all taxes included" prices | ||
2012-01-30 11:41 <navis> cedk: 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 that | ||
2012-01-30 11:42 <navis> cedk: for example so that prices like 9,95 are respected on invoices | ||
2012-01-30 11:42 <navis> cedk: this is a requirement if one wants a pos solution later on | ||
2012-01-30 11:43 <navis> cedk: my question is would such a functionnality be considered for inclusion in tryton ? | ||
2012-01-30 12:00 <cedk> navis: I can not say because I don't understand what you want to do | ||
2012-01-30 12:01 <navis> cedk: ok, I need to sell with taxes included | ||
2012-01-30 12:01 <cedk> navis: I understand the requirements, but not the solution | ||
2012-01-30 12:02 <navis> cedk: 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 approximation | ||
2012-01-30 12:02 <navis> cedk: ah ok | ||
2012-01-30 12:02 <navis> cedk: the solution is to modify the sale object so that all calculations are done using the tax included price | ||
2012-01-30 12:03 <navis> cedk: and at the end the net (tax excluded) prices are retro computed from that | ||
2012-01-30 12:03 <cedk> navis: I'm against such solution | ||
2012-01-30 12:03 <navis> cedk: | ||
2012-01-30 12:03 <navis> cedk: why ? | ||
2012-01-30 12:04 <cedk> navis: because it is not the role of sale to do that, it is pos | ||
2012-01-30 12:04 <navis> cedk: no, this is independent from pos | ||
2012-01-30 12:04 <navis> cedk: pos needs this, but others too | ||
2012-01-30 12:04 <navis> cedk: consider a retailer web site, selling b2c and not b2b | ||
2012-01-30 12:05 <cedk> navis: it is a pos | ||
2012-01-30 12:05 <cedk> navis: sale module is b2b and pos should be b2c | ||
2012-01-30 12:05 <navis> cedk: a web site like amazon is a pos ? | ||
2012-01-30 12:05 <navis> cedk: a pos has much more requirements than that | ||
2012-01-30 12:06 <navis> cedk: and is absolutely not adapted to web sales | ||
2012-01-30 12:07 <navis> cedk: pos is a sales canal, like any other one | ||
2012-01-30 12:08 <navis> cedk: it is independent of your target client | ||
2012-01-30 12:08 <navis> cedk: tax included or excluded is dependent on your target client, not the sales canal | ||
2012-01-30 12:09 <navis> cedk: you can sell with prices tax included or excluded at a pos and on the web, it depends on your client, not where you sell | ||
2012-01-30 12:10 <cedk> navis: I don't agree | ||
2012-01-30 12:11 <navis> cedk: you mean a web site selling to end users must use a pos ??? | ||
2012-01-30 12:12 <navis> cedk: and you can't sell to businesses at a pos ? | ||
2012-01-30 12:12 <cedk> navis: I don't care about the name pos | ||
2012-01-30 12:13 <cedk> navis: sale is b2b and b2c is something else | ||
2012-01-30 12:15 <navis> cedk: ok, so if I understand correctly, you prefer a new object, same as sale but with tax included logic | ||
2012-01-30 12:16 <navis> cedk: like a sale_b2c | ||
2012-01-30 12:16 <cedk> navis: yes | ||
2012-01-30 12:18 <navis> cedk: could that be included in tryton when done ? | ||
2012-01-30 12:20 <cedk> navis: why not | ||
2012-01-30 12:22 <navis> cedk: just a question, why do you prefer a different object ? | ||
2012-01-30 12:26 <navis> cedk: I mean, sale_b2c can also be used to sell to businesses, it is just using a different base to calculate prices | ||
2012-01-30 12:26 <cedk> navis: because from experience mixing taxe included with tax excluded doesn't work | ||
2012-01-30 12:28 <navis> cedk: I didn't plan to mix, by activating the tax included module, you switch to tax included calculations | ||
2012-01-30 12:29 <navis> cedk: with t | ||
2012-01-30 12:29 <navis> cedk: with two objects, we will have to make them mutually exclusive | ||
2012-01-30 12:30 <navis> cedk: is this possible in tryton ? declaring a conflict between two modules ? | ||
2012-01-30 12:31 <bechamel> navis: why do you want to makes them exclusive | ||
2012-01-30 12:32 <bechamel> ? | ||
2012-01-30 12:32 <navis> bechamel: because they would make the same product have a different price for the same client | ||
2012-01-30 12:33 <navis> bechamel: 1€ tax included is not 0,82 tax excluded | ||
2012-01-30 12:33 <navis> bechamel: it would be very illogical to use both | ||
2012-01-30 12:33 <bechamel> navis: what if you sell tax included to some of your customers and tax excluded to others ? | ||
2012-01-30 12:35 <navis> bechamel: it is not selling tax included or excluded, it is just basing the calculations on the tax included or excluded amount | ||
2012-01-30 12:35 <navis> bechamel: you can calculate on the tax included prices, and still sell tax excluded | ||
2012-01-30 12:35 <navis> bechamel: to some clients | ||
2012-01-30 12:36 <navis> bechamel: when I sell to french business clients, they receive their invoices tax excluded | ||
2012-01-30 12:36 <navis> bechamel: but their calculation is the same as any of my belgian clients | ||
2012-01-30 12:37 <bechamel> navis: ok but the modified calculation is especially usefull for tax included prices, isn't it ? | ||
2012-01-30 12:38 <navis> bechamel: we sell to end users, so we have to use round tax included prices | ||
2012-01-30 12:38 <navis> bechamel: that doesn't mean that we do not sell to businesses | ||
2012-01-30 12:39 <navis> bechamel: take a simple example: let a product be 1€ vat included | ||
2012-01-30 12:39 <cedk> navis: you can not use tax included if you sell in b2b | ||
2012-01-30 12:39 <cedk> navis: because your net price will change depending on the quantity | ||
2012-01-30 12:40 <navis> cedk: we announce prices vat included, to businesses too | ||
2012-01-30 12:41 <cedk> navis: I will not buy to you if you don't tell me you vat excluded price | ||
2012-01-30 12:41 <navis> cedk: if as a business you buy on amazon, your net price is based on a tax included price | ||
2012-01-30 12:41 <navis> cedk: believe me, many business do :-) | ||
2012-01-30 12:43 <cedk> navis: I don't know if amazon has a pro section | ||
2012-01-30 12:43 <navis> cedk: it can just generate rounding errors for businesses who want vat excluded prices | ||
2012-01-30 12:43 <navis> cedk: they usually don't care | ||
2012-01-30 12:43 <bechamel> navis: anyway, I don't see how "one sale model vs two sale model " change anything for you | ||
2012-01-30 12:44 <navis> cedk: but try to sell a rounding error to a retail client, and see what happens | ||
2012-01-30 12:44 <navis> bechamel: I didn't think about it, but why not... | ||
2012-01-30 12:44 <bechamel> navis: the "same product with different prices for the same client" is nit solved | ||
2012-01-30 12:45 <bechamel> *not | ||
2012-01-30 12:46 <navis> bechamel: I don't understand, can you be more specific ? | ||
2012-01-30 12:46 <cedk> I don't see where I can put a VAT number on amazon, so not a good example | ||
2012-01-30 12:48 <bechamel> navis: it was about mutually-exclusive modules | ||
2012-01-30 12:49 <bechamel> navis: you want to make the modules mutually-exclusive but you also say that you have both business and non-business customers | ||
2012-01-30 12:51 <navis> bechamel: yes, I have business customers, their price is the same as non-business | ||
2012-01-30 12:51 <navis> bechamel: I of course have base, vat, and base+vat on my invoices | ||
2012-01-30 12:52 <navis> bechamel: but all calculations are based on vat included prices | ||
2012-01-30 12:52 <navis> bechamel: that only change the rounding, really | ||
2012-01-30 12:53 <navis> bechamel: which is important to retail (10x1€ = 10€, not 10,04), but less to businesses | ||
2012-01-30 12:53 <cedk> navis: it is not possible to have the same price for b2b and b2c | ||
2012-01-30 12:54 <cedk> navis: what you do is manage b2b as b2c | ||
2012-01-30 12:55 <navis> cedk: I do sell to plenty of businesses, and have never had any problem | ||
2012-01-30 12:56 <navis> cedk: of course they know us as a retailer | ||
2012-01-30 12:56 <navis> cedk: but after reflection, I have nothing against both modules coexisting | ||
2012-01-30 12:57 <navis> cedk: and now I see the problem in mixing everything in sale | ||
2012-01-30 12:57 <navis> cedk: that would not be a problem in our case, but could be for others | ||
2012-01-30 13:01 <meanmicio> Hello all ! | ||
2012-01-30 13:02 <meanmicio> I'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 efforts | ||
2012-01-30 13:37 <cedk> meanmicio: you should take a look at https://github.com/hudora/huBarcode | ||
2012-01-30 14:12 <meanmicio> cedk : thanks. I'm working with qrcode (http://pypi.python.org/pypi/qrcode/2.0) | ||
2012-01-30 14:13 <meanmicio> cedk : It looks quite nice, but is preliminary. This one generates easily a PNG from the argument. Just testing it. | ||
2012-01-30 14:15 <meanmicio> cedk : now is a matter of embedding the resulting graph to Libreoffice | ||
2012-01-30 14:15 <cedk> meanmicio: which one? | ||
2012-01-30 14:16 <meanmicio> cedk : the QR png graph generated with this qrcode lib | ||
2012-01-30 14:16 <meanmicio> cedk : So we can use them in the reports. | ||
2012-01-30 14:18 <cedk> meanmicio: hubarcode also generate png | ||
2012-01-30 14:29 <meanmicio> cedk: Yes. I will test both, since they both are in pypi. qrcode seem quite light. | ||
2012-01-30 14:31 <meanmicio> cedk : Now is a matter of passing the data as an argument from Tryton, then embedding into Libreoffice. | ||
2012-01-30 14:38 <cedk> meanmicio: depends if you really will only need qr | ||
2012-01-30 16:22 <navis> cedk: I'm looking at the sale_b2c (name is not set in stone :-) implementation discussed earlier today | ||
2012-01-30 16:22 <navis> cedk: wouldn't using a new object mean that we have to reimplement all extensions made to sale ? | ||
2012-01-30 16:23 <navis> cedk: like opportunities, price_lists, shipment,... and later pos, reservations,... | ||
2012-01-30 16:24 <navis> cedk: all these apply to both objects | ||
2012-01-30 16:26 <navis> cedk: reimplement is a big word, duplicating is more appropriate | ||
2012-01-30 16:28 <navis> cedk: but still, «duplicating» sounds very bad in an it project... | ||
2012-01-30 16:29 <cedk> navis: I don't see how opportunity could be used for a b2c | ||
2012-01-30 16:29 <cedk> navis: I don't how shipment is a prequel to sale | ||
2012-01-30 16:30 <navis> cedk: sale_shipment_cost | ||
2012-01-30 16:30 <cedk> navis: price_list is generic and should work on any kind of Model | ||
2012-01-30 16:31 <navis> cedk: it is sale_price_list, it specifically modifies sale and depends on it | ||
2012-01-30 16:32 <navis> cedk: why would opportunity be irrelevant for non business clients ? | ||
2012-01-30 16:32 <navis> cedk: I can get non business leads | ||
2012-01-30 16:37 <cedk> navis: I will say for the last time, sale tax included is only for b2c | ||
2012-01-30 16:37 -!- bdunnette(~dunn0172@2607:ea00:101:3c4c:5e26:aff:fe7a:3ea3) has left #tryton | ||
2012-01-30 16:37 <navis> cedk: yes ok, I agree with that | ||
2012-01-30 16:38 <navis> cedk: but all extensions made to sales are also relevant in b2c | ||
2012-01-30 16:39 <navis> cedk: now maybe there is what is needed in tryton to make those extensions generic, I don't know it enough | ||
2012-01-30 16:40 <navis> cedk: but there is no reason why opportunities, price_lists,... are not relevant for the b2c case | ||
2012-01-30 16:41 <cedk> navis: sorry, but using price tax included is not relevant in an ERP | ||
2012-01-30 16:41 <cedk> navis: so you can have a document that can work with it but it will never completly integrated in the system | ||
2012-01-30 16:42 <cedk> navis: working with tax included has sense for b2c which is a pos | ||
2012-01-30 16:43 <navis> cedk: I can see that you have much resistance to it, I don't understand why, but I will stop bothering you with it | ||
2012-01-30 16:43 <navis> cedk: sorry to have lost your and my time | ||
2012-01-30 16:43 <cedk> navis: I have because OpenERP has such feature that is broken since day 1 and will never work | ||
2012-01-30 16:44 <navis> cedk: I know that this is broken in openerp, and i don't care, openerp is broken in so many ways that it is irrelevant now | ||
2012-01-30 16:45 <cedk> navis: I worked on it during months without succeed | ||
2012-01-30 16:45 <navis> cedk: but that doesn't mean that the functionnality has to be a broken hack | ||
2012-01-30 16:45 <cedk> navis: so I'm sure we can not mix both in one document | ||
2012-01-30 16:45 <navis> cedk: I'm ok with that | ||
2012-01-30 16:45 <navis> cedk: and I'm ok with a separate object | ||
2012-01-30 16:46 <navis> cedk: I'm just thinking about it and finding gotchas before I commit to it | ||
2012-01-30 16:46 <navis> cedk: and one gotcha is that it duplicates functionnality | ||
2012-01-30 16:47 <cedk> navis: I really prefer duplicate code than complex and buggy | ||
2012-01-30 16:47 <navis> cedk: now if that functionnality (all extensions to sales) can be made to work on sale and sale_b2c, then no problem | ||
2012-01-30 16:52 <cedk> navis: have you an example of software with such fonctionnalities? | ||
2012-01-30 16:52 <navis> cedk: yes, I use it internally | ||
2012-01-30 16:53 <navis> cedk: but every software which can sell to non businesses must have it in some form | ||
2012-01-30 16:53 <navis> cedk: in the free o | ||
2012-01-30 16:54 <navis> cedk: in the free world, I guess every web shop engine must have it | ||
2012-01-30 16:54 <cedk> navis: come on every webshop can not even manage taxes correctly | ||
2012-01-30 16:55 <cedk> navis: you mean your current software can work both way | ||
2012-01-30 16:56 <navis> cedk: :-) ok ok for web shops :-) | ||
2012-01-30 16:56 <navis> cedk: yes, but one has to decide one way or the other at initial configuration | ||
2012-01-30 16:56 <navis> cedk: we manage all sales in tax-included calculation mode | ||
2012-01-30 16:57 <cedk> navis: the software can work in one or other way out-of-the-box? | ||
2012-01-30 16:58 <cedk> navis: more over, the more we talk the more I think you need a pos | ||
2012-01-30 16:58 <navis> cedk: out of the box is a big word, it came fully installed with a contract | ||
2012-01-30 16:59 <navis> cedk: but it can work both ways | ||
2012-01-30 16:59 <navis> cedk: frankly I do need a pos, but it is not my priority right now | ||
2012-01-30 17:00 -!- pjstevns(~paul@a83-163-46-103.adsl.xs4all.nl) has left #tryton | ||
2012-01-30 17:00 <navis> cedk: and that functionnality is not stritcly limited to pos | ||
2012-01-30 17:00 <navis> cedk: if I make it, I'd like to make it right | ||
2012-01-30 17:08 <bechamel> navis: does your current software allows to "tweak" tax rounding (iirc, it's the main issue with tax included prices). | ||
2012-01-30 17:10 <navis> cedk: no, it is just that I define sale prices tax included for belgium, and other values are calculated from there | ||
2012-01-30 17:10 <navis> oups, that was meant for bechamel... | ||
2012-01-30 17:11 <navis> cedk: I just checked, ldlc.be can use both ways of calculating | ||
2012-01-30 17:11 <bechamel> navis: so when you sale to other countries, your prices are not rounded anymore ? | ||
2012-01-30 17:12 <navis> cedk: go to ldlc.be, put 10x C6657GE in a basket, and you can see it ttc or hvat | ||
2012-01-30 17:12 <navis> cedk: which is not the same amount | ||
2012-01-30 17:12 <navis> bechamel: if business users, thats right | ||
2012-01-30 17:13 <navis> bechamel: to take the same example, ldlc has the same way of doing things | ||
2012-01-30 17:13 <bechamel> navis: and for non-business customer? if I understand correctly you remove the 21% vat and the re-add the foreign vat | ||
2012-01-30 17:14 <navis> bechamel: prices on ldlc.fr and ldlc.be are the same, except for the difference in vat | ||
2012-01-30 17:14 <navis> bechamel: no, non-business customers in the eu have 21% vat | ||
2012-01-30 17:15 <navis> bechamel: and out of eu have no vat | ||
2012-01-30 17:16 <bechamel> navis: I see | ||
2012-01-30 17:17 <navis> bechamel: this does not depend on the way prices are calculated, non business customers in eu pay the vat of the seller | ||
2012-01-30 17:21 <bechamel> navis: 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 around | ||
2012-01-30 17:22 <navis> bechamel: yes, it seems so | ||
2012-01-30 17:23 <navis> bechamel: 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 ? | ||
2012-01-30 17:24 <cedk> navis: quantity is limited to 99 :-) | ||
2012-01-30 17:24 <navis> cedk: on ldlc ? I had the same problem, that's why I said 10 :-) | ||
2012-01-30 17:25 <cedk> navis: of course if you limit the quantity, you can not reach the issue | ||
2012-01-30 17:25 <navis> cedk: yes, 10x C6657GE gets the issue | ||
2012-01-30 17:27 <navis> cedk: vat included = 161,40; vat excluded = 133,40 | ||
2012-01-30 17:27 <cedk> navis: any way, I'm pretty sure they have define a price TTC and a price HTC | ||
2012-01-30 17:27 <navis> cedk: 133,40 x 1,21 = 161,41 | ||
2012-01-30 17:27 <bechamel> navis: 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 model | ||
2012-01-30 17:28 <cedk> navis: of course, but what is their invoice? | ||
2012-01-30 17:28 <bechamel> and this means that all related modules must be adapted | ||
2012-01-30 17:28 <navis> cedk: no idea, I guess they respect what is in the basket, that would be too gross | ||
2012-01-30 17:29 <cedk> navis: so they have 2 objects | ||
2012-01-30 17:29 <bechamel> cedk: "I'm pretty sure they have define a price TTC and a price HTC" -> is it an issue ? | ||
2012-01-30 17:30 <cedk> bechamel: no but it will requires 2 objects to store both kind of command | ||
2012-01-30 17:30 <navis> bechamel: the only difference is the way a sale_line and sale_total is calculated | ||
2012-01-30 17:30 -!- bdunnette(~dunn0172@2607:ea00:101:3c4c:5e26:aff:fe7a:3ea3) has left #tryton | ||
2012-01-30 17:30 <cedk> navis: not only calculated but also stored | ||
2012-01-30 17:32 <navis> cedk: a sale line doesn't store all amounts ? | ||
2012-01-30 17:33 <navis> cedk: yes it does, unit_price and amount are sufficient | ||
2012-01-30 17:35 <navis> cedk: for sale you store net prices, for b2c you store ttc prices | ||
2012-01-30 17:37 <navis> cedk: for sale, untaxed is the sum of amounts and total is computed | ||
2012-01-30 17:37 <navis> cedk: for b2c total is the sum, and untaxed is computed | ||
2012-01-30 17:44 <cedk> for info: http://www.b2ck.com/~ced/hg/hgwebdir.cgi/sale_import | ||
2012-01-30 17:47 <navis> cedk: what is it ? | ||
2012-01-30 17:47 <cedk> navis: an old module to import sale line from a pos | ||
2012-01-30 17:50 <navis> cedk: 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 done | ||
2012-01-30 19:02 -!- bdunnette(~dunn0172@2607:ea00:101:3c4c:5e26:aff:fe7a:3ea3) has left #tryton | ||
2012-01-30 19:24 <meanmicio> It looks like there's an issue with relatorio/genshi when dealing with binary fields | ||
2012-01-30 19:36 <udono> meanmicio: hi, paepke has worked on barcode with Tryton. Maybe he has some ideas. You can find him on #tryton.de | ||
2012-01-30 19:38 <meanmicio> udono : thanks | ||
2012-01-30 19:39 <meanmicio> uduno : but unrelated to that, the binary fields are having issues when rendering | ||
2012-01-30 19:40 <udono> meanmicio: are you on tip? | ||
2012-01-30 19:41 <udono> meanmicio: or better ask: Which version of Tryton you use? | ||
2012-01-30 19:41 <meanmicio> uduno : nope. Working on stable 2.2 | ||
2012-01-30 19:42 <meanmicio> uduno : will check with the latest | ||
2012-01-30 19:43 <udono> meanmicio: It could be the change in 2.2 with the buffer, let me take a look... | ||
2012-01-30 19:47 <cedk> meanmicio: what is the issue? | ||
2012-01-30 19:47 <udono> meanmicio: the type for binary data changed in Tryton from base64 to buffer: http://hg.tryton.org/2.2/trytond/rev/8d2762bb1aa4 | ||
2012-01-30 19:47 <gltripp> re | ||
2012-01-30 19:48 <gltripp> cedk: i didn't submit an issue | ||
2012-01-30 19:49 <cedk> gltripp: why? | ||
2012-01-30 19:50 <meanmicio> cedk : when trying to render/display a binary field (ie, patient picture) I get a traceback error (unicodedecode) at genshi/template/directives.py | ||
2012-01-30 19:52 <cedk> meanmicio: what do you put as directive? | ||
2012-01-30 19:55 <meanmicio> cedk : just the field name (ie, newborn.photo) | ||
2012-01-30 19:55 <cedk> meanmicio: it can not work | ||
2012-01-30 19:56 <meanmicio> cedk : of course, when is null it works (None) :-) | ||
2012-01-30 19:57 <cedk> meanmicio: image must be at least (bitstream, mimetype) | ||
2012-01-30 19:57 <cedk> meanmicio: where bitstream could be another relatorio report or file object | ||
2012-01-30 19:58 <cedk> meanmicio: it could also be (bitsream, mimetype, width, height) | ||
2012-01-30 20:00 <navis> /j #tryton-fr | ||
2012-01-30 20:00 <navis> oups... | ||
2012-01-30 20:00 <cedk> gltripp: if you don't submit issue, it will never be fixed | ||
2012-01-30 20:01 <meanmicio> cedk : 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) | ||
2012-01-30 20:01 <gltripp> i know - i think i will do it in the next time | ||
2012-01-30 20:22 <gltripp> ouh | ||
2012-01-30 20:22 <gltripp> thats strange | ||
2012-01-30 20:23 <gltripp> i tried to upgrade from 1.8 to 2.0 | ||
2012-01-30 20:23 <gltripp> and got... http://pastebin.com/cvEXYADU | ||
2012-01-30 20:30 <meanmicio> cedk : 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). | ||
2012-01-30 20:33 <cedk> meanmicio: I don't understand | ||
2012-01-30 20:33 <cedk> gltripp: I don't understand how you can have now this issue when yesterday you go until the migration of stock module | ||
2012-01-30 20:36 <gltripp> yesterday: migration from 1.8 db to 2.2 | ||
2012-01-30 20:36 -!- bdunnette(~dunn0172@2607:ea00:101:3c4c:5e26:aff:fe7a:3ea3) has left #tryton | ||
2012-01-30 20:36 <gltripp> today: (same DB-snapshot) 1.8 to 2.0 | ||
2012-01-30 21:01 <cedk> gltripp: I don't understand how it is possible to have such error | ||
2012-01-30 21:12 <cedk> gltripp: indeed, I understood it | ||
2012-01-30 21:13 <cedk> gltripp: it seems you have the sequence ir_model_field_id_seq not sync | ||
2012-01-30 21:13 <cedk> gltripp: which means that you have record in ir_model_field that has an id greater than the one in ir_model_field_id_seq | ||
2012-01-30 21:14 <cedk> meanmicio: image can only be display in a frame | ||
2012-01-30 21:22 <gltripp> w'll examine that | ||
2012-01-30 21:24 <cedk> gltripp: I created the issue of yesterday https://bugs.tryton.org/issue2429 | ||
2012-01-30 21:37 <meanmicio> cedk : I'm using the format in the frame as in the relatorio documentation instructs image : object.field , but it won't render it. | ||
2012-01-30 22:55 -!- bdunnette(~dunn0172@2607:ea00:101:3c4c:5e26:aff:fe7a:3ea3) has left #tryton | ||
2012-01-30 23:53 <cedk> meanmicio: it can not work, you must use: image: (object.field, 'image/png') |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!