Una fecha con hora parece un dato simple hasta que dos personas la miran desde países distintos.
Ahí aparece la pregunta incómoda: a qué hora pasó realmente, si la pantalla de cada una dice algo diferente.
La zona horaria es la respuesta, y entenderla evita discusiones que suelen terminar en una corrección de datos innecesaria.
Conviene separar dos cosas que se confunden todo el tiempo.
El sistema almacena el instante en una referencia común, la misma para todos los usuarios y para todos los países.
Ese valor no cambia nunca: es un punto exacto en la línea del tiempo, sin depender de dónde estaba quien lo generó.
La pantalla toma ese instante y lo traduce a la zona horaria configurada en el usuario que está mirando.
Por eso una operación registrada a las nueve de la mañana en Buenos Aires aparece a las seis de la mañana para alguien configurado en Ciudad de México.
No hay dos datos ni una copia desincronizada: hay un solo dato y dos traducciones correctas.
Es el efecto que más consultas genera y tiene una explicación sencilla.
Cuando una operación se registra cerca de la medianoche, la traducción a otra zona puede caer en el día anterior o en el siguiente.
Un pedido cargado a las once de la noche del lunes en Argentina se lee como del lunes por la tarde en México, pero uno cargado a la una de la mañana del martes se puede leer como del lunes por la noche.
Cuando ese registro entra en un informe agrupado por día, la fila cae en un día distinto según quién ejecute el informe.
El total general nunca cambia, y lo único que se mueve es el corte entre un día y el siguiente.
No todos los campos de fecha se comportan igual, y la diferencia explica buena parte de los casos raros.
Guarda un instante y por eso se traduce a la zona de cada usuario.
Es el tipo que usan la fecha de creación de un registro, la última modificación y la hora de una llamada.
Guarda un día de calendario y se muestra igual para todo el mundo, porque no representa un instante.
La fecha de emisión de una factura o la fecha de vencimiento de un contrato pertenecen a esta familia, y esa es la razón por la que nunca se corren.
Saber a qué familia pertenece cada campo de fecha resuelve casi todas las dudas antes de que se conviertan en un pedido de soporte.
Hay dos configuraciones y cumplen funciones distintas.
La de la organización es el valor por defecto, el que hereda cada usuario nuevo cuando se lo da de alta.
La del usuario manda sobre esa: es la que decide qué ve esa persona en su pantalla, en sus informes y en los correos que recibe del sistema.
Alguien que se muda de país o que pasa una temporada larga en otra sede tiene que ajustar la suya, o va a seguir leyendo todo con la hora de origen.
Guardar el instante en una referencia común y traducirlo al final es lo que permite que una empresa distribuida trabaje sobre los mismos datos.
Cada persona ve las horas en el marco que usa para organizar su día, sin que nadie tenga que hacer cuentas mentales.
Y como el dato guardado es uno solo, la auditoría de cuándo ocurrió cada cosa no depende de dónde estaba quien lo miró.
Es el mismo criterio con el que la Plataforma EGA Futura trata la moneda de cada registro.
La zona horaria acompaña a cada usuario del ERP y se aplica en todas las pantallas sin que haya que hacer nada.
Se ve en la fecha de creación de un pedido, en la hora de un evento del Calendario, en el sello de la última modificación de un registro y en los avisos que llegan por correo.
Cada usuario tiene su zona horaria en su propia configuración, junto con el idioma y el formato de números.
Es un dato personal y no un permiso, así que cambiarlo no afecta a nadie más ni modifica ningún registro.
Quien viaja de forma permanente a otra sede ajusta ese valor una vez y toda la Plataforma pasa a hablarle en su hora local.
Un informe se ejecuta siempre con la zona horaria de quien lo abre.
Por eso conviene acordar de antemano con qué zona se mira un tablero de operación diaria, sobre todo cuando el corte del día define un objetivo comercial.
Cuando el indicador tiene que dar lo mismo para todo el equipo, la salida limpia es agrupar por un campo de fecha sin hora, que no se traduce.
La zona horaria por defecto de la Org, el formato regional y el comportamiento de los campos de fecha forman parte de la puesta a punto que hace EGA Futura.
La Org la administra EGA Futura, así que tu empresa no necesita un administrador propio para dejar todo esto bien resuelto desde el primer día.
El equipo del cliente describe cómo trabaja, en qué países tiene gente y qué indicadores tienen que cortar el día a la misma hora para todos.
Con esa información, EGA Futura configura los valores por defecto y define qué campos conviene que sean de fecha sola.
Es servicio incluido, y es la clase de detalle que evita meses de informes que no cierran entre sí.
Estas son las dudas que aparecen en cuanto un equipo empieza a trabajar desde más de un país.
Porque cada usuario tiene su propia zona horaria configurada y la pantalla traduce el mismo dato a cada una.
El instante guardado es uno solo y no cambió: lo que cambia es la forma de mostrarlo.
Comparar las dos pantallas y ver la diferencia exacta de horas suele confirmar que todo está funcionando bien.
Casi nunca hay datos mal cargados.
Los registros creados cerca de la medianoche caen en un día u otro según la zona de quien ejecuta el informe, así que el corte se mueve aunque el total general se mantenga.
Cuando el indicador tiene que dar igual para todo el equipo, conviene agrupar por un campo de fecha sin hora.
No se modifica ningún registro.
La zona horaria es una preferencia de visualización, así que solo cambia cómo se muestran las fechas y horas en la pantalla de esa persona.
Porque es un campo de fecha sola, que guarda un día de calendario y no un instante.
Ese tipo de campo se muestra igual para todos los usuarios, sin importar dónde estén.
El sistema lo contempla solo, porque cada zona horaria conoce sus propias reglas de cambio de hora.
Lo único que hace falta es que la zona del usuario sea la del lugar donde realmente trabaja, y no una cercana elegida al pasar.
Lo resuelve EGA Futura como parte del servicio, porque administra la Org.
Tu empresa describe en qué países opera y qué indicadores tienen que cortar el día igual para todos, y esa definición se implementa junto con el resto de la puesta en marcha del ERP en la nube.
Esta sección es para quien escribe requerimientos que involucran fechas o trabaja sobre la Org, y necesita distinguir bien cada tipo de campo.
La primera decisión de cualquier requerimiento con fechas es de qué tipo tiene que ser el campo.
| Tipo de campo | Qué guarda | Se traduce a la zona del usuario |
|---|---|---|
| Date | Un día de calendario | No, se muestra igual para todos |
| Date/Time | Un instante en el tiempo | Sí, se convierte al mostrarlo |
| Time | Una hora del día sin fecha | No, se muestra igual para todos |
| CreatedDate y LastModifiedDate | Un instante generado por el sistema | Sí, se convierte al mostrarlo |
Son dos niveles y el más específico gana, que es lo que suele sorprender al revisar por qué alguien ve otra hora.
| Nivel | Alcance | Nota |
|---|---|---|
| Zona horaria de la organización | Valor por defecto de la Org | Lo hereda cada usuario nuevo al crearse |
| Zona horaria del usuario | Solo esa persona | Manda sobre la de la organización |
| Configuración regional | Formato de fecha, número y moneda | Es independiente de la zona horaria |
| Idioma | Textos de la interfaz | También independiente de los dos anteriores |
Conviene tenerlo escrito, porque el criterio no es el mismo en todos los contextos.
| Contexto | Zona horaria que se aplica |
|---|---|
| Pantalla de Detalle y Vista de lista | La del usuario que mira |
| Informe o panel | La del usuario que lo ejecuta |
| Correo enviado por el sistema | La del usuario destinatario |
| Exportación a archivo | La del usuario que exporta |
Hay tres consecuencias que conviene anticipar al redactar el requerimiento, porque después son caras de revertir.
La primera es la elección del tipo de campo: un dato que representa un día de negocio conviene que sea Date y no Date/Time, porque así queda inmune a la zona de quien lo mira.
La segunda es que un filtro de informe sobre un campo con hora se evalúa en la zona del usuario que ejecuta, así que un pedido del tipo lo de ayer tiene que aclarar el ayer de quién.
La tercera es que las integraciones intercambian el instante en la referencia común, y la traducción ocurre recién en la pantalla, o sea que comparar un valor exportado contra lo que se ve en la ficha exige tener presente el desfasaje.
Decir esto en el pedido ahorra la vuelta más frecuente de todas, que es la de un tablero que da bien para una sede y mal para la otra.
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.
Quiero llevar mi Empresa a la Nube