KORE · los cambios
El día que la autoridad cambia la versión del complemento, su sistema o cambia con ella o deja de facturar.
Su cliente le pidió un dato más en la evidencia de entrega, el corporativo cambió la política de margen y la autoridad fiscal publicó una versión nueva del complemento del traslado. En el modelo con el que se le vendió, esas tres cosas son tres órdenes de cambio. Aquí son una edición con su bitácora.
El cambio que no se puede aplazar
El caso que define a este sector: la versión nueva del complemento
En casi todas las industrias, un cambio que el sistema no absorbe se aguanta unos meses con una hoja de cálculo al lado. En el autotransporte de carga hay uno que no. El traslado de mercancías en territorio nacional tiene que ir amparado por un comprobante fiscal digital con complemento Carta Porte, con origen, destino, mercancías, operador, vehículo, remolques, permiso y póliza. La versión 3.1 del complemento es de uso obligatorio desde el 17 de julio de 2024, y entró sin convivencia con la versión anterior.
Traducido a lo que pasa en su oficina: el día en que una versión deja de recibirse, el sistema que no la tiene dentro no timbra. Y un sistema que no timbra, en esta industria, no es un sistema con una funcionalidad pendiente: es un sistema que ya no puede mover la carga, porque el comprobante es lo que la ampara, ni cobrarla, porque el comprobante es la factura. No hay hoja de cálculo que sustituya eso.
Un cambio de versión del complemento no es un campo nuevo. Es un paquete: catálogos que se actualizan, campos que aparecen o dejan de aceptarse, validaciones que cambian de criterio y reglas de llenado nuevas. Eso toca la pantalla donde se captura la salida, la validación previa al despacho, el servicio que arma el comprobante y el registro que se conserva. Es, exactamente, el tipo de cambio que esta página describe: uno que atraviesa varias capas del sistema y que en el modelo tradicional se cotiza.
Y hay más calendario del que suele mirarse: el decreto publicado en el Diario Oficial de la Federación el 7 de noviembre de 2025 reformó el artículo 29-A del Código Fiscal de la Federación, adicionó el 29-A Bis y adicionó el artículo 30-B, que entra en vigor el 1 de abril de 2026. Cada una de esas fechas es un cambio que alguien tiene que meter a un sistema, y ninguna de ellas se negocia con el proveedor.
Quien no tiene el complemento vigente dentro no deja de cumplir un requisito: deja de poder facturar.
En esta industria, un cambio normativo que el sistema no absorbe no es un retraso. Es una unidad que no sale.
Por qué existe la orden de cambio, y de qué es síntoma
La orden de cambio no es un trámite administrativo: es la consecuencia lógica de un modelo de contratación. Cuando el sistema que usted usa se le licenció cerrado, cualquier diferencia entre su operación y el producto se vuelve trabajo de alguien que no es usted. Ese trabajo hay que cotizarlo, aprobarlo, calendarizarlo, probarlo y facturarlo. La orden de cambio es la factura de esa distancia.
El efecto secundario es más caro que la factura. Con el tiempo, su empresa aprende a no pedir. Se deja de registrar el dato que el cliente embarcador pediría, se arma el costo por kilómetro en una hoja de cálculo paralela, y el sistema que costó una fortuna termina sirviendo para facturar y para nada más. Y no es culpa de su gente: es el modelo con el que se le vendió.
En un grupo que crece por adquisición el problema se multiplica, y el propio brochure de este sistema lo nombra: cada empresa integrada llega con su catálogo de unidades y con su forma de calcular el costo por kilómetro. Homologar eso es un cambio, y es un cambio que hay que hacer cada vez que se integra una empresa. En un modelo de órdenes de cambio, cada adquisición trae su propia cotización de sistemas.
Cuando pedir un cambio cuesta, el sistema deja de reflejar la operación. Y entonces el que decide vuelve a decidir con la hoja de cálculo.
El pretexto no es tecnológico
Lo que cambia en su operación, en un ejercicio cualquiera
Antes de hablar del motor, conviene ver la lista de cambios reales que el autotransporte federal de carga absorbió en los últimos ejercicios. Ninguno es una idea de mejora: todos son obligaciones con fecha, publicadas por una autoridad, que alguien tuvo que meter a un sistema.
Cambios con fecha que su sistema tuvo que absorber
| Cambio | Fecha | Qué toca dentro del sistema |
|---|---|---|
| Complemento Carta Porte versión 3.1 de uso obligatorio, sin convivencia con la versión anterior | 17 de julio de 2024 | Catálogos, campos y validaciones del comprobante; pantalla de captura de la salida; validación previa al despacho; servicio que arma el comprobante |
| Reforma del artículo 29-A del Código Fiscal de la Federación y adición del 29-A Bis | decreto del 7 de noviembre de 2025, en vigor el 1 de enero de 2026 | Requisitos del comprobante y su cancelación, con motivo y sustitución |
| Adición del artículo 30-B del Código Fiscal de la Federación | decreto del 7 de noviembre de 2025; el artículo entra en vigor el 1 de abril de 2026 | Obligaciones de registro y conservación, con su fecha propia de entrada |
| Endurecimiento de los supuestos de restricción y cancelación de sellos digitales, artículos 17-H y 17-H Bis | decreto del 7 de noviembre de 2025 | La dependencia del timbrado: si el sello se restringe, el viaje no se documenta |
| NOM-053-SCT-2-2023, que cancela expresamente la NOM-053-SCT-2-2010 | publicada en el Diario Oficial de la Federación el 11 de julio de 2024, exigible 180 días naturales después | Especificaciones del equipo de arrastre y salvamento en el expediente documental de la unidad que lo presta |
| Reglamento de los servicios auxiliares de arrastre, de arrastre y salvamento y de depósito de vehículos | publicado el 3 de mayo de 2023, en vigor el 4 de mayo de 2023 | Permisos y placas del servicio auxiliar, como documentos con vigencia dentro del expediente |
| Lineamientos de esos mismos servicios auxiliares | publicados el 15 de noviembre de 2023 | Documentación y resguardo del vehículo, y obligaciones del permisionario |
| Nueva Ley Federal de Protección de Datos Personales en Posesión de los Particulares, con autoridad distinta | publicada el 20 de marzo de 2025, en vigor el 21 de marzo de 2025; reforma del 14 de noviembre de 2025 | Aviso de privacidad del operador, base de licitud de su ubicación y el camino para ejercer sus derechos |
Fuente: complemento Carta Porte del CFDI (SAT); decreto de reformas al Código Fiscal de la Federación, Diario Oficial de la Federación, 7 de noviembre de 2025; NOM-053-SCT-2-2023 (DOF, 11 de julio de 2024); Reglamento (DOF, 3 de mayo de 2023) y Lineamientos (DOF, 15 de noviembre de 2023) de servicios auxiliares; Ley Federal de Protección de Datos Personales en Posesión de los Particulares (DOF, 20 de marzo de 2025) · verificado al 27 de septiembre de 2026
Ocho cambios obligatorios en tres ejercicios. En un modelo de órdenes de cambio, eso son ocho cotizaciones.
Los cuatro niveles de impacto, decididos antes de que usted edite
El motor de cambios de la plataforma no pregunta después qué tan grave fue lo que usted tocó. Lo sabe antes. Cada campo editable del sistema está clasificado en una tabla de reglas que vive en el código, y la clasificación se resuelve en tiempo de compilación, sin inferencia al momento.
Son 662 reglas de clasificación, contadas en el código: 2 en nivel bloqueado, 199 en nivel directo, 315 en nivel con efecto en cascada y 146 en nivel con aprobación. Un campo sin regla explícita cae al nivel directo por omisión, no a un limbo.
Nivel de impacto · qué hace el sistema
| Nivel | Nombre | Qué ocurre cuando alguien lo edita | Reglas |
|---|---|---|---|
| 0 | Bloqueado | El campo está deshabilitado en pantalla y no genera solicitud. Es el caso de lo que no se toca sin rehacer el expediente del viaje | 2 |
| 1 | Directo | Se aprueba solo y el cambio se aplica. Queda solicitud registrada y aplicada, con usuario y hora | 199 |
| 2 | Directo con efecto en cascada | Se aplica de inmediato y encola la tarea que propaga el efecto al resto del sistema | 315 |
| 3 | Con aprobación | La solicitud queda pendiente y el campo se bloquea con un indicador en pantalla hasta que el responsable aprueba o rechaza | 146 |
Fuente: niveles declarados; conteo por nivel verificado · 27 de septiembre de 2026
Las tres reglas que gobiernan el comportamiento están escritas y son verificables. Bloqueo visual: si un campo tiene una solicitud pendiente, el control queda deshabilitado y muestra el indicador de espera, de modo que el coordinador de tráfico y el de cumplimiento no pidan lo contrario sobre la misma tarifa. Detección automática: el nivel de impacto se determina en compilación. Reversión incorporada: la escritura sobre la tabla de origen lleva el valor original, y es el motor el que aplica el valor nuevo cuando corresponde — por eso un cambio pendiente no deja el expediente de un viaje a medias.
Los tipos de cambio: quién lo pide, qué hace el sistema, qué registro queda
Esta es la tabla que sostiene la afirmación del titular. Cada fila es un tipo de cambio que el sistema trata de manera distinta, con la tarea del motor que lo ejecuta cuando hay efecto en cascada y el registro que queda al terminar. Los ejemplos son de una operación de transporte de carga, no genéricos.
Tipo de cambio · quién lo pide · qué hace el sistema · qué registro queda
| Tipo de cambio | Ejemplo en su operación | Quién lo pide | Qué hace el sistema | Qué registro queda |
|---|---|---|---|---|
| Dato de configuración de nivel directo | La tolerancia de desviación de ruta; los días de aviso antes de que venza una licencia federal | El responsable del proceso, en su propia pantalla | Clasifica, aprueba solo y aplica el valor | Solicitud registrada y marcada como aplicada, con usuario y hora |
| Cambio de configuración con propagación | El catálogo de rutas y su tarifa pactada; la política de margen por cliente | El responsable del proceso | Aplica el valor y encola la tarea de configuración incremental, que ajusta el proyecto sin regenerarlo | Solicitud aplicada, tarea de cambio encolada y notificación informativa al proyecto |
| Alta de un artefacto nuevo | Una pantalla para el servicio de movilidad de personal; una entidad para el remolque que el grupo empezó a operar | El responsable del proceso, con la aprobación del responsable del sistema | Inserta el artefacto —pantalla, entidad o relación— en el proyecto existente | Solicitud, artefacto dado de alta con su identificador y notificación |
| Renombrado con propagación | El rol «coordinador de rutas» pasa a llamarse como lo llama su grupo | El responsable del sistema | Propaga el nombre nuevo a todos los textos del proyecto que lo referencian, sin intervención de un modelo de lenguaje | Solicitud aplicada y registro de los campos alcanzados |
| Baja en cascada | Se retira una empresa del grupo, una ruta o un tipo de unidad que dejó de operarse | El responsable del sistema | Elimina en cascada el artefacto aprobado y lo que dependía de él | Solicitud aplicada y notificación informativa |
| Cambio con aprobación | El umbral de consumo con el que se marca una anomalía de combustible; el criterio con el que una unidad queda fuera de servicio | Lo pide quien opera; lo aprueba quien responde por el proceso | Deja la solicitud pendiente y bloquea el campo en pantalla hasta la decisión | Solicitud con comentario obligatorio del aprobador, y su estado: aprobada o rechazada |
| Cambio bloqueado | La llave del viaje ya timbrado y entregado | Nadie: el campo no es editable | El control está deshabilitado en pantalla y no genera solicitud | No hay cambio, y por eso no hay duda sobre el comprobante |
| Cambio con efecto en el código | La versión nueva del complemento del traslado: catálogos, campos y validaciones distintos | El responsable del proceso | Ejecuta comprobación previa, respaldo, el cambio y el posproceso; y donde toca, regenera la capa de datos, los servicios y la pantalla | Instantánea de versión de la pantalla, con número de versión consultable |
Fuente: tareas de gestión de cambios del motor y el recorrido completo de un cambio:539-586 · los ejemplos de operación provienen del brochure de KORE y de las normas citadas · 27 de septiembre de 2026
Ocho tipos de cambio, ocho registros distintos. Ninguno de los ocho se cotiza.
Qué pasa, paso por paso, cuando alguien cambia algo
El recorrido está documentado y es el mismo para todos los niveles; lo que cambia es dónde se detiene. Se describe lo que ocurre, en orden, sin decir cuánto tarda.
Nadie abrió un ticket. Nadie cotizó. Y aun así hay expediente: solicitud, decisión, comentario, respaldo, versión y notificación.
- La pantalla pregunta antes de dibujarse. Al abrir, consulta qué campos tienen solicitud pendiente y los deshabilita con su indicador.
- Al guardar, el cambio se intercepta. La operación registra el cambio como tal, y la escritura sobre la tabla de origen lleva el valor original.
- El motor clasifica. Devuelve nivel de impacto, tarea de cambio asociada y tipo de operación.
- Se crea la solicitud. Auto-aprobada en los niveles directos, pendiente en el nivel con aprobación.
- Se decide. En los niveles directos, el propio sistema. En el nivel con aprobación, el responsable desde la pantalla de gestión de cambios, que aprueba o rechaza.
- El procedimiento aplica el cambio. Lee la solicitud, escribe sobre la tabla correspondiente, pasa la solicitud a aprobada, si el cambio tiene efecto en cascada, encola la tarea que lo propaga.
- Se ejecutan los efectos. Comprobación previa, respaldo, cambio, posproceso y —cuando el cambio lo exige— regeneración de la base, de los servicios y de las pantallas afectadas.
- Queda la versión. Se calcula el número de versión nuevo y se guarda la instantánea, consultable después por pantalla.
La matriz de estados de una solicitud de cambio
Una solicitud de cambio es una entidad con estados, no un correo. El catálogo de estados está en la base del motor y tiene ocho entradas, transcritas aquí tal como están (la base del motor de la casa, tabla cat_estado_cambio, consultada el 27 de septiembre de 2026 a las 14:09 h, hora del propio servidor).
Un detalle que conviene decir porque circula al contrario: no existe un estado «revertido» en el catálogo del motor. Aparece mencionado en material interno de trabajo, y no está en la base. La reversión se sostiene con el respaldo del artefacto y la instantánea de versión, que sí existen y se citan más arriba, no con un estado de la solicitud.
Los ocho estados de una solicitud de cambio, transcritos del motor
| # | Estado | Qué significa en la práctica |
|---|---|---|
| 1 | Por analizar | La solicitud existe y espera clasificación |
| 2 | Analizando | El motor está resolviendo nivel de impacto y efectos |
| 3 | Por aprobar | Espera la decisión del responsable; el campo está bloqueado en pantalla |
| 4 | Aprobada | La decisión está tomada y el cambio va a escribirse |
| 5 | Rechazada | La decisión fue no, con su comentario |
| 6 | Por aplicar cambios | Aprobada y en cola de aplicación |
| 7 | En proceso de aplicación de cambios | Hay una tarea de propagación corriendo |
| 8 | Cambios aplicados | El cambio está en el sistema, con su instantánea de versión |
Fuente: transcrito del motor de la casa, tabla cat_estado_cambio, consultada el 27 de septiembre de 2026 a las 14:09 h, hora del propio servidor. El recorrido documentado del caso frecuente es 1 → 3 → 4 → 7 → 8, con 5 como salida de la decisión.
Qué se verificó, con su fecha
La afirmación «los cambios se hacen en la sesión» sólo vale si alguien la probó campo por campo. La verificación de cobertura del motor de cambios existe, está fechada y dice lo siguiente.
Verificación de cobertura del motor de cambios
| Qué se verificó | Resultado | Fecha y origen |
|---|---|---|
| Campos editables recorridos de extremo a extremo | 229 campos en 63 entidades, con cero errores | 31 de mayo de 2026 |
| Reparto de esos campos por comportamiento | 175 se aprueban solos · 52 quedan pendientes de aprobación · 2 están bloqueados | 31 de mayo de 2026 |
| Corrida anterior, para comparar | 174 campos, cero errores | 30 de mayo de 2026 |
| Reglas de clasificación en el código | 662 reglas: 2 bloqueadas, 199 directas, 315 con cascada, 146 con aprobación | Conteo en código |
| Pantallas del portal con el motor integrado y pantallas sin él | Inventario con sus huecos nombrados: dos pantallas con regla declarada y sin integración de pantalla, y 31 pantallas fuera del motor por diseño | Verificación interna de cobertura |
| Catálogo de estados de la solicitud de cambio | Ocho estados, y ninguno se llama «revertido» | 27 de septiembre de 2026, 14:09 h del servidor · cat_estado_cambio |
Fuente: verificación interna de cobertura del motor de cambios de la plataforma, con las fechas indicadas, y consulta propia a la base del motor
Se publica también el hueco, porque un inventario que sólo lista lo que funciona no es un inventario. Hay pantallas del portal cuya regla de clasificación existe en el código sin la integración correspondiente en la pantalla, y hay pantallas que quedan fuera del motor por decisión de diseño. Están nombradas una por una en el inventario interno, con su fecha.
229 campos probados, cero errores, y los huecos con nombre. Eso es una verificación; lo demás es una promesa.
Por qué no hay orden de cambio
La respuesta no es comercial, es estructural. La orden de cambio existe para resolver cuatro incógnitas: qué tan grave es el cambio, quién tiene que autorizarlo, qué más se rompe y cuánto cuesta el trabajo de aplicarlo. En este sistema las cuatro están resueltas antes de que usted abra la pantalla.
Lo único que queda del ciclo tradicional es la parte que sí es suya: la decisión de negocio sobre si el cambio debe hacerse.
- La gravedad no se estima: está clasificada. 662 reglas en el código dicen el nivel de impacto de cada campo, decidido en compilación. No hay una junta que lo dictamine.
- La autorización no es un comité: es un estado. Los 146 campos de nivel con aprobación la piden dentro del sistema, a quien responde por el proceso, con comentario obligatorio. Los otros no la necesitan porque su efecto ya está acotado.
- Lo que se rompe no se investiga: se propaga. Las tareas de configuración incremental, alta de artefacto, renombrado con propagación y baja en cascada existen precisamente para eso, y son parte del motor, no de un proyecto aparte.
- El trabajo de aplicarlo no se cotiza porque no se hace a mano. Donde el cambio toca el código, el propio motor regenera la capa de datos, los servicios y la pantalla, y guarda la versión. No hay horas de consultoría que facturar porque no hay horas de consultoría.
Dicho al revés, que es como se entiende mejor: no es que hayamos decidido no cobrar por los cambios. Es que el cambio dejó de ser un entregable. Y cuando el cambio no es un entregable, no hay nada que facturar por entregarlo — por eso el trato es cobrar por resultados.
El contraste, en términos del modelo de contratación
La comparación que sigue no habla de la calidad de ningún producto ajeno. Habla del modelo con el que se contrata, que es lo que determina qué le pasa a usted el día que la autoridad publica una versión nueva del complemento del traslado.
El mismo cambio, dos modelos de contratación
| Cuando la autoridad cambia la versión del complemento | En un sistema licenciado, con órdenes de cambio | En KORE |
|---|---|---|
| Quién decide si se puede hacer | El proveedor, tras un análisis de viabilidad que se contrata | Está decidido: el campo tiene su nivel de impacto en el código |
| Quién autoriza | Un comité de control de cambios, con acta | El responsable del proceso, dentro del sistema, con comentario obligatorio |
| Qué se firma antes de empezar | Cotización, alcance y calendario | Nada. La solicitud es el registro, y la genera el propio sistema |
| Quién ejecuta | Consultoría, propia o de un socio implementador | El motor, con sus tareas de propagación y regeneración |
| Qué pasa con los demás módulos | Se investiga el impacto y se cotiza aparte | La propagación es parte del tipo de cambio: renombrado, alta, baja en cascada |
| Cómo se prueba | Un ciclo de pruebas contratado | Comprobación previa y posproceso dentro del recorrido; el sistema deja la versión |
| Qué queda documentado | El acta del comité y la orden firmada | Solicitud, estado, comentario, respaldo, instantánea de versión y notificación |
| Qué pasa si sale mal | Una orden de cambio nueva | El respaldo del artefacto y la instantánea de versión anterior existen desde antes de aplicar |
| Qué pasa mientras se resuelve | La operación espera, y mientras espera no puede documentar el traslado con la versión vigente | El cambio entra donde se trabaja, y el expediente del viaje no queda a medias |
| Qué aprende su empresa | A no pedir | A pedir, porque pedir no cuesta |
Fuente: comparación sobre el modelo de contratación, no sobre la calidad de ningún producto ajeno · 27 de septiembre de 2026
El que cobra por cada cambio tiene un incentivo que usted no comparte: que su operación no se parezca al producto.
Lo que esta página no le promete
Aquí no aparece ningún número de días, de horas ni de segundos, y la razón se dice completa: en el material técnico de la plataforma existen cifras de latencia del motor de cambios, y al revisarlas resultaron ser estimaciones escritas en un diagrama, sin instrumentación, sin entorno de medición, sin percentil y sin fecha. Una cifra así no se publica, ni siquiera cuando ayuda.
Tampoco se publica el porcentaje de cobertura que circula en el mismo material, porque su aritmética no cuadra con el universo de campos verificado. Lo que sí se publica es lo que se contó: 662 reglas en el código, 229 campos recorridos con cero errores el 31 de mayo de 2026, el reparto entre los que se aprueban solos, los que esperan aprobación y los que están bloqueados, y los ocho estados del catálogo del motor leídos de la base.
Y queda una distinción que conviene no perder. «En la sesión» describe dónde ocurre el cambio —dentro del sistema, en la pantalla donde se trabaja, sin salir a un proceso paralelo—, no cuánto tarda el reloj. Lo que se compromete es que no hay una orden de cambio entre su decisión y el sistema. El resto lo verá usted mismo cuando lo tenga enfrente.
Se describe lo que ocurre. No se compromete un número de días.
Preguntas frecuentes
¿Qué pasa cuando la autoridad publica una versión nueva del complemento del traslado?
Entra como cambio con efecto en el código, que es el tipo de cambio más grande de los ocho: catálogos, campos y validaciones distintos, que tocan la pantalla de captura, la validación previa al despacho y el servicio que arma el comprobante. El recorrido incluye comprobación previa, respaldo, el cambio, el posproceso y la regeneración de la base, de los servicios y de las pantallas afectadas, y termina con una instantánea de versión consultable. No se cotiza, y la razón por la que importa es simple: quien no tenga la versión vigente dentro no puede timbrar.
¿De verdad no hay órdenes de cambio, o es una forma de hablar?
No las hay porque el cambio no es un entregable que alguien tenga que producir a mano. Cada campo editable está clasificado en uno de cuatro niveles de impacto por una tabla de 662 reglas en el código; la autorización, cuando hace falta, es un estado de la solicitud dentro del propio sistema; y la propagación al resto del sistema la ejecuta el motor con sus tareas de configuración incremental, alta de artefacto, renombrado y baja en cascada.
¿Entonces cualquiera puede cambiar cualquier cosa?
No. Dos campos están en nivel bloqueado y no son editables por nadie; 146 exigen aprobación del responsable, con comentario obligatorio, y mientras esperan, el campo queda deshabilitado en pantalla con su indicador (regla de bloqueo visual). El control no desapareció: dejó de ser un trámite externo para ser una decisión registrada dentro del sistema.
¿En cuánto tiempo queda aplicado un cambio?
No publicamos un plazo, y decimos por qué: las cifras de tiempo que existen en el material técnico interno son estimaciones escritas en un diagrama, sin instrumentación ni entorno de medición. Lo que sí está verificado es el recorrido —solicitud, clasificación, decisión, aplicación, propagación, versión— y que 229 campos se recorrieron de extremo a extremo con cero errores el 31 de mayo de 2026. El plazo lo comprobará usted en el sistema, no en esta página.
¿Qué pasa si el cambio sale mal?
El respaldo del artefacto y la instantánea de versión se producen dentro del propio recorrido, antes y después de aplicar, no como un trámite aparte. Lo que no existe es un estado «revertido» de la solicitud: el catálogo de estados del motor tiene ocho entradas y ninguna es ésa, verificado en cat_estado_cambio el 27 de septiembre de 2026 a las 14:09 h del propio servidor. La reversión se sostiene con el respaldo y la versión, no con un estado.
¿Y cuando integramos una empresa nueva al grupo?
Ése es el caso donde el modelo de contratación se nota más. Homologar el catálogo de unidades, los clientes y la forma de calcular el costo por kilómetro de la empresa integrada es un cambio de configuración con propagación, donde hace falta, un alta de artefacto: entran por el motor, con solicitud, respaldo y versión. En un modelo de órdenes de cambio, cada adquisición trae su propia cotización de sistemas.
Referencias
- SAT · Complemento Carta Porte del CFDI, versión 3.1: publicado el 17 de junio de 2024 y de uso obligatorio desde el 17 de julio de 2024, sin convivencia con la versión anterior. Consultado el 27 de septiembre de 2026. ↗
- Decreto por el que se reforman, adicionan y derogan diversas disposiciones del Código Fiscal de la Federación. Diario Oficial de la Federación, 7 de noviembre de 2025. Reformó los artículos 17-H Bis y 29-A, adicionó el 29-A Bis y el 30-B —éste en vigor el 1 de abril de 2026— y una fracción al 17-H. Consultado el 27 de septiembre de 2026. ↗
- NOM-053-SCT-2-2023, características y especificaciones técnicas y de seguridad de los equipos para vehículos tipo grúa de arrastre y salvamento. Diario Oficial de la Federación, 11 de julio de 2024; exigible 180 días naturales después de su publicación. Cancela expresamente la NOM-053-SCT-2-2010. Consultada el 27 de septiembre de 2026. ↗
- Reglamento de los Servicios Auxiliares al Autotransporte Federal de Arrastre, de Arrastre y Salvamento y de Depósito de Vehículos. Diario Oficial de la Federación, 3 de mayo de 2023; en vigor el 4 de mayo de 2023. Lineamientos correspondientes, Diario Oficial de la Federación, 15 de noviembre de 2023. Consultados el 27 de septiembre de 2026. ↗
- Ley Federal de Protección de Datos Personales en Posesión de los Particulares. Diario Oficial de la Federación, 20 de marzo de 2025, en vigor el 21 de marzo de 2025, con reforma del 14 de noviembre de 2025. Consultada el 27 de septiembre de 2026. ↗
- Motor del motor de la casa · catálogo de estados de la solicitud de cambio, tabla cat_estado_cambio de la base del motor de la casa: ocho entradas, ninguna llamada «revertido». Consultada el 27 de septiembre de 2026 a las 14:09 h, hora del propio servidor.
- Evidencia de plataforma: motor de cambios del motor de la casa — 662 reglas de clasificación y su reparto por nivel; niveles de impacto, recorrido y estados de la solicitud; verificación de cobertura, 30 y 31 de mayo de 2026; y inventario y huecos. Recogidas con cita de archivo y línea en el expediente interno. Verificado el 27 de septiembre de 2026.
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 KORE 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.