| chat.freenode.net #tryton log beginning Mon Dec 3 00:00:01 CET 2012 | ||
| 2012-12-03 01:39 <Ark_> can somebody explain me a fundamental question about WebDAV? | ||
| 2012-12-03 01:41 <Ark_> (one about apache and tryton, a question whether they interfere, a question that I couldn't answer myself from reading the doc/wiki and by googling) | ||
| 2012-12-03 02:48 -!- Ark_(~Ark@158-172.1-85.cust.bluewin.ch) has left #tryton | ||
| 2012-12-03 09:58 -!- 16WABFDF8(~ralf58@dslb-088-070-132-151.pools.arcor-ip.net) has left #tryton | ||
| 2012-12-03 12:37 <corro> jcm: Do you have by chance a newer build of the tryton client 2.4 you could share? We're having problems with the official 2.4.0 client and I remember you helped us out with a 2.0 build last time. | ||
| 2012-12-03 13:56 <sisalp> hello, last week I had to revisit openerp basic modules with a group of economy/management/accounting teachers | ||
| 2012-12-03 13:57 <sisalp> we noticed aain many problems, one ot them, I think also affects Tryton | ||
| 2012-12-03 13:57 <sisalp> s/aain/again/ | ||
| 2012-12-03 13:58 <sisalp> the point is to fix future operations in the sale order, while they are not under the sales' responsability | ||
| 2012-12-03 13:59 <sisalp> I mean supply / delivery /invoicing consequencies of the sale order | ||
| 2012-12-03 14:00 <sisalp> the point would to allow some parameters to be changed later, until suggested documents are at least drafted | ||
| 2012-12-03 14:01 <sisalp> am I clear ? | ||
| 2012-12-03 14:10 <bechamel> sisalp: it's hard to think about pratical ideas for improvement if we consideer only generic observation | ||
| 2012-12-03 14:10 <sharoonthomas> corro: There is windows binary for 2.4.1 http://downloads2.tryton.org/2.4/tryton-2.4.1.exe | ||
| 2012-12-03 14:11 <sisalp> bechamel: thank you answering. What should I provide ? List of these parameters ? | ||
| 2012-12-03 14:12 <bechamel> sisalp: personaly I like to have an actual use-case | ||
| 2012-12-03 14:13 <sisalp> bechamel: you mean describe it as a story ? | ||
| 2012-12-03 14:13 <corro> sharoonthomas: Thank you, but I forgot to mention that I'm looking for a mac client. The current official one hangs on various views. | ||
| 2012-12-03 14:14 <bechamel> sisalp: my first reaction was: "just let salesman create draft orders and then leave the final parameter setting to a manager" but I'm not sure it is relevant for ou | ||
| 2012-12-03 14:14 <bechamel> *you | ||
| 2012-12-03 14:15 <sharoonthomas> corro: there are some instructions here http://code.google.com/p/tryton/wiki/BuildingMacOSXInstall | ||
| 2012-12-03 14:15 <sisalp> bechamel: if you don't validate the order, you don't use the workflow, it's a pity | ||
| 2012-12-03 14:16 <bechamel> sisalp: yes, this helps to focus on the needs | ||
| 2012-12-03 14:16 <corro> sharoonthomas: Thanks | ||
| 2012-12-03 14:16 <sisalp> the idea is : the sale man requests a specific purchase to fulfill the SO | ||
| 2012-12-03 14:17 <bechamel> sisalp: I mean that the manager finalize the order then validate it (and the workflow runs normaly) | ||
| 2012-12-03 14:17 <sisalp> 2 tryton generates a purchase request | ||
| 2012-12-03 14:17 <sisalp> 3 the purchaser decides not to buy but to get it from stock | ||
| 2012-12-03 14:18 <sisalp> 4 he updates the SO so it is delivered from stock | ||
| 2012-12-03 14:18 <sisalp> I can do the same with invoices on order or on shipments | ||
| 2012-12-03 14:19 <sisalp> bechamel, I disagree, the manager doesn't know more until the purchase order is worked out | ||
| 2012-12-03 14:20 <sisalp> keeping the SO as draft prevents invoicing too | ||
| 2012-12-03 14:22 <sisalp> bechamel: consider an SO can be delivered weeks later | ||
| 2012-12-03 14:22 <bechamel> sisalp: it was not a real proposition, but to explain you that it is difficult to answer such a large question without context | ||
| 2012-12-03 14:23 <sisalp> bechamel: keeping the SO draft is just a way to say : do it manually because Tryton cannot do it | ||
| 2012-12-03 14:23 <sharoonthomas> corro: do let me know if it goes well, i remember trying it once before and it did not work. | ||
| 2012-12-03 14:24 <sharoonthomas> corro: the instructions are a bit old, would be nice if you update it too | ||
| 2012-12-03 14:25 <sisalp> bechamel: what kind of context would help ? | ||
| 2012-12-03 14:26 <sisalp> bechamel: I just think that if the company has more than one employee, today situation doesn't make sens | ||
| 2012-12-03 14:26 <bechamel> sisalp: mys first question is why "the sale man requests a specific purchase" ? | ||
| 2012-12-03 14:26 <sisalp> bechamel: because he can | ||
| 2012-12-03 14:27 <sisalp> sales are not mesured on stock levels | ||
| 2012-12-03 14:27 <sisalp> the higher it is the better for them | ||
| 2012-12-03 14:28 <bechamel> sisalp: and more importantly how does he "request a purchase"? there are no such think on the sale order | ||
| 2012-12-03 14:28 <sisalp> bechamel: but if you hide this parameter to sales, which would be better, then the problem has no solution | ||
| 2012-12-03 14:30 <bechamel> sisalp: which parameter ? | ||
| 2012-12-03 14:30 <sisalp> bechamel: same for invoice. The sales is not in charge of deciding whether the customer will be invoiced based on the order or on the shipment | ||
| 2012-12-03 14:30 <sisalp> bechamel: I check for the parameter | ||
| 2012-12-03 14:36 <sisalp> bechamel: on stock / on order is no longer shown, may be part of my suggestion is already in ;-) | ||
| 2012-12-03 14:37 <bechamel> sisalp: :) | ||
| 2012-12-03 14:39 <bechamel> sisalp: and maybe you also didn't see that you can define default value for sale and shipment method (On Order Processed / On chipment Sent/ manualy) in Sale > Configuration > Sale configuration | ||
| 2012-12-03 14:39 <bechamel> s/method/methods/ | ||
| 2012-12-03 14:39 <sisalp> bechamel: the point is to allow modification afterwards | ||
| 2012-12-03 14:41 <bechamel> sisalp: those are just default values for the sale, they can be changed on the sale | ||
| 2012-12-03 14:42 <sisalp> bechamel: I made the following : I did a new sale order, validate and process. I cannot change shipment/invoicing method after this | ||
| 2012-12-03 14:47 <bechamel> sisalp: I agree that the current behaviour is not forgiving to the user :) | ||
| 2012-12-03 14:48 <sisalp> bechamel: the point is not to forgive a generic user, but the "right" user | ||
| 2012-12-03 14:49 <sisalp> moves and invoice are still draft, I should be able to modify SO parameters and ask Tryton to calculate new ones | ||
| 2012-12-03 14:49 <sisalp> when either invoice or moves are validated, then I understand the SO cannot be modified | ||
| 2012-12-03 14:50 <bechamel> sisalp: this what I wanted to say by "forgiving": if the user make a mistake he is stuck | ||
| 2012-12-03 14:51 <sisalp> bechamel: I disagree: sales user is not equivalent to stock management user and accountant. | ||
| 2012-12-03 14:52 <sisalp> bechamel: we can be hard with the one who is in charge of, not with those who are not | ||
| 2012-12-03 14:53 <sisalp> bechamel : the sale man doesn't make a mistake if he indicates the best values he can guess | ||
| 2012-12-03 14:53 <sisalp> because he has no idea of the decisions other are in charge of later. | ||
| 2012-12-03 14:54 <sisalp> bechamel: does it sound reasonable ? | ||
| 2012-12-03 14:55 <sisalp> I understand Tryton is far better than OE on this point, but still not 100% natural | ||
| 2012-12-03 14:59 <sisalp> Hello all, I would be interested in hearing from others if I'm the only one to feel this way | ||
| 2012-12-03 15:02 <sisalp> from sale order, I could cancel the draft invoice, I had to go to scck management to cancel the move | ||
| 2012-12-03 15:03 <sisalp> then it didn't help, I cannot reprocess the order | ||
| 2012-12-03 15:03 <sisalp> s/ssct/stock | ||
| 2012-12-03 15:04 <bechamel> sisalp: yes, I think this is a problem | ||
| 2012-12-03 15:05 <sisalp> I did it on demo database as admin | ||
| 2012-12-03 15:06 <yangoon> sisalp: I agree that those restrictions are too early in the workflow | ||
| 2012-12-03 15:06 <yangoon> it would be of general help to have a common and documented worklflow of the sales process | ||
| 2012-12-03 15:21 <bechamel> actually before this http://hg2.tryton.org/modules/sale/rev/ed8b2536f9fe it was possible to cancel a sale with a shipment or an invoice exception, but there are no issue associated to the changeset so I don't know what it solve exactly | ||
| 2012-12-03 16:38 <rmu> something that bugs me in purchase: | ||
| 2012-12-03 16:38 <rmu> i enter a draft purchase | ||
| 2012-12-03 16:39 <rmu> then make "request for quotation", send this to supplier | ||
| 2012-12-03 16:39 <rmu> supplier gives price | ||
| 2012-12-03 16:39 <rmu> then i have to set purchase back to draft in order to enter the price | ||
| 2012-12-03 16:54 <chrips> I'm having trouble pulling module with hg 'pull -u' does not pull the modules and npull is unrecognized (depreciated?) | ||
| 2012-12-03 16:54 <chrips> I can't find any reference to npull anywhere | ||
| 2012-12-03 17:17 <rmu> chrips: hgnested | ||
| 2012-12-03 18:07 <cedk> sisalp: I don't see what is the problem | ||
| 2012-12-03 18:08 <cedk> sisalp: the methods stored on the sale are the one the company decide to work with | ||
| 2012-12-03 18:09 <cedk> sisalp: I don't see what you want to change | ||
| 2012-12-03 18:10 <bechamel> cedk: why this changeset hide the cancel button when there is a shipment/invoice exception: http://hg2.tryton.org/modules/sale/rev/ed8b2536f9fe ? | ||
| 2012-12-03 18:11 <cedk> bechamel: because you have to run the wizard for that | ||
| 2012-12-03 18:13 <bechamel> cedk: which one? "handle invoice/shipment exception"? | ||
| 2012-12-03 18:14 <bechamel> cedk: sorry it's obvoously "Create return sale" | ||
| 2012-12-03 18:14 <cedk> bechamel: yes | ||
| 2012-12-03 18:14 <cedk> bechamel: if you have just one of 2 invoices cancel, you will not cancel the sale | ||
| 2012-12-03 18:15 <bechamel> cedk: I think the wizard should be shown as a button, beside the "handle invoice/shipment exception" | ||
| 2012-12-03 18:17 <cedk> bechamel: don't understand | ||
| 2012-12-03 18:18 <bechamel> cedk: there is an affordance problem, in this sitation the user as two choice: 1) fix the exception 2) cancel everything | ||
| 2012-12-03 18:19 <bechamel> and he only see 1) | ||
| 2012-12-03 18:19 <cedk> bechamel: false, he can not cancel everything | ||
| 2012-12-03 18:20 <cedk> bechamel: you can not cancel something validated, you just finish it with exception | ||
| 2012-12-03 18:20 <bechamel> cedk: creating the return sale is what for you ? | ||
| 2012-12-03 18:21 <bechamel> cedk: you play with words to avoid answering the questions, like a politician | ||
| 2012-12-03 18:21 <cedk> bechamel: what is the problem ????? | ||
| 2012-12-03 18:22 <bechamel> cedk: the fact that when an (invoice/shipment) exception appears the user as two option, but he sees only one button | ||
| 2012-12-03 18:23 <cedk> bechamel: he has only 1 option ! | ||
| 2012-12-03 18:23 <cedk> bechamel: don't try to reintroduce your own bugs | ||
| 2012-12-03 18:24 <bechamel> cedk: you told me that the wizard replace the cancel button | ||
| 2012-12-03 18:24 <cedk> bechamel: no I never said that | ||
| 2012-12-03 18:25 <bechamel> "why this changeset hide the cancel button" -> "because you have to run the wizard for that" | ||
| 2012-12-03 18:25 <cedk> bechamel: read better | ||
| 2012-12-03 18:26 <bechamel> cedk: so if I make a mistake in a sale and confirm it, there is nothing I can do to fix the situation ? | ||
| 2012-12-03 18:26 <cedk> bechamel: run the wizard | ||
| 2012-12-03 18:26 <cedk> bechamel: you have to keep track that you make a mistake | ||
| 2012-12-03 18:28 <bechamel> cedk: ok then, what if I (the salesman) realize my mistake when an exception is triggerded by the warehouse guy or by the financial guy ? | ||
| 2012-12-03 18:28 <cedk> bechamel: what exception ? | ||
| 2012-12-03 18:29 <cedk> this afternoon, you just talked whithout any real scenario, it is just a lost of time | ||
| 2012-12-03 18:29 <bechamel> cedk: the cause of the exception is not relevant, they appear so they must be handled | ||
| 2012-12-03 18:29 <cedk> bechamel: which exception is not handled ? | ||
| 2012-12-03 18:30 <bechamel> cedk: example a supplier stop suppliyng a product | ||
| 2012-12-03 18:30 <cedk> bechamel: if you don't have any example, just shut up | ||
| 2012-12-03 18:30 <cedk> bechamel: so cancel the shipment | ||
| 2012-12-03 18:30 <bechamel> cedk: and I leave the sale like that ? | ||
| 2012-12-03 18:30 <cedk> bechamel: run the fucking wizard !!!!!!!!! | ||
| 2012-12-03 18:31 <cedk> bechamel: I stop, run a recent Tryton before asking stupid question | ||
| 2012-12-03 18:33 <bechamel> cedk: so we agree that we may have one situation where a shipment as been cancelled that can arize from two circumstance 1) the saleman made a mistake 2) the supplier stopped to supply a product | ||
| 2012-12-03 18:34 <bechamel> cedk: I there is a wizard, all my questions are about UI and affordance | ||
| 2012-12-03 18:34 <bechamel> s/I there/I know there/ | ||
| 2012-12-03 18:38 <bechamel> afk | ||
| 2012-12-03 18:43 <sisalp> cedk: sisalp: the methods stored on the sale are the one the company decide to work with : this is what is under question | ||
| 2012-12-03 18:43 <sisalp> cedk: I disagree | ||
| 2012-12-03 18:44 <sisalp> czdk: the business logic is unconsistent | ||
| 2012-12-03 18:44 <cedk> sisalp: the method are part of the sale as it is what the customer agree to work with | ||
| 2012-12-03 18:45 <cedk> sisalp: if you don't want salemen to change it, just make it readonly | ||
| 2012-12-03 18:47 <sisalp> cedk: I think you don't want to understand do you ? | ||
| 2012-12-03 18:48 <sisalp> cedk: is ithere a hidden technical problem that makes it impossible to sort responsabilities correctly in the workflow ? | ||
| 2012-12-03 18:49 <sisalp> cedk: and we don't consider information the customer knows. don't make it confuse | ||
| 2012-12-03 18:54 <cedk> sisalp: I don't see what you are talking about | ||
| 2012-12-03 18:54 <cedk> sisalp: invoice and shipment method are known by the customer | ||
| 2012-12-03 18:55 <sisalp> cedk: why ? | ||
| 2012-12-03 18:55 <sisalp> cedk: I mean why at order time ? | ||
| 2012-12-03 18:56 <cedk> sisalp: it is part of the sale contract: the customer has to know if he has to pay before being delivery or not | ||
| 2012-12-03 18:56 <cedk> sisalp: and as a customer, I could not agree about paying before being delivery | ||
| 2012-12-03 18:57 <cedk> for example | ||
| 2012-12-03 18:58 <sisalp> cedk: it is more complex than this | ||
| 2012-12-03 18:58 <sisalp> cedk: but I now understand what you meant | ||
| 2012-12-03 19:00 <cedk> sisalp: but if you consider that choosing the right method must be done by someone else than the salemen, then you can still create a new state in the workflow for that | ||
| 2012-12-03 19:00 <cedk> sisalp: but it is clear that it is something that must not change once validated | ||
| 2012-12-03 19:00 <sisalp> it's not so "clear" | ||
| 2012-12-03 19:02 <sisalp> cedk: and I don't understand if it is a technical consideration or a business practice | ||
| 2012-12-03 19:02 <cedk> sisalp: it is part of the contract | ||
| 2012-12-03 19:07 <cedk> sisalp: and also how will you manage the change between "shipment on invoice paid" and "pay on delivery" | ||
| 2012-12-03 19:10 <sisalp> cedk: creating other states on sale order is not so clear. | ||
| 2012-12-03 19:11 <sisalp> cedk: why do you choose this example in particular ? | ||
| 2012-12-03 19:12 <cedk> sisalp: because it create just a shipment and no invoice vs no shipment and a invoice | ||
| 2012-12-03 19:12 <sisalp> cedk: if I follow your idea "it is part of the contract" if is supposed to be added in the sale order document, isn't it ? | ||
| 2012-12-03 19:13 <cedk> sisalp: why not but most of the time it is on the general sale clause of the company | ||
| 2012-12-03 19:13 <sisalp> cedk: rg your last answer: yes you are back to the beginning | ||
| 2012-12-03 19:14 <sisalp> cedk: the idea was : change this parameter and get Tryton recalculate | ||
| 2012-12-03 19:14 <sisalp> cedk : if previous documents don't have been edited ot validated | ||
| 2012-12-03 19:15 <sisalp> I understand better now. For me it is often dependent on the customer and sometimes on the product | ||
| 2012-12-03 19:16 <cedk> sisalp: too complex, better to cancel and recreate a new one because in real life it is was you are doing: changing the sale condition so customer has to validate again | ||
| 2012-12-03 19:22 <sisalp> so in case we had more complex conditions to check, we would have to add new states to SO so checks and changes are done before it's validation. | ||
| 2012-12-03 19:23 <sisalp> asking all required people (logistic and accountant) to work on sale order validation process | ||
| 2012-12-03 19:23 <sisalp> this is a workable solution I think | ||
| 2012-12-03 19:25 <sisalp> in consequence, purchases and manufacturing will be anticipated on a forecast, so sale order can be validated at the latest moment | ||
| 2012-12-03 19:53 <cedk> sisalp: but I really don't understand your scenario | ||
| 2012-12-03 19:53 <cedk> sisalp: I don't see what you want to manage | ||
| 2012-12-03 19:57 <sisalp> cedk: the need is to let all users make their job when they have to, not at sale order time, which can be weeks ago. | ||
| 2012-12-03 19:58 <sisalp> as an example : customers who open an account get credit, others have to pay before shipment | ||
| 2012-12-03 19:59 <sisalp> a customer orders in june for delivery in september. In september if his account is open he gets credit, else he has to pay | ||
| 2012-12-03 20:00 <cedk> sisalp: what you describe is a new method | ||
| 2012-12-03 20:01 <cedk> sisalp: and the decision is not the job of the stock manager nor the accountant | ||
| 2012-12-03 20:01 <cedk> sisalp: you have to store this on the party | ||
| 2012-12-03 20:01 <sisalp> of cource in b2c, when you sell goods which are ready to ship, a standard workflow based on general conditions is ok | ||
| 2012-12-03 20:02 <sisalp> whether I stock or not the information, I cannot adapt after the order is validated | ||
| 2012-12-03 20:03 <sisalp> basically the order is made in june, but customer situation has changed before the order is physically processed. | ||
| 2012-12-03 20:06 <sisalp> the decision may be stock manager and accountant or not, the question about the periode of time where the initial choice can be modified. | ||
| 2012-12-03 20:07 <sisalp> nevertheless, I understand a new methode could be defined, not bad | ||
| 2012-12-03 20:08 <sisalp> it would anticipate different cases | ||
| 2012-12-03 20:08 <sisalp> else the users will choose the most permissive process in all cases, then adequation is decided manually, which makes sens | ||
| 2012-12-03 20:09 <cedk> sisalp: also your example, remeber me the prototype of sale_credit module |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!