[pyar] [OT][Django] Consulta más de diseño que de Django

Carlos Miguel FARIAS carlosmiguelfarias en gmail.com
Lun Sep 19 17:02:16 ART 2016


Deberías ver que datos te pide la AFIP para cada tipo de documento.
Debes tener en cuenta que en un documento comercial intervienen dos
personas (emisor y receptor), todos tienen fecha de emisión, recepción.
Para identificar un documento en general tienes letra, sucursal y número.
Eso sumado el emisor te da unicidad (para mi Pk, no me gustan los
autoincrementales para pk, salvo casos especiales).
Incluiría importe total neto e impuestos aplicables (sobre todo si es
responsable inscripto) y otros elementos necesarios (relativos a factura
electrónica)

Los documentos pueden ser pedido cliente, sirve como base para presupuesto,
si es un taller no veo necesario remito, salvo que venda repuestos. También
facturas, notas de débito y crédito (recibos)
O sea que en general, todos los documentos tienen una cabecera común (muy
similar) y detalles separados, pero con muchos datos comunes.

En cuanto el manejo múltiples mails, direcciones y teléfonos, lo
simplificaría a un campo text por cada uno, y usar renglones para cada uno.
No olvides cuit en los clientes y proveedores.

Es importante que converses con el mecánico que datos va a aprovechar del
sistema y con el contador que le va a servir o que otras necesidades
fiscales deberían controlarse.

Saludos: Miguel, Santa Rosa, La Pampa

El 19/09/2016 12:23, "Ricardo Daniel Quiroga" <l2radamanthys en gmail.com>
escribió:

> Hola
> Dependiendo la finalidad podrias mantenerlo en un unico tipo de documento
> generico si no vas a hacer mucho, ahora en cuestiones practicas
> creo lo mejor es separar en diferentes modelos ya que no es lo mismo una
> nota de credito, una factura, un remito etc aunque tengan
> algunos datos en comun, todo dependera de la finalidad que quieras darle,
> si es solo guardar los comprobantes lo primero, si quieres darle una
> finalidad mas contable y real vallas por lo segundo, parecera mas tedioso
> pero los modelos de como es una factura por ejemplo y que informacion lleva
> esta definido
> ya en ves de liar como hacer andar todos los tipos de comprobante en un
> unico modelo.
>
> Saludos
>
> El 19 de septiembre de 2016, 8:31, Rafael E. Ferrero <
> rafael.ferrero en gmail.com> escribió:
>
>>
>> Estoy haciendo un mini-proyecto de gestión para el taller de mi Cuñado
>> (seguro hay más completos y mejores que el que puedo hacer yo, pero me
>> sirve en lo personal)
>>
>> Pensé en este modelo <https://s12.postimg.io/nl1sqyvnx/image.png>:
>> *(Aclaración: Entity es clase base, Person y Company heredan de ella. Se
>> que puede ser un cuello de botella en rendimiento ya que Entity no es
>> Abstract pero lo necesito así para que ContactMethod y Document se
>> relacionen con un ForeignKey a ella)*
>>
>> En Entity guardo Clientes, Proveedores y hasta a la misma empresa que
>> usara el sistema... todo sería una Entidad.
>> Cada Entidad puede ser o una Persona Física (vos, yo, etc) o una Persona
>> Jurídica (una empresa, una organizacion, etc)
>> Cada Entidad podría tener N métodos de contacto (n direcciones postales,
>> n teléfonos y le podría agregar n emails, n urls, etc agregando nuevas
>> clases que extiendan de ContactMethod)
>>
>> Pretendo poder guardar todos los comprobantes (Recibos, Notas de Crédito,
>> Notas de Débito, Facturas, etc ya sean tanto de Compra como de Ventas) en
>> Document.
>> Pero no sé si es correcto lo que prentendo...¿o me convienen tener una
>> clase por cada tipo de comprobante?
>>
>> Se entiende que cada comprobante tiene un "comportamiento" administrativo
>> distinto... por ejemplo una Factura de Compra me incrementaría la cantidad
>> de producto, y una de venta me lo descontaría,  un Recibo que emite la
>> empresa es una cobranza que reduce la deuda del cliente, etc, etc.
>>
>> En el modelo que yo planteo, Si creo métodos dentro de la clase Document
>> que haga algo respecto al tipo de comprobante ¿Sería Correcto? ¿o debería
>> hacerlo en la clase DocumentType?
>> (Ej. Si el tipo de Comprobante es Factura y el Emisor no es la Entidad
>> "dueña del sistema" sería una Factura de Compra y como tal en Product
>> debería sumar a la existencia tantas veces como se indicaría en Row... al
>> revés sería si el Emisor ES la Entidad "dueña" del sistema... y así por
>> cada tipo de comprobante)
>>
>> ¿No sé si estoy encarando bien este diseño? ¿Qué me recomendás? ¿Qué
>> sería lo más conveniente para registrar los comprobantes (tanto fiscales
>> como una factura o internos como un recibo)
>>
>> Gracias de antemano !!!
>>
>> Rafael E. Ferrero
>>
>>
>> _______________________________________________
>> pyar mailing list pyar en python.org.ar
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>>
>
>
>
> --
>
> Ricardo Daniel Quiroga
>
>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20160919/dd4e2bdb/attachment-0001.html>


Más información sobre la lista de distribución pyar