| chat.freenode.net #tryton-es log beginning Wed Feb 28 00:02:01 CET 2018 | ||
| -!- meigallodixital(~meigallod@162.200.26.77.dynamic.reverse-mundo-r.com) has joined #tryton-es | 09:00 | |
| meigallodixital | hi | 09:01 |
|---|---|---|
| pokoli | buenos dias | 09:02 |
| -!- csotelo(~csotelo@190.237.175.75) has joined #tryton-es | 10:11 | |
| -!- mariomop(~quassel@186.153.85.211) has joined #tryton-es | 11:13 | |
| meigallodixital | pregunta de ubicarme, si quiero que en compras si un producto E siempre tenga un tax concreto (exento operaciones corrientes) el mejor sitio sería controlarlo en on_change_product() en productline? | 11:32 |
| meigallodixital | es que veo que tiene depends a unit y quantity pero no a tax | 11:32 |
| pokoli | meigallodixital: en la configuración del producto le pones este impuesto y ya esta | 11:46 |
| meigallodixital | no me vale porue si es G es el impeusto configurado si es E es exento quiero que sea auto, que me reemplace el impuesto por defecto por extento siempre | 11:51 |
| pokoli | meigallodixital: aplica la regla de impuestos extento y ya lo tienes | 11:57 |
| meigallodixital | pero en que momento es lo que preguntaba, en el onchange? | 11:58 |
| pokoli | meigallodixital: http://hg.tryton.org/modules/purchase/file/09417c6de8e4/purchase.py#l1216 | 11:59 |
| pokoli | meigallodixital: incluso hay un funcional para determinar que impuestos hay que utilizar, igual te vale con sobreescribir ese funcional | 12:00 |
| meigallodixital | voy a ver gracias | 12:00 |
| meigallodixital | encontré un rror de traduccion de casualidad | 12:00 |
| meigallodixital | "0 - Plan General Contable 2008""Operaciones exentas sin derecho de deducción (servicios asistentciales)""Ambos" | 12:00 |
| meigallodixital | sobra una t en asistenciales | 12:00 |
| pokoli | meigallodixital: la idea es que ese impuesto desaparezca: https://codereview.tryton.org/41101002/diff/40001/tax.xml | 12:01 |
| meigallodixital | ok, lo vi de casualidad revisando las reglas, yo no lo uso por eso lo comentaba :) | 12:02 |
| -!- meigallodixital_(~meigallod@162.200.26.77.dynamic.reverse-mundo-r.com) has joined #tryton-es | 12:24 | |
| -!- meigallodixital(~meigallod@77.26.200.162) has joined #tryton-es | 12:28 | |
| -!- nstefani(~nstefani@190.210.221.137) has joined #tryton-es | 12:37 | |
| meigallodixital | re | 12:39 |
| meigallodixital | tendría que cambiar a aprte del _get_tax_rule_pattern el método no? porque no pasa la línea y necesito consultarla para saber si es g o e entiendo | 12:39 |
| -!- nstefani(~nstefani@190.210.221.137) has joined #tryton-es | 12:41 | |
| pokoli | meigallodixital: como indicas si es g o e? | 12:51 |
| meigallodixital | en la linea de compra | 13:00 |
| pokoli | meigallodixital: y no puedes hacer on_change_tu_campo ? | 13:02 |
| pokoli | meigallodixital: para que al cambiar de g a e te cambie los impuestos? | 13:02 |
| meigallodixital | el onchange se ejecuta si lo seteo por prog? | 13:03 |
| meigallodixital | porque si es tienda es e por defecto y readonly para los compradores | 13:03 |
| pokoli | meigallodixital: entonces porqué no haces lo mismo con los impuestos? | 13:05 |
| meigallodixital | porque el mismo producto se puede comprar e o g | 13:06 |
| pokoli | meigallodixital: pero si el campo es readonly.... no se puede modificar | 13:06 |
| pokoli | meigallodixital: por lo tanto siempre sera e para tienda | 13:06 |
| meigallodixital | el comrpador no, el gerente de tienda y nosotros si | 13:06 |
| meigallodixital | en entral | 13:06 |
| pokoli | meigallodixital: por lo que para tienda puedes poner el impuesto exento tambien | 13:06 |
| meigallodixital | por eso me gustaría que fuera auto para evitar errores | 13:07 |
| pokoli | meigallodixital: si haces el campo reaonly no hay errores.... | 13:07 |
| meigallodixital | voy a probar meterlo en el onchange de mi campo regime a ver que tal | 13:07 |
| pokoli | meigallodixital: si haces una vista con un dominio de regime = 'E', si se llama el on_change | 13:07 |
| meigallodixital | para tienad no, pero para gerente y central si, puedo ponerlo e y olvidarme de cambiar los impuestos | 13:07 |
| pokoli | meigallodixital: pues pones un on_change i ya esta | 13:17 |
| meigallodixital | en ello estoy | 13:18 |
| meigallodixital | para sobreescribir los ids no debiera ser ñl metodo browse? entiendo que devuelve ids solo | 14:33 |
| pokoli | meigallodixital: sobreescribir ids? | 14:47 |
| pokoli | meigallodixital: nose que quieres hacer, pero esa frase ha levantado todas mis alarmas | 14:48 |
| meigallodixital | machacar taxes, lei mal no es eso | 14:48 |
| pokoli | meigallodixital: sigo sin comprender | 14:48 |
| meigallodixital | si es E quiero sobreescribir taxes de la linea de compra | 14:48 |
| meigallodixital | no añadir sino machacrlo para hacerlo del tirón | 14:49 |
| meigallodixital | https://pastebin.com/Ky8wAhM9 | 14:50 |
| meigallodixital | algo de este estilo | 14:50 |
| meigallodixital | que me estoy dando cuenta que no es tan facil porque si me vuelven a canmbiar a g tengo que volver a hacer la comprobación de impuestos iniciales, no se si compensará tocar el funcional como me decías antes | 14:51 |
| pokoli | meigallodixital: los on_changes debes assiganr los valors a la propia instancia | 14:54 |
| pokoli | meigallodixital: self.taxes = taxes | 14:55 |
| meigallodixital | no se si con el get_rule_patttern se podría hacer globalmente, lo que pasa que veo que ahí no se pasa la línea de compra | 14:55 |
| pokoli | meigallodixital: si es g, lo que puedes hacer es limipar los taxes y llamar al on_change_product | 14:56 |
| pokoli | meigallodixital: en el get_rule_pattern podrias poner-le el regime | 14:56 |
| meigallodixital | a eso iba, que la final voy a tener que llamar al on_change_product igualmente, si con el get_rule_pattern funciona centralizaría ahi lso cambios, pero para pasarle el regime y/o linea completa necesito tocar el el método también porque veo que no le pasa nada | 15:08 |
| meigallodixital | en requisition creo que si | 15:08 |
| meigallodixital | que fue los code que cotillee antes | 15:09 |
| pokoli | meigallodixital: el problema que veo es que el pattern es por cliente y puede ser que no tengas | 15:27 |
| meigallodixital | hum | 15:28 |
| pokoli | meigallodixital: el tax rule es por cliente perdon | 15:28 |
| pokoli | meigallodixital: y no es un campo obligatorio | 15:28 |
| meigallodixital | si, de dhecho en changeo_product se comprueba por eso pregunbtaba que tal empezar ahi | 15:48 |
| meigallodixital | y el pattern lo pasa tanto cuando comprueba party como producto por eso pensaba que qizás por ahí ... | 15:50 |
| meigallodixital | pero no tengo regime en get_rule_pattern | 15:50 |
| -!- danypr92(~daniel@90.68.31.84) has joined #tryton-es | 15:55 | |
| meigallodixital | en purchase request se llama asi: def _get_tax_rule_pattern(line, purchase): | 15:55 |
| meigallodixital | entiendo que tendría que ahcer algo similar | 15:56 |
| danypr92 | Buenas, queremos desarrollar algo parecido a lo que ofrece este módulo: https://bitbucket.org/zikzakmedia/trytond-party_event para la versión 3.8. Alguien sabe porque se descontinuo este proyecto? Alguna alternativa para versiones posteriores de Tryton? Gracias! | 15:59 |
| meigallodixital | supongo que falta de demanda hasta igual fue prueba de concepto simplemente | 16:10 |
| danypr92 | Gracias! | 16:27 |
| pokoli | danypr92: mientras mantengas el COPYRIGHT, puedes cojer ese modulo como base y adaptar-lo a nuevas versiones | 16:51 |
| pokoli | danypr92: viendo el código possiblemente este módulo se descontinuo en beneficio del módulo activity | 16:52 |
| -!- zodman(~zodman@178.62.7.89) has joined #tryton-es | 19:17 | |
| -!- mariomop(~quassel@181.91.16.62) has joined #tryton-es | 19:38 | |
| -!- marto87(~marto@host126.186-109-85.telecom.net.ar) has joined #tryton-es | 20:10 | |
| -!- marto87(~marto@host126.186-109-85.telecom.net.ar) has left #tryton-es | 21:11 | |
| -!- danypr92(~daniel@2.152.107.85.dyn.user.ono.com) has joined #tryton-es | 23:01 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!