Búsquedas frecuentes
Tutoriales actualizados
Una rendición de gastos es el conjunto de comprobantes que una persona reúne para justificar el dinero que puso de su bolsillo o que se le adelantó por cuenta de la empresa. Agrupa varios gastos sueltos de un mismo período en un solo documento, para que se revisen y se reintegren de una vez y no de a uno. En el ERP de EGA Futura la Rendición de gastos es un objeto propio con empleado, área funcional, inicio y fin de período, propósito, total y un estado que recorre Borrador, Enviado, Aprobado y Pagado.
Una rendición de gastos es el conjunto de comprobantes con el que una persona justifica plata que puso o que se le adelantó por cuenta de la empresa.
Su rasgo distintivo es que agrupa: no es un gasto suelto sino una carpeta de gastos de un mismo período.
Ese agrupamiento es todo el punto, porque convierte veinte revisiones chicas en una sola.
Un gasto es un hecho: una comida, un taxi, un pasaje, un insumo.
La rendición es el sobre que los contiene y les pone un marco común.
Ese marco aporta tres datos que un gasto suelto no tiene: de quién es, a qué período pertenece y para qué fue todo el conjunto.
Con esos tres datos el reintegro se vuelve una sola operación de tesorería en lugar de veinte.
La arma quien incurrió en los gastos, casi siempre un empleado que viajó o que compró algo urgente.
Cada línea necesita su comprobante, su fecha, su importe y una descripción que se entienda sin preguntar.
El comprobante es la pieza crítica: sin respaldo, un gasto es una afirmación y no un hecho.
Por eso la mayoría de las empresas exige el original o su imagen antes de reintegrar nada.
Dentro de una misma rendición suelen mezclarse cosas que no deberían mezclarse.
Está el gasto claramente empresario, el gasto que se le va a refacturar a un cliente y el gasto personal que se coló por error.
Separarlos temprano evita el problema más incómodo del circuito, que es descubrir la mezcla después de haber pagado.
La rendición cubre un tramo de tiempo, y ese tramo define contra qué período contable se imputan los importes.
Un gasto de fin de mes rendido recién a mediados del siguiente puede terminar cargado en el mes equivocado si nadie mira la fecha del comprobante.
De ahí que la fecha de cada gasto y la fecha de la rendición se registren por separado.
La rendición empieza abierta, mientras la persona sigue sumando comprobantes.
Cuando se cierra, se envía para que alguien la revise.
Si se aprueba, pasa a pago y termina reintegrada; si no, vuelve con observaciones.
Esa etapa de revisión merece su propio criterio y está explicada en Aprobación de gasto.
Lo primero es previsibilidad de caja, porque los reintegros dejan de aparecer de golpe.
Lo segundo es información: agrupadas por área y por período, las rendiciones muestran dónde se va el dinero chico, que sumado deja de ser chico.
Lo tercero es respaldo, porque el conjunto de comprobantes queda archivado junto con la decisión que lo aprobó.
El hub de Gastos, viáticos y rendiciones ubica este concepto dentro de un proceso empresarial.
En Compras y Gastos bajo control: eProcurement para empresas medianas vemos cómo se aplica a decisiones y tareas concretas.
En el ERP de EGA Futura la Rendición de gastos es un objeto propio, distinto del Gasto y ubicado un nivel por encima de él.
Cada Gasto puede apuntar a una rendición, y esa relación es la que arma la carpeta.
El campo Empleado identifica a la persona que la presentó, apuntando al registro de Empleado.
El campo Área funcional permite imputar el conjunto al sector que corresponde.
Con esos dos campos alcanza para responder de quién sale el pedido y quién absorbe el costo.
La rendición delimita su alcance con dos fechas: Inicio período y Fin período.
Ese par es lo que la convierte en un documento de tramo y no de un día.
Cada gasto conserva además su propia Fecha del gasto, así que siempre se puede distinguir cuándo ocurrió de cuándo se rindió.
El campo Propósito es de texto largo y es donde se explica para qué fue el conjunto.
El campo Total guarda el importe en la moneda del registro.
El campo Estado muestra cuatro valores: Borrador, Enviado, Aprobado y Pagado.
Las rendiciones nuevas arrancan en Borrador de forma automática.
Dos fechas acompañan ese recorrido: Fecha envío y Fecha aprobación.
La distancia entre ambas es una medida simple y útil, porque expone cuánto tarda la empresa en responderle a su propia gente.
Las etiquetas de esta lista se muestran en español pero los valores almacenados están en inglés.
Eso no cambia nada para quien usa la pantalla, y sí importa para cualquier filtro hecho por API o por código.
Son las dudas de quien ordena los gastos de un viaje o de un mes: qué hacer sin comprobante y cómo tratar los importes en varias monedas.
El gasto es el hecho individual y la rendición es la carpeta que agrupa varios.
Una rendición sin gastos adentro no tiene contenido, y un gasto sin rendición igual existe y se puede aprobar por sí solo.
Queda marcado como gasto sin respaldo, que es una situación distinta de un gasto normal.
Cada empresa define su propia política al respecto, y las exigencias de respaldo documental las fija la legislación de cada país.
Es habitual en viajes al exterior, donde los comprobantes vienen en la moneda del lugar.
El punto a resolver es el tipo de cambio: conviene fijar de antemano qué cotización se aplica y de qué fecha, para que el reintegro no dependa de la negociación de cada caso.
Lo más práctico es cerrarla junto con el cierre del mes o al terminar el viaje que la originó.
Dejarla abierta indefinidamente hace que los comprobantes viejos caigan en un período contable que ya se cerró.
El nombre de API del objeto es EGAFutura__ExpenseReport__c y su etiqueta es Rendición de gastos.
El vínculo con cada gasto vive del lado hijo, en el campo EGAFutura__ExpenseReport__c del objeto EGAFutura__Gasto__c, cuya etiqueta es Rendición.
La persona es EGAFutura__SubmitterEmployee__c, un Lookup hacia EGAFutura__Empleado__c con etiqueta Empleado.
El tramo de tiempo son EGAFutura__ReportPeriodStart__c y EGAFutura__ReportPeriodEnd__c, ambos de tipo Date.
Las fechas del circuito son EGAFutura__SubmittedDate__c y EGAFutura__ApprovedDate__c.
El importe es EGAFutura__TotalAmount__c, de tipo Currency con dos decimales.
El texto largo es EGAFutura__Purpose__c y la imputación es EGAFutura__AreaFunctional__c.
El campo EGAFutura__Status__c muestra etiquetas en español pero guarda los valores en inglés.
La correspondencia exacta es Borrador igual a Draft, Enviado igual a Submitted, Aprobado igual a Approved y Pagado igual a Paid.
El valor por omisión es Draft.
Cualquier consulta SOQL, fórmula o regla de validación tiene que comparar contra el valor en inglés, nunca contra la etiqueta visible.
Los dos objetos usan campos con el mismo propósito pero distinto nombre de API en algunos casos.
El total de la rendición es TotalAmount__c mientras que el del gasto es Monto__c, detalle que conviene tener a mano al mapear datos entre ambos.
Los términos del glosario que empiezan igual que este. Las demás letras se abren acá mismo, sin salir de la página.
Ventas, compras, inventario, finanzas y equipo, con la información al día y disponible desde cualquier dispositivo. Funciona en la nube, así que no hay servidores que mantener.
