EGA Futura » Capacitación y Soporte
Un movimiento de caja es cada entrada o salida de dinero en efectivo anotada en el momento en que ocurre.
Parece trivial, pero es la unidad más pequeña del control financiero: si el movimiento no se registra, deja de existir a los pocos días.
La memoria de quien cobró o pagó no sirve como respaldo, y por eso el registro tiene que ser inmediato y no reconstruido.
Un importe suelto no dice nada: hacen falta al menos la fecha, el importe, el concepto y quién lo autorizó.
El concepto es el que después permite agrupar, comparar meses y detectar que un gasto chico se volvió grande sin que nadie lo notara.
Y el comprobante es lo que convierte una anotación en una operación verificable frente a un tercero.
El arqueo consiste en contar el dinero físico y compararlo contra el saldo que dicen los registros.
Cuando las dos cifras coinciden, los movimientos del período están bien cargados.
Cuando no coinciden aparece una diferencia de caja, que puede ser un vuelto mal dado, un movimiento sin registrar o un comprobante traspapelado.
La diferencia no se tapa: se registra como tal y se investiga, porque una diferencia repetida siempre tiene una causa concreta.
La caja chica es un monto acotado que se deja disponible para gastos menores que no justifican una transferencia.
El esquema más usado es el de fondo fijo: se define un importe, se gasta contra comprobantes y cada tanto se repone exactamente lo gastado.
La virtud de ese esquema es que el fondo siempre vuelve al mismo número, lo que hace evidente cualquier faltante.
Una cuenta bancaria genera su propio registro: el extracto llega igual, aunque nadie anote nada.
El efectivo no tiene esa red de seguridad, y por eso el único registro que existe es el que alguien se toma el trabajo de cargar.
Esa asimetría explica por qué las empresas tienden a reducir el manejo de efectivo hasta el mínimo que la operación tolere.
Acá hay una confusión frecuente que conviene despejar temprano.
El movimiento de caja registra cuándo se movió el dinero, no cuándo se generó la obligación de pagarlo o el derecho a cobrarlo.
Una venta a crédito ya es resultado del mes en que se facturó, aunque el dinero entre recién dos meses después.
Por eso una empresa puede ser rentable y quedarse sin efectivo al mismo tiempo, que es una de las formas más comunes de cerrar un negocio que funcionaba.
Hay herramientas de software que llevan la tesorería y la contabilidad de forma integrada, como el ERP en la nube de EGA Futura.
Conviene empezar por lo más importante, que es lo que hoy existe y lo que no.
El ERP tiene un objeto de Cuentas de tesorería, y la caja es uno de los tipos que ese objeto admite.
Lo que todavía no está construido es el objeto que guarde cada movimiento, con su fecha y su importe.
O sea que hoy la caja se puede definir y vincular con la contabilidad, pero el registro movimiento por movimiento es una pieza pendiente.
El campo Tipo admite exactamente tres valores: Banco, Caja y Tarjeta de crédito.
Esa lista revela el criterio de diseño: tesorería agrupa todo lugar donde hay dinero disponible, sea efectivo, saldo bancario o línea de crédito.
El campo es obligatorio, así que ninguna cuenta de tesorería puede quedar sin clasificar.
Cada cuenta de tesorería exige una cuenta contable asociada, y esa exigencia no es un detalle burocrático.
Es lo que garantiza que ninguna caja quede fuera de los libros, que es exactamente el problema que se busca evitar.
Una caja sin cuenta contable sería dinero de la empresa que la contabilidad no ve.
Existe una casilla llamada Cuenta principal que sirve para señalar cuál se usa por defecto.
Es útil cuando hay varias cajas o varias cuentas y conviene que una quede propuesta primero.
La casilla no impide marcar más de una, así que la regla de uso hay que fijarla en el procedimiento interno.
Hoy se puede definir las cajas, numerarlas y conectarlas con el plan de cuentas.
Lo que todavía no se puede es cargar movimientos dentro de esas cajas ni obtener un saldo calculado por la Plataforma.
La aplicación de tesorería es una de las cinco en construcción activa, así que esta es una de las zonas donde más cambios se esperan.
Que una pieza falte hoy no significa que no vaya a existir, y conviene volver a revisar la estructura antes de diseñar un procedimiento sobre ella.
La caja guarda dinero en efectivo y el banco guarda saldo en una cuenta de una entidad financiera.
La diferencia práctica es el respaldo: el banco genera su propio extracto y el efectivo solo tiene el registro que alguien carga.
En el ERP los dos son valores del campo Tipo dentro del mismo objeto de Cuentas de tesorería, junto con Tarjeta de crédito.
La diferencia se registra como diferencia y se investiga, en lugar de ajustar el saldo para que coincida.
Las causas más comunes son un vuelto mal dado, un movimiento sin cargar o un comprobante traspapelado.
Una diferencia que se repite todos los meses siempre tiene una causa concreta y localizable.
Todavía no, porque no existe un objeto de movimientos vinculado a la cuenta de tesorería.
Lo que sí se puede es definir las cajas, numerarlas y asociarlas con su cuenta contable.
La aplicación de tesorería está en construcción activa, así que conviene revisar la estructura antes de dar por firme esta limitación.
Porque el resultado y la caja miden momentos distintos.
Una venta a crédito genera resultado el mes que se factura, pero el dinero puede entrar mucho después.
Si mientras tanto hay que pagar sueldos y proveedores, la rentabilidad no alcanza para cubrir el desfase.
El objeto se llama EGAFutura__Cuenta_tesoreria__c y su etiqueta es Cuenta de tesorería.
Tiene 5 campos personalizados de EGA Futura, lo que lo convierte en uno de los objetos más pequeños del área financiera.
No tiene tipos de registro definidos.
Conviene decirlo antes que nada: en la organización no hay ningún objeto de movimientos de caja ni de movimientos de tesorería.
La búsqueda de campos con la palabra caja en toda la organización devuelve únicamente el valor Caja dentro de una lista de selección y el valor Caja de ahorro en otra.
Quien necesite un libro de caja hoy tiene que asumir que esa pieza no está construida.
EGAFutura__Tipo__c, lista de selección, no admite valor nulo.
EGAFutura__Cuenta_contable__c, búsqueda hacia EGAFutura__Cuenta_contable__c, tampoco admite valor nulo.
Es una decisión de diseño poco habitual: una búsqueda obligatoria fuerza a que toda cuenta de tesorería esté imputada antes de poder guardarse.
EGAFutura__Tipo__c admite Banco, Caja y Tarjeta de crédito.
La etiqueta coincide con el valor almacenado en los tres casos y no hay valor predeterminado.
EGAFutura__Cuenta_principal__c, casilla de verificación.
EGAFutura__Numero_cuenta__c, texto de 120 caracteres.
EGAFutura__EGA_Futura_ID__c, número automático.
El objeto no tiene campos fórmula ni campos de resumen, así que no hay saldo calculado por la Plataforma.
Tampoco existe hoy ningún campo en toda la organización que apunte hacia este objeto, o sea que ningún otro registro se imputa todavía a una cuenta de tesorería.
Para cuentas bancarias existe un objeto aparte y mucho más completo, EGAFutura__Bank_Bank_Account__c, con 16 campos personalizados.
Conviene no confundirlos: uno modela la cuenta bancaria en detalle y el otro agrupa todo lugar donde hay dinero disponible.
Todo lo anterior se verificó contra la organización de desarrollo el 9 de agosto de 2026.
La aplicación de tesorería es una de las cinco en construcción activa, junto con las de impuestos, contabilidad, ventas y compras.
Que un objeto no exista hoy no prueba que no vaya a existir, así que conviene releer la estructura antes de apoyarse en este detalle.