Re: [tryton-es] Traducción campos auditoria

[Jordi Esteve (Zikzakmedia)]

El 11/11/16 a les 09:29, Sergi Almacellas Abellana ha escrit:

Buenos días,

Actualmente los campos de auditoria se traducen de la siguiente forma:

- ID -> "ID"
- Create Date -> "Fecha creación"
- Write Date -> "Fecha modificación"
- Create User -> "Usuario creación"
- Write User -> "Usuario modificación"

Esto se acordo en la lista catalana [1], durante la versión 2.4, 
saltandose la guia de estilo que dice que se debe utilizar la 
preposiciones en caso de que sea necesario.


Creo que ahora es un bueno momento para cambiar estas traducciones por 
una mas genéricas ya que estas traducciones se van a utilizar tambien 
como base para el Español de Latino America. Así, propongo que a 
partir de la versión 4.2, las traducciones sean las siguientes:


- ID -> "Identificador"


No me gusta nada esta propuesta. Es un campo que se utiliza mucho, sobre 
todo por técnicos informáticos que buscan un registro en concreto, y es 
mucho más rápido escribir en el filtro ID: 274 que no Identificador: 274


Yo apuesto clarísimamente para dejarlo tal y como está, que además es el 
término usado en inglés, ID como abreviación de Identificador.




- Create Date -> "Fecha de creación"
- Write Date -> "Fecha de modificación"
- Create User -> "Usuario de creación"
- Write User -> "Usuario de modificación"



No tengo una posición definida. Estoy de acuerdo en que así se cumplen 
las reglas de estilo pero por el otro lado encuentro más práctico los 
términos sin la preposición de, pues se sobreentiende. Lo que deicida la 
mayoría me estará bien.



--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Existe manual para desarrolladores de tryton?

[Jordi Esteve]

Hola José Luís,

El 08/09/16 a les 18:41, Jose Luis Zanotti ha escrit:
Estimados, soy nuevo con tryton, me gustaría agregar algunas 
funcionalidades, o buscar si ya están y no las encuentro.


Me gustaría crear unos módulos para agregar más campos a los 
productos, como fotos, descripciones, especificaciones, peso, etc, etc.


Quiero combinar tryton con ecommerce, hace solo 48 horas q estoy 
"tratando" de usar tryton. y encontré 100s de problemas, pero ya lo 
tengo casi fucnional.


Gracias de antemano.



Para empezar podrías consultar el manual técnico de tryton [1] que 
hicieron en Silix:



[1] https://bitbucket.org/silix/tryton-capacitacion-tecnica

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Eliminar el campo classe del account_payment_type

[Jordi Esteve]

El 23/08/16 a les 17:39, Sergi Almacellas Abellana ha escrit:

El 12/08/16 a les 19:46, Jordi Esteve ha escrit:

Yo creo que es mejor como está actualmente o tener 3 clases de pago (a
pagar, a cobrar, ambos) para evitar usar tipos de pago sin sentido. A
ver que opina otra gente, aunque estarán de vacaciones ;-)


Comó ya dije, Mi mejor opción es la siguiente:

- En el módulo account_payment_type no poner ninguna restricción.

En caso que alguien quiera poner restricciones en el tipo de pago que 
se implemente el módulo con sus restricciones. Si quieres se puede 
implementar un módulo nuevo con las mismas restricciones que existen 
ahora mismo. (account_payment_type_kind?)


Un saludo,




Y como ya respondí:

Las acciones de cobrar o pagar son recíprocas, pero en una empresa 
determinada un tipo de pago sólo se usa de una manera (sólo para cobrar 
o sólo para pagar) o en algunos casos de las dos.


Es un problema el disponer como tipo de pago uno que se sabe seguro que 
no se va a usar, podría ser fuente de errores por parte de los usuarios. 
Por eso, para evitar usar tipos de pagos que no tiene sentido en una 
determinada empresa, se diseño tal como está: poder limitar si un pago 
se usa sólo para pagar o cobrar.


Si quieres evitar "duplicidades en los tipos de pago", se podría tener 3 
clases de pago: A pagar, A cobrar y Ambos. En los dos primeros sólo 
pediría como se usa la cuenta bancaria una sola vez, pero en Ambos 
pediría como se usa la cuenta bancaria para pagar y para cobrar. Pero 
personalmente no le veo que sea una gran mejora hacerlo así.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Eliminar el campo classe del account_payment_type

[Jordi Esteve]

El 08/08/16 a les 16:09, Sergi Almacellas Abellana ha escrit:

El 02/08/16 a les 20:10, Jordi Esteve (Zikzakmedia) ha escrit:

El 01/08/16 a les 11:38, Sergi Almacellas Abellana ha escrit:

El 30/07/16 a les 20:11, Jordi Esteve (Zikzakmedia) ha escrit:


No me parece bien. Como te he comentado, es frecuente tener tipos de
pago que sólo fueran para cobrar o para pagar. Por ejemplo:

Datàfono (lector de tarjetas de crédito/débito). Sólo suele ser para
cobrar.
Cheque. Muchas empresas sólo los usan para cobrar.
Pagaré. Muchas empresas sólo los usan para pagar.


A mi entender, ambos tres ejemplos se pueden usar tanto para cobrar
cómo para pagar.

Es más: Pagar es una acción recíproca, por lo que al pagar a alguien
mediante un tipo de pago habrá otra persona que realizará la acción de
cobrar mediante el mismo tipo de pago.

De todos modos, entiendo que te refieres a que la propia empresa no
usa de forma habitual el tipo de pago para cobrar o bien pagar, y para
expresar los tipos de pago utilizado ya lo definimos cómo propiedades
de los terceros, por lo que no veo problema en tener definidos tipos
de pago a cobrar o a pagar que no se utilicen de forma habitual.



Exacto, son acciones recíprocas, pero en una empresa determinada un tipo
de pago sólo se usa de una manera (sólo para cobrar o sólo para pagar) o
en algunos casos de las dos.

Es un problema el disponer como tipo de pago uno que se sabe seguro que
no se va a usar, podría ser fuente de errores por parte de los usuarios.


Nadie impide crear un tipo de pago que no se va a usar o con el tipo 
incorrecto, por lo que los errores por parte de los usuarios pueden 
ser los mismos.


Alguien te diria: "El usuario debe ser responsable de saber lo que 
esta poniendo" :P


Completamente en desacuerdo. Asignando los grupos correctos al usuario 
esto no es posible.


Los módulos de tryton ya por defecto sólo proporcionan permisos de 
lectura al tipo de pago (igual que pasa con los plazos de pago, por 
ejemplo). Sólo los usuarios del grupo Administración de contabilidad 
tienen permisos para crear tipos/plazos de pago adicionales. Por tanto 
usuarios normales como los contables (los asignados al grupo 
Contabilidad) no podrán crear ni modificar tipos de pago.







Por eso, para evitar usar tipos de pagos que no tiene sentido en una
determinada empresa, se diseño tal como está: poder limitar si un pago
se usa sólo para pagar o cobrar.


Por lo que estamos obligando a todos los demás a tener la información 
duplicada. Además, si alguien cree que es de vital importancia definir 
esta restricción se puede implementar su propio módulo con sus 
restricciones de dominio, que seguramente serán mucho mas 
personalizadas y potentes.


Lo de la información duplicada dependerá de la empresa. Como ya te 
comenté, hay muchos casos en que una empresa en concreto sólo maneja 
tipos de pago en una dirección.


Y es mejor tener información duplicada (que es muy poca) que permitir 
usar tipos de pago sin sentido.






Si quieres evitar "duplicidades en los tipos de pago", se podría tener 3
clases de pago: A pagar, A cobrar y Ambos. En los dos primeros sólo
pediría como se usa la cuenta bancaria una sola vez, pero en Ambos
pediría como se usa la cuenta bancaria para pagar y para cobrar. Pero
personalmente no le veo que sea una mejora hacerlo así.


Este paso intermedio también es una opción, aunque a mi entender es 
mucho mas simple quitar el tipo y que todos sean de ambos. Además esto 
es mucho mas acorde con todo el diseño de tryton. Si te fijas en lo 
siguientes modelos:


- Plazos de pago
- Diarios de pago

No existe ninguna clase para poder filtrar ninguno de los dos modelos, 
por lo que los dos se pueden usar indistintamente para ambas cosas, 
por lo que solo por coherencia con los otros maestros, los tipos de 
pago deberían funcionar de la misma forma.


A parte veo una mejora en todo ello: Eliminar código y restricciones, 
con lo que nos evitamos que este dominio [1] o este [2] nos obligue a 
eliminar el tipo de pago al generar las facturas cuando las cantidades 
son negativas.



Además podremos utilizar el mismo tipo de pago original al generar una 
devolución de una factura, ya que actualmente nos vemos obligados a 
poner el tipo de pago en blanco para la devoluciones ya que sino nos 
salta la validación del dominio.


Si las devoluciones se hacen con otro tipo de pago al de la factura 
original, que suele ser el caso pues el pago es en la otra dirección, no 
pasa.


Yo creo que es mejor como está actualmente o tener 3 clases de pago (a 
pagar, a cobrar, ambos) para evitar usar tipos de pago sin sentido. A 
ver que opina otra gente, aunque estarán de vacaciones ;-)



--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Eliminar el campo classe del account_payment_type

[Jordi Esteve (Zikzakmedia)]

El 01/08/16 a les 11:38, Sergi Almacellas Abellana ha escrit:

El 30/07/16 a les 20:11, Jordi Esteve (Zikzakmedia) ha escrit:


No me parece bien. Como te he comentado, es frecuente tener tipos de
pago que sólo fueran para cobrar o para pagar. Por ejemplo:

Datàfono (lector de tarjetas de crédito/débito). Sólo suele ser para
cobrar.
Cheque. Muchas empresas sólo los usan para cobrar.
Pagaré. Muchas empresas sólo los usan para pagar.


A mi entender, ambos tres ejemplos se pueden usar tanto para cobrar 
cómo para pagar.


Es más: Pagar es una acción recíproca, por lo que al pagar a alguien 
mediante un tipo de pago habrá otra persona que realizará la acción de 
cobrar mediante el mismo tipo de pago.


De todos modos, entiendo que te refieres a que la propia empresa no 
usa de forma habitual el tipo de pago para cobrar o bien pagar, y para 
expresar los tipos de pago utilizado ya lo definimos cómo propiedades 
de los terceros, por lo que no veo problema en tener definidos tipos 
de pago a cobrar o a pagar que no se utilicen de forma habitual.




Exacto, son acciones recíprocas, pero en una empresa determinada un tipo 
de pago sólo se usa de una manera (sólo para cobrar o sólo para pagar) o 
en algunos casos de las dos.


Es un problema el disponer como tipo de pago uno que se sabe seguro que 
no se va a usar, podría ser fuente de errores por parte de los usuarios. 
Por eso, para evitar usar tipos de pagos que no tiene sentido en una 
determinada empresa, se diseño tal como está: poder limitar si un pago 
se usa sólo para pagar o cobrar.


Si quieres evitar "duplicidades en los tipos de pago", se podría tener 3 
clases de pago: A pagar, A cobrar y Ambos. En los dos primeros sólo 
pediría como se usa la cuenta bancaria una sola vez, pero en Ambos 
pediría como se usa la cuenta bancaria para pagar y para cobrar. Pero 
personalmente no le veo que sea una mejora hacerlo así.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Eliminar el campo classe del account_payment_type

[Jordi Esteve (Zikzakmedia)]

El 29/07/16 a les 14:48, Sergi Almacellas Abellana ha escrit:

Hola,

Acabo de darme cuenta que en una nuestra base de datos tenemos los 
siguientes tipos de pagos configurados:


Nombre:Tipo C.C  Clases de Tipo
Domiciliación bancariaTerceroA cobrar
Domiciliación bancariaEmpresaA pagar
EfectivoNingunoA cobrar
EfectivoNingunoA pagar
Transferencia BancariaEmpresaA cobrar
Transferencia BancariaTerceroA pagar

Por lo que estamos definiendo los tipos de pago por duplicado para 
poder definirlos como a pagar o a cobrar.


Este es un caso concreto (una instalación o entorno que comentaba 
Raimon). En otra instalación de Tryton podría tener tipos de pago que 
sólo fueran para cobrar o para pagar.





Entonces mi proposuesta era eliminar el campo classe ("kind") y poner 
dos campos para definir el Tipo de C.C, por lo que la misma 
información quedaria de la siguiente forma:



Nombre:Tipo C.C (Pagar) Tipo C.C (Cobrar)
Domiciliación bancariaEmpresaTercero
EfectivoNingunoA Ninguno
Transferencia BancariaTercerA Empresa

Por lo que a mi entender habría menos información duplicada.

Opiniones? Alguien be algún inconveniente?



No me parece bien. Como te he comentado, es frecuente tener tipos de 
pago que sólo fueran para cobrar o para pagar. Por ejemplo:


Datàfono (lector de tarjetas de crédito/débito). Sólo suele ser para cobrar.
Cheque. Muchas empresas sólo los usan para cobrar.
Pagaré. Muchas empresas sólo los usan para pagar.

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Eliminar el campo classe del account_payment_type

[Jordi Esteve (Zikzakmedia)]

El 29/07/16 a les 14:48, Sergi Almacellas Abellana ha escrit:

Hola,

Acabo de darme cuenta que en una nuestra base de datos tenemos los 
siguientes tipos de pagos configurados:


Nombre:Tipo C.C  Clases de Tipo
Domiciliación bancariaTerceroA cobrar
Domiciliación bancariaEmpresaA pagar
EfectivoNingunoA cobrar
EfectivoNingunoA pagar
Transferencia BancariaEmpresaA cobrar
Transferencia BancariaTerceroA pagar

Por lo que estamos definiendo los tipos de pago por duplicado para 
poder definirlos como a pagar o a cobrar.


Este es un caso concreto (una instalación o entorno que comentaba 
Raimon). En otra instalación de Tryton podría tener tipos de pago que 
sólo fueran para cobrar o para pagar.





Entonces mi proposuesta era eliminar el campo classe ("kind") y poner 
dos campos para definir el Tipo de C.C, por lo que la misma 
información quedaria de la siguiente forma:



Nombre:Tipo C.C (Pagar) Tipo C.C (Cobrar)
Domiciliación bancariaEmpresaTercero
EfectivoNingunoA Ninguno
Transferencia BancariaTercerA Empresa

Por lo que a mi entender habría menos información duplicada.

Opiniones? Alguien be algún inconveniente?



No me parece bien. Como te he comentado, es frecuente tener tipos de 
pago que sólo fueran para cobrar o para pagar. Por ejemplo:


Datàfono (lector de tarjetas de crédito/débito). Sólo suele ser para cobrar.
Cheque. Muchas empresas sólo los usan para cobrar.
Pagaré. Muchas empresas sólo los usan para pagar.

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Orden de los impuestos en el plan contable Español

[Jordi Esteve]

El 27/07/16 a les 16:26, Sergi Almacellas Abellana ha escrit:

Buenas tardes,

Ahora mismo los impuestos no tienen definido el campo sequence, por lo 
que se ordenan en orden de creación. Por lo que, para poner un 
ejemplo, el impuesto "IVA 21%" aparece detras de las retenciones a 
cuenta, cosa (a mi entender) un poco extraña. ..


Para solucionarlo se deberia llenar el campo sequence de los 
impuestos, para aparezcan primero los impuestos mas usados y luego los 
impuestos menos usados y luego los menos usados.


Esto es una ventaja para la mayoría pero un problema para la minoría, 
ya que cómo el campo sequence se llena a nivel de plantilla de plan 
contable, no podrán personalizar el orden de los impuestos para 
adaptarlo a sus necesidades (cosa que tampoco se puede hacer hoy).


Opiniones?


Opino lo mismo que tu: Que estaría bien rellenar el campo sequence de 
los impuestos para que aparecieran ordenados de más a menos importancia. 
Y es una ventaja para casi todo el mundo, por lo que no dudaría en hacerlo.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Eliminar impuestos antiguos del plan contable Español

[Jordi Esteve]

El 18/07/16 a les 13:06, Sergi Almacellas Abellana ha escrit:

Hola,

Hay bastantes impuestos en el plan contable español que ya no se 
aplican a dia de hoy. (Por ejemplo, iva 7%, iva 8%). Aunque tengan el 
campo  fecha de fin lleno, estos se están creando par los nuevas 
instalación, cosa que no es necessaria.


Si nadie tinene ningún inconveniente prodeciré a la eliminación de los 
mismos para que reducir el número de impuestos creados. 


Me parece muy bien, es una de esas cosas que tienes en el TODO y nunca 
encuentras el momento de hacerlas.


Creo que se podrían eliminar los impuestos de ventas

IVA 7%
IVA 8%
IVA 16%
IVA 18%

y lo mismo para los de compras, tanto operaciones corrientes como bienes 
de inversión.


Y todos los impuestos compuestos derivados de estos, pero esto ya se 
hará automáticamente con el script de generación de los XMLs a partir de 
CSVs.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Formato en plantilla de reportes

[Jordi Esteve (Zikzakmedia)]

El 23/06/16 a les 17:56, Fernando Sánchez ha escrit:

Saludos a la Comunidad Tryton en español.

Tengo una consulta respecto al uso de plantillas para la generacion de 
reportes.
Revisando el menu Administración/Interfaz de usuario/acciones/informes 
veo que es posible variar la plantilla en que se diseñan los reportes, 
desde Opendocument Text a Opendocument Spreadsheet, que no es otra 
cosa desde procesador de textos hacia hoja de calculo.


Mi consulta va por el lado de la analogía entre ambos entornos, en el 
opendocument text insertamos las etiquetas desde 
insert/fields/placeholder, como se hace esto desde calc, recorrí todas 
las opciones de menú y no encontré algo parecido, o se ingresan las 
etiquetas directamente a las celdas?
Alguien lo hizo alguna vez, agradecería que quien haya pasado esa 
experiencia la comparta.




Debes insertar un enlace con una URL que apunte a relatorio://

O sea, dentro de una celda de la hoja debes usar el menú Insertar/Enlace 
de libreoffice calc, y como destino poner, por ejemplo:


relatorio://for each="p in objects"

Si quieres editar uno que ya has creado, debes poner el cursor justo 
delante del enlace y volver a usar el menú Insertar/Enlace.


No sé si habrá otra forma más práctica de hacerlo.

Puedes hacer cosas curiosas como por ejemplo generar un fichero ods con 
una hoja distinta para cada registro a imprimir, para ello crea una hoja 
de calculo de 3 páginas,


en la primera pones el enlace relatorio://for each="p in objects"

en la segunda pones el contenido de la hoja

en la tercera pones el enlace relatorio:///for

así se repetirá la segunda hoja por cada registro a imprimir.

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Subdivisiones en la versión de desarrollo

[Jordi Esteve]

El 21/06/16 a les 16:54, Sergi Almacellas Abellana ha escrit:

El 21/06/16 a les 13:05, Àngel Àlvarez Serra ha escrit:


Para mi,

- Quitamos la restricción

Ya que he visto concenso en este punto lo he implementado:

https://bitbucket.org/trytonspain/trytond-country_zip_es/commits/11a7beae5e6c28066db3ca38b40216cc14445f49 


Bien





- Cambiamos el widget selection por un many2one para evitar problemas de
carga.


Lo he probado con la BD del módulo country, el país que tiene mas 
subdivisiones es Reino Unido y funciona sin problema.


Yo no pondría un campo en Many2One por coherencia con los otros campos 
del formulario que son de tipo selección y con el auto completado.


De acuerdo.




Yo creo que deberíamos mejorar el auto completado para que poniendo 
solo el código postal y el país te rellene toda la información.


Esto ya lo hace actualmente country_zip




Además, igual habría que mejorar el auto completado para que funcione 
cómo un on_change en caso de que solo haya un registro.


Además el país se puede rellenar por defecto, cumpliendo con la 
mayoria de los casos. Esto lo hacia el módulo party_country [1], que 
acabo de resucitar :)


No hace falta, ya puedes volver a matar y enterrar party_country de 
nuevo. Esto ya ho hace actualmente country_zip, añade un país por 
defecto en la configuración de terceros.






- Modificamos el recname para que se muestre todos los niveles.

Catalunya  > Barcelona


Entonces: sólo dejaríamos seleccionar el último nivel?



No, yo lo dejaría flexible, así las empresas pueden decidir si trabajan 
con comunidades o provincias. Si ponen comunidad verían Catalunya pero 
si ponen provincia se vea Catalunya/Barcelona. Creo que esta era la 
propuesta de Àngel.



--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Subdivisiones en la versión de desarrollo

[Jordi Esteve]

El 21/06/16 a les 13:05, Àngel Àlvarez Serra ha escrit:



2016-06-21 11:33 GMT+02:00 Jordi Esteve <mailto:jest...@zikzakmedia.com>>:


El 21/06/16 a les 11:07, Raimon Esteve ha escrit:

2016-06-21 10:58 GMT+02:00 Sergi Almacellas Abellana
mailto:se...@koolpi.com>>:

Buenos días,

En la versión de desarrollo de tryton se ha introducido un
commit [1], que
hace que solo se puedan seleccionar las subdivisiones de
primer nivel en las
direcciones.

Esto implica que en el caso de España, sólo se pueden
seleccionar las
comunidades autónomas, cuando hasta ahora se esta poniendo
la provincia

Aquí hay dos soluciones:

1. Añadir un nuevo campo que nos permita seleccionar la
provincia (y forzar
que esta sea hija de la subdivisión). Esto implicaría
además, corregir los
datos existentes en la base de datos.
2. Quitar la restricción en un un módulo nuevo (o alguno
ya existente cómo
el country_zip_es)

Opiniones al respecto?

Me quedo con la segunda opción, pues es más común seleccionar
"Barcelona" como província (o Lleida ;) ), que "Catalunya".
La primera opción, son más campos, más edición por parte
usuario, etc.

Sobre la segunda opción:

O bien, cambiamos lo mismo que han propuesto, pero que se
seleccione
el según nivel: la provincia.
O bien, en party.configuration, un campo selection que permita la
configuración, si se desea comunidad autónoma, o bien,
provincia, o
bien

Si, yo lo haría en el country_zip_es


+1


Para mi,

- Quitamos la restricción
- Cambiamos el widget selection por un many2one para evitar problemas 
de carga.

- Modificamos el recname para que se muestre todos los niveles.

Catalunya  > Barcelona



+1 a los 3 comentarios d'Àngel de la 2a propuesta de Sergi.

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Subdivisiones en la versión de desarrollo

[Jordi Esteve]

El 21/06/16 a les 11:07, Raimon Esteve ha escrit:

2016-06-21 10:58 GMT+02:00 Sergi Almacellas Abellana :

Buenos días,

En la versión de desarrollo de tryton se ha introducido un commit [1], que
hace que solo se puedan seleccionar las subdivisiones de primer nivel en las
direcciones.

Esto implica que en el caso de España, sólo se pueden seleccionar las
comunidades autónomas, cuando hasta ahora se esta poniendo la provincia

Aquí hay dos soluciones:

1. Añadir un nuevo campo que nos permita seleccionar la provincia (y forzar
que esta sea hija de la subdivisión). Esto implicaría además, corregir los
datos existentes en la base de datos.
2. Quitar la restricción en un un módulo nuevo (o alguno ya existente cómo
el country_zip_es)

Opiniones al respecto?

Me quedo con la segunda opción, pues es más común seleccionar
"Barcelona" como província (o Lleida ;) ), que "Catalunya".
La primera opción, son más campos, más edición por parte usuario, etc.

Sobre la segunda opción:

O bien, cambiamos lo mismo que han propuesto, pero que se seleccione
el según nivel: la provincia.
O bien, en party.configuration, un campo selection que permita la
configuración, si se desea comunidad autónoma, o bien, provincia, o
bien

Si, yo lo haría en el country_zip_es


+1

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Fecha contabilización

[Jordi Esteve]

El 14/06/16 a les 16:08, Albert Cervera i Areny ha escrit:
En las facturas tenemos el campo "Fecha contabilización" que, en caso 
de rellenarse, se utiliza como valor para la "Fecha efectiva" del 
asiento contable correspondiente.


El problema es que el asiento ya tiene un campo "Fecha 
contabilización" pero que indica la fecha en la que se creó el asiento.


Esto presta a confusión porqué el usuario asume que el concepto de 
"Fecha contabilización" de la factura es el mismo que el del asiento.


Propongo cambiar la traducción del campo "Fecha contabilización" a 
"Fecha efectiva contabilización" en las facturas para que sea más 
entendedor.


¿Como lo véis? ¿Otras propuestas?

PD: Haré lo mismo en Catalán.


Bien hacer el cambio para evitar confusiones.

Quedaría aún más claro traducirlo por "Fecha efectiva asiento" (Data 
efectiva assentament).


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Traducción noticias versión 4.0

[Jordi Esteve (Zikzakmedia)]

El 11/05/16 a les 20:27, Raimon Esteve ha escrit:

2016-05-11 18:04 GMT+02:00 Sergi Almacellas Abellana :

Hola,

He subido a un review con la traducción de las noticias de la release 4.0:

https://tryton-rietveld.appspot.com/23081002

No esta acabado, però se puede ir revisando.

en la versión CA veo algunas faltas. He empezado la propuesta
mejor antes pasarlo por un corrector, alias, Jordi? ;)

Raimon


Si, hoy miraré y haré correcciones en ambas versiones de las dos últimas 
noticias de tryton.org.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Crear sugerencias en pootle

[Jordi Esteve (Zikzakmedia)]

El 18/04/16 a les 11:07, Sergi Almacellas Abellana ha escrit:

El 15/04/16 a les 22:53, Jordi Esteve ha escrit:


Que extraño, creía que por defecto todo el mundo podía hacer sugerencia
para el idioma castellano (de España). Sergi, te acabo de dar permisos
para hacer sugerencias, revisar sugerencias y hacer traducciones
directamente para el idioma castellano (de España), a ver si ahora 
puedes.



Pues ahora tampoco puedo, me sale exactmente lo mismo :$


Pues no se me ocurre que problema puede haber.

Creo que todo el mundo puede hacer sugerencias para el idioma castellano 
(de España). ¿Puede probarlo y confirmarlo otro usuario? Si es así creo 
que el problema sería de tu usuario, algo similar le pasó a Óscar 
Álvarez con el castellano de Colombia y Cedric tuvo que hacer un reset o 
algo parecido.





Están todas hechas, supongo que querrás revisar alguna.
Si, hice un cambio en el catalán que ya veo que has replicado en el 
castellano. Genial!!!


Si, siempre miro de sincronizar las mejoras en las traducciones de los 
dos idiomas, como tu no pudiste lo he hecho yo.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Crear sugerencias en pootle

[Jordi Esteve]

El 15/04/16 a les 14:34, Sergi Almacellas Abellana ha escrit:

Hola,

A ver si alguien me puede hechar una mano. Por lo que veo, en 
pootle.tryton.org solo tengo permisos para trabajar con el idoma 
catalan, pero no puedo hacer sugerencias para el Idioma castellano.


Alguien me puede habilitar dichos permisos?

Alguien mas tiene el mismo problema?


Que extraño, creía que por defecto todo el mundo podía hacer sugerencia 
para el idioma castellano (de España). Sergi, te acabo de dar permisos 
para hacer sugerencias, revisar sugerencias y hacer traducciones 
directamente para el idioma castellano (de España), a ver si ahora puedes.


Están todas hechas, supongo que querrás revisar alguna.

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Re: Cuenta Corriente ?

[Jordi Esteve]

El 01/04/16 a les 16:13, Fernando Sánchez ha escrit:

Estimado Jordi

He leído tu respuesta y observo que usas 2 términos que me gustaría 
conceptualices para mejor entendimiento. Bueno, aquí en peru solo 
usamos uno de ellos y para efectos prácticos me gustaría definas esos 
términos en el contexto en que los usas.


Asiento: para nosotros es el reflejo contable de una transacción donde 
intervienen las cuentas afectadas y los montos (entre otros datos) en 
el debe y haber usando el principio de la partida doble y con balance 0.


Apunte: Es lo que no tengo claro a que le llaman apunte en españa, 
deduzco que sera una "linea" del asiento. Dime si estoy acertado o 
corrige por favor.




Si, efectivamente, los apuntes son las líneas del asiento.

Asiento, en inglés account move.

Apunte, en inglés account move line.

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Re: Cuenta Corriente ?

[Jordi Esteve]

El 31/03/16 a les 23:15, Lucas Riccombene ha escrit:

Alguien sabe como manejar fecha de vencimientos de pagos?


Los pagos y cobros son apuntes contables de cuenta a pagar o cobrar, y 
tienen rellanado el campo Fecha de vencimiento. Estos se calculan 
automáticamente al contabilizar una factura, según la fecha de la 
factura y el plazo de pago de la misma. Pero una vez contabilizada la 
factura, puedes editar el asiento de la factura y cambiar la fecha de 
vencimiento de sus apuntes a pagar o a cobrar.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] EXPRESION SALE_SHOP EN BABI

[Jordi Esteve (Zikzakmedia)]

El 30/03/16 a les 17:39, Luis Deiana ha escrit:
Buenos días, podrían ayudarme a crear una expresión en babi de la 
tienda en la que se facturo? el modelo seria: "Linea de Factura" y el 
campo a mostrar: "nombre de la tienda".

Saludos.


Tienes que ir saltando de campo, línea -> venta -> tienda -> nombre 
tienda. De memoria sería así:


sale.shop.name

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Re: BABI (Year - Product Category - Product)

[Jordi Esteve]

El 18/03/16 a les 14:26, Luis Deiana ha escrit:



El miércoles, 16 de marzo de 2016, 18:18:44 (UTC-3), Luis Deiana 
escribió:


BUENAS TARDES, ESTUVE PROBANDO EL INFORME "Year - Product Category
- Product" DEL MODELO "Linea de Factura" Y ME ENCONTRÉ CON ALGUNOS
ERRORES (SEGÚN ENTIENDO):

1 - EL INFORME TIENE UN FILTRO (Posted/Paid Customer
Invoices/Credit Notes) QUE CREO INDICA QUE NO TIENE EN CUENTA LAS
LINEAS DE FACTURA PERTENECIENTES A NOTAS DE CRÉDITO,



No, todo el contrario. El filtro "Posted/Paid Customer Invoices/Credit 
Notes" que proporciona el módulo babi_report_account_invoice tiene el 
dominio


[["state", "in", ["posted", "paid"]], ["type", "in", ["out_invoice", 
"out_credit_note"]]]


por tanto filtra todas las facturas y notas de crédito (abonos) de 
cliente contabilizadas o pagadas.




SIN EMBARGO AL HACER UNA DEVOLUCIÓN DE UN PRODUCTO CON TPV Y
ACTUALIZAR EL INFORME PASO DE CANTIDAD 2  A CANTIDAD 3 DESPUÉS DE
LA DEVOLUCIÓN. TAMBIÉN SE INCREMENTO EL SUBTOTAL.



Si usas la expresión "Base imponible factura" definida como

o.invoice.untaxed_amount if o.invoice.type in ('out_invoice', 
'in_credit_note') else -o.invoice.untaxed_amount


debería hacerlo bien, pues tienen en cuenta de sumar o restar la base 
según sea factura o nota de crédito.





2 -  AL SACAR EL FILTRO SE INCREMENTA LA CANTIDAD A 5, QUE TAMPOCO
SE DE DONDE PROVIENE ESE NUMERO. PERO SE QUE HUBO UNA COMPRA DE 2
UNIDADES Y SEGÚN ENTIENDO SOLO DEBERÍA TOMARME LAS VENTAS Y NO LAS
COMPRAS.



Me hablas de ventas y compras, supongo que te refieres a facturas de 
cliente y de proveedores, que son modelos distintos. Si sacas el filtro, 
en lugar de tener en cuenta sólo las facturas y notas de crédito 
(abonos) de cliente contabilizadas o pagadas, tendrá en cuenta todas las 
facturas y notas de crédito, de cliente y de proveedor, y que estén en 
cualquier estado.





3 - CUANDO ABRO UN INFORME NO COMO ARBOL, SINO CON LA OTRA VISTA (CREO 
QUE SERIA FORMULARIO) SOLO ME MUESTRA 1000 REGISTROS.




Sergi ya te respondió.

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Lector de Codigo de barras en Tryton 3.4

[Jordi Esteve (Zikzakmedia)]

El 15/03/16 a les 21:31, Fabyc ha escrit:

Hola.

On Thursday, January 28, 2016 at 5:04:38 PM UTC-5, Jordi Esteve 
(Zikzakmedia) wrote:


Hola Fernando,

El 28/01/16 a les 14:45, Fernando Sánchez ha escrit:
> Estimada comunidad,
>
> Reciban mi saludo cordial, a la vez tengo una consulta respecto
al uso
> de lector de código de barras con tryton 3.4.
>
> Sucede que estamos usando un lector de códigos Argox AS8000 y al
> registrar los códigos en el formulario de plantillas de
productos, nos
> posicionamos en el campo de código (sección variantes) ,
disparamos el
> lector y el código del producto aparece en el campo. Hasta ahí
perfecto.
>
> Tuvimos dificultad al usar el mismo lector para recibir
productos en
> almacén, en el formulario de recepción de productos desde el
proveedor
> (pienso que debe ser igual en el de envíos a clientes), al
agregar una
> nueva linea nos muestra el formulario respectivo, dentro de
ellos el
> campo producto. Posicionamos el cursor en este campo y al leer el
> código de barras, este aparece y en una fracción de segundo
> desaparece. Siendo este un producto cuyo código ya esta
registrado en
> la base de datos.
> Pienso que tiene que ver con la funcionalidad asociada al campo,
que
> es uno de busqueda.
>
> A ver si alguien vivió esta situación y me da alguna luz para poder
> resolver el problema.

Seguramente será que el cliente Gtk de Tryton por defecto no
autocompleta los campos m2o y m2m cuando la búsqueda obtiene un único
resultado.

Nosotros modificamos ligeramente el cliente Gtk de Tryton para que lo
hiciera, prueba de descargarte el que hay disponible aquí

http://www.zzsaas.com/es/descarga-tryton.html
<http://www.zzsaas.com/es/descarga-tryton.html>


¿Habrá algún repositorio de donde descargar el código fuente de los 
parches
aplicados para el soporte de la fuincionalidad en mención y/o algunas 
otras

más necesarias para la utilización en un super mercado?

Busqué en el repositorio de Zikzakmedia en Bitbucket pero no encuentro el
cliente modificado.



No, no está en bitbucket. Te mando adjunto el patch de "Autocomplete 
m2m, m2o and o2m when search restul is 1" para v3.8, pero es 
prácticamente el mismo para otras versiones.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

# HG changeset patch
# User resteve 
# Date 1447629341 -3600
#  Mon Nov 16 00:15:41 2015 +0100
# Branch zz3.8
# Node ID f336e6457599e83752979cc46e3f417235b5986a
# Parent  347f9902b024955d14614a062bc0433bd96d9dea
Autocomplete m2m and o2m when search result is 1

diff -r 347f9902b024 -r f336e6457599 tryton/gui/window/view_form/view/form_gtk/many2many.py
--- a/tryton/gui/window/view_form/view/form_gtk/many2many.py	Tue Sep 29 12:59:17 2015 +0200
+++ b/tryton/gui/window/view_form/view/form_gtk/many2many.py	Mon Nov 16 00:15:41 2015 +0100
@@ -11,6 +11,7 @@
 from tryton.common.placeholder_entry import PlaceholderEntry
 from tryton.common.completion import get_completion, update_completion
 from tryton.common.domain_parser import quote
+from tryton.common import RPCExecute, RPCException
 
 _ = gettext.gettext
 
@@ -43,6 +44,7 @@
 self.wid_text = PlaceholderEntry()
 self.wid_text.set_placeholder_text(_('Search'))
 self.wid_text.set_property('width_chars', 13)
+self.wid_text.connect('key_press_event', self.on_keypress)
 self.wid_text.connect('focus-out-event', lambda *a: self._focus_out())
 self.focus_out = True
 hbox.pack_start(self.wid_text, expand=True, fill=True)
@@ -145,6 +147,20 @@
 
 self.focus_out = False
 
+domain2 = [('rec_name', 'ilike', '%' + value + '%'), domain]
+try:
+ids = RPCExecute('model', self.attrs['relation'], 'search',
+domain2, 0, 2, None, context=context)
+except RPCException:
+ids = []
+if len(ids) == 1:
+self.focus_out = True
+self.screen.load(ids, modified=True)
+self.screen.display(res_id=ids[0])
+self.screen.set_cursor()
+self.wid_text.set_text('')
+return
+
 def callback(result):
 self.focus_out = True
 if result:
diff -r 347f9902b024 -r f336e6457599 tryton/gui/window/view_form/view/form_gtk/one2many.py
--- a/tryton/gui/window/view_form/view/form_gtk/one2many.py	Tue Sep 29 12:59:17 2015 +0200
+++ b/tryton/gui/window/view_form/view/form_gtk/one2many.py	Mon Nov 16 00:15:41 2015 +0100
@@ -12,6 +12,7 @@
 from tryton.common.placeholder_entry import Place

Re: [tryton-es] EXPRESION EN BABI

[Jordi Esteve (Zikzakmedia)]

El 16/03/16 a les 09:04, Sergi Almacellas Abellana ha escrit:

El 16/03/16 a les 00:30, Luis Deiana ha escrit:



El sábado, 12 de marzo de 2016, 13:31:14 (UTC-3), Sergi Almacellas
Abellana escribió:

El 12/03/16 a les 15:18, Luis Deiana ha escrit:
 > Hola, me podria alguien ayudar a crear una expresion de "Party
Category"
 > para usarla como dimension en BABI . Gracias

Depende desde que modelo lo vas a utilizar, que campos quieres 
mostrar

de las categorias (el nombre, el id), si quieres mostrar la primera
categoria o todas...

Si defines un poco mejor la pregunta, quizás te podamos dar una 
mejor

respuesta.

Hola Sergio

Mi nombre es Sergi ;)
y gracias por la respuesta,el modelo seria :"Linea de

Factura", el campo a mostrar seria:"el nombre", en principio necesito la
primera categoría y si no es mucha molestia me gustaría también saber
como hacerlo con todas las categorías. Gracias.



Para la primera categoria:

o.invoice.party.categories[0].name

Para todos las categorias (separadas por comas):

','.join([c.name for c in o.invoice.party.categories])



Quizás la primera expresión que calcula la primera categoría del tercero 
se debería afinar, pues si uno de los terceros que aparece en el informe 
no tiene ninguna categoría te va a dar un error cuando calcules el 
informe. Mejor poner algo así en la expresión:


o.invoice.party.categories and o.invoice.party.categories[0].name or ''

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Compra a un proveedor extracomunitario

[Jordi Esteve (Zikzakmedia)]

El 14/03/16 a les 16:18, Guillem Barba Domingo ha escrit:



El 14 mar. 2016 10:10, "Jaume I" <mailto:reienja...@gmail.com>> escribió:

>
> El tratamiento del arancel es asimilado a mayor valor de compra del 
producto. Se calcula a partir de un porcentaje (publicado en unas 
tablas por el Ministerio de Hacienda) aplicado al valor estadístico de 
la mercancía. No me extenderé sobre el valor estadístico, solo decirte 
que no es sencillo calcularlo para los profanos (yo soy uno de ellos) 
y se basa en el precio del producto más los gastos de transporte y de 
seguro entre los puntos de origen y destino.

>
> En resumen, que del aranel no se puede extraer el IVA, puesto que 
este impuesto se calcula a partir de la Base Imponible (y no del p... 
valor estadístico)

>
> Sin embargo, para el arancel sigo pensando que es una buena solución 
"inventarse" un producto que podriamos llamar "arancel aplicado al 
producto tal" que tuviera un tratamiento SIN impuesto (o exento).
> Y para el IVA soportado, en mi humilde opinión, la mejor solución 
sería crear una regla de impuesto que, a la hora de aplicarla, nos 
permitiera señalar como base imponible un importe que sólo aparecería 
a la hora de consultar el Plan de códigos de impuestos (esta base 
imponible no aparecería en la factura ni en el asiento contable). Si 
además, "apuntara" o relacionase la factura del transitario con la del 
proveedor ya sería orgásmico.

>
> El cómo hacerlo, eso es lo que no sé.

Creo que podrias símplemente añadir una línea en la tabla de impuestos 
de la factura, marcando el checkbos "manual".
Lo que ahora no te sé decir si esto creará las líneas de impuesto que 
se usan para generar los informes


Si, sería una opción, introducir manualmente una línea de impuestos de 
la factura, pero es muy artesanal y hay que acertar de poner el código 
de impuesto y los signos correctos.


A mi me parece mejor la opción de crear dos tipos de productos de tipo 
servicio, pero los asignaría impuestos diferentes:


1) Producto Arancel, asociado a cuenta *[600] Arancel cobrado por los 
servicios aduaneros* y con impuesto *IVA soportada exento (operaciones 
corrientes)*


2) Producto IVA cobrado servicio aduanero, asociado a cuenta *[472] IVA 
cobrado por los servicios aduaneros* y con impuesto *IVA aduanero* que 
se debería crear y que no tendría códigos de impuesto por la base, sólo 
códigos de impuesto por la cuota, que sería del 100%, así sólo 
reflejaría el 100% de su valor en un código de impuesto de la cuota (se 
podría usar el código *IVA.IBC.C - Cuotas devengadas importaciones 
Bienes corrientes*)


Así, si en la primera factura habías asignado el impuesto *IVA 0% 
Importaciones Bienes corrientes* que anota toda la base al código 
*B.IVA.IBC.C - Base importaciones Bienes corrientes*, quedaría bien 
reflejado el árbol de códigos de impuesto , tanto la base como la cuota, 
pero cada uno de ellos en facturas separadas.


El único inconveniente es que la base y la cuota, al ponerse en facturas 
separadas, podría ser que uno no fuera exactamente el 21% del otro por 
algún error del usuario, pero es inevitable, y la opción artesanal de 
introducir manualmente una línea de impuestos de la factura tb le 
pasaría lo mismo.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Asientos Contables

[Jordi Esteve]

Hola Fernando,

El 11/03/16 a les 05:22, Fernando Sánchez ha escrit:

Hola comunidad

Aqui les comento una situación que encontramos al explorar la 
funcionalidad contable.
No soy contador y podria ser algo fuera de lugar lo que escriba pero 
es mi opinión y espero otras opiniones.
Observamos que al facturar medicamentos (pueden ser cualquier otros 
productos de la misma familia), con mas de una linea o producto el 
sistema genera un asiento para cada linea, a mi parecer, si ambas 
lineas son por ejemplo de medicinas, usan la misma cuenta de ventas, 
deberia haber un solo asiento con la suma de ambos importes en lugar 
de un asiento por cada linea.


Es esto una caracteristica de tryton y debe aceptarse tal cual? o hay 
alguna configuracion que hacer para lograr que se totalicen los 
asientos que afecten la misma  cuenta.




Esto es una característica del módulo oficial account_invoice de tryton. 
Al contabilizar una factura crea un asiento con un apunte (línea) por 
cada línea de la factura, más los apuntes de los impuestos más los 
apuntes a pagar/cobrar del proveedor/cliente.


Lo que tu propones es válido a nivel contable, se podría desarrollar una 
mejora en un módulo nuevo que permitiera indicar si los asientos creados 
a partir de una factura se agrupen los apuntes de gastos/ingresos que 
sean de la misma cuenta. Fíjate que el problema estaría en que 
Descripción se pone a este apunte agrupado, ahora se pone la descripción 
de la línea de la factura, pero si se agrupan habría que poner un texto 
genérico o vacío.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] manera hay manera de importar lista de precios detalladas por producto con su formula

[Jordi Esteve]

El 02/03/16 a les 16:57, Lucas Riccombene ha escrit:
Hola Comunidad estoy trabajando con tryton 3.4 utilizando el modulo 
lista de precios y no puedo importar las lista de precios que exporte 
de tryton.

agrego imagen con la lista de precios, el .csv genero tryton .
Paso que realizo
1 exporta de tryton las columnas (nombre, producto/nombre, formula)
2 guardo la exportacion
3 importo y no me detecta las columnas y si las selecciono a mano me 
genera un error


Consulta hay manera hay manera de importar lista de precios detalladas 
por producto con su formula




Yo diría que a la tercera columna le sobra la palabra Código, pues esa 
columna debe ser Producto a secas, las líneas de tarifa tienen el campo 
Producto (tryton ya te buscará el producto a partir del código o del 
nombre o de lo que sea). O sea:


Nombre,Líneas/Fórmula,Producto
lista 1,product.cost_price * 2.2,19889
,product.cost_price * 2.2,92064
lista 2,product.cost_price * 2.0,92064




--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Lista de precios

[Jordi Esteve]

El 17/02/16 a les 17:33, Carlos Eduardo Sotelo Pinto ha escrit:

Estimada comunidad

he estado revisando el modulo product_price_list, pero aun no 
encuentro la forma correcta del uso o como este impacta en los precios 
al momento de generar una factura


¿Alguna experiencia el respeto?


Con el módulo product_price_list sólo podrás definir tarifas. Deberás 
instalar el módulo sale_price_list para que las tarifas sean asignadas y 
aplicadas en las ventas.


Y si creas directamente facturas en lugar de usar ventas, deberás 
instalar el módulo no oficial account_invoice_price_list que por ejemplo 
encontrarás en


http://bitbucket.org/trytonspain/trytond-account_invoice_price_list

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Re: Jornadas Estatales Tryton en Barcelona

[Jordi Esteve (Zikzakmedia)]

El 12/02/16 a les 22:31, Lucas Riccombene ha escrit:

Hola para participar en las charlas como seria. Cuente con mi presencia.
En mi caso solo hablo es Castellano (Argentina).


No hay problema, las comunicaciones serán en castellano o en catalán, 
pero prácticamente todo el público entiende ambos idiomas.


El Mobile World Centre (mírate el enlace que ha enviado Albert) se 
encuentra en el punto más céntrico de Barcelona, en Plaça Catalunya


https://www.google.es/maps/place/Carrer+de+Fontanella,+2,+08002+Barcelona/@41.443311,2.0959179,12z/data=!3m1!4b1!4m2!3m1!1s0x12a4a2f1223c2867:0x1a7fcd766587654?hl=en

Jordi


Para los argentinos que tengan ganas de ir dejo mi correo 
lu...@slmacoop.com.ar


S.L.A.M. "Software libre autogestinado metropolitano"
www.slamcoop.com.ar




El miércoles, 10 de febrero de 2016, 21:15:10 (UTC-3), Albert Cervera 
i Areny escribió:


Hola a todos,
tengo el placer de comunicaros que los próximos días 23 y 24 de mayo
celebraremos en Barcelona las primeras Jornadas Tryton de la
comunidad
Española.

Ya de entrada las jornadas cuentan con la colaboración de 5 empresas:

- DataLife [1]
- NaN-tic [2]
- Onneo [3]
- Thymbra [4]
- Zikzakmedia [5]

pero realmente esperamos que os apuntéis muchos más! Podéis enviarme
un correo en privado los que querráis.

Además tenemos la suerte de contar con la colaboración del Mobile
World Centre [6], que nos acojeará en un lugar excelente en el centro
de Barcelona. Y lógicamente con una excelente conectividad.

En breve enviaremos el enlace para empezar a inscribiros pero de
momento podéis empezar a reservaros las fechas. Como véis, lo hemos
organizado a principios de semana para los que queráis podáis
aprovechar el fin de semana anterior para visitar la ciudad.

En próximas comunicaciones también explicaremos cómo podéis hacer
vuestras propuestas de charlas.

¡Un saludo!

[1] http://www.datalife.com.es
[2] http://www.nan-tic.com
[3] http://www.onneo.net
[4] http://www.thymbra.com
[5] http://www.zikzakmedia.com
[6] https://www.mobileworldcentre.com/
<https://www.mobileworldcentre.com/>

PD: Mobile World Centre es una iniciativa público-privada creada por
Mobile World Capital Barcelona (MWCB) y Telefónica con el objetivo de
acercar a la ciudadanía el mundo de la telefonía móvil y de Internet.
Es un espacio para descubrir cómo la transformación mobile está
revolucionando las vías de comunicación, nuestro día a día o el
entorno social y empresarial. El Centre es un espacio abierto a los
ciudadanos que acoge una exposición permanente y ofrece una agenda de
actividades vinculadas a la actualidad y a proyectos centrados en la
transformación social, cultural, tecnológica y económica de la
movilidad. Mobile World Centre es también un punto de información y
difusión del resto de iniciativas de MWCB.

www.mobileworldcapital.com <http://www.mobileworldcapital.com>
www.movistar.com <http://www.movistar.com>

-- 
Albert Cervera i Areny

http://www.NaN-tic.com
    Tel. 93 553 18 03




--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Inventario Incial - Inicio de Operaciones con Tryton

[Jordi Esteve]

El 30/01/16 a les 15:20, Fernando Sánchez ha escrit:

Hola a todos,

Estoy revisando la forma de hacer la carga de inventario inicial para 
una empresa que inicia operaciones.
Revisando tryton 3.4, segun mis escasos conocimientos y tratando de 
deducir el camino correcto, se me ocurrio que esa carga inicial debe 
hacerse via Inventarios/crear inventarios, seleccionar ubicacion 
perdido y encontrado, ingresar todo el inventario inicial: codigo, 
cantidad, lote y guardar. Luego ir a movimientos internos y generar el 
movimiento desde perdido/encontrado hacia zona de almacenamiento.


Por favor diganme si es la secuencia correcta o se debe hacer de otra 
forma.


Vas bien, pero el último paso "ir a movimientos internos y generar el 
movimiento desde perdido/encontrado hacia zona de almacenamiento." no es 
necesario. Después de crear el inventario con sus líneas lo confirmas y 
ya se crearán automáticamente los movimientos desde la ubicación que 
regularizas hacia la ubicación especial "perdido y encontrado" o al revés.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Lector de Codigo de barras en Tryton 3.4

[Jordi Esteve]

El dia 30/01/2016 6.59, "Fernando Sánchez"  va
escriure:
>
> Hola Jordi
>
>
>
> El jueves, 28 de enero de 2016, 17:04:38 (UTC-5), Jordi Esteve
(Zikzakmedia) escribió:
>>
>> Hola Fernando,
>>
>> El 28/01/16 a les 14:45, Fernando Sánchez ha escrit:
>> > Estimada comunidad,
>> >
>> > Reciban mi saludo cordial, a la vez tengo una consulta respecto al uso
>> > de lector de código de barras con tryton 3.4.
>> >
>> > Sucede que estamos usando un lector de códigos Argox AS8000 y al
>> > registrar los códigos en el formulario de plantillas de productos, nos
>> > posicionamos en el campo de código (sección variantes) , disparamos el
>> > lector y el código del producto aparece en el campo. Hasta ahí
perfecto.
>> >
>> > Tuvimos dificultad al usar el mismo lector para recibir productos en
>> > almacén, en el formulario de recepción de productos desde el proveedor
>> > (pienso que debe ser igual en el de envíos a clientes), al agregar una
>> > nueva linea nos muestra el formulario respectivo, dentro de ellos el
>> > campo producto. Posicionamos el cursor en este campo y al leer el
>> > código de barras, este aparece y en una fracción de segundo
>> > desaparece. Siendo este un producto cuyo código ya esta registrado en
>> > la base de datos.
>> > Pienso que tiene que ver con la funcionalidad asociada al campo, que
>> > es uno de busqueda.
>> >
>> > A ver si alguien vivió esta situación y me da alguna luz para poder
>> > resolver el problema.
>>
>> Seguramente será que el cliente Gtk de Tryton por defecto no
>> autocompleta los campos m2o y m2m cuando la búsqueda obtiene un único
>> resultado.
>>
>> Nosotros modificamos ligeramente el cliente Gtk de Tryton para que lo
>> hiciera, prueba de descargarte el que hay disponible aquí
>>
>> http://www.zzsaas.com/es/descarga-tryton.html
>>
>> y lo pruebas.
>>
>> --
>> Jordi Esteve
>> Consultor Zikzakmedia SL
>> jes...@zikzakmedia.com
>> Mòbil 679 170 693
>>
>> Zikzakmedia SL
>> St. Jaume, 9, baixos, 2a
>> 08720 Vilafranca del Penedès
>> Tel 93 890 2108
>>
>
> Gracias por contestar, pero la modificación al cliente tryton que me
indicaste hace que cuando exista una sola opcion para seleccionar esta se
haga sin abrir la ventana de busqueda, es util y mejora la usabilidad.
>
> Pero lo que me sucede es otra cosa, tiene que ver con el lector de codigo
de barras, decia que cuando se usa sobre un campo de busqueda, el codigo se
ingresa y desaparece en una fracción de segundo. Mientras que cuando se usa
sobre un textbox sin funcionalidad de busqueda si funciona perfectamente.

Pero ,  ¿has probado la otra versión de cliente Gtk?

Me de la impresión q las dos cosas están relacionadas. Evidentemente tienes
que configurar la pistola para q al final añada un enter o tab.

Jordi

Re: [tryton-es] Lector de Codigo de barras en Tryton 3.4

[Jordi Esteve]

Hola Fernando,

El 28/01/16 a les 14:45, Fernando Sánchez ha escrit:

Estimada comunidad,

Reciban mi saludo cordial, a la vez tengo una consulta respecto al uso 
de lector de código de barras con tryton 3.4.


Sucede que estamos usando un lector de códigos Argox AS8000 y al 
registrar los códigos en el formulario de plantillas de productos, nos 
posicionamos en el campo de código (sección variantes) , disparamos el 
lector y el código del producto aparece en el campo. Hasta ahí perfecto.


Tuvimos dificultad al usar el mismo lector para recibir productos en 
almacén, en el formulario de recepción de productos desde el proveedor 
(pienso que debe ser igual en el de envíos a clientes), al agregar una 
nueva linea nos muestra el formulario respectivo, dentro de ellos el 
campo producto. Posicionamos el cursor en este campo y al leer el 
código de barras, este aparece y en una fracción de segundo 
desaparece. Siendo este un producto cuyo código ya esta registrado en 
la base de datos.
Pienso que tiene que ver con la funcionalidad asociada al campo, que 
es uno de busqueda.


A ver si alguien vivió esta situación y me da alguna luz para poder 
resolver el problema.


Seguramente será que el cliente Gtk de Tryton por defecto no 
autocompleta los campos m2o y m2m cuando la búsqueda obtiene un único 
resultado.


Nosotros modificamos ligeramente el cliente Gtk de Tryton para que lo 
hiciera, prueba de descargarte el que hay disponible aquí


http://www.zzsaas.com/es/descarga-tryton.html

y lo pruebas.

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Como ordenar los productos de una factura?

[Jordi Esteve]

El dia 06/01/2016 18.15, "Lucas Riccombene"  va
escriure:
>
> Hola a tod@s, estoy queriendo ordenar los productos de una factura y la
grilla actual no lo realiza alguna idea de como se puede realizar. Una
linea de investigación.

Estás ordenando las líneas de la factura arrastrandolas con el ratón y no
puedes?
El módulo oficial account_invoice ya lo permite. Creo recordar que el
cliente Gtk para Mac daba problemas en esto.

Jordi

Re: [tryton-es] Preguntas sobre cierre de ejercicio fiscal

[Jordi Esteve]

El 28/12/15 a les 23:33, Eduardo J de la Garza G ha escrit:

Buen día!

Revisé los pasos para realizar el cierre de ejercicio fiscal publicado 
en el blog de zikzakmedia pero tengo algunas dudas:


- ¿Se debe cerrar el ejercicio fiscal antes de abrir el nuevo?

No

- En su caaso, ¿se puede abrir el nuevo ejercicio fiscal y cerrar el 
anterior días después?

Si

- Si está abierto el nuevo ejercicio fiscal y se realizan facturas u 
otros movimientos dentro del nuevo periodo ¿afecta al cierre del 
ejercicio anterior o en alguna otra cosa?

No


- ¿Para qué se utiliza el módulo account move renumber?
Para renumerar los asientos contables. Esto sólo es necesario en países 
donde la normativa exige que todos los asientos contables tengan una 
numeración consecutiva (sin agujeros o saltos). Ten en cuenta que si 
tienes diarios contables con la opción "Permitir cancelar asientos" 
marcada, puedes pasar a borrador asientos contabilizados y luego 
eliminarlos, por lo que te pueden quedar agujeros o saltos en la numeración.



- Una vez cerrado el ejercicio fiscal ¿se puede volver a abrir para 
crear algún asiento y volverlo a cerrar?


Si.


si se hace esto ¿en qué afecta?
En principio en nada, excepto que los saldos iniciales del nuevo 
ejercicio cambiarán, como debería ser.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Traducción español (España) y català de v3.8 de tryton

[Jordi Esteve (Zikzakmedia)]

El 30/10/15 a les 10:52, Albert Cervera i Areny ha escrit:

2015-10-28 22:01 GMT+01:00 Jordi Esteve :

Hola,

Acabo de finalizar la traducción español (España) y català de v3.8 de tryton
en pootle.tryton.org. Eran sólo unos 1000 términos nuevos en cada idioma.

Gracias, Jordi.


Si queréis podéis echarle una ojeada y hacer alguna sugerencia.


He repasado los "OK" que en Catalán teníamos como "D'acord" en algunos
casos y "Accepta" en otros. Lo he dejado todo como "D'acord".


Ok, mejor dicho "D'acord" ;-)

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

[tryton-es] Traducción español (España) y català de v3.8 de tryton

[Jordi Esteve]

Hola,

Acabo de finalizar la traducción español (España) y català de v3.8 de 
tryton en pootle.tryton.org. Eran sólo unos 1000 términos nuevos en cada 
idioma.


Si queréis podéis echarle una ojeada y hacer alguna sugerencia.

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Duda en asignación de permisos botón assign_try

[Jordi Esteve (Zikzakmedia)]

El 15/10/15 a les 00:07, Luis Martinez ha escrit:

Buenas tardes,

Estoy creando nuevos grupos y asignando los permisos correspondientes 
en los modelos, campos y menú, sin embargo me topé con que el botón de 
assign_try para envío de devolución a proveedor, envío interno y envío 
a cliente a pesar de asignarle el grupo correspondiente no me aparece 
habilitado para ningún usuario perteneciente al grupo.   Lo estoy 
haciendo desde la interface gráfica Administración -> Modelos -> 
Acceso a modelos -> Botones.


Me ha funcionado bien para todos los demás botones incluso de esos 
mismos modelos a excepción del que menciono.


Alguna sugerencia?

Gracias de antemano,


Seguramente es debido a que este botón está readonly si los usuarios no 
pertenecen al grupo "group_stock", pues está definido así dentro del 
mismo código, mírate cualquier tipo de albarán en el fichero shipment.py 
del módulo stock:


'assign_wizard': {
'invisible': Eval('state') != 'waiting',
'readonly': ~Eval('groups', []).contains(
        Id('stock', 'group_stock')),
},

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Boton para abrir una vista especifica de un modelo u otro

[Jordi Esteve (Zikzakmedia)]

El 28/09/15 a les 13:40, Antonio Roncero ha escrit:



El lunes, 28 de septiembre de 2015, 12:10:06 (UTC+1), Jesús Martín 
Jiménez escribió:




El 28 de septiembre de 2015, 12:57, Antonio Roncero
> escribió:



El lunes, 28 de septiembre de 2015, 11:28:02 (UTC+1), Jesús
Martín Jiménez escribió:

Hola Antonio,

El 28 de septiembre de 2015, 12:24, Antonio Roncero
 escribió:



El lunes, 28 de septiembre de 2015, 10:55:38 (UTC+1),
Jesús Martín Jiménez escribió:

Hola Antonio,

El 28 de septiembre de 2015, 11:22, Antonio
Roncero  escribió:

Buenos dias,

tengo un modelo (A) que tienes varios campos
que relacionan con otros modelos(B,C,D...). En
cada registro de A solo puede estar relleno
uno de ellos, es decir, que si la relacion con
el modelo C esta rellena, con D y B no. Es la
unica manera que se me ha ocurrido para hacer
"relaciones dinamicas" con otros modelos.


También podrías utilizar un campo reference [1]


Gracias, creo que puede ser una manera mas correcta. ;)

He visto que se usa en invoice para definir el origen
de la linea, pero no encuentro donde se define en la
vista. ¿algun ejemplo donde pueda ver como se comporta?


Mira en Administración > Modelos > Adjuntos.


Gracias. He visto que se representa como la cadena que
almacena "modelo,id". ¿Existe algun widget (el "refenrece" es
el que actua por defecto) que pueda usarse para abrir el
registro asociado?


En la vista de formulario que te indico está.


Ese es el que estoy mirando. En modo formulario, efectivamente cuando 
le doy al id de registro se abre, pero en modo arbol, se pone en modo 
edicion de la cadena. Los iconos para seleccionar, eliminar o ver el 
adjunto son del campo data (que abre, elimina.. el adjutno en si, no 
el registro). ¿Hay alguna manera de que se comporte en el modo arbol 
igual que en el modo formulario abriendo el registro?


Nunca he probado de poner un campo "reference" en una vista listado 
editable (la que tu llamas modo árbol). Puede que el widget del campo 
"reference" en una vista listado no esté pulido por eso se edita sólo la 
cadena, habría que mejorarlo.


También puedes usar un atajo, que es clicar con el botón derecho sobre 
una línea de la vista listado editable y seleccionar el campo 
"reference", opción editar, que se abrirá en una pestaña nueva.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] A pagar con mandato en account_payment_sepa_es

[Jordi Esteve (Zikzakmedia)]

El 16/09/15 a les 18:16, Albert Cervera i Areny ha escrit:

Hola,
el módulo account_payment_sepa_es añade un filtro en la pantalla de
apuntes contables para ver todos los que hay por cobrar y que tengan
mandato [1].

Entiendo que podemos eliminarlo puesto que no es necesario disponer de
un mandato para poder hacer una transferencia. Objeciones?

[1] 
https://bitbucket.org/trytonspain/trytond-account_payment_sepa_es/src/c927041b1e37c55af705df2c90bf1db9aea2a9e8/account.xml?at=default&fileviewer=file-view-default#account.xml-7



Era útil para filtrar los efectos que tenían mandato en caso de recibos 
domiciliados, en este caso si es necesario tener mandato. Pero no 
imprescindible, se pueden filtrar los efectos según el tipo de pago y 
crear un grupo de pagos (remesa) a partir de ellos, si alguno no tiene 
mandato dará error al generar el grupo de pagos.


En resumen, no tengo una posición clara. Tenerlo es algo útil, no 
tenerlo simplifica el código.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Actualizacion modulo IRPF 19,5%

[Jordi Esteve]

Hola Miriam,

El 28/08/15 a les 13:16, Miriam Aymerich ha escrit:

Gracias Sergi, ha funcionado.

El  problema que tengo ahora es que cuando actualizo el Plan Contable, 
algunas de las cuentas que habia creado anteriormente, me cambia la 
descripción y el código ( veo la original cuenta 7000 en vez dela 
que creé 70100). Veo que pasa con las cuentas que tienen el campo 
"template" informado.


En las cuentas creadas recientemente esto ya no pasa, me conserva la 
descripción y el codigo de mis cuentas ( veo que no tienen template 
informado en la base de datos).


Sabeis por que pasa? era un bug? puedo simplemente borrar el template 
de las cuentas que he creado yo  antes de actualizar el plan contable?


No, no es un bug. Si modificas una cuenta creada a partir de la 
plantilla, esta se actualiza cuando se actualiza el plan contable, pues 
es una cuenta básica del plan contable.


Si quieres modificar una cuenta, duplícala y le cambias el código y/o la 
descripción. Entonces una actualización del plan contable ya no le afecta.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

[tryton-es] Error en la definición de los impuestos de IVA inversión del sujeto pasivo.

[Jordi Esteve]

Hola,

Creo que los impuestos de IVA Inversión del sujeto pasivo de plan 
contable español están mal definidos. Este impuesto tiene 3 impuestos hijos:


1) Para anotar la base del impuesto en [61] - Inversión del sujeto pasivo
2) Para anotar las bases y cuotas en Régimen general IVA Devengado. Aquí 
se anota en negativo pero solo la base, el impuesto se anota en 
positivo. Esto me huele mal.
3) Para anotar las bases y cuotas en operacions interiores de bienes 
corrientes


Creo que el impuesto hijo 2) debería anotarse ambos en negativo. 
Actualmente está definido como -21% y el signo de la base -1 y el signo 
del impuesto -1, lo que provoca que se anote la base en negativo, pero 
el impuesto en positivo, dando un descuadre importante entre bases y 
cuotas cuando se liquidan los impuestos.


Creo que debería definirse como -21% y el signo de la base -1 y el signo 
del impuesto 1. Y a la inversa para las facturas de abono. ¿Alguien lo 
puede confirmar?


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] IVA Soportado bienes de inversion

[Jordi Esteve]

On 15/07/15 12:13, Miriam Aymerich wrote:

Hola,
Una duda: hay alguna forma  de parametrizar que TRYTON detecte que 
cuando contabilizas una factura de compra en las cuentas 2xxx de 
activo en vez de las cuentas 6xxx de gasto , le añada el IVA soportado 
de inversión en vez de IVA soportado de bienes corrienes, o es manual 
en cada factura?



Que yo sepa actualmente es manual.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Herencia en Tryton

[Jordi Esteve]

On 07/07/15 12:28, Antonio Roncero wrote:
Hola, sigo con mi iniciacion a la programacion. Ahora estoy con la 
herencia.


En openerp tenia 2 tipos de herencia

  * Herencia de clase: añadia campos que eran visibles en las vistas
de la clase original
  * Herencia por prototipo: Creaba una nueva clase copiando las
propiedades de la clase padre
  * Herencia polimorfica: permitia heredar de varias clases y creaba
una tabla nueva con la referencia al objeto de las clases
heredadas y los campos nuevos.

En tryton, por lo que me ha parecido leer, solo hay una, que según he 
entendido es una mezcla de las dos primeras de openerp, es decir añade 
campos a la tabla original pero no se ven en la vista a no ser que la 
creemos.



¿Como se podria tener herencia de los tipos dos? es decir, una que me 
cree un nuevo modelo (con su propio __name__) que herede los campos y 
metodos del padre. Y del tipo 3, es decir, una que me permita heredar 
de varias clases a la vez.




Los dos casos se pueden hacer usando la herencia de Python. Las 
herencias de Tryton son simplemente las herencias que te proporciona el 
propio lenguage python.


Por ejemplo mírate el módulo account_bank que permite añadir cuentas 
bancaris en facturas, apuntes contables, etc. Se define una clase base 
BankMixin (por convenio llevan la palabra Mixin al final) donde defines 
campos y métodos comunes y luego creas o amplias clases existentes a 
partir de este Mixin:


class Invoice(BankMixin):
class Line(BankMixin):
class CompensationMoveStart(ModelView, BankMixin):

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Valores por defecto en m2o

[Jordi Esteve (Zikzakmedia)]

El 06/07/15 a les 16:15, Francisco Maria Moyano Casco ha escrit:


Estimados.

Como hago para pasar valores por defecto cuando creo un nuevo registro 
a través de un Many2One. Por ejemplo, cuando hago un Many2One a 
product.template (tengo instalado además el modulo purchase), quiero 
que del campo type, que es de tipo selection, me seleccione "assets" 
de manera automática y por defecto.




Me parece que en v.3.4 y anteriores no se puede, pero en v.3.6 y 3.7 (la 
de desarrollo) si está implementado, pues creo recordar que se ha 
retocado el cliente de tryton.


Lo digo de memoria, quizás sea en la v 3.7 (la de desarrollo) donde se 
ha implementado.


Jordi



Se que en caso de campos booleanos, se hace


@classmethod
def check_xml_record(cls, records, values):
return True

Pero con otros campos hago aguas.

Justo el campo type tiene por defecto el valor "goods", así que 
mataría dos pajaros de un tiro con esta consulta



No se si se entiende la consulta.

Saludos, y muchas gracias.

Francisco




--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Re: Problema con conciliar cuentas

[Jordi Esteve (Zikzakmedia)]

El 06/07/15 a les 16:57, Antonio Roncero ha escrit:



El viernes, 3 de julio de 2015, 12:25:57 (UTC+1), Jordi Esteve 
(Zikzakmedia) escribió:


On 03/07/15 13:16, Antonio Roncero wrote:
>
> A ver si me estoy equivocando en el proceso...

Si, te equivocas en el proceso.

>
> Creo la factura, la confirmo, y como el cliente tiene mandato sepa,
> voy a efectos a pagar/cobrar-> a cobrar con mandato y ejecuto el
> wizard que me genera el fichero sepa. En mensajes sepa, lo paso a
> estado realizado.
>
> Las facturas me siguen apareciendo validadas a espera de pagar,
por lo
> que debo ejecutar el proceso de conciliación para asociar los
apuntes
> que haya generado el mandato sepa (que por cierto no se como
mirarlos,
> porque no veo por ningun lado el dario de cobro que he creado en
SEPA)
> con lo de las facturas.

Aquí es donde fallas. Cuando se genera un fichero SEPA no implica que
las facturas estén pagadas. Piensa que en un fichero SEPA se ordenan
pagos o cobros a fechas en el futuro. Hasta que no llegue las
fechas de
pago/cobro de cada recibo estos no se cobraran realmente. Por
tanto la
generación de ficheros SEPA no crea ningún asiento de pago ni tampoco
ninguna conciliación, es simplemente una orden que mandas al banco.

Contabilizarás los pagos/cobros cuando introduzcas els extracto del
banco y lo confirmes. Para ello puedes usar el módulo oficial
account_statement o los módulos account_bank_statement* que
encontraràs
en bitbucket que son más flexibles. Te recomiendo estos últimos
pues hay
módulos interesantes:

account_bank_statement_es_csb43
account_bank_statement_payment
account_bank_statement_payment_sepa


He instalado los modulos, y cuando intento importar un csb43 me da 
este error:


|
Error:'account.bank.statement'Modelhas noattribute 'lines':None
|

He mirado el modelo de account.bank.statement y el modelo si tiene el 
campo lines (one2may a account.bank.statement.line)... Ni idea :(


Yo tampoco tengo idea, sin saber en que línea falla y que fichero usaste 
para importar. Parece como si importara 0 líneas del extracto.


Deberías debugar para ver que pasa cuando falla, y detectar si realmente 
es problema del código del módulo o de tu instalación o fichero a importar.


Este módulo está muy testeado, ya tiene muchos meses de vida y está 
instalado en múltiples instalaciones importando ficheros CSB43 de 
distintos bancos.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Re: Problema con conciliar cuentas

[Jordi Esteve]

On 03/07/15 13:16, Antonio Roncero wrote:


A ver si me estoy equivocando en el proceso...


Si, te equivocas en el proceso.



Creo la factura, la confirmo, y como el cliente tiene mandato sepa, 
voy a efectos a pagar/cobrar-> a cobrar con mandato y ejecuto el 
wizard que me genera el fichero sepa. En mensajes sepa, lo paso a 
estado realizado.


Las facturas me siguen apareciendo validadas a espera de pagar, por lo 
que debo ejecutar el proceso de conciliación para asociar los apuntes 
que haya generado el mandato sepa (que por cierto no se como mirarlos, 
porque no veo por ningun lado el dario de cobro que he creado en SEPA) 
con lo de las facturas.


Aquí es donde fallas. Cuando se genera un fichero SEPA no implica que 
las facturas estén pagadas. Piensa que en un fichero SEPA se ordenan 
pagos o cobros a fechas en el futuro. Hasta que no llegue las fechas de 
pago/cobro de cada recibo estos no se cobraran realmente. Por tanto la 
generación de ficheros SEPA no crea ningún asiento de pago ni tampoco 
ninguna conciliación, es simplemente una orden que mandas al banco.


Contabilizarás los pagos/cobros cuando introduzcas els extracto del 
banco y lo confirmes. Para ello puedes usar el módulo oficial 
account_statement o los módulos account_bank_statement* que encontraràs 
en bitbucket que son más flexibles. Te recomiendo estos últimos pues hay 
módulos interesantes:


account_bank_statement_es_csb43
account_bank_statement_payment
account_bank_statement_payment_sepa

El primero para importar los extractos directamente de ficheros norma 
CSB 43, los otros dos para detectar que un pago/cobro de la línea de 
extracto corresponde a una remesa SEPA.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] analíticas en movimientos de inventario

[Jordi Esteve]

On 03/07/15 10:51, Guillem Barba Domingo wrote:
2015-07-02 15:59 GMT+02:00 Jordi Esteve <mailto:jest...@zikzakmedia.com>>:


On 02/07/15 15:18, Guillem Barba Domingo wrote:

2015-06-22 19:18 GMT+02:00 Eduardo J de la Garza G
mailto:ejdelagar...@gmail.com>>:

Gracias Guillem por tus comentarios, la opción para asociar
una cuenta analítica a cada depósito no me aparecía porque
tenía instalados tanto el módulo analyitic_stock, como el
analytic_account_warehouse. Cuando quité el
analytic_account_warehouse ya me de la opción y funciona.


ups! hay una incompatibilidad entre estos dos módulos porque
definen el mismo campo. Me lo apunto a ver si lo solucionamos...
algún día.

Ahora tengo otras preguntas: Al realizar un envío interno, el
módulo sí genera la línea de asiento analítica pero sin
asiento contable y eso provoca error cuando quiero abrir el
plan de cuentas analíticas ¿cómo puedo solucionar esto?


Te deben faltar los parches a los módulos de core.
Para que funcione el módulo analytic_line_state [1] (que es el
que permite tener apuntes analíticos sin apunte contable) se debe
tener el módulo analytic_account parcheado, pues no se aceptó
nuestra propuesta y se nos acabaron las energías y tiempo
disponible para intentar entrar el cambio.



Existe un módulo analytic_optional_move [1] que permite tener
apuntes analíticos sin apunte contable y sin necesidad de parchear
los módulos del core, aunque no se si será compatible con
analytic_line_state pq no lo he probado. Si fueran compatibles
sería más limpio que analytic_line_state dependiera de
analytic_optional_move.

[1] https://bitbucket.org/zikzakmedia/trytond-analytic_optional_move


me lo dejo pendiente de mirar bien pues nosotros materializábamos 
algun otro campo que no sólo la compañía pero tal vez no haría falta y 
sería mejor solución.


Solo un detalle, el nombre "company2" es un poco "feo" :-P sería mejor 
algo más explícito como "line_company" o "provisional_company"




Si, seguramente el día que lo hice no estaba muy inspirado. Si prefieres 
cambiarlo no hay problema.



--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] analíticas en movimientos de inventario

[Jordi Esteve]

On 02/07/15 15:18, Guillem Barba Domingo wrote:
2015-06-22 19:18 GMT+02:00 Eduardo J de la Garza G 
mailto:ejdelagar...@gmail.com>>:


Gracias Guillem por tus comentarios, la opción para asociar una
cuenta analítica a cada depósito no me aparecía porque tenía
instalados tanto el módulo analyitic_stock, como el
analytic_account_warehouse. Cuando quité el
analytic_account_warehouse ya me de la opción y funciona.


ups! hay una incompatibilidad entre estos dos módulos porque definen 
el mismo campo. Me lo apunto a ver si lo solucionamos... algún día.


Ahora tengo otras preguntas: Al realizar un envío interno, el
módulo sí genera la línea de asiento analítica pero sin asiento
contable y eso provoca error cuando quiero abrir el plan de
cuentas analíticas ¿cómo puedo solucionar esto?


Te deben faltar los parches a los módulos de core.
Para que funcione el módulo analytic_line_state [1] (que es el que 
permite tener apuntes analíticos sin apunte contable) se debe tener el 
módulo analytic_account parcheado, pues no se aceptó nuestra propuesta 
y se nos acabaron las energías y tiempo disponible para intentar 
entrar el cambio.




Existe un módulo analytic_optional_move [1] que permite tener apuntes 
analíticos sin apunte contable y sin necesidad de parchear los módulos 
del core, aunque no se si será compatible con analytic_line_state pq no 
lo he probado. Si fueran compatibles sería más limpio que 
analytic_line_state dependiera de analytic_optional_move.


[1] https://bitbucket.org/zikzakmedia/trytond-analytic_optional_move


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Modulo SEPA

[Jordi Esteve]

On 25/06/15 22:37, Antonio Roncero wrote:



El jueves, 25 de junio de 2015, 18:57:11 (UTC+1), Jordi Esteve 
(Zikzakmedia) escribió:


On 23/06/15 10:01, Antonio Roncero wrote:
> Hola,
>
> he conseguido generar un archivo xml con el modulo SEPA, pero mi
> querido banco sólo trabaja con el formato 19.34 de SEPA, es
decir, la
> version "texto plano". ¿Hay algun modulo que genere este tipo de
> archivos? o ¿conoceis algun conversor de xml a 19.34 para linux?
>

Que yo sepa el formato SEPA siempre es con ficheros XML.


Que va, por lo visto hasta enero de 2016 se permite transmision SEPA 
en formato texto y me imagino que es lo que muchos bancos han 
"parcheado" por rapidez mientra prepara el sistema en xml.


Aqui [1] puedes ver un pdf con la definicion (a partir de la pagina 14)


Por los números que indicas, 19.34, ¿no querrás decir que tu banco
trabaja con los antiguos cuadernos bancarios CSB19, CSB34 (tb hay
el 32
y 58 )? Son textos planos y son normas que en principio caducan el
próximo febrero 2016. En este caso debes usar algunos de estos
módulos
que encontrarás en bitbucket


En realidad me han bailado los numeros y es 19-44 (que es para B2B)


Pues no conocía 19-44. Que yo sepa no hay nada hecho y si tiene que ser 
provisional hasta enero 2016 no vale la pena hacerlo. Todos los bancos 
con los que trabajamos o trabajan nuestros clientes acceptan el formato 
SEPA xml desde febrero 2014 o incluso antes. Y los que no (que serán 
pocos y pequeños) por lo menos te deberían ofrecer alguna herramienta de 
transformación de ficheros.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Modulo SEPA

[Jordi Esteve]

On 23/06/15 10:01, Antonio Roncero wrote:

Hola,

he conseguido generar un archivo xml con el modulo SEPA, pero mi 
querido banco sólo trabaja con el formato 19.34 de SEPA, es decir, la 
version "texto plano". ¿Hay algun modulo que genere este tipo de 
archivos? o ¿conoceis algun conversor de xml a 19.34 para linux?




Que yo sepa el formato SEPA siempre es con ficheros XML.

Por los números que indicas, 19.34, ¿no querrás decir que tu banco 
trabaja con los antiguos cuadernos bancarios CSB19, CSB34 (tb hay el 32 
y 58 )? Son textos planos y son normas que en principio caducan el 
próximo febrero 2016. En este caso debes usar algunos de estos módulos 
que encontrarás en bitbucket


account_payment_es_csb_19
account_payment_es_csb_32
account_payment_es_csb_34
account_payment_es_csb_34_01
account_payment_es_csb_34_11
account_payment_es_csb_58

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] cobro por domicialicion SEPA

[Jordi Esteve (Zikzakmedia)]

El 19/06/15 a les 11:24, Antonio Roncero ha escrit:

Hola,

por fin he migrado la empresa de openerp a tryton y como voy avanzando 
me van surgiendo dudas. La de hoy:


Me gustaria cobrar unas facturas a traves fichero de domiciliacion, 
para lo cual he creado los mandatos sepa a los clientes con los que 
voy a probar (por cierto, creo que hay un fallillo minimo en los 
informes ya que tiene el texto fijo de devolución a 8 semanas y en 
caso de b2b son dos dias).
En efectos a cobrar con mandato me aparecen las facturas que he 
generado a esos clientes, pero no se como seguir. No veo por ningun 
lado la opcion de crear el fichero. Creo que tengo los modulos 
necesarios instalado pero obviamente me falta algo.


¿alguien me puede ayudar?


Desde los efectos tienes un asistente para crear los pagos (digamos que 
serían los recibos a cobrar o a pagar). Y desde los pagos tienes un 
asistente para crear los grupos de pagos (digamos que serían las remesas 
de recibos a cobrar o pagar). Según que módulos tengas instalados se 
pueden hacer estos dos pasos a la vez con un asistente que te crea 
directamente el grupo de pagos a partir de los efectos. Yo te recomiendo 
que al principio lo hagas paso a paso para comprobar que los pagos 
intermedios se crean correctamente, con la cuenta bancaria asociada.


Cuando tengas el grupo de pagos creado verás que tiene asociado un 
mensaje SEPA, es el fichero xml que debes enviar al banco.


Jordi

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Otra duda con el modulo de contratos (zikzak)

[Jordi Esteve]

On 11/06/15 12:00, Antonio Roncero wrote:



El jueves, 11 de junio de 2015, 10:02:50 (UTC+1), Sergi Almacellas 
Abellana escribió:


El 11/06/15 a les 10:56, Antonio Roncero ha escrit:
>
>
> El miércoles, 10 de junio de 2015, 11:37:29 (UTC+1), Jordi Esteve
> (Zikzakmedia) escribió:
>
> On 09/06/15 23:23, Albert Cervera i Areny wrote:
>  > 2015-06-09 21:24 GMT+02:00 Antonio Roncero  >:
>  >> Gracias, voy a probar las dos opciones, a ver cual me viene
> mejor. Yo mismo
>  >> iba a intentar modificar el comportamiento del modulo
(aunque
> aun estoy muy
>  >> verde).
>  >>
>  >> Como comentario, que no critica, es una pena ver tanto
esfuerzo
> duplicado.
>  >> Me imagino que es algo mas que comentado y no se si tiene
> solucion, pero
>  >> seria interesante encontrarla (no se si es parte de los
> objetivos de la
>  >> fundacion)
>  > No es esfuerzo duplicado, simplemente que para tener un
diseño
>  > adecuado hace falta darle bastantes vueltas a las cosas.
Zikzak hizo
>  > una primera versión, nosotros intentamos utilitzarla (lo
> utilizábamos
>  > nostros mismos hasta hace bien poco), hasta que nos
encontramos con
>  > las limitaciones que tu has visto y tubimos que
replantearlo de
> nuevo.
>  >
>  > Más que dos opciones que compiten simplemente creo que
una es la
>  > evolución de la otra.
>
> Cierto, aunque seguramente el contract de zikzakmedia tb
evolucione de
> forma independiente a como lo hace el de nantic. Tendrás que
tomar una
> decisión, tb la de hacer un tercer fork si lo consideras
oportuno.
>
>
> Estoy probando los dos y os comento mi opinion:
>
> El concepto de servicio en el de ZikZak está mejor planteado
como idea,
> al poder poner varios productos por servicio, pero creo que es
un error
> que las cantidades se definan aquí y no en el contrato en sí. Los
> servicios en el NaN para mi sobran al ser simplemente un enlace
1 a 1 a
> un producto. Se podria ahorrar ese paso
>
> En cambio el concepto de contrato de NaN me gusta mas a poder
> "personalizar" cada contrato y no creando servicios diferentes
segun la
> cantidad como se hace en el de ZikZak.
>
> Creo que hubiera sido ideal el modulo de NaN pudiendo añadir varios
> productos por servicio.

No entiendo cómo entendéis un servicio con varios productos.
¿Podéis poner algun ejemplo?


Seria para usarlo como "plantilla" de contrato, por ejemplo:

Servicio de Mantenimiento Integral:
   * Mantenimiento equipo informatico
   * Mantenimiento servidor
   * Mantenimiento impresora

Asi es el planteamiento de ZikZak, el problemas es cuando quieres 
"personalizar" el numero de equipos, servidores e impresoras... que 
tienes que crear practicamente un servicio por cliente


No necesariamente, las líneas de un servicio pueden tener una cantidad 
por defecto, pero luego se puede sobrescribir en el momento de hacer el 
cálculo de cada período. Como ya te comenté, la mejor opción es instalar 
el mòdul contract_formula [1] que permite definir una expresión Python 
para el cálculo de la cantidad del servicio. Por ejemplo que coja el 
valor de un campo especial definido en party.party, donde indicas para 
cada tercero su cantidad por defecto.


[1] http://bitbucket.org/zikzakmedia/trytond-contract_formula

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Otra duda con el modulo de contratos (zikzak)

[Jordi Esteve]

On 09/06/15 23:23, Albert Cervera i Areny wrote:

2015-06-09 21:24 GMT+02:00 Antonio Roncero :

Gracias, voy a probar las dos opciones, a ver cual me viene mejor. Yo mismo
iba a intentar modificar el comportamiento del modulo (aunque aun estoy muy
verde).

Como comentario, que no critica, es una pena ver tanto esfuerzo duplicado.
Me imagino que es algo mas que comentado y no se si tiene solucion, pero
seria interesante encontrarla (no se si es parte de los objetivos de la
fundacion)

No es esfuerzo duplicado, simplemente que para tener un diseño
adecuado hace falta darle bastantes vueltas a las cosas. Zikzak hizo
una primera versión, nosotros intentamos utilitzarla (lo utilizábamos
nostros mismos hasta hace bien poco), hasta que nos encontramos con
las limitaciones que tu has visto y tubimos que replantearlo de nuevo.

Más que dos opciones que compiten simplemente creo que una es la
evolución de la otra.


Cierto, aunque seguramente el contract de zikzakmedia tb evolucione de 
forma independiente a como lo hace el de nantic. Tendrás que tomar una 
decisión, tb la de hacer un tercer fork si lo consideras oportuno.


Como comentar Albert, el contract de Nantic añade nuevas funcionalidades 
muy interesantes como la asociación de activos y partes de trabajo. Pero 
a nosotros no nos gusta la simplificación que han hecho con 
contract.service dejándolo con sólo un único producto y sin cantidad. 
Preferimos nuestro enfoque de que un servicio puede contener varios 
productos con cantidades por defecto o calculadas de forma periódica. 
Dicho de otro modo el servicio es como una plantilla de contratos, y 
pudiendo tener varios productos con sus cantidades por defecto es más 
flexible. Y estos dos puntos que comenta Albert tb están en el contract 
de zikzakmedia (el primero está en el horno):



- Facturar por períodos naturales o no (por ejemplo del 16 al 15 del
mes siguiente o bien siempre del 1 al 31 y proratear si se empieza el
día 16).
- Añadir desfase entre el período facturado y la fecha de factura. Por
ejemplo, puedes decidir si facturas el trimestre el día 1 de enero, el
20 de febrero o cuando quieras...


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Otra duda con el modulo de contratos (zikzak)

[Jordi Esteve]

On 08/06/15 10:34, Raimon Esteve wrote:

2015-06-08 10:28 GMT+02:00 Antonio Roncero :

Hola,

estoy probando el modulo de contratos (contract y contract_invoice) de
zikzak y me surge la siguiente duda.

He generado un servicio "mantenimiento" que tiene un producto asociado
"mantenimiento de equipo informatico". En cantidad he puesto 1 unidad.
Ahora quiero generar dos contratos con este servicio para el cliente A y el
B. ¿Como puedo hacer para modificar la cantidad del producto en cada
contrato?, es decir, quiero que para el cliente A sean 5 equipos y para el B
7.

son 2 servicios diferentes.



Si, esta es una opción, la más fácil si tienes poca variablidad de este 
servicio.


Sinó la otra opción es instalar el mòdul contract_formula [1] que 
permite definir una expresión Python para el cálculo de la cantidad del 
servicio. Por ejemplo que coja el valor de un campo especial definido en 
party.party, donde indicas para cada tercero su cantidad por defecto.



Cálculo de cantidad en el contrato


Permite hacer cálculos en los productos para obtener nuevas cantidades.

Por ejemplo, la cantidad se puede calcular a partir de un consumo. En este
caso, deberá diseñar una expresión de código Python para calcular la 
cantidad.


[1] http://bitbucket.org/zikzakmedia/trytond-contract_formula

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Canviar la clase de las cuentas de activo a "Gastos"

[Jordi Esteve]

On 01/06/15 22:59, Albert Cervera i Areny wrote:

2015-06-01 20:16 GMT+02:00 Jordi Esteve :

Hola,

Actualmente no es posible añadir una cuenta contable de activo/immovilizado
(las que empiezan con 20, 21, 22, 23, 24 y 25) en líneas de factura de
proveedor o en la cuenta de activo de los productos de tipo activo, ya que
su clase es "Otro" en lugar de "Gastos."

20, 21 y 22, OK
23 parece que sí


Si, yo diría que 21 (Inmovilizaciones materiales) y 23 (Inmovilizaciones 
materiales en curso) son muy parecidas, son productos inmovilizados que 
se pueden comprar y seguramente su factura de compra tenga impuestos 
añadidos.



24 y 25, lo dudo más. ¿Estás seguro que deberían ser incluídas estas?


También son compras, pero referidas a Inversiones financieras. 
Seguramente las inversiones financieras no tengan impuestos y por tanto 
no se introduzcan directamente como un asiento contable en lugar de una 
factura de proveedor. En este caso no hacer falta que sean cuentas de 
clase "Gastos".


Podemos no hacer el cambio en la 24 y 25, y si una empresa lo necesita 
que se cambie ella misma la clase de estas cuentas.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

[tryton-es] Canviar la clase de las cuentas de activo a "Gastos"

[Jordi Esteve]

Hola,

Actualmente no es posible añadir una cuenta contable de 
activo/immovilizado (las que empiezan con 20, 21, 22, 23, 24 y 25) en 
líneas de factura de proveedor o en la cuenta de activo de los productos 
de tipo activo, ya que su clase es "Otro" en lugar de "Gastos."


¿Sería conveniente, además de contablemente correcto, cambiar la clase 
de estas cuentas de "Otro" a "Gastos" en los planes contables account_es 
y account_es_pyme?


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Decimales Informe de Venta Jasper

[Jordi Esteve (Zikzakmedia)]

El 26/05/15 a les 15:57, aleixfre...@gmail.com ha escrit:

Buenas tardes,

hemos realizado una actualización de Tryton de la versión 3.0 a 3.4

Y nos hemos encontrado con un problema en la impresión del Report de 
Venta en Jasper.


El campo precio unitario se visualiza con 4 decimales cuando en la 
anterior versión se visualizava con 2 decimales.


Es realmente extraño pues el informe es exactamente el mismo.

Quería saber si en la nueva versión éste parámetro se configura de 
alguna forma desde Tryton y por tanto afecta a la visualiación del 
informe.


Muchas gracias!


Seguramente sea debido a que ahora se puede definir el número de 
decimales a usar en precio unitario o en el descuento (si tienes 
instalado el módulo sale_discount) en el fichero de configuración de 
trytond, en una sección digits, y si no los defines te coge por defecto 4:


[digits]
unit_price_digits = 4
discount_digits = 4

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Campo one2many usando tab key

[Jordi Esteve]

On 18/05/15 13:41, Sergi Almacellas Abellana wrote:

El 18/05/15 a les 13:12, Jordi Esteve ha escrit:

On 16/05/15 14:26, Oscar Andres Alvarez Montero wrote:


Que yo sepa no hay solucion para eso en el cliente oficial tryton, y
si la hay tendrias que parchear el cliente: en linux facil, en windows
muy dificil.


Si, hay que parchear el cliente, para el cliente v3.4 deberías usar
estos dos



En la versión 3.6 funciona sobre los campos Many2One, no he probado 
con los One2Many y Many2Many, pero también debería funcionar. Y si no 
funciona se reporta cómo bug para que lo solucionen.


Si, esto es lo mejor. De hecho esta funcionalidad estaba en versiones 
anteriores de tryton pero se perdió creo en la v3.4. Excelente que esté 
presente de nuevo en la v3.6.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Campo one2many usando tab key

[Jordi Esteve]

On 16/05/15 14:26, Oscar Andres Alvarez Montero wrote:


Que yo sepa no hay solucion para eso en el cliente oficial tryton, y 
si la hay tendrias que parchear el cliente: en linux facil, en windows 
muy dificil.


Si, hay que parchear el cliente, para el cliente v3.4 deberías usar 
estos dos


tryton-4018.patch 
<https://bitbucket.org/zikzakmedia/tryton-patchs/src/eb06d1bd68aa699f17cdd3b415ab87af5d5c5cac/tryton-4018.patch?at=3.4>
tryton-4018-b.patch 
<https://bitbucket.org/zikzakmedia/tryton-patchs/src/eb06d1bd68aa699f17cdd3b415ab87af5d5c5cac/tryton-4018-b.patch?at=3.4>


En windows sería lo mismo, pero si quieres un fichero .exe instalador 
que te los incluya deberás crearlo. Puedes usar este que ya incluye este 
y otros patchs:


http://www.zzsaas.com/es/descarga-tryton.html

Jordi


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Duda con el modulo de contratos

[Jordi Esteve]

On 15/05/15 09:07, Guillem Barba Domingo wrote:


El 15/05/2015 0:42, "Albert Cervera i Areny" <mailto:alb...@nan-tic.com>> va escriure:

>
> 2015-05-14 22:30 GMT+02:00 Antonio Roncero <mailto:ronc...@gmail.com>>:

> >
> >
> > El jueves, 14 de mayo de 2015, 21:01:09 (UTC+1), Albert Cervera i 
Areny

> > escribió:
> >>
> >> 2015-05-14 21:20 GMT+02:00 Antonio Roncero <mailto:ron...@gmail.com>>:

> >> > Hola de nuevo,
> >> >
> >> > el modulo de contratos vale para hacer contratos con 
proveedores y poder

> >> > crear las facturas de los mismos?
> >>
> >> Qué módulo de contratos?
> >
> >
> > Estoy tomando como "repositorio" apps.tryton-erp.es 
<http://apps.tryton-erp.es>, por lo que este:

> >
> > http://apps.tryton-erp.es/contract/
> >
> > ¿Cuantos hay?
>
> Por lo menos, este otro:
>
> https://bitbucket.org/nantic/trytond-contract
>
> En cualquier caso, ninguno de los dos sirve para los contratos de
> proveedores. Ambos son para facturación recurrente a clientes. Son dos
> aproximaciones distintas al mismo problema.
>
> Para el tema de analítica deberías extender esos módulos.

También existe un tercero:

https://bitbucket.org/nantic/trytond-marchase_contract

Éste sí que tiene que ver con proveedores pero su funcionalidad es 
reducida: no te quedará compras ni facturas si no que sirve para 
registrar un compromiso de compra/suministro a un precio:
- cuando se hace una compra de un producto y proveedor con contrato lo 
selecciona automáticamente y usa el precio del contrato.
- Va controlando la cantidad servida/recibida respecto a la cantidad 
total pactada.
- Permite indicar la cantidad en origen (en nuestro caso de uso, la 
balanza del proveedor) y la de destino (la del cliente, el usuario de 
tryton) y determinar en cada contrato cuál de las dos cantidades se 
usa a la hora de facturar y para controlar la cantidad servida 
respecto a lo pactado. A nivel de estoc siempre se va a contar la 
cantidad en destino, lógico.




Interesante, quería mirármelo pero el link marchase_contract está roto.

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Duda con el modulo de contratos

[Jordi Esteve]

On 15/05/15 09:20, Raimon Esteve wrote:

2015-05-14 21:20 GMT+02:00 Antonio Roncero :

Hola de nuevo,

el modulo de contratos vale para hacer contratos con proveedores y poder
crear las facturas de los mismos?

El módulo desarrolado por  Zikzakmedia crea lineas de factura según
contrato/servicio (el contract invoice si no recuerdo mal el nombre) .
Por tanto, puedes después con el standalone o otros módulos agrupar
estas lineas con facturas cliente o proveedor.


2 correcciones a lo que dice Raimon:

El módulo contract (y contract_formular y contract_invoice) han sido 
desarrollados por Zikzakmedia y Nantic, Nantic ha hecho muchas mejoras y 
tb mantenien una rama propia.


El módulo contract sólo genera líneas de factura de cliente, no de 
proveedor. Luego se pueden incluir en facturas de cliente, bien con el 
botón + (depende del módulo account_invoice_standalone), bien desde las 
propias líneas con un asistente que te permite definir la fecha y la 
descripción de las facturas (si instalas contract_invoice).



--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Contabilidad para asosiaciones

[Jordi Esteve]

Hola Antonio,

On 15/05/15 12:17, Antonio Roncero wrote:

Hola,

Voy a migrar la asociación (ONG) de un familiar desde openerp 6.1 a 
tryton, por lo que voy a migar el plan contable de asociaciones desde 
openerp.


Muy bien. Hay gente que tb me ha preguntado si algún día estará el plan 
contable de asociaciones en tryton.



He visto que la contabilidad española son dos modulos independientes. 
Supongo que tengo que coger por ejemplo el de pymes y modificar las 
cuentas contables. ¿Es esta la manera correcta o hay un modulo base 
con las cuentas e informes comunes y luego modulos para cada tipo 
especifico que añade las variantes de cada plan contable?




Sería esto último, más o menos. Existe un repositorio account_es_csv2xml 
[1] que contiene ficheros CSV fáciles de editar con una hoja de cálculo 
donde se definen cuentas e impuestos (esto últimos común a todos los 
planes) y con un script python que incluye se generan todos los xmls de 
cada plan contable. Lo tienes brevemente explicado en [2], aunque lo 
mejor es que te lo bajes y lo pruebes, y si tienes alguna duda lo 
vuelves a preguntar por aquí.


[1] https://bitbucket.org/trytonspain/tryton-account_es_csv2xml
[2] http://wiki.tryton-erp.es/PlanesContables

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Pagar directamente con asiento contable

[Jordi Esteve]

On 14/05/15 13:59, Sergi Almacellas Abellana wrote:

El 14/05/15 a les 13:16, Albert Cervera i Areny ha escrit:

- O bien seleccionando los dos apuntes individualmente (utilitzando el
módulo account_statement_of_account o creando una entrada de menú que
te habra todos los apuntes contables)


Esto lo puedes abrir desde:

Contabilidad -> Asientos -> Diarios - Períodos

Haciendo doble click sobre el diario período se abren todos los 
apuntes de ese diario en ese período.


Eso si, los apuntes deben estar en el mismo diario, período.

I si en ambos apuntes tienes indicado el tercero, desde la opción 
"Apuntes a cobrar/pagar" de la opción relacionado.


Si lo quieres todos, ya tendrás que crear la entrada de menú.



Y una tercera opción, la que me gusta más. Si tienes el módulo 
account_payment instalado, podrás verlos en el menú 
Contabilidad/Pagos/Efectos a pagar/cobrar, ordenándolos por tercero, 
marcándolos y conciliando con la acción Conciliar.


Y si te instalas account_payment_bank se te añadirán pestañas para solo 
ver efectos con apuntes inversos, que lo facilita más.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Pagar directamente con asiento contable

[Jordi Esteve]

On 14/05/15 13:45, Albert Cervera i Areny wrote:

2015-05-14 13:21 GMT+02:00 Antonio Roncero :

Gracias Albert, me ha funcionado perfectamente.

¿Existe algun modulo que añada a la pestaña de pagos de la factura los
asientos de los pagos de la misma?

No, que yo conozca.



Yo tampoco pero lo puedes hacer indirectamente, abriendo el asiento de 
la factura (en la pestaña Información adicional) y luego clic derecho 
sobre el apunte conciliado, seleccionas Conciliación/Relacionado/Líneas 
de conciliación.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Integracion Web

[Jordi Esteve]

On 09/05/15 11:23, Albert Cervera i Areny wrote:

2015-05-08 14:04 GMT+02:00 Antonio Roncero :

Hola, he visto que hay varias formas de integrar tryton en la web:

* Nereid
* flask_tryton
* Galatea
...

Galatea se basa en flask_tryton y añade varios modelos y algunas
funciones extra, además de módulos para distintas funcionalidades como
catálogos o tiendas. Lo han desarrollado en Zikzakmedia y nosotros
tenemos un fork que es el que utilitzamos en nuestra web (está toda
sobre flask_tryton/galatea). La idea es terminar integrando nuestros
cambios con los de Zikzakmedia pero aunque lo hemos comentado, nos ha
faltado tiempo para encontrarnos y llegar a un acuerdo.


¿Tenéis experiencias con ellas?¿Cual creeis que es la mejor forma de
hacerlo?

Experiencia: http://www.nan-tic.com :)



Y aquí tienes otras webs también basadas en flask_tryton y módulos 
galatea, que a diferencia de la anterior ofrecen catálogo de productos, 
registro del visitante, carrito de compra y confirmación pedido, o sea 
tener un tienda web sobre los modelos de Tryton.


http://www.scraphouse.es (productos de scrapbooking, venta a cliente final)
http://profesional.scraphouse.es (productos de scrapbooking, venta a 
profesional o distribuidor)

http://www.cimbis.es (productos de ortodoncia)


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Control Stock Insuficiente no se realiza desde Ventas o Sale POS (Ventas TPV)

[Jordi Esteve]

On 07/05/15 19:10, Agustín Montagna wrote:

Hola a Todos!

Estamos ya casi en producción con Tryton en un local de venta 
minorista, usando para vender el módulo de Sale Pos (aunque lo que 
describo pasa desde Ventas también). Estamos con Tryton 3.2 y algunos 
módulos de la localización Argentina.


El asunto es el siguiente: No existe ninguna alerta al momento de 
generar la venta que avise que no hay stock suficiente en el almacén 
para satisfacer dicha demanda puntual. He revisado los foros y no 
encuentro nada al respecto. He visto en manuales que para las reservas 
y otros movimientos de inventario sí existe en Tryton una alerta que 
hasta permite forzar dichos movimientos ante la insuficiencia del stock.


La pregunta sería, hay manera de generar esta alerta? Tengo algo mal 
configurado? En caso de que no esté la funcionalidad, cómo la podemos 
agregar, porque entiendo que no debe ser muy complejo dado que ya 
existen las comprobaciones en otros módulos.


En ventas no te alerta la falta de stock, ya que puedes vender sin tener 
stock, el sistema luego ya te calcularà compras o producciones (si te 
instalas y configuras los módulos *_supply) necesarias para poder servir 
las ventas en proceso.


Pero en algunos casos puede ser conveniente avisar de la falta de stock 
en el momento de hacer la venta, te puede ser útil el módulo 
sale_product_stock_shop [1] que avisa al usuario que no hay suficiente 
cantidad de producto en el almacén para hacer la venta según 
configuración de la tienda.


[1] bitbucket.org/zikzakmedia/trytond-sale_product_stock_shop

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Error en product pack

[Jordi Esteve (Zikzakmedia)]

El 06/05/15 a les 13:11, Antonio Roncero ha escrit:



El miércoles, 6 de mayo de 2015, 12:01:36 (UTC+1), raimonesteve escribió:

2015-05-06 12:16 GMT+02:00 Antonio Roncero >:
> Hola,
>
> he instalado el modulo product_pack con su dependecia
product_barcode.
>
> Cuando intento asignarle un codigo al producto o al embalaje me
da el
> siguiente error:
>
> Traceback (most recent call last):
>   File "/trytond/protocols/jsonrpc.py", line 150, in
_marshaled_dispatch
> response['result'] = dispatch_method(method, params)
>   File "/trytond/protocols/jsonrpc.py", line 179, in _dispatch
> res = dispatch(*args)
>   File "/trytond/protocols/dispatcher.py", line 161, in dispatch
> result = rpc.result(meth(*c_args, **c_kwargs))
>   File "/trytond/model/modelview.py", line 201, in fields_view_get
> result['arch'] = _inherit_apply(result['arch'], view.arch)
>   File "/trytond/model/modelview.py", line 73, in _inherit_apply
> % (element2.tag, element2.get('expr')))
> AttributeError: Couldn't find tag (xpath:
/form/field[@name="sequence"]) in
> parent view!
>
> Alguien sabe de que puede ser?

en la visrta form no hay el campo sequence para heredar


la vista del product_pack "product_barcode_form.xml" es la que busca 
ese campo sequence











pero la vista "product_barcode_form.xml" no tiene ese campo















Si la unica dependecia de product_pack es product_barcode, ¿puede ser 
que falte otro modulo que meta ese campo sequence y que no este en el 
tryton.conf como dependecia?




Exacto, este es el problema, la vista de product_barcode_form.xml ahora 
está mal definida, seguramente se cambió el módulo product_barcode para 
quitarle el campo sequence y no se cambió el módulo product_pack que 
depende de él. Habría que corregirlo.




> Y una segunda pregunta, una vez instalado correctamente se puede
vender por
> empaquetados, es decir, si tengo un embalaje de 12 unidades, en
la venta
> seleccionar 1 unidad de ese embalaje y que la cantidad sea 12.?



Si te miras el código de este módulo, no tiene esta funcionalidad. 
Tampoco tiene dependencia de sale. Seguramente debería implementarse en 
un módulo nuevo sale_product_pack o similar.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

[tryton-es] Traducción de las dos últimas noticias pendientes de revisar

[Jordi Esteve (Zikzakmedia)]

Traducción de las dos últimas noticias pendientes de revisar:

www.tryton.org: Add ca and es tryton release 3.6 news + pycon2015

http://codereview.tryton.org/14251002

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

[tryton-es] Fwd: [tryton-announce] New Tryton release 3.6

[Jordi Esteve]

Hola,

¿Está alguien trabajando con la traducción de la noticia del lanzamiento 
de la v3.6 de tryton? Si no lo ha empezado nadie ya me pongo yo, haré la 
traducción castellana y catalana.


Jordi


 Forwarded Message 
Subject:[tryton-announce] New Tryton release 3.6
Date:   Mon, 20 Apr 2015 18:00:00 -
From:   Tryton: Tryton 
Reply-To:   tryton-annou...@googlegroups.com
To: tryton-annou...@googlegroups.com



 New Tryton release 3.6
 

We are proud to announce the 3.6 release of Tryton .

The release shows the official support of PyPy  which 
is an alternative implementation of Python which focuses on speed and 
efficiency.


As usual, migration from previous series is fully supported with the 
obvious exception of the ldap_connection module which was removed.



   Major changes for the user

 *

   A new color scheme for the graphs has replaced the single brightness
   variance. Now the color scheme also changes the hue for each color
   by the golden angle (which ensure a color will not be picked twice).

   Graph color scheme
 *

   The dictionary widget receive completion on key searching like the
   other widgets.

 *

   The date/time widgets have been completely rewritten to be more
   flexible on the format to enter. But they are also more practicable
   when used with mouse only thanks to the real pop-up for the calendar
   and the drop down for the time.

   Date widget DateTime widget
 *

   Columns of list view that have always the same value are hidden
   automatically because they don't provide information. For example,
   the list of posted invoices will not show the state column because
   by definition they are all posted.


 Accounting

 *

   It is now possible to add a description to the cancel move from the
   wizard.

 *

   A new option to only show the balance appears in the General Ledger.

 *

   Tax can now be configured to modify the base price for the next
   taxes in the list.

 *

   It is now possible to define templates for common moves. When
   running a template, the user will be asked to encode some data like
   an amount or a party, then an account move will be generated with
   those inputs.

   Move Template
 *

   A printable report exists now for the depreciation of assets.

 *

   The account charts for France and Belgium has been updated. And the
   Belgium one is now translated in dutch.

 *

   A test wizard is available now to see the result generated by the
   payment term. As the payment terms are quite flexible because they
   support to apply many deltas (instead of only one), it is not always
   easy to forecast the behaviour.

   Payment Term Test
 *

   The SEPA 
   coverage is now extended to the pain.001.003.03 and 008.003.02
   flavors which are used in Germany. And it is also possible to
   re-generate a SEPA message in case of wrong configuration on the
   first generation.

 *

   The statements create moves grouped by default by number, date and
   party. So when one statement line is split for invoice
   reconciliation, only one move will be created now and the origin of
   this move will be the group of the statement lines.

 *

   Tax rules can now depend on the origin and the destination country
   thanks to the new module account_tax_rule_country.

 *

   The CFONB
   

   custom (non-standard) format of SEPA is added by the new module
   account_payment_sepa_cfonb.

 *

   A new type deposit of account is added by the new module
   account_deposit. It allows to invoice deposit and recall later this
   amount on the next invoice.


 Product

 * The price list can now be defined as tax included. Tryton will then
   compute the price without taxes based on the taxes applied.


 Sale

 * A new state won was added to the sale opportunity. It goes to this
   state automatically when at least one of its sale is confirmed and
   all others are also confirmed or canceled.
 * The amount of the opportunity is updated accordantly to the amount
   of the linked sales. This will give more accurate reports.
 * The computation of the shipment cost is now computed only at the
   quotation. This lower the load on the client when the order is
   pretty large as the cost will be computed only once instead of each
   times a line is added.
 * The new module sale_extra allow to add extra line on sale based on
   criteria. The extra can be either a free product or an extra service
   cost etc.


 Stock

 * There is now a relate from the product to its order points.
 * The creation of purchase request warns also on late production like
   it does for late incoming shipment.
 * The Shelf Live/Expiration Dates are now supported with the new
   module stock_lot

Re: [tryton-es] Incomptatibilidad con módulo account_invoice_consecutive

[Jordi Esteve]

On 21/12/14 17:03, Albert Cervera i Areny wrote:

2014-12-21 14:10 GMT+01:00 Albert Cervera i Areny :

2014-11-08 19:30 GMT+01:00 Jordi Esteve :

On 07/11/14 16:59, Albert Cervera i Areny wrote:

Algunos comentarios:

- No lo he probado pero creo que falla si haces una factura de
proveedor (en ningún sitio compruebas que sólo tienes que buscar la
secuencia si se trata de factura/abono de cliente).

En principio debería funcionar también para facturas de proveedor, ahora veo
que el primer commit que ha hecho Jesús ha limitado asignar diferentes
números de secuencia a facturas de cliente y de devolución de cliente en
función del diario.

Realmente queremos poder definir secuencias distintas por diario para
proveedores? Si no se requiere correlación entre facturas y no hay la
necesidad de definir distintas series de facturación para proveedores
no veo qué sentido tiene.. Os parece bien que eliminemos esta
posibilidad?

He creado un fork de este módulo [1] y un pull request [2] para hacer
éste y otros cambios. Ya daréis vuestra opinión.

[1] https://bitbucket.org/nantic/trytond-account_invoice_multisequence
[2] 
https://bitbucket.org/trytonspain/trytond-account_invoice_multisequence/pull-request/1/add-irmodelaccess-simplify-and-fix/diff


Olvidé responde a esta petición. Yo prefiero dejar abierta la 
posibilidad de poder definir distintas series de facturación para 
cualquier tipo de factura. Lo habitual es usar series de numeración 
distintas para facturas y abonos de cliente, pero alguna empresa podría 
usar tb series distintas para facturas o abonos de proveedor en función 
de la delegación o área de la empresa a la que van destinadas, como una 
forma de separarlas. Además el tener distintas series de facturación 
para cualquier tipo de factura no complica el código, sinó todo el 
contrario. Lo mismo dejarlo abierto para que las secuencias pueden ser 
por ejercicio o por periodo, así queda mucho más integrado a lo que 
ofrece el módulo account_invoice del core de tryton.


Algunas de las mejoras hechas en [1] han sido portadas a [2] 
recientemente, por ejemplo poder editar las multi secuencias 
directamente en los ejercicios fiscales.


[1] https://bitbucket.org/nantic/trytond-account_invoice_multisequence
[2] https://bitbucket.org/trytonspain/trytond-account_invoice_multisequence

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Traducción 3.6

[Jordi Esteve]

Hola,

On 10/04/15 15:41, Raimon Esteve wrote:

Hola,

como sabeis ya está anunciado la fecha para la versión 3.6 de Tryton
para el próximo 20 de abril (1). Ya es momento de la traducción, que
tenemos fecha hasta el 17th abril 20:00 UTC (viernes que viene, una
semana justo). De todos modos, Jordi deberá decidir cuando prepara los
commits y a que hora los sube. Supongo que será el medidodía.

Ya se encuentra disponible y operativo el servidor 3.5 para la
traducción (Español de España).

Los datos del servidor son los mismos que siempre. Si hay alguién que
no los conoze o quiere colaborar con la traducción, que mande un
privado a Jordi Esteve o a mi y os daremos el acceso.

Recordad que hay algunas notas sobre traducciones que se han anotado
para fijar en la 3.6 (2). Si hay alguna traducción pendiente de fijar
de la 3.4, por favor, nos lo comentan.

Que tengan un buen fin de semana de traducción.

Estadística:

247 pedientes traducción
296 a revisión (fuzzy)

(1) https://groups.google.com/d/msg/tryton-dev/yE5HTIJHey8/yzb_iY3bGQ8J
(2) http://wiki.tryton-erp.es/Traduccion3.4-3.6


Las traducciones es_ES (español de España) ya están terminadas y subidas 
a hg.tryton.og, tanto las de tryton (gracias Sergi), como las de trytond 
y sus módulos.


He aprovechado para hacer una revisión de la coherencia de varios 
términos entre módulos distintos. Creo que en esta versión ha quedado 
una traducción bastante impecable (idem para el catalán).


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Traducción 3.6

[Jordi Esteve (Zikzakmedia)]

El 17/04/15 a les 14:44, Albert Cervera i Areny ha escrit:

2015-04-17 14:41 GMT+02:00 Jordi Esteve (Zikzakmedia) :

Hola,

Respecto a las traducciones de (Español de España) ya está todo traducido,
los 247+296 términos que comentaba Raimon, mayormente de los 7 nuevos
módulos que incluirá la v 3.6. También se han repasado muchas traducciones
hechas.

Básicamente se ha cambiado:

Confirmar y Confirmado/a por Contabilizar y Contabilizado/a (Post) en
asientos y facturas. Unos 50 términos se han cambiado.
Realizar envío (make shipment) por Empaquetar en los albaranes de cliente.

Faltaría hacer los cambios de Realizar y Realizado por Finalizar y
Finalizado (en albaranes y solicitudes de compra). Lo hago en 1 hora.

Hay algunos términos nuevos que tengo algunas dudas, se aceptan sugerencias
(hay de margen unas 3 o 4h.):

Nuevo estado de los movimientos de stock: Staging. De momento se ha
traducido por "En proceso"
shelf life -> Vida útil
Shelf life date -> Fecha caducidad
Delta -> Incremento (nueva funcionalidad para definir las líneas de los
plazos de pago)
Deposit -> Fianza (para los pagos a cuenta o adelantos de factura)

Para mi devería ser "Anticipo". En Catalán yo lo llamé "Bestreta".



Si, me he equivocado al escribirlo. Quería decir

Deposit -> Anticipo (para los pagos a cuenta o adelantos de factura)

Alguna sugerencia más?

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Traducción 3.6

[Jordi Esteve (Zikzakmedia)]

Hola,

Respecto a las traducciones de (Español de España) ya está todo 
traducido, los 247+296 términos que comentaba Raimon, mayormente de los 
7 nuevos módulos que incluirá la v 3.6. También se han repasado muchas 
traducciones hechas.


Básicamente se ha cambiado:

Confirmar y Confirmado/a por Contabilizar y Contabilizado/a (Post) en 
asientos y facturas. Unos 50 términos se han cambiado.

Realizar envío (make shipment) por Empaquetar en los albaranes de cliente.

Faltaría hacer los cambios de Realizar y Realizado por Finalizar y 
Finalizado (en albaranes y solicitudes de compra). Lo hago en 1 hora.


Hay algunos términos nuevos que tengo algunas dudas, se aceptan 
sugerencias (hay de margen unas 3 o 4h.):


Nuevo estado de los movimientos de stock: Staging. De momento se ha 
traducido por "En proceso"

shelf life -> Vida útil
Shelf life date -> Fecha caducidad
Delta -> Incremento (nueva funcionalidad para definir las líneas de los 
plazos de pago)

Deposit -> Fianza (para los pagos a cuenta o adelantos de factura)

Jordi

El 10/04/15 a les 15:41, Raimon Esteve ha escrit:

Hola,

como sabeis ya está anunciado la fecha para la versión 3.6 de Tryton
para el próximo 20 de abril (1). Ya es momento de la traducción, que
tenemos fecha hasta el 17th abril 20:00 UTC (viernes que viene, una
semana justo). De todos modos, Jordi deberá decidir cuando prepara los
commits y a que hora los sube. Supongo que será el medidodía.

Ya se encuentra disponible y operativo el servidor 3.5 para la
traducción (Español de España).

Los datos del servidor son los mismos que siempre. Si hay alguién que
no los conoze o quiere colaborar con la traducción, que mande un
privado a Jordi Esteve o a mi y os daremos el acceso.

Recordad que hay algunas notas sobre traducciones que se han anotado
para fijar en la 3.6 (2). Si hay alguna traducción pendiente de fijar
de la 3.4, por favor, nos lo comentan.

Que tengan un buen fin de semana de traducción.

Estadística:

247 pedientes traducción
296 a revisión (fuzzy)

(1) https://groups.google.com/d/msg/tryton-dev/yE5HTIJHey8/yzb_iY3bGQ8J
(2) http://wiki.tryton-erp.es/Traduccion3.4-3.6



--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Re: Modulo Fondos (Pago - Cobros)

[Jordi Esteve (Zikzakmedia)]

El 16/04/15 a les 20:34, Martín Di Lisio ha escrit:

Hola a todos,

Buscando encontré este hilo y lo refloto.

Estamos necesitando un módulo donde yo pueda elegir pagar una o más 
facturas, ya generadas, que estén en estado de Pago, y que se puedan 
pagar de manera mixta, con cheques, efectivo, etc.
El formulario de Pago de cada factura, no tiene esta información por 
defecto. Hay algún módulo que se le parezca? Es decir, no quiero 
generar un recibo o una orden de pago, como en el voucher, solo quiero 
pagar las facturas.


El botón de Pago de cada factura permite pagar un factura totalmente o 
parcialmente. Permite pagar una factura con varios pagos de distintos 
tipos (distintos diarios de dinero). Si quieres pagar varias facturas a 
la vez no te sirve, entonces puedes usar el módulo 
account_bank_statement, aunque también creo que con account_statement 
que está incluido en el core de tryton te serviría, pues en cada línea 
de extracto puedes indicar que facturas se pagan. O hacerlo a mano, 
introducieno el asiento contable del pago en el diario correspondiente, 
y luego conciliando el pago con las facturas que paga.




Estuve viendo el sale pos, pero está más orientado a una venta de un 
negocio, donde se genera la venta y luego la factura. No se si me 
serviria para facturas ya emitidas.


sale_pos es otra historia. Primero permite hacer ventas (de forma más 
ágil que el módulo sale) y segundo permite pagar ventas mediante 
registro de los pagos en extractos. Si trabajas con facturas 
directamente y quieres pagar facturas no es el camino.



--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Modulo Gestión Documental

[Jordi Esteve (Zikzakmedia)]

El 13/04/15 a les 19:25, vgargalloburd...@gmail.com ha escrit:

Buenas tardes,

 Existe algún modulo de gestión documental en Tryton?


Gestor documental propiamente dicho no tiene, pero si tiene una 
herramienta sencilla de adjuntar ficheros a cualquier registro del ERP. 
Está explicado un poco aquí


http://doc.tryton-erp.es/trytond_doc/tryton_adjuntos.html

básicament es usar el botón del clip en cualquier registro (tercero, 
producto, venta, ...), o arrastrar y soltar un archivo encima del clip 
para añadir un adjunto nuevo a un registro.


Puedes consultar todos los adjuntos desde el menú 
Administración/Modelos/Adjuntos.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Duda sobre Terceros

[Jordi Esteve (Zikzakmedia)]

El 08/04/15 a les 11:08, Antonio Roncero ha escrit:

Hola,

estoy mirando como funciona el concepto de terceros en tryton y me 
surge una duda. Un tercero puede tener varias direcciones y varios 
medios de contacto, hasta ahi bien. ¿Como se puede asociar un contacto 
a un tercero para que los medios de contactos sean del contacto? por 
ejemplo:


Tengo la *empresa A*, que tiene dos sedes *direccion 1* y*direccion 2* 
y un *Persona 1. C*ada uno de estos contactos tienen sus telefonos e 
email independientes. ¿como podria hacerlo en tryton? es decir, 
asociar un medio de contacto a una direccion o persona especifica.


Creo que te intersa el módulo party_communication [1]


Medios de contacto en empresas y direcciones


Añade una relación entre los medios de contacto (teléfono, móvil, email, 
...) y
las direcciones de tercero. De este modo puede saberse que medios de 
contactos

pertenecen a una dirección concreta.

La dirección en un medio de contacto no es un campo requerido. Por 
tanto, si un

medio de contacto no dispone de dirección se entiende que es un medio de
contacto general del tercero (por ejemplo un teléfono corporativo o una 
web).



¿Se puede hacer con el planteamiento por defecto de tryton o tendria 
que hacer (o existe) un modulo que asocie terceros con otros terceros?




Si, existe el módulo party_relationship [2], pero su uso sería más para 
relacionar terceros, como empleado-empleador, filial-empresa madre, etc.


The party relationship module allows to define different types of relations
between parties.

Each relation is defined by a relation type. A reverse relation type can be
defined, so  when creating a relation of a type, the reverse relation 
will be

automatically created.

[1] bitbucket.org/trytonspain/trytond-party_communication

[2] http://hg.tryton.org/modules/party_relationship

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Modulo Product Variant Unique

[Jordi Esteve]

On 04/04/15 11:25, vgargalloburd...@gmail.com wrote:

Hola,

alguien me puede decir donde puedo encontrar el modulo Product Variant 
Unique. Lo necesito porque es necesario para poder instalar otro 
modulo de Zikzakmedia SL que se llama Product Measurements Shape.


És fácil encontrarlo, sólo debes buscarlo en bitbucket, en el mismo 
portal donde has encontrado el módulo product_measurements_shape. En 
concreto aquí


https://bitbucket.org/nantic/trytond-product_variant_unique

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Error con la validacion del cif en importacion de bancos españoles

[Jordi Esteve]

On 01/04/15 20:24, Antonio Roncero wrote:
Hola, estoy empezando con tryton para migrar mi empresa desde openerp. 
He instalado trython desde las fuentes (hg clone -b 3.4 
http://hg.tryton.org/trytond/) y todos los modulos oficiales. Hasta 
aquí todo ha funcionado correctamente.
Cuando creo la empresa, al intentar poner el cif, no me aparece el 
listado en el desplegable "País del CIF/NIF" y me deja poner cualquier 
cif sin hacer comprobación. Además, cuando intento ejecutar el wizard 
de importar bancos españoles, me da un error que ES no aparece en los 
listados de cif.




No tendrás instalada la librería python vatnumber

pip install vatnumber

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Sale POS Cantidad por defecto "1" en linea de venta

[Jordi Esteve]

Hola Óscar,

On 01/04/15 05:39, Oscar Alvarez wrote:

Hola Devs

Me gustaria proponer que se fije automaticamente el valor "1" por 
defecto de la cantidad en la linea de venta del modulo [1] sale_pos, 
esto nos permite acelerar el proceso de ingreso de productos en cada 
venta, sobre todo en ventas donde hay gran cantidad de productos, muy 
comunmente es asi en tiendas grandes.


[1] https://bitbucket.org/zikzakmedia/trytond-sale_pos


Esto depende un poco del tipo de empresa o negocio. Hay gente que 
prefiere que por defecto la cantidad sea 1 pq es lo más habitual, hay 
otros que prefieren que lo pida siempre para evitar errores de poner 1 
cuando eran más.


Nosotros esto lo solucionamos instalando y configurando el módulo 
default_value [1]. Es un módulo muy sencillo que permite configurar 
valores por defecto para cualquier campo de tipo 'boolean', 'char', 
'integer', 'text', 'float', 'numeric', 'date', 'datetime', 'time', 
'many2one', 'selection', 'reference'. Sirve para cualquier tipo de 
modelo, por tanto tb es útil para definir valores por defecto en 
asistentes. Hay que usarlo con moderación para no redefinir valores por 
defecto ya definidos en los módulos propios.


[1] https://bitbucket.org/zikzakmedia/trytond-default_value

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Está intentando evitar una regla de acceso. (Tipo de documento: sale.sale)

[Jordi Esteve]

El dia 22/03/2015 2.35,  va escriure:
>
> Hola,
>
> Estoy intentando crear un presupuesto de venta y me aparece este error
"Está intentando evitar una regla de acceso. (Tipo de documento:
sale.sale)". Tengo instalado los módulos de venta: sale,
sale_invoice_grouping, sale_price_list, sale_rule y sale_shop. Es el primer
presupuesto que intento generar.
>
> Alguien me puede ayudar con este problema.

Seguramente debes tener ventas hechas en algunas tiendas y accedes con un
usuario que no tiene asignado ninguna tienda por lo que no puede ver
ventas.

Jordi

Re: [tryton-es] Reserva automática de albaranes de cliente

[Jordi Esteve]

On 20/03/15 21:50, Albert Cervera i Areny wrote:

2015-03-20 19:53 GMT+01:00 Jordi Esteve :

El módulo stock básico de tryton permite reservar (assign) manualmente los
albaranes de clientes.

No he visto en los módulos oficiales la posibilidad de poder reservar
automáticamente los albaranes de cliente, por ejemplo con una acción
planificada, que intente reservar los albaranes confirmados que pueda, sin
forzar ninguna reserva. ¿Sabéis si existe algún módulo extra que lo haga?

No conozco ninguno. De todas formas me parece, a menos que se
exactamente lo que necesita la empresa, que no es una buena
estrategia. Creo que sería mejor poder ver qué albaranes podríamos
servir con el stock actual y que el usuario pueda decidir cuales
quiere realizar.


Si el número de albaranes a servir diariamente es muy elevado, que el 
usuario tenga que decidir cuales quiere realizar puede ser tedioso.



  El problema de la reserva es que a priori sigue un
criterio aleatorio, aunque una posibilidad, claro está, puede ser
reservar por orden de fecha estimada (y complementado con la fecha del
pedido en caso de coincidencias).


Si, esta es la idea, que el sistema haga la reserva automática de los 
albaranes por orden de fecha estimada. Y según quiera la empresa, la 
reserva podría ser con albaranes parciales o sólo con albaranes totales 
(aquellos albaranes que no se han podido reservar completamente se 
deshace la reserva parcial para que otros albaranes si puedan reservarse 
completamente).


Me parece una funcionalidad bastante común y me extrañaba que nadie no 
hubiese trabajado en ella. No es muy complicada, nos pondremos a 
desarrollarla nosotros mismos.




He visto que existe el módulo stock_reservation [1] de Nantic que segurament
hace algo parecido pero me parece un enfoque muy complicado, pues define un
nuevo modelo reserva y hacer varios cálculos laboriosos.

Éste módulo hace varias cosas. Las más importantes diría que son:

- Hace esta reserva que comentas sin necesidad de dividir el
movimiento de estoc del albarán. Imagina que automatizas la reserva y
tienes que deshacerla. El sistema habrá dividido el albarán y según
que módulos tengas instalados además habrá rellenado el lote.
- Indica al usuario si hay compras pendientes de llegar, compras
pendientes de pedir al proveedor o incluso solicitudes de compra que
no son necesarias y generarán estoc sobrante. Imprescindible si hay
cancelaciones!
- Al relacionar los suministros con los consumos, permite saber a qué
compra exactamente está esperando un albarán de salida (incluso si la
compra alimentará una producción, que alimentará otra producción que
alimentará al albarán!). Y a la inversa, puedes ver qué producciones y
ventas se van a ver afectadas si decides no hacer la compra al
proveedor.


Gracias por la detallada explicación, el módulo todavía no tiene carpeta 
doc e iba un poco perdido ;-)


Ciertamente muy interesante su funcionalidad, aunque me asusta que en un 
entorno real con muchos productos/albaranes/solicitudes de 
compra/compras la operación de reserva sea muy lenta, pues he visto que 
el código hace muchas iteraciones para conseguir estos resultados.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

[tryton-es] Reserva automática de albaranes de cliente

[Jordi Esteve]

El módulo stock básico de tryton permite reservar (assign) manualmente 
los albaranes de clientes.


No he visto en los módulos oficiales la posibilidad de poder reservar 
automáticamente los albaranes de cliente, por ejemplo con una acción 
planificada, que intente reservar los albaranes confirmados que pueda, 
sin forzar ninguna reserva. ¿Sabéis si existe algún módulo extra que lo 
haga?


He visto que existe el módulo stock_reservation [1] de Nantic que 
segurament hace algo parecido pero me parece un enfoque muy complicado, 
pues define un nuevo modelo reserva y hacer varios cálculos laboriosos.


[1] https://bitbucket.org/nantic/trytond-stock_reservation

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Beneficio x Venta

[Jordi Esteve]

On 07/02/15 01:42, Luis Deiana wrote:
Buenas tardes, hay algún modulo o forma que me permita saber cual es 
el beneficio por cada venta teniendo en cuenta que el costo y el 
precio de venta varían  de manera considerable ?


Creo que te podría ir bien el módulo sale_margin que añade márgenes en 
las ventas y en las líneas de ventas:


https://bitbucket.org/zikzakmedia/trytond-sale_margin

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Ayuda un tanto urgente con los períodos de ejercicio

[Jordi Esteve (Zikzakmedia)]

El 03/02/15 a les 13:28, Maria Cecilia Santos Popper ha escrit:

Estimados,

estoy con un problema un tanto grave ya que creo que he cometido un 
error importante a la hora de generar los perídos.
Siendo que estaba habituada al a localización argentina usando el 
módulo invoice_ar (que generaba los perídos del ejercicio en manera 
automática), cuando implenté el modulo invoice y cometí el error de 
generar un período sólo llamado 2015 que va desde elñ 01/01/2015 hasta 
el 31/12/2015.
El problema es que al querer generar movimientos de caja y ventas en 
Febrero de 2015 me sale un error que dice "No se ha asignado período".
he intentado generar un período para febrero que va desde el 
01/02/2015 hasta el 28/02/2015, pero el error que surge entonces es 
"se superpone con el período 2015).
El problema es que no puedo modificar el período 2015 ya que este 
tiene asientos obviamente.


La cuestión es que estoy atascada con esto, sin poder facturar ni 
hacer asientos por un error básico que cometí en la configuracioń.


Hay alguna forma de salir de esta "trampa"?



Deberás pasar todos los asientos a borrador y asignarles un período 
distinto, por ejemplo un período de ajuste de 01/01/2015 a 01/01/2015 o 
un período situado en 2014. Luego podràs eliminar/cambiar el período 
incorrecto, crear los correctos y asignarlos a los asientos anteriores y 
confirmarlos.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Asiento de apertura y cierre

[Jordi Esteve (Zikzakmedia)]

Hola,

El 02/02/15 a les 13:08, Manuel Bailen ha escrit:

Hola a todos,

he cerrado en el ejercicio 2014 y no me genera ningún asiento de 
apertura ni cierre, en principio no le dí mayor importancia pues el 
balance y la cuentas de resultados eran correctos,


Si, tryton no genera ningún asiento de apertura ni cierre, no hace 
falta, pues en cada cuenta queda anotado el saldo al cierre del 
ejercicio (pestaña Cierres o Prórrogas dentro de una cuenta contable). 
Sólo genera el asiento de pérdidas y ganancias o regularización.



pero ahora me encuentro que cuando abro el extracto de una cuenta, en 
la consulta no se arrastran los saldos del ejercicio cerrado y el 
saldo es incorrecto.


Parece más un error del extracto de una cuenta, no sé como lo sacas.



¿Hay alguna forma de hacer los asientos de apertura y cierre (aparte 
de con un asiento manual claro)?


No hace falta hacerlo, por eso tryton no ofrece una forma automatizada 
de hacerlos.




¿Existe otra forma de comprobar los movimientos y el saldo de las cuentas?
Desde menú Contabilidad/Planes contables/Abrir plan contable puedes ver 
los saldos de las cuentas. Y haciendo doble clic sobre una cuenta podrás 
ver los movimientos de esa cuenta.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] sale_pos - self_pick_up activo en estado presupuesto y confirmado

[Jordi Esteve (Zikzakmedia)]

El 29/01/15 a les 08:21, Raimon Esteve ha escrit:

2015-01-29 0:32 GMT+01:00 Luis Deiana :

Buenas noches, quería hacer una sugerencia que desde mi punto de vista
podría ser muy útil y le daría mayor flexibilidad a Tryton (si es que no hay
una solución ya para este tema):
Por que no se habilita la opcion self_pick_up en los estados posteriores a
borrador ?

Según configuración en la tienda:

https://bitbucket.org/zikzakmedia/trytond-sale_pos/src/db1ad8189738acfcdc723e7602f6938b324390d3/shop.py?at=default#cl-14
https://bitbucket.org/zikzakmedia/trytond-sale_pos/src/db1ad8189738acfcdc723e7602f6938b324390d3/sale.py?at=default#cl-48

Pues la tienda física A el cliente lo viene a recoger = pick up y la
tienda B es un call center y le envias por transportista


Raimon, creo que Luis no se refería a esto, sinó a que una venta, una 
vez está en presupuesto o confirmada, no te deja marcar la opción 
autorecogida (self_pick_up) en el formulario de la venta.


Esto está hecho así en coherencia a otros campos de la venta. La opción 
autorecogida (self_pick_up) cambia los métodos de facturación y envío de 
la venta, y estos también se deshabilitan en los estados posteriores a 
borrador (presupuesto o confirmado).


Estoy de acuerdo que daría más agilidad poder cambiar estos 3 campos en 
los estados posteriores a borrador (presupuesto o confirmado).


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] el filtro: Entidad: !=Cliente Mostrador. No funciona ?

[Jordi Esteve (Zikzakmedia)]

El 29/01/15 a les 08:43, Guillem Barba Domingo ha escrit:



El 29/01/2015 8:27, "Raimon Esteve" <mailto:raimonest...@gmail.com>> va escriure:

>
> 2015-01-28 23:06 GMT+01:00 Luis Deiana <mailto:luis.deian...@gmail.com>>:

> >
> >
> > El miércoles, 28 de enero de 2015, 12:47:52 (UTC-3), Jordi Esteve
> > (Zikzakmedia) escribió:
> >>
> >> On 28/01/15 14:17, Jesús Martín Jiménez wrote:
> >>
> >>
> >>
> >> El 28 de enero de 2015, 14:14, Luis Deiana <mailto:luis.d...@gmail.com>> escribió:

> >>>
> >>> Buenos dias, cuando se vende a un cliente no habitual utilizo un 
cliente
> >>> llamado "Cliente Mostrador" y necesito que Tryton me muestre 
todas las
> >>> ventas que no se hicieron a este cliente. Por lo tanto lo filtro 
según el

> >>> link 1* de la siguiente manera:
> >>>
> >>> Entidad: !Cliente Mostrador
> >>> tambien probe: Entidad: !=Cliente Mostrador
> >>>
> >>> No me reconoce el filtro y me muestra todas las ventas incluidas 
las del

> >>> Cliente Mostrador
> >>>
> >>> Utilizo Tryton 3.2
> >>>
> >>> 1*
> >>> 
http://doc.tryton-erp.es/trytond_doc/tryton_buscador.html#operaciones-con-el-filtro

> >>>
> >>>
> >> Prueba de poner los dos puntos después del igual.
> >>
> >> Entidad !=: Cliente Mostrador
> >>
> >>
> >> Esto no me suena que funcione bien como filtro. Debería ser
> >>
> >> Entidad: !"Cliente Mostrador"
> >>
> >
> > Ninguna de las opciones dio resultado, el espacio me lo recibe si 
lo cambio
> > por guion bajo (Clienet_Mostrador). Pero la negacion no me la 
reconoce de

> > ninguna manera.
>
> Revisalo porque es tal como te lo he comentado.
>
> todos los string con espacio, se debe usar las comillas. Si usas el
> buscador interno, verás que lo pone en comillas si hay un espacio:
>
> Nombre: "Cliente Varios"
>
> Y la negación, con "!"
>
> Nombre: !"Cliente Varios"

Esto funciona en general pero no en esta ocasión.
Mejor dicho: esta negación funciona si es contra "Nombre" pero no 
contra "Entidad"


El modelo Party tiene definido este search_rec_name (aproximadamente):
def search_rec_name():
  return ['OR',
('name',) + clause[:1],
('code',) + clause[1:],
]

Creo que esta OR hace que la negación no funcione.
Éste lunes o martes me encontré con un caso igual en otro modelo pero 
tengo pendiente investigarlo (ver exactamente como trata la negación).


Creo que no se puede, pero a ver si esto funciona:
"Entidad/Nombre": !"Cliente Mostrador"



Si, exacto, este es el problema, Guillem se me ha adelantado con la 
explicación.


La negación funcionará bien con campos simples, donde no esté redefinido 
el método search_rec_name() para incluir otros criterios con 'OR'. 
Prueba a buscar facturas, ventas, ... distintas a un cierto número de 
factura/venta/... y verás que te funcionará.


Yo diría que en el caso de tercero, como se busca por nombre o por 
código, no funciona, pues te devuelve todos los terceros ya que todos 
los terceros tienen un código distinto a tu criterio.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] el filtro: Entidad: !=Cliente Mostrador. No funciona ?

[Jordi Esteve]

On 28/01/15 14:17, Jesús Martín Jiménez wrote:



El 28 de enero de 2015, 14:14, Luis Deiana <mailto:luis.deian...@gmail.com>> escribió:


Buenos dias, cuando se vende a un cliente no habitual utilizo un
cliente llamado "Cliente Mostrador" y necesito que Tryton me
muestre todas las ventas que no se hicieron a este cliente. Por lo
tanto lo filtro según el link 1* de la siguiente manera:

Entidad: !Cliente Mostrador
tambien probe: Entidad: !=Cliente Mostrador

No me reconoce el filtro y me muestra todas las ventas incluidas
las del Cliente Mostrador

Utilizo Tryton 3.2

1*

http://doc.tryton-erp.es/trytond_doc/tryton_buscador.html#operaciones-con-el-filtro


Prueba de poner los dos puntos después del igual.

Entidad !=: Cliente Mostrador



Esto no me suena que funcione bien como filtro. Debería ser

Entidad: !"Cliente Mostrador"

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Activar o Desactivar un produsco

[Jordi Esteve]

On 24/01/15 01:17, Luis Deiana wrote:



El viernes, 23 de enero de 2015, 8:02:27 (UTC-3), raimonesteve escribió:

2015-01-23 0:32 GMT+01:00 Luis Deiana >:
> Al desactivar un producto no tendría que dejar de mostrármelo
como opción de
> venta o compra ?? o sea, hay varios productos que ya no me
sirven y los
> desactive para reducir la lista al momento de comprar o vender
pero resulta
> que siguen figurando normalmente aunque ya no están en la
ventana de
> productos.

Desactivado el producto (product.template) o la variante
(product.product)? Creo que te falta el product.product.

si quieres activar/desactivar producto con plantilla, aquí tienes:

https://bugs.tryton.org/issue4347 <https://bugs.tryton.org/issue4347>

con un review (que zikzakmedia lo usa, claro ;) )

http://codereview.tryton.org/9861002
<http://codereview.tryton.org/9861002>


Ok, gracias y si desactive un producto y sus variantes como puedo 
volver a activarlos ?


Cualquier registro que esté desactivado lo puedes volver a activar si lo 
buscas con el criterio Activo: Falso y le vuelves a marcar el campo Activo.


Lo tienes explicado aquí

http://doc.tryton-erp.es/trytond_doc/tryton_buscador.html#encontrar-inactivos

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Venta de Confirmado -> Presupuesto

[Jordi Esteve]

On 24/01/15 15:15, Luis Deiana wrote:
Buen día, es posible volver desde una venta echa en sale_pos que se 
encuentra en estado de confirmado a estado de borrador ?



Si tienes el módulo sale_confirmed2quotation instalado te añade un botón 
en las ventas que permite pasarlas de confirmadas a borrador. Si están 
en ventas TPV no lo verás pq el formulario de ventas TPV no tiene este 
botón, deberás consultar la venta con el formulario normal.


PD: Las ventas normales y la ventas TPV son lo mismo, lo único que 
cambia es la pantalla (formulario) para getionarlas.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] La cambiar de producto en una venta y compra no actualiza el detalle

[Jordi Esteve]

On 02/01/15 15:39, Luis Deiana wrote:
Al seleccionar un producto A en una venta o compra se carga el detalle 
del mismo. Si modifico este producto A por otro B después de estar 
seleccionado no modifica el detalle y sigue con el detalle del 
producto anterior A, lo cual produce un error al impactar en el plan 
de cuentas pq registra una venta o compra de un producto erróneo.


Me parece que no es así. Si te refieres al campo "Descripción" de las 
líneas de venta, esta descripción no se modifica si se cambia el 
producto para evitar perderla si la has cambiado o escrito una 
descripción personalizada. Si quieres que el campo "Descripción" de las 
líneas de venta se rellene de nuevo, dejalo vacío para que así cuando 
seleccionas un nuevo producto se rellene de nuevo con el valor por defecto.


Respecto al plan de cuentas (cuentas contables), las ventas no 
seleccionan ninguna. Es en la factura que la cuenta contable asociada al 
producto se rellena, y si el producto se cambia la cuenta contable por 
defecto también.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Duda respecto Sale Device en módulo sale_shop

[Jordi Esteve]

Hola Maria Cecilia,

On 19/12/14 11:37, Maria Cecilia Santos Popper wrote:

Hola!

Tengo una duda respecto de esta opción en el módulo sale_shop.
Lo que estoy queriendo lograr es generar dos devices (dispositivos) 
distintos para registrar los pagos: un para pagos en efectivo y el 
otro para pagos con tarjetas.
He generado los dos extractos (Caja y Tarjetas, respectivamente. Ambos 
están abiertos en estado borrador.


Pero al querer hacer un pago de una venta ficticia, cuando selecciono 
el boton pagar, sólo me aparece el extracto "Caja". Lo mismo sucede 
cuando quiero abrir los Statements desde la opción que aparece en el 
módulo ventas.


Lo que noto es que en la pestaña "Preferencias" del usuario al cual le 
he asignado el shop, sólo puedo seleccionar un tipo de Sale Device, 
por lo que es lógico que luego no pueda seleccionarlo al momento de 
pagar la venta.


La pregunta es: hay alguna forma de seleccionar múltiples devices para 
un mismo usuario???

Gracias y espero que no sea muy tonta mi pregunta.



El módulo sale_shop solo proporciona tiendas, supongo que te refieres al 
sale_payment que añade devices (dispositivos) y los relaciona con extractos.


No está diseñado para ser configurado como expones. Los devices 
(dispositivos) son los terminales de venta TPV y cada uno de ellos puede 
tener formas de pago distintas configurados como diarios de extracto.


En tu caso tienes un device y dos diarios de extracto (payment journals).

En la presentación [1] que hice en el TUB2013 lo tienes brevemente expuesto.

[1] http://downloads.tryton.org/TUB2013/pos.pdf

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Registro de correspondencia

[Jordi Esteve]

Hola Lluís,

On 10/12/14 09:21, ldalmau wrote:

Hola,

¿Es posible llevar un registro de correspondencia con tryton (entradas 
y salidas)? ¿Alguna recomendación o módulo para ello?


¿A que te refieres con "registro de correspondencia (entradas y salidas)?

1) ¿A correspondencia física? Por ejemplo, ¿los típicos registros de 
entrada y salida de las administraciones públicas? No hay nada al 
respecto, pero se me ocurre que el módulo party_event para registrar 
eventos a terceros te podría servir, pues permite registrar eventos de 
un tercero con una fecha, asunto, descripción y hasta asociarle un 
empleado y un recurso. Podría usar el tipo "Otros" o crear nuevos tipos 
que fuese Entrada y Salida.


2) ¿A correos electrónicos enviados y recibidos?

Para los correos enviados se pueden usar los siguientes módulos 
publicados en bitbucket para crear plantillas de correo electrónico y 
que cuando estos sean enviados queden registrados como eventos del tercero:

electronic_mail
electronic_mail_event
electronic_mail_template
electronic_mail_wizard

Para correos recibidos puedes utilizar los módulos helpdesk para 
registrarlos y mantener conversación vía email.

account_invoice_helpdesk
helpdesk
project_helpdesk
sale_helpdesk
sale_opportunity_helpdesk
stock_helpdesk

[1] https://bitbucket.org/zikzakmedia/trytond-party_event

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] circuito ventas- compras - inventario

[Jordi Esteve]

On 03/12/14 19:29, Maria Cecilia Santos Popper wrote:



2014-12-03 5:54 GMT-03:00 Jesús Martín Jiménez 
mailto:jmar...@zikzakmedia.com>>:


Hola Cecilia,

El 2 de diciembre de 2014, 23:06, Maria Cecilia Santos Popper
mailto:cecili...@gmail.com>> escribió:

Saludos a todos desde Argentina.!
Nuestra empresa (cooperativa de servicios informáticos) desea
implementar Tryton como sistema de gestión.
Hemos avanzado bastante en la impñementacion del modulo de
contabilidad (plan de cuentas argentino) y ventas (sale).
Lamentablemente no podemos integrar el modulo sale _pos por
una incompatibilidad entre este y Account_invoice_ar (pero
dejaré eso para otro post).
La dificultad que tengo en este momento es respecto al módulo
de compras y como integrar la gestión de inventario.
Puntualmente quisiera saber si hay alguna forma de automatizar
la creación de albaranes internos para realizar los impactos
en el inventario ya que hasta ahora no he logrado que se
modifique el stock si no es generando el correspondiente albarán.


Sí se puede. Para ello debes acceder a la vista de configuración
de ventas a través del menú Ventas > Configuración > Configuración
de ventas. Allí verás los métodos de envío de ventas y de
facturación de ventas. Sólo tienes que seleccionar la opción que
desees: al procesar el pedido, al pagar la factura, o manualmente
(que parece que es la opción que debes tener seleccionada
actualmente).


Gracias por la respuesta. He verificado que en la configuración de 
Ventas tengo seleccioandas las opciones "Facturación de la Venta: Al 
procesar la orden" y Método de Envío de Venta: Al procesar la orden". 
Entonces, cuando genero una venta al cliente, efectivamente se genera 
un remito (albaran) que luego debo procesar y empaquetar.
Pero no sucede lo mismo con las ordenes de compra, ya que si genero 
una compra y su correspondiente factura, no veo el remito de proveedor 
para poder procesarlo.


No, en el caso de las compras no se genera el albarán (remito) entero, 
sólo las líneas, ya que no sabes si el proveedor te lo va a enviar 
entero o por partes.


Cuando recibas algo, deberás crear un albarán de proveedor nuevo, 
asignarle el proveedor y añadirle las líneas existentes con el botón +.




O sea, si no entiendo mal, cada vez que genero una compra, a
su vez tengo que generar un remito interno para poder
actualizar el inventario, no es así?


No. El inventario no se actualiza sino que se calcula cada vez que
necesitas consultarlo a partir de los movimientos de stock realizados.

Justamente esa es mi duda: cómo realizar los movimientos de stock, 
porque por lo que veo, cuando genero una venta de un producto 
determinado, esto no se ve actualizado en el inventario correspondiente.

Actualmente tengo las siguientes ubicaciones:
Zona de Almacenamiento
Peridos y Encontrados
Zona de Entrada
Zona de Salida
Todas estas son del tipo Depósito. Pero en nuestro caso, no tenemos 
depósito sino que simplemente la mercaderia pasa del proveedor a la 
venta en nuestro local. He intendado generar una ubicación que sea 
Venta Local (tipo Vista) pero entonces no me permite realizar 
inventarios de ubicaciones que no sean depósito.


Cuando envies/recibas todos los productos de un albarán el stock quedará 
acutalizado (cantidad real). Mientras solo cambia la cantidad prevista.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Error con "plazo de pago" tipo "fijo"

[Jordi Esteve (Zikzakmedia)]

El 27/11/14 a les 09:02, Raimon Esteve ha escrit:
2014-11-26 21:12 GMT+01:00 Manuel Bailen <mailto:bai...@esdebian.org>>:

> Hola a todos,
> Me lanza el siguiente error al confirmar facturas si utilizo un 
"plazo de pago" con una de las lineas de tipo "fijo".
> El valor del campo "Tipo de pago" de "Apunte contable" no es 
correcto según su dominio.


Pues el apunte contable lo relacionas con un tipo de pago, y el apunte 
contable tienes un dominio (filtro) y el tipo de pago que deseas 
inserir no es acorde con el dominio.


> He probado con las 3.2 y la 3.4 en una base de datos nueva y da el 
mismo error.

> En la primera línea utilizo tipo "fijo" y 0 días, 0 meses, 
> En la segunda línea utilizo tipo "remanente" y 30 días, 0 meses, ...

Vete a modelos, buscas este campo y miras que módulo lo añade. Y miras 
el código fuente para saber como debe ser el dominio, la línea 22 (1).


El dominio:

domain=[
('kind', '=', Eval('account_kind')),
],

Por tanto, el tipo de pago debe ser "payable" o "receivable" acorde 
con el campo "account_kind" de "account.move.line"


(1) 
https://bitbucket.org/trytonspain/trytond-account_payment_type/src/44ba335d66363431b668c38ecbfc970ab89ccf2b/move.py?at=default#cl-22




Este problema suele pasar cuando ya tienes apuntes/facturas contables 
creados con un cierto tipo de pago, y a este tipo de pago le cambias el 
tipo/clase (cobrar -> pagar o al revés). Entonces todos los 
apuntes/facturas contable que usan este tipo de pago dan problema de 
dominio.


Creo que se hizo una mejora del módulo account_payment_type hace muy 
poco que precisamente no permite cambiar el tipo de pago si ya se usa en 
algún apunte/factura.


Jordi

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Re: Crear solicitud de compra manual

[Jordi Esteve (Zikzakmedia)]

El 19/11/14 a les 14:13, Luis Deiana ha escrit:

Ok, perdón,  se me paso.


Luís, otra vez estás haciendo top-posting. Evítalo por favor.

Mira de escribir/responder sólo para aportaciones interesantes, si no se 
hace ruido en la lista de correo innecesariamente.


Jordi



El miércoles, 19 de noviembre de 2014 05:50:38 UTC-3, Guillem Barba 
Domingo escribió:



El 18/11/2014 22:41, "Luis Deiana" > va escriure:
>
> Hola, no se si entendi mal, pero creo que los que necesitas es
crear un nuevo registro en:
> Compras / Solicitudes de compra
>
> El martes, 18 de noviembre de 2014 14:57:51 UTC-3, Eduardo J de
la Garza G escribió:
>>
>> Hola,
>>
>> El asistente que crea solicitudes de compra funciona bien, sin
embargo, tengo necesidad de crear solicitudes de compra
manualmente adicionales a las que crea el asistente. ¿Qué debo
hacer para que el sistema me lo permita pues únicamente me da la
oportunidad de ver las solicitudes que se crean con el asistente
pero no de crear nuevas en la misma pantalla?
>>
>> Gracias de antemano por sus comentarios.

Y si tampoco puedes hacerlo como te pide Luís, puede ser que no
esté habilitado el crear solicitudes manualmente, pues tiene mas
sentido crear la Compra directamente.
Ten en cuenta que cuandose ejecuta el asistente de crear
solicitudes, lo primero que hace es eliminar TODAS las solicitudes
(que no estén ya en estado "comprado"), y entonces hace el cálculo
de lo que tiene que comprar.

PD: @luis, por favor, NO hagas top posting.




--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Incomptatibilidad con módulo account_invoice_consecutive

[Jordi Esteve]

On 07/11/14 16:59, Albert Cervera i Areny wrote:

2014-11-07 15:41 GMT+01:00 Jesús Martín Jiménez :

Hola,

El 7 de noviembre de 2014, 15:13, Albert Cervera i Areny
 escribió:

2014-11-07 11:41 GMT+01:00 jmartin :

Hola,

Estoy desarrollando un módulo que permitiría asignar diferentes números
de
secuencia a facturas de cliente y de devolución de cliente en función
del

Perfecto! Ya comentarás cuando esté publicado...


Lo he colgado de trytonspain [1] -_-'

Perfecto.

Algunos comentarios:

- No lo he probado pero creo que falla si haces una factura de
proveedor (en ningún sitio compruebas que sólo tienes que buscar la
secuencia si se trata de factura/abono de cliente).


En principio debería funcionar también para facturas de proveedor, ahora 
veo que el primer commit que ha hecho Jesús ha limitado asignar 
diferentes números de secuencia a facturas de cliente y de devolución de 
cliente en función del diario.


La idea original es que este módulo permita asignar diferentes números 
de secuencia a cualquier tipo de facturas en función del diario, de 
manera que también permite tener secuencias distintas en facturas de 
proveedor.


La nueva clase account.journal.invoice.sequence debería llamarse 
account.journal.invoice.sequence.out (contiene secuencias estrictas de 
factura de salida). Y hacer una nueva clase 
account.journal.invoice.sequence.in con las dos secuencias estrictas de 
facturas de entrada (proveedor). Y en account.journal tener dos campos 
sequences_out y sequences_in que sean sólo visibles cuando el diario sea 
de tipo revenue o income respectivamente.



- Pienso que también estaría bien poder ver la llista de secuencias en
el año fiscal (normalmente configurarás un nuevo año y esperas
encontrar ahí toda la configuración).
No es fácil mostrar en el ejercicio fiscal todas las distintas 
secuencias de cada período y diario. Se me ocurre añadir una pestaña 
nueva en los ejercicios fiscales que tuviera dos campos o2m apuntando a 
account.journal.invoice.sequence.out y 
account.journal.invoice.sequence.in con un domino del ejecicio fiscal. 
¿Qué os parece?



- Falta un dominio en el campo period que asegure que el período está
dentro del año fiscal introducido (el cual es obligatorio).

Totalmente de acuerdo.


- Y para terminar: en mi opinion no es necesario soportar la
posibilidad de tener varias secuencias por período. No creo que tenga
mucho sentido. Para mi, sólo lo tiene a nivel de año fiscal porqué lo
que quieres es evitar el problema de la correlación de números y
fechas y si tienes una secuencia por cada mes siempre puedes hacer una
factura al 30 o 31 del mes anterior.


No entiendo esto último de correlación de fechas y hacer una factura el 
30 o 31 mes anterior.


Yo creo que no está de más soportar varias secuencias por período, pues 
es una extensión natural de lo que tiene Tryton de base en account: 
Permite definir las secuencias de facturación a nivel de ejercicio 
fiscal o a nivel de período.


Ahora extendemos esta base para que las facturas puedan tener secuencias 
de facturación a nivel de diario y ejercicio fiscal o a nivel de diario 
y período. Hacerlo por diario y período es opcional, igual que pasa en 
el módulo base account.



[1] https://bitbucket.org/trytonspain/trytond-account_invoice_sequence


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] sale_price_list_change_party

[Jordi Esteve]

On 04/11/14 13:24, Luis Deiana wrote:
Hola, estoy probando este modulo, que según entiendo sirve para poder 
cambiar el cliente en una venta después de cargar uno o varios 
productos. Pero no encuentro como cambiar el cliente ya que no me 
vuelve a habilitar el campo de selección de clientes ni encuentro 
ningún asistente, si alguien ya lo utilizo con sale o con sale_pos y 
me puede orientar se lo voy a agradecer. Gracias y


Te debería aparecer un asistente en ventas que te permite indicar el 
tercero y/o la tarifa, el cuál te las cambia en la venta y vuelve a 
calcular los precios aplicando esa nueva tarifa.


more doc/es/index.rst

===
Ventas. Cambio de tercero en ventas con tarifa de venta
===

Asistente que permite cambiar el tercero de una venta en la que ya se han
añadido líneas de venta. También nos permite seleccionar el mismo tercero
y cambiar las direcciones de facturación o de envío, como la tarifa de 
venta.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Solicitud de compra

[Jordi Esteve]

Hola Luis,

Buenos días, al ejecutar el asistente de solicitud de compra solo me 
crea solicitudes con los productos que tienen stock menor a cero hay 
algún modulo o función que me permita generar solicitudes de compras 
con los productos que tienen stock en cero sin tenes que controlar uno 
por uno los productos que están faltando? espero se entienda la consulta.

Saludos.


Si estás a cero no te falta nada, sólo cuando estás por debajo de cero 
es que te faltan. Si estás debajo de cero el ERP puede crearte 
solicitudes de compra/producción para volver a ponerte el stock a cero.


Si quiere que el sistema te crea solicitudes de compra/producción cuando 
está a cero, no debajo de cero, deberás crearte reglas de stock mínimo 
(o de abastecimiento), donde le indiques para cada producto el umbral 
por debajo del cuál te debe pedir, y la cantidad a la que deberías 
llegar, por ejemplo que te pida cuando estás debajo de 1 para tener 5.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

[tryton-es] Traducción al español de la notícia sobre la reciente publicación de tryton 3.4

[Jordi Esteve]

Hola,

Acabo de subir un codereview con la traducción al español de 4 notícias, 
la reciente publicación de tryton 3.4 y otras 3 de anteriores, por si la 
queréis revisar:


http://codereview.tryton.org/14611002

--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

Re: [tryton-es] Módulos para editar facturas ya confirmadas y para poder buscar apuntes/líneas contables

[Jordi Esteve]

On 15/10/14 15:03, Albert Cervera i Areny wrote:

2014-10-15 10:30 GMT+02:00 Jordi Esteve :

On 14/10/14 17:34, Albert Cervera i Areny wrote:

2014-10-14 16:15 GMT+02:00 Jordi Esteve (Zikzakmedia)
:

Hola,

Comentaros que recientemente he subido este para de módulos bastante
genéricos por si alguien le puede interesar:

account_invoice_posted2draft: [1]
Permite cambiar facturas confirmadas a borrador (eliminando el asiento
contable de la factura) para poder modificar la información de la
factura.
Para poder cambiar el estado de las facturas confirmadas abra el menú
|menú_account_journal| y marque la opción **Permitir cancelar asientos**
de
los diarios de tipo **Ingresos** (para las facturas de cliente) o
**Gastos**
(para las facturas de proveedor).
Este módulo es necesario en aquellas empresas que necesiten poder
modificar
una factura ya confirmada sin tener que hacer una factura de abono y otra
de
nueva. Ya hace tiempo que desarrollamos un módulo parecido llamado
account_invoice_cancel que permitía cancelar una factura confirmada para
poderla modificar pero en tryton daba problemas, ya que si la factura
cancelada proviene de una venta ya no la deja cambiar de estado, y si se
cancela una factura confirmada de proveedor tampoco se puede cambiar. En
cambio, en este nuevo módulo account_invoice_posted2draft se pasa la
factura
confirmada a borrador y no afecta tener instalados los módulos de compras
y/o ventas.

¿Habéis comprobado si la cantidad de una línea proviniente de una
venta se regenera la venta cuando se vuelve a contabilizar la factura?


No entiendo bien la frase, no sé cuál es el sujeto. ¿Qué es lo que se
regenera, la cantidad, la venta, ...?

La línea de venta. Workflow:

- Crear venta
- Procesar venta
- Realizar albarán
- Confirmar factura
- Volver factura a borrador
- Cambiar cantidad de una línea (pasar de 10 unidades a 5)
- Confirmar de nuevo la factura

Debería crear una nueva factura con las 5 unidades pendientes de facturar.


Así lo hace. La transición draft->posted de las facturas actua de la 
misma forma sea la primera vez que la haga o las posteriores. En este 
sentido el módulo account_invoice_poste2draft es simple y su 
funcionamiento no depende que estén instalados otros módulos como 
sale/purchase.


Lo que si no hace, pq tampoco lo hace el módulo core de tryton, es si se 
cambia la cantidad de 10 a 15 de la línea de factura y su vuelve a 
confirmar, crear una nueva factura con -5 unidades a facturar. Si se 
factura de menos se crea una nueva factura con lo que falta, si se 
factura de más no.


--
Jordi Esteve
Consultor Zikzakmedia SL
jest...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108