INTRODUCCIÓN
El presente documento establece los términos, condiciones y límites operativos bajo los cuales iRODE TECHNOLOGY (en adelante "EL PROVEEDOR") prestará los servicios de implementación del sistema Odoo Enterprise al CLIENTE. Este documento complementa y forma parte integral del Contrato de Servicios firmado entre las partes.
La aceptación del Contrato de Servicios implica la aceptación total e incondicional de estos Términos y Condiciones. Cualquier condición particular que difiera de lo aquí establecido deberá ser acordada por escrito mediante addendum firmado por ambas partes.
1. ALCANCE DEL PROYECTO Y LÍMITES DE SERVICIO
1.1 DEFINICIÓN ESTRICTA DEL ALCANCE
El alcance del proyecto queda ESTRICTAMENTE delimitado a lo expresamente descrito en la Propuesta Comercial aceptada y firmada por el CLIENTE. No se contempla ninguna funcionalidad, módulo, desarrollo, integración o servicio que no esté específicamente mencionado en dicho documento.
Cualquier funcionalidad, proceso, escenario operativo, reporte, desarrollo o integración no expresamente detallado en la Propuesta Comercial se considera FUERA DEL ALCANCE y estará sujeto a evaluación, cotización adicional y aprobación formal mediante addendum al contrato.
IMPORTANTE: Los desarrollos personalizados y configuraciones están diseñados para cubrir los escenarios y casos de uso específicamente detallados en la Propuesta Comercial. No se contemplarán escenarios adicionales, variaciones de proceso o casos especiales que no hayan sido identificados y documentados durante la fase de levantamiento de información.
1.2 LÍMITES DE DESARROLLOS PERSONALIZADOS
Los desarrollos personalizados incluidos en el proyecto están sujetos a los siguientes límites:
• Cada desarrollo personalizado incluye hasta DOS (2) ciclos completos de revisión y ajustes después de la entrega inicial.
• Un ciclo de revisión se considera consumido cuando el CLIENTE solicita modificaciones después de haber revisado el desarrollo presentado.
• Las modificaciones solicitadas deben estar alineadas con los requerimientos originalmente aprobados. Cambios en los requerimientos base se consideran cambios de alcance.
• Modificaciones adicionales más allá del segundo ciclo de revisión serán consideradas automáticamente como cambios de alcance y cotizadas según las tarifas vigentes de servicios adicionales.
• La aprobación de un desarrollo personalizado debe realizarse por escrito. Una vez aprobado formalmente, cualquier modificación posterior será considerada cambio de alcance.
1.3 QUÉ NO ESTÁ INCLUIDO EN EL ALCANCE
Para evitar ambigüedades, se especifica expresamente que NO están incluidos en el alcance base del proyecto:
• Módulos de Odoo no mencionados en la Propuesta Comercial
• Integraciones con sistemas, aplicaciones o servicios externos no contemplados originalmente
• Reportes personalizados adicionales a los especificados
• Capacitaciones extraordinarias fuera de lo establecido en la Planificación del Proyecto
• Migraciones de datos de sistemas no identificados en la fase de levantamiento
• Desarrollos de funcionalidades identificadas después de la firma del contrato
• Soporte o mantenimiento posterior al período de garantía
• Visitas presenciales adicionales a las establecidas en la Planificación del Proyecto
• Asesorías o consultorías fuera del horario laboral establecido
• Configuraciones de infraestructura tecnológica del CLIENTE (redes, servidores locales, VPNs, etc.)
• Recuperación de datos por errores operativos del CLIENTE
• Corrección de problemas causados por modificaciones no autorizadas al sistema
2. LÍMITES OPERATIVOS Y POLÍTICAS DE ATENCIÓN
2.2 LÍMITES DE REUNIONES Y SESIONES DE TRABAJO
Las reuniones, sesiones de trabajo, capacitaciones y validaciones del proyecto están estrictamente limitadas a lo establecido en LA PLANIFICACIÓN. Esto incluye:
• Reuniones de levantamiento de información
• Sesiones de validación de configuraciones
• Reuniones de seguimiento y avances
• Capacitaciones por rol y módulo
• Sesiones de pilotos de prueba
• Reuniones de ajustes post-piloto
• Sesiones de acompañamiento durante Go Live
REPROGRAMACIÓN DE REUNIONES:
Las reprogramaciones de reuniones por parte del CLIENTE con menos de 24 horas de anticipación serán reprogramadas a discreción de EL PROVEEDOR según disponibilidad de agenda. EL PROVEEDOR notificará las nuevas opciones de fecha y horario disponibles para reagendar la sesión.
La reprogramación frecuente (3 o más veces para la misma sesión) o la falta de asistencia reiterada del CLIENTE a reuniones programadas puede resultar en la extensión del cronograma del proyecto, ya que afecta la disponibilidad y planificación del equipo de EL PROVEEDOR.
IMPORTANTE: EL PROVEEDOR se reserva el derecho de reprogramar reuniones con notificación mínima de 24 horas de anticipación en caso de situaciones extraordinarias (enfermedad de personal clave, emergencias, compromisos ineludibles con otros clientes, etc.).
Reuniones adicionales solicitadas fuera del cupo establecido en LA PLANIFICACIÓN estarán sujetas a disponibilidad de agenda y serán cotizadas según las tarifas vigentes. Para conocer las tarifas actuales, contacte al área comercial o de proyectos de EL PROVEEDOR.
2.3 SOPORTE TÉCNICO Y ACUERDO DE NIVEL DE SERVICIO (SLA)
El soporte técnico durante el período de implementación se rige por las políticas de atención de EL PROVEEDOR y los estándares de respuesta establecidos en nuestro Acuerdo de Nivel de Servicio (SLA).
NIVELES DE SEVERIDAD Y TIEMPOS DE RESPUESTA:
Para conocer los detalles completos de horarios de atención, tiempos de respuesta según criticidad, procedimientos de escalamiento y créditos por incumplimiento de SLA, consulte nuestro "Anexo SLA - Estándares de Respuesta y Niveles de Servicio" disponible en https://www.irodetech.com/sla o solicitándolo al área de proyectos.
2.4 POLÍTICAS DE ATENCIÓN VIGENTES
Para detalles operativos específicos sobre atención, capacitaciones, metodologías de trabajo, procedimientos de escalamiento y otros aspectos operativos, el CLIENTE puede consultar las "Políticas de Atención y Servicio" vigentes de EL PROVEEDOR, disponibles en https://www.irodetech.com/terms o solicitándolas al correo ventas@irodetech.com.
Estas políticas son complementarias a este documento y pueden ser actualizadas periódicamente. Las versiones vigentes al momento de la firma del contrato serán las aplicables durante todo el proyecto, salvo que ambas partes acuerden por escrito adoptar versiones posteriores.
3. ESTRUCTURA ORGANIZACIONAL Y RESPONSABILIDADES DEL CLIENTE
3.1 DESIGNACIÓN OBLIGATORIA DE PROJECT MANAGER O DIRECTOR DE PROYECTO
El CLIENTE está OBLIGADO a designar formalmente a un Project Manager o Director de Proyecto (en adelante "PM DEL CLIENTE") que será el interlocutor principal y coordinador por parte del CLIENTE durante todo el proyecto.
REQUISITOS DEL PM DEL CLIENTE:
• Debe tener autoridad para tomar decisiones operativas sobre el proyecto
• Debe tener disponibilidad mínima según lo establecido en LA PLANIFICACIÓN
• Debe tener capacidad de coordinar con todas las áreas involucradas del CLIENTE
• Debe ser el punto de contacto único para aprobaciones operativas del día a día
RESPONSABILIDADES DEL PM DEL CLIENTE:
• Coordinar la disponibilidad del personal clave del CLIENTE para reuniones y capacitaciones
• Asegurar la entrega oportuna de información requerida por EL PROVEEDOR
• Gestionar las aprobaciones internas del CLIENTE
• Ser el canal oficial de comunicación entre su organización y el equipo de EL PROVEEDOR
• Escalar a niveles superiores cuando se requieran decisiones estratégicas o de inversión
• Monitorear el cumplimiento de responsabilidades del CLIENTE establecidas en LA PLANIFICACIÓN
• Participar activamente en todas las reuniones de seguimiento del proyecto
COORDINACIÓN CON NIVELES SUPERIORES:
El PM DEL CLIENTE deberá mantener informado y trabajar coordinadamente con el dueño, propietario, Gerente General o Director Ejecutivo de la empresa, según corresponda, para:
• Obtener aprobaciones de decisiones estratégicas o que impliquen inversión adicional
• Escalar situaciones que requieran intervención de niveles superiores
• Asegurar que las decisiones del proyecto estén alineadas con la estrategia de la empresa
• Evitar inconvenientes, malentendidos o desalineaciones entre niveles organizacionales
Se reconoce que algunos clientes prefieren mantener control directo sobre ciertos aspectos del proyecto. En estos casos, el PM DEL CLIENTE actuará como facilitador y coordinador, pero las decisiones críticas se tomarán en conjunto con los niveles superiores designados.
DESIGNACIÓN DE ASISTENTE DE PROYECTO:
Si el PM DEL CLIENTE es el dueño o Director General de la empresa y tiene limitaciones de disponibilidad, DEBE designar formalmente a un Asistente de Proyecto que asuma las responsabilidades operativas del día a día, con autoridad delegada para:
• Coordinar reuniones y capacitaciones
• Recopilar y entregar información
• Aprobar avances operativos (no estratégicos)
• Comunicarse directamente con el equipo de EL PROVEEDOR
La falta de designación formal de un PM DEL CLIENTE o Asistente de Proyecto dentro de los primeros 5 días hábiles posteriores a la firma del contrato faculta a EL PROVEEDOR para suspender el inicio del proyecto hasta que esta designación se formalice, sin que esto implique extensión de plazos de entrega.
3.2 DISPONIBILIDAD DE PERSONAL CLAVE
El CLIENTE debe garantizar la disponibilidad del personal clave de su organización según lo establecido en LA PLANIFICACIÓN del proyecto. La falta de disponibilidad de personal clave se considera incumplimiento del CLIENTE y faculta a EL PROVEEDOR para:
• Reprogramar actividades según disponibilidad de agenda de EL PROVEEDOR
• Extender el cronograma del proyecto
• Suspender temporalmente actividades hasta que se garantice la disponibilidad requerida
DEFINICIÓN DE FALTA DE DISPONIBILIDAD:
Se considera falta de disponibilidad cuando el personal clave del CLIENTE:
• No asiste a reuniones programadas con más de 24 horas de anticipación (sin causa justificada documentada)
• No completa tareas asignadas en los plazos acordados
• No está disponible para validaciones críticas en los tiempos establecidos en LA PLANIFICACIÓN
• Participa parcialmente en capacitaciones (llega tarde, se retira antes, no presta atención)
Tres (3) o más faltas de disponibilidad del mismo personal clave facultan a EL PROVEEDOR para solicitar formalmente al CLIENTE el reemplazo de dicha persona o la extensión formal del cronograma.
3.3 ENTREGA OPORTUNA DE INFORMACIÓN
El CLIENTE se compromete a entregar TODA la información requerida por EL PROVEEDOR en los plazos establecidos en LA PLANIFICACIÓN del proyecto. La información debe ser entregada:
• En formatos digitales editables (Excel, CSV, SQL, XML, JSON, etc.)
• Completa y sin datos faltantes críticos
• Organizada y estructurada según los templates proporcionados por EL PROVEEDOR
• Validada y aprobada internamente por el CLIENTE antes de la entrega
TIPOS DE INFORMACIÓN REQUERIDA (de manera enunciativa, no limitativa):
• Organigrama actualizado de la empresa
• Plan contable vigente y políticas contables
• Catálogos de productos/servicios con códigos internos y clasificaciones
• Listados completos de clientes con datos fiscales y comerciales
• Listados completos de proveedores con datos fiscales y comerciales
• Saldos iniciales contables (balance general y estado de resultados)
• Saldos iniciales de inventarios con valorización
• Saldos iniciales de cuentas por cobrar y cuentas por pagar
• Listas de precios vigentes
• Estructuras de comisiones y descuentos
• Procesos documentados (diagramas de flujo preferentemente)
• Políticas internas relevantes para la operación
• Accesos a sistemas actuales (si aplica para migraciones)
• Credenciales de servicios externos a integrar (APIs, Google Drive, etc.)
CONSECUENCIAS POR RETRASO EN ENTREGA DE INFORMACIÓN:
• Retraso de 1 a 5 días hábiles: Se extiende el cronograma en proporción 1:1 (cada día de retraso = 1 día de extensión)
• Retraso de 6 a 10 días hábiles: Se extiende el cronograma en proporción 1:2 (cada día de retraso = 2 días de extensión)
• Retraso mayor a 10 días hábiles: EL PROVEEDOR puede suspender el proyecto hasta recibir la información, sin obligación de cumplir con el cronograma original
La información incompleta, desorganizada o en formatos no procesables será devuelta al CLIENTE para corrección, contabilizándose el tiempo de corrección como retraso imputable al CLIENTE.
3.4 APROBACIONES, VALIDACIONES Y PRUEBAS DE ACEPTACIÓN DE USUARIO (UAT)
PLAN DE PRUEBAS Y CASOS DE ACEPTACIÓN:
Cada entregable del proyecto (configuraciones, desarrollos personalizados, reportes, integraciones) incluirá un Plan de Pruebas y Casos de Aceptación que definirá:
• Pruebas críticas (funcionalidades esenciales que deben operar correctamente)
• Pruebas no críticas (funcionalidades secundarias o de mejora)
• Criterios de éxito específicos para cada prueba
• Datos de muestra y escenarios de prueba
• Responsables de ejecutar cada prueba
• Procedimiento de reporte de observaciones
LÍMITES DE CICLOS DE APROBACIÓN:
Cada entregable del proyecto incluye hasta DOS (2) ciclos de revisión y ajustes. Un ciclo se consume cuando el CLIENTE solicita modificaciones después de revisar el entregable.
PLAZOS DE APROBACIÓN Y PROCEDIMIENTO UAT:
El CLIENTE dispone de CINCO (5) días hábiles para:
• Ejecutar las pruebas definidas en el Plan de Pruebas
• Reportar observaciones formalmente por escrito
• Aprobar o rechazar el entregable
Si el CLIENTE no responde dentro de los 5 días hábiles, se aplicará el siguiente procedimiento:
• Día 6-7: EL PROVEEDOR envía recordatorio formal incluyendo el Plan de Pruebas y evidencia de que el CLIENTE recibió instrucciones para la prueba
• Día 8-10: Se extiende automáticamente el cronograma en los días de retraso
• Día 11+: El entregable se considerará APROBADO TÁCITAMENTE únicamente si:
a) Se han cumplido las pruebas críticas formales definidas en el Plan de Pruebas
b) Existe evidencia documentada en el tracker/sistema de gestión de que el CLIENTE recibió instrucciones claras para ejecutar las pruebas
c) El CLIENTE no reportó fallas críticas dentro del período de revisión
d) EL PROVEEDOR procedió con las siguientes fases
LIMITACIONES DE LA APROBACIÓN TÁCITA:
La aprobación tácita NO exime al CLIENTE de reportar posteriormente problemas o errores que se identifiquen durante el período de garantía, siempre que:
• Sean errores de programación o configuración realizados por EL PROVEEDOR
• No sean causados por uso inadecuado o modificaciones del CLIENTE
• Estén cubiertos por las cláusulas de garantía de la Sección 7
La aprobación tácita aplica para permitir el avance del proyecto, pero NO libera a EL PROVEEDOR de corregir errores genuinos dentro del período de garantía.
MECANISMO DE APROBACIÓN FORMAL:
Todas las aprobaciones deben realizarse POR ESCRITO a través de:
• Correo electrónico a ventas@irodetech.com
• Sistema de gestión del proyecto (si aplica)
• Firma de actas de validación cuando se requiera
La aprobación debe incluir:
• Identificación clara del entregable aprobado/rechazado
• Resultados de las pruebas ejecutadas según el Plan de Pruebas
• Nombre y cargo de quien aprueba (debe tener autoridad para hacerlo)
• Fecha de aprobación
• Observaciones detalladas en caso de rechazo
NO se consideran aprobaciones válidas:
• Comunicaciones verbales o telefónicas
• Mensajes por WhatsApp o redes sociales (salvo que EL PROVEEDOR los confirme por escrito)
• Aprobaciones de personas sin autoridad designada formalmente
MODIFICACIONES POST-APROBACIÓN:
Cualquier modificación solicitada a un entregable ya aprobado formalmente (explícita o tácitamente) se considera automáticamente CAMBIO DE ALCANCE y será cotizada y facturada por separado según las tarifas vigentes de servicios adicionales.
4. GESTIÓN DE CAMBIOS DE ALCANCE
4.1 DEFINICIÓN DE CAMBIO DE ALCANCE
Se consideran cambios de alcance (sujetos a evaluación, cotización y aprobación adicional) todas las solicitudes que impliquen:
• Funcionalidades no mencionadas en la Propuesta Comercial original
• Modificaciones a desarrollos personalizados más allá del segundo ciclo de revisión
• Cambios en requerimientos previamente aprobados y validados
• Integraciones con sistemas o servicios no contemplados originalmente
• Reportes adicionales a los especificados en la Propuesta Comercial
• Nuevos módulos de Odoo no incluidos en el alcance original
• Escenarios operativos o casos de uso no identificados durante el levantamiento inicial
• Capacitaciones adicionales fuera de lo establecido en LA PLANIFICACIÓN
• Migraciones de datos de sistemas no contemplados inicialmente
• Modificaciones a procesos de negocio ya configurados y aprobados
• Personalizaciones adicionales de interfaces o reportes
• Ajustes causados por cambios en legislación fiscal/laboral posteriores a la firma del contrato (salvo que se haya contratado servicio de actualización legislativa)
4.2 PROCEDIMIENTO PARA GESTIÓN DE CAMBIOS DE ALCANCE
Cuando el CLIENTE requiera un cambio de alcance, se seguirá el siguiente procedimiento OBLIGATORIO:
PASO 1 - SOLICITUD FORMAL:
El CLIENTE envía solicitud por escrito a ventas@irodetech.com detallando:
• Descripción clara de la funcionalidad o modificación requerida
• Justificación de negocio
• Urgencia/prioridad
• Impacto esperado si no se implementa
PASO 2 - EVALUACIÓN POR EL PROVEEDOR:
EL PROVEEDOR analiza la solicitud y determina:
• Si efectivamente constituye un cambio de alcance o está ya incluido en el contrato
• Impacto en tiempo (días/semanas de extensión del cronograma)
• Impacto en costo (horas de desarrollo/configuración requeridas)
• Impacto en recursos (disponibilidad del equipo técnico)
• Dependencias con otras partes del proyecto
Plazo de evaluación: Máximo 5 días hábiles desde recepción de solicitud formal.
PASO 3 - COTIZACIÓN:
Si se confirma que es un cambio de alcance, EL PROVEEDOR presenta:
• Cotización económica detallada
• Impacto en el cronograma del proyecto
• Condiciones de pago del cambio
• Vigencia de la cotización (usualmente 7 días hábiles)
PASO 4 - APROBACIÓN O RECHAZO:
El CLIENTE debe responder formalmente por escrito:
• Aprobando la cotización (se procede al Paso 5)
• Rechazando la cotización (se archiva la solicitud)
• Solicitando negociación o ajustes (se itera entre Pasos 3 y 4)
PASO 5 - FORMALIZACIÓN:
Si el CLIENTE aprueba:
• Se firma un ADDENDUM al Contrato de Servicios
• Se actualiza LA PLANIFICACIÓN del proyecto reflejando el nuevo alcance y cronograma
• El CLIENTE realiza el pago inicial del cambio (50% del monto del cambio)
• Se procede con la implementación del cambio
PASO 6 - IMPLEMENTACIÓN Y CIERRE:
• EL PROVEEDOR implementa el cambio según lo acordado en el addendum
• El CLIENTE valida y aprueba el cambio implementado
• El CLIENTE realiza el pago final del cambio (50% restante)
• Se cierra formalmente el cambio de alcance
IMPORTANTE: NO se iniciará NINGÚN trabajo relacionado con un cambio de alcance sin la firma del addendum correspondiente y el pago inicial del 50%. Solicitudes verbales o por canales informales NO serán atendidas.
4.3 TARIFAS DE SERVICIOS ADICIONALES
Los servicios adicionales y cambios de alcance serán cotizados según las tarifas vigentes de EL PROVEEDOR. Para conocer las tarifas actuales y solicitar una cotización específica, contacte al área comercial o de proyectos a través de:
• Correo electrónico: ventas@irodetech.com
• WhatsApp Business: +502 5212 1225
• PBX: +502 6676-6804
Las tarifas pueden variar según la complejidad del servicio, la urgencia requerida, y la disponibilidad del equipo técnico.
4.4 CAMBIOS NO SOLICITADOS POR EL CLIENTE
Si durante la implementación EL PROVEEDOR identifica mejoras, optimizaciones o funcionalidades adicionales que podrían beneficiar al CLIENTE pero que no están en el alcance original:
• EL PROVEEDOR las presentará como RECOMENDACIONES opcionales
• La implementación de estas recomendaciones requerirá aprobación formal del CLIENTE
• Serán cotizadas como cambios de alcance
• El CLIENTE es libre de aceptarlas o rechazarlas sin penalización
EL PROVEEDOR NO implementará cambios de alcance por iniciativa propia, aunque los considere beneficiosos, sin la aprobación formal y pago correspondiente del CLIENTE.
5. CONDICIONES DE PAGO Y PENALIZACIONES
5.1 CALENDARIO DE PAGOS Y FACTURACIÓN
Los pagos del proyecto se realizan según lo establecido en LA PLANIFICACIÓN del proyecto y en la Propuesta Comercial aceptada. Los hitos de pago típicos son:
PRIMER PAGO:
• Momento: Al firmar el Contrato de Servicios, ANTES de iniciar cualquier trabajo
• Porcentaje: Según lo establecido en la Propuesta Comercial (típicamente 50%)
• Condición: Es REQUISITO INDISPENSABLE para dar inicio al proyecto
PAGOS SUBSECUENTES:
• Momento: Al completar hitos específicos del proyecto según LA PLANIFICACIÓN
• Porcentaje: Según lo establecido en la Propuesta Comercial
• Condición: EL PROVEEDOR emite factura al completar el hito correspondiente
5.2 FACTURACIÓN Y EXIGIBILIDAD DE PAGOS
Los pagos se vuelven EXIGIBLES en el momento en que EL PROVEEDOR emite la factura correspondiente, lo cual ocurre cuando:
• Se firma el Contrato de Servicios (primer pago), O
• Se completa un hito del proyecto según LA PLANIFICACIÓN y EL PROVEEDOR lo notifica formalmente al CLIENTE
IMPORTANTE: Los pagos están vinculados a la FACTURACIÓN emitida por EL PROVEEDOR al completar los hitos establecidos en LA PLANIFICACIÓN, conforme al avance real del proyecto.
El CLIENTE tiene un plazo MÁXIMO de CINCO (5) días hábiles para efectuar cada pago desde la fecha de emisión de la factura.
MEDIOS DE PAGO ACEPTADOS:
• Transferencia bancaria (datos proporcionados en factura)
• Depósito bancario (datos proporcionados en factura)
• Cheque certificado a nombre de iRODE TECHNOLOGY
5.3 MORA EN PAGOS Y CONSECUENCIAS
Si el CLIENTE no realiza un pago en el plazo establecido (5 días hábiles desde emisión de factura), se aplicarán las siguientes consecuencias AUTOMÁTICAS:
DÍAS 1-5 DE MORA (días hábiles 6-10 desde la emisión de factura):
• Se envía recordatorio formal de pago pendiente
• Se aplica interés moratorio del 2% mensual sobre el monto pendiente (prorrateado por día)
DÍAS 6-10 DE MORA (días hábiles 11-15 desde la emisión de factura):
• Se envía segundo recordatorio formal con advertencia de suspensión
• Se continúa aplicando interés moratorio del 2% mensual
• Se suspende cualquier nueva entrega de avances al CLIENTE
DÍA 11 DE MORA EN ADELANTE (día hábil 16+ desde la emisión de factura):
• SUSPENSIÓN AUTOMÁTICA DEL PROYECTO: EL PROVEEDOR suspende todas las actividades del proyecto hasta que el pago se regularice
• Se continúa aplicando interés moratorio del 2% mensual
• El cronograma se extiende automáticamente en el número de días que dure la suspensión
• No se reanuda el proyecto hasta que se liquide el monto total adeudado MÁS los intereses moratorios acumulados
DÍA 31 DE MORA EN ADELANTE (aproximadamente día hábil 35+ desde la emisión de factura):
• TERMINACIÓN DEL CONTRATO: EL PROVEEDOR puede dar por terminado unilateralmente el Contrato de Servicios
• El CLIENTE pierde cualquier derecho a reembolso de pagos ya realizados
• El CLIENTE debe pagar el 100% del trabajo completado hasta la fecha de terminación, MÁS los intereses moratorios
• Se inician acciones legales para cobro de adeudos si fuera necesario
5.4 PAGOS DE CAMBIOS DE ALCANCE
Los cambios de alcance aprobados mediante addendum tienen su propio esquema de pago:
• 50% al aprobar y firmar el addendum (ANTES de iniciar el trabajo del cambio)
• 50% al finalizar y aprobar el cambio de alcance
Los pagos de cambios de alcance son INDEPENDIENTES de los pagos del proyecto base y se rigen por las mismas políticas de plazo y mora descritas anteriormente.
5.5 RETRASOS IMPUTABLES A EL PROVEEDOR
Si EL PROVEEDOR incurre en retrasos IMPUTABLES EXCLUSIVAMENTE a su responsabilidad (no causados por el CLIENTE), EL PROVEEDOR informará debidamente al equipo del CLIENTE o al CLIENTE sobre:
• La causa del retraso
• El impacto estimado en el cronograma
• Las medidas correctivas que se implementarán
• El nuevo cronograma ajustado
EL PROVEEDOR se compromete a mantener comunicación transparente y oportuna sobre el estado del proyecto y cualquier eventualidad que pueda afectar los plazos acordados.
En caso de retrasos significativos (superiores al 20% del plazo total del proyecto) imputables exclusivamente a EL PROVEEDOR, se podrán negociar ajustes o compensaciones según corresponda y la gravedad del retraso.
5.6 PENALIZACIONES POR INCUMPLIMIENTOS DEL CLIENTE
Además de la extensión automática del cronograma por retrasos imputables al CLIENTE (entrega tardía de información, falta de disponibilidad de personal, retrasos en aprobaciones), se aplicarán las siguientes penalizaciones:
CANCELACIÓN DEL PROYECTO POR PARTE DEL CLIENTE:
• No hay reembolso de pagos ya realizados bajo ninguna circunstancia
• El CLIENTE debe pagar el 100% del trabajo completado hasta la fecha de cancelación (si es mayor a lo ya pagado)
• EL PROVEEDOR NO entregará el código fuente en caso de terminación anticipada del contrato
• Se entregan únicamente las configuraciones y el acceso al sistema en el estado en que se encuentre
FALTA REITERADA DE DISPONIBILIDAD DE PERSONAL CLAVE:
• Si se acumulan 5 o más ausencias injustificadas de personal clave del CLIENTE a reuniones programadas con anticipación, EL PROVEEDOR puede extender unilateralmente el cronograma en 2 semanas por cada 5 ausencias acumuladas
INFORMACIÓN FALSA O INCOMPLETA ENTREGADA INTENCIONALMENTE:
• Si el CLIENTE oculta información relevante o proporciona información falsa que impacte significativamente el proyecto, EL PROVEEDOR puede dar por terminado el contrato sin reembolso de pagos realizados
6. ACCESOS, SEGURIDAD Y CONFIDENCIALIDAD
6.1 ACCESO AL SISTEMA Y BASE DE DATOS
Durante el período de implementación, EL PROVEEDOR contará con los accesos necesarios al sistema Odoo del CLIENTE para llevar a cabo las labores de configuración, desarrollo, pruebas y resolución de incidencias. El alcance y nivel de dichos accesos queda a discreción de EL PROVEEDOR, quien los gestionará de manera responsable y conforme a las buenas prácticas de seguridad, limitándolos a lo estrictamente requerido para el correcto avance del proyecto.
Todo acceso queda registrado automáticamente en los logs del sistema Odoo. EL PROVEEDOR mantendrá trazabilidad de los cambios significativos realizados durante el proyecto.
Al finalizar el proyecto y efectuado el Go Live, EL PROVEEDOR trasladará los accesos administrativos al CLIENTE a través de una persona debidamente designada y facultada por este último para administrarlos. Dicha persona será responsable de gestionar usuarios, permisos y credenciales de manera segura y conforme a las políticas internas del CLIENTE.
Los accesos de EL PROVEEDOR al sistema serán desactivados una vez concluida la implementación, salvo que el CLIENTE los autorice expresamente para fines específicos de soporte, mantenimiento o nuevos desarrollos bajo contrato vigente.
Durante el período de garantía (90 días post Go Live), el CLIENTE se compromete a otorgar acceso a EL PROVEEDOR cuando sea razonablemente necesario para la corrección de errores cubiertos por dicha garantía.
PÉRDIDA DE GARANTÍA:
Cualquier modificación no autorizada al sistema, instalación de módulos no aprobados por EL PROVEEDOR, cambios directos en la base de datos, o acceso concedido a terceros sin autorización expresa de EL PROVEEDOR, invalidará automáticamente la garantía del proyecto, conforme a lo establecido en la Sección 7.4 de este documento.
6.2 PROPIEDAD INTELECTUAL Y CÓDIGO FUENTE
EL PROVEEDOR, en su rol de implementador y partner autorizado de Odoo, instalará y operará en los servidores y base de datos del CLIENTE ciertos programas, módulos y aplicaciones que constituyen propiedad intelectual exclusiva de EL PROVEEDOR y/o de Odoo Inc., de conformidad con lo siguiente:
i) El sistema ERP utilizado es propiedad exclusiva de Odoo Inc. Su uso está sujeto a los términos de la licencia maestra correspondiente. El CLIENTE reconoce que EL PROVEEDOR actúa como Partner de implementación autorizado, sin que esto implique transferencia alguna de los derechos de autor sobre el código núcleo (core) de Odoo.
ii) Todos los nuevos desarrollos, módulos adicionales (add-ons), integraciones de API, personalizaciones de flujos de trabajo y herramientas complementarias creadas o aplicadas por EL PROVEEDOR para la plataforma son propiedad intelectual exclusiva de EL PROVEEDOR.
iii) EL PROVEEDOR se reserva todos los derechos de autor sobre las metodologías, know-how y código fuente de los desarrollos específicos realizados. El CLIENTE recibe una licencia de uso no exclusiva, intransferible y limitada sobre dichos desarrollos, supeditada a la vigencia del licenciamiento correspondiente de la plataforma base.
Estos derechos de propiedad intelectual no están sujetos a términos o plazos de aplicación de la confidencialidad, por lo que su resguardo y limitación de uso serán de aplicación a perpetuidad.
ACCESO AL CÓDIGO FUENTE:
La entrega del código fuente, acceso a repositorios o cualquier forma de transferencia de los desarrollos personalizados no forma parte del alcance estándar del servicio. Cualquier solicitud relacionada con el acceso, custodia o entrega del código fuente será evaluada de manera individual por EL PROVEEDOR, quien determinará a su discreción razonable las condiciones, alcances, restricciones y costos aplicables según el caso.
Para dichos supuestos, las partes suscribirán los acuerdos complementarios que correspondan, incluyendo Acuerdos de Confidencialidad específicos para el código y/o Acuerdos de Custodia (Code Escrow) cuando aplique.
El detalle de los términos, condiciones y alcances aplicables a estas solicitudes se encuentra disponible en el Acuerdo de Confidencialidad de Código y Propiedad Intelectual de iRODE TECHNOLOGY, accesible en: [ENLACE AL ACUERDO]
En caso de terminación anticipada del contrato por cualquier causa, EL PROVEEDOR no estará obligado a entregar el código fuente. El CLIENTE recibirá el acceso al sistema en el estado en que se encuentre, la documentación funcional generada hasta la fecha, y los accesos administrativos necesarios para operar el sistema.
6.3 RESPALDO DE DATOS, RESTAURACIÓN Y PROCEDIMIENTOS
RESPALDOS AUTOMÁTICOS:
Odoo Enterprise incluye respaldos automáticos diarios gestionados por Odoo S.A. en sus servidores (Bélgica/Luxemburgo). EL PROVEEDOR no administra directamente dichos respaldos, pero configurará correctamente los parámetros disponibles durante la implementación y asesorará al CLIENTE sobre su uso y verificación.
El CLIENTE puede solicitar la restauración de respaldos directamente desde el panel de administración de Odoo o con asistencia de EL PROVEEDOR según corresponda.
PROCEDIMIENTOS DE RESTAURACIÓN:
Durante el período de garantía (90 días post Go Live), EL PROVEEDOR asistirá al CLIENTE en procesos de restauración sin costo adicional, con tiempo de respuesta máximo de 4 horas hábiles y restauración efectiva en un plazo máximo de 24 horas hábiles, sujeto a la disponibilidad del respaldo en los servidores de Odoo S.A.
Posterior al período de garantía, la asistencia en restauración podrá contratarse bajo Contrato de Soporte vigente, conforme a las tarifas y tiempos de respuesta del nivel de servicio contratado.
RETENCIÓN Y VERIFICACIÓN:
Odoo S.A. mantiene respaldos con retención típica de 30 días. Para retenciones más largas, el CLIENTE deberá implementar respaldos locales adicionales. Se recomienda realizar verificaciones periódicas de integridad de los respaldos (trimestral o semestralmente). EL PROVEEDOR puede asistir en estas pruebas como parte de un contrato de soporte.
RESPONSABILIDADES:
EL PROVEEDOR no es responsable por pérdida de datos causada por acciones de usuarios del CLIENTE, fallas de infraestructura, ataques cibernéticos, credenciales comprometidas, modificaciones no autorizadas al sistema, ni por limitaciones en la política de retención de respaldos de Odoo S.A.
6.4 CONFIDENCIALIDAD Y PROTECCIÓN DE DATOS
COMPROMISO MUTUO DE CONFIDENCIALIDAD:
Ambas partes se comprometen a mantener estricta confidencialidad sobre la información comercial, financiera, técnica, operativa y de personal a la que tengan acceso en el marco del proyecto, incluyendo pero no limitado a: estrategias, precios, estados financieros, configuraciones, integraciones, desarrollos, datos de clientes y proveedores, y procesos internos.
OBLIGACIONES DE EL PROVEEDOR:
• No divulgar información del CLIENTE a terceros
• Utilizar la información exclusivamente para los fines del proyecto
• Implementar medidas de seguridad razonables para proteger la información
• Eliminar datos de prueba con información real al concluir el proyecto
• No utilizar datos del CLIENTE para entrenar modelos de inteligencia artificial sin autorización expresa
• No utilizar el nombre del CLIENTE como referencia comercial sin autorización previa por escrito
OBLIGACIONES DEL CLIENTE:
• No divulgar información técnica propietaria de EL PROVEEDOR (metodologías, know-how, código fuente)
• No utilizar conocimiento adquirido durante el proyecto para desarrollar soluciones competidoras
• Proteger adecuadamente las credenciales de acceso al sistema
• No realizar acciones que puedan afectar negativamente la certificación o estatus de EL PROVEEDOR como Partner Oficial de Odoo
GESTIÓN DE INCONFORMIDADES Y ESCALAMIENTO A ODOO S.A.:
Si el CLIENTE tiene inconformidades con el servicio, deberá seguir el procedimiento de escalamiento interno establecido en la Sección 9.4 antes de comunicarse con Odoo S.A. en relación con controversias sobre el servicio de EL PROVEEDOR. Este procedimiento existe para garantizar una resolución justa y oportuna, no para limitar los derechos legítimos del CLIENTE.
El CLIENTE podrá contactar directamente a Odoo S.A. sin agotar dicho procedimiento únicamente cuando exista riesgo inminente de daño, fuerza mayor que impida la comunicación con EL PROVEEDOR, o cuando la consulta sea sobre licencias, facturación o políticas propias de Odoo S.A.
Cuando el CLIENTE requiera escalar una controversia a Odoo S.A. después de agotar los niveles 1 y 2 del procedimiento de escalamiento, deberá notificar a EL PROVEEDOR con al menos 10 días hábiles de anticipación, fundamentando la queja en hechos comprobables y actuando de buena fe.
El CLIENTE conserva en todo momento su derecho a proporcionar retroalimentación veraz y constructiva, reportar problemas legítimos siguiendo el procedimiento establecido, y ejercer sus derechos ante autoridades competentes.
PROTECCIÓN DE LA RELACIÓN COMERCIAL:
Durante la vigencia del contrato y por un año posterior a su terminación, el CLIENTE se abstendrá de divulgar información falsa o difamatoria sobre EL PROVEEDOR, interferir maliciosamente con la relación entre EL PROVEEDOR y Odoo S.A., o cuestionar la certificación de EL PROVEEDOR ante Odoo S.A. sin fundamento objetivo y sin haber seguido el procedimiento de escalamiento.
VIGENCIA DE LA CONFIDENCIALIDAD:
Las obligaciones de confidencialidad sobre información general del proyecto permanecen vigentes por cinco (5) años posteriores a la terminación del contrato. Los derechos de propiedad intelectual sobre el código y desarrollos de EL PROVEEDOR tienen aplicación a perpetuidad, conforme a lo establecido en la Sección 6.2.
Excepciones: No constituye violación de confidencialidad la divulgación requerida por ley, autoridad judicial o ente gubernamental; información que sea de dominio público previo a la relación contractual; información desarrollada de forma independiente; o información divulgada con autorización expresa por escrito de la parte titular.
6.5 LEY APLICABLE, JURISDICCIÓN Y ARBITRAJE
Este Contrato se regirá e interpretará de conformidad con las leyes de la República de Guatemala. Las partes acuerdan expresamente que toda disputa, controversia o reclamo que se derive o se relacione con la aplicación, interpretación y/o cumplimiento de este contrato, por cualquier causa, ya sea durante su vigencia o luego de su terminación, deberá resolverse mediante Arbitraje de Derecho.
Para el efecto, si ambas partes lo acuerdan, el arbitraje estará a cargo de un solo árbitro. Si no existiere acuerdo al respecto, el arbitraje estará a cargo de tres árbitros: uno nombrado por cada una de las partes, y el tercero nombrado por los dos árbitros anteriores. En caso de que los dos árbitros no llegaren a acuerdo en el nombramiento del tercero, cualquiera de las partes podrá solicitarlo al juez de primera instancia competente. Los honorarios del tribunal arbitral serán determinados de común acuerdo entre las partes. En todo caso existirá un secretario nombrado por el tribunal arbitral, sea este unipersonal o colegiado.
En lo no establecido en esta cláusula, el arbitraje será administrado por el tribunal arbitral conforme a las normas del Reglamento del Centro de Arbitraje y Conciliación de la Cámara de Comercio de Guatemala (CENAC), aplicables a partir de la audiencia de instalación del tribunal arbitral. El laudo arbitral tendrá carácter final, vinculante e inapelable para ambas partes.
7. GARANTÍAS Y LIMITACIONES DE RESPONSABILIDAD
7.1 GARANTÍA DE FUNCIONALIDAD
EL PROVEEDOR garantiza que:
• Los módulos de Odoo configurados funcionarán según las especificaciones aprobadas formalmente por el CLIENTE durante el proyecto
• Los desarrollos personalizados cumplirán con los requerimientos validados y aprobados por escrito por el CLIENTE
• Las integraciones funcionarán según el alcance definido en la Propuesta Comercial y probado durante los pilotos
PERÍODO DE GARANTÍA:
NOVENTA (90) DÍAS CALENDARIO posteriores a la fecha de Go Live (puesta en producción del sistema).
LA GARANTÍA CUBRE:
• Corrección de errores de programación en desarrollos personalizados que impidan su funcionamiento según lo aprobado
• Ajustes a configuraciones que no operen según lo validado en los pilotos de prueba
• Resolución de problemas de integración dentro del alcance original que se manifiesten en producción
• Errores de cálculo o procesamiento en reportes personalizados desarrollados por EL PROVEEDOR
• Corrección de bugs en desarrollos personalizados que provoquen comportamientos inesperados del sistema
• Ajustes a flujos de trabajo configurados que no operen según lo aprobado
• Corrección de problemas de permisos o accesos configurados incorrectamente por EL PROVEEDOR
PROCEDIMIENTO PARA HACER VÁLIDA LA GARANTÍA:
• El CLIENTE reporta el problema por escrito a ventas@irodetech.com
• EL PROVEEDOR analiza si el problema está cubierto por garantía (máximo 2 días hábiles)
• Si está cubierto, EL PROVEEDOR corrige el problema sin costo adicional
• El tiempo de corrección depende de la criticidad según SLA (crítico: 5 días hábiles máximo; no crítico: 10 días hábiles máximo)
7.2 EXCLUSIONES DE GARANTÍA - QUÉ NO CUBRE LA GARANTÍA
La garantía NO cubre bajo ninguna circunstancia:
PROBLEMAS CAUSADOS POR EL CLIENTE O TERCEROS:
• Modificaciones, personalizaciones o desarrollos realizados por el CLIENTE o terceros NO autorizados expresamente por EL PROVEEDOR
• Instalación de módulos adicionales de Odoo no autorizados por EL PROVEEDOR
• Uso inadecuado del sistema contrario a las capacitaciones impartidas o mejores prácticas
• Eliminación o modificación de datos críticos del sistema por usuarios del CLIENTE
• Cambios en la configuración del sistema realizados por usuarios sin conocimiento técnico adecuado o sin autorización
• Desactivación de reglas de validación o controles implementados por EL PROVEEDOR
• Cambios en parámetros de sistema, permisos de usuario o configuraciones de seguridad realizados por el CLIENTE
PROBLEMAS DE INFRAESTRUCTURA Y EXTERNOS:
• Fallas de internet, energía eléctrica o hardware del CLIENTE
• Incompatibilidades con navegadores obsoletos o no soportados oficialmente por Odoo
• Problemas de rendimiento causados por limitaciones de conectividad del CLIENTE
• Fallas en equipos de código de barras, impresoras, scanners u otro hardware del CLIENTE
• Problemas causados por software de terceros instalado en las computadoras del CLIENTE (antivirus, firewalls, VPNs configuradas inadecuadamente)
CAMBIOS EXTERNOS AL PROYECTO:
• Actualizaciones de versión de Odoo realizadas por el CLIENTE sin autorización de EL PROVEEDOR
• Cambios en legislación fiscal, laboral o comercial guatemalteca posteriores a la firma del contrato que requieran ajustes al sistema
• Cambios en APIs o servicios de terceros integrados (Google, SAT, bancos, transportistas) que afecten las integraciones
• Nuevos requerimientos operativos del CLIENTE surgidos después del Go Live
• Cambios en procesos de negocio del CLIENTE que requieran reconfiguraciones
MÓDULOS ESTÁNDAR DE ODOO:
• Bugs o errores en módulos estándar de Odoo S.A. no personalizados (estos deben reportarse directamente a Odoo S.A.)
• Limitaciones funcionales inherentes a la plataforma Odoo Enterprise
• Problemas de rendimiento en los servidores de Odoo S.A.
• Cambios en funcionalidad estándar de Odoo implementados por Odoo S.A. en actualizaciones
SEGURIDAD Y ACCESOS NO AUTORIZADOS:
• Problemas derivados de ataques cibernéticos, malware, ransomware, phishing o acceso no autorizado al sistema del CLIENTE
• Pérdida de datos por cualquier causa
• Uso compartido de credenciales entre múltiples usuarios
• Problemas de seguridad causados por mala gestión de credenciales por parte del CLIENTE
DATOS Y CONTENIDO:
• Calidad, exactitud o completitud de los datos ingresados por el CLIENTE
• Problemas derivados de duplicidad de datos ingresados por usuarios del CLIENTE
• Inconsistencias en información histórica migrada de sistemas anteriores
• Errores en cálculos causados por parámetros o datos base incorrectos proporcionados por el CLIENTE
CAPACITACIÓN Y USO:
• Falta de adopción del sistema por parte de usuarios del CLIENTE
• Resistencia al cambio de los usuarios del CLIENTE
• Necesidad de capacitaciones adicionales por alta rotación de personal del CLIENTE
• Dudas operativas sobre uso del sistema fuera del período de garantía
7.3 GARANTÍA EN MÓDULOS ESTÁNDAR DE ODOO
Los módulos estándar de Odoo Enterprise (no personalizados) están respaldados directamente por Odoo S.A. (el fabricante del software), no por EL PROVEEDOR.
Si el CLIENTE identifica problemas en módulos estándar:
• EL PROVEEDOR puede asistir en la identificación y reporte del problema a Odoo S.A.
• La resolución depende de los tiempos y políticas de Odoo S.A.
• EL PROVEEDOR no garantiza tiempos de respuesta o resolución de Odoo S.A.
• Odoo S.A. puede determinar que un comportamiento es "según diseño" y no un bug
7.4 PÉRDIDA Y RESTAURACIÓN DE GARANTÍA
CAUSALES DE PÉRDIDA DE GARANTÍA:
La garantía se PIERDE si:
• El CLIENTE o terceros NO autorizados por escrito por EL PROVEEDOR realizan modificaciones al código, configuraciones o base de datos
• El CLIENTE instala módulos de terceros (Odoo App Store u otras fuentes) sin autorización escrita de EL PROVEEDOR
• El CLIENTE actualiza la versión de Odoo sin coordinación y autorización escrita de EL PROVEEDOR
• El CLIENTE permite acceso de otros proveedores de servicios a la base de datos o código fuente sin autorización escrita de EL PROVEEDOR
• El CLIENTE está en mora de pagos por más de 15 días calendario
RESTAURACIÓN DE GARANTÍA:
La garantía NO es permanentemente irrecuperable. Puede restablecerse si:
OPCIÓN 1 - Remediación Autorizada:
• EL PROVEEDOR autoriza por escrito las modificaciones realizadas después de revisarlas
• EL PROVEEDOR valida que las modificaciones no afectaron la estabilidad ni funcionalidad del sistema
• El CLIENTE paga una tarifa de auditoría y validación (tarifa a cotizar según alcance de modificaciones)
OPCIÓN 2 - Auditoría y Corrección:
• El CLIENTE contrata a EL PROVEEDOR para realizar una auditoría completa del sistema
• Se identifican y documentan todas las modificaciones no autorizadas
• El CLIENTE contrata la remediación (corrección, reversa o re-implementación) de las modificaciones
• EL PROVEEDOR valida por escrito que el sistema está en estado comparable al original
• La garantía se restablece por el tiempo restante del período original (máximo 90 días desde Go Live original)
FACTORES A EVALUAR PARA RESTAURACIÓN:
EL PROVEEDOR evaluará los siguientes factores para determinar si es viable y bajo qué condiciones restaurar la garantía:
• Gravedad y extensión de las modificaciones no autorizadas
• Impacto en la estabilidad del sistema
• Posibilidad técnica de revertir o corregir las modificaciones
• Tiempo transcurrido desde las modificaciones
• Complejidad de la auditoría y remediación requerida
• Cooperación del CLIENTE para proporcionar información completa de los cambios
• Costo/beneficio para el CLIENTE de restaurar vs. contratar soporte regular
La decisión de restaurar la garantía queda a discreción razonable de EL PROVEEDOR y no es una obligación automática. Sin embargo, EL PROVEEDOR actuará de buena fe para facilitar la restauración cuando sea técnica y comercialmente viable.
7.5 LIMITACIÓN DE RESPONSABILIDAD
LÍMITE ECONÓMICO DE RESPONSABILIDAD:
La responsabilidad total de EL PROVEEDOR por daños DIRECTOS derivados del proyecto NO EXCEDERÁ EN NINGÚN CASO el monto total pagado por el CLIENTE en el Contrato de Servicios de implementación.
EXCLUSIÓN DE RESPONSABILIDAD POR NEGLIGENCIA GRAVE O DOLO:
Esta limitación de responsabilidad NO APLICA en casos de:
• Dolo (intención deliberada de causar daño)
• Negligencia grave comprobada de EL PROVEEDOR
En tales casos, la responsabilidad de EL PROVEEDOR se determinará según el daño real comprobado, sin aplicar el límite del monto del contrato.
EL PROVEEDOR NO SERÁ RESPONSABLE BAJO NINGUNA CIRCUNSTANCIA POR:
• Lucro cesante, pérdida de beneficios esperados o pérdida de ingresos del CLIENTE (salvo en caso de dolo)
• Pérdida de datos o información (más allá de asistir en restauración desde respaldos disponibles)
• Interrupción de negocios o procesos operativos del CLIENTE
• Daños a la reputación o imagen comercial del CLIENTE
• Daños indirectos, consecuentes o punitivos de cualquier naturaleza
• Reclamos de terceros (clientes, proveedores, autoridades) hacia el CLIENTE
• Multas, sanciones o penalizaciones gubernamentales al CLIENTE
• Pérdida de oportunidades de negocio
• Costos de implementación de soluciones alternativas
SEGUROS RECOMENDADOS:
EL PROVEEDOR mantiene (o se compromete a mantener) los siguientes seguros profesionales:
• Seguro de Responsabilidad Profesional (Errors & Omissions - E&O)
• Ciber-seguro para protección contra incidentes de seguridad
El CLIENTE puede solicitar certificados de cobertura de seguros antes de la firma del contrato.
CAUSAS DE EXONERACIÓN TOTAL DE RESPONSABILIDAD:
EL PROVEEDOR queda completamente exonerado de cualquier responsabilidad cuando los daños o problemas sean causados por:
• Fuerza mayor o caso fortuito (desastres naturales, pandemias, guerras, disturbios civiles, cortes masivos de energía o internet, actos de autoridad, etc.)
• Ataques cibernéticos, malware, ransomware, phishing dirigidos al CLIENTE o a infraestructura externa
• Acciones u omisiones del CLIENTE o de sus empleados, contratistas o representantes
• Incumplimiento del CLIENTE de sus obligaciones establecidas en estos Términos y Condiciones
• Modificaciones no autorizadas al sistema realizadas por el CLIENTE o terceros
• Fallas o cambios en servicios de terceros (Odoo S.A., Google, SAT, bancos, etc.)
7. GARANTÍAS Y LIMITACIONES DE RESPONSABILIDAD
8.1 CAUSALES DE TERMINACIÓN POR PARTE DE EL PROVEEDOR
EL PROVEEDOR puede dar por terminado unilateralmente el Contrato de Servicios, con efecto inmediato y sin responsabilidad alguna, en los siguientes casos:
MORA EN PAGOS:
• Mora superior a 30 días calendario en cualquier pago del proyecto
• Falta de pago del primer pago dentro de los 10 días hábiles posteriores a la firma del contrato
INCUMPLIMIENTOS REITERADOS:
• Acumulación de 5 o más retrasos significativos (superiores a 5 días hábiles cada uno) en entrega de información requerida
• Falta de disponibilidad de personal clave en 5 o más ocasiones sin causa justificada
• Incumplimiento reiterado de compromisos de aprobación (3 o más aprobaciones con más de 10 días de retraso)
CONDUCTAS INAPROPIADAS:
• Conducta abusiva, amenazante, discriminatoria o irrespetuosa hacia el personal de EL PROVEEDOR
• Acoso de cualquier tipo hacia miembros del equipo de EL PROVEEDOR
• Solicitudes que violen leyes, regulaciones o principios éticos
VIOLACIONES DE SEGURIDAD, CONFIDENCIALIDAD O RELACIÓN CON ODOO:
• Violación documentada de cláusulas de confidencialidad
• Uso no autorizado de información propietaria de EL PROVEEDOR
• Compartir credenciales o accesos del equipo de EL PROVEEDOR con terceros no autorizados
• Divulgación de información negativa o difamatoria sobre EL PROVEEDOR a Odoo S.A., empleados del CLIENTE u otros
• Acciones que afecten negativamente la certificación o relación de EL PROVEEDOR con Odoo S.A.
CONSECUENCIAS DE TERMINACIÓN POR INCUMPLIMIENTO DEL CLIENTE:
Cuando EL PROVEEDOR termina el contrato por causales imputables al CLIENTE:
• NO hay reembolso de ningún pago ya realizado
• El CLIENTE debe pagar INMEDIATAMENTE el 100% del trabajo completado hasta la fecha de terminación (si es mayor a lo ya pagado)
• EL PROVEEDOR NO entrega el código fuente bajo ninguna circunstancia
• EL PROVEEDOR entrega únicamente acceso al sistema en el estado en que se encuentre, SIN GARANTÍA de funcionalidad total
• El CLIENTE no puede reclamar daños y perjuicios
• Se inician acciones legales de cobro si hubiera saldos pendientes
8.2 CAUSALES DE TERMINACIÓN POR PARTE DEL CLIENTE
El CLIENTE puede terminar el Contrato de Servicios en los siguientes casos:
INCUMPLIMIENTO GRAVE DE EL PROVEEDOR:
• Retraso superior a 60 días calendario imputable EXCLUSIVAMENTE a EL PROVEEDOR (no causado por falta de información o disponibilidad del CLIENTE)
• Incumplimiento reiterado y documentado de compromisos establecidos en LA PLANIFICACIÓN del proyecto
• Violación documentada de cláusulas de confidencialidad por parte de EL PROVEEDOR
POR CONVENIENCIA:
• El CLIENTE puede cancelar el proyecto en cualquier momento por decisiones estratégicas propias
• Debe notificar por escrito con TREINTA (30) días calendario de anticipación
• Debe estar al corriente en todos los pagos al momento de la notificación
ESQUEMA DE LIQUIDACIÓN SEGÚN FASE DEL PROYECTO:
Si la terminación ocurre durante FASE DE LEVANTAMIENTO (Mes 1):
• El CLIENTE recupera el 30% del total pagado hasta ese momento
• El CLIENTE debe pagar cualquier trabajo adicional realizado más allá del alcance original (si aplica)
• Se entrega documentación de levantamiento completada hasta la fecha
• NO se entrega código fuente
Si la terminación ocurre durante FASE DE CONFIGURACIÓN E INTEGRACIÓN (Meses 2-3):
• El CLIENTE recupera el 15% del total pagado hasta ese momento
• Se entrega el sistema en el estado en que se encuentre (puede estar incompleto)
• NO hay garantía de funcionalidad
• NO se entrega código fuente
Si la terminación ocurre durante FASE DE PILOTOS Y CAPACITACIÓN (Meses 4-5):
• NO hay reembolso (0%)
• El CLIENTE debe completar el pago de la fase en curso si aún no lo ha realizado
• Se entrega el sistema en el estado en que se encuentre
• NO se entrega código fuente
Si la terminación ocurre durante o después de GO LIVE (Mes 6+):
• NO hay reembolso (0%)
• El CLIENTE debe pagar el 100% del proyecto si no lo ha hecho
• Se procede con cierre administrativo del proyecto
• NO se entrega código fuente
IMPORTANTE: Los porcentajes de reembolso aplicarán únicamente si la terminación es por CONVENIENCIA del CLIENTE y el CLIENTE está al corriente en todos sus pagos y obligaciones. Si la terminación es por incumplimiento de EL PROVEEDOR, se negociarán condiciones específicas según la gravedad del incumplimiento.
En TODOS los casos de terminación anticipada, EL PROVEEDOR NO entregará el código fuente de los desarrollos personalizados.
8.3 PROCEDIMIENTO DE CIERRE DEL PROYECTO
Independientemente de la causa de terminación (finalización normal o terminación anticipada), se seguirá el siguiente procedimiento de cierre:
PASO 1 - NOTIFICACIÓN FORMAL:
• La parte que termina el contrato envía notificación formal por escrito a la contraparte
• Debe indicar claramente la causal de terminación
• Debe proponer fecha de cierre efectivo (respetando períodos de aviso cuando aplique)
PASO 2 - LIQUIDACIÓN ECONÓMICA:
• Se calcula el saldo pendiente de pago en ambas direcciones (si aplica)
• Se calculan reembolsos si corresponden según esquema de liquidación
• Se calcula cualquier interés moratorio pendiente
• Ambas partes acuerdan la forma y plazos de liquidación
PASO 3 - TRANSFERENCIA DE ENTREGABLES:
• EL PROVEEDOR entrega documentación técnica y funcional generada (NO incluye código fuente salvo terminación normal con proyecto 100% pagado)
• EL PROVEEDOR entrega manuales de usuario y capacitaciones grabadas (si existen)
• Se documenta el estado del sistema al momento del cierre
PASO 4 - TRANSFERENCIA DE ACCESOS:
• Se transfieren accesos administrativos del sistema al CLIENTE (a persona designada)
• Se entregan credenciales de servicios integrados que estén a nombre de EL PROVEEDOR (si aplica)
• Se desactivan accesos del equipo de EL PROVEEDOR al sistema del CLIENTE
• El CLIENTE firma conformidad de recepción de accesos
PASO 5 - ELIMINACIÓN SEGURA DE INFORMACIÓN:
• EL PROVEEDOR elimina de forma segura toda información confidencial del CLIENTE que esté en posesión de su equipo
• Se eliminan respaldos locales, documentación con datos sensibles, credenciales, etc.
• Se confirma por escrito la eliminación
PASO 6 - ACTA DE CIERRE:
• Se firma un Acta de Cierre de Proyecto entre ambas partes
• Debe incluir: estado final del proyecto, pagos liquidados, compromisos pendientes (si los hay), liberación de responsabilidades mutuas
• Ambas partes conservan una copia firmada
PASO 7 - CIERRE ADMINISTRATIVO:
• Se archivan todos los documentos del proyecto (contratos, addendums, actas, cotizaciones, aprobaciones)
• Se emiten facturas finales si corresponde
• Se actualiza el status del proyecto en sistemas internos de ambas partes.