AgriNet · APIs e integraciones
Un sistema que promete integrarse se mide contando sus rutas. Aquí están contadas, con la hora del servidor y con sus huecos.
Esta página no argumenta que el sistema se integra. Publica el inventario de sus rutas tal como está en la base del motor que lo generó, con la hora de corte del propio servidor, y dice cuáles de los campos de ese inventario están vacíos. Después vienen los estándares del sector, las integraciones con lo que ya tiene y los eventos que el sistema avisa hacia afuera.
Por dónde empezar
Un registro de salida, dos obligaciones cubiertas
El mejor argumento de integración de este sistema no es una lista de conectores. Es una coincidencia que casi nadie explota: el complemento fiscal mexicano de traslado y el evento crítico de envío de la norma estadounidense piden los mismos campos —origen, operador, placas, fecha de envío y kilos enviados.
El sistema los captura una vez, en la salida del centro de distribución, y con ese único registro emite el complemento fiscal mexicano y el dato clave estadounidense. No es un ahorro de teclas: es que los dos documentos dicen lo mismo, porque salieron del mismo registro. Cuando se capturan por separado, tarde o temprano no coinciden, y ese día alguien tiene que explicar por qué.
Ese es el criterio con el que está construida toda esta página: una integración sirve cuando elimina una captura, no cuando agrega una pantalla. Y el criterio de la mitad técnica es el hermano de ese: una ruta cuenta cuando está en el inventario con su contrato, no cuando alguien la menciona.
El mismo dato, capturado una vez, cumpliendo dos regímenes. Eso es integración; lo demás es exportar un archivo.
Cada fila de las tablas que siguen se puede leer con la misma pregunta: ¿qué captura elimina, y dónde está registrada?
Lo que la base dice
986 endpoints en 962 rutas, contados en la base del motor
El motor con el que está construido AgriNet guarda, para cada sistema que genera, la tabla de sus endpoints. Para el proyecto de AgriNet esa tabla tiene 986 filas y 962 rutas distintas. La diferencia son 23 rutas que aparecen en más de una fila, porque la misma ruta sirve a más de una operación de negocio con un nombre distinto: el mismo camino de consulta que alimenta un reporte alimenta también un tablero. Se dice la diferencia en lugar de publicar sólo el número mayor.
Ese contraste es el dato que importa de un inventario de API, porque es el que se puede falsear más fácil. Un catálogo con mil filas y trescientas rutas distintas es un catálogo inflado. Aquí las dos cifras están a veinticuatro filas una de otra, y la consulta que lo comprueba es una línea.
La distribución por método es la de un sistema que opera, no la de un catálogo de lectura: más de la mitad de las rutas escriben o disparan una acción. Eso es coherente con lo que hace el sistema —aprobar una evaluación de proveedor, cambiar el estatus de un simulacro de retiro, publicar una ficha técnica— y es lo contrario de un inventario de consultas para pintar tableros.
Método HTTP · cuántas rutas · qué hace cada grupo en la operación
| Método | Rutas | Qué hace ese grupo en la operación agroexportadora |
|---|---|---|
| POST | 547 | Creación y acción: alta de requisición y de orden de compra, solicitud y aprobación de evaluación de proveedor, cambio de estatus de un simulacro de retiro, publicación de ficha técnica, adjuntar evidencia, firmar resolución, notificar, escalar una alerta de nivel operativo a gerencia y de gerencia a dirección. |
| GET | 351 | Consulta: bandejas por rol, expediente de trazabilidad del lote, ficha técnica por cliente, polígono de parcela, catálogos, tableros con sus filtros y el detalle de cada indicador, y la bitácora de auditoría de las interacciones. |
| PUT | 86 | Actualización: datos de una evaluación en curso, configuración de una alerta, datos operativos de una etapa de cultivo, estado de una unidad logística. |
| DELETE | 2 | Baja: dos rutas de retiro, y sólo dos. Un sistema de trazabilidad borra poco por diseño: lo que sustituye a un borrado es un cambio de estado con su motivo y su hora, y eso vive en las matrices de estado, no aquí. |
| Sin método resuelto | 0 | Ninguna fila queda sin método HTTP. En otro de los sistemas de la casa esa cifra no es cero, y allí se publica como hueco; aquí el hueco no existe y también se dice. |
| Total | 986 | 962 rutas distintas, 23 de ellas en más de una fila. |
Transcrito de la base del motor de la casa, consultado el 27 de septiembre de 2026 entre las 14:25 y las 14:30 h, hora del propio servidor, en modo de solo lectura. La hora es parte del dato: un conteo sin hora de corte no es reproducible.
Las 88 familias de ruta bajo /api/ y la ausencia total de rutas fuera de ese prefijo son dos datos del mismo tipo: dicen que el inventario sigue una convención, no una costumbre. Las familias con más peso son el tablero (80 rutas), el lote trazable (70), las órdenes de compra (50), la remisión (47) y el capital humano (46).
Con este inventario, la pregunta de una integración deja de ser «¿se puede?» y pasa a ser «¿qué ruta y qué campos?». Es una conversación distinta, y mucho más corta.
El contrato de la ruta
Qué trae cada ruta, campo por campo
Una ruta sin contrato es una promesa. El contrato de una ruta son seis cosas: qué versión es, qué se le manda, qué devuelve, con qué código responde cuando sale bien, con qué códigos responde cuando sale mal y si exige autorización. La tabla que sigue cuenta, campo por campo, en cuántas de las 986 filas está poblado cada uno.
La columna de la derecha es la que hace útil esta tabla. No dice «cumple»: dice el número y el valor medido, y cuando el número no llega a 986 lo dice también. Ocurre una vez, y es el esquema de petición.
Campo del contrato · cuántas rutas lo traen · valor medido en la base
| Campo | Rutas que lo traen | Valor medido |
|---|---|---|
| Ruta | 986 de 986 | Todas empiezan por /api/. Ninguna ruta del inventario queda fuera de ese prefijo. |
| Método HTTP | 986 de 986 | POST, GET, PUT y DELETE. Ninguna fila sin método resuelto. |
| Versión de la API | 986 de 986 | Todas declaran v1. Un solo valor en las 986 filas. |
| Esquema de la petición | 974 de 986 | Doce rutas no traen esquema de petición. Son rutas de consulta sin parámetros propios, del tipo «refrescar el tablero», donde no hay nada que mandar. No se rellena la cifra a 986: se publican las doce. |
| Esquema de la respuesta | 986 de 986 | Descripción estructurada de lo que la ruta devuelve, con los campos nombrados: por ejemplo el reporte de trazabilidad regulatoria con su folio, su código de lote, su polígono de parcela, su balance de masa y su memoria cronométrica. |
| Códigos de éxito | 986 de 986 | 200 en todas. |
| Códigos de error | 986 de 986 | 400, 401, 403, 404, 500, la misma lista en todas: petición mal formada, sin autenticar, sin permiso, no encontrado y fallo de servidor. |
| Exige autorización | 986 de 986 | Ninguna ruta del sistema es anónima. Es la única afirmación de seguridad que el inventario sostiene con dato, y por eso es la única que se hace. |
| Nombre de negocio | 986 de 986 | Cada ruta tiene un nombre en el idioma de la operación —«Aprobar o Rechazar Evaluación de Proveedor»—, no sólo un verbo y un camino. |
| Descripción en texto | 986 de 986 | Campo de descripción poblado en las 986. |
| Código de la operación | 986 de 986 | Del tipo API-FUN-ABA-007: familia funcional y número. Es lo que permite citar una ruta en un acta sin transcribir su camino. |
| Estado de la API | 986 de 986, con un solo valor: borrador | El catálogo del motor tiene cuatro estados —borrador, activa, deprecada y retirada— y las 986 filas están en el primero. Ninguna está marcada como activa. Es el estado real del inventario y se publica así, porque es exactamente lo que un área de sistemas necesita saber antes de construir contra él. |
Transcrito de la base del motor de la casa, consultado el 27 de septiembre de 2026 entre las 14:25 y las 14:30 h, hora del propio servidor, en modo de solo lectura. La hora es parte del dato: un conteo sin hora de corte no es reproducible.
Que las 986 estén en borrador no se esconde: se pone en la misma tabla que la cifra que favorece, porque si no, la que favorece no significa nada.
Los huecos
Qué se decide con su equipo de sistemas antes de conectar
Esta es la sección que decide si una página de integraciones vale algo. Medir sólo lo que está lleno es hacer publicidad. Lo que sigue son los campos de la misma tabla que están en cero, y están en cero en las 986 filas sin excepción.
Conviene leer la tercera columna con cuidado, porque no todos los huecos significan lo mismo. Hay campos nulos, que son trabajo pendiente; hay campos poblados con el valor cero, que son una decisión declarada; y hay un caso —el esquema de autenticación— que es un hueco del inventario del motor y aparece igual en los otros sistemas de la casa.
Campo vacío · en cuántas rutas · qué significa el hueco
| Campo vacío | Rutas | Qué significa, y qué falta |
|---|---|---|
| Esquema de autenticación concreto | 0 de 986 poblado | Las 986 exigen autorización, pero ninguna declara con qué mecanismo. El catálogo del motor modela nueve esquemas con su norma de referencia —autenticación básica, llave de aplicación, token al portador, token web en JSON, dos flujos de autorización delegada, doble TLS y aserción de identidad—, pero el campo que elige uno está vacío en las 986. Lo publicable es que la obligación está declarada y el mecanismo no. |
| Alcance de autorización | 0 de 986 | No hay alcances por ruta capturados. El permiso vive en el modelo de roles del sistema —18 roles, con su matriz de acceso por pantalla—, no en el inventario de rutas. |
| Acuerdo de tiempo de respuesta | 0 de 986 | Ninguna ruta trae un tiempo máximo comprometido. Y aquí hay un contraste que conviene decir: entre las pruebas generadas hay 454 de tiempo de respuesta de API. Se prueba el tiempo de respuesta sin que el inventario declare cuál es el comprometido. Publicar un tiempo de respuesta con este campo vacío sería inventarlo. |
| Límite de llamadas por minuto | 0 de 986 | No hay control de caudal declarado por ruta. Es lo primero que hay que definir antes de abrir el sistema a un tercero, y es configuración, no arquitectura. |
| Segundos de caché | 0 en las 986 | El campo está poblado, con el valor cero: ninguna respuesta se declara cacheable. Es un dato, no un hueco, y conviene no confundirlos. |
| Paginación | 0 en las 986 | El campo está poblado con cero en todas, incluidas las 351 de consulta: ninguna ruta se declara paginada en el inventario. La plataforma sí tiene lectura paginada del lado del servidor, con índice de fila inicial, máximo de filas, condición y orden; lo que falta es que el inventario de este sistema lo declare ruta por ruta. Son dos afirmaciones de sujeto distinto y no se mezclan. |
| Etiqueta de agrupación | 0 de 986 | El campo de etiqueta está nulo en todas: las 88 familias de esta página se agruparon por prefijo de ruta, no por etiqueta declarada, y se dice. |
| Entidad y tabla física asociadas | 0 de 986 | El vínculo entre la ruta y la entidad del diccionario de datos no está capturado en esta tabla, aunque las 181 entidades y sus 181 tablas físicas sí están. Se puede reconstruir por el nombre de la ruta, pero reconstruir no es medir. |
| Identificador de operación | 0 de 986 | El campo que usaría un generador de cliente para nombrar el método está nulo en todas. Afecta a la comodidad de quien consuma la API, no a su funcionamiento. |
| Tipo de API | 0 de 986 | El clasificador está nulo en todas. Por la forma de sus rutas y de sus métodos son REST; el campo que lo declararía está vacío, y se dice así en lugar de afirmarlo desde la forma. |
| Pasos de proceso con endpoint de reversión | 0 | Aquí hay un cero que no se entiende sin su cadena. Los endpoints de reversión —la ruta que deshace un paso— no cuelgan del inventario de rutas, sino de la tabla de pasos de proceso. Esa tabla está en cero para este proyecto, así que el cero de reversiones es una consecuencia, no un hallazgo. En otro de los sistemas de la casa esa tabla tiene 17 pasos y 11 reversiones, de modo que la capacidad existe y a este proyecto no se le pobló. Publicar «cero reversiones» sin decir de qué depende sería exacto y engañoso a la vez. |
| Contrato de API publicado y políticas de gobierno | 0 y 0 | Ni contrato publicado ni políticas de gobierno de API registradas para este proyecto. Esas tablas existen en el motor y tienen filas, pero pertenecen a otro proyecto, ajeno a los sistemas de la casa: no se atribuyen aquí. |
| Integraciones externas registradas | 0 | El registro de integraciones del motor está vacío para este proyecto. Las integraciones que la página describe más abajo salen del brochure comercial y así están atribuidas, no del inventario del motor. Son dos fuentes distintas y no comparten frase. |
Transcrito de la base del motor de la casa, consultado el 27 de septiembre de 2026 entre las 14:25 y las 14:30 h, hora del propio servidor, en modo de solo lectura. La hora es parte del dato: un conteo sin hora de corte no es reproducible.
Que el esquema de autenticación esté vacío en las 986 filas no es un descuido de esta página: es el estado de la base. En el sistema de logística de la casa el mismo campo aparece vacío en sus mil seiscientas diez rutas, y en el hospitalario, en sus doscientas noventa y cinco. Es un hueco del inventario del motor, igual en todos, y se dice igual en todos.
Los cuatro huecos que importan para abrir este sistema a un tercero son el mecanismo de autenticación, el control de caudal, la paginación declarada y el paso de las 986 rutas de borrador a activas. Los cuatro son trabajo acotado y ninguno es una decisión de arquitectura: se configuran. Lo que no se puede es publicarlos como si ya estuvieran.
Una página de integraciones que enseña sus trece campos vacíos vale más que una que enseña trece logotipos, porque la primera se puede verificar en media hora.
La convención
Las quince operaciones canónicas, y por qué no se multiplican
Hay un argumento que se oye mucho y casi nunca se sostiene: «de las N entidades de su modelo, el generador produce el ciclo completo de altas, bajas y cambios». En este motor ese argumento está verificable, porque la plantilla no hay que inferirla del código: está registrada en la base, en un catálogo de convenciones con quince operaciones, cada una con su plantilla de ruta y su plantilla de procedimiento almacenado.
Las quince son: actualizar, actualizar en bloque, aprobar, buscar, calcular, cancelar, consultar, crear, crear en bloque, eliminar, exportar, importar, listar, notificar y rechazar. Su plantilla de ruta es del tipo /api/{entidad}, /api/{entidad}/{id} o /api/{entidad}/{id}/aprobar, y su plantilla de procedimiento, del tipo usp{Entidad}_Aprobar. Las rutas reales de este proyecto coinciden con esa plantilla, incluido el nombre del procedimiento: se puede comprobar fila por fila.
Y aquí viene la parte que hace honesta a la sección. La proporción no se deduce: se mide. Este sistema tiene 181 entidades. Si se multiplicara por quince, saldrían dos mil setecientas quince rutas, y no es lo que hay. Lo medido son 986 rutas en el inventario, es decir 5.4 por entidad, y 1,224 acciones de pantalla con endpoint, es decir 6.8 por entidad. No todas las operaciones aplican a todas las entidades: un catálogo de acciones de reproceso no se aprueba ni se cancela.
La plantilla está en la base y se cumple. La proporción se mide. Las dos frases son verdad y la segunda es la que impide inflar la primera.
La aritmética, medida y no estimada
| Magnitud | Valor medido | De dónde sale |
|---|---|---|
| Entidades del modelo | 181 | Diccionario de datos del proyecto, las 181 con nombre físico |
| Tablas físicas con su DDL | 181 | Diseño de base de datos del proyecto |
| Campos físicos con tipo de dato de SQL | 1,635 | Campos del diseño de base de datos, con tipo lógico, tipo físico, tamaño y tabla relacionada |
| Operaciones canónicas de la plantilla | 15 | Catálogo de convenciones de endpoint del motor, con plantilla de ruta y de procedimiento |
| Rutas por entidad, medidas | 5.4 | 986 rutas del inventario entre 181 entidades. No 15: la multiplicación daría 2,715 y sería falsa. |
| Acciones de pantalla con endpoint por entidad, medidas | 6.8 | 1,224 acciones con endpoint entre 181 entidades |
Transcrito de la base del motor de la casa, consultado el 27 de septiembre de 2026 entre las 14:25 y las 14:30 h, hora del propio servidor, en modo de solo lectura. La hora es parte del dato: un conteo sin hora de corte no es reproducible.
Pida la proporción medida, no la plantilla multiplicada. Quien le dé la segunda no ha contado.
Más allá de la tabla de rutas
Las otras cuatro capas, y las tareas que corren sin pantalla
El inventario de rutas es la capa visible, pero no es la única. El motor guarda cuatro más para este proyecto, y una de ellas —la de acciones de pantalla— trae algo que el inventario principal no tiene: el procedimiento almacenado real que está detrás de cada ruta.
Esa es la diferencia entre una ruta declarada y una ruta con capa de datos debajo. De las 1,224 acciones de pantalla con endpoint, 1,025 traen el nombre del procedimiento almacenado que ejecutan, y las 1,224 traen el contrato de entrada tipado: nombre del parámetro, de dónde viene —camino, cuerpo o consulta—, tipo de dato, si es obligatorio y con qué campo físico empata.
Y aquí hay trabajo que no tiene pantalla porque no lo hace nadie: el muestreo programado, el aviso de caducidad, el escalamiento de una alerta que nadie atendió, el recálculo del costo cuando llega una factura de flete. Eso son las 159 tareas de servidor registradas para este proyecto, y las 159 traen su endpoint de ejecución, su clase y su método. Con nombres que no son genéricos: calcular el tiempo de respuesta del simulacro de retiro, asignar ubicación por rotación de caducidad, compilar los parámetros de una ficha técnica, escalar una alerta a dirección general por vencimiento del plazo gerencial.
- Muestreo de agua programado: el punto y la frecuencia salen de la evaluación sistémica, no de la memoria de alguien.
- Aviso de caducidad de certificados, análisis y evaluaciones, con la anticipación configurada.
- Escalamiento de alerta por vencimiento de plazo, en dos niveles: de lo operativo a la gerencia y de la gerencia a la dirección, cada nivel con su tarea propia registrada.
- Recálculo del costo real por kilo cuando entra un costo nuevo, incluido el flete del viaje.
- Inventario cíclico: la ubicación a contar hoy, asignada sin que nadie arme la lista.
- Publicación de eventos hacia el sistema del comprador, en el estándar del sector, con la periodicidad pactada.
Capa · qué guarda · cuántas filas en este proyecto
| Capa | Qué guarda cada fila | Filas medidas |
|---|---|---|
| Acción de pantalla con endpoint | Método, ruta, contrato de entrada tipado ligado al campo físico, procedimiento almacenado de respaldo y si exige autorización | 1,224 · 1,224 con contrato de entrada · 1,025 con procedimiento almacenado · 1,224 con autorización · GET 495, POST 460, PUT 266, DELETE 3 |
| Enlace pantalla ↔ ruta | Qué pantalla consume qué ruta, con su orden de ejecución | 1,093 |
| Tarea de servidor | Endpoint de ejecución, clase y método que la atiende, disparador (mensaje externo o evento) y número de reintentos | 159 · las 159 con endpoint, clase y método |
| Consulta que alimenta una alerta | La consulta de solo lectura que calcula el indicador, su ventana, su severidad y su programación | 206 definiciones de alerta |
| Paso de proceso con endpoint y reversión | El endpoint de cada paso y el endpoint que lo deshace | 0 · no poblado para este proyecto; el cero de reversiones cuelga de aquí |
| Contrato de entrada tipado de la respuesta | El contrato de salida, campo por campo | 0 de 1,224 · sólo el de entrada está tipado; la respuesta se describe en texto estructurado, no en contrato |
Transcrito de la base del motor de la casa, consultado el 27 de septiembre de 2026 entre las 14:25 y las 14:30 h, hora del propio servidor, en modo de solo lectura. La hora es parte del dato: un conteo sin hora de corte no es reproducible.
Una advertencia sobre las tareas de servidor, porque su tabla tiene cincuenta y cuatro columnas previstas para programación horaria, zona de tiempo, ventana de ejecución, tiempo máximo, reintento con espera creciente, cola de descartados, idempotencia, tiempo de respuesta comprometido y rol que vigila. En este proyecto esas columnas están declaradas pero vacías. Lo publicable es la estructura y el conteo, no un valor de tiempo de respuesta.
Una tarea programada es la única forma de que algo se haga el día que nadie se acuerda de hacerlo. Y 1,025 procedimientos almacenados son la única forma de saber que detrás de la ruta hay una tabla.
El hallazgo, con su cero
8,474 pruebas automatizadas generadas, y ninguna ejecutada todavía
Este es el dato que no estaba identificado, y se mide para este proyecto, no para el conjunto. La base del motor tiene ciento cincuenta y cuatro mil setecientos veintiséis casos de prueba en total, repartidos entre muchos proyectos; los de AgriNet son 8,474. La cifra global no es de este sistema y no se le atribuye: la de este sistema es la que se publica.
Los 8,474 salen de 112 especificaciones, una por pantalla, agrupadas en 1,749 suites con 50,993 pasos. Las 8,474 están marcadas como generadas automáticamente, las 8,474 traen su código de prueba de navegador y las 8,474 traen sus pasos escritos. Se generaron entre las 14:12:25 y las 15:11:57 del 24 de septiembre de 2026: una hora.
Y ahora el cero, que es la mitad del dato. Ninguna de las 8,474 se ha ejecutado. Las 8,474 están en estado pendiente, ninguna tiene fecha de última ejecución, la bitácora de corridas está vacía para este proyecto y la tabla de resultados también. La cadena explica por qué: una prueba de navegador necesita una dirección de aplicación desplegada contra la que correr, y lo que está generado es la especificación, no la corrida. Publicar «ocho mil cuatrocientas setenta y cuatro pruebas» sin este párrafo sería exacto y engañoso.
Familia de prueba · cuántas · qué comprueba en este sistema
| Familia | Pruebas | Qué comprueba |
|---|---|---|
| Validación de campo | 3,166 | Longitud (1,329), obligatoriedad (617), tipo numérico (557), rango (368), comparación entre campos (120), fecha (55), condicional (39) y formato (11). Es la comprobación de que el formulario no acepta lo que la regla de negocio prohíbe. |
| Caso de uso | 1,863 | El recorrido completo de un caso de uso del sistema, de principio a fin, sobre la pantalla que lo sostiene. |
| Diseño y presentación | 826 | Visibilidad, tipografía, espaciado, respuesta a distinto tamaño de pantalla, iconografía, color, alineación y estado vacío. |
| Experiencia de uso y accesibilidad | 797 | Retroalimentación al usuario, etiquetas, mensajes de error, botones, campos obligatorios y —lo que importa para una auditoría de accesibilidad— 112 pruebas de accesibilidad y 112 de navegación por teclado. |
| Control de acceso por rol | 687 | Que cada uno de los roles vea lo que le toca y no vea lo demás. Son las mismas 687 pruebas que llevan rol requerido declarado: la cifra cuadra por dos caminos. |
| Tiempo de respuesta de la API | 454 | El tiempo de respuesta de las rutas. Y aquí el contraste con la sección de huecos: se prueba el tiempo de respuesta, y el inventario de rutas no declara cuál es el comprometido. |
| Flujo y filtrado | 351 | El paso de una pantalla a la siguiente y el comportamiento de los filtros. |
| Tipo de pantalla | 254 | Que una bandeja se comporte como bandeja, un asistente como asistente y una ficha como ficha. |
| Proceso de negocio | 76 | El proceso completo atravesando varias pantallas. |
| Total | 8,474 | En 112 especificaciones, 1,749 suites y 50,993 pasos. |
Transcrito de la base del motor de la casa, consultado el 27 de septiembre de 2026 entre las 14:25 y las 14:30 h, hora del propio servidor, en modo de solo lectura. La hora es parte del dato: un conteo sin hora de corte no es reproducible.
Dos ceros más, con su cadena, porque publicarlos sin ella induciría a error. Cero planes de prueba y cero requisitos de prueba por funcionalidad: las 8,474 pruebas no cuelgan de un plan ni de la funcionalidad, cuelgan de la especificación de la pantalla. Y cero criterios de aceptación y cero referencias a norma en la columna que los guardaría: el criterio de aceptación vive dentro del código de la prueba y de sus pasos, no en ese campo. Son huecos del inventario, no pruebas sin criterio.
El proyecto declara además tres tipos de prueba obligatorios con su herramienta: funcional en modalidad mixta, de rendimiento automatizada y de seguridad automatizada, las tres con el mismo umbral —aprobar el cien por ciento de los casos críticos—. Los criterios de entrada y de salida de esos tres tipos están vacíos, y también se dice.
Un sistema con ocho mil cuatrocientas setenta y cuatro pruebas escritas y ninguna corrida es un sistema con la mitad del trabajo hecho. Decir cuál mitad es lo que distingue una página de un folleto.
Los estándares
Los estándares del sector que el sistema soporta
Los estándares de esta tabla no salen de la base del motor: salen del brochure comercial de AgriNet y de los organismos que los publican, y así están atribuidos. Es una fuente distinta de la de las secciones anteriores y no se mezcla con ella.
No son formatos propios: son los estándares con los que su comprador, su transportista y su certificador ya trabajan. Hablarlos es lo que hace que no tenga que convencer a nadie de adoptar nada.
Estándar · qué resuelve · dónde se usa en la operación
| Estándar | Qué resuelve | Dónde se usa | Organismo |
|---|---|---|---|
| EPCIS 2.0, con interfaz REST y JSON-LD | El lenguaje común de los eventos de la cadena: qué pasó, cuándo, dónde y por qué, en un formato que otro sistema entiende sin traducción | La publicación de los eventos críticos hacia el sistema del comprador o de un tercero | GS1 |
| GS1 Digital Link | Que un código en la caja resuelva a una dirección web con la información del lote | La etiqueta que el cliente final o el inspector pueden leer con un teléfono | GS1 |
| EDI 856 · aviso de embarque | Avisar al cliente qué viene, en qué tarimas y con qué lotes, antes de que llegue la unidad | La comunicación con supermercados y retail que trabajan con intercambio electrónico de datos | GS1 · ANSI X12 |
| GS1-128 y DataMatrix | La simbología con la que el código se imprime y se lee sin teclear | La etiqueta de tarima y la de caja, leídas en empaque, en centro de distribución y en andén | GS1 |
| Identificador de producto, de localización y código seriado de contenedor de embarque | Las tres llaves: qué producto, en qué lugar, en qué tarima concreta | El catálogo de producto, las ubicaciones y cada tarima armada | GS1 |
| Código de lote de trazabilidad: identificador de producto más número de lote | La llave del lote con la que se rastrea hacia arriba y hacia abajo | El evento de empaque inicial, y desde ahí todos los siguientes | GS1 · exigido por la norma estadounidense |
| CFDI con complemento Carta Porte 3.1 | Amparar el traslado terrestre, férreo, aéreo, marítimo y fluvial, con origen, puntos intermedios, destino, medio de transporte e intervinientes | La salida del centro de distribución, en las dos modalidades: comprobante de ingreso del transportista y de traslado con valor cero | SAT · obligatorio desde el 17 de julio de 2024 |
Estándares técnicos de trazabilidad: brochure comercial de AgriNet, sección 04. Carta Porte 3.1: SAT, obligatoria desde el 17 de julio de 2024, sin convivencia con la versión 3.0. Código de lote de trazabilidad: FDA, 21 CFR Part 1 Subpart S. Ninguna fila de esta tabla sale del inventario del motor: el registro de integraciones de ese inventario está en cero para este proyecto, y se dice en la sección de huecos.
Hablar el estándar del comprador es la diferencia entre entregar un archivo y entregar un dato que su sistema ya sabe leer.
Las integraciones
Las integraciones con lo que ya tiene
Estas nueve integraciones están declaradas en el brochure comercial de AgriNet, y eso es lo que son: declaraciones del brochure. El registro de integraciones de la base del motor está en cero para este proyecto, como dice la tabla de huecos, de modo que cada fila lleva su sujeto: el brochure lo declara, el inventario del motor no lo registra todavía.
Ninguna de ellas le pide cambiar el sistema que ya usa. El criterio, otra vez: cada una tiene que eliminar una captura o una llamada telefónica.
Y una aclaración de método, porque importa: aquí no se nombra ninguna marca ajena. Se dice «un sistema de planificación de recursos empresariales genérico» porque lo que se afirma es el modelo de conexión, no la calidad de un producto de otro.
Integración · qué entra · qué sale · qué captura elimina
| Integración | Qué entra al sistema | Qué sale del sistema | Qué captura elimina |
|---|---|---|---|
| Sistema de planificación de recursos y contabilidad | Catálogo de productos y clientes, órdenes de compra y de venta, tipo de cambio | Póliza de costo del lote, comprobante fiscal de traslado, costo de flete por viaje con transportista, monto y placas ligados a la orden de compra | La captura doble del costo y del comprobante |
| Portal del proveedor | Certificados, análisis, fichas y documentos que el proveedor carga y que el sistema valida antes de aceptar | El estado de su expediente y lo que le falta, visible para él | El correo de ida y vuelta pidiendo documentos |
| Portal del cliente | Órdenes, citas solicitadas y confirmaciones | Expediente del lote, trazabilidad por evento, aviso de embarque y estado del embarque | La llamada del cliente preguntando dónde viene su producto |
| Posición y telemetría de unidades | Posición, velocidad, geocerca, sensor de puerta, sello electrónico y telemetría de la unidad | Hora estimada de llegada, riesgo de perder la cita y escalamiento por desvío, parada no autorizada o apertura de puerta fuera de ruta | La llamada al operador para saber dónde va |
| Sensores de campo | Humedad de suelo a varias profundidades, conductividad eléctrica, estación agroclimática, caudalímetros, presión de riego y trampas con conteo automático | Régimen de riego, presión de plaga y bitácora del lote-hectárea | La lectura manual anotada en libreta |
| Sensores de agua | Turbidez, cloro residual, pH y potencial de oxidación-reducción en línea, con punto de muestreo programado | El muestreo de laboratorio disparado y la evidencia de la evaluación sistémica | El recorrido de toma de lecturas |
| Sensores de poscosecha y cámara | Temperatura y humedad por cámara, registradores de pulpa, control de atmósfera, consumo energético y apertura de andén | Excursión de cadena de frío por tramo, con minutos fuera de rango | La descarga manual del registrador al final del viaje |
| Transporte y cadena de frío en ruta | Registrador de temperatura de contenedor, geocerca, sensor de puerta y sello electrónico | Cadena de frío registrada por tramo y evidencia de entrega con firma y fotografía | La hoja de ruta en papel |
| Drones | Mapeo multiespectral, conteo de plantas y fallas de emergencia, firma espectral de plaga, inspección de terrenos adyacentes y delimitación de polígono | Mapa de vigor por lote-hectárea, ajuste de proyección de cosecha, orden de aplicación dirigida, evidencia fotográfica fechada y georreferenciada, y coordenadas de polígono | El recorrido a pie para levantar evidencia de colindancia |
Integraciones declaradas en el brochure comercial de AgriNet: sección 01 (sistema de planificación y contabilidad como dolor a resolver), 08 (torre de control, costeo de flete, control de robo), 09 (drones, sensores por ámbito, portal del proveedor y portal del cliente). Evidencia fotográfica de terrenos adyacentes: FDA, 21 CFR Part 112. Coordenadas de polígono: geolocalización exigida en el mercado europeo. El registro de integraciones de la base del motor está en cero para este proyecto: estas nueve son del brochure.
Nueve integraciones y nueve capturas que dejan de existir. Esa es la única aritmética que justifica una integración.
Webhooks y eventos
Los eventos: qué avisa el sistema hacia afuera y cuándo
Una integración que hay que consultar no es una integración: es una tarea. Lo que cambia la operación es lo contrario —que el sistema avise sin que nadie pregunte—, y para eso hay tres caminos, los tres verificables en el código de la plataforma.
El primero es el canal de eventos en tiempo real: el orquestador de la plataforma expone un concentrador de eventos, que es por donde una pantalla abierta se entera de algo sin recargar. El segundo son las notificaciones a dispositivo, con su registro del aparato y su disparo del aviso. El tercero es el aviso entre servicios: al terminar la generación, el motor llama al servicio de documentación con el identificador del proyecto y de la tarea, sin esperar respuesta.
Y en la dirección contraria, el sistema recibe avisos de terceros: hay endpoints de recepción de eventos externos, incluido uno genérico, más consulta de estado y comprobación de vida. En el inventario de este proyecto hay además una acción de pantalla cuyo código es literalmente la recepción de un aviso externo, con su ruta y su método: el mecanismo no es teórico.
Evento del sector · cuándo se dispara · a quién avisa · por dónde
| Evento | Cuándo se dispara | A quién avisa | Canal |
|---|---|---|---|
| Aviso de embarque | Al cerrar la carga y salir del centro de distribución | Su cliente: supermercado o retail | Intercambio electrónico de datos, aviso de embarque EDI 856 |
| Comprobante de traslado emitido | En la misma salida del centro de distribución, con el registro único del evento de envío | La autoridad fiscal mexicana y el transportista | Comprobante fiscal digital con complemento Carta Porte 3.1 |
| Expediente del lote listo | Al completarse los siete eventos críticos con sus datos clave, o al atenderse una solicitud | El solicitante: autoridad, comprador u organismo certificador | Enlace de lectura para un tercero sin cuenta, o publicación de eventos en el estándar del sector |
| Excursión de cadena de frío prevista | Cuando la tendencia de temperatura va a salirse del rango, antes de que se salga | Jefe de centro de distribución y responsable de la unidad | Canal en tiempo real y notificación a dispositivo |
| Lectura de agua fuera de criterio | Cuando la lectura en línea cruza el criterio configurado | Responsable de inocuidad, y el laboratorio con el muestreo disparado | Canal en tiempo real y notificación a dispositivo |
| Desvío, parada no autorizada o apertura de puerta fuera de ruta | En el momento del evento de geocerca o de sensor de puerta | El responsable al que escala | Notificación a dispositivo |
| Certificado, análisis o evaluación por caducar | Con la anticipación configurada antes de la fecha de caducidad | Responsable de inocuidad y dirección | Notificación a dispositivo y aviso en la bandeja del rol |
| Embarque que no saldría hoy | Al detectarse expediente documental incompleto o incoherente con cita en las próximas 24 horas | Coordinación de exportación y dirección de operaciones | Canal en tiempo real y aviso en la bandeja del rol |
| Cita en riesgo de perderse | Cuando la hora estimada de llegada sale de la ventana de andén asignada | Coordinación de transporte y el cliente, por su portal | Canal en tiempo real y portal del cliente |
| Documento del proveedor cargado o rechazado | Al validarse la carga en el portal del proveedor | El proveedor y el responsable de inocuidad | Portal del proveedor y aviso en la bandeja del rol |
| Cambio al sistema aprobado y ejecutado | Al aprobarse y ejecutarse una solicitud de cambio | Quien lo pidió y quien lo aprobó | Canal en tiempo real; queda además en la cola y el historial de versiones |
Canales verificados en el código de la plataforma: concentrador de eventos en tiempo real, notificación a dispositivo, recepción de eventos externos y enlace de lectura para terceros. Los eventos del sector y sus destinatarios salen del brochure comercial de AgriNet, secciones 04, 08 y 09. El canal concreto de cada evento se configura: lo que está verificado es que los tres canales existen.
Un sistema que avisa cambia el trabajo de las personas. Uno que hay que consultar sólo cambia dónde está guardado el dato.
La plataforma · verificable
Los endpoints de la plataforma, con método y ruta
Cambio de sujeto, y conviene decirlo antes de la primera fila: lo que sigue no es del proyecto de AgriNet, es de la plataforma con la que está construido. Los 986 endpoints de las secciones anteriores son del sistema; estos son del motor que lo genera y lo opera. No comparten tabla ni frase.
El servicio del portal está construido sobre una interfaz REST con autenticación por token. El ruteo combina atributos explícitos con tres rutas por convención —api/{controlador}/{acción}/{id}, {controlador}/{acción}/{id} y api/{controlador}/{id}— declaradas. Se publica porque un departamento de sistemas pide exactamente esto antes de aprobar nada.
Autenticación y catálogo de entidades
| Método | Ruta | Qué hace |
|---|---|---|
| POST | /oauth/token | Obtener el token de acceso |
| GET | /api/{entidad} y /api/{entidad}/GetAll | Leer una entidad del catálogo o todas |
| GET | /api/{entidad}/ListaSelAll | Leer con paginación, filtro y orden: índice de fila inicial, máximo de filas, condición y orden |
| POST | /api/{entidad} | Crear un registro |
| PUT | /api/{entidad}/{id} | Actualizar un registro |
| DELETE | /api/{entidad}/{id} | Borrar un registro |
| GET / POST | /api/Spartan_File y /api/Spartan_File/Files | Subir y recuperar archivos: es por donde entra el certificado escaneado o la fotografía de campo |
| GET | /api/geocoding y /api/geocoding/reverse | Resolver una dirección a coordenadas y al revés: es lo que ata la dirección del proveedor a su punto en el mapa |
| POST | /api/WebScraper/extract | Extraer datos estructurados de una fuente web |
La plantilla de entidad se verificó en cuatro controladores y tiene 16 acciones por entidad. Conteos en disco: 500 archivos (499 controladores más una clase base), 10 con prefijo de ruta, 14 con al menos una ruta explícita, 66 atributos de ruta y 3,953 atributos de método HTTP: 1,759 GET, 1,042 PUT, 761 DELETE y 391 POST. Todo esto es de la plataforma, no del proyecto de AgriNet.
Definición de reportes y cambios al sistema
| Método | Ruta | Qué hace |
|---|---|---|
| GET | /api/reportedefinicion/bypantalla/{idPantalla} | Traer la definición del reporte de una pantalla |
| POST | /api/reportedefinicion/save y /publish | Guardar y publicar una definición de reporte |
| GET / POST | /api/reportedefinicion/versions/{id} y /restore/{idVersion} | Ver versiones de un reporte y volver a una anterior |
| POST | /api/solicitud_cambio/desde-edicion | Levantar la solicitud de cambio desde la propia edición: es el endpoint que sostiene «los cambios en la sesión» |
| GET | /api/motor/impacto | Calcular qué toca un cambio antes de aprobarlo |
| PUT | /api/motor/aprobar/{id} y /api/motor/rechazar/{id} | Aprobar o rechazar la solicitud, con registro de quién |
| POST | /api/motor/ejecutar/{id} y /api/motor/ejecutar-siguiente/{idProyecto} | Ejecutar el cambio aprobado |
| GET | /api/motor/cola/{idProyecto} y /api/motor/versiones/{idPantalla} | Ver la cola de cambios y el historial de versiones de una pantalla |
| POST | /api/motor/versiones/{idVersion}/marcar-estable | Fijar cuál versión de la pantalla es la estable |
| GET | /api/motor/reporte/{idProyecto}/{tipo} | Sacar el reporte de cambios del proyecto |
| GET / PUT | /api/motor/config-aprobacion/{idProyecto} | Consultar y fijar quién aprueba qué |
El controlador del motor de cambios tiene prefijo api/motor. Verificado el 27 de septiembre de 2026 leyendo atributos en el código.
Documentación técnica del sistema, como servicio
| Método | Ruta | Qué hace |
|---|---|---|
| POST | /api/DocumentacionTecnica/generar | Generar el documento técnico pedido |
| POST | /api/DocumentacionTecnica/generar-por-pantalla | Generar la documentación de una pantalla concreta |
| GET | /api/DocumentacionTecnica/catalogo | Traer el catálogo de documentos generables |
| GET | /api/DocumentacionTecnica/proyecto/{idProyecto}/documentos | Listar los documentos de un sistema |
| GET | /api/DocumentacionTecnica/documento/{id}/versiones | Ver las versiones de un documento |
| POST | /api/DocumentacionTecnica/visor-generar-enlace | Generar un enlace para que un tercero —su auditor, su comprador— lea la documentación sin cuenta |
| GET | /api/DocumentacionTecnica/visor-publico/{token} | Abrir ese enlace, del lado del tercero |
| GET | /api/DocumentacionTecnica/visor-descargar-todos/{idProyecto} | Descargar el conjunto completo |
18 endpoints en un solo controlador: 10 de lectura y 8 de escritura, con prefijo api/DocumentacionTecnica. El catálogo que sirven tiene 211 documentos en 18 secciones. Para este proyecto, el motor tiene 26 documentos aprobados dados de alta.
La especificación pública de la interfaz de la plataforma está escrita a mano y cubre un subconjunto curado: 21 rutas. El propio resumen de cifras del dossier de plataforma cuenta 20 en ese archivo; el conteo de rutas enumeradas es 21, y la diferencia se deja dicha en lugar de elegir la que conviene.
Un endpoint con su archivo y su línea se puede auditar. Un diagrama de arquitectura, no; y para este proyecto, además, el motor tiene cero diagramas de arquitectura dados de alta.
La honestidad que sostiene la página
Qué está medido, qué es estimación y qué está en cero
Esta es la sección que un departamento de sistemas va a leer primero, y por eso está escrita sin adornos. La regla de la columna del medio es de sujeto: cada fila dice si la afirmación es del proyecto, de la plataforma o de la base completa del motor.
Se publica la cifra que no favorece junto con la que favorece. Es la única manera de que la que favorece signifique algo.
Afirmación · estado · por qué
| Afirmación | Estado | Por qué |
|---|---|---|
| 986 endpoints del proyecto, con método, versión, esquemas, códigos HTTP y autorización obligatoria | Medido en la base del motor | Consulta directa sobre el inventario de rutas del proyecto de este sistema en el motor, con corte de servidor del 27 de septiembre de 2026, 14:25 h. La consulta y el corte se publican para que otro los repita. Es del proyecto |
| 8,474 pruebas automatizadas del proyecto, en 112 especificaciones, 1,749 suites y 50,993 pasos | Medido para este proyecto | Se midió el proyecto, no el conjunto. La base completa tiene 154,726 casos y esa cifra no es de este sistema. Es del proyecto |
| Cero pruebas ejecutadas, cero planes de prueba, cero pasos de proceso con reversión, cero integraciones registradas, cero diagramas, cero agentes dados de alta | Cero medido, con su cadena | Cada cero lleva su explicación de qué depende: las pruebas esperan una aplicación desplegada, las reversiones cuelgan de los pasos de proceso, las integraciones del brochure no están en el registro del motor. Es del proyecto |
| Las 986 rutas están en estado de borrador, ninguna activa | Medido | El catálogo tiene cuatro estados y las 986 filas están en el primero. Se publica porque cambia lo que un área de sistemas debe planear. Es del proyecto |
| La plantilla de 15 operaciones canónicas con su ruta y su procedimiento | Medido en el catálogo del motor | Las 15 filas están en la base con su plantilla, y las rutas reales del proyecto coinciden con ellas. Es de la plataforma, y su cumplimiento, del proyecto |
| «181 entidades × 15 operaciones = 2,715 endpoints» | Falso, y por eso no se publica | La proporción real medida es de 5.4 rutas por entidad en el inventario y 6.8 acciones por entidad en la capa de pantalla. La plantilla existe; multiplicar por ella, no |
| 500 archivos de controlador, 3,953 atributos de método HTTP, 66 atributos de ruta, 10 prefijos y 14 controladores con ruta explícita | Verificado en disco | Conteo directo, excluyendo directorios de compilación. Es de la plataforma |
| Los métodos y rutas de las tablas de la plataforma | Verificado leyendo el código | Salen de atributos y firmas, con su cita en el expediente interno. No se llamó ningún endpoint: nada se ejecutó en ejecución. Es de la plataforma |
| «Cerca de 7,800 endpoints de la plataforma» | Estimación, no evidencia | Sale de multiplicar controladores por operaciones de la plantilla. El ruteo por convención hace que muchas acciones no lleven atributo, así que un conteo exacto de la plataforma no es posible sin instrumentación en ejecución. No se publica como dato duro. Ojo con el sujeto: esto es de la plataforma, y no afecta a los 986 del proyecto, que sí están contados |
| «498 endpoints» y «498 controladores» del catálogo interno | Desactualizado | El documento interno es de junio de 2026 y el código creció: hoy son 500 archivos y 14 con ruta explícita. Cuando el documento y el código no coinciden, gana el código |
| La especificación pública de la plataforma está generada automáticamente | No: está escrita a mano | Cubre un subconjunto curado de 21 rutas. La generación en ejecución está declarada activada por la documentación interna, pero no se verificó: no se compiló ni se abrió |
| Los endpoints heredados de acceso directo por cadena de consulta | Marcados para retirarse | La propia documentación de la plataforma los marca como heredados y a deprecar porque no usan el esquema de token. No se ofrecen como vía de integración |
| Contratos OpenAPI 3.1, AsyncAPI 2.6 y políticas de gobierno de API | Existen en el motor, pero no son de este sistema | Las filas de esas tablas pertenecen íntegramente a un proyecto ajeno a los sistemas de la casa. Para el proyecto de este sistema en el motor el conteo es cero, y no se atribuyen |
| Las ocho calificaciones de calidad de producto del proyecto | Las filas existen, la calificación está vacía | Lo publicable es que el motor evalúa ocho atributos de calidad; una nota concreta, no, porque el campo está vacío |
Medición en la base del motor de la casa el 27 de septiembre de 2026, corte de servidor 14:25–14:30 h, en solo lectura. Auditoría de código de SPARTANE del mismo día para las filas de plataforma. Reglas aplicadas: el código en disco gana sobre el documento interno; la estimación no se publica como conteo; y lo del proyecto y lo de la plataforma no comparten frase.
Pida esta misma tabla a cualquier proveedor. La ausencia de la columna del medio es la respuesta.
Para el equipo técnico
Lo que su área de sistemas va a preguntar, y cómo comprobarlo
Cinco preguntas que siempre llegan, con la cita o el conteo puesto. Y al final, el camino para que su equipo repita la medición en lugar de creerla.
La conversación que conviene traer a la sesión no es «¿se integra con lo que tenemos?», que la respuesta siempre es sí. Es esta: ¿qué captura deja de existir el primer día, y contra qué ruta.
- El conteo de rutas por método, la lista de campos poblados y la lista de campos vacíos: una consulta de agregación sobre el inventario del proyecto, con la hora del servidor delante. Es la que produjo las tablas 2, 3 y 4 de esta página.
- El conteo de pruebas por familia y el estado de cada una: otra consulta, sobre la tabla de casos de prueba filtrada por este proyecto. Si sale una cifra distinta de 8,474, es porque el corte es otro, y por eso la hora se publica.
- La plantilla de las quince operaciones canónicas con su ruta y su procedimiento: el catálogo se lee entero en una consulta y tiene quince filas.
- El sistema en vivo, en /sistemas/agrinet/sistema/, sin registro y con los datos de ejemplo marcados en pantalla: entre por el rol que le toque y siga un lote.
- ¿Cómo se autentica? Del proyecto, lo medido es que las 986 rutas exigen autorización y que ninguna declara el mecanismo: ese campo está vacío en las 986. De la plataforma, lo verificado es que hay token de acceso obtenido en un endpoint propio y que el orquestador refresca ese token y blinda la condición de filtro antes de pasarla al servicio. Las dos respuestas son ciertas y tienen sujetos distintos.
- ¿Se puede paginar y filtrar del lado del servidor? De la plataforma, sí: cada entidad expone lectura con índice de fila inicial, máximo de filas, condición y orden, y el orquestador construye esa llamada con la condición blindada. Del inventario de este proyecto, la marca de paginación está en cero en las 986: la capacidad existe y la declaración por ruta falta.
- ¿Hay eventos en tiempo real o sólo consulta? Hay un concentrador de eventos en
/bff/events, además de notificación a dispositivo y recepción de eventos externos. Y del proyecto, 159 tareas de servidor con su endpoint de ejecución, disparadas por mensaje externo o por evento. - ¿Hay pruebas, y puedo verlas? Del proyecto: 8,474 casos con su código de prueba de navegador, en 112 especificaciones. Ninguna ejecutada todavía; las 8,474 están pendientes y no hay bitácora de corridas. Se puede pedir la especificación de una pantalla concreta y leerla antes de decidir nada.
- ¿Qué pasa cuando cambiamos algo del sistema, se rompe la integración? El cambio pasa por cálculo de impacto antes de aprobarse, queda en cola y la pantalla conserva su historial de versiones con una marcada como estable. El detalle está en Los cambios, en la sesión.
Su área de sistemas no necesita confiar en esta página: necesita poder repetir la consulta y abrir el archivo y la línea. Las dos cosas están aquí.
Preguntas frecuentes
¿Cuántos endpoints tiene AgriNet, exactamente?
986, en 962 rutas distintas, medidos en la base del motor el 27 de septiembre de 2026 a las 14:25 h, hora del propio servidor. 547 POST, 351 GET, 86 PUT y 2 DELETE, ninguna fila sin método. Las 986 llevan versión v1, esquema de respuesta, código 200 de éxito y la lista 400, 401, 403, 404 y 500 de error, y las 986 exigen autorización. Doce no traen esquema de petición, y eso también se publica.
¿Con qué mecanismo se autentican esos endpoints?
No lo decimos, porque el inventario no lo dice: el campo que elige el esquema de autenticación está vacío en las 986 filas. Lo que sí está en las 986 es la obligación de autorización, así que ninguna ruta es anónima. El catálogo del motor modela nueve esquemas con su norma de referencia, pero ninguno está elegido para este sistema. El mismo campo aparece vacío en los otros sistemas de la casa: es un hueco del inventario del motor y se dice igual en todos.
¿Cuántos endpoints tiene la plataforma en total?
Ahí sí no se puede decir con exactitud, y conviene no confundir los dos sujetos. Los 986 del sistema están contados en la base. El total de la plataforma no es contable sin instrumentar la aplicación en ejecución: el ruteo por convención hace que muchas acciones no lleven atributo. Lo exacto de la plataforma es 500 archivos de controlador y 3,953 atributos de método HTTP. La cifra de «cerca de 7,800» que circula en la documentación interna es una estimación y así se marca.
¿Las 8,474 pruebas están corridas?
No, y es la mitad del dato. Las 8,474 están generadas, con su código de prueba de navegador y sus pasos, en 112 especificaciones, 1,749 suites y 50,993 pasos; y las 8,474 están en estado pendiente, ninguna con fecha de última ejecución y sin bitácora de corridas. Una prueba de navegador necesita una aplicación desplegada contra la que correr: lo que existe es la especificación. Se publica el conteo y se publica el cero.
¿De 181 entidades no salen 2,715 endpoints, si la plantilla tiene quince operaciones?
No, y esa multiplicación es el error más fácil de cometer. La plantilla de quince operaciones existe y está registrada en la base con su ruta y su procedimiento almacenado, y las rutas reales la cumplen. Pero no todas las operaciones aplican a todas las entidades: un catálogo no se aprueba ni se cancela. Lo medido son 5.4 rutas por entidad en el inventario y 6.8 acciones por entidad en la capa de pantalla. Esa proporción sí se sostiene.
¿Tengo que cambiar mi sistema de contabilidad?
No. La integración va en las dos direcciones: entran catálogos, órdenes y tipo de cambio, y salen la póliza de costo del lote, el comprobante de traslado con su complemento y el costo de flete por viaje con transportista, monto y placas ligados a la orden de compra. Esa integración está declarada en el brochure comercial, no en el registro de integraciones del motor, que para este proyecto está en cero. Lo que se afirma aquí es el modelo de conexión; sobre la calidad de un producto ajeno no opinamos.
¿El complemento Carta Porte ya es obligatorio en su versión 3.1?
Sí. Es obligatoria desde el 17 de julio de 2024, sin convivencia con la versión 3.0, y ampara el traslado terrestre, férreo, aéreo, marítimo y fluvial, en dos modalidades: comprobante de ingreso del transportista y comprobante de traslado con valor cero. El sistema lo emite del mismo registro de salida con el que arma el dato clave del evento de envío.
¿Mi auditor puede consultar la documentación sin que le abramos una cuenta?
Sí: hay un endpoint que genera un enlace de lectura y otro que lo sirve del lado del tercero, además de la descarga del conjunto completo. Eso es de la plataforma; del proyecto, el motor tiene 26 documentos aprobados dados de alta.
Referencias
- GS1 · EPCIS and CBV 2.0: estándar de eventos de la cadena de suministro, con enlace REST y serialización JSON-LD. Consultado el 27 de septiembre de 2026. ↗
- GS1 · Digital Link: resolución de un identificador a recursos web. Consultado el 27 de septiembre de 2026. ↗
- GS1 · General Specifications: identificador de producto, de localización y código seriado de contenedor de embarque; simbología GS1-128 y DataMatrix. Consultado el 27 de septiembre de 2026. ↗
- SAT · Complemento Carta Porte, versión 3.1: obligatoria desde el 17 de julio de 2024, sin convivencia con la versión 3.0. Consultado el 27 de septiembre de 2026. ↗
- FDA · Food Traceability Rule, 21 CFR Part 1 Subpart S: código de lote de trazabilidad, eventos críticos y datos clave; entrega en 24 horas. Consultada el 27 de septiembre de 2026. ↗
- SPARTANE · medición en la base del motor de la casa, el proyecto de este sistema, en modo de solo lectura y sin una sola escritura. Corte de servidor del 27 de septiembre de 2026 entre las 14:25:04 y las 14:30:16 h. De ahí salen: el inventario de 986 endpoints con su relleno campo por campo y sus campos vacíos; las 1,224 acciones de pantalla con endpoint, 1,224 con contrato de entrada tipado y 1,025 con procedimiento almacenado; los 1,093 enlaces pantalla-ruta; las 159 tareas de servidor; las 206 definiciones de alerta; las 181 entidades, 181 tablas físicas y 1,635 campos con tipo de dato; los 8,474 casos de prueba con sus 112 especificaciones, 1,749 suites y 50,993 pasos, todos pendientes de ejecución; y las quince operaciones canónicas del catálogo de convenciones.
- SPARTANE · dossier de evidencia de plataforma, 06-apis: conteo de controladores y atributos; ruteo; plantilla de entidad; motor de cambios; servicio de documentación; orquestador y concentrador de eventos; recepción de eventos externos; especificación pública. Verificado el 27 de septiembre de 2026 leyendo el código; nada se ejecutó en runtime. Todo esto es de la plataforma, no del proyecto de AgriNet.
- AgriNet · brochure comercial, 13 páginas: sección 01 (sistema de planificación y contabilidad), 04 (estándares técnicos de trazabilidad), 08 (logística, torre de control, costeo de flete, control documental de exportación y el registro de salida que cubre dos obligaciones) y 09 (drones, sensores por ámbito, portal del proveedor y portal del cliente).
El modelo
Primero ve su sistema funcionando, sin costo y sin compromiso. Después decide si lo compra o lo renta.
No es un demo: es AgriNet con sus procesos, sus áreas y su operación dentro. Entra, lo recorre y lo usa. Verlo no cuesta nada y no lo compromete a nada. Cuando decida, cobramos por resultados, no por entregables.
Siga por aquí