[Php-avanzado] SRS dudas y aclaraciones

[Leonardo Tadei - Pegasus Tech Supply]

Hola Favio!

El dom, 02-08-2009 a las 21:18 -0300, Favio Lazzarini escribió:
> Leonardo: 
> 
> Te mando algunas aclaraciones mas, se me esta llenando la cocina de
> humo. Solo queria un sistemita que imprimiera un papelito con lo que
> me debe el fulano, un poco mas y tengo que registrarlo en afip.

	Te entiendo... es como si alguien te dijera que quiere que le hagas una
casita, y vos que enterarte qué comodidades tiene, medio por la fuerza,
pero te dicen que "un lugar para dormir, uno para comer y un baño"...
pero resulta que esto no define si es un momoambiente o si tendrá
habitaciones, de qué son los pisos, que terminación llevan las paredes,
los techos, y tenés que ir preguntando cada cosa antes de hacer nada.
	Después de ese proceso desgastador, en el que entregaste un dormitorio,
un baño y un comedor (y le agregaste por tu cuenta una puerta, porque no
te la pidieron pero era obvia) el cliente te mira sorprendido y te
pregunta por la cocina, porque para él era obvio que si hacía falta un
lugar para comer, también había que cocinar, y te comenta que no le
caben los skies en el roperito que le hiciste, y que no te dijo que
tenía porque ese es un tema personal que nada tiene que ver con las
casas.
	Ah! y además tenía pensado hacer un duplex y vos le usaste todo el
terreno!

	Puede ser un sistemita minúsculo (aunque ninguno de facturación lo es),
pero si no está definido el "qué", comprar y vender puede hacerse de
tantas formas parecidas pero no iguales que al no definirlo vas a "hacer
la casa" 3 veces... y vos solo querías un lugarcito para vivir.


> > TABLE `pagos` y TABLE `det_pagos` tienen algo que no me cierra. Se
> > registra un pago y después se registra el detalle de un pago? Puede
> un
> > pago tener varios detalles? qué significa que los tenga?
> > No entiendo esto.
> 
> > 
> 
> > Un pago tiene un detalle, pero no cancela una factura.
> 
>  
> 
>       Estoy de acuerdo con esto. Pero si un pago tiene un detalle (y
> no
> 
> cancela una factura) parecería que  el pago _es_ el detalle y sobra
> una
> 
> tabla.
> 
>  
> 
> Te entiendo, osea que si un cliente paga y no llega a pagar ni una
> factura, a que cosa le imputo el pago, bueno la respuesta es NO SE.
> 
> Agradeceria que me indiques como se realiza segun las reglas del Buen
> Arte.

	Con gusto puedo ayudarte con el "como"... pero necesito saber el "qué".
	Podés tener facturas (debe) y recibos/pagos (haber); podés cancelar
solo facturas enteras; podés cancelar facturas parciales en varios pagos
hasta llegar al total; podés en un pago cancelar varias facturas y
relacionar el pago con cada factura afectada...


> > TABLE `productos`
> >       si va el `id_iva` entonces el `iva` no tiene sentido...
> > no es conveniente dejar plasmada la foto de cunando se realizo la
> > factura que tasa tenia ese iva al momento de haberlo facturado?
> 
>  
> 
>       Sí es conveniente, pero esto es para las "boletas". Esta es la
> tabla de
> 
> Productos...
> 
> No se que queres decirme aca, pero, te cuento como viene la mano de
> nuevo con este punto.
> 
> El id_iva es solo para saber que tipo de iva tiene el producto a la
> hora de ser facturado
> 
> Ejemplo partes informaticas lleva el 10,5%. Por eso lo puse en la
> tabla de productos.

	Esto es correcto.
	Pero también tenés iva y tasa_del_iva en la tabla de detalles de la
factura, y esto es lo que no tiene sentido.


> > TABLE `proveedores`
> >       seguro que todos no nulos? 
> 
> > 
> 
> > No se que queres decir?
> 
>  
> 
>       Definiste todos lo campos como "not null", entonces si no tenés
> por ej
> 
> el teléfono, tenés que inventar uno o no podés cargar al Proveedor.
> 
>       Queda poco práctico o te obliga a inventar.
> 
>  
> 
> Mira yo cargo y aunque esten vacios me los carga igual, es veradad que
> quedo asi sin darme cuenta y lo cambiaré cuando logre que el sistema
> me acepte los cambios qyue les pido, ahora esta mañero y no quiere.

	Ok. Tal ves te esté fallando por los "not null"...

> > Los datos de las cabeceras de los comprobantes están pobres: no
> tienen
> 
> > tipo de comprobante, nro con formato fiscal (aunque no lo uses ahora
> 
> > esto puede facturar de verdad en un futuro), etc.

> > No hice las cabeceras aun, pero el tipo de factura va a depender del
> 
> > cliente a quien se le factura
> 
>  
> 
>       Pero Favio! A un Responsable Inscripto se le pueden emitir
> facturas A o
> 
> B si sos Inscripto o C si no lo sos.
> 
>       Con la categoría impositiva del cliente no alcanza para
> determinar el
> 
> tipo, y además, si el cliente cambia de categoría impositiva le
> cambiás
> 
> el pasado?
> 
>  
> 
> Todavia no llegue a eso, no te anticipes, tenes razon que a un Resp
> Inscr. (Flor de gil que se pierde el IVA) . Tambien se le puede hacer
> b si lo solicita. Veremos como.

	A veces no es por gil, sino por un tema legal: un Resp Insc no puede
tener facturas de cosas que no se correspondan con su actividad
principal... o por qué creés que casi ningún Inscripto pide factura de
la nafta? Sencillamente porque cosas como combustibles, ropa o comidas
no se corresponden con la mayoría de las actividades nomencladas.

> Pregunta: ¿que optra cosa es necesaria para saber que tipo de factura
> hay que hacerle a nuestro cliente además de su categoria impositiva?

	Ninguna: el sistema propone A, B o C según corresponda, pero el usuario
debe poder cambiar una A a una B.
	Igual, la marte importante en esta etapa es: dónde guardás si la
factura es A, B o C?


> > > 10- El sistema debe emitir estado de Stock
> 
> > >             Atributos del informe :
> > >             fecha emision, nombre producto, codigo prod.,
> cantidad, 
> > > precio parcial(seleccionable), monto de capital(seleccionable).
> >   Vas a tener que definir el precio de qué lista es, o si es de
> > todas.
> > Aca me exprese mal:
> 
> > 
> 
> > El stock me informa solo el precio de costo, para ver el capital
> 
> > (meramente informativo, para poder hacer un balance de caja.
> 
> > 
> 
> > Digamos tengo $5000 en stock y $3000 en Cta Cte mi capital es de....
> 
>  
> 
>       Entiendo... pero en dónde estás guardando el "costo" del
> producto???
> 
> El costo del producto lo guarde en la tabla precios (ahora que lo
> pienso me parece que esta mal) no?

	Sí, está mal: si el costo depende únicamente de la clave primaria del
producto, entonces va en la tabla Productos...


>       Lo vi, lo que no veo es cómo se hace para agregar una nueva
> lista de
> 
> precios, ni cómo va a adaptarse el formulario de alta para trabajar
> con
> 
> las nuevas listas que se agreguen o borren.
> 
>  
> 
> Si me falta los scrip de altas y bajas de listas de precios eso va a
> entrar por los menus de miscelanios

	Ok... las listas se dan de alta en "miscelaneos"... pero no respondés
mi pregunta: cómo sigue funcionando el alta de Productos ahora que hay
una lista de precio más??? Lo previste?

> Y se visulizan cuando automaticament al dar de alta a un cliente.
> 
> Pregunta? (aca me entierro para toda la tesis) que pasa si doy de baja
> a una lista donde estas adheridos varios clientes?

	Esta es fácil: hay solo dos caminos a seguir. O cuando se borra una
lista se chequea si algún cliente la usa, y si la usa al menos uno,
impedís que se borre; o borrás la lista y reasignás todos los clientes a
alguna existente.


> > Obviamente me faltaria una entrada mas restingida donde pueda
> agregar
> 
> > categorias impositivas, listas de precios, loscalidades, provincias,
> 
> > paises, , ver mails y otros miscelanios
> 
>  
> 
>       Esto escribilo si querés, ya que después lo restringiremos con
> los
> 
> permisos del usuario, que son transversales a toda la funcionalidad.
> 
>  
> 
> Me parece que no voy a escribir mas, comunicate con mi abogada. Me
> acojo al derecho de no declarar. jaja

	Jajaja!!! Me refería a que vayas escribiendo esa parte del programa,
porque esas tablas es muy difícil que estén mal.

	Seguimos!

-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key