[tryton-es] Eliminar el campo classe del account_payment_type

[Sergi Almacellas Abellana]

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 bancaria Tercero A cobrar
Domiciliación bancaria Empresa A pagar
Efectivo Ninguno A cobrar
Efectivo Ninguno A pagar
Transferencia Bancaria Empresa A cobrar
Transferencia Bancaria Tercero A pagar

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

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 bancaria Empresa Tercero
Efectivo Ninguno A Ninguno
Transferencia Bancaria Tercer A Empresa

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

Opiniones? Alguien be algún inconveniente?

[Raimon Esteve]

Post by Sergi Almacellas Abellana
Hola,
Acabo de darme cuenta que en una nuestra base de datos tenemos los
Nombre: Tipo C.C Clases de Tipo
Domiciliación bancaria Tercero A cobrar
Domiciliación bancaria Empresa A pagar
Efectivo Ninguno A cobrar
Efectivo Ninguno A pagar
Transferencia Bancaria Empresa A cobrar
Transferencia Bancaria Tercero A pagar
Por lo que estamos definiendo los tipos de pago por duplicado para poder
definirlos como a pagar o a cobrar.
Entonces mi proposuesta era eliminar el campo classe ("kind")

debemos diferenciar. hay entornos que sólo permites un tipo de pago,
dos, o .....

Post by Sergi Almacellas Abellana
y poner dos campos para definir el Tipo de C.C

no todos los pagos van asociados a una cuenta corriente

Post by Sergi Almacellas Abellana
por lo que la misma información quedaria
Nombre: Tipo C.C (Pagar) Tipo C.C (Cobrar)
Domiciliación bancaria Empresa Tercero
Efectivo Ninguno A Ninguno
Transferencia Bancaria Tercer A Empresa
Por lo que a mi entender habría menos información duplicada.
Opiniones? Alguien be algún inconveniente?
--
Sergi Almacellas Abellana
www.koolpi.com

--
Si us plau, NO adjunti arxius a les seves respostes. Li preguem que
integri el text al cos del missatge. Pot respondre usant NetEtiquete
que li ajudarà a seguir la conversa.
http://es.wikipedia.org/wiki/Netiquette

Por favor, NO adjunte archivos a sus respuestas. Le rogamos que
integre el texto en el cuerpo del mensaje. Puede responder usando
NetEtiquete que le ayudará a seguir la
conversación.http://es.wikipedia.org/wiki/Netiquette

Please, DO NOT send attachment files with your answers, just copy and
paste only the text you need to send into the body of your mails.
Repply using NetEtiquete. http://en.wikipedia.org/wiki/Netiquette

[Sergi Almacellas Abellana]

Post by Raimon Esteve
debemos diferenciar. hay entornos que sólo permites un tipo de pago,
dos, o .....

A que te refieres por entorno?

Puedes poner ejemplos?

Post by Raimon Esteve

Post by Sergi Almacellas Abellana
y poner dos campos para definir el Tipo de C.C

no todos los pagos van asociados a una cuenta corriente

Entonces en el tipo de C.C se le pone ninguno, como venimos haciendo
ahora :)

[Jordi Esteve (Zikzakmedia)]

Post by Sergi Almacellas Abellana
Hola,
Acabo de darme cuenta que en una nuestra base de datos tenemos los
Nombre: Tipo C.C Clases de Tipo
Domiciliación bancaria Tercero A cobrar
Domiciliación bancaria Empresa A pagar
Efectivo Ninguno A cobrar
Efectivo Ninguno A pagar
Transferencia Bancaria Empresa A cobrar
Transferencia Bancaria Tercero A 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.

Post by Sergi Almacellas Abellana
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
Nombre: Tipo C.C (Pagar) Tipo C.C (Cobrar)
Domiciliación bancaria Empresa Tercero
Efectivo Ninguno A Ninguno
Transferencia Bancaria Tercer A 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
***@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel [phone]

[Sergi Almacellas Abellana]

Post by Jordi Esteve (Zikzakmedia)
No me parece bien. Como te he comentado, es frecuente tener tipos de
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.

[Jordi Esteve (Zikzakmedia)]

Post by Sergi Almacellas Abellana

Post by Jordi Esteve (Zikzakmedia)
No me parece bien. Como te he comentado, es frecuente tener tipos de
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
***@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel [phone]

[Sergi Almacellas Abellana]

Post by Jordi Esteve (Zikzakmedia)

Post by Sergi Almacellas Abellana

Post by Jordi Esteve (Zikzakmedia)
No me parece bien. Como te he comentado, es frecuente tener tipos de
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

Post by Jordi Esteve (Zikzakmedia)
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.

Post by Jordi Esteve (Zikzakmedia)
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.


[1]
https://bitbucket.org/trytonspain/trytond-sale_payment_type/src/34383b6f1f79cfa8f07ffac72ea5b0a1210b3977/sale.py?fileviewer=file-view-default#sale.py-31
[2]
https://bitbucket.org/trytonspain/trytond-purchase_payment_type/src/851d26258c449e4fe04afe53de2ba4f29d68f235/purchase.py?fileviewer=file-view-default#purchase.py-34

[Jordi Esteve]

Post by Sergi Almacellas Abellana

Post by Jordi Esteve (Zikzakmedia)

Post by Sergi Almacellas Abellana

Post by Jordi Esteve (Zikzakmedia)
No me parece bien. Como te he comentado, es frecuente tener tipos de
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.

Post by Sergi Almacellas Abellana

Post by Jordi Esteve (Zikzakmedia)
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.

Post by Sergi Almacellas Abellana

Post by Jordi Esteve (Zikzakmedia)
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
- 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
***@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel [phone]

[Raimon Esteve]

... el ejemplo, tipos de pago virtuales, no siempre tendrás "a pagar"
y "a cobrar". Debes diferenciar

Saludos

[Sergi Almacellas Abellana]

Post by Raimon Esteve
... el ejemplo, tipos de pago virtuales, no siempre tendrás "a pagar"
y "a cobrar". Debes diferenciar

Un ejemplo que permite cobrar y pagar:

https://www.paypal.com/ -> puedes pagar y cobrar

Ademas, las pasarelas de pago, cómo se utilizan en sitios webs (o
derivados), se permite al cliente seleccionar los tipos de pago
disponibles, por lo que ya se define en la configuración del sitio web
(o dónde quieras) aquellos que están disponibles y/o el que se utilizará
por defecto.

Un saludo,

[Sergi Almacellas Abellana]

Post by Sergi Almacellas Abellana
Ademas, las pasarelas de pago, cómo se utilizan en sitios webs (o
derivados), se permite al cliente seleccionar los tipos de pago
disponibles, por lo que ya se define en la configuración del sitio web
(o dónde quieras) aquellos que están disponibles y/o el que se utilizará
por defecto.

Por ejemplo añadiendo una marca para definir que es un pago virtual:

https://bitbucket.org/zikzakmedia/trytond-galatea_esale/src/0afe7ccbed3f6d8091d3b0a7082b93eb973c30a3/payment_type.py?fileviewer=file-view-default

[Raimon Esteve]

Post by Sergi Almacellas Abellana

Post by Sergi Almacellas Abellana
Ademas, las pasarelas de pago, cómo se utilizan en sitios webs (o
derivados), se permite al cliente seleccionar los tipos de pago
disponibles, por lo que ya se define en la configuración del sitio web
(o dónde quieras) aquellos que están disponibles y/o el que se utilizará
por defecto.

https://bitbucket.org/zikzakmedia/trytond-galatea_esale/src/0afe7ccbed3f6d8091d3b0a7082b93eb973c30a3/payment_type.py?fileviewer=file-view-default

es otro tema. Tu puedes disponer un Redsys y no querer tipo de pago "a
pagar". Etc

este tema ya se habló en su inicio.... hablo ya de años....

[Sergi Almacellas Abellana]

Post by Raimon Esteve

Post by Sergi Almacellas Abellana

Post by Sergi Almacellas Abellana
Ademas, las pasarelas de pago, cómo se utilizan en sitios webs (o
derivados), se permite al cliente seleccionar los tipos de pago
disponibles, por lo que ya se define en la configuración del sitio web
(o dónde quieras) aquellos que están disponibles y/o el que se utilizará
por defecto.

https://bitbucket.org/zikzakmedia/trytond-galatea_esale/src/0afe7ccbed3f6d8091d3b0a7082b93eb973c30a3/payment_type.py?fileviewer=file-view-default

es otro tema. Tu puedes disponer un Redsys y no querer tipo de pago "a
pagar". Etc

I tambien puedes disponer de un Redsys y queror los dos tipos de pago.

Si quiere tener la restricción se implementa en un nuevo módulo sin
forzar a todo el mundo a tenerla, de modo que aquellos que lo necessiten
instalen el módulo y listos.

Post by Raimon Esteve
este tema ya se habló en su inicio.... hablo ya de años....

Si, lo recuerdo. Pero hacemos nuevas versiones para ir mejorando poco a
poco no?

[Raimon Esteve]

Post by Sergi Almacellas Abellana

Post by Raimon Esteve

Post by Sergi Almacellas Abellana

Post by Sergi Almacellas Abellana
Ademas, las pasarelas de pago, cómo se utilizan en sitios webs (o
derivados), se permite al cliente seleccionar los tipos de pago
disponibles, por lo que ya se define en la configuración del sitio web
(o dónde quieras) aquellos que están disponibles y/o el que se utilizará
por defecto.

https://bitbucket.org/zikzakmedia/trytond-galatea_esale/src/0afe7ccbed3f6d8091d3b0a7082b93eb973c30a3/payment_type.py?fileviewer=file-view-default

es otro tema. Tu puedes disponer un Redsys y no querer tipo de pago "a
pagar". Etc

I tambien puedes disponer de un Redsys y queror los dos tipos de pago.

si es así, lo das de alta con el nuevo tipo.

Post by Sergi Almacellas Abellana
Si quiere tener la restricción se implementa en un nuevo módulo sin forzar a
todo el mundo a tenerla, de modo que aquellos que lo necessiten instalen el
módulo y listos.

o viceversa, el nuevo módulo lo quita o haces un patch en tu instancia.

Post by Sergi Almacellas Abellana

Post by Raimon Esteve
este tema ya se habló en su inicio.... hablo ya de años....

Si, lo recuerdo. Pero hacemos nuevas versiones para ir mejorando poco a poco
no?

correcto, es volver hacia atràs pues ya se habló.

Raimon

[Sergi Almacellas Abellana]

Post by Raimon Esteve

Post by Sergi Almacellas Abellana
Si quiere tener la restricción se implementa en un nuevo módulo sin forzar a
todo el mundo a tenerla, de modo que aquellos que lo necessiten instalen el
módulo y listos.

o viceversa, el nuevo módulo lo quita o haces un patch en tu instancia.

No porqué tryton esta pensado para ir añadiendo y no ir quitando. Aunque
se puede quitar, es mucho más fàcil añadir en un nuevo módulo que quitar
en un módulo que sobre-escribe.

[Raimon Esteve]

Post by Raimon Esteve

Post by Sergi Almacellas Abellana
Si quiere tener la restricción se implementa en un nuevo módulo sin forzar a
todo el mundo a tenerla, de modo que aquellos que lo necessiten instalen el
módulo y listos.

o viceversa, el nuevo módulo lo quita o haces un patch en tu instancia.

No porqué tryton esta pensado para ir añadiendo y no ir quitando. Aunque se
puede quitar, es mucho más fàcil añadir en un nuevo módulo que quitar en un
módulo que sobre-escribe.

Tryton te permite eliminar campos de vista. Esto es "quitar" ;)

[Sergi Almacellas Abellana]

Post by Raimon Esteve

Post by Raimon Esteve

Post by Sergi Almacellas Abellana
Si quiere tener la restricción se implementa en un nuevo módulo sin
forzar a
todo el mundo a tenerla, de modo que aquellos que lo necessiten
instalen el
módulo y listos.

o viceversa, el nuevo módulo lo quita o haces un patch en tu instancia.

No porqué tryton esta pensado para ir añadiendo y no ir quitando. Aunque se
puede quitar, es mucho más fàcil añadir en un nuevo módulo que quitar en un
módulo que sobre-escribe.

Tryton te permite eliminar campos de vista. Esto es "quitar" ;)

No es tan facil ya que el campo es obligatorio tiene una restricción de
que no permite valores nulles en la base de datos y si lo quitas de la
vista no vas a poder crear ningún registro.

Además, quitar-lo es quitar todos los dominios en las facturas, ventas y
otros modelos porqué sino no vas a poder trabajar, ya que estos dominios
presuponen que el campo existe.

[Raimon Esteve]

Post by Raimon Esteve

Post by Raimon Esteve

Post by Sergi Almacellas Abellana
Si quiere tener la restricción se implementa en un nuevo módulo sin
forzar a
todo el mundo a tenerla, de modo que aquellos que lo necessiten
instalen el
módulo y listos.

o viceversa, el nuevo módulo lo quita o haces un patch en tu instancia.

No porqué tryton esta pensado para ir añadiendo y no ir quitando. Aunque se
puede quitar, es mucho más fàcil añadir en un nuevo módulo que quitar en un
módulo que sobre-escribe.

Tryton te permite eliminar campos de vista. Esto es "quitar" ;)

No es tan facil ya que el campo es obligatorio tiene una restricción de que
no permite valores nulles en la base de datos y si lo quitas de la vista no
vas a poder crear ningún registro.
Además, quitar-lo es quitar todos los dominios en las facturas, ventas y
otros modelos porqué sino no vas a poder trabajar, ya que estos dominios
presuponen que el campo existe.

Me referia a la funcionalidad de "quitar" de Tryton. No quitar este
campo de pago concreto de la vista.

Saludos

[Sergi Almacellas Abellana]

Post by Raimon Esteve
Me referia a la funcionalidad de "quitar" de Tryton.

Ahora si que ya no se a que te refieres :S

[Raimon Esteve]

Post by Sergi Almacellas Abellana

Post by Raimon Esteve
... el ejemplo, tipos de pago virtuales, no siempre tendrás "a pagar"
y "a cobrar". Debes diferenciar

https://www.paypal.com/ -> puedes pagar y cobrar
Ademas, las pasarelas de pago, cómo se utilizan en sitios webs (o
derivados), se permite al cliente seleccionar los tipos de pago disponibles,
por lo que ya se define en la configuración del sitio web (o dónde quieras)
aquellos que están disponibles y/o el que se utilizará por defecto.

Paypal es un ejemplo; hay más tipos. Además, ten cuidado con el tema
de comisiones según el tipo ;)

Post by Sergi Almacellas Abellana
Un saludo,
--
Sergi Almacellas Abellana
www.koolpi.com

--
Si us plau, NO adjunti arxius a les seves respostes. Li preguem que
integri el text al cos del missatge. Pot respondre usant NetEtiquete
que li ajudarà a seguir la conversa.
http://es.wikipedia.org/wiki/Netiquette

Por favor, NO adjunte archivos a sus respuestas. Le rogamos que
integre el texto en el cuerpo del mensaje. Puede responder usando
NetEtiquete que le ayudará a seguir la
conversación.http://es.wikipedia.org/wiki/Netiquette

Please, DO NOT send attachment files with your answers, just copy and
paste only the text you need to send into the body of your mails.
Repply using NetEtiquete. http://en.wikipedia.org/wiki/Netiquette

[Sergi Almacellas Abellana]

Post by Jordi Esteve
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,

[Raimon Esteve]

Post by Sergi Almacellas Abellana

Post by Jordi Esteve
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 ;-)

y Jordi y srvidor ya te hemos dado feedback de como lo puedes hacer si
no deseas crear nuevos tipos de pago

Post by Sergi Almacellas Abellana
- 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?)

[Jordi Esteve]

Post by Sergi Almacellas Abellana

Post by Jordi Esteve
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 ;-)

- 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
***@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel [phone]

[Jordi Esteve (Zikzakmedia)]

Post by Sergi Almacellas Abellana
Hola,
Acabo de darme cuenta que en una nuestra base de datos tenemos los
Nombre: Tipo C.C Clases de Tipo
Domiciliación bancaria Tercero A cobrar
Domiciliación bancaria Empresa A pagar
Efectivo Ninguno A cobrar
Efectivo Ninguno A pagar
Transferencia Bancaria Empresa A cobrar
Transferencia Bancaria Tercero A 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.

Post by Sergi Almacellas Abellana
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
Nombre: Tipo C.C (Pagar) Tipo C.C (Cobrar)
Domiciliación bancaria Empresa Tercero
Efectivo Ninguno A Ninguno
Transferencia Bancaria Tercer A 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
***@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel [phone]