Toda empresa tiene una o dos reglas que no se parecen a las de nadie.
Un cálculo de comisión con tres excepciones, un límite de crédito que mira cuatro cosas a la vez, un modo propio de armar el precio según el cliente y la temporada. Esas reglas son, muchas veces, la ventaja competitiva de la empresa.
Apex es la herramienta con la que esas reglas dejan de vivir en la cabeza de alguien y pasan a ejecutarse solas dentro del sistema.
Es el lenguaje de programación de Salesforce, y corre en los mismos servidores donde están los datos del ERP.
Eso último no es un detalle. Un programa que corre al lado de los datos trabaja rápido, respeta los permisos de cada usuario y se ejecuta igual sin importar desde dónde se lo dispare.
La misma regla vale desde el navegador, desde el celular y desde un sistema externo que envía un pedido. No hay una versión para cada camino.
Conviene verlo desde la necesidad de negocio y no desde la herramienta.
| Lo que necesita la empresa | Ejemplo concreto |
|---|---|
| Un cálculo que cruza varios objetos | Un límite de crédito que mira facturas, cobranzas y pedidos abiertos a la vez |
| Un proceso sobre muchos registros | Actualizar precios sobre miles de productos en una sola corrida nocturna |
| Una integración con un sistema externo | Enviar cada comprobante al servicio fiscal y guardar la respuesta en el registro |
| Una validación que depende de otros registros | Frenar un despacho cuando el saldo total del cliente supera un tope |
| Una operación con muchos pasos encadenados | Armar la orden, reservar el stock y avisar al transporte en un solo movimiento |
La regla de oro de cualquier implementación sana es que el código llega último, no primero.
Un campo que se completa solo con una cuenta simple, un registro que no se guarda si falta un dato, una alerta cuando algo cambia de estado o una aprobación en dos pasos son casos de configuración.
Se implementan más rápido, se explican mejor y se modifican sin tocar nada delicado.
Cuando la regla mira datos de tres objetos distintos, cuando el volumen es grande, cuando hay que conversar con un sistema de afuera o cuando la lógica tiene excepciones encadenadas, ahí entra Apex.
La pregunta correcta nunca es si se puede programar, sino si hace falta. Y esa pregunta la responde el equipo que implementa, no quien pide.
Un programa en la Plataforma no corre en cualquier momento: siempre hay algo que lo dispara.
| Disparador | Cuándo entra en acción |
|---|---|
| Al guardar un registro | En el momento en que alguien crea, edita o borra algo |
| Por horario | Todas las noches, todos los lunes, el primer día del mes |
| A pedido | Cuando un usuario aprieta un botón en la pantalla |
| Por volumen | Cuando hay que recorrer una cantidad grande de registros en tandas |
| Desde afuera | Cuando otro sistema envía o pide información |
Programar sobre una plataforma compartida tiene reglas que en un desarrollo hecho desde cero no existen, y las tres que siguen protegen a tu empresa.
La primera es que todo código llega a producción con sus pruebas automáticas. La Plataforma las exige, así que una regla nueva no puede romper en silencio otra que ya funcionaba.
La segunda es que el código respeta la seguridad del sistema. Corre con permisos, no por encima de ellos, así que nadie ve por esa vía algo que no vería en pantalla.
La tercera son los límites de la Plataforma, que impiden que un proceso mal planteado consuma los recursos de todos. Obligan a resolver por lotes lo que es masivo, que además es la forma correcta de hacerlo.
Significa que la personalización deja de ser un proyecto de software y pasa a ser una conversación sobre cómo trabaja la empresa.
Nadie de tu empresa necesita aprender a programar ni contratar un equipo técnico para que EGA Futura ERP haga las cosas a su manera. Las capacidades de la Plataforma están descritas en las características de EGA Futura ERP.
EGA Futura ERP está construido sobre la Plataforma Salesforce, así que Apex es parte de sus cimientos y no un agregado.
La Org la administra EGA Futura, y eso incluye el código. Tu empresa define el requerimiento y el equipo lo implementa, lo prueba y lo mantiene.
Es una diferencia importante frente a la forma clásica de personalizar un ERP, donde la empresa termina contratando programadores o dependiendo de un consultor externo para cada cambio.
Acá el pedido se hace en el idioma del negocio. Alguien dice "necesitamos que el descuento máximo dependa de la antigüedad del cliente y de su saldo", y eso alcanza para empezar.
La conversación útil describe tres cosas: qué tiene que pasar, en qué momento tiene que pasar y qué hace el sistema cuando la condición no se cumple.
Con esas tres respuestas, el equipo decide si el caso se resuelve configurando o si conviene código, y esa decisión técnica no la carga tu empresa.
Es uno de los usos más frecuentes, porque casi ninguna empresa vive con un solo sistema.
El ERP conversa con servicios de facturación electrónica, con bancos, con tiendas en línea y con las herramientas que tu empresa ya usa. Ese intercambio se resuelve con automatizaciones y con Apex, según qué tan particular sea el caso.
El complemento de integraciones contempla hasta diez mil conexiones diarias entre automatizaciones y Apex, que es un volumen pensado para operaciones que sincronizan todo el día. Qué incluye cada edición está en la página de precios de EGA Futura ERP.
Estas son las preguntas que aparecen cuando una empresa se pregunta hasta dónde puede adaptar el ERP a su forma de trabajar.
No. El ERP se opera desde la pantalla, y Apex vive por debajo, resolviendo lo que la empresa pidió que ocurra solo.
El código lo escribe y lo mantiene el equipo de EGA Futura, así que tu empresa define el qué y el equipo resuelve el cómo.
Una automatización configurada se arma desde una pantalla, con condiciones y acciones, y cubre la mayoría de los casos.
Apex entra cuando la regla mira datos de varios objetos, cuando el volumen es grande o cuando hay que conversar con un sistema externo.
La Plataforma exige que todo código llegue a producción acompañado de sus pruebas automáticas, y esas pruebas se ejecutan también sobre lo que ya estaba.
Es una de las mayores diferencias frente a un desarrollo a medida hecho fuera de una plataforma.
El código corre respetando los permisos definidos, así que la seguridad del sistema se mantiene igual desde cualquier camino.
Se resuelve por lotes, que es la forma en que la Plataforma procesa volúmenes grandes sin afectar el trabajo de nadie.
Un recálculo masivo de precios o una actualización de saldos se corren de noche y a la mañana están listos.
Sí, y es uno de los usos más habituales. La conversación empieza por qué datos tienen que viajar, en qué dirección y con qué frecuencia. Conviene plantearlo en una demostración del ERP.
Para quien escribe requerimientos o trabaja sobre la Org.
Apex es un lenguaje orientado a objetos que se ejecuta en los servidores de la Plataforma, con acceso directo al modelo de datos de la Org y a su motor de consultas.
Saber el nombre correcto acorta cualquier requerimiento, porque evita describir con un párrafo algo que tiene una palabra.
| Nombre | Qué nombra |
|---|---|
| Trigger | El código que se ejecuta al crear, editar o borrar un registro |
| Clase | La unidad donde vive la lógica y desde donde se reutiliza |
| Proceso por lotes | La forma de recorrer volúmenes grandes en tandas sucesivas |
| Proceso asíncrono | El trabajo que se encola y corre sin hacer esperar al usuario |
| Proceso programado | El que se ejecuta en un horario definido |
| Callout | La llamada del ERP a un servicio externo |
| Servicio expuesto | El punto por el que otro sistema le habla al ERP |
| Prueba automática | El código que verifica que lo anterior sigue funcionando |
Definir el momento es la mitad del requerimiento, porque cambia por completo la solución técnica.
| Momento | Qué lo dispara | Ejemplo típico |
|---|---|---|
| Al guardar | Un trigger sobre el objeto | Recalcular un total cuando cambia una línea |
| Por horario | Un proceso programado | Revisar vencimientos todas las noches |
| A pedido | Un botón o una acción en pantalla | Generar un documento cuando alguien lo solicita |
| Por volumen | Un proceso por lotes | Actualizar precios sobre miles de productos |
| Desde afuera | Un servicio expuesto | Recibir un pedido de una tienda en línea |
La Plataforma impone límites de consumo por transacción, y esa restricción es la que sostiene el rendimiento de todas las Orgs que conviven en la misma infraestructura.
La consecuencia práctica es que todo lo masivo se resuelve por lotes. Un requerimiento que empieza por "que recorra todos los registros y actualice" se implementa como un proceso por lotes, y conviene escribirlo así desde el principio.
El segundo punto es el orden. Cuando sobre un mismo objeto conviven una regla de validación, una automatización configurada y un trigger, el orden en que se ejecutan importa, y ahí es donde aparecen los efectos que nadie esperaba. Un requerimiento que declara qué gana cuando dos reglas se cruzan ahorra semanas de ida y vuelta.
Y el tercero es qué se hace cuando algo falla. Un proceso que habla con un sistema externo tiene que saber qué hacer si el otro lado no responde, y esa decisión es de negocio antes que técnica.
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