

La aprobación de gasto es el momento en que alguien con autoridad decide si la empresa se hace cargo de un desembolso.
Suena a trámite, pero es el único punto del circuito donde todavía se puede decir que no.
Después de pagar, la conversación cambia de tema.
La rendición de gastos es el trabajo de quien gastó: juntar comprobantes y explicarlos.
La aprobación es el trabajo de quien decide: mirar eso y resolver.
Son dos actos distintos, con dos responsables distintos, y mezclarlos es lo que vacía de sentido al control.
Quien gasta no se aprueba a sí mismo.
Aprobar no es firmar: es responder cuatro preguntas concretas.
Si el gasto ocurrió de verdad, cosa que resuelve el comprobante.
Si corresponde a la empresa y no a la persona.
Si respeta las reglas internas de monto, categoría y autorización previa.
Y si hay presupuesto disponible en el área que lo absorbe.
Un rechazo sin motivo escrito genera dos problemas a la vez.
El primero es práctico: quien presentó el gasto no sabe qué corregir y vuelve a presentar lo mismo.
El segundo es de gobierno: sin motivo, nadie puede revisar después si el criterio fue parejo entre áreas.
Por eso el motivo de rechazo merece un campo propio y no un comentario suelto.
Hay una categoría intermedia que conviene no perder: el gasto real y honesto que igual se sale de la regla.
Una cena más cara de lo permitido, un taxi que debería haber sido colectivo, una compra sin autorización previa.
Marcarlo como incumplimiento, aunque después se apruebe por excepción, es lo que permite medir cuánto vale la excepción.
Si nadie lo marca, la política se erosiona sin que nadie note cuándo pasó.
Son dos estados distintos y confundirlos genera reclamos.
La aprobación reconoce la deuda con la persona.
El reembolso la cancela, y lo ejecuta tesorería según su propio calendario de pagos.
Registrar las dos fechas por separado es lo que permite responder la pregunta incómoda de cuánto se tarda en devolver la plata.
El criterio más común es por monto y por jerarquía, con escalones sucesivos.
El segundo criterio es por área, porque quien absorbe el costo es quien debería opinar.
El tercero es por tipo de gasto, ya que no se controla igual un pasaje que un activo.
Lo importante es que esos límites estén escritos antes y no se discutan caso por caso.
En el ERP de EGA Futura el circuito de aprobación vive dentro del propio registro de Gasto, no en un objeto aparte.
Eso significa que el gasto y su historia de decisión viajan juntos.
El campo Estado recorre cinco valores: Borrador, Enviado, Aprobado, Rechazado y Reembolsado.
Los gastos nuevos arrancan en Borrador de forma automática.
Aprobado y Rechazado son las dos salidas de la revisión, y Reembolsado marca que el dinero efectivamente volvió.
Cada paso del circuito tiene su propia fecha, y esa es la decisión de diseño más útil del objeto.
Están Fecha de envío, Fecha aprobación, Fecha rechazo y Fecha reembolso.
Con esas cuatro se miden los tiempos reales del circuito sin necesidad de reconstruirlos a mano.
Hay además una Fecha límite, pensada para los gastos que no pueden esperar.
El campo Aprobador guarda al usuario que resolvió.
El campo Motivo de rechazo es de texto largo y es donde se explica la negativa.
Del lado de quien presentó el gasto está el campo Empleado.
La casilla Tiene comprobante responde si el gasto está respaldado.
El campo Número de comprobante guarda su identificación.
La casilla Incumple política marca el desvío, y Detalle incumplimiento explica en qué consiste.
Esa pareja es la que permite aprobar por excepción sin perder el registro de que fue una excepción.
El objeto separa Monto, Importe neto e Importe IVA, lo que evita tener que despejar impuestos a mano.
Dos casillas definen la naturaleza del gasto: Gasto facturable y Gasto personal.
La imputación se resuelve con Área funcional, Tipo de gasto y Tarea de proyecto.
El pago queda documentado en Referencia pago y el gasto puede quedar unido a una Factura de compra o a una Rendición de gastos.
Las etiquetas de la lista de estados se muestran en español pero los valores almacenados están en inglés.
Para el uso diario en pantalla no cambia nada.
Técnicamente el sistema no lo impide, pero anula el control que la aprobación existe para dar.
La práctica habitual es que apruebe alguien distinto de quien gastó, y que los límites por monto queden escritos de antemano.
Se corrige la imputación sin borrar el registro de la decisión original.
Conservar la historia completa es lo que después permite explicar la diferencia ante una revisión interna.
Sí, y es una situación frecuente: el gasto fue real y necesario aunque se saliera de la regla.
Lo que corresponde es dejarlo marcado como excepción para que después se pueda medir cuántas hubo y de qué tipo.
No hay un número universal, pero sí una consecuencia clara: cuanto más tarda, más gente evita adelantar plata de su bolsillo.
Medir la distancia entre la fecha de envío y la de aprobación convierte esa percepción en un dato.
El circuito vive en el objeto EGAFutura__Gasto__c, cuya etiqueta es Gasto.
No hay un objeto separado de aprobación: los campos de decisión son campos del propio gasto.
El campo EGAFutura__Status__c muestra etiquetas en español y guarda los valores en inglés.
La correspondencia es Borrador igual a Draft, Enviado igual a Submitted, Aprobado igual a Approved, Rechazado igual a Rejected y Reembolsado igual a Reimbursed.
El valor por omisión es Draft.
Son cinco campos de tipo Date: EGAFutura__SubmittedDate__c, EGAFutura__ApprovedDate__c, EGAFutura__RejectedDate__c, EGAFutura__ReimbursementDate__c y EGAFutura__MilestoneDate__c.
El aprobador es EGAFutura__ApproverUser__c, un Lookup hacia User, y el solicitante es EGAFutura__SubmitterEmployee__c.
El motivo de rechazo es EGAFutura__RejectionReason__c, de texto largo.
El control de política son EGAFutura__IsPolicyViolation__c y EGAFutura__PolicyViolationNotes__c.
El respaldo son EGAFutura__IsReceiptAttached__c y EGAFutura__ReceiptNumber__c, este último un texto de 80 caracteres.
Los tres importes son EGAFutura__Monto__c, EGAFutura__NetAmount__c y EGAFutura__TaxAmount__c.
Las casillas de naturaleza son EGAFutura__IsGasto_facturable__c y EGAFutura__IsGasto_personal__c.
Las relaciones salientes son EGAFutura__ExpenseReport__c, EGAFutura__PurchaseInvoice__c, EGAFutura__Supplier__c, EGAFutura__Tipo_gasto__c, EGAFutura__Area_funcional__c y EGAFutura__Tarea_proyecto__c.
Al ser todas casillas de tipo Checkbox, las marcas de política y respaldo nunca son nulas, así que un filtro por falso incluye también a los registros que nadie revisó.