irc.libera.chat #tryton log beginning Tue Mar 8 12:00:01 AM CET 2022 | ||
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton | 23:10 | |
-!- ChanServ changed mode/#tryton -> +o cedk | 23:10 | |
-!- mrichez(~Maxime@2a02:a03f:c2e8:f900:ed77:85ea:af2b:ba6e) has joined #tryton | 06:03 | |
-!- springwurm(~springwur@5.104.149.54) has joined #tryton | 06:06 | |
-!- timitos(~kpreisler@host-88-217-184-172.customer.m-online.net) has joined #tryton | 06:44 | |
-!- rpit(~rpit@p200300c88f358e00d393c30638403e8a.dip0.t-ipconnect.de) has joined #tryton | 06:57 | |
-!- acaubet(~Thunderbi@194.224.31.235) has joined #tryton | 08:10 | |
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton | 08:13 | |
-!- ChanServ changed mode/#tryton -> +o cedk | 08:13 | |
-!- prakhar(~prakhar@14.139.245.4) has joined #tryton | 09:34 | |
-!- nicoe(~nicoe@2a02:2788:54:1ff:18c2:1aff:fef9:2b7f) has joined #tryton | 09:50 | |
mrichez | hi, 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 |
---|---|---|
mrichez | we could select stock_moves in any state (draft, cancelled, ...) | 11:09 |
mrichez | we could select the same stock_move for 2 invoices and also product could be totally different than invoiced product | 11:10 |
mrichez | Do you consider it should be features for this module ? | 11:12 |
-!- tbruyere(~tbruyere@mail.saluc.com) has joined #tryton | 11:38 | |
pokoli | mrichez: 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 moves | 11:44 |
pokoli | mrichez: and for the product, tryton allows to sale a product (and invoice it) but send a similar one as replacement | 11:45 |
pokoli | So the domain should allow both cases | 11:45 |
pokoli | mrichez: about the intrastat, we are intersted also in it, it will be great if you can share your progress | 11:46 |
mrichez | pokoli: thanks for explanation, and about unique stock_move-invoice_line ? | 11:46 |
pokoli | mrichez: make sure to have a lok at: https://discuss.tryton.org/t/intrastat-reporting/3456 | 11:46 |
mrichez | pokoli: i saw you made a discuss about intrastat... | 11:46 |
pokoli | mrichez: what do you mean by unique? | 11:47 |
pokoli | avoiding duplicates on Many2Many relation? | 11:47 |
mrichez | pokoli: 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 |
pokoli | mrichez: 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 |
mrichez | pokoli: unit_price will be erased with the last unit_price | 11:51 |
mrichez | pokoli: 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 |
pokoli | mrichez: 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 possible | 11:53 |
pokoli | PRobably the unit price of the stock_move should be the mean between all invoices unit_price | 11:53 |
pokoli | mrichez: 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 future | 11:54 |
mrichez | pokoli: 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 migrate | 11:56 |
pokoli | mrichez: I guess the XML file is related to belgium, isn't it? | 11:58 |
mrichez | pokoli: 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 |
pokoli | mrichez: 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 |
pokoli | mrichez: for sales, normally the invoices are not created manually but from sale method. | 11:59 |
pokoli | ;-) | 12:00 |
mrichez | pokoli: yes xml file is related to belgium : https://www.nbb.be/fr/statistiques/commerce-exterieur/declarations | 12:00 |
pokoli | mrichez: I undesrstand your concerns, but I guess we can not do so much to prevent human errores | 12:00 |
mrichez | pokoli: :-) | 12:00 |
pokoli | ohh I see the belgium lik is already posted in the discussion. | 12:02 |
pokoli | mrichez: maybe you may add some domain on the field that applies when the invoice is draft and the origin is empty | 12:02 |
pokoli | mrichez: this will add some rules for manual invoices | 12:02 |
mrichez | pokoli: 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 |
pokoli | but should be done as customizatio | 12:02 |
pokoli | mrichez: yes, you may have diferent shipments linked to the same invoice. And even to diferent destinations | 12:03 |
mrichez | pokoli: nice idea that will be applied in our custo | 12:03 |
mrichez | pokoli: so for intrastat i need to browse all stock moves on the invoices lines in a specific period | 12:03 |
pokoli | mrichez: for me report should be based on stock move, so each in case of several shipments the amounts are splitted | 12:04 |
pokoli | mrichez: yes, but use a table query with a proper model to compute the values. That will be faster than browsing | 12:04 |
mrichez | pokoli: we should also convert price in euro with rate at invoice date | 12:05 |
mrichez | pokoli: and we allow users to define a tariff_code on invoice_line so we need also this information for report | 12:05 |
mrichez | pokoli: intrastat report is generated once a month, so speed is not needed :-) | 12:06 |
pokoli | mrichez: tariff_code is linked to product, you have it on customs module | 12:08 |
pokoli | mrichez: for me it's better to allow the user to see the values on the screen and then generate the report from there | 12:09 |
mrichez | pokoli: 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 invoice | 12:09 |
mrichez | pokoli: thanks for suggestions! be back after lunch time :-) | 12:15 |
pokoli | mrichez: enjoy your meal! | 12:15 |
pokoli | mrichez: So the best is to have a model for the instrastat that you can override the tariff_code that is used | 12:16 |
-!- Guest75(~textual@2a02:810d:1800:1ef4:3489:e447:258b:4ba1) has joined #tryton | 12:40 | |
mrichez | pokoli: we need the correct tariff_code on the invoice :-) | 12:51 |
pokoli | mrichez: 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 |
mrichez | pokoli: 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 #tryton | 13:09 | |
pokoli | mrichez: I'm curious why you have to select the right custom code in the invoice_line. Is not possible to automate it? | 13:10 |
pokoli | I mean, if you have several codes depending on the party country, it should be possible to pick the right one | 13:10 |
mrichez | pokoli: 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 |
pokoli | mrichez: that make sense! Thanks for the explanation | 13:16 |
mrichez | pokoli: :-) | 13:16 |
mrichez | pokoli: i'll show you my custom module when it will be done... | 13:17 |
pokoli | mrichez: great, may it can be a starting point for the future generic module | 13:20 |
pokoli | mrichez: btw, how do you manage European countries? | 13:21 |
mrichez | pokoli: i saw Ced's suggestion about using stdnum.eu.vat.MEMBER_STATES | 13:22 |
mrichez | pokoli: so i defined a function field boolean on country model to check if country_code is in stdnum.eu.vat.MEMBER_STATES | 13:24 |
pokoli | mrichez: ok, but you will need that for searching to just pick the shipments of the countries | 13:25 |
mrichez | pokoli: hum it's ok if i'm not using a query, no ? move.shipment.delivery_address.country.is_eu_member = True | 13:27 |
mrichez | pokoli: and also not taking 'Belgium' (in my case) | 13:28 |
pokoli | mrichez: I guess Belgium is the company country, so you should be able to skip that | 13:29 |
mrichez | pokoli: yes | 13:29 |
pokoli | mrichez: 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 memory | 13:29 |
mrichez | pokoli: so it's better to define a "real" field on the country model about eu_membership ? | 13:30 |
pokoli | mrichez: 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 |
pokoli | mrichez: then popoulate such group with the EU_MEMBERS list | 13:48 |
mrichez | pokoli: nice :-) | 13:48 |
-!- timitos(~kpreisler@host-88-217-184-172.customer.m-online.net) has joined #tryton | 13:49 | |
-!- nicoe(~nicoe@host-82-212-178-227.dynamic.voo.be) has joined #tryton | 13:57 | |
-!- nicoe(~nicoe@host-82-212-178-227.dynamic.voo.be) has joined #tryton | 14:47 | |
-!- nicoe(~nicoe@host-82-212-178-227.dynamic.voo.be) has joined #tryton | 14:50 | |
-!- timitos(~kpreisler@host-88-217-184-172.customer.m-online.net) has joined #tryton | 20:15 | |
-!- udono1(~udono@004-131-067-156.ip-addr.inexio.net) has joined #tryton | 20:32 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!