| chat.freenode.net #tryton log beginning Mon Mar 1 12:00:02 AM CET 2021 | ||
| -!- mathesis_(~ja1000@187.148.60.233) has joined #tryton | 23:51 | |
| -!- srgdts_(~srgdts@unaffiliated/srgdts) has joined #tryton | 02:20 | |
| -!- springwurm(~Springwur@5.104.149.54) has joined #tryton | 05:52 | |
| -!- mrichez(~Maxime@2a02:a03f:c2e8:f900:ed77:85ea:af2b:ba6e) has joined #tryton | 06:09 | |
| -!- Timitos(~kpreisler@2001:a61:42d:c01:762b:62ff:fe84:ed7e) has joined #tryton | 06:38 | |
| -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton | 07:43 | |
| -!- rpit(~rpit@p200300c88f0235001c42215a17f33f55.dip0.t-ipconnect.de) has joined #tryton | 08:29 | |
| -!- wifasoi(8c69cf0d@mittelab/sudo/wifasoi) has joined #tryton | 09:04 | |
| wifasoi | Hi, have a (a possible problem)... I try to read the account_receivable from a party, but without success (it return the account don't specified error). The problem is that i specify an acount payable receivable (but not a default one) for each party | 09:06 |
|---|---|---|
| wifasoi | I tried to get the payable/receyvable account directtly but not luck | 09:10 |
| wifasoi | (but form the interface i can see i defined them) | 09:11 |
| wifasoi | (and from the database table) | 09:11 |
| wifasoi | what, in your experience, can cause this? | 09:11 |
| wifasoi | (i'm using tryton 5.8) | 09:13 |
| cedk | wifasoi: wrong context, probably it is missing the company | 09:17 |
| wifasoi | ok, makes sense.. becouse I'm using the tryton console, so I should perform the operation in a "with Context()" block | 09:18 |
| -!- thaneor(~acer8@r167-61-0-243.dialup.adsl.anteldata.net.uy) has joined #tryton | 09:18 | |
| wifasoi | thank you very much, I totally forgot it :D | 09:18 |
| -!- thaneor1(~ldlc6@r167-61-0-243.dialup.adsl.anteldata.net.uy) has joined #tryton | 09:19 | |
| -!- springwurm(~Springwur@5.104.149.54) has joined #tryton | 09:27 | |
| -!- ludo2(~Thunderbi@2001:912:1480:380::1) has joined #tryton | 09:30 | |
| -!- nicoe(~nicoe@2a02:578:852a:c00:7e2a:31ff:fe5e:b25d) has joined #tryton | 09:43 | |
| LordVan_ | hi | 09:55 |
| LordVan_ | quick question as i could not find anything online .. i want to display a float number, but by default it uses en_US format ('.' instead of the ',' which i want for german) | 09:55 |
| LordVan_ | *display on a report | 09:55 |
| pokoli | LordVan_: i was reading your comments and I think we are working also on a similar project than yours | 10:06 |
| pokoli | LordVan_: is your bussines cutting steel to produce pieces? | 10:06 |
| pokoli | LordVan_: the numeric format depens on the user language. You should switch your user interface to german to show the numbers in proper format | 10:07 |
| LordVan_ | pokoli, yes | 10:07 |
| LordVan_ | user interface is german | 10:07 |
| LordVan_ | but the generation of the odt report is ran on the server so | 10:08 |
| LordVan_ | *run | 10:08 |
| pokoli | LordVan_: sale report is rendered on the party language | 10:08 |
| pokoli | LordVan_: so probably setting the party language to german should fix your issue | 10:09 |
| LordVan_ | that could be it | 10:09 |
| pokoli | LordVan_: we use sale_supply_production module to automatically generate production orders when the sale is confirmed | 10:09 |
| LordVan_ | i should set the default party language to german . .for new ones it might not be set | 10:09 |
| pokoli | I'm still missing the part to descrive the needed operations on the parts at sale_line level | 10:10 |
| LordVan_ | pokoli, i mostly added some test fields | 10:11 |
| pokoli | We find that entering the full product details (specially prodution route) is hard for the users. So we are looking for some idea to simplify it | 10:11 |
| LordVan_ | use a wizard maybe | 10:11 |
| LordVan_ | i just have extra fields and will add a "material" module | 10:12 |
| pokoli | LordVan_: material is just a table with a name, isn't it? | 10:13 |
| pokoli | LordVan_: my main worries is about the operations that should be applied to the product on the production | 10:13 |
| pokoli | Because we want to use the production module to compute costs and allowing the office users to know in which status of prodution is any customer order | 10:13 |
| LordVan_ | pokoli, well i will model it after country module (loosely) as i might need it later too and i don'T want it just text based | 10:14 |
| LordVan_ | yes i do not use production | 10:14 |
| LordVan_ | i just need to generate the report with correct material, thickness, painted or not,.. | 10:14 |
| LordVan_ | pokoli, i was gonna upload my code to my github repo again anyway | 10:15 |
| LordVan_ | (nothing special about it) | 10:15 |
| LordVan_ | so i can do that later and show you, but i doubt there's much you'd not already know | 10:15 |
| LordVan_ | the whole production process here is documented first on paper (hence why i need to generate the reports when an order is placed) | 10:16 |
| pokoli | LordVan_: we started on a first step where we do not use production, and just sale orders and related invoices | 10:16 |
| pokoli | and now are on the second phase where we want to introduce productions | 10:17 |
| LordVan_ | pokoli, same here - though i am not doing invoicing with tryton just yet | 10:17 |
| LordVan_ | i have some things I need to still work out first before generating invoices | 10:17 |
| pokoli | LordVan_: for generaing a report of material is just about adding some properties to products (or sale lines) and then print this information from the sale order in a custom report | 10:17 |
| LordVan_ | since I am doing most of this myself it is not an issue to split it into small stages | 10:17 |
| LordVan_ | pokoli, yes but i also need to write my own report class soon for some .. a bit special cases (like where one sale_line needs to generate multiple pages, or multiple sale_lines need to be combined on one page) | 10:18 |
| LordVan_ | for that report i can't (always) just take every sale_line and use that but am going to have to post-process first what can/should be merged or split | 10:19 |
| LordVan_ | -- to explain .. a sale_line can contain an assembly .. but that then consists of parts of different materials, metal sheet thickness,.. and each of those needs a seperate printed out page for production) | 10:19 |
| LordVan_ | and in other cases we want more sale_line rows to be on one page because the customer does not want individual prices and they are the same material + thickness | 10:20 |
| pokoli | LordVan_: I think I now your problems | 10:21 |
| pokoli | LordVan_: using production module will probably make it easier | 10:21 |
| LordVan_ | ;) | 10:21 |
| LordVan_ | we have too many prototypes or just simply one-off things to use production .. it would over-complicate it | 10:21 |
| pokoli | because on production is where you declare what needs to be done on each material | 10:22 |
| LordVan_ | i might start using production later on for some repeatedly ordered parts, but for now .. | 10:22 |
| pokoli | LordVan_: the production should be automaticall generated with sale_supply_production module | 10:22 |
| LordVan_ | pokoli, that would be a huge task | 10:26 |
| LordVan_ | with likely barely any gain | 10:26 |
| LordVan_ | for 90% of the orders | 10:27 |
| pokoli | LordVan_: why you sai there will be no gain? | 10:29 |
| pokoli | LordVan_: production is what contains all the tasks to be done, material to be used and the planning | 10:29 |
| pokoli | LordVan_: indeed you will have an extra operation for cutting the main material into the pieces that can not be tracked at sale level | 10:29 |
| pokoli | Because the cutting groups pieces of several orders | 10:29 |
| LordVan_ | pokoli, in theory yes | 10:30 |
| LordVan_ | ideally | 10:30 |
| LordVan_ | but that would require ahead of time planning of all those things | 10:30 |
| LordVan_ | we do most of our orders rather short notice | 10:30 |
| LordVan_ | sometimes order like one day 13:00 and want to pick up next morning 7AM | 10:30 |
| LordVan_ | there is no point trying to plan/schedule cutting | 10:30 |
| LordVan_ | we'd throw/change the plans more often than not | 10:31 |
| LordVan_ | we rarely have stuff that actually cuts for a long time on one material | 10:31 |
| pokoli | LordVan_: for that reason there is the shipping_date on the sale order | 10:33 |
| pokoli | LordVan_: if you do not have any shipping date the order is scheduled on a fixed period (i.e: 3 days) | 10:33 |
| pokoli | LordVan_: but once you have an order that should be picked up next morning you just set the shipping_date to tomorrow | 10:34 |
| LordVan_ | pokoli, i completely agree with you that ideally that all would work out great .. but for a small company where a lot of the workers are pretty much computer illiterate | 10:35 |
| pokoli | Tryton will create all the related documents with this dates in mind, so the production users know on which orders should work first (ordered by date) without needing to care on anything else | 10:35 |
| LordVan_ | it might be something in the (further) future | 10:35 |
| LordVan_ | but that'D require major organisational changes company wide | 10:35 |
| LordVan_ | that simply are not going to happen now | 10:36 |
| LordVan_ | if i may ask .. how large is the company you are doing this project for? | 10:36 |
| pokoli | LordVan_: not so much, 15 employees working | 10:40 |
| pokoli | LordVan_: indeed they are working with papers like you describe (but they generate them using an excel file) | 10:41 |
| LordVan_ | our project sheets used to be manuall written (Every single sheet every time except for some copy paste) until a few years ago when I implemented it in dolibarr - which did not work out | 10:43 |
| LordVan_ | now we generate a large part of the (not too complex) ones fully with tryton already | 10:43 |
| LordVan_ | we got like 15 employees total .. (including part time office,..) | 10:44 |
| LordVan_ | pokoli, do they have a lot of "plannable" orders? we just got lots and lots of small, low quantity orders | 10:45 |
| LordVan_ | so the complexity of production module is .. well | 10:45 |
| LordVan_ | would probably require me myself to deal with most of it tbh as our office staff wouldn'T be able to handle that (qualification/knowledge wise) | 10:46 |
| pokoli | ACTION is on phone | 10:50 |
| pokoli | LordVan_: 150 orders per months moreless | 11:04 |
| -!- mariomop(~quassel@181.29.189.235) has joined #tryton | 11:05 | |
| pokoli | LordVan_: there are ones which are just 1 o 2 quantities of an item | 11:05 |
| Hirschbeutel | we all have very similar problems 😉 | 11:09 |
| Hirschbeutel | the coating as well very often a complete individual request. | 11:10 |
| Hirschbeutel | I have processdefinition on sale line: like (sanding, priming, topcoat, polishing) - this ar lines with the name and a text description if sales person ask for them | 11:13 |
| pokoli | Hirschbeutel: we have another project related to custom T-Shirts and they have similar needs | 11:14 |
| pokoli | and I also had been asked for some option to define the full production on sale quotation. SO you need to plan everything in advance and compute the costs (and prices) | 11:15 |
| pokoli | Then if the customer agrees, you should follow the plan if not it can be thrown away | 11:15 |
| Hirschbeutel | yes | 11:15 |
| pokoli | Hirschbeutel: i think there is place for some standard modules there but I still do not have an idea on how to design it | 11:20 |
| pokoli | for now we are using custom code to make the projects work | 11:21 |
| Hirschbeutel | me to - we shoul work on some generic | 11:22 |
| pokoli | Hirschbeutel: agree but generic requires time to think it carefully :) | 11:43 |
| Hirschbeutel | pokoli: I can abstract what I do for in our case | 11:44 |
| pokoli | Hirschbeutel: it will be a starting point | 11:45 |
| pokoli | Hirschbeutel: but probably I prefer to comment it here because for me there are like two funcionalities | 11:45 |
| pokoli | 1. Specify some production details at sale level | 11:45 |
| pokoli | 2. Create a planning to know the costs of a production and use it at quotation level | 11:46 |
| pokoli | the second can be used without sale module to create plan diferent versions of a production BOM/Routing configuration | 11:46 |
| pokoli | IIRC when I was at nantic we implemented a module for the second | 11:46 |
| Hirschbeutel | because in our case ist a fundamental part of all: most of clients do not know the process - sale man ask them to know as many as he can and than searches for the best production process | 11:46 |
| Hirschbeutel | not searching - there could be a generic process that fits or we need a customized based on a generic or it is completly custom | 11:48 |
| Hirschbeutel | in our case we can calculate based on the steps needed in the process - so price differs from some variables but we can calculate based on process_step | 11:49 |
| Hirschbeutel | I have a process_template - you can select it on sale, a copy of the process_lines is made - leave it as it or change them to your needs | 11:51 |
| Hirschbeutel | so we have the design :) | 11:51 |
| pokoli | Hirschbeutel: our prices also depen on the processes | 11:53 |
| pokoli | Hirschbeutel: indeed we added a product to the production_operation and we allow to add operations on sale line which are added latter to the production process | 11:53 |
| pokoli | Hirschbeutel: unit_price is computed with the price of the product + the prices of the operations with product (extra services) | 11:54 |
| Hirschbeutel | similar | 11:56 |
| Hirschbeutel | I don't have a product - I have process_steps with some variables (like squaremeters, material etc) | 11:57 |
| Hirschbeutel | more like a fluid bom | 12:02 |
| LordVan_ | for us most of the time the cost is only calculated after manufacturing | 12:08 |
| LordVan_ | because there is no time to calculate beforehand or it is just not well enough defined | 12:08 |
| Hirschbeutel | LordVan_: It is not unusual to charge according to the work done | 12:10 |
| Hirschbeutel | LordVan_: project module can do that :D | 12:10 |
| Hirschbeutel | thats wy for me project is my prefered way and I will fight my whole live to convince cedrik | 12:11 |
| Hirschbeutel | for some companies a sale creates a kind of project | 12:11 |
| LordVan_ | Hirschbeutel, haha | 12:13 |
| Hirschbeutel | I think the blueprint to invoice services is similar - but it depends of definintion of service | 12:13 |
| LordVan_ | I do agree .. we consider nearly each sale a project | 12:13 |
| Hirschbeutel | yes | 12:13 |
| LordVan_ | tbh i haven'T actually looked at the project module too much | 12:14 |
| LordVan_ | but | 12:14 |
| LordVan_ | what i need right now works well with just sale and sale_line adjustments | 12:14 |
| LordVan_ | the special cases are a different story | 12:14 |
| Hirschbeutel | so you can be one of my knights in the everlasting fight to make the project module omnipotent | 12:15 |
| Hirschbeutel | :D | 12:15 |
| Hirschbeutel | it should manage my live as welll | 12:15 |
| LordVan_ | i would install the project module to have a look at it now, but i only have the production instance running and i don'T know if i want it on there haha | 12:16 |
| Timitos | Hirschbeutel: its not about fighting its about convincing | 12:20 |
| Hirschbeutel | no - cedrik is right, I was joking | 12:20 |
| LordVan_ | haha | 12:21 |
| Hirschbeutel | its one of the features of tryton: you have possibilities but you have to choose | 12:21 |
| Hirschbeutel | but convincing int this case means fighting, am I wrong? :) | 12:23 |
| Hirschbeutel | I think what we know is: there is a need for some modules handling small to no series production | 12:24 |
| Hirschbeutel | handcrafts | 12:25 |
| Timitos | yes. many of us do need modules for this. there are already some threads on discuss about that and maybe we only need to intensify the discussion about these needs to find the common patterns | 12:25 |
| Hirschbeutel | yes! | 12:26 |
| Hirschbeutel | the common pattern is that there is no pattern, because the USP in this case is to differentiate :) | 12:27 |
| Hirschbeutel | I would like to work on this .... | 12:27 |
| Timitos | if there is no pattern then we all end with custom modules | 12:28 |
| Hirschbeutel | possibly we can find a very reduced core concept | 12:29 |
| Hirschbeutel | first is to find the document where the coding of the request starts | 12:29 |
| Hirschbeutel | for me this is sale:opportuity - but you know that I have implementet it on sale | 12:30 |
| Hirschbeutel | LordVan_ statet that sale_opportunity in small companies is one step to much - and I think this was the reason why I did it on sale | 12:31 |
| Hirschbeutel | but in review sale_oportunity seems better | 12:34 |
| LordVan_ | Hirschbeutel, i have most things on sale that i need | 12:35 |
| LordVan_ | starting with sale_opportunity would add complexity and me having to add a lot of stuff in 2 places | 12:36 |
| Hirschbeutel | yes - I know - for this reason I have my stuff on sale as well | 12:37 |
| Hirschbeutel | this should be discussed | 12:38 |
| Hirschbeutel | who starts the thread? | 12:38 |
| LordVan_ | feel free i am quite busy right now ;) | 12:42 |
| Hirschbeutel | pass the baton to > ... | 12:44 |
| Hirschbeutel | Ok - will think about it - without thinking I will post only chaotic stuff :) | 12:45 |
| LordVan_ | same here | 12:52 |
| Hirschbeutel | cedk: ping | 13:01 |
| -!- springwurm(~Springwur@5.104.149.54) has joined #tryton | 13:02 | |
| pokoli | LordVan_: if you are manufacturing, the production modules takes care of automatically computing the costs for you | 14:04 |
| LordVan_ | pokoli, they would .. if i knew beforehand - or it would be feasible to enter all that | 14:04 |
| LordVan_ | as i said i will probably use it for repeatedly ordered parts later on | 14:04 |
| pokoli | Hirschbeutel: about sales and projects link is already discussed here: https://discuss.tryton.org/t/link-between-sales-and-projects/654/26?u=pokoli | 14:04 |
| pokoli | it still requires some love from my side | 14:05 |
| LordVan_ | and then look into if i can simplify the process enough to use it for the simple orders too | 14:05 |
| cedk | Hirschbeutel: pong | 14:06 |
| pokoli | LordVan_: for repetitive orders it works out of the box. As you will have the Bill of Materials and the route of Operations previously created | 14:06 |
| Hirschbeutel | @pokoli: I have similar on sale - linking it and an action: create project | 14:07 |
| Hirschbeutel | in this action I handle the conversion from the data encoded on sale to that ones needed for the project | 14:08 |
| Hirschbeutel | cedk: I startet to work on sale_point first to understand it right. the TODO create an invoice - do you mean a normal invoice with the sequence of the standard invoices? | 14:10 |
| Hirschbeutel | cedk: I need to read the legal requirements - but I think this depends on country. will ask Timitos - I guess in Germany it is a receipt and and the "invoice" is the same thing only with an Adress on it .... | 14:12 |
| pokoli | Hirschbeutel: IIRC in spain it is possible to just create an account move which resumes all the tickets | 14:13 |
| pokoli | Hirschbeutel: only requirement is that you do not identify the customer | 14:14 |
| Hirschbeutel | yes - thats the receipt | 14:14 |
| -!- lucascastro(~lucascast@177-185-133-170.dynamic.isotelco.net.br) has joined #tryton | 14:15 | |
| pokoli | Hirschbeutel: not sure but probable we will need to create an invoice without identify the customer (no tax_identifier) because those records should be send to SII | 14:16 |
| pokoli | SII -> Send all invoices to tax authority using a webservices | 14:17 |
| LordVan_ | same here | 14:17 |
| Hirschbeutel | pokoli: if I understood right the use case is: customers pays and asks for an invoice - because he want to get back taxes or to feel more comfortabel or whatever | 14:18 |
| pokoli | Hirschbeutel: then you should ask for the tax_identifier and identify the customer to create a normal invoice | 14:19 |
| Hirschbeutel | pokoli: one moment - will look at some in my office - but I feel that nobody asking me for that (cause I don't know without going back to my office ;) | 14:21 |
| Hirschbeutel | pokoli: no - only a minimal address and a line telling: paid in cash on date | 14:23 |
| LordVan_ | btw | 14:24 |
| LordVan_ | about my numeric formant question earlier @pokoli | 14:24 |
| LordVan_ | the sale party has german set as language | 14:24 |
| LordVan_ | so is tryton UI | 14:24 |
| LordVan_ | so it must be the server side | 14:24 |
| LordVan_ | not respecting that | 14:24 |
| -!- htgoebel(~hartmut@ppp-188-174-53-141.dynamic.mnet-online.de) has joined #tryton | 14:27 | |
| pokoli | LordVan_: but where are the wrong format shown? On the user interface or on the report? | 14:37 |
| LordVan_ | odt report | 14:37 |
| LordVan_ | it shows 2.0 instead of 2,0 | 14:37 |
| pokoli | LordVan_: custom report? | 14:37 |
| LordVan_ | not yet no just the normal sale report | 14:37 |
| LordVan_ | with custom odt ofc | 14:39 |
| pokoli | LordVan_: then probably you are missing the set_lang call in the odt template | 14:39 |
| LordVan_ | ah | 14:39 |
| LordVan_ | that could be | 14:39 |
| LordVan_ | i shall check out the original template again. | 14:39 |
| LordVan_ | thanks | 14:39 |
| htgoebel | Hi, | 14:41 |
| htgoebel | does Tryton already provided some means of a "waiting list" for a service? | 14:41 |
| htgoebel | Like when you need a place in the hospital: You put your name on the list and if a bed is available you are asked whether you want to take it. You can jump of the list anytime and there is no contract until you actually agree on taking the bed. | 14:41 |
| pokoli | ACTION is happy to have an active chat today with the community :) | 14:44 |
| -!- mniip(~mniip@freenode/staff/mniip) has joined #tryton | 14:44 | |
| pokoli | htgoebel: we usally manage that with states | 14:45 |
| pokoli | htgoebel: for example, on outgoing list there is a "waiting" state which is all the shipments that should be picked | 14:45 |
| pokoli | htgoebel: and the shipment is not picked/packed/sent until it goes forward in the workflow | 14:45 |
| htgoebel | pokoli: This would be far to late in the process. | 14:46 |
| htgoebel | pokoli: Wait - need to rephrase | 14:47 |
| pokoli | htgoebel: to be honest I do not know your process because you did not explain it to us :) | 14:48 |
| pokoli | just giving some ideas | 14:48 |
| htgoebel | pokoli: When using a state for some picking, the process has advanced quite far already. | 14:51 |
| htgoebel | The waiting is at the very beginning, the is not even a contract, not even a binding sale offer. | 14:51 |
| htgoebel | Like when you are waiting to get a place on the next ship, a room in a seniors residence, a kidney transplantation: Your name and contact is put on a list and if everybody in front of you has been served, it's your turn to decide whether you still want to agree on some contract | 14:51 |
| htgoebel | pokoli: Implementing this from scratch is easy: Just an ordered lists of parties. | 14:55 |
| htgoebel | pkoli: I just wonder if Tryton already implements such means. | 14:55 |
| pokoli | htgoebel: if you have some asset to be rent, there is the sale_subscription_asset module | 14:57 |
| pokoli | htgoebel: otherwise it's just o quotation that need to be accepted | 14:57 |
| htgoebel | pokoli: Thx. | 14:58 |
| pokoli | htgoebel: once you have a table with a many2one to party, there is a list of parties which you can order on any field (for example creation data) | 14:58 |
| pokoli | htgoebel: not sure if that helped so much, but your concept is very abstract | 14:58 |
| htgoebel | pokoli: Well, a waiting list is quite abstract ;-) | 14:59 |
| pokoli | htgoebel: what I mean is that the implementation can be very diferent depending on the problem to solve | 15:00 |
| pokoli | htgoebel: following on your examples, on the ship you should agree on the days before confirming the place and make it not available for others | 15:00 |
| pokoli | htgoebel: a room in seniors residence can be managed out of the with sale_subscrition_asset module: https://docs.tryton.org/projects/modules-sale-subscription-asset/en/latest/ | 15:01 |
| pokoli | htgoebel: and a kidney translplantion probably you start looking at the kidney once you have the need of it (a kind of sale_supply) | 15:02 |
| pokoli | so for me there should be a diferent implementation for each of your examples | 15:02 |
| htgoebel | pokoli: Thanks. I actually missed that I need to wait for an answer (or timeout) before offering to the next one on the list. | 15:03 |
| htgoebel | pokoli: For now - i still need to convince my CIO ;-) I'll go with a very simply many2one table. | 15:04 |
| htgoebel | Everything else needs to be defined later. | 15:04 |
| pokoli | htgoebel: if your CIO needs a videoconference to resolve doubts I will be happy to help on that | 15:05 |
| pokoli | htgoebel: but please have a concrete list of questions so we can answer them | 15:05 |
| pokoli | htgoebel: and if you do not mind we can make it like an interview and share it on tryton's youtube chanels for others | 15:06 |
| Hirschbeutel | htgoebel: I have a waiting list for books | 15:06 |
| Hirschbeutel | htgoebel: (party, book, date of request) more or less - if book returns, next user gets a message - after a defined delay the next - first comes first serve | 15:07 |
| htgoebel | pokoli: Thanks for the offer - the "CIO" actually is not the CIO but the (main and single) developer of the current solution. | 15:07 |
| htgoebel | pokoli: This is why I asked for technical features. | 15:07 |
| htgoebel | pokoli: Anyhow, my presentation is tomorrow and I'm about to structure what I have up to now. | 15:07 |
| htgoebel | Hirschbeutel: Sounds very much like what I meant :-) | 15:08 |
| pokoli | Hirschbeutel: did you have a waiting list for webshop? | 15:09 |
| htgoebel | hirschbeutel: If this is publicly available, I'd like to present it tomorrow. Otherwise I'd just tell there already is such an solution. | 15:09 |
| pokoli | Hirschbeutel: we have one where all the users are noticed when a product is received on the warehouse | 15:09 |
| Hirschbeutel | htgoebel: you can tell him there is a solution for everything, the only problem is to know where | 15:10 |
| Hirschbeutel | pokoli: not yet - but this is a rquirement | 15:10 |
| Hirschbeutel | pokoli: not having this is lame :) | 15:11 |
| Hirschbeutel | pokoli: we should start a repo with shop plugins | 15:11 |
| pokoli | Hirschbeutel: did you think there is some usage without webshop? | 15:12 |
| Hirschbeutel | pokoli: yes - possibly if you think like: a sales person can encode such a line and forget about this - so system will do the marketing | 15:13 |
| Hirschbeutel | pokoli: so the answer is YES! | 15:13 |
| Hirschbeutel | (mechanism, email*, date, product) | 15:14 |
| pokoli | Hirschbeutel: indeed we just store the party and the product | 15:14 |
| Hirschbeutel | email* for rpc from outside | 15:15 |
| pokoli | Hirschbeutel: and we have a state field to see if the request has been received or not | 15:15 |
| pokoli | Hirschbeutel: and when the state is updated to received we trigger a notification using notification_email module | 15:15 |
| Hirschbeutel | which request? | 15:15 |
| Hirschbeutel | mail state? | 15:15 |
| Hirschbeutel | nice | 15:16 |
| pokoli | Hirschbeutel: request -> the record of the waiting list (product and party) | 15:16 |
| Hirschbeutel | pokoli: do not understand - if there is a line, a request happend, or not? | 15:17 |
| pokoli | Hirschbeutel: there is a line with two states: Waiting and Received | 15:18 |
| pokoli | Hirschbeutel: once the party adds the product to the waiting list, a line with party and the product is created | 15:18 |
| pokoli | at this stage the line is in waiting state | 15:18 |
| Hirschbeutel | ah - know I got it | 15:19 |
| pokoli | Hirschbeutel: and when the product is recieved the state of the line is updated to received | 15:19 |
| pokoli | From there you can use the marketing_automation module or the notification_email | 15:19 |
| pokoli | or nothing :) | 15:19 |
| Hirschbeutel | I delete the line - because there are to many requests and nobody needs this information historical | 15:19 |
| Hirschbeutel | but with state is good as well -depends off the number of requests and if the company sees this a a GDPO issue | 15:21 |
| Hirschbeutel | don't know - for legal stuff deleting is always the best solution :) | 15:22 |
| Hirschbeutel | burn it .... | 15:22 |
| Hirschbeutel | pokoli: send me a offer :) | 15:24 |
| pokoli | Hirschbeutel: we prefer to save the line to see if the customer purchased the product at the end or not | 15:25 |
| pokoli | Hirschbeutel: for example if we send a notification and the party does not buy the product in 7 days we can send another mail, or call him | 15:25 |
| pokoli | You know, marketing is evil at some points. They now more from us than ourselves | 15:25 |
| Hirschbeutel | pokoli: I would hate you for that :) | 15:26 |
| Hirschbeutel | pokoli: but possibly buy to get rid of your calls | 15:26 |
| -!- rpit1(~rpit@p200300c88f0235001c42215a17f33f55.dip0.t-ipconnect.de) has joined #tryton | 15:27 | |
| Hirschbeutel | pokoli: in our case, the products are in short supply - if you don't get back to us, you're out of luck. | 15:29 |
| Hirschbeutel | pokoli: but this all is the same module | 15:29 |
| Hirschbeutel | pokoli: I'll take yours | 15:29 |
| pokoli | Hirschbeutel: you can always read the customer to waiting list automitcally if there is not stock and they did not have luck to buy | 15:31 |
| Hirschbeutel | pokoli: gimme offer - i will sell it | 15:31 |
| Hirschbeutel | pokoli: need to migrate all that stuff, no time to write new features | 15:32 |
| pokoli | Hirschbeutel: indeed to make it generic we should probably need a draft state, and a test to ensure that when adding to the waiting list there is not stock | 15:33 |
| Hirschbeutel | i could contribute as well :) | 15:34 |
| pokoli | Hirschbeutel: and a warehouse where the customer want's the product | 15:34 |
| Hirschbeutel | pokoli: why? | 15:34 |
| pokoli | Hirschbeutel: because in our case we have a single warehouse but I it should be possible to have and order between warehouses | 15:34 |
| pokoli | Hirschbeutel: because we may have a warehouse on germany and another in Barcelona | 15:35 |
| pokoli | Hirschbeutel: if there are a lots of demand of products in Germany and we have stock on Barcelona, we may delivery directly | 15:35 |
| Hirschbeutel | pokoli: yes - in this case it would be cool | 15:35 |
| pokoli | Hirschbeutel: that the work of going from a custom solution to a generic one that can be reused | 15:44 |
| pokoli | Hirschbeutel: i let you open a feature request on the forum :) | 15:45 |
| Hirschbeutel | second task I put on my list ... | 15:49 |
| pokoli | Hirschbeutel: i throw the entire list away because it was to large xD | 15:50 |
| pokoli | too* | 15:50 |
| Hirschbeutel | pokoli: I was ask to help out in a project and now fixing the whole day | 15:51 |
| pokoli | Hirschbeutel: it seems clear that they need help on fixing a lot of issues. | 15:52 |
| pokoli | Hirschbeutel: You should ask them to provide you a complete test suite to avoid the errors | 15:53 |
| Hirschbeutel | pokoli: the fixes have changed to new features ;) | 15:53 |
| Hirschbeutel | pokoli: they own me | 15:54 |
| pokoli | Hirschbeutel: this also happen on tryton bug tracker, bugs are converted to new features some times :P | 15:54 |
| -!- springwurm(~springwur@p200300fbaf0ac8000000000000000bf8.dip0.t-ipconnect.de) has joined #tryton | 17:14 | |
| -!- jani-matti(~quassel@93-90-53-6.welcomnet.fi) has joined #tryton | 17:19 | |
| -!- lucascastro(~lucascast@45-167-143-6.netfacil.inf.br) has joined #tryton | 17:24 | |
| -!- lucascastro(~lucascast@177.185.131.162) has joined #tryton | 17:40 | |
| -!- lucascastro(~lucascast@177-185-131-162.corp.isotelco.net.br) has joined #tryton | 17:49 | |
| -!- htgoebel(~hartmut@ppp-188-174-53-141.dynamic.mnet-online.de) has left #tryton | 18:08 | |
| -!- nicoe(~nicoe@2a02:578:852a:c00:7e2a:31ff:fe5e:b25d) has joined #tryton | 18:21 | |
| -!- ludo2(~Thunderbi@2001:912:1480:380::1) has joined #tryton | 18:52 | |
| -!- ludo2(~Thunderbi@2001:912:1480:380::1) has joined #tryton | 20:03 | |
| -!- nicoe(~nicoe@2a02:578:852a:c00:7e2a:31ff:fe5e:b25d) has joined #tryton | 20:28 | |
| -!- thaneor(~ldlc6@r167-61-59-203.dialup.adsl.anteldata.net.uy) has joined #tryton | 21:21 | |
| -!- thaneor1(~acer8@r167-61-59-203.dialup.adsl.anteldata.net.uy) has joined #tryton | 21:21 | |
| -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton | 22:47 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!