Carga de proyectos, requerimientos mínimos.

Última revisión Martín Viegas, 30/07/2009

Para poder reproducir los errores cargados, los programadores necesitamos que los proyectos
sean claros y con ciertos datos imprecindibles (y otros deseables). Esto nos va a ayudar a todos a
que una vez cargado el proyecto, disminuya el flujo de información de un lado a otro, ya que si el
proyecto es claro, no hay que estar consultando a la persona que lo cargó.

1) Que el título sea un resúmen descriptivo del problema (no sirve un “Error en Ventas”).
2) Siempre cargarle un establecimiento, sino vino de un cliente, cargarle IMS3 (IMS – Internos).
Esto nos da una idea de qué base de datos usar, o a quien consultar.

En la solapa de Detalles y Datos Anexos:

3) Además del tipo de letra y el color distintivos, poner SIEMPRE el nombre de la persona que
escribe (en lo posible la fecha también, para cuando se arman conversaciones).
4) Poner la ruta completa a la opción de menú donde está el error, tener en cuenta que muchos
de nosotros no sabemos donde estan muchas de las opciones, y además, siempre se estan
cargando opciones nuevas. Ej.:
Inf. de le Empresa\Gestion Compras\Compras\Requisiciones\Asignaciones\Asignación y Desasignación
Manual
Esto se hace facilmente apretando Ctrl+Alt+O sobre la opción de menú.
5) Decir con qué Base de datos se da el error. Si el error se da en cualquiera que se utilice,
decirlo. Sino, avisar en que base y si está o no en el FTP de clientes.
6) Dar los pasos para reproducir el error (o los errores). Muchas veces pasa que usando
determinado comprobante, determinado cliente, o tales artículos, se da el error. No podemos
estar adivinando.
Un ejemplo podría ser: Con el comprobante XXA, y el cliente Pepe, al hacer click en la grilla del
detalle sale el error ‘ambiguos field name’.

En la solapa de Archivos Asociados

7) Los datos anexos colocarlos en el FTP, así todos podemos acceder a las imágenes,
documentos, Bases, etc que se quiera. Ahora tambien se puede usar la Wiki y el Scribd. Si
usan su propia máquina o el Server (de Bs As o La Plata), el resto no puede acceder y tenemos
que estar pidiendo los archivos (esto, cuando estan todos ocupados, hace que se pierda tiempo
en lo que hay que usarlo: reproducir el error y arreglarlo).
Un ejemplo de cómo se puede dar una ruta directa al archivo, para que comience a bajarlo es:
ftp://quilate.ims-soluciones.com.ar:quila@ftp.ims-
soluciones.com.ar/DESARROLLO/Martin/ERR_LP/Filtro_mal.jpg
Si se fijan, en el mismo link se da el usuario y la contraseña para acceder al archivo directamente.
El formato es: ftp://usuario:clave@direccion completa

8) Cuando sale un error de una consulta (query) normalmente sale el error y en el detalle está el
sql ejecutado. Esto facilmente se puede copiar a un txt o escribirlo directamente en el detalle
del proyecto.
9) Si el error que sale es del Eurekalog se puede pasar a txt facilmente (ver documento sobre esto:
Como guardar datos de un error en Quilate (EurekaLog))

Como último punto, (y el más importante) usen la lógica y el sentido común. No se puede hacer
una guía de todos los casos posibles de una carga de un proyecto. Cuando terminen de cargar el
proyecto, léanlo y piensen realmente si se entiende lo que quisieron poner, si no queda claro,
vuelvan a redactar lo que esté mal.

Resumiendo los puntos:

1)Título descriptivo.
2)Cargar establecimiento.
3)Nombre y fecha en comentarios.
4)Ruta de la opción de menú.
5)Base con la cual se hacen las pruebas.
6)Pasos detallados para reproducir el error.
7)Datos anexos en ftp, wiki y scribd.
8)Copiar la query.
9)Copiar el EurekaLog.
10)Usar la lógica y el sentido común.