Info General

Va algo de info sobre como funciona el sistema de Compras gestionado por Trac. El sistema está basado en tickets. Cada uno de estos representa una acción (pedido de cotización, pedido de compra, etc). Estos tickets son pasados de usuario en usuario, donde cada usuario lleva a cabo alguna acción y reasigna el ticket, o lo cierra. A lo largo del ciclo de vida de un ticket, el ticket va cambiando de dueño (asignación, reasignación), y de estado (abierto → autorizado → cerrado).

Propiedades de un ticket

• Tipo de ticket: Cotizacion, Compra, Informacion
• Prioridad: Urgente, Mayor, Importante, Cuando Puedas, Menor
• Estado: Abierto, Asigndo, Aceptado, Autorizado, Cerrado
• Dueño: la persona a cargo del ticket (va cambiando por reasignación)

Además de ir cambiando de estados (abierto, cerrado), los tickets tienen otras propiedades. Esto es esencial para poder agruparlos y poder hacer seguimientos, encontrarlos más facilmente y en definitiva, gestionar mejor las compras. Recuerden siempre que Trac es un sistema para desarrollo de software que estamos intentando adaptarlo lo mejor que podemos a compras.

Milestones / Subsidios

Los milestones sirven para agrupar tickets. Ese es el propósito original. En software development, serian 'releases'. En un sistema de compras, nuestra idea es usar los milestones para agrupar tickets por subsidio (fuente de financiamiento), o por alguna iniciativa (ej covid-19, cell sorter/FACS) donde haya varias fuentes de financiamiento, o de varios laboratorios. Si usamos los milestones de esta manera, podemos ir a la página de Subsidios y visualizar los tickets agrupados y el avance de compras de cada proyecto.

Los milestones tienen fecha de vencimiento (ej fin del subsidio), pero puede dejarse vacia. Los milestones o subsidios en Trac no tienen responsable o dueño.

Componentes / Laboratorios

Los componentes si tienen dueños. Asi que en este Trac la idea es complementar la idea anterior de milestones / subsidios, haciendo que los componentes sean laboratorios. Los componentes tienen responsables. De manera que es facil redireccionar automaticamente los tickets al responsable correspondiente si en el ticket se asigna el componente correspondiente.

Ciclo de vida de un ticket

A continuación van algunos ejemplos de acciones que se pueden hacer con tickets. A lo largo del ciclo de vida de un ticket, este puede cambiar de estado :

• Crear ticket (ej pedido cotización) ⇒ asignar a responsable (ej Ernesto) (estado: abierto, asignado)
  • Ernesto acepta la asignación ⇒ Pide cotización (estado: abierto, aceptado)
• Incorporar cotización (ej PDF, adjunto) a un ticket ⇒ reasignar a originante (el que hizo el pedido)
  • El dueño original del ticket acepta la reasignación (estado: abierto, aceptado)
• Pedir autorización / Firma ⇒ asignar el ticket a un firmante (ej Jefe de Grupo)
  • El jefe de grupo acepta la reasignación (estado: abierto, aceptado)
• Firmar / Autorizar ⇒ reasignar ticket a responsable de compras (ej Ernesto) (estado: firmado, reasignado)
• Hacer el pedido al proveedor ⇒ reasignar el ticket a responsable de Pago a Proveedores (ej Leonardo)
• Incorporar confirmacion de pago (PDF Factura, transferencia) ⇒ reasignar al responsable de Compras (ej Ernesto)
• Recibir el producto (PDF Remito) ⇒ Cerrar ticket

Un breve resumen lineal, podria ser algo como:

none -> nuevo -> asignado -> aceptado -> cotizacion -> autorizacion -> pedido -> pago -> recibido -> cerrado

Pero claro que la situación puede ser más compleja, porque es posible ir hacia atrás (pedir recotizar), reasignar tickets a otros usuarios, etc. A continuación se muestra un esquema completo de los estados y cambios de estado de un ticket.