IRC logs of #tryton for Tuesday, 2022-03-08

irc.libera.chat #tryton log beginning Tue Mar 8 12:00:01 AM CET 2022
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton23:10
-!- ChanServ changed mode/#tryton -> +o cedk 23:10
-!- mrichez(~Maxime@2a02:a03f:c2e8:f900:ed77:85ea:af2b:ba6e) has joined #tryton06:03
-!- springwurm(~springwur@5.104.149.54) has joined #tryton06:06
-!- timitos(~kpreisler@host-88-217-184-172.customer.m-online.net) has joined #tryton06:44
-!- rpit(~rpit@p200300c88f358e00d393c30638403e8a.dip0.t-ipconnect.de) has joined #tryton06:57
-!- acaubet(~Thunderbi@194.224.31.235) has joined #tryton08:10
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton08:13
-!- ChanServ changed mode/#tryton -> +o cedk 08:13
-!- prakhar(~prakhar@14.139.245.4) has joined #tryton09:34
-!- nicoe(~nicoe@2a02:2788:54:1ff:18c2:1aff:fef9:2b7f) has joined #tryton09:50
mrichezhi, i'm trying to create a custom module for a simple intrastat report. I notice 2 strange things  in module account_invoice_stock:11:08
mrichezwe could select stock_moves in any state (draft, cancelled, ...)11:09
mrichezwe could select the same stock_move for 2 invoices and also product could be totally different than invoiced product11:10
mrichezDo you consider it should be features for this module ?11:12
-!- tbruyere(~tbruyere@mail.saluc.com) has joined #tryton11:38
pokolimrichez: Normally the stock_moves are directly set by the sale/purchase module. So if both shipments and invoices are created on order it requires to allow to have draft moves11:44
pokolimrichez: and for the product, tryton allows to sale a product (and invoice it) but send a similar one as replacement11:45
pokoliSo the domain should allow both cases11:45
pokolimrichez: about the intrastat, we are intersted also in it, it will be great if you can share your progress11:46
mrichezpokoli: thanks for explanation, and about unique stock_move-invoice_line ?11:46
pokolimrichez: make sure to have a lok at: https://discuss.tryton.org/t/intrastat-reporting/345611:46
mrichezpokoli: i saw you made a discuss about intrastat... 11:46
pokolimrichez: what do you mean by unique? 11:47
pokoliavoiding duplicates on Many2Many relation? 11:47
mrichezpokoli: you could reuse a stock_move already linked to an invoice_line (so unit_price on this stock_move could be updated twice, ...)11:48
pokolimrichez: it is posisble that the same stock move is send in two invoices. Indeed tryton should correctly compute the unit_price in this case 11:50
mrichezpokoli: unit_price will be erased with the last unit_price11:51
mrichezpokoli: about intrastat we are first doing a custom module, because we only use it for sales (for now).... we saw also this module https://gitlab.com/datalifeit/trytond-intrastat/ but everything seems not correct (using invoice address instead of shipment address)11:52
pokolimrichez: This is possible by creating a sale, fully shipping it. Invoicing a half of the quantity, and the invoice the rest in a separate invoice. This is not quite commont but possible11:53
pokoliPRobably the unit price of the stock_move should be the mean between all invoices unit_price11:53
pokolimrichez: I have no issues about using a custom module but if you follow the desing of the instrastat that will help you migrating in the future11:54
mrichezpokoli: indeed... but it's just to generate a report (xml file) so if there's a trytond_instrastat module later i don't think it'll be a problem to migrate11:56
pokolimrichez: I guess the XML file is related to belgium, isn't it? 11:58
mrichezpokoli: anyway about the "open" domain on stock_moves in invoice_line is quite "dangerous" when you create an invoice manually  (you can choose any stock_move, maybe it should be more restrictive in some cases ?)11:58
pokolimrichez: about the datalife module, I will recomend to use a table_query instead of a fixed module that is stored. And then generate the xml from there 11:59
pokolimrichez: for sales, normally the invoices are not created manually but from sale method. 11:59
pokoli;-)12:00
mrichezpokoli: yes xml file is related to belgium : https://www.nbb.be/fr/statistiques/commerce-exterieur/declarations12:00
pokolimrichez: I undesrstand your concerns, but I guess we can not do so much to prevent human errores12:00
mrichezpokoli: :-)12:00
pokoliohh I see the belgium lik is already posted in the discussion. 12:02
pokolimrichez: maybe you may add some domain on the field that applies when the invoice is draft and the origin is empty 12:02
pokolimrichez: this will add some rules for manual invoices 12:02
mrichezpokoli: my first reflexion was about "could we have different shipments linked to an invoice_line ?" (because i need to retrieve destination european countries )12:02
pokolibut should be done as customizatio12:02
pokolimrichez: yes, you may have diferent shipments linked to the same invoice. And even to diferent destinations12:03
mrichezpokoli: nice idea that will be applied in our custo12:03
mrichezpokoli: so for intrastat i need to browse all stock moves on the invoices lines in a specific period12:03
pokolimrichez: for me report should be based on stock move, so each in case of several shipments the amounts are splitted12:04
pokolimrichez: yes, but use a table query with a proper model to compute the values. That will be faster than browsing12:04
mrichezpokoli: we should also convert price in euro with rate at invoice date12:05
mrichezpokoli: and we allow users to define a tariff_code on invoice_line so we need also this information for report12:05
mrichezpokoli: intrastat report is generated once a month, so speed is not needed :-)12:06
pokolimrichez: tariff_code is linked to product, you have it on customs module12:08
pokolimrichez: for me it's better to allow the user to see the values on the screen and then generate the report from there12:09
mrichezpokoli: yes, but we made some custo because we have multiple tariff_codes on the same product and we allow users to change this tariff_code on the sale and on the invoice12:09
mrichezpokoli: thanks for suggestions! be back after lunch time :-)12:15
pokolimrichez: enjoy your meal! 12:15
pokolimrichez: So the best is to have a model for the instrastat that you can override the tariff_code that is used12:16
-!- Guest75(~textual@2a02:810d:1800:1ef4:3489:e447:258b:4ba1) has joined #tryton12:40
mrichezpokoli: we need the correct tariff_code on the invoice :-)12:51
pokolimrichez: we did some customization for our customer because they require to show the tariff code on sale, shipment and invoice reports. So it is not strange to have it related to the invoice 12:57
mrichezpokoli: it's not strange so we need this information from invoice_line to generate intrastat and having the correct tariff_code used.12:59
-!- springwurm(~springwur@5.104.149.54) has joined #tryton13:09
pokolimrichez: I'm curious why you have to select the right custom code in the invoice_line. Is not possible to automate it? 13:10
pokoliI mean, if you have several codes depending on the party country, it should be possible to pick the right one13:10
mrichezpokoli: it depends on what will be done with our product... same product (steel ball) could be use as ball bearing, ball in an aerosol, ... so it should be defined manually 13:15
pokolimrichez: that make sense! Thanks for the explanation13:16
mrichezpokoli: :-)13:16
mrichezpokoli: i'll show you my custom module when it will be done... 13:17
pokolimrichez: great, may it can be a starting point for the future generic module13:20
pokolimrichez: btw, how do you manage European countries? 13:21
mrichezpokoli: i saw Ced's suggestion about using stdnum.eu.vat.MEMBER_STATES13:22
mrichezpokoli: so i defined a function field boolean on country model to check if country_code is in stdnum.eu.vat.MEMBER_STATES13:24
pokolimrichez: ok, but you will need that for searching to just pick the shipments of the countries13:25
mrichezpokoli: hum it's ok if i'm not using a query, no ? move.shipment.delivery_address.country.is_eu_member = True13:27
mrichezpokoli: and also not taking 'Belgium' (in my case)13:28
pokolimrichez: I guess Belgium is the company country, so you should be able to skip that13:29
mrichezpokoli: yes13:29
pokolimrichez: yes, you can use such test but filtering inside loops is not a good Idea because you will load a lot of uneeded records in memory13:29
mrichezpokoli: so it's better to define a "real" field on the country model about eu_membership ?13:30
pokolimrichez: I think we agreed to have a module to define country groups. So a Many2Many field indicating the groups on which the country belongs to 13:48
pokolimrichez: then popoulate such group with the EU_MEMBERS list13:48
mrichezpokoli: nice :-)13:48
-!- timitos(~kpreisler@host-88-217-184-172.customer.m-online.net) has joined #tryton13:49
-!- nicoe(~nicoe@host-82-212-178-227.dynamic.voo.be) has joined #tryton13:57
-!- nicoe(~nicoe@host-82-212-178-227.dynamic.voo.be) has joined #tryton14:47
-!- nicoe(~nicoe@host-82-212-178-227.dynamic.voo.be) has joined #tryton14:50
-!- timitos(~kpreisler@host-88-217-184-172.customer.m-online.net) has joined #tryton20:15
-!- udono1(~udono@004-131-067-156.ip-addr.inexio.net) has joined #tryton20:32

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!