Licitación ID: 869591-1-LR24
Desarrollo Soluciones Plataforma Mercado Público
Responsable de esta licitación: DIRECCION DE COMPRAS Y CONTRATACION PUBLICA, Calidad del Gasto en las Compras Públicas
Reclamos recibidos por incumplir plazo de pago: 13
Este número indica los reclamos recibidos por esta institución desde los últimos 12 meses hasta el día de ayer. Recuerde interpretar esta información considerando la cantidad de licitaciones y órdenes de compra que esta institución genera en el Mercado Público.
Dejar un reclamo sobre esta licitación Dejar un reclamo sobre esta licitación
Productos o servicios
1
Desarrolladores de software 1 Unidad
Cod: 80111711
Linea de Servicio N°1  

2
Desarrolladores de software 1 Unidad
Cod: 80111711
Linea de Servicio N°2  

1. Características de la licitación
Nombre de la licitación:
Desarrollo Soluciones Plataforma Mercado Público
Estado:
Adjudicada
Descripción:
La Dirección de Compras y Contratación Pública en adelante “DCCP” o “Dirección Chilecompra”, indistintamente requiere la contratación de servicios para el desarrollo de las siguientes soluciones para la plataforma Mercado Público: la creación de nuevos organismos compradores en Mercado Público, la ficha del organismo comprador, la información de compradores en los procesos de compra, la integración con información del Tribunal de Contratación Pública, la actualización de trato directo, la actualización de compra ágil, la incorporación del mecanismo de compra de diálogos competitivos y la incorporación del mecanismo de compra de contratos para la innovación.
Tipo de licitación:
Pública-Licitación Pública igual o superior a 5.000 UTM (LR)
Tipo de convocatoria:
ABIERTO
Moneda:
Peso Chileno
Etapas del proceso de apertura:
Una Etapa
Toma de razón por Contraloría:
No requiere Toma de Razón por Contraloría
Publicidad de ofertas técnicas:
Las ofertas técnicas serán de público conocimiento una vez realizada la apertura técnica de las ofertas.
2. Organismo demandante
Razón social:
DIRECCION DE COMPRAS Y CONTRATACION PUBLICA
Unidad de compra:
Calidad del Gasto en las Compras Públicas
R.U.T.:
60.808.000-7
Dirección:
Monjitas 392 piso 8
Comuna:
Santiago Centro
Región en que se genera la licitación:
Región Metropolitana de Santiago
3. Etapas y plazos
Fecha de cierre de recepción de la oferta: 12-03-2024 15:00:00
Fecha de Publicación: 07-02-2024 10:54:00
Fecha inicio de preguntas: 07-02-2024 11:00:00
Fecha final de preguntas: 21-02-2024 18:00:00
Fecha de publicación de respuestas: 28-02-2024 18:00:00
Fecha de acto de apertura técnica: 12-03-2024 15:15:00
Fecha de acto de apertura económica (referencial): 12-03-2024 15:15:00
Fecha de Adjudicación: 10-04-2024 19:19:02
Fecha de entrega en soporte fisico No hay información
Fecha estimada de firma de contrato No hay información
Tiempo estimado de evaluación de ofertas No hay información
4. Antecedentes para incluir en la oferta
Adicionalmente, todos los proveedores para ofertar en esta licitación, deberán obligatoriamente confirmar y firmar electrónicamente la Declaración Jurada de Requisitos para Ofertar.
Documentos Administrativos
1.- Anexo N°1: Formulario Datos del Oferente
2.- Anexo N°2: Declaración jurada de independencia de la oferta.
3.- Anexo N°3: Declaración Jurada para autorización de notificaciones
4.- Anexo N°4: Declaración para Uniones Temporales de Proveedores
Documentos Técnicos
1.- Anexo N°5: Oferta técnica
 
2.- Anexo N°5.1: Formato tipo “Carta de Referencia Experiencia Oferente”
 
3.- Anexo N°6: Programas de integridad
 
Documentos Económicos
1.- Anexo N°7. Oferta económica.
5. Requisitos para contratar al proveedor adjudicado
Persona natural
Encontrarse hábil en el Registro de Proveedores, registro que verificará NO haber incurrido en las siguientes causales de inhabilidad:

1 .- Haber sido condenado por cualquiera de los delitos de cohecho contemplados en el título V del Libro Segundo del Código Penal.
 
2 .- Registrar una o más deudas tributarias por un monto total superior a 500 UTM por más de un año, o superior a 200 UTM e inferior a 500 UTM por un período superior a 2 años, sin que exista un convenio de pago vigente. En caso de encontrarse pendiente juicio sobre la efectividad de la deuda, esta inhabilidad regirá una vez que se encuentre firme o ejecutoriada la respectiva resolución.
 
3 .- Registrar deudas previsionales o de salud por más de 12 meses por sus trabajadores dependientes, lo que se acreditará mediante certificado de la autoridad competente.
 
4 .- La presentación al Registro Nacional de Proveedores de uno o más documentos falsos, declarado así por sentencia judicial ejecutoriada.
 
5 .- Haber sido declarado en quiebra por resolución judicial ejecutoriada.
 
6 .- Haber sido eliminado o encontrarse suspendido del Registro Nacional de Proveedores por resolución fundada de la Dirección de Compras.
 
7 .- Haber sido condenado por prácticas antisindicales o infracción a los derechos fundamentales del trabajador.
 
8 .- Registrar condenas asociadas a responsabilidad penal jurídica (incumplimiento artículo 10, Ley 20.393).
 
Documentos persona natural
- Fotocopia Legalizada de Cédula de Identidad
- Declaración jurada acreditando que no se encuentra afecto al art. 4 inciso 6 de la ley 19.886, en el cual se establece que "ningún órgano de la administración del Estado podrá suscribir contratos administrativos de provisión de bienes y servicios con los funcionarios directivos del mismo órgano o empresa, ni con personas unidas a ellos por los vínculos de parentesco."
Persona jurídica
Encontrarse hábil en el Registro de Proveedores, registro que verificará NO haber incurrido en las siguientes causales de inhabilidad:

1 .- Haber sido condenado por cualquiera de los delitos de cohecho contemplados en el título V del Libro Segundo del Código Penal.

2 .- Registrar una o más deudas tributarias por un monto total superior a 500 UTM por más de un año, o superior a 200 UTM e inferior a 500 UTM por un período superior a 2 años, sin que exista un convenio de pago vigente. En caso de encontrarse pendiente juicio sobre la efectividad de la deuda, esta inhabilidad regirá una vez que se encuentre firme o ejecutoriada la respectiva resolución.

3 .- Registrar deudas previsionales o de salud por más de 12 meses por sus trabajadores dependientes, lo que se acreditará mediante certificado de la autoridad competente.

4 .- La presentación al Registro Nacional de Proveedores de uno o más documentos falsos, declarado así por sentencia judicial ejecutoriada.

5 .- Haber sido declarado en quiebra por resolución judicial ejecutoriada.

6 .- Haber sido eliminado o encontrarse suspendido del Registro Nacional de Proveedores por resolución fundada de la Dirección de Compras.

7 .- Haber sido condenado por prácticas antisindicales o infracción a los derechos fundamentales del trabajador.

8 .- Registrar condenas asociadas a responsabilidad penal jurídica (incumplimiento artículo 10, Ley 20.393).

Documentos persona jurídica
- Fotocopia Legalizada del Rut de la Empresa
- Declaración jurada acreditando que no se encuentra afecto al art. 4 inciso 6 de la ley 19.886, en el cual se establece que "ningún órgano de la administración del Estado podrá suscribir contratos administrativos de provisión de bienes y servicios con los funcionarios directivos del mismo órgano o empresa, ni con personas unidas a ellos por los vínculos de parentesco."
- Certificado de Vigencia de la Sociedad
- (1) Certificado de Boletín de Informes Comerciales
- (1) Certificado de Quiebras/Convenio Judicial
6. Criterios de evaluación
ÍtemObservacionesPonderación
1 Técnico Según bases de licitación adjuntas 78%
2 Precio Según bases de licitación adjuntas 20%
3 Cumplimiento de requisitos formales Según bases de licitación adjuntas 2%

7. Montos y duración del contrato
Estimación en base a: Presupuesto Disponible
Fuente de financiamiento: No hay información
Monto Total Estimado: 963800000
Justificación del monto estimado El presupuesto máximo disponible para esta contratación se encuentra descrito en las bases de licitación adjuntas, y debe incluir todos los impuestos que procedan.
Contrato con Renovación: NO
Observaciones el caso que la oferta supere el monto disponible, podrá ser declarada inadmisible
Tiempo del Contrato 12 Meses
Plazos de pago: 30 días contra la recepción conforme de la factura
Opciones de pago: Transferencia Electrónica
Nombre de responsable de pago: Juan Carlos Piñones
e-mail de responsable de pago: juan.pinones@chilecompra.cl
Nombre de responsable de contrato: Bruno Perez
e-mail de responsable de contrato: bruno.perez@chilecompra.cl
Teléfono de responsable del contrato: 56-2-2904419-
Prohibición de subcontratación: No permite subcontratación
El adjudicatario no podrá ceder ni transferir en forma alguna, total ni parcialmente, los derechos y obligaciones que nacen del desarrollo de esta licitación y, en especial, los establecidos en el respectivo contrato que se celebre con la DCCP.
8. Garantías requeridas
    Garantías de Seriedad de Ofertas
Beneficiario: Dirección de Compras y Contratación Pública, RUT N° 60.808.000-7.
Fecha de vencimiento: 06-06-2024
Monto: 5000000 Peso Chileno
Descripción: Cualquier instrumento que asegure el cobro de la garantía de manera rápida y efectiva, pagadera a la vista y con el carácter de irrevocable. Ejemplos de ellos son: Boleta de garantía, certificado de fianza a la vista, póliza de seguro de garantía, vale vista, entre otros, todos los cuales deberán ser pagaderos a la vista y tener el carácter de irrevocables. No se aceptan cheques como instrumento de garantía. Esta garantía podrá otorgarse mediante uno o varios instrumentos financieros de la misma naturaleza que en conjunto representen el monto a caucionar.
Glosa: "Para garantizar seriedad de la oferta de la propuesta pública de la contratación de servicios de desarrollo de soluciones para la plataforma Mercado Público”
Forma y oportunidad de restitución: En el caso del proveedor adjudicado, la restitución de esta garantía será realizada una vez que haya entregado la Garantía de Fiel Cumplimiento de Contrato. La devolución de las garantías de seriedad a aquellos oferentes cuyas ofertas hayan sido declaradas inadmisibles se efectuará dentro del plazo de 10 días hábiles contados desde la notificación de la resolución que dé cuenta de la inadmisibilidad. En este caso, las garantías podrán ser retiradas el día siguiente a la publicación de la resolución que dé cuenta de la inadmisibilidad en el Sistema de Información, en las dependencias de la Dirección. La devolución de las garantías de seriedad a aquellos oferentes cuyas ofertas hayan sido declaradas admisibles, pero no hayan sido adjudicadas, se efectuará a partir de la fecha de notificación de la dictación de la resolución que apruebe el contrato con el proveedor adjudicado. En este último caso, las garantías podrán ser retiradas en las dependencias de la Dirección.
    Garantía fiel de Cumplimiento de Contrato
Beneficiario: Dirección de Compras y Contratación Pública, RUT N° 60.808.000-7.
Fecha de vencimiento: 21-07-2025
Monto: 5 %
Descripción: Cualquier tipo de instrumento de garantía que asegure el cobro de este, de manera rápida y efectiva, pagadera a la vista y con el carácter de irrevocable. Ejemplos de ellos son: Boleta de garantía, certificado de fianza a la vista, vale vista, entre otros, todos los cuales deberán ser pagaderos a la vista y tener el carácter de irrevocables. No se aceptan cheques como instrumento de garantía.
Glosa: “Para garantizar el fiel y oportuno cumplimiento de la propuesta púbica de la contratación de servicios de desarrollo de soluciones para la plataforma Mercado Público y el pago de saldos insolutos de remuneraciones o cotizaciones de seguridad social con sus actuales trabajadores o con trabajadores contratados en los últimos dos años”.
Forma y oportunidad de restitución: ver documento adjunto
9. Requerimientos técnicos y otras cláusulas
Cláusula de Readjudicación
Si el respectivo adjudicatario se desistiere de su oferta, de firmar el contrato, no se inscribiese en el Registro Proveedores de Mercado Público, o no cumpliere los demás requisitos establecidos en las bases para la suscripción del contrato, en los plazos que se establecen en las presentes Bases, la DCCP podrá, junto con dejar sin efecto la adjudicación original, readjudicar la licitación al oferente que, de acuerdo al resultado de la evaluación, le siga en puntaje y cumpla los requisitos establecidos en las presentes bases, y así sucesivamente, dentro del plazo de 30 días corridos contados desde la publicación de la adjudicación original, a menos que, de acuerdo a los intereses del servicio, se estime conveniente declarar desierta la licitación.
Bases de licitación
?

BASES DE LICITACIÓN PÚBLICA PARA LA CONTRATACIÓN DEL SERVICIO DE “DESARROLLO DE SOLUCIONES PARA LA PLATAFORMA MERCADO PÚBLICO”

  1. Antecedentes generales de la licitación

Nombre Adquisición

Contratación de servicios de desarrollo de soluciones para la plataforma Mercado Público.

Descripción

La Dirección de Compras y Contratación Pública (en adelante “DCCP” o “Dirección Chilecompra”, indistintamente) requiere la contratación de servicios para el desarrollo de las siguientes soluciones para la plataforma Mercado Público: la creación de nuevos organismos compradores en Mercado Público, la ficha del organismo comprador, la información de compradores en los procesos de compra, la integración con información del Tribunal de Contratación Pública, la actualización de trato directo, la actualización de compra ágil, la incorporación del mecanismo de compra de diálogos competitivos y la incorporación del mecanismo de compra de contratos para la innovación.

Tipo de Licitación

Licitación Pública mayor a 5.000 UTM (LR).

Tipo de Convocatoria

Abierta.

Moneda o Unidad reajustable

Pesos Chilenos (CLP)

Presupuesto disponible c

$963.800.000 pesos

Etapas del Proceso de Apertura

Una etapa, quedando disponible en el acto de apertura, tanto la oferta técnica y económica, así como los antecedentes administrativos, para su evaluación.

Opciones de pago

Transferencia electrónica

Publicidad de las Ofertas Técnicas

Toma de razón por Contraloría

No está afecta al trámite de toma de razón por parte de la Contraloría General de la República.

  1. Organismo licitante

Razón Social

Dirección de Compras y Contratación Pública

Unidad de Compra

Departamento de Arquitectura de Software y Desarrollo de Software

R.U.T.

60.808.000-7

Dirección

Monjitas N°392, Piso 8

Comuna

Santiago

Región en que se genera la Adquisición

Región Metropolitana

  1. Etapas y Plazos

En general, todos los plazos de días establecidos en las presentes Bases serán de días hábiles administrativos, entendiéndose por estos entre lunes y viernes, ambos inclusive, con excepción de los festivos, salvo aquellos que expresamente se señale que serán de días corridos.

Fecha inicio de preguntas

A partir del mismo día de la fecha de publicación del llamado en el portal https://www.mercadopublico.cl

Video informativo

Dentro del plazo máximo de 5 días contados desde la publicación del respectivo llamado en el portal www.mercadopublico.cl se publicará un video informativo en el ID de la licitación. En dicho video se expondrá información ya contenida en las presentas bases.

Fecha final de preguntas

10 días posteriores a la fecha de publicación del llamado en el portal https://www.mercadopublico.cl, a las 18:00 horas.

Plazo para publicar respuestas a las consultas

Dentro de 15 días posteriores a la fecha de publicación del llamado en el portal https://www.mercadopublico.cl, a las 18:00 horas.

En caso de que el número de preguntas que se realicen sea superior a 50, la DCCP podrá aumentar el plazo de publicación de respuestas hasta por 5 días adicionales.

En cualquier caso, la nueva fecha de publicación de respuestas será informada en el portal https://www.mercadopublico.cl en el ID de la licitación, no requiriéndose un acto administrativo para tal efecto.

Fecha de Cierre para presentar Ofertas

30 días corridos posteriores a la fecha de publicación del llamado en el portal https://www.mercadopublico.cl, a las 15:00 horas.

 

Con el objeto de aumentar la participación de oferentes o en el caso de ocurrir la hipótesis planteada en el acápite “Fecha de Publicación de Respuestas”, la Dirección ChileCompra podrá extender este plazo, mediante acto administrativo debidamente tramitado.

Fecha de Apertura de ofertas

El mismo día en que se produzca el cierre de recepción de ofertas, a las 15:15 horas en el portal www.mercadopublico.cl.

Fecha de Adjudicación

Dentro de 20 días posteriores a la fecha de cierre de recepción de ofertas en el portal https://www.mercadopublico.cl, a las 19:00 horas.

Cuando la adjudicación no se realice dentro del plazo señalado, la DCCP deberá informar en el Sistema de Información las razones que justifican el incumplimiento del plazo para adjudicar e indicar un nuevo plazo para la adjudicación, de conformidad con lo dispuesto en el artículo 41, inciso segundo, del reglamento de la Ley N°19.886.

Plazo para Firma de Contrato

Dentro de los 10 días posteriores a la fecha de notificación de la resolución de adjudicación totalmente tramitada.

  1. Instancia de preguntas y respuestas y modificaciones a las bases

4.1            Foro de preguntas

Los interesados en participar en la presente licitación podrán formular consultas y solicitar aclaraciones dentro de los plazos señalados en la cláusula N°3 de estas Bases. Las preguntas deberán formularse a través de https://www.mercadopublico.cl. La Dirección de Compras y Contratación Pública (DCCP) pondrá las preguntas y sus respuestas en conocimiento de todos los interesados, a través de su publicación en https://www.mercadopublico.cl, sin indicar el autor de las preguntas, dentro del plazo señalado en la referida cláusula N°3.

Las referidas respuestas del foro se entenderán formar parte integral de las presentes bases de licitación.

De conformidad a lo señalado en las “Políticas y Condiciones de Uso” del Sistema de Información, acápite “Foro de preguntas y respuestas”, el foro en el Sistema de Información tiene por única y exclusiva finalidad el motivar aclaraciones respecto al proceso licitatorio en particular, en virtud de lo dispuesto en el artículo 27 del reglamento de la Ley N°19.886, de manera tal que queda prohibido a los usuarios utilizar esta vía para otros fines, tales como proferir injurias en contra de la Entidad Licitante, en contra de otros proveedores, publicitar la venta de bienes y/o servicios, coordinar acuerdos entre oferentes, entre otros. En caso de que se realicen intervenciones en el foro de esta naturaleza, esto es, no atingentes al proceso licitatorio, la Dirección ChileCompra se abstendrá de responder aquel comentario y lo ocultará de la vista pública.

4.2            Modificaciones a las bases

La DCCP podrá modificar las presentes Bases y sus anexos, ya sea de oficio o en atención a una aclaración solicitada por alguno de los interesados, a través del foro de preguntas y respuestas, durante el proceso de la propuesta, hasta antes del vencimiento del plazo para presentar ofertas.

Las modificaciones que se lleven a cabo serán informadas a través del sitio web https://www.mercadopublico.cl. Estas modificaciones formarán parte integrante de las Bases. Las modificaciones de Bases estarán vigentes desde la total tramitación del acto administrativo que las apruebe.

Junto con aprobar la modificación, se establecerá un nuevo plazo prudencial para el cierre o recepción de las propuestas, a fin de que los potenciales oferentes puedan adecuar sus ofertas.

  1. Requisitos Mínimos para participar de la oferta

  1. No haber sido condenado por prácticas antisindicales, infracción a los derechos fundamentales del trabajador o por delitos concursales establecidos en el Código Penal dentro de los dos últimos años anteriores a la fecha de presentación de la oferta, de conformidad con lo dispuesto en el artículo 4° de la ley N° 19.886.

  1. No haber sido condenado por el Tribunal de Defensa de la Libre Competencia, dentro de los cinco años anteriores, contados desde que la sentencia definitiva quede ejecutoriada, con la prohibición de contratar a cualquier título con órganos de la administración, contemplada en el artículo 26, letra d), del Decreto con Fuerza de Ley N°1, de 2004, del Ministerio de Economía, Fomento y Reconstrucción, que fija el texto refundido, coordinado y sistematizado del decreto ley N° 211, de 1973.

  1. No haber sido condenado a la pena de prohibición de celebrar actos y contratos con organismos del Estado, por los delitos mencionados en la ley N°20.393.

  1. No haber sido condenado por los Tribunales de Justicia a la medida dispuesta en el artículo 33 de la ley N°21.595 de Delitos Económicos. En el caso de que el oferente sea una persona jurídica, ya sea que se trate de sociedades, fundaciones o corporaciones, esta no debe tener como socio, accionista, miembro o partícipe con poder para influir en la administración, a personas naturales que hubieren sido condenadas a la citada medida.

  1. No haber sido, durante el periodo de un año transcurrido con antelación a la presente declaración, funcionario directivo del organismo licitante y/o comprador, hasta el nivel de jefe de departamento o su equivalente, o funcionario que participe en procedimientos de contratación del organismo licitante y/o comprador, ni estar unido(a) a éstos o aquéllos por los vínculos descritos en la letra b) del artículo 54 de la ley N°18.575 (cónyuge, hijo, adoptado o pariente hasta el tercer grado de consanguinidad y segundo de afinidad inclusive).

  1. No integrar la nómina de personal del organismo licitante y/o comprador, en cualquier calidad jurídica, ni ser contratado a honorarios por el organismo licitante y/o comprador, ni estar unido(a) a éstos o aquéllos por lo vínculos descritos en el inciso primero del artículo 35 quáter de la ley N° 19.886 (cónyuge, convivientes civil o pariente hasta el segundo grado de consanguinidad o afinidad).

  1. No ser una sociedad de personas o empresa individual de responsabilidad limitada en la que una o más de las personas singularizadas en las letras e) y f) precedentes formen parte o sean beneficiarias finales.

  1. No ser una sociedad en comandita por acciones, sociedad por acciones o anónima cerrada en que una o más de las personas singularizadas en las letras e) y f) precedentes sean accionistas o beneficiarias finales.

  1. No ser una sociedad anónima abierta en que una o más de las personas singularizadas en las letras e) y f) precedentes sean dueñas de acciones que representen el 10% o más del capital o sean beneficiarias finales.

  1. No ser gerente, administrador, representante o director de cualquiera de las sociedades antedichas.

A fin de acreditar el cumplimiento de dichos requisitos, el oferente, ya sea una persona natural, persona jurídica o Unión Temporal de Proveedores, deberá efectuar dicha declaración de manera electrónica a través del formato de declaración denominado “Declaración jurada de requisitos para ofertar”, el que se encuentra disponible en el módulo de presentación de las ofertas del Sistema de Información www.mercadopublico.cl.

Sin perjuicio de lo anterior, la Dirección ChileCompra podrá verificar la veracidad de la información entregada en la declaración, en cualquier momento, a través de los medios oficiales disponibles. En caso de que el oferente corresponda a una UTP, se entenderá que quien ingresa la oferta a través del Sistema de Información está facultado por los demás integrantes para realizar tal declaración a favor de cada uno de ellos y, por lo tanto, la DCCP podrá realizar dicha verificación para cada integrante de ésta.

Las ofertas presentadas por una Unión Temporal de Proveedores (UTP) deberán contar con un apoderado. El apoderado de la UTP debe corresponder a un integrante de la misma, ya sea persona natural o jurídica. En el caso que el apoderado sea una persona jurídica, ésta deberá actuar a través de su representante legal.

En caso de que el oferente no dé cumplimiento a la exigencia señalada precedentemente, es decir, que no complete debidamente la declaración jurada online, se configurará un incumplimiento respecto de lo establecido en la presente cláusula, por lo que dicha oferta será declarada inadmisible, y no será parte del proceso de evaluación de ofertas, sin perjuicio de lo señalado en el artículo 40 del Reglamento de la Ley N°19.886.

Debe tenerse presente que faltar a la verdad respecto de lo informado en una declaración jurada puede traducirse en la comisión del delito de perjurio, en virtud del artículo 210 del Código Penal, que dispone que "el que ante la autoridad o sus agentes perjurare o diere falso testimonio en materia que no sea contenciosa, sufrirá las penas de presidio menor en sus grados mínimo a medio y multa de seis a diez unidades tributarias mensuales."

  1. Anexos e instrucciones para la presentación de ofertas

Presentar Ofertas por Sistema

Obligatorio:

Las propuestas deberán ser ingresadas al portal https://www.mercadopublico.cl, bajo el ID que identifica esta licitación en el plazo señalado en la cláusula N°3 de estas bases, contado desde la fecha de publicación de las presentes Bases de licitación en el referido Portal y con anterioridad a la fecha de cierre de recepción de las ofertas.

Anexos Administrativos

  • Declaración jurada online: Los oferentes deberán firmar la “Declaración de ausencia de conflicto de interés e inhabilidades por condenas”, la cual se genera en línea a través de https://www.mercadopublico.cl, en el paso 3 del módulo de presentación de las ofertas.
  • Anexo N°1: Formulario Datos del Oferente.
  • Anexo N°2: Declaración jurada de independencia de la oferta.
  • Anexo N°3: Declaración Jurada para autorización de notificaciones.

 

UTP:

Adicionalmente, en caso de que el oferente sea UTP debe incluir:

  • Anexo N°4: Declaración para Uniones Temporales de Proveedores: debe ser presentado por el apoderado de la UTP que presente la oferta en el Sistema de Información, quien además debe realizar la declaración contenida en la “Declaración de ausencia de conflicto de interés e inhabilidades por condenas” electrónica presentada junto a la oferta.

Las ofertas presentadas por una Unión Temporal de Proveedores (UTP) deberán contar con un apoderado, el cual debe corresponder a un integrante de la misma, ya sea persona natural o jurídica. En el caso que el apoderado sea una persona jurídica, ésta deberá actuar a través de su representante legal para ejercer sus facultades.

Todos los anexos referidos deben ser ingresados a través del Sistema https://www.mercadopublico.cl, en la sección “Anexos Administrativos”.

En caso de no presentarse debidamente la declaración jurada online constatando la ausencia de conflictos de interés e inhabilidades por condenas, o no presentarse los Anexos N°2 y N°4, la oferta será declarada inadmisible.

Anexos Técnicos

Además, todos los oferentes deberán adjuntar lo siguiente:

Anexo N°5:  Oferta técnica.

Anexo N°5.1: Formato tipo “Carta de Referencia Experiencia Oferente”: Se deberán presentar tantas Cartas de Referencia conforme a cada experiencia declarada en Anexo N°5.

Anexo N°6: Programas de integridad.

Los anexos mencionados deben ser ingresados a través del Sistema https://www.mercadopublico.cl, en la sección “Anexos Técnicos”, en el ID de esta licitación, dentro del plazo de presentación de ofertas señalado en la cláusula N°3 “Etapas y plazos”, junto con los antecedentes indicados en dichos anexos.

Aquellas ofertas que no entreguen el Anexo N°5, de acuerdo con lo señalado en estas bases, serán declaradas inadmisibles y no serán evaluadas, sin perjuicio de la aplicación del artículo 40 del reglamento de la ley N°19.886, si correspondiere.

Consideraciones:

La oferta deberá cumplir con todos los requisitos establecidos en la cláusula 9.3 “Requisitos técnicos de admisibilidad de las ofertas” entendiéndose que éstos son los requisitos técnicos mínimos para poder participar en la línea de servicio respectiva. La oferta que no cumpla con todos estos requisitos técnicos mínimos será descartada y no será considerada en la evaluación. En virtud de lo anterior, la oferta será declarada inadmisible en las líneas de servicio donde se verifiquen dichos incumplimientos.

Anexos Económicos

Anexo N°7. Oferta económica.

Se deberá adjuntar un único Anexo N°7 debidamente completado, independiente de que la oferta se refiera a una o más líneas de servicio. En caso de no adjuntarse dicho anexo, o habiéndose presentado, este no se encuentra debidamente completado, la oferta será declarada inadmisible en su totalidad y no participará del proceso de evaluación. Por su parte, si el valor ofertado supera el presupuesto máximo disponible descrito en la cláusula 12.7, la oferta podrá ser declarada inadmisible.

El anexo referido es obligatorio y debe ser ingresado a través del Sistema https://www.mercadopublico.cl, en la sección “Anexos Económicos”, en el ID de esta licitación, dentro del plazo de presentación de ofertas señalado en la cláusula N°3 “Etapas y plazos”.

Anexos informativos

Los siguientes anexos no corresponden a documentos que deban ser presentados por el proveedor junto a su oferta, sino que estos anexos contienen información que debe ser tenida en consideración por los oferentes:

Anexo A: Especificaciones referenciales para el desarrollo de soluciones.

Anexo B: Herramientas Tecnológicas disponibles.

Anexo C: Diagrama de Arquitectura.

Anexo D: Información referencial de equipos de trabajo.

Observaciones

Los oferentes deberán presentar su oferta a través de su cuenta en el Sistema de Información https://www.mercadopublico.cl. En los anexos que forman parte de la oferta se debe identificar correctamente al proveedor oferente, sea persona natural, persona jurídica o UTP, debiendo existir coincidencia entre los datos de identificación del oferente que consten en la cuenta de usuario del Sistema de Información, por un lado, y los datos de identificación del oferente que consten en los respectivos anexos, por otro. En caso de existir una discordancia insalvable de identidad, que no haga posible la aplicación del artículo 40 del reglamento de la ley N°19.886, la respectiva oferta será declarada inadmisible.

Los anexos arriba singularizados, en los casos en que se requiera firma (los que posean espacio para firma), deberán ser suscritos por los oferentes, por la persona natural o por los representantes legales de los oferentes, en el caso de que éstos sean personas jurídicas. En el caso que la oferta sea presentada por una Unión Temporal de Proveedores, el apoderado de esta deberá tener poder suficiente para efectuar esta declaración representando a cada uno de los integrantes de la unión, respecto de los anexos técnicos y económicos.

Las únicas ofertas válidas serán las presentadas a través del portal https://www.mercadopublico.cl. No se aceptarán ofertas que se presenten por un medio distinto al establecido en estas bases, salvo si se acredita la indisponibilidad técnica del sistema de acuerdo con el artículo N°62 del Reglamento de la Ley N°19.886.

 

Los oferentes deberán constatar que el envío de sus ofertas a través del portal https://www.mercadopublico.cl haya sido realizado con éxito, incluyendo el previo ingreso de todos los formularios y anexos requeridos y completados de acuerdo con lo establecido en las presentes bases. Será responsabilidad de los oferentes adoptar las precauciones necesarias para ingresar oportuna y adecuadamente sus ofertas.

Para lo anterior, siempre se deberá verificar que los archivos que se ingresen contengan efectivamente los anexos solicitados; asimismo, se debe comprobar siempre, luego de que se finalice la última etapa de ingreso de la oferta respectiva, que se produzca el despliegue automático del “Comprobante de Envío de Oferta” que se entrega en dicho Sistema, el cual puede ser impreso por el proponente para su resguardo. En dicho comprobante será posible visualizar los anexos adjuntos, cuyo contenido es de responsabilidad del oferente. El hecho que el oferente haya obtenido el “Comprobante de envío de oferta” señalado, únicamente acreditará el envío de esta a través del Sistema, pero en ningún caso certificará la integridad o la completitud de ésta, lo cual será parte de la evaluación respectiva.

 

En caso de que, antes de la fecha de cierre de la licitación, un proponente edite una oferta ya enviada, deberá asegurarse de enviar nuevamente la oferta una vez haya realizado los ajustes que estime, dentro del plazo establecido para la presentación de las propuestas, y descargar un nuevo “Comprobante de Envío de Oferta”.

Las ofertas presentadas por UTP y su evaluación deberán ceñirse a las disposiciones del artículo 67 bis del Reglamento de la ley N°19.886. Asimismo, se sugiere el cumplimiento de las recomendaciones de la Directiva N°22 de la Dirección ChileCompra, disponible en https://www.chilecompra.cl/directivas-de-compra/.

7.    Antecedentes legales para ser contratado

El oferente que resultare adjudicado deberá encontrarse inscrito y en estado “hábil” en el Registro de Proveedores, al momento de celebrar el respectivo contrato con la Dirección ChileCompra. Adicionalmente, deberá presentar y acreditar en el Registro de Proveedores, salvo en aquellos casos en que se requiera acreditar a la Dirección ChileCompra, los siguientes documentos:

Si el

adjudicatario es Persona Natural

a)     Fotocopia simple de cédula de identidad de persona natural.

b)     Anexo N°9: Declaración jurada simple para contratar (Deudas vigentes con trabajadores).

 Si el

adjudicatario NO es Persona Natural

a)     Certificado de vigencia del poder del Representante Legal, con una antigüedad no superior a 60 días corridos, contados desde la fecha de notificación de la adjudicación, otorgado por el Conservador de Bienes Raíces correspondiente o, en los casos que resulte procedente, cualquier otro antecedente que acredite la vigencia del poder del representante del oferente, según los plazos de vigencia indicados.

b)     Certificado de Vigencia de la Sociedad con una antigüedad no superior a 60 días corridos, contados desde la fecha de notificación de la adjudicación, o el antecedente que acredite la existencia jurídica del oferente.

c)      Anexo N°9: Declaración jurada simple para contratar (Deudas vigentes con trabajadores).

SOLO PARA ADJUDICATARIOS UTP:

  • Las Uniones Temporales de Proveedores (UTP) deben regirse por lo dispuesto en el artículo 67 bis del reglamento de la Ley N°19.887, tanto para su constitución, para la celebración del contrato y ejecución del mismo.
  • El apoderado de la UTP debe corresponder a un integrante de la misma, ya sea persona natural o jurídica. Aquel integrante que se designe como mandatario de la UTP deberá tener poder suficiente, lo cual deberá constar en los documentos legales que se presenten y que respaldan la constitución de dicha figura, de acuerdo con el artículo 67 bis del Reglamento de la Ley N°19.886. En el caso que el apoderado sea una persona jurídica, ésta deberá actuar a través de su representante legal para ejercer sus facultades.
  • Las UTP deberán entregar todos los documentos señalados en esta cláusula respecto de cada uno de sus integrantes.
  • La UTP que resulte adjudicada en contrataciones iguales o superiores a 1.000 UTM, deberá, además, materializar por escritura pública el acuerdo en que conste la unión temporal de proveedores, la que deberá presentarse al organismo público comprador al momento de contratar.
  • Al momento de la suscripción del contrato, la UTP deberá informar quién de sus integrantes será el emisor del documento tributario de cobro.

Asimismo, para contratar, el oferente adjudicado deberá cumplir con lo dispuesto en el artículo 6°, inciso final, de la Ley N°21.640 de Presupuestos del Sector Público correspondiente al año 2024, que dispone lo siguiente:

“ Las instituciones privadas, cualquiera sea su naturaleza, al momento de contratar con el Estado deberán acompañar un certificado de cumplimiento de obligaciones laborales y de remuneración. En el evento de que la institución privada se encuentre incorporada en algún registro por incumplimientos laborales o de remuneraciones, o no acompañe los referidos certificados en la oportunidad correspondiente, no podrá contratar con el Estado mientras no subsane el incumplimiento que la afecte.”

7.1            Observaciones

Todos los anexos deben ser firmados por el representante del oferente respectivo o por sí, en el caso de que sean personas naturales.

Cuando el oferente sea una Unión Temporal de Proveedores (UTP), deberá presentar el Anexo N°4 por cada integrante de la UTP, suscrito por el respectivo integrante o por el representante legal del integrante, según sea el caso.

Los antecedentes legales para poder ser contratado, sólo se requerirán respecto del adjudicatario y deberán estar disponibles en el Registro Electrónico de la Administración dentro de los 10 días hábiles contados desde la notificación de la resolución de adjudicación totalmente tramitada.

Lo señalado en el párrafo precedente no resultará aplicable a las garantías de fiel cumplimiento de contrato, las cuales deberán ser entregadas físicamente en las dependencias de la DCCP, o bien enviadas por correo certificado y recibido en la dirección ya indicada (Monjitas 392, piso 10, Santiago), dentro de los 10 días hábiles contados desde la notificación de adjudicación totalmente tramitada. En los casos en que se otorgue esta garantía de manera electrónica, deberá ajustarse a la ley N°19.799 sobre Documentos electrónicos, firma electrónica y servicios de certificación de dicha firma, y su entrega y/o notificación debe efectuarse al correo oficinadepartes@chilecompra.cl.

Durante la vigencia del respectivo contrato, el adjudicatario deberá acreditar mediante el Anexo N°9, Declaración jurada simple para contratar, que no registra saldos insolutos de remuneraciones o cotizaciones de seguridad social con sus actuales trabajadores en los últimos dos años. Lo anterior es sin perjuicio de las obligaciones que a este respecto se le exijan para autorizar los pagos que se generen durante la ejecución contractual. Asimismo, esta declaración deberá renovarse al cumplirse la mitad del periodo de ejecución del contrato. En el caso de una UTP, deberá ser entregada por cada integrante de esta.

 

Si el respectivo proveedor adjudicado no entrega o no mantiene disponibles en el Registro Proveedores de Mercado Público la totalidad de los antecedentes requeridos para ser contratado dentro del plazo fatal de 10 días hábiles contados desde la notificación de la resolución de adjudicación a través del portal https://www.mercadopublico.cl, se considerará que desiste de la adjudicación, facultando a la DCCP para readjudicar la licitación, en conformidad con lo establecido en las presentes bases.

7.2            Obligatoriedad de inscripción en el Registro de Proveedores

En caso de que el proveedor que resulte adjudicado no se encuentre inscrito en el Registro Electrónico Oficial de Contratistas de la Administración (Registro de Proveedores), deberá inscribirse dentro del plazo de 10 días hábiles administrativos, contados desde la notificación de la resolución de adjudicación.

Tratándose de una UTP, cada proveedor de dicha unión temporal deberá inscribirse en el Registro Proveedores de Mercado Público en los mismos plazos señalados precedentemente.

8.    Garantías requeridas

8.1        Garantía de Seriedad de la Oferta

El oferente deberá presentar juntamente con su oferta un instrumento de garantía que permita caucionar la seriedad de la oferta ingresada por éste en el presente proceso licitatorio.

Las ofertas que no acompañen en su oferta la Garantía de Seriedad de la Oferta en la forma y oportunidad dispuestas en esta cláusula serán declaradas inadmisibles.  

El instrumento de garantía en cuestión deberá regirse según lo siguiente:

Tipo de Documento

Cualquier instrumento que asegure el cobro de la garantía de manera rápida y efectiva, pagadera a la vista y con el carácter de irrevocable. Ejemplos de ellos son: Boleta de garantía, certificado de fianza a la vista, póliza de seguro de garantía, vale vista, entre otros, todos los cuales deberán ser pagaderos a la vista y tener el carácter de irrevocables. No se aceptan cheques como instrumento de garantía.

Esta garantía podrá otorgarse mediante uno o varios instrumentos financieros de la misma naturaleza que en conjunto representen el monto a caucionar.

Beneficiario

Dirección de Compras y Contratación Pública, RUT N° 60.808.000-7.

Fecha de Vencimiento

Esta garantía deberá tener una vigencia de 120 días corridos posterior a la fecha de publicación de las presentes bases en el Sistema de Información.

Monto

$5.000.000.- (cinco millones de pesos chilenos)

Glosa

El instrumento, cualquiera sea su naturaleza, deberá indicar en su glosa lo siguiente: "Para garantizar seriedad de la oferta de la propuesta pública de la contratación de servicios de desarrollo de soluciones para la plataforma Mercado Público”.

En caso de que el banco emisor rechace incluir la glosa en el cuerpo del instrumento, el oferente deberá dar cumplimiento a la inclusión de la glosa en forma manuscrita en el mismo, o bien, en documento anexo.

 

8.1.1        Plazos y forma de entrega de la garantía

El plazo para la recepción de la garantía de seriedad de la oferta se extenderá hasta antes de la fecha y hora de cierre de presentación de las ofertas.

La forma de entrega de la garantía dependerá de la naturaleza del documento:

a)      Si la garantía fuera emitida en soporte papel, ésta deberá ser entregada en la Oficina de Partes de esta Dirección ubicada en calle Monjitas 392, piso 10, comuna de Santiago, de lunes a jueves de 09:00 a 15:00 horas y los viernes de 09:00 a 13:00 horas, o bien, enviada por correo certificado y recibido en el mismo domicilio, antes del cierre de recepción de ofertas.

b)     En los casos en que se otorgue de manera electrónica, deberá ajustarse a la ley N° 19.799 sobre Documentos electrónicos, firma electrónica y servicios de certificación de dicha firma, y adjuntarse el documento en la sección de “Garantías” al momento de ingresar la oferta en Mercado Público. En caso de no poder ingresarse junto a la oferta, se deberá enviar el documento electrónico al correo oficinadepartes@chilecompra.cl.

8.1.2        Forma y oportunidad de restitución

En el caso del proveedor adjudicado, la restitución de esta garantía será realizada una vez que haya entregado la Garantía de Fiel Cumplimiento de Contrato.

La devolución de las garantías de seriedad a aquellos oferentes cuyas ofertas hayan sido declaradas inadmisibles se efectuará dentro del plazo de 10 días hábiles contados desde la notificación de la resolución que dé cuenta de la inadmisibilidad. En este caso, las garantías podrán ser retiradas el día siguiente a la publicación de la resolución que dé cuenta de la inadmisibilidad en el Sistema de Información, en las dependencias de la Dirección.

La devolución de las garantías de seriedad a aquellos oferentes cuyas ofertas hayan sido declaradas admisibles, pero no hayan sido adjudicadas, se efectuará a partir de la fecha de notificación de la dictación de la resolución que apruebe el contrato con el proveedor adjudicado. En este último caso, las garantías podrán ser retiradas en las dependencias de la Dirección.

8.1.3        Ejecución de la garantía

Esta garantía se otorgará para caucionar la seriedad de las ofertas y de todas las obligaciones que se imponen al oferente pudiendo ser ejecutada unilateralmente por vía administrativa por la DCCP, en los siguientes casos:

       i.          No suscripción del contrato definitivo por parte del proveedor adjudicado.

      ii.          No entrega de los antecedentes requeridos de acuerdo con las presentes bases para la suscripción del referido contrato.

     iii.          Desistimiento de la oferta dentro del plazo de vigencia establecido en las presentes bases.

     iv.          Presentación de una oferta falsa, manifiestamente errónea o inductiva a error, en el sentido que importe la entrega de antecedentes que no se correspondan con la realidad y cuya entidad incida en la validez de la oferta, lo que se deberá ser determinado mediante información objetiva y disponible.

      v.          No inscripción en el Registro de Proveedores en estado “hábil” dentro del plazo establecido en las presentes bases.

     vi.          Por la no presentación oportuna de la garantía de fiel cumplimiento del contrato, en el caso del proveedor adjudicado.

   vii.          En general, por el incumplimiento de cualquiera de las obligaciones que se imponen al oferente que postule a este proceso licitatorio.

8.2            Garantía de Fiel Cumplimiento de Contrato

La garantía de fiel cumplimiento de contrato deberá ajustarse a lo regulado en el artículo 68 del Reglamento de la Ley de Compras Públicas y a lo establecido a continuación:

Tipo de Documento

Cualquier tipo de instrumento de garantía que asegure el cobro de este, de manera rápida y efectiva, pagadera a la vista y con el carácter de irrevocable. Ejemplos de ellos son: Boleta de garantía, certificado de fianza a la vista, vale vista, entre otros, todos los cuales deberán ser pagaderos a la vista y tener el carácter de irrevocables. No se aceptan cheques como instrumento de garantía.

Beneficiario

Dirección de Compras y Contratación Pública, RUT N° 60.808.000-7.

Fecha de Vencimiento

60 días hábiles posteriores al término de la vigencia del contrato suscrito con el adjudicatario.

Monto

5% del valor total del contrato.

Glosa

El instrumento, cualquiera sea su naturaleza, deberá indicar en su glosa lo siguiente “Para garantizar el fiel y oportuno cumplimiento de la propuesta púbica de la contratación de servicios de desarrollo de soluciones para la plataforma Mercado Público y el pago de saldos insolutos de remuneraciones o cotizaciones de seguridad social con sus actuales trabajadores o con trabajadores contratados en los últimos dos años”.

En caso de que el instrumento no permita la inclusión de la glosa señalada, el oferente deberá dar cumplimiento a la incorporación de ésta en forma manuscrita en el mismo instrumento, o bien, mediante un documento anexo a la garantía.

Responsabilidad

Será responsabilidad del adjudicatario realizar los trámites pertinentes para entregar la garantía en la forma solicitada y en los plazos estipulados para ello, como asimismo de mantenerla vigente al menos por 60 días hábiles posteriores a la fecha de término de la vigencia del contrato de acuerdo con lo indicado en la cláusula N°12.2 sobre “Vigencia del contrato y renovación”.

8.2.1        Plazos y forma de entrega de la garantía

Si la garantía fuera emitida en soporte papel, ésta deberá ser entregada en la Oficina de Partes de esta Dirección ubicada en calle Monjitas 392, piso 10, Santiago, de lunes a jueves de 09:00 a 15:00 horas y los viernes de 09:00 a 13:00 horas, dentro de los 10 días hábiles posteriores a la fecha de notificación de la resolución de adjudicación totalmente tramitada.

En los casos en que se otorgue de manera electrónica, deberá ajustarse a la ley N° 19.799 sobre documentos electrónicos, firma electrónica y servicios de certificación de dicha firma y deberá remitirse al correo electrónico garantias@chilecompra.cl, con copia al correo oficinadepartes@chilecompra.cl.

8.2.2        Reposición, forma y oportunidad de restitución

En el caso de que se produzca el cobro de la garantía de fiel cumplimiento, debido al incumplimiento de cualquiera de las obligaciones dispuestas en las presentes bases de licitación y el contrato, y que justifiquen su cobro, el adjudicatario deberá reponer la o las garantías señaladas por igual monto y plazo de vencimiento que la o las garantías originales, dentro de los 10 días hábiles siguientes contados desde la notificación de cobro de la primera. En caso de no reponer dicha garantía en el plazo indicado anteriormente, se procederá en conformidad a lo establecido en la cláusula N°12.6.3 “Término anticipado del contrato”.

Será responsabilidad del proveedor contratado mantener vigente la garantía de fiel cumplimiento de acuerdo con lo indicado en esta cláusula. Mientras se encuentre vigente el contrato celebrado con el adjudicatario, las reposiciones y renovaciones de esta garantía serán de exclusiva responsabilidad del Proveedor.

En el caso que los adjudicatarios entreguen un vale vista como garantía de fiel y oportuno cumplimiento, se recuerda que de acuerdo a lo dispuesto en el artículo 156 del DFL N°3 del año 1997, del Ministerio de Hacienda, que fija el texto refundido, sistematizado y concordado de la Ley General de Bancos y de otros cuerpos legales que se indican, dichos documentos tendrán una validez de 5 años, a partir de lo cual se reafirma que la obligación de mantener vigente este tipo de garantía corresponde únicamente al adjudicatario.

Las garantías presentadas en este proceso serán devueltas, sin reajustes ni intereses, una vez cumplida su fecha de vencimiento. El retiro de éstas será de responsabilidad exclusiva del proveedor contratado.

8.3            Garantías por anticipo

De conformidad con lo establecido en el artículo 73 del reglamento de la Ley N°19.886, las presentes bases de licitación permitirán que las partes acuerden en el respectivo contrato o cualquiera de sus modificaciones el pago de anticipos sujeto a la entrega por parte del adjudicatario de una garantía de anticipo por el 100% de los recursos anticipados, si así fuere necesario para el adecuado cumplimiento de las obligaciones de ambos contratantes. En este caso, se permitirán los mismos instrumentos establecidos para la garantía de fiel cumplimiento, señalados en la cláusula N°8.2 de estas bases.

Si existiere más de un hito de pago, la garantía podrá entregarse en uno o más instrumentos, cuyos montos irán en la proporción del valor de cada hito.

La devolución de la garantía por anticipo se efectuará dentro del plazo de 10 días hábiles contados desde la recepción conforme por parte de la Entidad compradora de los servicios que el proveedor haya suministrado con cargo al respectivo anticipo.

9.    Descripción de la contratación

9.1            Contexto de la contratación

El artículo 19 de la Ley N°19.886 dispuso la creación de un Sistema de Información de Compras y Contrataciones de la Administración, a cargo de la Dirección de Compras y Contratación Pública, que se aplicará a los organismos señalados en el artículo 1º de la citada ley, y que deberá estar disponible a todo el público, en la forma que regula el reglamento.

El Sistema de Información, también denominado Mercado Público permite que más de 850 organismos públicos realicen sus procesos de compra de forma pública y transparente, adquiriendo bienes y/o servicios de los proveedores que los ofrecen en la ya referida plataforma.

El 11 de diciembre del 2023, se publicó en el Diario Oficial la Ley N°21.634 que moderniza la Ley N°19.886 en cuya virtud se deberán modificar una serie de funcionalidades de la plataforma Mercado Público, así como, incorporar nuevas funcionalidades y mecanismos de compra.  

Considerando aquello, la Dirección ChileCompra requiere contratar el servicio de desarrollo de las soluciones para la plataforma Mercado Público, mediante la contratación de horas de desarrollo, para las líneas de servicio que a continuación se señalan.

9.2            Líneas de servicios licitados

Las presentes bases tienen por objeto la adquisición del servicio de desarrollo de soluciones para la plataforma Mercado Público considerando dos líneas de servicio cuya descripción detallada se encuentra en el Anexo A de las presentes bases.

Los oferentes podrán ofertar a ambas líneas de servicio, sin embargo, cada oferente solo podrá adjudicar un máximo de una línea de servicio, de acuerdo con lo indicado en la cláusula 11.5 “Adjudicación”.

Las referidas líneas de servicio tendrán por objeto el desarrollo de arquitectura, lineamientos, entregables funcionales e implementación, incluyendo certificación y transferencia de conocimiento, de las soluciones que a continuación se señalan:

N° Línea de Servicio

Soluciones de la plataforma Mercado Público

Línea de servicio N°1

  • Creación de nuevos organismos compradores en Mercado Público
  • Ficha del organismo comprador
  • Información de compradores en los procesos de compra
  • Integración con información del Tribunal de Contratación Pública

Línea de servicio N°2

  • Actualización de “Trato Directo”
  • Actualización de “Compra Ágil”
  • Incorporación de mecanismo de compra “Diálogos Competitivos”
  • Incorporación de mecanismo de compra "Contratos para la Innovación"

9.3            Requisitos técnicos de admisibilidad de las ofertas

Los oferentes deberán cumplir con los siguientes requisitos técnicos mínimos respecto de cada línea de servicio a la que oferte, en caso de incumplir cualquiera de estas exigencias, la oferta de la línea respectiva será declarada inadmisible:

1)       Periodo de garantía técnica

Los desarrollos de las soluciones descritas para cada línea de servicio deberán contar con una garantía técnica de tres meses desde que cada entregable es puesto en Go Live, conforme a la programación del Cronograma de Trabajo descrito en la cláusula 9.4 número 3 de las presentes bases.

Este período de garantía debe declararse en el Anexo N°5. En caso de no declararse, la oferta será considerada inadmisible.

2)       Equipo de trabajo

El oferente deberá proponer un equipo de trabajo, el cual debe cumplir con las siguientes condiciones:

  1. Perfiles de los profesionales

Para el correcto desarrollo de los servicios que se requieren para cada línea de servicio los oferentes deberán contar con los perfiles de profesionales que se describirán a continuación.

Estos perfiles deberán ser incluidos por los oferentes de manera obligatoria en su propuesta de equipo de trabajo, la que se debe consignar en el Anexo N°5. Estos profesionales, deberán tener  dedicación exclusiva al proyecto, esto para cada línea de servicio.

Los perfiles y la cantidad mínima de profesionales requerida para cada perfil se definen a continuación:

Perfil

Cantidad mínima de personas

Línea de servicio N°1

Línea de Servicio N°2

Líder Técnico

1

1

Desarrollador Frontend (ReactJS)

3

3

Desarrollador Backend (Spring boot)

5

6

Desarrollador AWS

1

1

Desarrollador .NET

1

3

Ingeniero DevOps

1

1

TOTAL

12

15

Según lo señalado precedentemente, estos perfiles deben incluirse obligatoriamente en la oferta para cada línea de servicio. Para cumplir con lo requerido, el oferente deberá individualizar a todos los profesionales en el Anexo N°5 para cada perfil definido. Es decir, para la línea de servicio N°1, deberá indicar a 12 profesionales, mientras que para la línea de servicio N°2, deberá indicar a 15 profesionales.

Aquellas ofertas  que no cumplan con incluir la totalidad de perfiles y profesionales por perfil indicados para cada línea de servicio serán consideradas inadmisibles y no serán evaluadas.

  1. Requisitos por perfil

A continuación, se describen los requisitos obligatorios que deben cumplir los profesionales que se asignarán a cada perfil, los que deberán ser acreditados mediante la sección Currículum Vitae en el Anexo 5. En el evento de no cumplir todos los requisitos descritos a continuación, o bien, en caso de que la información no pudiera ser acreditada, la oferta será declara inadmisible y no será evaluada para la línea de servicio correspondiente, sin perjuicio de la aplicación del artículo 40 del reglamento de la ley N°19.886, si correspondiere.

Cabe mencionar que un mismo profesional no podrá repetirse ni estar asignado a más de un perfil dentro de una misma línea de servicio. No obstante lo anterior, si un proveedor oferta a ambas líneas de servicio, considerando lo estipulado en la cláusula 11.5 “Adjudicación”, éste podrá repetir profesionales entre líneas de servicio. Por ejemplo: el Líder Técnico podría ser el mismo profesional en ambas líneas de servicio, pero no podría ser, a la vez, Ingeniero DevOps en la misma línea de servicio ofertada.

  1. Líder técnico

Obligatorio:

                           I.          Contar con, al menos, tres años ejerciendo en cargos como líder técnico o líder de equipos de desarrollo, en instituciones públicas o privadas.

                         II.          Contar con, al menos, tres años en desarrollo de software (codificación) en lenguajes de programación Frontend en, al menos, alguna de las siguientes tecnologías: ReactJS, Angular, Javascript.

                        III.          Contar con, al menos, tres años en desarrollo de software (codificación) en lenguajes de programación Backend, en al menos alguna de las siguientes tecnologías: Spring Boot, Java, C#, VisualBasic.

  1. Desarrollador Frontend (ReactJS)

Obligatorio:

                           I.          Contar con, al menos, tres años de experiencia comprobada en desarrollo de software con tecnología ReactJS, en uno o más proyectos digitales en instituciones públicas o privadas.

                         II.          Contar con experiencia en el trabajo con equipos multidisciplinarios y de desarrollo ágil.

                        III.          Contar con experiencia trabajo con software de control de versiones.

  1. Desarrollador Backend (Spring boot)

Obligatorio:

                           I.          Contar con, al menos, tres años de experiencia comprobada en desarrollo de software con Java Spring boot en uno o más proyectos digitales en instituciones públicas o privadas.

                         II.          Contar con experiencia en el desarrollo con base de datos SQL Server, PostgreSQL o similar. 

                        III.          Contar con experiencia en el Desarrollo de servicios REST JSON.

                       IV.          Contar con experiencia en trabajo con equipos multidisciplinarios y de desarrollo ágil.

  1. Desarrollador AWS

Obligatorio:

                           I.          Contar con, al menos, dos años de experiencia comprobada en desarrollo en proyectos de AWS.

                         II.          Contar con al menos una de las siguientes certificaciones vigente al momento de la publicación de la licitación: AWS Certified Solutions Architect – Associate / AWS Certified Solutions Architect – Professional / AWS Certified Security – Specialty u otra certificación relacionada al rol de Arquitectura y Seguridad de AWS / AWS Certified Developer Associate.

                        III.          Contar con experiencia en el desarrollo con base de datos SQL Server, PostgreSQL o similar. 

                       IV.          Contar con experiencia en el desarrollo de servicios REST JSON.

                         V.          Contar con experiencia en trabajo con equipos multidisciplinarios y de desarrollo ágil. 

                       VI.          Contar con experiencia desarrollando con DDD (Domain Driven Design).

  1. Desarrollador .Net

Obligatorio:

                           I.          Contar con, al menos, tres años de experiencia comprobada en desarrollo de software utilizando lenguaje de programación .NET.

                         II.          Experiencia comprobable en desarrollo de servicios web REST y SOAP.

                        III.          Contar con experiencia en el desarrollo con Base de datos SQL Server, PostgreSQL o similar. 

                       IV.          Contar con experiencia en el desarrollo de servicios REST JSON.

                         V.          Contar con experiencia en trabajo con equipos multidisciplinarios y de desarrollo ágil. 

                       VI.          Contar con experiencia comprobable en C#, VB.NET, MVC, Razor.

  1. INGENIERO DEVOPS

 

Obligatorio:

                           I.          Contar con, al menos, tres años de experiencia comprobada en rol de DevOps y/o DevSecOps en uno o más proyectos digitales en instituciones públicas o privadas

                         II.          Contar con experiencia en la administración y/o desarrollo con Base de datos SQL Server, PostgreSQL o similar.

                        III.          Contar con experiencia mínima de un año en el manejo de Pipelines con Azure DevOps o similares.

                       IV.          Contar con experiencia en el manejo de Git / Gitflow. 

                         V.          Contar con experiencia en trabajo con equipos multidisciplinarios y de desarrollo ágil. 

                       VI.          Contar con experiencia mínima de un año implementando y/o administrando servicios Cloud en AWS, GCP y/o Azure.

  1. Currículum Vitae

A fin de acreditar la experiencia de los profesionales que se ofertan como parte del equipo de trabajo para cada perfil, se deberá completar la sección “Currículum Vitae” de cada uno de sus integrantes en el Anexo 5. En caso de no incluir información de cada profesional, la oferta será considerada inadmisible, sin perjuicio del ejercicio de la facultad contenida en el artículo 40 del reglamento de la Ley N°19.886, en caso de ser procedente.

9.4            Operatoria de los servicios.

El proyecto se desarrollará con la metodología interna de la Dirección ChileCompra basada en Metodología Ágil, considerando lo siguiente:

1)       Reunión Inicial de Trabajo y Onboarding

La reunión inicial se coordinará y se realizará a la mayor brevedad posible, luego de firmado el contrato por el proveedor.

El objetivo de esta reunión inicial es dar a conocer con mayor detalle la plataforma de Mercado Público y la planificación de la implementación de los desarrollos, tanto al proveedor adjudicado como a su equipo de trabajo.

Asimismo, se confirmará cómo se realizará la coordinación de las reuniones de seguimiento y evaluación del desarrollo y ejecución de cada entregable, detallando la forma de implementación y sus actividades clave.

En esta misma ocasión, se llevará a cabo un proceso de onboarding para los profesionales del equipo de trabajo del proveedor adjudicado, donde se explicará la relevancia de las soluciones a desarrollar y otros temas que pudieran resultar relevantes a este respecto.

Finalmente, en esta reunión inicial deberán suscribirse los Acuerdos de Confidencialidad por parte de todos los integrantes del equipo de trabajo, utilizando para ello el Anexo N°10 dispuesto en estas bases. En el caso que no se suscriban estas declaraciones por todos los integrantes del equipo de trabajo en la reunión inicial, se les concederá un plazo de cinco días hábiles para que remitan los documentos faltantes firmados.

Superado este plazo, la DCCP deberá solicitar el cambio de profesional en los términos de la cláusula 9.4 número 2 de las presentes bases. Si pese a todo, el Adjudicatario no cumple con esta obligación, instando a que todos sus profesionales firmen la declaración de confidencialidad, se considerará un incumplimiento susceptible de la aplicación de las medidas establecidas en la cláusula 12.6 de estas bases.

2)       Equipo de trabajo

El equipo de trabajo es esencial para la ejecución exitosa del contrato, en razón de ello, posterior a la adjudicación, se deberá tener constituido el equipo de trabajo dentro del plazo de 10 días hábiles posteriores a la firma del contrato, iniciando los trabajos según la planificación acordada entre las partes en la reunión inicial, a fin de cumplir con los plazos de entrega. Con todo, el adjudicatario se obliga a mantener de manera continua la cantidad de profesionales requerida para cada perfil durante toda la vigencia del contrato

Los profesionales propuestos por el oferente para formar parte del equipo de trabajo del proyecto podrán ser evaluados técnicamente a través de actividades que la DCCP estime convenientes, las cuales podrían considerar pruebas de conocimiento y entrevistas personales, y que serán comunicadas en la reunión inicial de trabajo.

Lo anterior, con el objetivo de validar los conocimientos técnicos de los profesionales según perfil, pudiendo solicitarse un cambio de profesional si el resultado no es satisfactorio.

En caso de que el profesional propuesto no apruebe la evaluación técnica, el proveedor, en el plazo de cinco días hábiles, deberá reemplazarlo por un nuevo profesional que cumpla las exigencias establecidas en las presentes bases, el que también podrá ser evaluado técnicamente.

Asimismo, en caso de ser necesario, la DCCP podrá requerir una modificación en el equipo de profesionales durante la vigencia del contrato, lo que será coordinado entre las partes, con la debida antelación.

Sin perjuicio de aquello, el adjudicatario podrá solicitar a la Dirección ChileCompra, a través de su coordinador del contrato, el cambio de los profesionales que se desempeñan en cada uno de los perfiles, teniendo en consideración realizarlo con anticipación suficiente para no discontinuar el servicio, salvo que este cambio se deba a alguna causal inimputable al proveedor. Ejemplo de estas últimas situaciones son, muerte, incapacidad médica, renuncia, entre otros. Este cambio no deberá afectar la continuidad del servicio prestado y tampoco deberá implicar un cambio en la totalidad del equipo adjudicado, lo que afectaría la integridad del cumplimiento del  Contrato pudiendo la DCCP poner Término Anticipado al Contrato.

La solicitud de cambio deberá ser presentada por el proveedor, representado por su coordinador de contrato u otra persona debidamente autorizada, debe asegurarse de informar y entregar a la Dirección, junto a la Solicitud de Cambio, todos los antecedentes que acrediten el cumplimiento por el nuevo profesional de los requerimientos técnicos establecidos en la presente cláusula para que esta Dirección evalúe y apruebe la experiencia e idoneidad de la persona propuesta.

La solicitud de cambio debe ser aprobada por la Dirección ChileCompra, reservándose ésta el derecho de aceptar o rechazar la petición lo que será comunicado vía correo electrónico al coordinador de contrato del proveedor. En caso de que la solicitud no sea aceptada, el proveedor tendrá un plazo máximo de 3 días hábiles para proponer otra persona. En todo caso, si la Dirección ChileCompra considera que estos cambios afectan la integridad del cumplimiento del Contrato podrá poner Término Anticipado al Contrato.

Una vez presentado el profesional, con la finalidad de acreditar que este cuenta con los conocimientos técnicos solicitados, la Dirección de Compras y Contratación Pública podrá realizar las actividades que estime convenientes las cuales podrían considerar pruebas de conocimiento y entrevistas personales.

En caso de que el profesional propuesto no apruebe la evaluación, el proveedor, en el plazo de tres días hábiles, deberá reemplazarlo por un nuevo profesional en las mismas condiciones descritas previamente.

En caso de que este segundo profesional presentado sea rechazado por reprobación de las actividades de validación de conocimientos técnicos requeridos, se considerará una falta grave a las obligaciones del contrato y en caso de que se produzcan tres rechazos consecutivos se pondrá término anticipado al contrato.

Con todo, si durante la ejecución del contrato, la DCCP estima que alguno de los integrantes del equipo no cumple con los estándares o competencias técnicas exigidas durante el desarrollo del servicio, o en el evento de existir disconformidad con el desempeño del profesional, o retraso en el plazo de los entregables que dependen del profesional, la DCCP podrá solicitar por escrito y de manera fundada el reemplazo de este.

Realizada la solicitud de cambio antes mencionada, el proveedor tendrá 10 días hábiles para la presentación de un nuevo profesional, el que podrá ser sometido al mismo procedimiento de validación ya regulado en la presente cláusula.

3)       Project Manager

El adjudicatario deberá disponer y mantener mientras se encuentre vigente el contrato , un profesional con el rol de Project Manager, distinto de los integrantes de los equipos de trabajo, cuya identidad deberá ser informada a la DCCP previo a la suscripción del contrato, para que ejerza la labor de contraparte técnica de la DCCP en lo referido a la coordinación de las tareas programadas para la ejecución de los servicios y cumpliendo con las siguientes obligaciones:

a)      Realizar la planificación, seguimiento y control de los proyectos, garantizando el seguimiento de la metodología de gestión de proyectos de la DCCP.

b)     Gestionar oportunamente el alcance, costo y tiempos, con adecuada gestión del cambio.

c)      Gestionar las restricciones, riesgos y planes de acción/ mitigación durante la ejecución de los proyectos.

d)     Generar los reportes de estado de proyecto, manteniendo informada a las partes interesadas sobre los avances de los desarrollos.

e)     Liderar al equipo de desarrollo, siendo responsable de alcanzar los objetivos de los proyectos y coordinando a todas las partes interesadas.

4)       Cronograma de trabajo

En relación con el cronograma de trabajo, éste será definido para cada línea de servicio en la reunión inicial y podrá contener plazos de entrega de productos mínimos viables (MVP) para los desarrollos requeridos.

Sin perjuicio de lo anterior, en caso de requerirse por necesidades institucionales, durante la vigencia del contrato las partes podrán modificar, de común acuerdo, los plazos establecidos en el cronograma de trabajo previendo el cumplimiento de la fecha de Go Live del 11 de diciembre de 2024.

El compromiso adquirido en el cronograma de trabajo de cada proyecto será considerado la base para el seguimiento y control del equipo de profesionales, el cual quedará documentado a modo de respaldo para asegurar el cumplimiento oportuno de los servicios en el “Acta de Inicio de Servicios”, que será el documento oficial a partir del cual comienzan a correr los plazos de entrega de los hitos. Esta acta deberá suscribirse por ambas partes, tan pronto las partes hayan definido el cronograma de trabajo.

Adicionalmente, y de forma mensual, la planificación podrá ser corregida y ajustada de común acuerdo según se requiera.

Este cronograma de trabajo se entenderá formar parte integral del contrato suscrito entre las partes, respecto del cual surge la obligación del proveedor de dar cumplimiento oportuno a la presentación de los entregables comprometidos. Por lo anterior, el Administrador de Contrato deberá llevar un registro claro de este cronograma en un soporte digital fiable que permita su custodia y revisión.

En caso de constatar un desvío mayor a 15% en la planificación y en que el atraso sea atribuible al proveedor, éste tendrá la obligación de aumentar el número de profesionales y/o disponer de todos los recursos que estén a su alcance para subsanar y corregir el atraso. Las horas trabajadas por la incorporación de profesionales adicionales para corregir el desvío, no serán de cargo de la institución.

El incumplimiento de los compromisos adquiridos en la planificación acordada será considerado un incumplimiento grave para efectos de la aplicación de las medidas dispuestas en las respectivas bases, según lo descrito en la cláusula 12.6.

5)       Reuniones de seguimiento

El Líder Técnico y su equipo de trabajo deberán reunirse con el equipo designado por la Dirección ChileCompra para presentar los avances del desarrollo.

Dichas reuniones serán realizadas de manera semanal, a menos que se determine otro orden en algunas etapas del proyecto, en las fechas que oportunamente comunique la DCCP. Asimismo, en estas reuniones o en cualquier momento que lo requiera, el adjudicado deberá especificar la necesidad de información que tenga que ser provista por la DCCP para el avance de los desarrollos.

6)       Seguimiento del proyecto

El seguimiento del proyecto se realizará considerando los tiempos y actividades descritas en el cronograma de trabajo, definido entre las partes en la reunión inicial, según se indica en el literal 1) del presente acápite.

 

El proveedor utilizará un tablero de trabajo colaborativo dispuesto por la DCCP (Jira, Timelog y/u otro vigente) para monitorear el avance del proyecto, el cual se debe mantener permanentemente actualizado con los estados que se utilicen para conocer el grado de avance en la ejecución de los servicios, con la finalidad de garantizar el cumplimiento de las fechas dispuestas en el cronograma de trabajo. Es deber del proveedor mantenerlo actualizado en todo momento de conformidad a lo requerido por la DCCP.

La DCCP podrá solicitar reuniones de refinamiento al inicio de cada actividad programada; retrospectivas al final de cada actividad según Cronograma de Trabajo y mesas de trabajo conjunto durante la implementación del proyecto, de considerarlo necesario.

Por último, será responsabilidad del adjudicatario mantener la información actualizada de forma diaria en la plataforma de gestión de tareas que la DCCP defina, en donde los profesionales deberán ir reportando los avances logrados, bloqueos, atrasos y/o cualquier otro tipo de información relevante para el correcto seguimiento de la tarea.

7)       Consideraciones generales para el desarrollo de soluciones

En consideración de las especificaciones referenciales indicadas en el Anexo A, se debe permitir capturar métricas de uso de las funcionalidades mediante la instalación de Google Analytics, Hotjar u otras herramientas.

Asimismo, se debe poder recoger feedback de las personas usuarias a través de instrumentos como encuestas, evaluaciones, formularios de contacto, entre otros que serán puestos a disposición por la DCCP.

8)       Controles de cambios

Todo posible control de cambio debe ser reportado por el proveedor al Administrador de Contrato de manera formal con el fin de que el equipo de proyecto de la DCCP determine si procede como control de cambio o de alcance de lo definido en los requerimientos, y deberá formalizarse mediante la modificación de contrato, por mutuo acuerdo de las partes.

9.5            Accesibilidad

Las soluciones que se desarrollen como resultado de la prestación del servicio objeto de esta licitación deberán cumplir con estándares mínimos de accesibilidad universal para que el sistema pueda ser utilizado por todas las personas usuarias de manera autónoma, considerando como base la pauta de accesibilidad propuesta por la WCAG (Web Content Accessibility Guidelines) en su versión 2.1 (https://www.w3.org/WAI/standards-guidelines/wcag/es), en el marco de la Guía Técnica para la implementación de sitios web accesibles, del Servicio Nacional de Discapacidad del Gobierno de Chile.

9.6            Transferencia tecnológica

Como requisito para el paso a producción cuya fecha será definida en el respectivo cronograma de trabajo, el proveedor deberá entregar los siguientes documentos con el despliegue de los productos:

  • Documento de BD (modelo y diccionario de datos).
  • Manuales de instalación (definición de PR y Scripts de BD).
  • Manuales de usuario.
  • Manual de sistema para traspaso a DevOps.

Adicionalmente a la entrega de los documentos, se deben realizar sesiones de traspaso de conocimientos a las áreas que la DCCP defina oportunamente. Además, deberá considerar, entre otras, las siguientes actividades y documentos:

  • Capacitaciones a quienes la entidad licitante designe.
  • Manuales de instalación.
  • Manuales de usuarios.
  • Manuales de sistemas.
  • Presentaciones
  • Documentación en formato 4+1 donde la DCCP requiera (Wiki)

En ambos casos, las actividades que se originen de lo descrito previamente, deberá quedar estipulado en el Cronograma de Trabajo.

9.7            Aseguramiento de la calidad

Los participantes a este proceso licitatorio deberán incorporar un proceso de “Quality Assurance (QA)”, mediante el cual el proveedor deberá diseñar y presentar al equipo de proyecto de la DCCP un plan de pruebas detallado antes de cada entrega, el cual debe ser aprobado por la DCCP, para luego generar un reporte por cada entregable (sprints) en base a los resultados de la certificación de los planes de pruebas.

Los oferentes deberán proponer los mecanismos de aseguramiento de la calidad que utilizarán en el desarrollo del proyecto y el procedimiento pertinente para que ChileCompra evalúe el resultado de las pruebas realizadas. Dichos mecanismos propuestos serán acordados en su versión definitiva en conjunto con el proveedor al momento de suscribir el respectivo contrato.

Se hace presente que este proceso debe ser considerado en la planificación de los desarrollos y no debe retrasar la planificación.

Objeto de esta revisión, el proveedor deberá presentar un informe con la evidencia de las pruebas que fueron ejecutadas.

10.Consideraciones generales para la presentación de ofertas

10.1         Reglas de la postulación

  1. Sólo se admitirá una oferta por participante, entendiendo aquella como la presentación por parte de un oferente de los antecedentes requeridos en la cláusula N°6 “Anexos e instrucciones para presentar ofertas” y que serán evaluados bajo lo establecido en las presentes bases de licitación. Con todo, en caso de que el proveedor ingrese más de una oferta, se considerará la oferta que ingresó en último lugar (considerando fecha y hora registradas en el Sistema de Información), descartando las restantes ofertas ingresadas.

  1. Se entenderá como “un participante” a aquella persona natural, jurídica o Unión Temporal de Proveedores (UTP) que presente una oferta en los términos señalados en el numeral anterior. En el caso de las UTP, se deja establecido que, si los mismos integrantes de una UTP se asocian dos o más veces mediante la misma figura para presentar ofertas distintas, aun cuando designen a distintos apoderados, se entenderá que se trata de un solo participante, de conformidad a lo establecido en el artículo 67 bis del reglamento de la Ley N°19.886, y en ese caso, se considerará solamente la primera oferta que se haya ingresado al sistema.

  1. Se exigirá el cumplimiento de los requerimientos establecidos en la cláusula N°6 “Anexos e instrucciones para la presentación de ofertas” de las presentes Bases de Licitación, considerándose inadmisibles todas aquellas ofertas que no cumplan con lo requerido en ella.

  1.  Aquellas ofertas que no fueran presentadas a través del Portal de Mercado Público (www.mercadopublico.cl), en los términos solicitados, quedarán marginadas de la propuesta y no serán consideradas en la evaluación. Lo anterior, sin perjuicio de que concurra y se acredite algunas de las causales de excepción contempladas en el artículo 62 del reglamento de la Ley de Compras.

  1. Los documentos solicitados por la Dirección ChileCompra deben estar vigentes a la fecha de publicación de la presentación de las ofertas indicado en la cláusula N°3 “Etapas y plazos” de estas bases de licitación y ser presentados como copias simples, legibles y firmadas por el representante legal de la empresa, en los casos en que así sea requerido. Lo anterior, sin perjuicio de la facultad de la DCCP de aplicar el artículo 40 del reglamento de la ley N°19.886, si correspondiere, y de verificar la veracidad de la información entregada por el proveedor.

  1. Será de exclusiva responsabilidad del oferente el ingresar la oferta de conformidad con lo establecido en estas Bases de Licitación, en los plazos y condiciones establecidas para tales efectos, y la sola presentación de ésta implica la aceptación irrestricta de la totalidad de las cláusulas, obligaciones y términos dispuestos en este proceso licitatorio a través de estas Bases y el respectivo contrato.

  1. La Dirección ChileCompra declarará inadmisible cualquiera de las ofertas presentadas que no cumpla los requisitos o condiciones establecidas en las presentes bases, sin perjuicio de la facultad de esta Dirección de solicitar a los oferentes antecedentes omitidos y que salven errores u omisiones formales, de acuerdo con lo establecido en el artículo 40 del reglamento de la ley N°19.886. 

  1. Las presentes Bases de Licitación contienen las disposiciones generales que regirán las relaciones entre la DCCP, y el proveedor de los bienes y/o servicios a que se refiere la presente licitación, en adelante “Proponentes”, “Oferentes”, “Consultores”, “Contratistas” o “Participantes”, durante el proceso y en todas las materias relacionadas con esta licitación.

10.2         Presentación de ofertas

En relación con la presentación de las ofertas, los oferentes deberán:

  1. Tener presente que, para presentar ofertas, el proponente debe estar inscrito en Mercado Público, pero no es obligatorio estar registrado y acreditado como proveedor hábil en el Registro de Proveedores de la Administración del Estado. Esta última exigencia solo procede para quien resulte adjudicado.

  1. Tener presente que sólo se considerarán las ofertas realizadas en los formatos de los archivos dispuestos por la Dirección ChileCompra y sólo aquellas ofertas de los proponentes que las hubiesen enviado oportunamente, esto es, antes del cierre de recepción de ofertas.

  1. Tener en consideración que las ofertas que no cumplan con los requerimientos técnicos mínimos serán declaradas inadmisibles.

  1. Hacer ingreso de su oferta en el portal www.mercadopublico.cl.

  1. Ingresar su oferta económica en valores brutos, es decir, considerando todos los impuestos y recargos, y en pesos chilenos sin decimales. En caso de que un valor contenga decimales, éste se redondeará al número entero siguiente en caso de que la primera cifra decimal sea igual o superior a 5. En caso contrario, el monto deberá ser redondeado al número entero anterior.

11.Evaluación y adjudicación de las ofertas

11.1         Comisión Evaluadora

Las propuestas serán evaluadas por una comisión integrada por al menos 3 funcionarios de la DCCP, nombrados a través de una resolución dictada por la autoridad competente de esta Dirección. La DCCP podrá proveer a la Comisión Evaluadora de la asesoría de expertos en materias específicas.

Excepcionalmente, y de manera fundada, algunos de los integrantes de la Comisión designados por la DCCP, podrán ser personas ajenas a la Administración, aunque siempre en número inferior a los funcionarios públicos que integran dicha comisión.

La designación de la comisión evaluadora se publicará en https://www.mercadopublico.cl. Y sus integrantes deberán registrarse como sujetos pasivos de acuerdo con lo dispuesto en la Ley N°20.730 que regula el lobby y las gestiones que representen intereses particulares ante las autoridades y funcionarios.

Los miembros de la Comisión Evaluadora no podrán:

  • Tener contactos con los oferentes, salvo para la solicitud de aclaraciones y de antecedentes omitidos, en aplicación del artículo 40 del reglamento de la ley N° 19.886. 
  • Aceptar solicitudes de reunión, de parte de terceros, sobre asuntos vinculados directa o indirectamente con esta licitación, mientras integren la Comisión Evaluadora.
  • Aceptar ningún donativo de parte de terceros. Entiéndase como terceros, entre otros, a las empresas que prestan servicios de asesoría, o bien, sociedades consultoras, asociaciones, gremios o corporaciones.

De acuerdo con lo establecido en el artículo 35 nonies de la Ley N° 19.886, los miembros de la Comisión Evaluadora, una vez designados, deberán suscribir una declaración jurada en la que manifiesten, expresamente, la ausencia de conflictos de interés con aquellos oferentes que participen en el procedimiento de licitación, obligándose, además, a guardar la confidencialidad del mismo.

Asimismo, y en virtud de lo preceptuado en el artículo referido, toda persona contratada a honorarios que participe de las funciones de calificación o evaluación en el presente proceso tendrá la calidad de agente público, encontrándose sujeto a responsabilidad administrativa en el desempeño de ellas, sin perjuicio de la responsabilidad civil o penal que corresponda.

Se deja constancia de que son motivos de abstención, aquellas situaciones contempladas en el artículo 35 quinquies de la Ley N° 19.886. Por consiguiente, no podrán tener participación, en comisiones evaluadoras o intervenir en el procedimiento de contratación pública o ejecución contractual en los que puedan tener interés, aquellas autoridades y funcionarios, independientemente de su calidad jurídica, que se encuentren en los casos puntualizados por la norma indicada.

11.2         Procedimiento de evaluación de ofertas

En el procedimiento de evaluación, una vez realizada la apertura electrónica de las ofertas, se verificará lo siguiente:

  • Que las ofertas presentadas cumplan con el envío de los anexos requeridos según las instrucciones de presentación de la oferta establecidas en las presentes bases.

  • Que cumplan con los requerimientos técnicos, administrativos y económicos y las demás condiciones exigidas en estas mismas bases y sus anexos.

Para efectos del proceso de evaluación, la Comisión Evaluadora que haya sido nombrada deberá:

  • Redactar las respectivas actas e informes técnicos y económicos, según corresponda, en las que se consignará el detalle de las evaluaciones y los acontecimientos acaecidos y los resultados de ésta.

  • Analizar las ofertas recibidas y asignar los puntajes respectivos en cada caso, teniendo en consideración el cumplimiento de lo estipulado en estas Bases de Licitación y el Proceso de Evaluación de las Ofertas.

  • Proponer la inadmisibilidad de las ofertas que no cumplan con los requisitos establecidos en las bases.

  • Proponer la deserción del proceso licitatorio, en caso de que no se presenten ofertas admisibles o éstas no sean convenientes a los intereses de la institución.

  • Proponer la adjudicación.

Durante el proceso de evaluación la comisión podría requerir aclaraciones a los oferentes respecto de errores formales en sus respectivas propuestas o solicitar antecedentes omitidos, en los términos del artículo 40 del Reglamento de la Ley N°19.886, y de acuerdo a lo descrito en la cláusula N°11.4 de las presentes bases de licitación. Al ejercer esta facultad, la Comisión Evaluadora no podrá propiciar que los oferentes alteren la esencia de sus ofertas, ni violar los principios de igualdad entre los oferentes y sujeción estricta a las Bases de Licitación.

Si, por motivos de fuerza mayor o caso fortuito, no se pudiere realizar la apertura electrónica de las ofertas, oportunamente ingresadas, la Dirección ChileCompra podrá fijar nueva fecha y hora para la realización.

11.3         Criterios de Evaluación

Todas las ofertas (para ambas líneas de servicio) deberán cumplir con los requisitos técnicos de admisibilidad que se indican en la cláusula N°9.3 de las presentes bases de licitación. De no cumplirse con dichos requisitos técnicos, la respectiva oferta será declarada inadmisible.

Si las ofertas han sido declaradas admisibles, esto es, que cumplen con los requisitos técnicos mínimos dispuestos en estas bases de licitación, se procederá a su evaluación, la que se realizará en una etapa, considerando los siguientes criterios, los cuales serán aplicados de forma independiente por cada línea de servicio.

Criterio

Subcriterio

% Total

Técnico

Experiencia del oferente en proyectos similares (36%)

78%

Certificaciones del oferente (24%)

Calificación del equipo de trabajo (35%)

Programa de integridad (3%)

Sello Empresa Mujer (2%)

Económico

Precio

20%

Administrativo

Cumplimiento de requisitos formales

2%

Al finalizar la evaluación, se sumarán los puntajes ponderados, y se adjudicará de conformidad a lo señalado en la cláusula 11.5 de estas bases de licitación.

11.3.1      Criterio técnico

El puntaje del criterio técnico corresponderá a la suma de los puntajes ponderados de cada uno de los siguientes subcriterios.

A)       Subcriterio Experiencia del oferente en proyectos similares

La evaluación de este subcriterio se realizará según lo expuesto por el oferente en el Anexo N°5 de las presentes bases de licitación.

En dicho Anexo N°5, el oferente deberá declarar su experiencia, la que deberá ser respaldada mediante un documento que acredite la implementación exitosa, utilizando el formato de Anexo N°5.1, o bien, un documento propio que contenga la información mínima ahí contenida.

En caso de que la información solicitad en el Anexo N°5 esté incompleta, se evidencien inconsistencias o la experiencia no sea respaldada, ésta no será considerada en la evaluación. Asimismo, en caso de que la información de respaldo no acredite una implementación exitosa, o bien, esta condición no pueda ser validada, la experiencia no será considerada en la evaluación.

Toda la información entregada por el oferente podrá ser verificada por la Comisión Evaluadora.

Se evaluará la cantidad total de proyectos similares en que hubiera participado el oferente conforme a lo declarado por éste. Los proyectos deberán haber sido finalizados en los últimos cinco años, contados desde la fecha de publicación de las presentes bases de licitación. Para que la experiencia sea contabilizada, solo se considerarán y se entenderán válidos los proyectos con, al menos tres meses de duración y que estén finalizados al momento del publicación de la presentación de ofertas.

Se entenderá como proyectos similares, cualquier proyecto anterior que haya tenido como objeto el desarrollo e implementación de servicios con todas o algunas de las siguientes tecnologías de acuerdo a cada línea de servicio:

  • Línea de servicio N°1: React, JAVA, tecnologías cloud de AWS.
  • Línea de servicio N°2: React, JAVA, contenedores y .NET en el desarrollo de sistemas web.

La asignación de puntajes se realizará considerando la siguiente tabla:

N° Proyectos similares acreditados

Puntaje

10 o más proyectos similares

100

Entre 7 y 9 proyectos similares

80

Entre 4 y 6 proyectos similares

50

Entre 2 y 3 proyectos similares

20

1 o ningún proyecto similar

0

El puntaje total de este subcriterio se dará según el siguiente polinomio:

Puntaje Experiencia del oferente en proyectos similares = Puntaje obtenido * 36%

B)       Subcriterio Certificaciones del oferente

Para la evaluación de este subcriterio, el oferente deberá adjuntar la certificación correspondiente a cada línea de servicio, la que debe especificar claramente el nombre, razón social o RUT del participante en el presente proceso licitatorio y debe encontrarse vigente al momento publicación de la licitación. En caso distinto, se entenderá que no cumple el mencionado requisito con lo cual no se tendrá por presentado el certificado requerido y no se asignará puntaje.

El puntaje que se asignará en este subcriterio para cada línea de servicio es el siguiente:

LÍNEA DE SERVICIO N°1

Tipo de certificación con respaldo

Puntaje

AWS Partner

100

No Presenta ninguna certificación o documento

0

LÍNEA DE SERVICIO N°2

Tipo de certificación con respaldo

Puntaje

ISO 27001

100

No Presenta ninguna certificación o documento

0

La Dirección ChileCompra podrá verificar la validez de estas certificaciones, utilizando para ello las referencias indicadas por el oferente.

El puntaje total de este subcriterio se dará según el siguiente polinomio:

Puntaje Certificaciones del oferente = Puntaje obtenido * 24%

C)       Subcriterio Calificación del equipo de trabajo

Para la evaluación de este subcriterio se considerará lo declarado por el oferente en el Anexo N°5 considerando solamente los profesionales de los perfiles obligatorios indicados en la cláusula 9.3 número 2, que corresponden a: Líder Técnico, Desarrollador Frontend, Desarrollador Backend, Desarrollador AWS, Desarrollador .NET e Ingeniero DevOps.

Para cada uno de estos perfiles se evaluará si posee la experiencia, certificaciones y cursos válidos. En el caso de la experiencia y los cursos, para ser considerados válidos y ser evaluados, deberán haber estado finalizados al momento de publicación de la presente licitación. Por su parte, en el caso de las certificaciones, deberán estar vigentes al momento de publicación de esta licitación.

Las experiencias, certificaciones y cursos que serán evaluados por perfil, se indican a continuación:

       i.          Líder técnico

Evaluable:

-        Experiencia:

                           I.          Contar con experiencia en la búsqueda, evaluación e implementación de productos y soluciones tecnológicas.

                         II.          Contar con experiencia en el diseño de software con buenas prácticas de seguridad y calidad.

                        III.          Contar con experiencia en la creación de Pipelines con Azure DevOps o similares.

                       IV.          Contar con experiencia en manejo de Git / Gitflow.

                         V.          Contar con experiencia desarrollando con DDD (Domain Driven Design).

                       VI.          Contar con experiencia mínima de 1 año en el manejo de Pipelines con Azure DevOps o similares.

                      VII.          Contar con experiencia en Testing (uso de herramientas de automatización de pruebas, test unitarios, pruebas de estrés).

                    VIII.          Contar con experiencia en gestión de proyectos de software.

-        Certificaciones:

                           I.          Certified Scrum Master.

                         II.          Certified Scrum Developer.

                        III.          Contenerización de aplicaciones (Docket, K8S o similares).

                       IV.          Cloud Practitioner, Cloud Developer, Cloud Architect o alguna complementaria.

-        Cursos:

                           I.          Calidad de Software.

                          II.          Desarrollo seguro.

  1. Desarrollador Frontend (ReactJS)

Evaluable:

-        Experiencia:

                           I.          Contar con experiencia en Testing (uso de herramientas de automatización de pruebas, test unitarios).

                          II.          Contar con experiencia en la creación de Pipelines con Azure DevOps o similares. 

                        III.          Contar con experiencia en manejo de Git / Gitflow.

                        IV.          Contar con experiencia en el uso de Styled-components.

                         V.          Contar con experiencia en el uso de Redux.

                        VI.          Contar con experiencia en el uso de ES6.

                      VII.          Contar con experiencia en el uso de Material-ui.

                     VIII.          Contar con experiencia en el uso de HTML5.

                        IX.          Contar con experiencia en el uso de TypeScript.

                          X.          Contar con experiencia en el uso UX/UI.

-        Certificaciones:

                           I.          Certified Scrum Master.

                          II.          Certified Scrum Developer.

-        Cursos:

                           I.          Desarrollo seguro.

                          II.          Calidad de Software.

  1. Desarrollador Backend (Spring boot)

Evaluable:

-        Experiencia:

                           I.          Contar con experiencia en Testing (uso de herramientas de automatización de pruebas, test unitarios, pruebas de estrés)

                         II.          Contar con experiencia desarrollando con DDD (Domain Driven Design).

                        III.          Contar con experiencia en el manejo de Pipelines con Azure DevOps o similares.

                       IV.          Contar con experiencia en el manejo de Git / Gitflow.

                         V.          Contar con experiencia en el manejo de contenedores.

                       VI.          Contar con experiencia en .NET.

-        Certificaciones:

                           I.          Certified Scrum Master.

                         II.          Certified Scrum Developer.

                        III.          Cloud Practitioner, Cloud Developer, Cloud Architect o alguna complementaria.

-        Cursos:

                           I.          Desarrollo seguro.

                         II.          Calidad de Software.

                        III.          Base de datos relacionales y no relacionales.

                       IV.          Contenerización de aplicaciones (Docket, K8S, similar).

                         V.          Java.

  1. Desarrollador AWS

Evaluable:

-        Experiencia

                           I.          Contar con experiencia en Testing (uso de herramientas de automatización de pruebas, test unitarios, pruebas de estrés)

                         II.          Contar con experiencia en el manejo de Pipelines con Azure DevOps o similares.

                        III.          Contar con experiencia en el manejo de Git / Gitflow. 

                       IV.          Contar con experiencia en el manejo de contenedores.

-        Certificaciones

                           I.          AWS SysOps Administrator.

                         II.          AWS Devops Engineer.

-        Cursos

                           I.          Desarrollo seguro.

                         II.          Calidad de Software.

                        III.          Base de datos relacionales y no relacionales.

                       IV.          Contenerización de aplicaciones (Docket, K8S, similar).

  1. Desarrollador .Net

Evaluable:

-        Experiencia

                           I.          Contar con experiencia comprobable en ORM Dapper.

                         II.          Contar con experiencia comprobable en JQuery.

                        III.          Contar con experiencia comprobable en Bootstrap.

                       IV.          Contar con experiencia comprobable en SQL Server y Elastic Search.

                         V.          Contar con experiencia en Testing (uso de herramientas de automatización de pruebas, test unitarios, pruebas de estrés).

                       VI.          Contar con experiencia en el manejo de Git / Gitflow. 

                      VII.          Contar con experiencia comprobable en buenas prácticas de Desarrollo seguro (ej: OWASP Top 10).

                    VIII.          Cuenta con experiencia en el manejo de Pipelines con Azure DevOps o similares.

-        Certificaciones

                           I.          No aplica

-        Cursos:

                           I.          Desarrollo seguro.

                         II.          Calidad de Software.

                        III.          Base de datos relacionales y no relacionales.

  1. DevOps

Evaluables:

-        Experiencia:

                           I.          Contar con experiencia en Testing (uso de herramientas de automatización de pruebas, test unitarios, pruebas de estrés).

                         II.          Contar con experiencia en el manejo de contenedores

-        Certificaciones

                           I.          Cloud Practitioner, Cloud Developer, Cloud Architect o alguna complementaria.

-        Cursos:

                           I.          Desarrollo seguro.

                         II.          Calidad de Software.

                        III.          Base de datos relacionales y no relacionales

                       IV.          Contenerización de aplicaciones (Docket, K8S, similar).

La  cantidad total de experiencias, certificaciones y cursos evaluables mencionados previamente para cada perfil se resumen en la siguiente tabla:

Perfil

Experiencia

Certificaciones

Cursos

Líder Técnico

8

4

2

Desarrollador Frontend (ReactJS)

10

2

2

Desarrollador Backend (Spring boot)

6

3

5

Desarrollador AWS

4

2

4

Desarrollador .NET

8

No aplica

3

Ingeniero DevOps

2

1

4

Para calcular el puntaje de este subcriterio se utilizará el siguiente método:

  1. Puntaje del perfil:

En primer lugar, se validará, de acuerdo con la información proporcionada por el oferente en su Anexo 5 y Anexo 5.2 la cantidad válida de experiencias, certificaciones y cursos por cada uno de los integrantes del equipo según su perfil y se calculará un puntaje para cada profesional de acuerdo con la siguiente fórmula:

Donde:

-        “N” es el nombre del perfil obligatorio requerido en las bases

-        “X” es el número del profesional evaluado. Esto último, debido a que existen perfiles que requieren más de un profesional, según se indica en la cláusula 9.3 número 2.

Las ponderaciones utilizadas en la fórmula anterior se encuentran en la siguiente tabla:

Perfil

Experiencia

Certificaciones

Cursos

Líder Técnico

25%

40%

35%

Desarrollador Frontend (ReactJS)

25%

40%

35%

Desarrollador Backend (Spring boot)

25%

40%

35%

Desarrollador AWS

25%

40%

35%

Desarrollador .Net

70%

No aplica

30%

Ingeniero DevOps

25%

40%

35%

  1. Puntaje total del equipo

El puntaje total del equipo corresponderá al promedio simple de los puntajes obtenidos en el punto anterior, multiplicado por 100, utilizando la siguiente fórmula:

Donde la Cantidad Total de Profesionales por cada línea de servicio está indicada en la cláusula 9.3 número 2.

Para acreditar el cumplimiento de cursos, diplomados y/o certificaciones, el oferente deberá indicar el link a través del formato de Currículum Vitae proporcionado en el Anexo 5.2, o bien, adjuntar los certificados respectivos extendidos por la institución educacional correspondiente.

Ejemplo:

Para simplificar el ejemplo, se trabajará hipotéticamente con un equipo compuesto por 3 perfiles y 4 profesionales para una línea de servicio:

Perfil

Tipo

Cantidades

Resultado

Resultado ponderado

Resultado Perfil

Evaluables

Válidas

Líder técnico

Experiencias 25%

8

4

4/8 = 0,500

0,125

0,875

Certificaciones 40%

4

4

4/4 = 1,000

0,400

Cursos 35%

2

2

2/2 = 1,000

0,350

Desarrollador Frontend N°1

Experiencias 25%

10

8

8/10 = 0,800

0,200

0,775

Certificaciones 40%

2

2

2/2 = 1,000

0,400

Cursos 35%

2

1

1/2 = 0,500

0,175

Desarrollador Frontend N°2

Experiencias 25%

10

10

10/10 = 1,000

0,250

0,625

Certificaciones 40%

2

1

1/2 = 0,500

0,200

Cursos 35%

2

1

1/2 = 0,500

0,175

Desarrollador .NET

Experiencias 70%

8

6

6/8 = 0,750

0,525

0,825

Certificaciones -

No aplica

-

No aplica

No aplica

Cursos 30%

3

3

3/3 = 1,000

0,300

Promedio de los resultados por perfil (A)

0,775

Puntaje Calificación del Equipo (A * 100)

77,5 ptos.

El puntaje total de este subcriterio se dará según el siguiente polinomio:

Puntaje Calificación del Equipo de Trabajo  = Puntaje obtenido * 35%

D)       Subcriterio Programas de integridad

 

Para la evaluación de este criterio, se evaluará si el oferente posee un programa de integridad que sea conocido por su personal, lo cual deberá ser declarado en el Anexo N°6. En caso de que dicho anexo no se presente en conjunto con la oferta presentada, o bien, éste no se encuentre debidamente completado y firmado, se entenderá que el oferente en cuestión no cuenta con un programa de integridad que sea conocido por su personal. Asimismo, también se entenderá que el oferente no cuenta con dicho programa de integridad cuando así lo declare en el anexo referido o cuando no acompañe a su declaración copia del programa de integridad en cuestión, tal como es requerido según lo señalado en el Anexo N°6.

Se entenderá por programas de integridad cualquier sistema de gestión que tenga como objetivo prevenir y si resulta necesario, identificar y sancionar las infracciones de leyes, regulaciones, códigos o procedimientos internos que tienen lugar en una organización, promoviendo una cultura de cumplimiento. 

 

De acuerdo con lo señalado, la asignación de puntajes en este criterio se realizará de acuerdo con lo siguiente:

 

CRITERIO 

PUNTAJE

Posee un programa de integridad que sea conocido por su personal. 

100

No posee un programa de integridad que sea conocido por su personal. 

0

 

En el caso de que una oferta sea presentada por una UTP, para la asignación de puntaje, la totalidad de los integrantes deben cumplir con lo requerido previamente.

 

El puntaje de este subcriterio se dará según el siguiente polinomio:

Puntaje Programas de Integridad = Puntaje obtenido * 3%

 

E)       Subcriterio Sello Empresa Mujer

Para la evaluación de este criterio se verificará el Registro de Proveedores disponible en el Sistema de Información www.mercadopubIico.cl., para verificar que el oferente cuenta con el Sello Empresa Mujer otorgado a proveedores inscritos en www.mercadopublico.cl que se caracterizan por ser liderados por una mujer, en el caso de las personas naturales, o en aquellas empresas que acreditan que más del 50% de la propiedad pertenece a una o más mujeres, o bien, que su representante legal o gerente general sea mujer, cuando se trata de personas jurídicas.

Sello Empresa Mujer

Puntaje

Oferente cuenta con Sello Empresa Mujer, lo cual es verificado en el Registro de Proveedores

100

Oferente no cuenta con Sello Empresa Mujer, lo cual es verificado en el Registro de Proveedores

0

En el caso de que una oferta sea presentada por una UTP, para la asignación de puntaje, se considerará lo informado en el Anexo N°4 respecto a este criterio de evaluación.

El puntaje total de este subcriterio se dará según el siguiente polinomio:

Puntaje Sello Empresa Mujer = Puntaje obtenido * 2%

11.3.2             Criterio económico

A)       Precio

Se considerará el precio total ofertado (con todos los recargos) por los proveedores en su oferta en el Anexo N°7, el cual no podrá superar el presupuesto total disponible conforme a la cláusula N°12.7. En caso de que el valor ofertado supere el presupuesto máximo disponible, la oferta podrá ser declarada inadmisible y no será evaluada.

Luego se aplicará la siguiente fórmula para obtener el puntaje del criterio “Precio”:

Puntaje Precio = 100 x (Precio mínimo / Precio ofertado)

11.3.3     Criterio administrativo

A)       Cumplimiento de requisitos formales

 

El oferente que presente su oferta cumpliendo todos los requisitos formales de presentación de la misma y acompañando todos los antecedentes requeridos en la cláusula 6 “Anexos e instrucciones para la presentación de ofertas” antes del cierre de presentación de oferta obtendrá 100 puntos.

Si el oferente ha incurrido en errores u omisiones formales o se han omitido certificaciones o antecedentes y se aplica lo dispuesto en la cláusula 11.4, resultando subsanadas correctamente en el plazo allí indicado, obtendrá 50 puntos asignados al criterio.

Por último, si el oferente no subsana correctamente errores u omisiones formales, o certificaciones o antecedentes omitidos al momento de presentar su oferta, o lo hace fuera del plazo indicado en la cláusula 11.4, obtendrá 0 puntos en este criterio.

 

El puntaje total de este criterio se dará según el siguiente polinomio:

Puntaje criterio cumplimiento de los requisitos formales = 𝑃𝑢𝑛𝑡𝑎𝑗𝑒 𝑜𝑏𝑡𝑒𝑛𝑖𝑑𝑜 2%

 

11.4         Solicitud de aclaraciones y antecedentes

No se aceptarán ofertas que no contengan toda la información requerida al momento del cierre de la licitación. Con todo, una vez realizada la apertura electrónica de las ofertas, la Dirección ChileCompra podrá solicitar a los oferentes que salven errores u omisiones formales, siempre y cuando las rectificaciones de dichos vicios u omisiones no les confieran a esos oferentes una situación de privilegio respecto de los demás competidores, esto es, en tanto no se afecten los principios de estricta sujeción a las bases y de igualdad de los oferentes, y se informe de dicha solicitud al resto de los oferentes si correspondiere a través del Sistema de Información, https://www.mercadopublico.cl.

Asimismo, la Dirección ChileCompra tiene la facultad de permitir la presentación de certificaciones o antecedentes que los oferentes hayan omitido presentar al momento de efectuar la oferta, siempre que dichas certificaciones o antecedentes se hayan producido u obtenido con anterioridad al vencimiento del plazo para presentar ofertas o se refieran a situaciones no mutables entre el vencimiento del plazo para presentar ofertas y el periodo de evaluación, según lo previsto en el artículo 40, del reglamento de la ley N° 19.886. Los oferentes deberán ingresar todos los antecedentes requeridos en una sola oportunidad dentro del plazo indicado en el siguiente párrafo, por lo tanto, no se considerarán los antecedentes que, sin perjuicio de ser entregados dentro del plazo, se incorporen luego de haberse realizado una primera presentación.

En ambos casos, los oferentes, tendrán un plazo máximo de 48 horas corridas, contados desde la notificación del respectivo requerimiento, para responder a lo solicitado por la DCCP o para acompañar los antecedentes requeridos por ésta. La DCCP no considerará las respuestas o los antecedentes recibidos una vez vencido dicho plazo.

Cabe señalar que la responsabilidad de revisar el “foro inverso”, disponible en http://www.mercadopublico.cl, a través del cual se solicitan los antecedentes y aclaraciones durante el periodo de evaluación, recae exclusivamente en los oferentes.

11.5         Adjudicación

Se adjudicará a un único oferente por cada línea de servicio licitada, al oferente que obtenga el mayor puntaje en la evaluación de las propuestas, en los términos descritos en las presentes bases, y teniendo en consideración lo dispuesto en la cláusula N°11.6 “Mecanismo de resolución de empates” en caso de que dos o más oferentes se encuentren en condiciones de adjudicar.

Si un proveedor oferta a más de una línea de servicio y, una vez evaluado, obtiene el mejor puntaje en ambas líneas, se compararán sus ofertas de acuerdo con el siguiente orden y se le adjudicará la línea de servicio que obtengan mayor puntaje en relación con las demás líneas de su oferta:

  1. Lugar Subcriterio Experiencia oferente
  2. Lugar Subcriterio Certificaciones del oferente
  3. Lugar Subcriterio Cantidad de perfiles con certificación

En último caso, y en caso de que no puedan priorizarse las líneas a adjudicar al oferente en cuestión (respecto de las líneas de servicio en que haya obtenido el mejor puntaje), en virtud de las reglas de priorización anteriormente descritas, le será adjudicada la línea de servicio que tengan el mayor monto total para el proveedor, siendo la línea restante adjudicada al oferente que le siguiese en puntaje en la línea respectiva.

La DCCP, mediante la dictación de una resolución fundada de su Director(a) o de quien corresponda según normativa interna de la Dirección ChileCompra, podrá:

  1. En conformidad al artículo 9° de la Ley N° 19.886, la DCCP, mediante resolución fundada, declarar inadmisibles las ofertas que no cumplan con lo requerido en las bases de licitación, o bien, declarar desierta la licitación, cuando no se recibieran ofertas admisibles o cuando ninguna de las ofertas admisibles resultare convenientes a sus intereses.

  1. Adjudicar al oferente que obtuvo el mayor puntaje para cada línea de servicio, de acuerdo con los criterios de evaluación establecidos precedentemente.

La presente licitación se adjudicará a través de una resolución dictada por la DCCP, la que será publicada en www.mercadopublico.cl, una vez que se encuentre totalmente tramitada.

En el caso de que la DCCP no realice la adjudicación dentro del plazo definido en las presentes Bases de licitación, aquélla informará a través del Sistema http://www.mercadopublico.cl dicho cambio, justificando la imposibilidad de cumplir con el plazo antes señalado y asimismo indicando el nuevo plazo para la adjudicación, según lo que indica el artículo 41, del Reglamento de la Ley N°19.886.

11.6         Resolución de empates

                          

En caso de que luego de realizado el proceso de evaluación de ofertas, hubiese dos o más postulantes que hayan obtenido el mismo puntaje máximo en una misma línea, quedando ambos en condiciones de ser adjudicados, se optará por aquella oferta que cuente con un mayor puntaje en los siguientes criterios, según orden de prelación definido a continuación:

  1. Precio
  2. Experiencia en proyectos similares
  3. Calificación del equipo de trabajo
  4. Certificaciones del oferente
  5. Cumplimiento de requisitos formales
  6. Sello empresa mujer

Finalmente, si aún persiste el empate, se seleccionará a la propuesta que ingresó primero en el portal www.mercadopublico.cl

11.7         Notificación de adjudicación

Una vez que se encuentre totalmente tramitada la resolución de adjudicación, se procederá a notificar dicha decisión a los oferentes, mediante su publicación en el sistema www.mercadopublico.cl en el respectivo ID. Luego de notificada la resolución, en caso de ser adjudicada la licitación, se suscribirá el respectivo contrato dentro de los plazos señalados en las presentes Bases. Cabe recordar que, de acuerdo con el artículo 6 del reglamento de la ley N° 19.886, el acto administrativo de adjudicación se entenderá notificado transcurridas 24 horas contadas desde su publicación en el portal https://www.mercadopublico.cl.

11.8         Mecanismo para solución de consultas respecto de la adjudicación

Las consultas respecto de la adjudicación podrán ser remitidas, en el plazo de 5 días hábiles contados desde la publicación de la resolución de adjudicación, a través de la página web https://ayuda.mercadopublico.cl/, indicando el ID de la presente licitación. La respuesta será derivada al correo electrónico del interesado dentro de los 10 días hábiles contados desde el término del plazo para realizar las consultas.

11.9         Readjudicación

Si el respectivo adjudicatario se desistiere de su oferta, de firmar el contrato, no se inscribiese en el Registro Proveedores de Mercado Público, o no cumpliere los demás requisitos establecidos en las bases para la suscripción del contrato, en los plazos que se establecen en las presentes Bases, la DCCP podrá, junto con dejar sin efecto la adjudicación original, readjudicar la licitación al oferente que, de acuerdo al resultado de la evaluación, le siga en puntaje y cumpla los requisitos establecidos en las presentes bases, y así sucesivamente, dentro del plazo de 30 días corridos contados desde la publicación de la adjudicación original, a menos que, de acuerdo a los intereses del servicio, se estime conveniente declarar desierta la licitación.

12.Condiciones contractuales y otras cláusulas.

12.1         Suscripción del contrato

 

El respectivo contrato deberá suscribirse dentro de los 10 días hábiles siguientes a la notificación de la resolución de adjudicación totalmente tramitada. Para suscribir el contrato, el proveedor o los proveedores deberán acompañar la garantía de fiel cumplimiento del contrato.

 

Si por cualquier causa que no sea imputable a la Dirección ChileCompra, el respectivo adjudicatario no se inscribe en el Registro de Proveedores, no presenta los antecedentes legales para contratar o las garantías de fiel cumplimiento del contrato, o bien, no suscribe el correspondiente contrato dentro de los plazos establecidos en las presentes bases, la Dirección ChileCompra entenderá por desistida la oferta, pudiendo dar aplicación a la cláusula de readjudicación de las presentes bases y ejecutar la garantía de seriedad de la oferta, de conformidad con lo establecido en la cláusula N° 8.1.3

 

12.2         Vigencia y renovación del contrato.

12.2.1     Vigencia del contrato

El contrato comenzará a regir desde la total tramitación de la resolución que lo apruebe y su vigencia se extenderá por 12 meses.

Sin perjuicio de lo anterior, y por razones del buen servicio, podrán comenzar a ejecutarse los servicios a contar de la fecha de suscripción del contrato respectivo, con anterioridad a la total tramitación del acto administrativo.

Sin embargo, queda expresamente establecido que no se podrá realizar pago alguno sin la total tramitación del referido acto administrativo y la respectiva recepción conforme de los servicios.

12.2.2     Renovación

La Dirección ChileCompra podrá renovar el contrato por una sola vez, según las necesidades institucionales y dependiendo de la calidad, eficiencia y efectividad del proveedor durante la ejecución del contrato. En el caso que el Administrador de Contrato solicite a la Dirección acogerse a esta opción de renovación, deberá dar cuenta de los siguientes antecedentes:

  • Informe de evaluación del contrato que acredite el buen desempeño y cumplimiento del servicio adjudicado, realizado por el Administrador de Contrato.
  • Certificado de disponibilidad presupuestaria para la renovación del contrato.

Cumplidas estas condiciones, deberá dictarse un acto administrativo que autorice la referida renovación, debiendo el proveedor entregar una nueva garantía de fiel cumplimiento que cubra el nuevo período de vigencia más 60 días hábiles posteriores a su término.

Los motivos fundados para establecer esta cláusula de renovación, según lo exigido por el artículo 12 del reglamento de la Ley N°19.886, son los siguientes:

 

       i.          Dar continuidad al desarrollo de las soluciones para cumplir con los requerimientos objeto de la modernización de la Ley de Compras Públicas.

      ii.          Se dispone de los recursos para la renovación.

     iii.          Informe de servicio satisfactorio por parte del administrador del contrato.

12.3         Lugar, horarios y plazo para la ejecución de los servicios

 

12.3.1     Lugar y horarios para la ejecución de los servicios

Los profesionales del equipo de trabajo podrán prestar los servicios remotamente, sin tener la obligación de concurrir a las oficinas de la Dirección ChileCompra, salvo que sea requerido por ésta en forma excepcional y por ser ello imprescindible para el avance de los servicios, en cuyo caso, los valores de traslado y alojamiento deberán ser asumidos por el proveedor.

 

Para la ejecución de los servicios, se deberá tener en consideración lo siguiente:

a)      La ejecución de las actividades que no requieran participación de los equipos de la Dirección ChileCompra serán realizadas en los días y horas acordados entre las partes, ) , privilegiándose que se trate de días y horarios hábiles del país en que resida cada profesional, sin perjuicio de lo señalado en el literal c) de esta cláusula.

b)     Los horarios en que se establezcan reuniones de coordinación, reporte de estado de avance o cualquier instancia de trabajo que requiera contar con los equipos (o parte de ellos) del adjudicatario y la Dirección ChileCompra, deberán establecerse en días hábiles administrativos chilenos, esto es, de lunes a viernes, excluyendo sábados, domingos y festivos. Para estos efectos, se deberán considerar solamente los feriados nacionales en territorio chileno. En cuanto al horario de estas actividades, se realizarán en base a la zona horaria oficial de Chile durante la ejecución del proyecto.

Se deja establecido que los horarios hábiles de trabajo son de lunes a jueves entre las 09:00 y las 18:00 horas, y los viernes de 09:00 a 17:00 horas.

c)      Los pasos a producción podrán realizarse dentro o fuera del horario hábil ya señalado dependiendo de la disponibilidad técnica y/o de profesionales que exista al momento del paso a producción y de las exigencias de la plataforma. El paso a producción será planificado durante la implementación, quedando reflejado en el Cronograma de Trabajo, y deberá contar con el apoyo del proveedor adjudicado. Asimismo, desde el momento en que el desarrollo queda en producción, comienza a regir el periodo de garantía ofertado sobre su desarrollo.

d)     En el caso que los profesionales ejercieran las labores señaladas en los puntos anteriores fuera de los días y horarios hábiles señalados en el literal b), el proveedor no podrá aumentar la tarifa por hora.

12.3.2     Plazos referenciales de la ejecución de los servicios

 

Las soluciones requeridas, deberán ser desarrolladas durante la vigencia del contrato señalada en la cláusula N°12.2, siendo el plazo máximo de Go Live de la totalidad de las soluciones de ambas líneas de servicio el 11 diciembre de 2024. No obstante, a modo referencial, a continuación se indica la cantidad de meses por solución que podrán considerarse dentro del Cronograma de Trabajo. Cabe mencionar que no son meses correlativos, puesto que, conforme a la planificación, algunos de ellos podrán traslaparse durante la ejecución:

 

-        Línea  de Servicio 1:

Solución

Cantidad de meses

Creación de nuevos compradores en Mercado Público

5,00

Ficha del organismo comprador

3,00

Información de compradores en los procesos de compra

2,50

Integración con información del Tribunal de Contratación Pública

3,00

-        Línea de Servicio 2:

Solución

Cantidad de meses

Actualización “Trato Directo”

6,00

Actualización “Compra Ágil”

7,5

Incorporación del mecanismo de compra “Diálogos competitivos”

6,00

Incorporación del mecanismo de compra “Contratos para la innovación”

6,00

12.4         Modificación del contrato.

El contrato podrá modificarse de mutuo acuerdo entre las partes, o bien, unilateralmente por la Dirección ChileCompra en caso de exigirlo el interés público o la seguridad nacional, lo que deberá ser debidamente justificado.

La modificación no podrá superar el 30% del valor total del respectivo contrato ni alterar su naturaleza, objeto o elementos esenciales, debiendo ser autorizada por el correspondiente acto administrativo. Asimismo, si fuere procedente, deberá contarse con el certificado de disponibilidad presupuestaria. En el caso que la modificación implique un aumento de plazo del contrato, el proveedor deberá entregar una nueva garantía de fiel cumplimiento, cuya vigencia no podrá ser inferior a 60 días hábiles posteriores a la fecha de término del contrato.

Cabe señalar que, frente a una eventual modificación de contrato en donde se requiera ampliar la cantidad de horas a ejecutar, se deberá respetar el valor unitario ofertado por el proveedor adjudicado en su oferta económica.

La modificación, si la hubiere, formará parte integrante de dicho contrato y deberá tramitarse totalmente antes que culmine la vigencia del contrato que se desea modificar, manteniendo, en lo no modificado, las condiciones contractuales previamente consensuadas.

12.5         Obligaciones del adjudicatario.

El adjudicatario, ya sea persona natural o persona jurídica, se obliga a:

  • Cumplir con las instrucciones que sean impartidas por la DCCP a través del administrador del contrato o quien lo subrogue o reemplace.
  • Participar en las reuniones fijadas por la DCCP a través del administrador del contrato o su subrogante.
  • Prestar los servicios requeridos en los términos expuestos en la cláusula N°9 de las presentes bases.
  • Cumplir las demás obligaciones que impone el presente instrumento.

12.6         Efectos derivados de incumplimiento del proveedor.

12.6.1     Multas

a)     Multas por atraso injustificado.

Al proveedor adjudicado se le aplicarán multas por el incumplimiento de los plazos comprometidos, en consideración al Cronograma de Trabajo vigente.

Las multas por atraso se calcularán sobre el valor total bruto que correspondiese pagar por el hito con demora en la entrega, de la siguiente forma:

-      Actividades programadas:

 

  • En el caso de que existan reuniones programadas conforme al Cronograma de Trabajo y ocurra un atraso injustificado, que implique más de 30 minutos en el inicio programa o no presentación a una reunión programada, y cuya responsabilidad sea atribuible al proveedor, se le notificará una No Conformidad. Cada vez que el proveedor reúna tres no conformidades durante la vigencia del contrato, se le aplicará una multa de 1 UF.
  • En caso de incumplimiento en la entrega de la totalidad de los Acuerdos de Confidencialidad, se aplicará una multa de 1 UF por cada día de atraso, hasta completar 10 días hábiles.
  • Entre 1 y 10 días hábiles de retraso en la finalización de una actividad programada según Cronograma de Trabajo, se aplicará una multa de 1 UF por cada día de atraso de responsabilidad del proveedor, aplicando esta multa desde el primer día de atraso y hasta el décimo día.
    • Entre 11 y 20 días hábiles, se aplicará una multa de 2 UF por cada día de atraso de responsabilidad del proveedor, aplicando esta multa desde el onceavo día de atraso y hasta el vigésimo día.
    • Entre 21 días hábiles o más de atraso injustificado: Constituirá causal de término anticipado del contrato el atraso que supere los 20 días hábiles en relación con el tiempo señalado en el cronograma general de trabajo.

b)     Niveles de servicio.

Al proveedor adjudicado se le aplicarán las siguientes multas por atraso relativas a los SLA comprometidos durante las actividades del servicio:

SLA

NIVEL REQUERIDO

MONTO DE MULTA

Respuesta incidencia invalidante (estimación de esfuerzos y plazos)

1 día hábil desde el requerimiento formal.

0,5 UF por día de atraso con un tope de 20 días.

Respuesta incidencia no invalidante (estimación de esfuerzos y plazos)

3 días hábiles desde el requerimiento formal.

0,5 UF por día de atraso con un tope de 20 días.

c)      Multas por incumplimientos asociados a la garantía del software.

Se cobrará al adjudicatario el pago de una multa de 10% del total del contrato por la no reparación de fallas del software original o sus reparaciones posteriores a la implementación, de acuerdo con su oferta y/o lo establecido como requisito mínimo, en la cláusula 9.3 número 1.

Esta multa no aplica para aquellas fallas de software proporcionado por el comprador al proveedor propias de su naturaleza o cuya causa raíz no sea identificable o de serlo no sea atribuible al proveedor.


Asimismo, se aplicarán multas por incumplimiento de los niveles de servicio, considerando factores como tiempo de indisponibilidad, tiempo de respuesta o de solución, número de incidentes o por cada evento.

Las referidas multas, en total, no podrán sobrepasar el 20% del valor total del contrato. En caso de que se supere el 20%, se configurará una causal de término anticipado del contrato.


Reglas comunes a las multas:

Las multas deberán ser pagadas por el proveedor en el plazo máximo de 10 días hábiles contados desde la notificación de la resolución que aplica la multa o de la resolución que rechaza recurso de reposición, en caso de haberse presentado, según el procedimiento que se detalla en la cláusula N°12.6.4 de estas bases. En caso de que no se pague dentro de dicho plazo, se procederá al cobro a través de la o las garantías de fiel cumplimiento, haciéndose pagadera la multa solo respecto de aquella parte que cubre el valor de esta, debiéndose restituir la diferencia al adjudicado. En este último caso, en la medida que la garantía cobrada esté vigente, el proveedor adjudicado deberá reponer la garantía por igual monto y por el mismo plazo de vigencia que la que reemplaza dentro de 10 días hábiles desde la notificación del cobro.

La transformación de la UF, según sea la multa aplicada, a pesos chilenos se realizará considerando el valor de dicha unidad a la fecha de la total tramitación de la resolución que aplica la multa.

Cuando el cálculo del monto de la respectiva multa en pesos chilenos resulte un número con decimales, éste se redondeará al número entero siguiente en caso de que la primera cifra decimal sea igual o superior a 5. En caso contrario, el monto deberá ser redondeado al número entero anterior.

No se considerarán como incumplimientos aquéllos que sean producto de hechos o circunstancias no imputables al Proveedor o que estén fuera de su control de acción. Por lo tanto, para el efecto del cálculo de las multas, sólo se considerarán eventos que sean de responsabilidad del Adjudicatario o que estén dentro de su control.

Las multas se aplicarán sin perjuicio del derecho de la DCCP de recurrir ante los Tribunales Ordinarios de Justicia, a fin de hacer valer la responsabilidad del contratante incumplidor.

Con todo, si las multas cursadas superan el 20% del monto total del contrato, la Dirección ChileCompra pondrá término anticipado al contrato y dará curso al cobro de la garantía de fiel cumplimiento del contrato.

Las medidas aplicadas al proveedor serán publicadas y consideradas dentro del cálculo del comportamiento contractual dispuesto en la plataforma para conocimiento de todos los compradores del Estado.

12.6.2     Cobro de garantía de fiel cumplimiento del contrato

La garantía de fiel cumplimiento de contrato podrá ser cobrada en los siguientes casos:

  1. Incumplimiento de las obligaciones laborales y sociales del adjudicatario con sus trabajadores.
  2. Cuando el respectivo proveedor adjudicado no pague las multas aplicadas dentro del plazo de 10 días desde la notificación de la resolución que aplica la multa o de la resolución que rechaza recurso de reposición, en caso de haberse presentado.
  3. Incumplimiento de las obligaciones impuestas por las presentes Bases, imputable al proveedor, siempre y cuando dicho incumplimiento no importe una causal de aplicación de otra medida.
  4. Cuando por una causa imputable al respectivo adjudicatario, se haya puesto término anticipado al correspondiente contrato en los casos señalados en la cláusula N°12.6.3 de estas bases, con las excepciones allí señaladas.

En caso de cobro de esta garantía derivado del incumplimiento de cualquiera de las obligaciones que imponen estas bases y/o el respectivo contrato, el proveedor deberá reponer la garantía por igual monto y por el mismo plazo de vigencia que la que reemplaza, dentro de los 10 días hábiles siguientes contados desde la notificación de su cobro.

En el caso de que el proveedor no reponga dicha garantía dentro de dicho plazo, se procederá en conformidad a lo establecido en la cláusula N°12.6.3, número 11, de las presentes bases.

12.6.3     Término anticipado del contrato

 

La DCCP está facultada para declarar administrativamente el término anticipado del contrato, en cualquier momento, sin derecho a indemnización alguna para el adjudicado, si concurre alguna de las causales que se señalan a continuación:

        i.          Cuando de común acuerdo, la DCCP y el respectivo adjudicatario resuelvan poner término al contrato.

      ii.          El incumplimiento grave de las obligaciones contraídas por el contratante, siempre que sea imputable a éste. Se entenderá por incumplimiento grave la no ejecución o la ejecución parcial por parte del adjudicatario de las obligaciones contractuales, descritas en las presentes Bases, sin que exista alguna causal que le exima de responsabilidad, y cuando dicho incumplimiento le genere a la entidad licitante perjuicio en el cumplimiento de sus funciones.

 

     iii.          Si el adjudicado se encuentra en estado de notoria insolvencia o fuere declarado deudor en un procedimiento concursal de liquidación. En este caso no procederá el término anticipado si se cauciona suficientemente el incumplimiento del contrato. Este numeral es sin perjuicio de lo dispuesto en la Ley N°20.720 que sustituye el régimen concursal vigente por una ley de reorganización y liquidación de empresas y personas y perfecciona el rol de la Superintendencia del ramo. En el caso de una UTP (Unión Temporal de Proveedores) aplica para cualquiera de sus integrantes.

     iv.          Por exigirlo el interés público o la seguridad nacional, razones de ley o de la autoridad ministerial de Salud, dictadas en caso de epidemias, pandemias u otras emergencias sanitarias en el país, que hagan imperiosa su inmediata terminación, debidamente justificado.

      v.          Registrar saldos insolutos de remuneraciones o cotizaciones de seguridad social con sus actuales trabajadores o con trabajadores contratados en los últimos dos años, a la mitad del período de ejecución del contrato, con un máximo de seis meses.

     vi.          Si se disuelve la empresa adjudicada, o la UTP adjudicada o alguno de los integrantes de la UTP adjudicada; o se retira alguno de los integrantes de la UTP adjudicada.

   vii.          Incumplimiento de uno o más de los compromisos asumidos por el adjudicatario, en virtud del “Pacto de integridad” contenido en estas bases.

  viii.          Sin perjuicio de lo señalado en el “Pacto de integridad”, si el proveedor adjudicado, sus representantes, o el personal dependiente de aquél, no observaren el más alto estándar ético exigible, durante la ejecución del respectivo contrato, o propiciaren prácticas corruptas, tales como:

a)      Dar u ofrecer obsequios, regalías u ofertas especiales al personal adscrito a la Dirección ChileCompra, que pudiere implicar un conflicto de intereses, presente o futuro, entre el respectivo proveedor y la Dirección ChileCompra.

b)     Dar u ofrecer cualquier cosa de valor con el fin de influenciar la actuación de un funcionario público durante la ejecución de los servicios objeto de la presente licitación.

c)      Tergiversar hechos, con el fin de influenciar la ejecución del Contrato.

     ix.          No renovación oportuna de la garantía de fiel cumplimiento del contrato en los plazos y condiciones establecidas en estas bases.

      x.          En caso de incumplimiento de la cláusula N°12.20 “Cesión de contrato y subcontratación” de las presentes bases de licitación.

     xi.          En caso de incumplimiento de la cláusula N°12.9 “Confidencialidad” de estas bases de licitación.

   xii.          Si se detectan situaciones en donde la información proporcionada por el proveedor sea falsa, situación que deberá ser comprobada objetivamente, siendo esta información utilizada para adjudicar la presente licitación. Asimismo, la comprobación de la falta de idoneidad, de fidelidad o de completitud de los antecedentes aportados por el proveedor adjudicado, para efecto de ser adjudicado o contratado.

  xiii.          La comprobación de que el adjudicatario, al momento de presentar su oferta contaba con información o antecedentes relacionados con el proceso de diseño de las respectivas bases, encontrándose a consecuencia de ello en una posición de privilegio en relación con el resto de los oferentes, ya sea que dicha información hubiese sido conocida por el proveedor en razón de un vínculo laboral o profesional entre éste y la entidad licitante, o bien, como resultado de prácticas contrarias al ordenamiento jurídico.

  xiv.          En el caso que la aplicación de multas supere el 20% del monto total del contrato, según lo señalado en la cláusula N°12.6.1 de estas bases.

   xv.          Perder la condición de hábil en el Registro de Proveedores del Estado por causal de inhabilidad sobreviniente establecida en el artículo 4° inciso 1° de la ley de compras. En el caso de una UTP, aplicará si esa condición sobreviene a cualquiera de sus integrantes.

  xvi.          Cuando se verifique un atraso en el cumplimiento de las obligaciones contractuales que supere los 20 días hábiles, establecidos en la cláusula N°12.6.1, letra a), de las presentes bases.

  1. Cuando el proveedor incumpla las obligaciones establecidas en la cláusula N°9.4 número 2 de estas bases, sobre “Equipo de trabajo”, poniendo en riesgo la continuidad del servicio.

  1. Cuando el proveedor se niegue a acreditar el cumplimiento de sus obligaciones laborales y previsionales en cuatro oportunidades, de conformidad con lo establecido en la cláusula N°12.23 sobre “Acreditación de cumplimiento de remuneraciones o cotizaciones de seguridad social y cumplimiento de normas laborales”.

  xix.          Si se impusiere al proveedor la medida de inhabilitación para contratar con el Estado, en los términos previsto en la Ley N°21.595 de Delitos Económicos. Esta causal de término anticipado de convenio marco también será aplicable a los proveedores personas jurídicas, sociedades, corporaciones o fundaciones que mantengan entre sus socios, accionistas, miembros o partícipes con poder de influir en la administración a personas naturales condenadas a la medida de inhabilitación de contratar con el Estado de acuerdo con lo establecido en el artículo 33 de la ley N°21.595.

En los casos señalados, con excepción de los numerales 1 y 4, además del término anticipado del contrato, se procederá al cobro de la garantía de fiel cumplimiento del contrato.

 

Resuelto el Término Anticipado del Contrato, no operará indemnización alguna para el adjudicatario, debiendo la DCCP concurrir al pago de las obligaciones ya cumplidas que se encontraren insolutas a la fecha de liquidación del contrato.

 

Para la aplicación de todas las causales de término anticipado previamente señaladas, salvo la del N°1, procederá el procedimiento de aplicación de medidas regulado en las presentes bases.

12.6.4     Procedimiento para la aplicación de medidas derivadas de incumplimientos

A continuación, se detalla el procedimiento asociado a la aplicación de las respectivas sanciones:

a)      Detectada una situación que amerite la aplicación de multa, cobro de garantía o el término anticipado del contrato (por alguna causal distinta de la establecida en el numeral 1 de la cláusula N°12.6.3), el administrador del respectivo contrato, designado por la DCCP, notificará al proveedor adjudicado, mediante correo electrónico del contacto proporcionado en Anexo N°1 “Formulario Datos del Oferente”, o en su defecto, personalmente o a través de carta certificada, informándole sobre la medida a aplicar y sobre los hechos en que aquélla se motiva.

b)     A contar de la notificación singularizada en el número anterior, el proveedor tiene un plazo de 5 días hábiles para efectuar sus descargos por escrito ante el administrador del correspondiente contrato, acompañando todos los antecedentes que respalden su posición, mediante correo electrónico dirigido al administrador del contrato, o bien, a través de la Oficina de Partes de la DCCP.

c)      Vencido el plazo indicado en el número anterior sin que se hayan presentado descargos, se aplicará la correspondiente medida por medio de una resolución fundada de la DCCP, la que deberá ser notificada al proveedor del modo indicado en el literal a).

d)     Si el adjudicado ha presentado descargos dentro del plazo establecido para estos efectos, esta Dirección tendrá un plazo de 30 días hábiles, contados desde la recepción del descargo del proveedor, para rechazarlos o acogerlos, total o parcialmente. Al respecto, el rechazo total o parcial de los descargos del respectivo proveedor deberá formalizarse a través de la dictación de una resolución fundada de la DCCP, en la cual deberá detallarse el contenido y las características de la sanción a aplicar. La indicada resolución deberá notificarse al respectivo proveedor adjudicado de la misma forma indicada en el literal a).

 

e)     Recurso de Reposición: El proveedor adjudicado dispondrá de un plazo de 5 días hábiles, contados desde la notificación de la resolución fundada, en la forma dispuesta en el literal a), para impugnar dicho acto administrativo, debiendo acompañar todos los antecedentes que justifiquen eliminar, modificar o reemplazar la respectiva sanción. La DCCP tendrá un plazo no superior a 30 días hábiles para resolver el citado recurso. Mientras se encuentre pendiente la resolución del recurso de reposición, no se hará efectiva la respectiva sanción.

f)       La resolución que acoja el recurso podrá modificar, reemplazar a dejar sin efecto el acto impugnado. Ahora bien, en el evento de que la medida aplicada sea una multa, el proveedor deberá pagar directamente a la DCCP dentro del plazo de 10 días hábiles a partir de la notificación de la resolución que acoja parcialmente o rechace el recurso, y en caso de no pagar dentro de dicho plazo, el cobro se hará efectivo a través de la ejecución de la o las garantías de fiel cumplimiento, en los términos señalados en la cláusula N°12.6.2 de estas bases.

Consideraciones respecto a las notificaciones:

Aun cuando la regla general en materia de notificaciones es que éstas se realicen personalmente o por carta certificada, las partes pueden convenir que la notificación se realice por medios electrónicos. En tal sentido, se notificará por correo electrónico únicamente a los proveedores que presentaron el Anexo N°3 “Declaración jurada para autorización de notificaciones”, autorizando dicho medio de notificación. A quienes no hayan presentado tal autorización, se les notificará personalmente o por carta certificada.

Las notificaciones por carta certificada se entenderán practicadas a contar del tercer día siguiente a su recepción en la oficina de Correos que corresponda.

Sin perjuicio de lo antes expuesto, si durante la vigencia del contrato entra en vigor la Ley N°21.180 de Transformación Digital Del Estado, que permite la notificación electrónica de los procedimientos administrativos, las notificaciones que se disponen en el presente procedimiento se podrán realizar a través del módulo de gestión de contratos del Sistema de Información www.mercadopublico.cl.

12.7         Presupuesto máximo disponible

El presupuesto máximo disponible para esta contratación se encuentra descrito en la siguiente table, incluidos todos los impuestos que procedan.

En el caso que la oferta supere este monto, podrá ser declarada inadmisible.

N° Línea de Servicio

Soluciones de la plataforma Mercado Público

Presupuesto disponible (Pesos)

Línea de servicio N°1

  • Creación de nuevos compradores en Mercado Público
  • Ficha del organismo comprador
  • Información de compradores en los procesos de compra
  • Integración con información del Tribunal de Contratación Pública

433.510.000

Línea de servicio N°2

  • Actualización “Trato Directo”
  • Actualización “Compra Ágil”
  • Incorporación del mecanismo de compra “Diálogos Competitivos”
  • Incorporación del mecanismo de compra “Contratos para la Innovación”

530.290.000

12.8         Pagos

La forma de pago de los servicios contratados será la siguiente:

En cuanto a las horas ejecutadas para actividades relativas en el marco de los servicios licitados descritos en la cláusula N°9.2, éstas se pagarán en forma mensual con posterioridad a la recepción conforme del Administrador de Contrato del informe de reporte de horas hombre efectivamente ejecutadas por cada uno de los profesionales, que debe remitir el proveedor dentro de los cinco primeros días del mes posterior a la ejecución de las horas.  Este informe deberá, además, dar cuenta del cumplimiento de las tareas y o los avances de estas, encomendados por esta Dirección para el periodo respectivo.

Una vez realizada la recepción conforme del reporte de horas y el informe de tareas, por parte del administrador del contrato, el proveedor podrá emitir la factura correspondiente y entregarla en las oficinas de la DCCP para su pago. Cabe señalar que esta Dirección pagará al proveedor sólo las horas/hombre que hayan sido efectivamente ejecutadas.

Conforme señala la Ley N° 21.131, el pago será efectuado por esta Dirección dentro de los 30 días corridos siguientes a la recepción de la respectiva factura o instrumento tributario de cobro, la que deberá emitirse solo una vez que se hayan recepcionado conforme los bienes y/o servicios.

Con todo, para proceder al pago se requerirá que previamente esta Dirección certifique la recepción conforme de los bienes y servicios adquiridos dentro del plazo establecido en el artículo 3° de la Ley N° 19.983.

La Dirección de Compras y Contratación Pública pagará en pesos chilenos. En caso de que el precio no esté en pesos chilenos, el monto a facturar será el precio de los servicios adquiridos, convertidos a pesos chilenos según el valor de la conversión correspondiente a la fecha de emisión de la factura, no procediendo ningún otro cobro adicional por servicios no convenidos, ni por tiempos en que por alguna razón el proveedor no presta un servicio. Cabe señalar que, cuando el resultado del monto a facturar resulte un número con decimales, éste se redondeará al número entero siguiente en caso de que la primera cifra decimal sea igual o superior a 5. En caso contrario, el monto deberá ser redondeado al número entero anterior.

El proveedor podrá presentar su documento de cobro tributario a la Dirección ChileCompra sólo una vez que ésta haya hecho recepción conforme formal del servicio comprometido en el hito de pago correspondiente. El documento de cobro deberá ser enviada a dipresrecepcion@custodium.com.

Para tramitar el pago de la prestación de los servicios efectivamente prestados, el adjudicatario deberá entregar a la Dirección ChileCompra, en formato físico o electrónico, junto con cada documento tributario de cobro, lo siguiente:

  • Informe del Producto con la recepción conforme de los servicios prestados y entregados, firmado por parte del Administrador del Contrato.
  • En caso de que corresponda, un Informe de aplicación de multas.
  • “Certificado de Cumplimiento de Obligaciones Laborales y Previsionales (Ley de Subcontratación)” de la Dirección del Trabajo, que indique que no registra saldos insolutos de remuneraciones o cotizaciones de seguridad social con sus actuales trabajadores asignados para la ejecución de este servicio.
  • Las Liquidaciones de sueldo de los trabajadores que prestan el servicio a la Dirección ChileCompra, correspondiente al mes anterior del cual se procede al pago, debidamente firmado por cada trabajador.

La Dirección ChileCompra deberá revisar los antecedentes presentados.

Los montos por pagar son totales, por ello, los oferentes deberán contemplar los valores como brutos, con todos los impuestos o recargos de otra naturaleza. De este modo, el establecimiento de los valores totales, incluyendo los eventuales impuestos en caso de proceder, es de exclusiva responsabilidad del oferente, no pudiendo luego agregar ningún recargo a la DCCP.

Sin perjuicio de lo anterior, en caso de término anticipado, se pagará sólo el monto correspondiente a los trabajos efectivamente realizados y a los plazos efectivamente trabajados, previa liquidación del contrato.

Los pagos serán realizados con transferencia electrónica. En el caso que el proveedor no posea cuenta alguna, debe darlo a conocer por escrito a la DCCP para así realizar el pago mediante cheque.

El pago de los productos será en pesos chilenos. Cuando el resultado del monto a facturar sea un número con decimales, se redondeará al número entero siguiente en caso de que la primera cifra decimal sea igual o superior a 5. En caso contrario, el monto deberá ser redondeado al número entero anterior.

12.9         Confidencialidad

El adjudicatario no podrá utilizar para ninguna finalidad ajena a la ejecución del contrato, la documentación, los antecedentes y, en general, cualquier información, que haya conocido o a la que haya accedido, en virtud de cualquier actividad relacionada con el contrato.

El adjudicatario, así como su personal dependiente que se haya vinculado a la ejecución del contrato, en cualquiera de sus etapas, deben guardar confidencialidad sobre los antecedentes relacionados con el desarrollo de los servicios.

El adjudicatario debe adoptar medidas para el resguardo de la confidencialidad de la información, reservándose el órgano comprador el derecho de ejercer las acciones legales que correspondan, de acuerdo con las normas legales vigentes, en caso de divulgación no autorizada, por cualquier medio, de la totalidad o parte de la información referida.

La divulgación, por cualquier medio, de la totalidad o parte de la información referida en los párrafos anteriores, por parte del proveedor, durante la vigencia del contrato o dentro de los 5 años siguientes después de finalizado éste, podrá dar pie a que la Entidad entable en su contra las acciones judiciales que correspondan. Con todo, tratándose de bases de datos de carácter personal, la obligación de confidencialidad dura indefinidamente, de acuerdo con la Ley N°19.628, sobre Protección de la Vida Privada.

12.10      Propiedad de la información

La entidad licitante será la titular de todos los datos de transacciones, bitácoras (logs), parámetros, documentos electrónicos y archivos adjuntos y, en general, de las bases de datos y de toda información contenida en la infraestructura física y tecnológica que le suministre el proveedor contratado, siempre y cuando se genere en virtud de la ejecución de los servicios objeto de la presente licitación para el respectivo contrato.

El proveedor no podrá utilizar la información indicada en el párrafo anterior, durante la ejecución del contrato ni con posterioridad al término de su vigencia, sin autorización escrita de la entidad licitante. Por tal motivo, una vez que el proveedor entregue dicha información a la entidad o al finalizar la relación contractual, deberá borrarla de sus registros lógicos y físicos. 

12.11      Seguridad de la información y ciberseguridad

El contrato que se celebre en el marco de esta licitación entregará al proveedor adjudicado acceso a información de ChileCompra y/o sus sistemas, en consecuencia, es obligación del adjudicatario resguardar debidamente esta información y cumplir las demás consideraciones que se establecen en esta cláusula.

El adjudicatario reconoce que es el único responsable por la confidencialidad y seguridad de la Información de la Dirección ChileCompra que a la que accede, custodia o controla, por lo cual el adjudicatario será el responsable de tomar las medidas apropiadas de seguridad administrativas, técnicas y físicas, asegurará la confidencialidad, disponibilidad, integridad y seguridad de la Información de ChileCompra.

El adjudicatario deberá implementar y mantener un programa de seguridad que cumpla con los requisitos de seguridad y privacidad y que incorpore las mejores prácticas de la industria. El programa de seguridad del adjudicatario deberá incluir las medidas apropiadas de seguridad administrativas, técnicas y físicas, asegurará la confidencialidad, disponibilidad, integridad y seguridad de la Información de ChileCompra y sus sistemas e incluirá por lo menos las siguientes medidas de seguridad:

  1. Controles adecuados para la autentificación de usuarios, incluyendo métodos seguros para asignar, seleccionar y almacenar el acceso de credenciales, limitar el acceso sólo a los usuarios activos y bloquear el acceso después de un número intentos de accesos fallidos acorde a las buenas prácticas de seguridad definidos de la industria detallados en los requisitos de seguridad y privacidad.

  1. Controles de acceso seguro, incluyendo aquellos que limiten el acceso a la Información de ChileCompra para los individuos que tengan una razón fidedigna y demostrable de negocios para acceder a dicha información, respaldados mediante políticas, protocolos y controles apropiados que faciliten la autorización, establecimiento, modificación y eliminación de los accesos.

  1. Ajustes apropiados y oportunos para el Programa de Seguridad del Proveedor que se basen en: el riesgo periódico de valoraciones; evaluaciones exhaustivas y frecuentes (tales como las valoraciones efectuadas a terceros) del Programa de Seguridad del Proveedor; monitoreo y pruebas frecuentes de la efectividad de medidas de seguridad; y revisión de dichas medidas de seguridad con una frecuencia mínima de un año, o cada vez que se presente un cambio sustancial en el ambiente técnico del Proveedor o en las prácticas del negocio que pudieran comprometer la confidencialidad, disponibilidad, integridad o seguridad de los sistemas informáticos del Proveedor.

  1. Programas de sensibilización y capacitación continua y apropiada de los trabajadores y demás personal que actué en nombre y representación del adjudicatario para asegurar que se apeguen a las políticas, procedimientos y protocolos del Programa de Seguridad.

  1. Monitoreo de los sistemas diseñados para garantizar la integridad de la información y prevenir la pérdida o acceso no autorizado a, o la adquisición, utilización y divulgación de la Información de ChileCompra.

  1. Medidas técnicas de seguridad, incluyendo la protección de firewalls y antivirus, administración de parches de seguridad, registro de accesos a, utilización o divulgación de la Información de ChileCompra, detección de intrusiones y cifrado de los datos estáticos y en tránsito.

  1. Medidas de seguridad en unidades físicas, incluyendo controles de accesos diseñados para restringir acceso a la Información de ChileCompra para los individuos que se describen en la Cláusula: Seguridad de la información sección 2.

  1. Segmentación lógica de la Información de ChileCompra de los datos que pertenezcan a otros clientes.

  1. Las tareas de mantenimiento de software solicitadas al proveedor deben cumplir con prácticas de desarrollo seguro y arquitectura recomendadas Microsoft y OWASP.

El Proveedor deberá ejercer la supervisión necesaria y apropiada sobre sus empleados y sobre cualquier otro personal que actúe en su representación para mantener la confidencialidad, integridad, disponibilidad y seguridad de la Información de ChileCompra.

El Proveedor deberá cumplir con todos los Requisitos de Seguridad de la Información y Privacidad aplicables.

El Proveedor deberá mantener un nivel de certificaciones o evaluaciones de seguridad que sea consistente con las mejores prácticas, y que se lleve a cabo mediante terceros que a juicio de ChileCompra estén calificados. A solicitud razonable de ChileCompra, dichos certificaciones deberán ser entregadas.

12.12      Portabilidad y transferencia de datos.

La Información de ChileCompra que se clasifique como reservada o confidencial no deberá almacenarse o transportarse en laptops ni en cualquier otro tipo de dispositivo móvil, ni en medios de almacenamiento extraíbles, incluyendo: USB, memorias portátiles, DVD o CD, a menos que dichos dispositivos se cifren utilizando una metodología de cifrado que se apruebe por escrito por el Área de Seguridad de la Información de ChileCompra.

Todas las transferencias de datos electrónicos de la Información de ChileCompra que se clasifiquen como reservada o confidencial se deberá realizar a través de FTP seguro u otro protocolo o metodología de cifrado que se apruebe por escrito por el área de Seguridad de la Información de ChileCompra.

Cualquier acuerdo de servicio con empresas que subcontraten de Hosting o Cloud que el proveedor use o en el futuro utilice para proveer servicios a ChileCompra, es un servicio de tercero que está sujeto a los lineamientos de las cláusulas de seguridad de la información y la presente cláusula.

.

De acuerdo a lo previsto en la presente clausula, no se podrá transferir, almacenar, o procesar la información de ChileCompra fuera del país en donde el Proveedor la recibe sin antes obtener una aprobación por escrito de ChileCompra, comprendiéndose las transferencias a agentes o subcontratados.

12.13      Evaluación y revisión seguridad de la información.

El Departamento de Seguridad de la Información de la Dirección ChileCompra deberá llevar a cabo una revisión de seguridad cuando ChileCompra lo considere razonablemente necesario.

 

A solicitud de ChileCompra, el Proveedor deberá proporcionar las copias de sus políticas de seguridad y privacidad, así como los procedimientos aplicables a la información de ChileCompra. Asimismo, el adjudicatario, a solicitud de ChileCompra, también podrá emitir respuestas por escrito a las preguntas relacionadas con las prácticas de seguridad de la información y privacidad que le sean aplicables a la información de ChileCompra. El proveedor deberá emitir respuestas escritas dentro de los primeros 10 días hábiles siguientes a la fecha de recepción de la solicitud de ChileCompra.

 

El Proveedor deberá proporcionar al Departamento de Seguridad de la Información la oportunidad de llevar a cabo una evaluación de seguridad y privacidad del Programa de Seguridad de la información, de los sistemas y los procedimientos de este. El personal de ChileCompra, o los terceros que ChileCompra contrate, deberán llevar a cabo dicha valoración in-situ, o bien, se deberá realizar mediante encuestas y entrevistas a discreción de ChileCompra. Dicha evaluación se llevará a cabo sólo una vez por cada año, a no ser que existe algún Incidente de Datos, en cuyo caso la frecuencia será mayor. Cuando vaya a realizarse una evaluación in-situ, ChileCompra deberá dar aviso al Proveedor con al menos de 15 días hábiles previos a dicha evaluación, con excepción que exista un Incidente de Datos, o en el caso que ChileCompra tuviera alguna base razonable para pensar que el Proveedor pudiese no cumplir con los puntos del presente apartado, en cuyo caso dicho aviso no será mayor a 48 horas.

 

El proveedor deberá notificar oportunamente por escrito a ChileCompra de cualquier incidente de datos, hallazgo, evaluación o revisión de seguridad que puedan impactar adversamente la información de ChileCompra o los sistemas de ChileCompra, realizadas por el proveedor o por un tercero; incluyendo, auditorías, evaluaciones de vulnerabilidad, revisión de códigos y análisis de penetración. El proveedor mantendrá informado oportunamente a ChileCompra de sus esfuerzos de remediación.

 

Asimismo, el Proveedor se compromete a cumplir con las disposiciones del Decreto Nº 273, de 2022 del Ministerio del Interior y Seguridad Pública, que establece la obligación de reportar incidentes de ciberseguridad. En este sentido, el Proveedor debe notificar inmediatamente al coordinador de contrato y al correo electrónico seguridad@chilecompra.cl sobre cualquier Incidente de Datos[1], de acuerdo con los procedimientos establecidos en el mencionado decreto.

La notificación inicial podrá darse a manera de resumen, indicando la existencia del incidente. Sin embargo, se deberá entregar una notificación extendida por escrito en el plazo establecido por el Decreto N°273 antes citado. Esta notificación deberá comprender con detalle razonable, la naturaleza y alcance del Incidente de Datos, incluyendo una descripción detallada de toda la información relacionada con ChileCompra que se haya visto afectada. Además, se deberán detallar las acciones correctivas que el Proveedor ha tomado para mitigar los impactos del incidente.

El Proveedor se compromete a realizar oportunamente dicha notificación con el nivel de detalle razonable que solicite ChileCompra, incluyendo los reportes de investigaciones o forenses relevantes. Este compromiso es esencial para asegurar el cumplimiento continuo del contrato y garantizar la seguridad de la información de ChileCompra.

Cualquier incumplimiento de estas obligaciones podrá dar lugar a medidas contractuales, sanciones o rescisión del contrato, de conformidad con las disposiciones del Decreto N°273 y otros términos contractuales pertinentes.

El Proveedor deberá tomar oportunamente todas las acciones correctivas necesarias y sugeridas, y deberá cooperar completamente con ChileCompra y el personal designado en todos los esfuerzos razonables para investigar el Incidente de Datos, mitigar los efectos adversos, y prevenir la recurrencia. Dicha cooperación deberá incluir la pronta respuesta a las averiguaciones de ChileCompra sobre el incidente de Datos.

 

Las partes deberán colaborar en caso de que sea necesario o recomendable proporcionar aviso del Incidente de Datos a cualquier persona, entidad gubernamental, los medios de comunicación o cualquier otra parte. Las Partes deberán colaborar con el contenido del aviso. ChileCompra deberá realizar las determinaciones finales sobre a quién, y si es que se proporcionaran notificaciones, el contenido de la notificación, y a qué Parte deberá ser la firmante de dicha notificación.

12.14      Entrega segura o eliminación y terminación de accesos.

Una vez que concluya el contrato, el Proveedor deberá regresar la Información de la Dirección ChileCompra que posea, custodie o controle.

No obstante, lo anterior, el Proveedor no podrá eliminar la Información de ChileCompra, salvo que esta acción sea acordada con la Dirección ChileCompra y en concordancia a la normativa aplicable. Cualquier eliminación de la Información de ChileCompra deberá garantizar que dicha información quede permanentemente ilegible e irrecuperable, siempre y cuando velando que la Dirección ChileCompra la disponga dentro de sus herramientas internas.

En la medida que el Proveedor tenga acceso o contacto con los sistemas de ChileCompra, deberá garantizar que dicho acceso cesará en la fecha de terminación del Contrato.

Mediante aviso razonable y a solicitud de ChileCompra, el Proveedor deberá proporcionar a ChileCompra las certificaciones de un órgano externo que dé fe del cumplimiento del Proveedor de las cláusulas de Seguridad de la Información y entrega segura o eliminación y terminación de accesos.

12.15      Tratamiento de datos personales por mandato.

En caso de que se encomiende al adjudicatario el tratamiento de datos personales por cuenta de la DCCP, ésta deberá suscribir un contrato de mandato escrito con el proveedor, en donde se especifiquen las condiciones bajo las cuales se podrán utilizar esos datos, según el artículo 8° de la Ley N°19.628, sobre Protección de la Vida Privada. En dicho contrato de mandato se indicará, a lo menos, la finalidad del tratamiento, el tipo de datos que se entrega al adjudicatario (en calidad de mandatario), la duración del encargo y un procedimiento para la devolución de los datos y su eliminación efectiva por parte del proveedor, al terminar ese contrato. Además, deberá prohibir expresamente el uso de dichos datos personales para fines distintos a los que persigue la DCCP (en calidad de órgano público mandante) y señalar expresamente que no se permite su comunicación a terceros.

12.16      Propiedad intelectual del software.

Al iniciar sus prestaciones, el adjudicatario deberá informar a la contraparte de la DCCP respecto del software sobre el cual tiene derechos de propiedad intelectual, sea como autor o a través de licenciamiento, y que será utilizado durante la ejecución del contrato.

En caso de que se realicen desarrollos de software para llevar a cabo las prestaciones contratadas, la DCCP adquirirá la propiedad intelectual del código fuente.

12.17      Acceso a sistemas.

En caso de que el personal del proveedor adjudicatario requiera acceso a los sistemas de la entidad licitante para llevar a cabo las prestaciones contratadas, deberá previamente informar a través de su coordinador del contrato a la contraparte del órgano comprador, el nombre y RUT de las personas que accederán, el objeto de actividad, la fecha y lugar, y el tipo de sistemas, información o equipos que requerirá.

Solo podrán tener acceso a los sistemas aquellas personas autorizadas por la contraparte del órgano contratante, en los términos que ésta determine y se entenderá que existe prohibición de acceso a todo otro sistema, información y equipos que no estén comprendidos en la autorización.

Si el personal del proveedor que recibe la autorización de acceso utiliza equipos propios, deberán individualizarse previamente.

12.18      Coordinador del contrato.

El adjudicatario deberá nombrar a un Coordinador de Contrato, distinto de los integrantes de los equipos de trabajo y distinto al Project Manager, cuya identidad deberá ser informada a la DCCP previo a la suscripción del contrato.

En el desempeño de su cometido, el Coordinador del contrato deberá, a lo menos:

  • Informar oportunamente a la DCCP de todo hecho relevante que pueda afectar el cumplimiento del contrato.
  • Representar al Proveedor, en la discusión de las materias relacionadas con la ejecución del contrato.
  • Coordinar las acciones que sean pertinentes para la operación y cumplimiento de este contrato.

 

Todo cambio relativo a la designación efectuada deberá ser informada por el proveedor al responsable de administrar el contrato por parte de la DCCP, a más tardar dentro de las 24 horas siguientes de efectuada la designación o cambio, al correo electrónico institucional del funcionario. La DCCP podrá rechazar o aprobar dicha designación. En caso de rechazo, el proveedor deberá nombrar otro coordinador y seguir el mismo procedimiento señalado precedentemente.

12.19      Supervisión, coordinación y administración del contrato por parte de la Dirección ChileCompra.

La DCCP definirá una contraparte técnica/administrador del contrato, para la coordinación del respectivo contrato, la que ejercerá las siguientes funciones, sin perjuicio de aquellas expresamente establecidas para los administradores de contratos, de acuerdo con las disposiciones internas de la DCCP. Entre otras, deberá ejercer las siguientes funciones:

  • Supervisar, coordinar y fiscalizar el cumplimiento de los procedimientos establecidos en las Bases para el oportuno cumplimiento del contrato.
  • Coordinar las acciones que sean pertinentes para la operación y cumplimiento de este contrato.
  • Dar visto bueno a los informes y recepción conforme de los servicios, como también la tramitación de pagos y aplicación de medidas.
  • Autorizar adecuaciones relativas al plan de trabajo, y en general atender y resolver situaciones emergentes no consideradas.
  • Colaborar y asistir al personal de apoyo en la obtención de la información pertinente para llevar adelante las funciones solicitadas.
  • Gestionar la autorización de los pagos programados según se haya establecido en el Contrato de Prestación de Servicios.
  • Determinar la aplicación de las medidas por incumplimiento que se estipulen en el Contrato, según corresponda.
  • Las demás que le encomiende el presente instrumento.

12.20      Cesión de contrato y subcontratación.

El adjudicatario no podrá ceder ni transferir en forma alguna, total ni parcialmente, los derechos y obligaciones que nacen del desarrollo de esta licitación y, en especial, los establecidos en el respectivo contrato que se celebre con la DCCP.

Por lo tanto, la empresa adjudicataria deberá ser la que efectivamente preste los servicios contratados, no pudiendo ceder de hecho a un tercero la ejecución de aquéllos.

Asimismo, se encuentra prohibida la subcontratación de servicios.

Por su parte, el Administrador de Contrato de la DCCP deberá exigir al proveedor la entrega de un documento que acredite la relación jurídica entre éste y el o los profesionales que participarán en la prestación de los servicios, tales como contratos de trabajo y/o contratos de prestación de servicios, entre otros que resulten procedentes para tales efectos.

La infracción de estas prohibiciones será causal inmediata de término del contrato, sin perjuicio de las acciones legales que procedan, de acuerdo con lo establecido en la cláusula 12.5.3, N°10, de las presentes bases.

12.21      Estándares de probidad

El adjudicatario que preste los servicios deberá observar, durante toda la época de ejecución del contrato, el más alto estándar ético exigible a los funcionarios públicos. Tales estándares de probidad deben entenderse equiparados a aquellos exigidos a los funcionarios de la Administración Pública, en conformidad con el Título III de la ley N°18.575, Orgánica Constitucional de Bases Generales de la Administración del Estado.

12.22      Pacto de integridad

El oferente declara que, por el sólo hecho de participar en la presente licitación, así como en la posterior ejecución del contrato de ser adjudicado, acepta expresamente el presente pacto de integridad, obligándose a cumplir con todas y cada una de las estipulaciones que contenidas el mismo, sin perjuicio de las que se señalen en el resto de las Bases de licitación y demás documentos integrantes.

 

Especialmente, el oferente acepta el suministrar toda la información y documentación que sea considerada necesaria y exigida de acuerdo con las presentes Bases de Licitación, asumiendo expresamente los siguientes compromisos, los cuales se extenderán a la ejecución contractual de ser el oferente adjudicado:

 

  1. El oferente se obliga a no ofrecer ni conceder, ni intentar ofrecer o conceder, sobornos, regalos, premios, dádivas o pagos, cualquiera fuese su tipo, naturaleza y/o monto, a ningún funcionario público en relación con su oferta, con el proceso de licitación pública, ni con la ejecución de él o los contratos que eventualmente se deriven de la misma, ni tampoco a ofrecerlas o concederlas a terceras personas que pudiesen influir directa o indirectamente en el proceso licitatorio, en su toma de decisiones o en la posterior adjudicación y ejecución del o los contratos que de ello se deriven.
  2. El oferente se obliga a no intentar ni efectuar acuerdos o realizar negociaciones, actos o conductas que tengan por objeto influir o afectar de cualquier forma la libre competencia, cualquiera fuese la conducta o acto específico, y especialmente, aquellos acuerdos, negociaciones, actos o conductas de tipo o naturaleza colusiva, en cualquier de sus tipos o formas.
  3. El oferente se obliga a revisar y verificar toda la información y documentación, que deba presentar para efectos del presente proceso licitatorio, tomando todas las medidas que sean necesarias para asegurar la veracidad, integridad, legalidad, consistencia, precisión y vigencia de esta.
  4. El oferente se obliga a ajustar su actuar y cumplir con los principios de legalidad, ética y transparencia en el presente proceso licitatorio.
  5. El oferente manifiesta, garantiza y acepta que conoce y respetará las reglas y condiciones establecidas en las Bases de licitación, sus documentos integrantes y el contrato que de ellos derivase.
  6. El oferente se obliga y acepta asumir las consecuencias y sanciones previstas en estas Bases de licitación, así como en la legislación y normativa que sean aplicables a la misma.
  7. El oferente reconoce y declara que la oferta presentada en el proceso licitatorio es una propuesta seria, con información fidedigna y en términos técnicos y económicos ajustados a la realidad, que aseguren la posibilidad de cumplir con la misma en las condiciones y oportunidad ofertadas.
  8. El oferente se obliga a tomar todas las medidas que fuesen necesarias para que las obligaciones anteriormente señaladas sean asumidas y cabalmente cumplidas por sus empleados y/o dependientes y/o asesores y/o agentes y en general, todas las personas con que éste o éstos se relacionen directa o indirectamente en virtud o como efecto de la presente licitación, haciéndose plenamente responsable de las consecuencias de su infracción, sin perjuicio de las responsabilidades individuales que también procediesen y/o fuesen determinadas por los organismos correspondientes.
  9. El oferente se compromete a no infringir los derechos humanos de terceros y a hacerse responsable respecto de las eventuales infracciones a dichos derechos, en la medida que le sean imputables, de acuerdo con lo señalado en los Principios Rectores de Derechos Humanos y Empresas elaborados por Naciones Unidas y aprobados por Chile.
  10. Una vez iniciado el procedimiento de contratación, el oferente deberá cumplir con la prohibición establecida en el artículo 35 ter de la Ley N° 19.886, esto es, no podrá mantener comunicación, como participante o interesado en el referido proceso, o como eventual interesado o participante en él, con las personas que desempeñen funciones en el organismo licitante que participen del proceso de adjudicación, independientemente de su calidad jurídica, en lo referido directa o indirectamente a tal proceso, salvo que se realice a través del Sistema de Información y Gestión de Compras Públicas administrado por la Dirección de Compras y Contratación Pública, y en la forma establecida en las bases de licitación, que asegure la participación e igualdad de todos los oferentes.

Se deja expresa constancia que toda referencia a “oferente” efectuada en la numeración de compromisos del párrafo anterior, se hace extensiva al adjudicatario respectivo en lo que corresponda.

12.23      Acreditación de cumplimiento de remuneraciones o cotizaciones de seguridad social y cumplimiento de normas laborales

Durante la vigencia del contrato suscrito, el adjudicatario deberá acreditar mediante una declaración jurada, según formato del Anexo N°9Declaración Jurada Simple para Contratar, que no registra saldos insolutos de remuneraciones o cotizaciones de seguridad social con sus actuales trabajadores o con trabajadores contratados en los últimos dos años. Este Anexo deberá ser presentado a la mitad de la vigencia del contrato, con un máximo de seis meses, desde el inicio de la ejecución del respectivo servicio, de corresponder. Sin perjuicio de ello, la Dirección ChileCompra también podrá solicitar al adjudicatario, en cualquier momento, la presentación de certificados de la Dirección del Trabajo u otros antecedentes que estime pertinentes para acreditar el cumplimiento de las obligaciones laborales antes señaladas.

En el caso de que la adjudicada sea una UTP, cada integrante de esta deberá presentar dicho anexo.

 

Lo anterior es sin perjuicio de la documentación exigida para cursar cada pago asociado al contrato.

El Contratista, en su calidad de empleador, será responsable exclusivo del cumplimiento íntegro y oportuno de las normas del Código del Trabajo y leyes complementarias, leyes sociales, de previsión, de seguros, de enfermedades profesionales, de accidentes del trabajo y demás pertinentes respecto de sus trabajadores y/o integrantes de sus respectivos equipos de trabajo.

Asimismo, y tal como se puntualizara en la cláusula N°12.8, si corresponde la DCCP exigirá al adjudicatario, antes de proceder al pago, el estado de cumplimiento de las obligaciones laborales y previsionales que a aquél correspondan respecto a sus trabajadores, mediante el “Certificado de Cumplimiento de Obligaciones Laborales y Previsionales”, Formulario F-30-1, otorgado por la Dirección del Trabajo, y la nómina de aquellos trabajadores que intervengan en la prestación del servicio objeto de la presente licitación.

En consecuencia, el Contratista será responsable, en forma exclusiva, y sin que la enumeración sea taxativa, del pago oportuno de las remuneraciones, honorarios, indemnizaciones, desahucios, gratificaciones, gastos de movilización, beneficios y, en general, de toda suma de dinero que, por cualquier concepto, deba pagarse a sus trabajadores y/o integrantes de sus respectivos equipos de trabajo.

Si por cualquier causa la Dirección dejara de efectuar o se abstuviera de cursar un pago, ello no podrá ser considerado o esgrimido por el Contratista para dejar de pagar las remuneraciones de sus trabajadores.

La Dirección deberá exigir al contratista, a simple requerimiento de la Contraparte Técnica, en conformidad con lo dispuesto en el artículo 4° de la Ley de Compras y artículo 183-C del Código del Trabajo, un certificado que acredite el monto y estado de cumplimiento de las obligaciones laborales y previsionales emitido por la Inspección del Trabajo respectiva, o bien, por medios idóneos que garanticen la veracidad de dicho monto y estado de cumplimiento, respecto de sus trabajadores. Ello, con el propósito de hacer efectivos, por parte de la Dirección, su derecho a ser informada y el derecho de retención, consagrados en los incisos segundo y tercero del artículo 183- C del Código del Trabajo, en el marco de la responsabilidad subsidiaria derivada de dichas obligaciones laborales y previsionales, a la que alude el artículo 183-D del mismo Código. En caso de negarse a entregar dicha documentación, se le aplicará una multa al proveedor equivalente al 0,5% del valor total del contrato por cada evento, hasta el límite de 3 veces, para lo cual se seguirá el procedimiento de aplicación de medidas consagrado en la cláusula N°12.6.4 de las presentes bases. Cada negativa a entregar dicha documentación, aunque sea respecto del mismo período, se considerará como una infracción distinta, con un límite de 3 negativas, y la cuarta negativa se considerará un incumplimiento grave, dando lugar al término anticipado del contrato.

Por otra parte, se deja expresa constancia que la suscripción del contrato respectivo no significará en caso alguno que el Contratista, sus trabajadores, o integrantes de los equipos presentados por estos, adquieran la calidad de funcionarios públicos, no existiendo vínculo alguno de subordinación o dependencia de ellos con esta Dirección.

El Adjudicatario y el personal bajo su dependencia se obligan a respetar las normas internas e instrucciones de la Dirección de Compras y Contratación Pública.

12.24      Documentos integrantes

La relación contractual que se genere entre la Dirección ChileCompra y el Adjudicatario se ceñirá a los siguientes documentos:

                     i.    La Ley N°19.886 y su reglamento.

                    ii.    Bases de licitación y sus anexos.

                  iii.    Consultas, respuestas y las aclaraciones derivadas del procedimiento estipulado en las bases de licitación.

                  iv.    Las modificaciones de las bases, si las hubiere.

                    v.    Oferta adjudicada.

                  vi.    Resolución de adjudicación.

                 vii.    Contrato definitivo suscrito entre las partes.

               viii.    Orden de Compra.

Todos los documentos antes mencionados forman un todo integrado y se complementan recíprocamente, en forma tal que se considerará parte del contrato cualquiera obligación que aparezca en uno u otro de los documentos señalados. Se deja constancia que se considerará el principio de preeminencia de las Bases, como marco básico.

12.25      Liquidación del contrato.

Para llevar a cabo la finalización de la relación contractual entre las partes, sea por término anticipado o no, el proveedor adjudicado deberá:

       Acordar un calendario de cierre con la entidad licitante, en donde se establezca un evento o plazo prudencial a partir del cual se entiende que el contrato entre en etapa de cierre.

       Elaborar un protocolo de fin de contrato, que suscribirán ambas partes, y en donde se detallen todas las actividades a realizar y los responsables de cada una de ellas, para lograr un cierre de contrato ordenado. Este protocolo puede incluir, según el tipo de proyecto, elementos como la entrega de códigos fuente, licencias, datos, documentación, soporte técnico, parametrización de sistemas, transferencia de know how, destrucción de información de propiedad del contratante, entre otros.

       Si la entidad licitante así lo requiere, el adjudicatario deberá prestar colaboración y participar en forma coordinada con aquélla en labores tendientes a la migración de sistemas u otras similares a un nuevo proveedor.  Lo anterior no comprende los servicios de migración que, en caso de ser requeridos deberán ser asumidos por el nuevo proveedor o acordados por separado con el adjudicatario.


ANEXO N°1: Formulario datos del Oferente

  1. DATOS DEL OFERENTE

-        En el caso que oferte una persona natural o jurídica:

Nombre Representante Legal o persona natural

Cargo

Razón Social o nombre persona natural

RUT Oferente

Dirección

Ciudad

Teléfono

E-mail

Web del oferente

-        En el caso que oferte una Unión Temporal de Proveedores (UTP):

Nombre UTP a la que pertenece

Nombre Apoderado UTP

Nombre Representante Legal o persona natural del integrante de la UTP que presenta este anexo

Razón Social de integrante UTP, si corresponde

RUT integrante UTP

Dirección

Ciudad

Teléfono

E-mail

Web

  1. DATOS DEL CONTACTO DEL OFERENTE

Nombre Contacto Licitación

Dirección

Ciudad

Teléfono

Celular (opcional)

e-mail

 

,

NOTA:

-        En el caso de las Uniones Temporales de Proveedores (UTP), este anexo deberá ser completado por cada uno de sus integrantes.

-        El apoderado UTP debe corresponder a un integrante de esta figura.


ANEXO N°2: Declaración jurada de independencia de la oferta

 

Yo, , cédula de identidad N° con domicilio en en representación de , RUT N° , del mismo domicilio, para la licitación pública para la “Contratación de servicios de desarrollo de soluciones para la plataforma Mercado Público”, declaro bajo juramento que:

(Marque en la línea correspondiente, el párrafo que corresponde a su situación)

_______

Mi representada no forma parte de un mismo grupo empresarial o está relacionada con personas en los términos establecidos en el Titulo XV “De los grupos empresariales, de los controladores y las personas relacionadas” de la Ley N°18.045 del Mercado de Valores.

_______

Mi representada forma parte de un grupo empresarial o está relacionada con personas en los términos establecidos en el Titulo XV “De los grupos empresariales, de los controladores y las personas relacionadas” de la Ley N°18.045 del Mercado de Valores, pero ninguno de los miembros del grupo empresarial o de sus personas relacionadas participa en el presente procedimiento licitatorio ofertando respecto del mismo producto o servicio.

_______

Mi representada forma parte de un grupo empresarial o está relacionada con personas en los términos establecidos en el Titulo XV “De los grupos empresariales, de los controladores y las personas relacionadas” de la Ley N°18.045 del Mercado de Valores, participando alguno de los miembros del grupo empresarial o de sus personas relacionadas en el presente procedimiento licitatorio respecto del mismo producto o servicio, declarando que la oferta que presenta mi representada fue preparada con total independencia del miembro del grupo empresarial o de la persona relacionada.

,

epresentante Legal o persona natural según corresponda >

NOTA:

-        En el caso de las personas jurídicas, quien suscribe debe ser el representante legal, y en el caso de las UTP, la declaración deberá ser suscrita por el apoderado de la UTP, ya sea persona natural o persona jurídica; y en este último caso, debe firmar su representante legal.


ANEXO N°3: Declaración jurada para autorización de notificaciones

Yo, , cédula de identidad N° , con domicilio en en representación de , RUT: , del mismo domicilio, para la licitación pública para la contratación del “Servicio de desarrollo de soluciones para la plataforma Mercado Público”, declaro bajo juramento que:

 

  1. Autorizo expresamente a la Dirección de Compras y Contratación Pública para que efectúe todas las notificaciones relacionadas con la ejecución contractual de este proceso de licitación a través del correo electrónico del contacto designado en el Anexo N°1, letra B, de estas bases.

  1. Asimismo, tomo conocimiento que las notificaciones referidas comprenden todo tipo de requerimientos con motivo de la presente licitación, incluyendo los procedimientos administrativos, tales como aquél señalado en la cláusula N 12.5.4  de estas bases.

,

 

 

 

NOTA:

-        Este anexo es voluntario, y en caso de adherirse a él, el oferente debe completarlo y acompañarlo como anexo al momento de postular.

-        En el caso de las personas jurídicas, quien suscribe debe ser el representante legal, y en el caso de las UTP, la declaración deberá ser suscrita por el apoderado de la UTP, ya sea persona natural o persona jurídica; y en este último caso, debe firmar su representante legal.


ANEXO N°4: Declaración para uniones temporales de proveedores

Este Anexo debe ser completado exclusivamente por proponentes que presenten su oferta a través de una Unión Temporal de Proveedores.

  1. Nombre de la Unión Temporal de Proveedores: ______________________________________

  1. Integrantes de la UTP:

NOMBRE O RAZÓN SOCIAL

RUT

CALIDAD

1

Apoderado UTP

2

Miembro UTP

3

Miembro UTP

(Agregue tantas filas como integrantes tenga la UTP)

  1. Criterios Técnicos:

Al momento de la presentación de la oferta, los integrantes de la UTP determinarán qué antecedentes presentarán para ser considerados en la evaluación respectiva, siempre y cuando lo anterior no signifique ocultar información relevante para la ejecución del respectivo contrato que afecte a alguno de los integrantes de la misma.

Indique en el siguiente recuadro a qué integrante(s) de la UTP pertenecen las experiencias declaradas en el Anexo N°5, identificando el proyecto y el cliente respectivo, información que ser concordante con el anexo referido:

PROYECTO

CLIENTE

INTEGRANTE UTP QUE PRESENTA EL PROYECTO

RUT / ID DE INTEGRANTE UTP

*Agregue las filas que requiera.

Indique en el siguiente recurado a qué profesionales está ofertando para el equipo de trabajo y a qué empresa integrante de la UTP pertenece cada uno:

NOMBRE DEL PROFESIONAL OFERTADO

INTEGRANTE UTP QUE OFERTA EL PROFESIONAL

RUT / ID DE INTEGRANTE UTP

*Agregue las filas que requiera.

Adicionalmente, para los siguientes criterios, el oferente deberá indicar a qué integrante de la UTP se le evaluará su condición:

SUBCRITERIO

INTEGRANTE UTP QUE OFERTA EL PROFESIONAL

RUT / ID DE INTEGRANTE UTP

1

Certificaciones del oferente

2

Sello Empresa Mujer

  1. Declaración de objeto, solidaridad y vigencia de la UTP:

Mediante esta declaración el firmante declara:

  • Ser parte de la Unión Temporal de Proveedores señalada en el numeral 1 de esta declaración, que tiene por objeto presentar una propuesta formal al proceso de licitación, bajo la modalidad establecida en el art. 67 bis del Reglamento de la Ley N°19.886.
  • Asimismo, declara que, conjuntamente con todos los integrantes de esta UTP, será solidariamente responsable de la presentación de la oferta, así como las obligaciones contraídas en virtud de los contratos suscritos en caso de ser adjudicado en esta licitación.
  • Finalmente, declara que la vigencia de la UTP no será inferior a la del contrato adjudicado, incluyendo las renovaciones, incrementos de plazos y prórrogas que procedan en caso de que las hubiere.

________________________________________________ 

 

 

NOTA:

El anexo debe ser presentado por el apoderado UTP, ya sea por la persona natural o por el representante legal de la empresa apoderada, completarlo debidamente, firmar y adjuntar a la oferta este anexo. En caso de que falte esta declaración, la oferta UTP será declarada inadmisible.


ANEXO N°5: Oferta Técnica

INFORMACIÓN IMPORTANTE: Este documento en formato Word es meramente referencial, por lo tanto, el Anexo N°5 deberá ser completado mediante formato Excel que se adjunta en la presente licitación a través de Sistema de Información.

En el presente anexo, el oferente debe completar la información técnica que se detalla respecto de su oferta, para efectos de su admisibilidad y posterior evaluación.

El oferente, , RUT N° _______________, en su calidad de representante legal, apoderado u oferente de , declara que el contenido de la presente oferta técnica, materia del presente documento, se ajusta a la realidad y consiste en:

  1. SERVICIOS OFERTADOS:

Línea de Servicio

Marque con una X las Líneas de servicio que oferta

Línea de Servicio N°1

Línea de Servicio N°2

  1. REQUISITOS TÉCNICOS DE ADMISIBILIDAD DE LA OFERTA:

Requisito técnico mínimo

Indique si cumple o no por cada línea de servicio

(Responda SI/NO)

Línea de servicio N°1

Línea de servicio N°2

1

La oferta cumple con considerar un periodo de garantía técnica de 3 meses por lo entregables según lo descrito en la cláusula 9.3 número 1.

2

La oferta cumple con incluir un equipo compuesto por los perfiles: Líder Técnico, Desarrollador Frontend (ReactJS), Desarrollador Backend (Spring boot), Desarrollador AWS, Desarrollador .Net e Ingeniero DevOps, en sus cantidades mínimas y de acuerdo con lo descrito en la cláusula 9.3 número 2 de las bases

3

La oferta cumple con considerar que el equipo de trabajo tenga dedicación exclusiva con el proyecto

4

Cada integrante del equipo de trabajo propuesto cumple con los requisitos técnicos mínimos por perfil, según lo solicitado en la cláusula 9.3 número 2 de las bases.

5

El equipo de trabajo propuesto cumple con no repetir profesionales dentro de la misma línea de servicio ofertada.

6

La oferta considera la totalidad de los requisitos de admisibilidad descritos en las bases de licitación

  1. REQUISITOS TÉCNICOS DE ADMISIBILIDAD DEL EQUIPO DE TRABAJO:

Por cada uno de los profesionales que conformen el equipo, deberá completar la siguiente información según el perfil correspondiente.

PERFIL

LÍDER TÉCNICO

CUMPLE (SI/NO)

NÚMERO DE LA EXPERIENCIA, CURSO O CERTIFICACIÓN EN EL CURRÍCULUM VITAE (Ej.: Curso 1)

NOMBRE COMPLETO:

REQUISITO

1

Contar con, al menos, tres años ejerciendo en cargos como líder técnico o líder de equipos de desarrollo, en instituciones públicas o privadas

 

2

Contar con, al menos, tres años en desarrollo de software (codificación) en lenguajes de programación Frontend en, al menos, alguna de las siguientes tecnologías: ReactJS, Angular, Javascript

 

3

Contar con, al menos, tres años en desarrollo de software (codificación) en lenguajes de programación Backend, en al menos alguna de las siguientes tecnologías: Spring Boot, Java, C#, VisualBasic

 

PERFIL

DESARROLLADOR FRONTEND (REACTJS)

CUMPLE (SI/NO)

NÚMERO DE LA EXPERIENCIA, CURSO O CERTIFICACIÓN EN EL CURRÍCULUM VITAE (Ej.: Curso 1)

NOMBRE COMPLETO:

REQUISITO

1

Contar con, al menos, tres años de experiencia comprobada en desarrollo de software con tecnología ReactJS, en uno o más proyectos digitales en instituciones públicas o privadas

 

2

Contar con experiencia en el trabajo con equipos multidisciplinarios y de desarrollo ágil

 

3

Contar con experiencia trabajo con software de control de versiones

 

PERFIL

DESARROLLADOR BACKEND (SPRING BOOT)

CUMPLE (SI/NO)

NÚMERO DE LA EXPERIENCIA, CURSO O CERTIFICACIÓN EN EL CURRÍCULUM VITAE (Ej.: Curso 1)

NOMBRE COMPLETO:

REQUISITO

1

Contar con, al menos, tres años de experiencia comprobada en desarrollo de software con Java Spring boot en uno o más proyectos digitales en instituciones públicas o privadas

 

2

Contar con experiencia en el desarrollo con base de datos SQL Server, PostgreSQL o similar

 

3

Contar con experiencia en el Desarrollo de servicios REST JSON

 

4

Contar con experiencia en trabajo con equipos multidisciplinarios y de desarrollo ágil

 

PERFIL

DESARROLLADOR AWS

CUMPLE (SI/NO)

NÚMERO DE LA EXPERIENCIA, CURSO O CERTIFICACIÓN EN EL CURRÍCULUM VITAE (Ej.: Curso 1)

NOMBRE COMPLETO:

REQUISITO

1

Contar con, al menos, dos años de experiencia comprobada en desarrollo en proyectos de AWS

 

2

Contar con al menos una de las siguientes certificaciones vigente al momento de la publicación de la licitación: AWS Certified Solutions Architect – Associate / AWS Certified Solutions Architect – Professional / AWS Certified Security – Specialty u otra certificación relacionada al rol de Arquitectura y Seguridad de AWS / AWS Certified Developer Associate

 

3

Contar con experiencia en el desarrollo con base de datos SQL Server, PostgreSQL o similar

 

4

Contar con experiencia en el desarrollo de servicios REST JSON

 

5

Contar con experiencia en trabajo con equipos multidisciplinarios y de desarrollo ágil

 

6

Contar con experiencia desarrollando con DDD (Domain Driven Design)

 

PERFIL

DESARROLLADOR .NET

CUMPLE (SI/NO)

NÚMERO DE LA EXPERIENCIA, CURSO O CERTIFICACIÓN EN EL CURRÍCULUM VITAE (Ej.: Curso 1)

NOMBRE COMPLETO:

REQUISITO

1

Contar con, al menos, tres años de experiencia comprobada en desarrollo de software utilizando lenguaje de programación .NET

 

2

Experiencia comprobable en desarrollo de servicios web REST y SOAP

 

3

Contar con experiencia en el desarrollo con Base de datos SQL Server, PostgreSQL o similar

 

4

Contar con experiencia en el desarrollo de servicios REST JSON

 

5

Contar con experiencia en trabajo con equipos multidisciplinarios y de desarrollo ágil.

 

6

Contar con experiencia comprobable en C#, VB.NET, MVC, Razor

 

PERFIL

INGENIERO DEVOPS

CUMPLE (SI/NO)

NÚMERO DE LA EXPERIENCIA, CURSO O CERTIFICACIÓN EN EL CURRÍCULUM VITAE (Ej.: Curso 1)

NOMBRE COMPLETO:

REQUISITO

1

Contar con, al menos, tres años de experiencia comprobada en rol de DevOps y/o DevSecOps en uno o más proyectos digitales en instituciones públicas o privadas

 

2

Contar con experiencia en la administración y/o desarrollo con Base de datos SQL Server, PostgreSQL o similar

 

3

Contar con experiencia mínima de un año en el manejo de Pipelines con Azure DevOps o similares

 

4

Contar con experiencia en el manejo de Git / Gitflow

 

5

Contar con experiencia en trabajo con equipos multidisciplinarios y de desarrollo ágil

 

6

Contar con experiencia mínima de un año implementando y/o administrando servicios Cloud en AWS, GCP y/o Azure

 

  1. Experiencia del oferente en proyectos similares:

El proponente deberá completar en su totalidad las siguientes tablas, a fin de dar cuenta de la experiencia del oferente para proyectos similares, la cual será considera una vez aceptados los desarrollos y operativos en plataforma productiva de la DCCP.

Para ser evaluados, los proyectos presentados deben:

-        Haber finalizado dentro de los últimos 5 años a contar de la fecha publicación de la licitación.

-        Haber tenido una duración de al menos 3 meses

-        Ser un proyecto similar al objeto de esta licitación, es decir, haber tenido como objeto el desarrollo e implementación de servicios con todas o algunas de las siguientes tecnologías de acuerdo a cada línea de servicio:

  • Línea de servicio N°1: React, JAVA, tecnologías cloud de AWS.
  • Línea de servicio N°2: React, JAVA, contenedores y .NET en el desarrollo de sistemas web.  

La DCCP podrá, a través de los datos de contacto aportados, corroborar la veracidad de la información entregada.

Podrá presentar hasta un máximo de 20 experiencias. En caso de presentar más experiencias sólo se considerarán las primeras 20 iniciativas.

Nombre del Proyecto

 Nombre del Cliente

URL Sitio web (si aplica)

Fecha de realización

Duración del trabajo realizado (número de meses)

Descripción del trabajo realizado y resultados obtenidos

Tecnologías utilizadas

Nombre persona de referencia

Fono de Contacto y/ o correo electrónico de persona de referencia

Nombre archivo “Carta de referencia” (Ej.: Carta 1, Carta 2, etc.)

(indicar inicio y fin

dd/mm/aa  - dd/mm/aa)

1

2

3

20

  1. CERTIFICACIONES DEL OFERENTE

LÍNEA DE SERVICIO N°1

Condición

Indique (SI/NO)

Nombre del documento adjunto que acredita condición

El oferente es partner de AWS

 

LÍNEA DE SERVICIO N°2

Condición

Indique (SI/NO)

Nombre del documento adjunto que acredita condición

El oferente cuenta con certificación ISO 27001

 

  1. EQUIPO DE TRABAJO

  1. Indique el nombre completo de cada integrante del equipo de trabajo:

LÍNEA DE SERVICIO N°1

Nombre Completo

Perfil

Condición del perfil

1

Líder Técnico

Obligatorio

2

Desarrollador Frontend (ReactJS) N°1

Obligatorio

3

Desarrollador Frontend (ReactJS) N°2

Obligatorio

4

Desarrollador Frontend (ReactJS) N°3

Obligatorio

5

Desarrollador Backend (Spring boot) N°1

Obligatorio

6

Desarrollador Backend (Spring boot) N°2

Obligatorio

7

Desarrollador Backend (Spring boot) N°3

Obligatorio

8

Desarrollador Backend (Spring boot) N°4

Obligatorio

9

Desarrollador Backend (Spring boot) N°5

Obligatorio

10

Desarrollador AWS

Obligatorio

11

Desarrollador .Net

Obligatorio

12

Ingeniero DevOps

Obligatorio

LÍNEA DE SERVICIO N°2

Nombre Completo

Perfil

Condición del perfil

1

Líder Técnico

Obligatorio

2

Desarrollador Frontend (ReactJS) N°1

Obligatorio

3

Desarrollador Frontend (ReactJS) N°2

Obligatorio

4

Desarrollador Frontend (ReactJS) N°3

Obligatorio

5

Desarrollador Backend (Spring boot) N°1

Obligatorio

6

Desarrollador Backend (Spring boot) N°2

Obligatorio

7

Desarrollador Backend (Spring boot) N°3

Obligatorio

8

Desarrollador Backend (Spring boot) N°4

Obligatorio

9

Desarrollador Backend (Spring boot) N°5

Obligatorio

10

Desarrollador Backend (Spring boot) N°6

Obligatorio

11

Desarrollador AWS

Obligatorio

12

Desarrollador .Net N°1

Obligatorio

13

Desarrollador .Net N°2

Obligatorio

14

Desarrollador .Net N°3

Obligatorio

15

Ingeniero DevOps

Obligatorio

  1. currículum vitae

Por cada uno de los profesionales que conformen el equipo, deberá completar la siguiente información según el perfil correspondiente.

ANTECEDENTES GENERALES

Nombre del profesional

 

Perfil asignado

 

Teléfono

 

Correo Electrónico

 

Formación Académica

Título / Institución en que se obtuvo

Año de Titulación

1

 

 

2

 

 

N

(agregar si es necesario)

 

Cursos

Nombre del curso

Año de Titulación

Nombre de adjunto

Requisito obligatorio

Condición evaluable

1

 

 

 

 

 

2

 

 

 

 

 

N

(agregar si es necesario)

 

 

 

 

Certificaciones

Nombre de la certificación

Link

Nombre de adjunto

Requisito obligatorio

Condición evaluable

1

 

 

 

 

 

2

 

 

 

 

 

N

(agregar si es necesario)

 

 

 

 

Experiencia

Nombre de la experiencia

Inicio - Fin

Total meses

Cliente

Indique todas las tecnologías, herramientas, lenguajes y/o metodología que utilizó

Requisito obligatorio

Condición evaluable

1

 

 

 

 

 

 

 

2

 

 

 

 

 

 

 

N

(agregar si es necesario)

 

 

 

 

 

 


ANEXO N°5.1: Formato tipo “carta referencia experiencia oferente”

A continuación, se indican los contenidos mínimos que se deben indicar en las “Cartas de Referencia” para acreditar la experiencia del oferente.

     i)        El oferente debe adjuntar una carta por cada experiencia que informe en el Anexo N°5.

    ii)        El oferente podrá adjuntar un formato distinto de carta de referencia, pero el documento adjunto deberá contener la información requerida en este Anexo.

  iii)        El proyecto informado deberá contar con una evaluación exitosa y/o satisfactoria.

  iv)        El nombre del archivo de cada “Carta de Referencia” debe ser Carta 1, Carta 2, etc., lo que permitirá identificarlo con la experiencia informada en el Anexo N°5 “Cuadro Experiencia del Oferente”, en la columna respectiva.

    v)        La comisión evaluadora podrá verificar la información proporcionada, pudiendo tomar contacto con los clientes indicados por el oferente.

Nombre del oferente

Nombre cliente a quien prestó el servicio (público o privado)

Persona que entrega referencia

Nombre

Cargo

Correo electrónico

Teléfono fijo, móvil

Nombre del proyecto

Fecha inicio del servicio

Fecha término del servicio

Descripción del Servicio entregado

Objetivo, tecnologías utilizadas, hitos, integraciones, etc

NIVEL DE SATISFACCIÓN CON EL SERVICIO PRESTADO: (marque con una X donde corresponda):

La implementación del proyecto fue exitosa

La implementación del proyecto NO fue exitosa

Firma del Cliente


ANEXO N°6: Programa de integridad

Yo, , cédula de identidad N° , con domicilio en en representación de , RUT: , del mismo domicilio, para la licitación pública para la contratación del servicio de “Servicio de desarrollo de soluciones para la plataforma Mercado Público”, declaro bajo juramento que: 

 

Mi representada ______ (SI/NO) posee un programa de integridad que es conocido por su personal, entendiendo programa de integridad cualquier sistema de gestión que tenga como objetivo prevenir y si resulta necesario, identificar y sancionar las infracciones de leyes, regulaciones, códigos o procedimientos internos que tienen lugar en una organización, promoviendo una cultura de cumplimiento.  

 

A fin de comprobar su declaración se deberá adjuntar a la oferta el referido programa de integridad.  

 

 

,  

 

________________________________________________ 

 

 

 

 

NOTA:

  1. En el caso de las personas jurídicas, quien suscribe debe ser el representante legal, y en el caso de las UTP, la declaración deberá ser suscrita por el apoderado de la UTP, ya sea persona natural o persona jurídica; y en este último caso, debe firmar su representante legal.
  2. Marcar con SÍ/NO el párrafo, según corresponda a su situación.


ANEXO N°7: Oferta Económica

Los oferentes deberán tener en consideración al momento de realizar su oferta lo siguiente:

  1. En caso de ofertar a ambas líneas de servicio, debe incluir el valor total bruto para cada una de ellas por separado, en el campo correspondiente.
  2. Para efectos de la evaluación, las ofertas ingresadas deben ser por el valor total bruto, en pesos chilenos, incluyendo todos los impuestos, para cada línea de servicio de forma independiente. Se debe ingresar un valor entero sin decimales. En caso de existir decimales, éste se redondeará al número entero siguiente en caso de que la primera cifra decimal sea igual o superior a 5. En caso contrario, el monto deberá ser redondeado al número entero anterior.
  3. En el formulario de ingreso de oferta disponible en www.mercadopublico.cl, el oferente deberá señalar el valor bruto hora por perfil.
  4. El valor total bruto ofertado no podrá superar el presupuesto por la línea de servicio descrito en la cláusula 12.7.

Línea de Servicio N°1:

N° Perfil

Nombre Perfil

Cantidad de Horas estimadas

Valor Bruto Hora por perfil

Valor Bruto Total por perfil

1

Líder técnico

1.443

2

Desarrollador Front (React)

3.659

3

Desarrollador Back (Spring boot)

5.539

4

Desarrollador AWS

1.443

5

Desarrollador .Net

1.108

6

Ingeniero DevOps

1.443

VALOR TOTAL BRUTO DE LA OFERTA PARA LÍNEA DE SERVICIO N°1

 

Línea de Servicio N°2:

N° Perfil

Nombre Perfil

Cantidad de Horas estimadas

Valor Bruto Hora por perfil

Valor Bruto Total por perfil

1

Líder técnico

1.443

2

Desarrollador Front (React)

3.659

3

Desarrollador Back (Spring boot)

6.990

4

Desarrollador AWS

1.443

5

Desarrollador .Net

3.238

6

Ingeniero DevOps

1.443

VALOR TOTAL BRUTO DE LA OFERTA PARA LÍNEA DE SERVICIO N°2

________________________________________________ 

 

 


ANEXO N°9: Declaración jurada para contratar

(Deudas Vigentes con Trabajadores)

 

Yo, , cédula de identidad N° con domicilio en , en representación de , RUT N° , del mismo domicilio, declaro que:

Mi representada ______ (SI/NO) registra saldos insolutos de remuneraciones o cotizaciones de seguridad social con los actuales trabajadores o con trabajadores contratados en los últimos 2 años.

Asimismo, declaro que por este acto vengo en ratificar todo lo obrado por el proveedor que represento en la licitación que resultó adjudicada, sea que se trate de actuaciones efectuadas por personas con poder suficiente para representarla o no.

,

Nota:

1. Todos los datos solicitados deben ser completados debidamente por el oferente que resulte adjudicado.

2. En el caso de la UTP, este anexo deberá ser completado por cada uno de los integrantes de la misma, respecto de la situación particular de su empresa.

3. Esta declaración será exigida al momento de suscribir el respectivo contrato.


ANEXO N°10: Declaración de Confidencialidad para integrantes del equipo de trabajo

Yo, _________________________, cédula de identidad N° _____________, de profesión __________________, con domicilio en _____________________________, en calidad de miembro del equipo consultor del proveedor que resultó adjudicado en la licitación pública ID ______________, declaro bajo juramento lo siguiente:

Estoy en conocimiento de todo lo estipulado en las bases de licitación, publicadas en el Sistema de Información www.mercadopublico.cl bajo el ID _____________, sus respectivos anexos, y el contrato de prestación de servicios de desarrollo de software contraídos entre el Adjudicatario y la Dirección ChileCompra, los cuales acepto íntegramente en este acto.

Asimismo, me comprometo a:

  1. No divulgar bajo ningún mecanismo, y en ninguna circunstancia, resguardando así estricta y absoluta reserva y confidencialidad, todo antecedente, información, documentación, archivo, registro u otro que sea generado o proporcionado por ChileCompra con ocasión del desarrollo de mis funciones en calidad de _____________, las que se encuentran establecidas en las bases de licitación, sus anexos y el contrato, ya sea que haya accedido a éstas de forma física, digital o a través de otro medio y/o mecanismo y que haya sido catalogada como información confidencial por parte de ésta.

  1. No utilizar para ninguna finalidad ajena a la ejecución de los servicios contratados la documentación, los antecedentes o cualquier información de los que, indistintamente del medio, haya tomado conocimiento en virtud de la ejecución del contrato o de cualquier actividad relacionada con éste.

  1. Mantener en todo momento la confidencialidad de la información, antecedentes, documentación, registros y cualquier otro que defina la Dirección ChileCompra de carácter confidencial que sean generados producto del desarrollo de las funciones del proyecto encomendado en los diferentes procesos, actividades, tareas u otro que desempeñe en mi calidad de ___________.

Lo anteriormente señalado aplicará para toda aquella información, antecedente, registro, archivo u otro que la Dirección ChileCompra declare afecto a confidencialidad, ante lo cual me comprometo a hacer valer íntegramente su condición durante la vigencia del contrato o hasta que la Dirección defina lo contrario.

Asimismo, declaro conocer y aceptar que, ante la divulgación por cualquier medio de la totalidad o parte de la información referida en los párrafos anteriores, durante la vigencia del contrato o una vez finalizado éste, dará pie a que la Dirección ChileCompra siga las acciones judiciales que correspondan.

________________________________________________ 

 

< Nombre del integrante del equipo de trabajo>

Nota:

  1. Esta declaración deberá ser firmada por cada integrante del equipo de trabajo del proveedor adjudicado.


ANEXO A: Especificaciones referenciales para el desarrollo de soluciones

A continuación, se proporcionan las especificaciones referenciales para cada uno de los desarrollos de soluciones en el marco de esta licitación.

  1. Línea de Servicio N°1:
  2. Creación de nuevos organismos compradores en Mercado Público
  3. Ficha del organismo comprador
  4. Información de compradores en los procesos de compra
  5. Integración con información del Tribunal de Contratación Pública

  1. Línea de Servicio N°2:
  2. Actualización de “Trato Directo”
  3. Actualización de “Compra Ágil”
  4. Incorporación de mecanismo de compra “Diálogos Competitivos”
  5. Incorporación de mecanismo de compra “Contratos para la innovación”

I.         Línea de Servicio N°1

1.        Creación de nuevos organismos compradores en Mercado Público

-        Objetivo general: Facilitar la incorporación de nuevos organismos compradores a Mercado Público.

-        Objetivo Específico: Desarrollar una funcionalidad que permita disminuir la burocracia e incorporar eficazmente a estos usuarios.

-        Requerimientos:

Requerimiento 1

Paso 0 – Bienvenida (paso informativo) y acceso al formulario de solicitud incorporación a Mercado Público

Escenario de uso

La persona solicitante ingresa a través de un formulario la institución que quiere inscribir en Mercado Público.

Descripción

Formulario informativo, de bienvenida. Es el primer paso al flujo de inscripción.

Criterios generales

Se accederá a este flujo a través de un link en el Home público de Mercado Público que deberá ser agregado.

Al ingresar al flujo de inscripción, existirá en este paso la bienvenida para nuevos usuarios. A través de esta sección se podrá acceder al formulario de incorporación, siendo este el primer paso informativo.

Existirán campos de información opcionales y obligatorios.

El formulario podrá guardarse antes de enviar la solicitud.

Imagen referencial

Consideraciones técnicas

Página estática.

Se requieren elementos tales como selectores, radio-button, date-picker, acordeones, entre otros.

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de Microservicios y Stored Procedure (MS y SP) para la persistencia de datos (ej. Si el form permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una sola función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rollback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend.

Todas las validaciones de reglas de negocio se deben realizar como base a nivel de backend,

Guardar logs en caso de rollback de una transacción que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rollback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

Utilizar recaptcha en todos los form donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs.

Requerimiento 2

Paso 1 – Clave Única e información del usuario

Escenario de uso

Usuario verifica su identidad a través de Clave Única. Adicionalmente podrá ingresar su número de teléfono laboral o móvil.

Descripción

Formulario permite conexión y verificación con Clave Única,

Criterios generales

Este paso tiene por objetivo verificar la identidad digital del usuario que está comenzando el proceso de inscripción de una institución, por lo que es necesaria la conexión con el servicio del Registro Civil para obtener sus nombres y apellidos.

Usuario deberá aceptar términos y condiciones de uso.

Adicionalmente podrá completar información adicional restante, como teléfono laboral, entre otros, generando las validaciones correspondientes por cada campo de información.

En caso de error o problemas de la plataforma, se deberán generar los mensajes correspondientes para el usuario.

Imagen referencial

Consideraciones técnicas

Inscripción/registro módulo en claveUnica.gob.cl, si falla, no se podrá continuar con el flujo y se debe mostrar un mensaje de error para intentar más tarde.

Conexión con WebService de Registro Civil Debe ser mediante backend, considerar timeout y debe validar consistencia e integridad de la respuesta.

Debe quedar un registro de la solicitud positivas (rut, fecha-hora, id y contenido de la respuesta) y negativas (ID_Solicitud, rut, fecha-horas, y detalle del error).

El registro de Log en caso de problemas o errores para conectar con el registro civil no debe impedir el término del flujo funcional.

Presentación de datos no modificables.

Modelo de Guardado de Datos temporalmente previo a la creación de solicitud. La limpieza de dichas tablas temporales debe ser diaria.

Validaciones de inputs, en front y back (doble validación).

Se debe considerar token SSO de aplicación.

Se debe solicitar client_secret para esta integración.

En el caso de fallas durante el proceso de inscripción se debe considerar rollback de las transacciones completas o por etapa e informar al usuario que ha ocurrido un error y que debe reintentar.

Se debe registrar los errores con rut, fecha-hora, traza de la app, etapa (si fuera el caso)

Se debe crear lista blanca para permitir en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el formulario permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una sola función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio u otros.

Implementar rollback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend

Todas las validaciones de reglas de negocio se deben realizar como base a nivel de backend.

Guardar logs en caso de rollback de una Transacción que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rollback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Utilizar recaptcha en todos los formularios donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros) para facilitar uso de CDNs.

Requerimiento 3

Paso 2 – Correo electrónico y validación

Escenario de uso

La persona solicitante debe ingresar su correo electrónico el cual deberá validar a través de un código de validación que será enviado a la dirección de correo electrónico que ingrese en el formulario

Descripción

Formulario que permite el ingreso de correo electrónico válido y gatilla número de verificación enviado por mail para validación, a correo ingresado por usuario.

Criterios generales

Una vez que el usuario ingresa su dirección de correo electrónico y hace clic sobre el botón “Enviar código”, recibirá el código de validación en el correo ingresado.

El código de validación tiene una vigencia de 5 minutos, en caso de que el usuario no ingrese el código de validación dentro de ese rango de tiempo, para continuar con el proceso deberá solicitar el envío de un nuevo código.

Es necesario considerar un contador de tiempo que le indique al usuario la cantidad de minutos y segundos restantes para ingresar el código de validación que solicitó.

Se debe considerar la construcción y envío del mail según plantilla que se entregará.

En caso de error o problemas de la plataforma, se deberán generar los mensajes correspondientes para el usuario.

Imagen referencial

Consideraciones técnicas

Se deberán implementar validaciones de seguridad respecto a ingreso de correos electrónicos.

Durante el diseño técnico se debe implementar una base de datos para listas negras.

Se debe alinear el envío de correo a los métodos seguros de envío de correos, disponibles en la plataforma.

Manejo de reintentos para el reenvío de correos.

Se debe considerar modelo de almacenamiento temporal de los datos ingresados.

Si el usuario no completa el proceso se debe realizar rollback de la transacción.

Se debe registrar el resultado del proceso de validación.

Se debe registrar los errores con ID_Solicitud, rut, fecha-hora, traza de la app, etapa (si fuera el caso)

Se debe registrar el rollback con ID_Solicitud, rut, fecha-hora, motivo.

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el formulario permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rollback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend,

Todas las validaciones de reglas de negocio se deben realizar como base a nivel de backend,

Guardar logs en caso de rollback de una tiranización que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rollback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar logs para capturar errores internos y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

Utilizar recaptcha en todos los formularios donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs

Requerimiento 5

Paso 4 – Máxima autoridad de la institución

Escenario de uso

La persona requirente ingresa la información de la máxima autoridad de la institución u organismo.

Descripción

Formulario con campos de información obligatoria para ingreso del usuario.

Criterios generales

Usuario debe ingresar el RUT de la persona que en ese momento sea la máxima autoridad de la institución, mediante el RUT de las personas el formulario obtendrá información del Registro Civil, debiendo completar información como:

  • Nombres (autocompletado mediante conexión con el servicio del Registro Civil)
  • Apellidos (autocompletado mediante conexión con el servicio del Registro Civil)
  • Cargo
  • Correo electrónico
  • Teléfono laboral

Cada campo de información tendrá validaciones individuales.


Existirá ayuda contextual para ayudar a los usuarios a identificar cuál sería la máxima autoridad de su institución.

En caso de error o problemas de la plataforma, se deberán generar los mensajes correspondientes para el usuario.

Imagen referencial


Consideraciones técnicas

Conexión con el Registro Civil.

Se debe considerar el modelo de datos para dar soporte datos temporales máxima Autoridad.

Validaciones mínimas en datos de entrada (ejemplo mail, teléfono).

Datos desplegados sin posibilidad de ser editados.

Doble validación en guardado de datos.

Debe quedar un registro de la solicitud al webservice positivas (ID_Solicitud, rut, fecha-hora, id y contenido de la respuesta) y negativas (ID_solicitud, rut, fecha-horas, y detalle del error)

El proceso debe considerar rollback en el caso de que el usuario no complete el proceso de inscripción.

Se debe registrar el rollback con ID_Solicitud, rut, fecha-hora, motivo.

Los datos temporales deben considerar tener un periodo de retención que en el caso de no estar definidos deben considerar ser borrados al cumplir 24 horas o al final del día.

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el formulario permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rollback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend,

Todas las validaciones de reglas de negocio se deben realizar como base a nivel de backend,

Guardar los en caso de rollback de una tiranización que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rollback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

Utilizar recaptcha en todos los formularios donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs

Requerimiento 6

Paso 5 – Convenio de colaboración y anexos

Escenario de uso

La persona requirente ingresa acuerdo de colaboración firmado, en caso de ser necesario.

Descripción

Formulario con campos de información obligatoria para ingreso del usuario.

Criterios generales

Usuarios que adhieran de forma voluntaria, deberán completar el convenio de colaboración.

Este documento electrónico debe permitir la firma electrónica simple a través de los mecanismos que se definan (como Clave Única, entre otros), permitiendo aceptar las condiciones por el usuario, guardando todos sus datos, la fecha de firma, antes de poder continuar.

Este documento será construido en base a una plantilla, la cual podrá ser editada o complementada por el usuario.

En caso excepcional, también los usuarios podrán descargar dicho documento electrónico y firmar electrónicamente por sus medios, pudiendo subirla en este paso como un documento adjunto.

Adicionalmente, de ser requerido por el usuario, podrá subir más anexos en este paso.

Imagen referencial

Consideraciones técnicas

Se debe generar un modelo que soporte el formulario digital y su administración para que sea editable y mantenible, es decir, hay que construir un backoffice.

Todos los archivos que se adjunten debiesen ser visibles en la “Solicitud de inscripción”. En el requerimiento 9.

Se debe considerar conexión con Clave Única para firma electrónica.

Debe quedar un registro de la solicitud al webservice positivas (ID_Solicitud, rut, fecha-hora, id y contenido de la respuesta) y negativas (rut, fecha-horas, y detalle del error)

Los datos temporales deben considerar tener un periodo de retención que en el caso de no estar definidos deben considerar ser borrados al cumplir 24 horas o al final del día.

Se debe considerar el modelo de datos para dar soporte al acuerdo de colaboración.

Se debe considerar modelo de almacenaje de documentos temporales.

Se debe validar que el RUT ingresado como firmante sea el mismo ingresado a través de la firma con Clave Única.

Se debe rescatar información de institución previamente almacenada en modelos temporales, para completar la firma del convenio de colaboración. Esta información proviene de una integración aún por definir (SII o SIAPER, eventualmente)

Se debe capturar y registrar errores durante la subida de documentos adjuntos.

Se debe guardar trazabilidad de los datos almacenados (fecha-hora, rut y contenido)

El proceso debe considerar rollback en el caso de que el usuario no complete el proceso de inscripción.

Se debe registrar el rollback con los siguientes datos, ID solicitud, rut, fecha-hora, motivo.

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el form permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rollback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend.

Todas las validaciones de reglas de negocio se deben realizar como base a nivel de backend,

Guardar los en caso de rollback de una tiranización que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rollback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

Utilizar recaptcha en todos los form donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs.

Requerimiento 7

Paso 6 – Comprobante y mensaje de confirmación envío de solicitud

Escenario de uso

El usuario finaliza el flujo de inscripción y recibe confirmación y comprobante

Descripción

Paso final del formulario con mensaje de confirmación de envío y generación de comprobante y notificación.

Criterios generales

Una vez que el usuario completa todos los pasos del formulario de registro, llega a una vista que confirma el envío de su solicitud, además de gatillarse el envío de correo electrónico que confirma este proceso. Se deberá asegurar el envío del dicho correo electrónico.

Adicionalmente se genera un comprobante de dicha solicitud, el cual podrá ser descargado como documento electrónico.

Dentro de esta sección, existirá un acceso directo a los cursos de capacitación especializados para nuevos compradores de Mercado Público, los cuales estarán disponibles en el sitio de capacitación de ChileCompra.

Imagen referencial


Consideraciones técnicas

La solicitud debe quedar registrada con todos los datos ingresados por el usuario y debe considerar adicionalmente ID único, fecha y hora.

Las solicitudes que lleguen al mantenedor se guardan y quedan en el histórico.

En el caso de ser necesario, se entregarán las condiciones para cuando se deba realizar un rollback. En estos casos se deberá registrar dicho rollback con los siguientes datos, ID solicitud, rut, fecha-hora, motivo, entre otros.

Una vez finalizado el proceso, si el usuario vuelve a intentar registrar la misma institución (paso 3) se mostrará un mensaje informando el estado de la solicitud de inscripción. (por institución).

Se crea solicitud de ingreso institución compradora en modelo de datos, con estado pendiente.

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el form permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rolback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend,

Todas las validaciones de reglas de negocio se deben realizar como base a nivel de backend,

Guardar los en caso de rolback de una tiranización que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rolback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

Utilizar recaptcha en todos los formularios donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs.

El pdf descargable debe tener la misma información del comprobante de solicitud.

  • Mantenedor de solicitudes de inscripción

Todas las solicitudes de inscripción serán revisadas por un usuario interno de ChileCompra. El objetivo es filtrar y validar las solicitudes de inscripción.

Requerimiento 8

Mantenedor – Listado de solicitudes ingresadas

Escenario de uso

Persona de la DCCP ingresa para revisar el listado de todas las solicitudes que han sido ingresadas.

Descripción

Mantenedor de solicitudes de incorporación de instituciones ingresadas por usuarios.

Criterios generales

Se deben visualizar las solicitudes mediante una tabla que incluye, ID, estado de solicitud, RUT, fecha de ingreso, ver más detalle y otras acciones, entre otros.

La tabla contendrá la opción de paginar en caso de ser necesario.

Las solicitudes podrán estar organizadas a través de tabs para facilitar la visualización de su estado.

Tendrá la opción de búsqueda a través de distintos filtros.

Cada solicitud tendrá un ID único.

Imagen referencial

Consideraciones técnicas

Los usuarios que acceden a este panel son funcionarios de ChileCompra con acceso al mantenedor a través de https://backoffice.mercadopublico.cl/, por lo que se debe crear el acceso en dicho menú.

El historial de solicitudes terminadas debe permanecer como parte de la información del usuario.

Después de que se cierre la sesión, validar que el token de seguridad haya sido eliminado por completo, para evitar de que sea utilizado por otros servicios.

Se debe manejar token jwt privado para listar solicitudes.

Requerimiento 9

Mantenedor – Ver detalle, aprobar o rechazar solicitud

Escenario de uso

Persona de la DCCP ingresa para aprobar o rechazar solicitudes.

Descripción

Ficha con el detalle de la solicitud. Permite la opción de ser revisadas, aceptadas o rechazadas.

Criterios generales

Al ingresar al detalle de cada solicitud de incorporación, se podrá visualizar toda la información ingresada por el usuario en el formulario de registro, junto con toda la información general de la institución:

Información de la institución/organismo:

-        Razón social,

-        Rut,

-        Dirección

-        Fecha de solicitud

Información del usuario solicitante:

-        Nombre Apellido

-        Rut

Información de la solicitud:

-        Información general de la solicitud

Finalmente, el usuario de la DCCP podrá aprobar o rechazar la solicitud, o editar. En caso de aprobar la solicitud, se le notificará al usuario y quedará habilitado su ingreso a Mercado Público con Clave Única.

En caso de rechazar la solicitud, el usuario solicitante recibirá una notificación con el motivo del rechazo, pudiendo volver a enviar su solicitud.

Existirán modales de confirmación previa acción de rechazar o aprobar.

Imagen referencial


Consideraciones técnicas

Después de que se cierre la sesión, validar que el token de seguridad haya sido eliminado por completo, para evitar de que sea utilizado por otros servicios.

Se debe considerar el traspaso de información entre los modelos temporales a los definitivos, en caso de ser necesario, crear nuevas tablas al modelo existente.

Una vez aprobada la solicitud, se debe considerar el traspaso de documentos temporales a un modelo definitivo. Esto debe considerar que es un modelo asincrono e hibrido, donde el procesamiento temporal es cloud y la inserción al transaccional onpremise debe realizarse mediente un gestor de colas (SQS / RabbitMQ)

Se crea usuario en MP asociado a nueva institución, con el rol que defina el negocio pudiendo editar perfil de empresa en MP (ejemplo: crear nuevos usuarios dentro de la org, editar datos de institución, bloquear usuarios, etc.).

Se debe manejar token jwt privado para la resolución de la solicitud.

Se envía a correo registrado del usuario solicitante la resolución de la solicitud, en caso de que sea aprobada, incluyendo la bienvenida a MP con los datos básicos para primer logueo, sino con los motivos del rechazo.

En el caso de ser necesario, se entregarán las condiciones para cuando se deba realizar un rollback. En estos casos se deberá registrar dicho rollback con los siguientes datos, ID solicitud, rut, fecha-hora, motivo, entre otros.

Como trazabilidad se debe registra (ID_Solicitud, cambio realizado, ID usuario mantenedor, Fecha-hora). Se deben registrar logs de errores.

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el form permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rollback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend. Todas las validaciones de reglas de negocio se deben realizar como base a nivel de backend,

Guardar logs en caso de rollback de una transacción que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rolback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar logs para capturar errores interno y errores de integraciones externas que contengan como mínino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

Utilizar recaptcha en todos los formularios donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs

  • Consideraciones de la Mesa de Arquitectura para este Desarrollo

                 i.          Ambientes en que se desplegará la solución: Desarrollo, Preproducción y Producción

                ii.          Plataformas Mercado Público

              iii.          Lenguajes de Desarrollo: ReactJS, NodeJS, Java17

              iv.          Infraestructura: Cloud con integraciones a Onpremise

                v.          Motor de BBDD: DynamoDB, SQLServer

              vi.          Política de Respaldos:  

  • Para las soluciones a instalar en infraestructura OnPrem:
    • Respaldo full diario de la base de datos
    • Respaldo diferencial cada 1 hora de log de base de datos
    • Si existen archivos a almacenar en fileserver, se sumará a la política ya existente.
    • Para las soluciones a instalar en infraestructura Cloud:
      • Respaldo cada 1 hora de base de datos y con replicación de dicho backup a repositorio Cloud a definir
      • Si existen archivos a almacenar en repositorio Cloud, se definirá política de respaldo/replicación/retención junto con el oferente adjudicado.
      • El código fuente se almacenará en Azure DevOps tanto para soluciones OnPrem como Cloud.

2.        Ficha del organismo comprador

-        Objetivo general: Facilitar el acceso a la información relevante de cada organismo público, de acuerdo a lo que estipula la nueva Ley de Compras Públicas.

-        Objetivo Específicos:

  1. Desarrollar una ficha de compradores.
  2. Facilitar la actualización de datos, por parte de fuentes externas oficiales
  3. Facilitar la actualización de datos por parte de los compradores

-        Requerimientos:

Requerimiento 1

Accesos a la ficha de un comprador

Escenario de uso

Un usuario que se encuentra navegando a través de Mercado Público desea acceder a la información de un organismo comprador

Descripción

En todas las partes que se encuentre presente el nombre de un organismo comprador, ya sean los lugares dentro de la plataforma de Mercado Público o secciones públicas del portal que no requieren login, deberán ser un link de acceso a la ficha de cada organismo comprador.

Criterios generales

Las siguientes secciones que muestran el nombre de un comprador debiesen funcionar como link a la ficha de comprador:

  • Gestión de Contratos
  • Compra Ágil
  • Órdenes de compra
  • Grandes Compras
  • Licitaciones
  • Cotizaciones
  • Otros mecanismos que se habiliten de acuerdo a la modernización de la ley de compras

Imagen referencial

Consideraciones técnicas

Considerar el resguardo de la información y o componentes que se muestran u ocultan en cada perfil del usuario, ya sea comprador, proveedor o público. Tener en cuenta que esta información no sea accesible al modificar el dom en la consola del navegador.

Se deberá modificar de forma transversal los módulos .NET y React en los cuales se haga referencia al comprador para poder integrar la ficha.

Considerar la modificación del menú principal para que apunte al nuevo sitio React de administración de datos del organismo.

Requerimiento 2

Información del organismo comprador

Escenario de uso

Un usuario se encuentra navegando a través de la ficha de un organismo comprador

Descripción

La ficha de organismo comprador contiene un componente que muestra toda la información general y de contacto de un comprador

Criterios generales

Esta sección debe contener:

  • Razón social y RUT del organismo comprador
  • Sector al que pertenece
  • Dirección
  • Teléfono
  • Sitio web
  • Correo electrónico

Imagen referencial

Consideraciones técnicas

Se deberá validar que el campo de razón social esta correcto para los compradores, de la misma forma en que se realizó una limpieza de datos para los proveedores.

Considerar normalización en modelo de datos para obtener los datos de contacto, ya que estos están a nivel de unidades de compra.

Se consideran tecnologías AWS como Opensearch, Amplify, Lambda, Ficha del Comprador.


Además se debe considerar el manejo de roles por token de SSO/keycloak.

Requerimiento 3

Cifras del organismo comprador

Escenario de uso

Un usuario se encuentra navegando a través de la ficha de un organismo comprador

Descripción

La ficha de organismo comprador contiene un componente que muestra información resumida en un año calendario del comprador

Criterios generales

Esta sección debe contener:

  • Monto transado por el organismo comprador.
  • Número de reclamos recibidos en base al número de órdenes de compra emitidas.
  • Promedio de días de Pago, esta sección solo estará disponible para aquellos compradores que utilizan SIGFE.
  • Botón de acceso a la ficha de este organismo comprador en el portal de Datos Abiertos de ChileCompra.
  • Botón para descargar la ficha del comprador en formato PDF y considerando almacenamiento temporal del archivo generado

Imagen referencial

Consideraciones técnicas

Tener cuidado en cómo se redirecciona desde un perfil privado de la ficha, hacia datos abiertos que es un sitio público y viceversa. El PDF será construido en el back.

Considerar si existe el servicio en datos abiertos para consumir la información asociada al comprador, lo mismo para la cantidad de reclamos y días de pago, caso contrario se deberán construir.

Requerimiento 4

Ficha de organismo comprador:

Tab de información general

Escenario de uso

Un usuario se encuentra navegando a través de la ficha de un organismo comprador

Descripción

La ficha de organismo comprador está compuesta por 5 tabs con distintos tipos de información, el primero es el tab de información general

Criterios generales

Este tab debe contener:

  • Información de contacto del administrador del organismo en Mercado Público
  • Información de la máxima autoridad de la institución

Imagen referencial

Consideraciones técnicas

Se debe Considerar la creación de un modelo de datos que permita almacenar esta información y que luego pueda ser administrada por el usuario, asociada a nivel de empresa.

La información de la máxima autoridad no existe en el servicio civil? Ya que la información quedará en blanco hasta que el comprador la ingrese. Si existe se sugiere generar una carga inicial a través de un servicio que podamos consumir.

Requerimiento 5

Ficha de organismo comprador:

Plan Anual de Compras

Escenario de uso

Un usuario se encuentra navegando a través de la ficha de un organismo comprador

Descripción

La ficha de organismo comprador está compuesta por 5 tabs con distintos tipos de información, el segundo es el tab de plan anual de compras

Criterios generales

Este tab debe contener:

  • Información de los montos ejecutados por el comprador durante los meses del año actual
  • Información sobre las órdenes de compra que se han generado fuera de la planificación

Imagen referencial

Consideraciones técnicas

Para el layout que contiene el gráfico y la tabla con información, se puede sacar desde el repositorio de datos abiertos (Frontend).

Esa información no existe en datos abiertos, por lo que se debe considerar la construcción del gráfico y el servicio.

Requerimiento 6

Ficha de organismo comprador:

Órdenes de compra

Escenario de uso

Un usuario se encuentra navegando a través de la ficha de un organismo comprador

Descripción

La ficha de organismo comprador está compuesta por 5 tabs con distintos tipos de información, el tercero es el tab de órdenes de compra

Criterios generales

Este tab debe contener:

  • Información de las órdenes de compra emitidas por el organismo comprador, por mecanismo de compra, además del estado en el que se encuentran.

Imagen referencial

Consideraciones técnicas

Los gráficos se pueden obtener desde el repositorio de datos abiertos (Frontend).

Se sugiere igualar el diseño a datos abiertos, es ideal poder reutilizar lo que ya está construido.

Requerimiento 7

Ficha de organismo comprador: Reclamos

Escenario de uso

Un usuario se encuentra navegando a través de la ficha de un organismo comprador

Descripción

La ficha de organismo comprador está compuesta por 5 tabs con distintos tipos de información, el cuarto es el tab de reclamos recibidos

Criterios generales

Este tab debe contener:

  • Información con el número y tipos de reclamos recibidos por el organismo comprador.

Imagen referencial

Consideraciones técnicas

Los gráficos se pueden obtener desde el repositorio de datos abiertos (Frontend).

Si Información no existe en datos abiertos, el proveedor adjudicado lo deberá construir.

Requerimiento 8

Ficha de organismo comprador:

Demandas en el Tribunal de Contratación Pública

Escenario de uso

Un usuario se encuentra navegando a través de la ficha de un organismo comprador

Descripción

La ficha de organismo comprador está compuesta por 5 tabs con distintos tipos de información, el quinto es el tab de demandas ante el Tribunal de Contratación Pública

Criterios generales

Este tab debe contener:

  • Información con el número y tipos de demandas recibidas en el Tribunal de Contratación Pública
  • Una tabla con el listado de las demandas recibidas durante el último año calendario, al hacer clic sobre el ROL de alguna demanda el usuario es redireccionado a la ficha de esa demanda

Imagen referencial

Consideraciones técnicas

Los gráficos se pueden obtener desde el repositorio de datos abiertos (Frontend).

Debe consumir la componente transversal de integración con el Tribunal de Contratación Pública,

Al hacer clic sobre el ROL de alguna demanda el usuario es redireccionado a la ficha de esa demanda, del sistema del Tribunal de Contratación Pública.

Requerimiento 9

Buscador de compradores

Escenario de uso

Un usuario se encuentra navegando a través de Mercado Público y desea buscar un organismo comprador específico

Descripción

Al buscador actual de proveedor, incluir la opción de seleccionar la búsqueda de compradores, de esta forma los usuarios podrán buscar directamente la ficha de un comprador en Mercado Público.

Criterios generales

El mismo buscador debe funcionar para la búsqueda de organismos compradores y proveedores del Estado, ya sea por razón social, RUT e ID extranjero en el caso de los proveedores.

Imagen referencial


Consideraciones técnicas

Será un buscador público.

La búsqueda se habilitará a proveedores y compradores. En la actualidad el buscador de proveedores sólo está disponible para compradores (en el menú de licitación) y para usuarios públicos con ficha reducida, y funcionará distinto para la ficha del comprador.

Considerar que se debe modificar el buscador de proveedores actual para soportar ambas búsquedas, y que la ficha de comprador sea en un proyecto independiente de front.

Se debe utilizar recaptcha para el buscador.

La base de datos utilizada por la búsqueda  es  NOSQL, por lo que hay que considerar migración de información al módulo de búsqueda basado en OpenSearch de AWS, por tanto se debe utilizar integrándose y realizando las modificaciones necesarias para la nueva búsqueda.

Requerimiento 10

Editar información del organismo comprador

Escenario de uso

Un usuario comprador desea editar la información que se muestra de su institución en la ficha de comprador de Mercado Público

Descripción

Se debe actualizar el módulo actual de “Editar información del organismo público”

Criterios generales

El módulo debe permitir actualizar la siguiente información de un organismo comprador:

  • Sitio web
  • Correo electrónico
  • Teléfono

Además de permitir modificar la información de su máxima autoridad, debe considerar la opción de agregar un subrogante, para ambos casos la información que se debe poder editar para ambos casos es:

  • RUT
  • Nombres y apellidos
  • Cargo
  • Correo electrónico
  • Teléfono laboral

Imagen referencial

Consideraciones técnicas

Presentación de datos no modificables.

Considerar que las validaciones del formulario sean tanto en front como en back.

Se debe crear un modelo de datos que contenga la información general de la entidad, ya que actualmente esta información está asociada a la unidad de compra.

  • Consideraciones de la Mesa de Arquitectura para este Desarrollo

                 i.          Ambientes en que se desplegará la solución: Desarrollo, Preproducción y Producción

                ii.          Plataformas: Mercado Público (Openshift, SQL Server, AWS y Datos Abiertos)

              iii.          Lenguaje de Desarrollo: ReactJS, NodeJS, Java17

              iv.          Infraestructura on premise o nube:  Cloud con integraciones a Onpremise

                v.          Motor de BBDD: OpenSearch, SQLServer

              vi.          Política de Respaldos: La DCCP informará las políticas de respaldo

3.        Información de compradores en los procesos de compra

-        Objetivo general: Facilitar el acceso a la información de quienes participan de procesos de compra a los organismos de Fiscalización y Control.

-        Objetivo Específicos:

  1. Recoger la información de los participantes en cada proceso de compra.
  2. Disponer de la información a los organismos de Control identificados en la modificación de la Ley.

-        Requerimientos:

Requerimiento 1

Acceso a listado de participantes de un proceso de compra

Escenario de uso

Usuario comprador desea acceder a revisar y/o editar el listado de participantes de alguno de sus procesos de compra

Descripción

Es necesario incluir un acceso al listado de participantes de cada proceso de compra en los distintos módulos relacionados  como por ejemplo:

  • Orden de compra
  • Cotizaciones
  • Licitaciones
  • Gestión de contratos
  • Compra Ágil
  • Trato Directo
  • Subasta Inversa Electrónica (*)
  • Contratos para la innovación (*)
  • Diálogos competitivos (*)
  • Otros mecanismos futuros.

(*) Mecanismos nuevos de compra que estarán disponibles a mediados del 2025.

Imagen referencial

Consideraciones técnicas

Proyectos en Visual Basic .NET Framework 4.8

  • Cotizaciones
  • Licitaciones
  • Orden de compra

C# .NET Framework 4.8:

  • Gestión de contratos

ReactJS:

  • Trato Directo
  • Compra Ágil

Solo se necesita redirección desde el botón nuevo a proyecto en ReactJS, este debe poder identificar el proceso de compra.

Requerimiento 2

Módulo de participantes de un proceso de compra

Escenario de uso

Usuario comprador accedió al módulo a revisar y/o editar el listado de participantes de alguno de sus procesos de compra

Descripción

El nuevo módulo de listado de participantes de un proceso de compra permite que un usuario comprador pueda acceder y editar las personas que desempeñaron alguna función dentro de un proceso de compra.

Criterios generales

El módulo cuenta con 3 secciones:

La primera es una tabla con la siguiente información por cada participante del proceso de compra:

  • Nombre y apellido
  • Cargo del participante
  • Función dentro del proceso de compra
  • RUT
  • Correo electrónico

Además, permite descargar la tabla en formato Excel y cuenta con la opción de agregar nuevos participantes.

La segunda sección permite al usuario conocer el mecanismo de compra que se utilizó en este proceso, si tiene una ficha de contrato asociada, y la o las órdenes de compra que puede tener asociadas.

La tercera sección es informativa y describe las distintas funciones que podría ejercer una persona en un proceso de compra, ya sea requirente, autorizador, firmante, comisión evaluadora, etc.

Imagen referencial

Consideraciones técnicas

Módulo debe ser desarrollado con React.js y el Backend con Java 17 SpringBoot. Además, utilizando tecnologías de aws cloud como Amplify, Lambda, RDS

Asociar funciones a procesos de compra, para que se asigne al versionamiento, considerar skill técnico según req 1.

Guardar logs con fechas, hora de edición, usuario que modifica, etc.

Debe cumplir con el estándar de seguridad de la información indicado por la DCCP.

Requerimiento 3

Añadir participantes

Escenario de uso

Usuario comprador desea añadir participantes al proceso de compra

Descripción

El módulo cuenta con la opción de agregar nuevos participantes a un proceso de compra, ya sea seleccionando una persona que ya participó en procesos anteriores o crear una nueva persona.

Criterios generales

Para añadir participantes el usuario tendrá dos opciones:

  • La primera es seleccionar una persona de la tabla que contendrá todas personas que hayan participado de un proceso de compra durante el último año.
  • La segunda es crear una nueva persona, este registro se añadirá a la tabla, los datos que debe ingresar son:
    • RUT de la persona (mediante conexión con el registro civil se autocompletarán los campos de nombres y apellidos cargo)
    • Cargo
    • Correo electrónico
    • Declarar si la persona es funcionaria pública
    • Declarar si la persona forma parte de su institución

Luego hacer clic en el botón “añadir persona al listado”.

Una vez que el usuario tenga seleccionada a la persona que desea agregar como participante, debe elegir una función desde el selector de funciones, para luego hacer clic en el botón “añadir participante”

Imagen referencial

Consideraciones técnicas

Presentación de datos no modificables.

Considerar que las validaciones del formulario sean tanto en front como en back.

Debe existir una integración con el Registro Civil.

Agregar validaciones básicas cuando ingresa el correo electrónico.

Requerimiento 4

Comprobante de emisión de orden de compra

Escenario de uso

Usuario comprador creó y envío a autorizar una orden de compra

Descripción

Durante el proceso de creación de una orden de compra se declaran algunos participantes del proceso de compra. Es necesario consolidar esta información y que sea de fácil acceso.

Criterios generales

Una vez que se envíe a autorizar una nueva orden de compra, es necesario reemplazar la “alerta” actual del navegador por un “comprobante” de emisión de orden de compra que permita al usuario comprador:

  • Ver con mayor facilidad información de la orden de compra creada, como su ID
  • Un enlace para volver al listado de órdenes de compra y
  • El listado de participantes del proceso de compra obtenidos a partir de la orden de compra
  • Acceso a añadir más participantes a través del nuevo módulo de participantes.

Imagen referencial

Consideraciones técnicas

Comprobante deberá ser desarrollado en módulo actual de OC.

Se necesita redirección desde el botón “Ir al listado de participantes” a página en React.

  • Consideraciones de la mesa de arquitectura.

                           i.          Ambientes en que se desplegará la solución: Desarrollo, Preproducción y Producción

                          ii.          Plataformas Mercado Público

                        iii.          Lenguaje de Desarrollo: ReactJS, NodeJS, Java17

                        iv.          Infraestructura : Cloud con integraciones a Onpremise

                          v.          Motor de BBDD: DynamoDB, SQLServer

                        vi.          Política de Respaldos: La DCCP informará las políticas de respaldo

4.        Integración con información del Tribunal de Contratación Pública.

-        Objetivo general: Implementar una componente transversal, que le permita a Mercado Público, contar con la información de los procesos (demandas, causas u otro), sobre procesos de compra, provenientes del Tribunal de Contratación Pública.

-        Objetivo Específicos:

  1. Desarrollo e implementación de una funcionalidad transversal, que nutra de información de causa del Tribunal de Contratación Pública, en los procesos de compra a Mercado Público.
  2. Integración con Servicios de información disponibles, desde la plataforma de procesos del Tribunal de Contratación Pública.

-        Requerimientos:

Requerimiento 1

Funcionalidad transversal de información de causas del Tribunal de Contratación Pública

Escenario de uso

Productos de Mercado Público requieren contar con la información de las causas asociadas a los procesos de compra y contratación pública, provenientes del Tribunal de Contratación Pública

Descripción

Los productos de Mercado Público, que deben contar con la información de las causas asociadas a los procesos de contratación o al organismo público, deben obtener esta información desde una componente transversal que, al consultarla, entrega la información correspondiente

Criterios generales

Consumir información desde el sistema de causas del Tribunal de Contratación Pública.

Generación de una solución transversal, que disponibilice la información del sistema del Tribunal de Contratación Pública, que pueda ser llamada desde los distintos productos de Mercado Público

Imagen referencial

No aplica

Consideraciones técnicas

En caso de que al momento del desarrollo, no estuviesen disponibles los servicios por el lado del Tribunal de Contratación Pública, el proveedor adjudicado debe desarrollar servicios dummies para conexión posterior.

II.        Línea de Servicio N°2

1.        Actualización de Trato Directo

-        Objetivo general: Implementar los desarrollos necesarios para dar fiel cumplimiento a las modificaciones realizadas a la ley de compras que se desprenden del pilar de probidad y transparencia, con respecto al mecanismo de compra excepcional Trato directo.

-        Objetivo Específicos:

  1. Generar funcionalidades permitan identificar las causales y montos que deberán contener publicidad previa a su adjudicación.
  2. Desarrollar e implementar sección especial para tratos directos con buscador idealmente con tecnología Elasticsearch.

-        Requerimientos:

La nueva solución tiene por objetivo permitir la creación de procesos a través de este mecanismo de compra. Dentro del módulo se listarán todos los “Tratos Directos” realizados por el comprador, será posible realizar una búsqueda por palabra clave, causal y estado de los “Tratos Directos”, además de filtrar la búsqueda por proveedor, fecha, entre otros. El usuario ingresará a una nueva pestaña al hacer clic en “Trato Directo” en el menú de navegación de Mercado Público.

Requerimiento 1

Listado de Tratos Directos

Escenario de uso

El usuario comprador accede al nuevo módulo de Trato Directo, llegando al listado con todos ellos los de su institución / unidad.

Descripción

Nuevo módulo que lista todos los procesos de compra realizado a través de Trato Directo por el comprador es posible buscar por palabra clave, causal de Trato Directo y filtrar los resultados por proveedor o rango de fecha de creación, entre otros.

Criterios generales

Este nuevo módulo debe contar con:

-Información sobre lo que es un Trato Directo y acceso a material de capacitación.

-Filtros de búsqueda.

-Acceso a crear un nuevo Trato Directo, el cual se abrirá en una nueva pestaña.

-Listado de todos los procesos de Tratos Directo realizados por el usuario comprador (resultados de búsqueda). Cada uno de ellos corresponde a un ítem que contiene un ID del Trato Directo, el nombre, la causal de Trato Directo utilizada, el Monto por el cual se realizó, proveedor, fecha de creación y el estado en el que se encuentra la orden de compra.

- Desde cada ítem se puede acceder al detalle (ficha) de cada Trato Directo.

-Filtros secundarios para acotar el número de “Tratos Directos” en la lista, estos filtros pueden ser por nombre del proveedor, rango de fecha de creación, entre otros. La DCCP cuenta con un módulo de búsqueda basado en OpenSearch de AWS, por tanto se debe utilizar integrándose y realizando las modificaciones necesarias para la nueva búsqueda.

Imagen referencial

Consideraciones técnicas

Tener en cuenta que serán dos perfiles para esta pantalla (comprador y proveedor).

Considerar descarga de excel de los resultados de búsqueda y la forma más optima de realizarlo.

Considerar utilizar elasticsearch para la búsqueda y lo que implica migrar los datos (etls, jobs, etc.)

Considerar uso de Logstach para cambios de estado.

Considerar uso de keycloak para single sign on tanto en back como en front.

Considerar integración con notificador de correos con AWS.

Incluir notificación dentro de oportunidades de negocio

Guardar errores ocurridos al momento de realizar búsqueda y los servicios que componen la búsqueda.

Se deben crear lista blanca para permitir en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Las fichas o vistas de los tratos directos no deben ser construida sobre componentes que permitan modificar contenido (ej. Form, MS con acceso de escritura, otros)

Las validaciones de permisos, autorización y roles se deben realizar en backend.

utilizar recaptcha en todos los form donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs

-          Creación de nuevo Trato Directo

El nuevo formulario de creación de Trato Directo tiene por objetivo eliminar la creación de estos a través del módulo de orden de compra y consolidar todo el proceso dentro este módulo. Cada Trato directo creado, generará una ficha con toda la información ingresada. El formulario de creación tendrá dos versiones, dependiendo de la causal que se seleccione en el paso 1.

Requerimiento 2

Formulario de creación de Trato Directo – Paso 1

Escenario de uso

Un usuario comprador desea crear un nuevo Trato Directo.

Descripción

El formulario de creación de Trato Directo permite a un usuario comprador crear un nuevo procedimiento de compra a través de este mecanismo.

Criterios generales

El nuevo formulario será por pasos. En el primer paso es necesario que el usuario seleccione la causal de trato directo dentro del listado disponible, declarar si el monto de compra será superior a las 1.000 UTM y la justificación del Trato Directo.

Dependiendo de la causal que seleccione y el monto, el siguiente paso (Paso 2) cambiará.

Imagen referencial

Consideraciones técnicas

Considerar que las validaciones del formulario sean tanto en front como en back.

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el form permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos).

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rolback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Guardar los en caso de rolback de una transacción que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

Las validaciones de permisos, autorización y roles se deben realizar en backend

utilizar recaptcha en todos los form donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs

Considerar que, al generar un nuevo trato directo, el código externo deberá seguir el patrón que tienen los demás procesos (código unidad de compra-correlativo-sufijo+año, ej: 500977-32-TD23), y al cambiar de año el correlativo vuelve a 1.

*Entendiendo que hay “pasos” de creación, ¿se guardarán en el borrador pasos completos o medios pasos también?

Requerimiento 3

Formulario de creación de Trato Directo – Paso 2

Causales: Proveedor Único y Confianza y Seguridad

Escenario de uso

Un usuario comprador desea crear un Trato Directo para las dos causales de: Proveedor único y Confianza y seguridad.

Descripción

Paso 2 del formulario de creación de Trato Directo, para las causales mencionadas.

Criterios generales

El paso 2 del formulario permite al usuario ingresar los principales campos de información requeridos, entre los cuales se encuentran:

-Nombre y descripción

-Vigencia de la contratación

-Moneda

-Fecha de cierre de recepción de observaciones.

-Proveedor (Ingresa el RUT y se autocompleta según la información del registro de proveedores)

-Productos/Servicios a cotizar, ingreso de los productos/servicios que comprará a través de este nuevo Trato Directo, debe permitir navegar a través del catálogo de productos e ingresar cantidad y monto unitario de cada producto, entre otros.

-En base a la suma del monto unitario de todos los productos se desplegará el monto total del Trato Directo.

-Dirección de entrega (región, comuna, dirección)

-Adjuntar cotizaciones en caso de que la causal de Trato Directo seleccionada lo requiera. (RUT del cotizante, teléfono, correo electrónico y adjuntar archivo.

Al presionar el botón de “Crear Trato Directo” se gatilla un aviso previo que explica que debido a la causal seleccionada y al monto del Trato Directo, este quedará publicado en estado “recibiendo respuestas”.

Al aceptar el aviso se generará la ficha del Trato Directo y los proveedores podrán ingresar comentarios y observar el trato directo.

Considerar trazabilidad de las operaciones realizadas por el usuario (ID_Usuario, ID_TratoDirecto, Fecha_Hora, detalle Operaciones realizadas).

Imagen referencial

Consideraciones técnicas

Presentación de datos no modificables.

Generar integración con Componente Transversal Adjuntos en AWS

Considerar que las validaciones del formulario sean tanto en front como en back.

Considerar la utilización de la información de feriados.

Considerar la utilización del servicio de monedas para hacer la conversión.

Considerar el correcto uso de decimales para el tipo de moneda seleccionada y la cantidad de estos, ej: 2 para dólar, 4 para utm.

Considerar el impuesto o cargo asociado con el que se generará la orden de compra.

Considerar costo del despacho.

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el form permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rolback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Guardar los en caso de rolback de una tiranización que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rolback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

Las validaciones de permisos, autorización y roles se deben realizar en Backend

Utilizar recaptcha en todos los form donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs

Si este producto llega a ser full nube, hay que disponibilizar los servicios que se requieran para llevar la información desde onpremise a la nube, al menos toda la capa de servicios (Registro de Proveedores, catálogo, etc.)

Requerimiento 4

Formulario de creación de Trato Directo – Paso 2

Otras causales

Escenario de uso

Un usuario comprador desea crear un Trato Directo para otras causales distintas a Proveedor único y Confianza y seguridad

Descripción

Paso 2 del formulario de creación de Trato Directo, para otras causales.

Criterios generales

El paso 2 del formulario permite al usuario ingresar los principales campos de información requeridos, entre los cuales se encuentran:

-Nombre y descripción

-Vigencia de la contratación

-Moneda

-Proveedor (Ingresa el RUT y se autocompleta según la información del registro de proveedores)

- El sistema no debe permitir el registro de proveedores que se encuentren en estado inhábil, según el cálculo que realiza Registro de Proveedores de Mercado Público.

-Productos/Servicios a cotizar, ingreso de los productos/servicios que comprará a través de este nuevo Trato Directo, debe permitir navegar a través del catálogo de productos e ingresar cantidad y monto unitario de cada producto, entre otros.

-En base a la suma del monto unitario de todos los productos se desplegará el monto total del Trato Directo, pudiendo configurarse los impuestos.

-Dirección de entrega (región, comuna, dirección)

-Adjuntar cotizaciones en caso de que la causal de Trato Directo seleccionada lo requiera. (RUT del cotizante, teléfono, correo electrónico y adjuntar archivo.

Al presionar el botón de “Crear Trato Directo” el usuario llegará a un comprobante de creación, se generará la ficha de trato directo y el usuario puede decidir si revisar la ficha del Trato Directo o emitir directamente la orden de compra.

Todo trato directo debe poder guardarse y eliminarse de ser necesario.

Imagen referencial

Consideraciones técnicas

*Monto total debiese estar asociado a los productos y se genera con el total de impuestos/cargos, etc.

Considerar la utilización de la información de feriados.

Considerar utilización del servicio de monedas para hacer la conversión.

Considerar el correcto uso de decimales para el tipo de moneda seleccionada y la cantidad de estos, ej: 2 para dólar, 4 para utm.

Considerar el impuesto asociado con el que se generará la orden de compra.

Presentación de datos no modificables.

Considerar que las validaciones del formulario sean tanto en front como en back.

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el form permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rolback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend

Guardar los en caso de rolback de una tiranización que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rolback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

utilizar recaptcha en todos los form donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs

-          Listado de Trato Directo

El nuevo módulo de Trato Directo permitirá a los proveedores revisar todas las fichas de trato directo publicadas. Para los tratos directo de tipo causal “Si solo existen un proveedor del bien o servicio” y/o “Confianza del proveedor, derivada de su experiencia” cuando sean compras por sobre 1.000 UTM, los proveedores podrán ingresar a dicha ficha para comentar y participar durante el periodo que estén abiertas a recibir consultas.

Requerimiento 5

Buscador de Trato directo - proveedor

Escenario de uso

Un usuario proveedor desea acceder al listado de tratos directos y aviso de Trato Directo generados por los organismos compradores.

Descripción

Módulo que lista todos los tratos directos y avisos de Trato Directo creados por cada organismo comprador. Permite filtrar y buscar entre el listado.

Criterios generales

Se listan todos los tratos directos y los avisos de Trato Directo creados por el comprador

Es posible buscar por palabra clave, causal de Trato Directo y filtrar los resultados por proveedor o rango de fecha de creación, entre otros.

Se entregarán las reglas para listar resultados (publicados recientemente, por fecha de cierre, etc).

Permite también filtrar “ver solamente los avisos de mis rubros” o “ver avisos en los que he participado”, entre otros.

Imagen referencial

Consideraciones técnicas

Considerar la performance al realizar la búsqueda con filtros.

La vista pública y la vista privada debe tener otra pantalla. Además, la pantalla comprador (privada) también es distinta a la proveedor (privada).

Se sugiere limitar/definir (1 mes, 2 o 3, dependiendo de la masividad) los rangos de fechas de búsqueda, pues plazos muy grandes afectan la performance.

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el form permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rolback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend

Guardar los en caso de rolback de una transacción que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rolback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

utilizar recaptcha en todos los form donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs

-          Ficha de trato directo

La ficha contiene toda la información de cada trato directo. Según el tipo de trato directo, la ficha permitirá hacer comentarios a los proveedores o no. Existen dos tipos de ficha:

-        Ficha de Trato directo Proveedor Único y Confianza y Seguridad

-        Ficha de otras causales de Trato Directo

Requerimiento 6

Ficha de Trato Directo

Tipo: Causal de Proveedor Único y Confianza

Escenario de uso

Usuario proveedor puede revisar e ingresar comentarios en una ficha publicada de trato directo de este tipo.

Descripción

Ficha con información de trato directo. Permite ingreso de comentarios mientras estén dentro de un rango de fecha determinado.

Criterios generales

La ficha de trato directo contiene toda la información ingresada por el comprador correspondiente.

Para este tipo de tratos directos de proveedor único y confianza, se habilitará una sección para el ingreso de comentarios y observaciones, que contendrá información como:

-        Identificación del proveedor que ingresa comentario (oculta)

-        Pregunta u observación

-        Adjuntos

-        Otros

con sección tipo foro que permite al proveedor ingresar información.

Se podrán ver todas las respuestas mediante un componente que permita ver más.

Debe considerar información de causas del Tribunal de Contratación Pública, Información con el número y tipos de demandas recibidas en el proceso, cuando corresponda. Al hacer clic sobre el ROL de alguna demanda el usuario es redireccionado a la ficha de esa demanda.

Imagen referencial

Consideraciones técnicas

Considerar ampliar la fecha de cierre

Configurar que las cotizaciones adjuntas sean públicas en el estado de recepción de respuestas

Considerar uso de componente transversal para adjuntos en stack actual.

Considerar que módulo legado .net registre las cotizaciones (adjuntos) en el paso correspondiente una vez generada la OC.

Considerar flujo que, en caso que un proveedor envíe sus servicios, el comprador deba hacer una licitación

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el form permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rolback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend

Guardar los en caso de rolback de una tiranización que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rolback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

utilizar recaptcha en todos los form donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs

Debe considerar consumir información desde la componente transversal de Información del Tribunal de Contratación Pública, para la información de las causas asociadas al proceso de contratación.

Al hacer clic sobre el ROL de alguna demanda el usuario es redireccionado a la ficha de esa demanda, del sistema del Tribunal de Contratación Pública.

Requerimiento 7

Ficha de Trato Directo

Tipo: Otras causales

Escenario de uso

Usuario proveedor puede revisar ficha de trato directo de este tipo. Puede revisar la o las órdenes de compra asociada a dicho trato directo.

Descripción

Ficha con información de trato directo y órdenes de compra asociadas.

Criterios generales

La ficha de trato directo contiene toda la información ingresada por el comprador correspondiente.

Contiene enlace a órdenes de compra asociadas a dicho trato directo.

Imagen referencial

Consideraciones técnicas

Considerar los estados de la orden de compra al momento de mostrarla en la ficha, ya que no todos los estados son públicos.

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el formulario permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rollback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend

Guardar los en caso de rolback de una tiranización que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rolback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

utilizar recaptcha en todos los form donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs

-          Módulo orden de compra

Se eliminará la opción de crear Trato Directo en el módulo de orden de compra, por lo cual se deben quitar todas las causales de Trato Directo del paso N°10.

Requerimiento 8

Eliminar causales del módulo de orden de compra

Escenario de uso

Un usuario comprador que desea crear una orden de compra por Trato Directo no podrá continuar con este proceso a través del módulo actual de orden de compra

Descripción

Los compradores que deseen generar un nuevo Trato Directo deberán realizar este proceso desde el nuevo módulo, no desde el módulo de orden de compra

Criterios generales

Eliminar las causales de contratación excepcional del paso número de 10 del proceso de creación de orden de compra.

Todos los tratos directos deberán ser generados previamente en el módulo dispuesto para ello. Una vez generados podrán generar orden de compra con los campos prellenados.

Imagen referencial

Consideraciones técnicas

Considerar que el módulo está desarrollado en Visual Basic .NET Framework 4.8.

Será necesario agregar lógica adicional ya que no se podrán desactivar por base de datos los registros a ocultar ya que serán necesarios para crear la orden de compra.

*Se deberá generar interacción de cómo se verá este paso cuando se genera una OC normal, que proviene de la, de compra ágil, etc, ya que el tipo se debiese seguir mostrando.

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el form permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rolback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend

Guardar los en caso de rolback de una tiranización que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rolback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

utilizar recaptcha en todos los form donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs

-          Vista pública

Se debe generar un buscador público de Trato Directo que permita a los usuarios de Mercado Público acceder a las fichas de Trato Directo generadas por cada organismo comprador.

Requerimiento 9

Buscador público

Escenario de uso

Usuario sin login desea revisar todos los Tratos Directos realizados por los organismos compradores de Mercado Público

Descripción

Buscador público para que los usuarios que accedan al portal de Mercado Público tengan acceso a la información de Trato Directo de los organismos compradores

Criterios generales

Desde el home de Mercado Público el usuario podrá acceder a “Trato Directo”.
El buscador público debe permitir a los usuarios acceder al listado de Tratos Directos creados por los organismos compradores, este debe permitir buscar
por palabra clave, n° de trato directo, causal, estado, entre otros filtros de búsqueda. Además de poder filtrar por organismo comprador y proveedor.

En caso de tener orden de compra asociada, esta debe ser visible.

Imagen referencial

Consideraciones técnicas

Considerar integración con solución de buscadores con distintos filtros.

Considerar uso de recaptcha.

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el form permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rolback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend

Guardar los en caso de rolback de una tiranización que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rolback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

  • Consideraciones de la Mesa de Arquitectura para este Desarrollo

  1. Ambientes en que se desplegará la solución: Desarrollo, Preproducción y Producción
  2. Plataformas Mercado Público
  3. Lenguaje de Desarrollo: ReactJS, NodeJS, Java17
  4. Infraestructura on premise o nube:  Cloud con integraciones a Onpremise
  5. Motor de BBDD: OpenSearch, SQLServer
  6. Política de Respaldos: La DCCP informará las políticas de respaldo

2.        Actualización de Compra Ágil

-        Objetivo general: Implementar mejoras al aplicativo en operación que permitan cumplir con modificaciones de nueva ley de compras.

-        Objetivo Específico:

  1. Generar mejoras impulsadas a generar mayor participación de proveedor con énfasis en MIPYMES locales

-        Requerimientos:

Requerimiento 1

Modificar valor máximo UTM para Compra Ágil

Escenario de uso

La persona compradora podrá crear una Compra Ágil de hasta 100 UTM

Descripción

Se debe modificar el valor de UTM 30 actuales a UTM 100 que se establece en nueva ley de compra. (monto total incluyendo impuestos).

Criterios generales

Al generar cambio en parámetro de monto tope para Compra Ágil este debe cambiar a ese nuevo tope para todos los campos que consideren este valor en el aplicativo.

Debe permitir a usuarios compradores ingresar un presupuesto estimado de hasta 100UTM, realizando el cálculo en todas las monedas disponibles.

-        USD Dólar

-        UTM

-        Unidad de Fomento UF

-        Peso Chileno

-        Euro

Imagen referencial

No aplica

Consideraciones técnicas

Revisar el servicio de UTM.

Este desarrollo se encuentra realizado y en producción, por lo que se debe actualizar tabla con valor y habilitar para que se realice el cálculo correspondiente.

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el form permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rolback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend,

Todas las validaciones de reglas de negocio se deben realizar como base a nivel de backend,

Guardar los en caso de rolback de una tiranización que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rolback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

utilizar recaptcha en todos los form donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs

Requerimiento 2

Habilidad proveedores

 

Escenario de uso

Los usuarios proveedores deberán estar en estado HÁBIL para poder ingresar una cotización

 

Descripción

Validación de estado de habilidad al momento de ingresar y enviar cotización en una Compra Ágil.

 

Criterios generales

El cálculo de habilidad es un servicio existente, se debe generar la validación de este parámetro cada vez que un proveedor ingrese y envía una cotización en Compra Ágil.

Si proveedor no está en este estado, no debe poder enviar su oferta.

Adicionalmente se debe generar el elemento gráfico tipo modal y también en página que permita comunicar el ok o no ok de la habilidad para poder ofertar en Compra Ágil.

 

Imagen referencial


 

Consideraciones técnicas

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el form permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rolback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend,

Todas las validaciones de reglas de negocio se deben realizar como base a nivel de backend,

Guardar los en caso de rolback de una tiranización que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rolback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

utilizar recaptcha en todos los form donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs

Requerimiento 3

Apertura diferida - Selección de proveedor pyme regional

Escenario de uso

Una vez llegada la fecha de cierre de la Compra Ágil, el usuario comprador puede visualizar los proveedores que ofertaron, pymes y regionales, de acuerdo a la dirección de entrega, en primera instancia. En caso de no recibir ofertas de este tipo de proveedores, o las ofertas recibidas son declaradas inadmisibles, podrá visualizar las otras ofertas recibidas

Descripción

Al cerrar el plazo de Compra Ágil, debe filtrar y separar aquellas ofertas que provienen de pequeñas y medianas empresa regionales, según dirección del despacho, del resto que no cumplen con esta condición.

Criterios generales

Al cerrar la compra ágil, la selección de proveedores debe permitir sólo seleccionar ofertas Mipymes regionales inicialmente.

Sólo al no existir ofertas válidas que cumplan con lo anterior o el usuario comprador declara inadmisibles todas las ofertas que no cumplan con lo solicitado en la Compra Ágil, debiendo justificar. Cuando esto ocurra, podrá visualizar  todas las otras cotizaciones recibidas, pudiendo seleccionarlas.

El declarar inadmisibles las ofertas, el Usuario comprador podrá seleccionar una de las siguientes alternativas:

  1. El producto o servicio ofertado no cumple con las especificaciones solicitadas
  2. El valor ofertado sobrepasa el monto máximo disponible para la compra
  3. El plazo de entrega es mayor que el solicitado
  4. El proveedor no oferta por la totalidad de los productos o servicios cotizados
  5. Otro

Se entregarán las reglas de negocio para determinar el tamaño y la región de cada empresa proveedora.

Imagen referencial



Consideraciones técnicas

Debe quedar la información guardada de la justificación, debe incluir una bitácora de cada compra ágil. (invitaciones)

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el form permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rolback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend,

Todas las validaciones de reglas de negocio se deben realizar como base a nivel de backend,

Guardar los en caso de rolback de una tiranización que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rolback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

utilizar recaptcha en todos los form donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs

Requerimiento 4

Criterio de selección

Escenario de uso

Una vez seleccionado el proveedor, el usuario deberá ingresar el motivo de selección para poder continuar a la orden de compra.

Descripción

Tipos de modal con justificación o selección, obligatorio, con opciones establecidas para compradores:

-        Modal aparece en caso de que no se seleccione cotización más económica, del listado de locales.

-        Modal aparece en caso de que no se seleccione cotización más económica, del listado de no locales.

-        Modal aparece en caso de que se desestime una cotización local.

Se entregarán las opciones que se visualizarán en cada caso.

La justificación será pública en la ficha de cada Compra ágil.

Criterios generales

Imagen referencial



Consideraciones técnicas

Se debe crear lista blanca para permita en back y front solo la entrada caracteres conocidos para prevenir la ejecución de comandos remotos y XSS, entre otros.

Aplicar mínimo privilegio en la creación de MS y SP para la persistencia de datos (ej. Si el form permite modificar 3 atributos, los SP o MS solo debe permitir guardar 3 atributos)

Utilizar componentes con una solo función, entendiendo que leer y escribir son funciones distintas y no pueden convivir en el mismo componente, dígase componente como procedimientos almacenados, microservicio, otros.

Implementar rolback para todas las transacciones que no se completen, ya sea por decisión del usuario o por errores del sistema.

Las validaciones de permisos, autorización y roles se deben realizar en backend,

Todas las validaciones de reglas de negocio se deben realizar como base a nivel de backend,

Guardar los en caso de rolback de una tiranización que considere como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, motivo del rolback.

Guardar trazabilidad de todas las operaciones realizadas por el usuario que incluya como mínimo ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, operación realizada.

Implementar log para capturar errores interno y errores de integraciones externas que contengan como minino ID_Usuario, ID_Proceso, Fecha_Hora, ID_OOPP/Empresa, captura del error completo.

utilizar recaptcha en todos los form donde se solicite a los usuarios ingresar datos

Separar los componentes estáticos de los dinámicos (imágenes, script, otros para facilitar uso de CDNs

Requerimiento 5

Mejoras de Usabilidad

Escenario de uso

Una vez logueado el comprador al generar nuevos procesos de compra ágil espera hacerlo de la manera más simple.

Descripción

Como mejora continua en cada nueva fase del proyecto, se incorporan mejoras señaladas por usuario del aplicativo que permiten tener una mejor experiencia en el uso.

Criterios generales

Al momento de crear procesos de compra ágil se requiere facilitar las tareas del comprador, entregando herramientas simples de usar dentro del módulo. Se requiere mejorar:

  1. Agregar al usuario comprador opción de seleccionar si se trata de monto "estimado" o "máximo disponible"
  2. Agregar al usuario comprador opción de seleccionar si desea el monto cotización sea visible u oculto para el proveedor al momento de crear cotización
  3. Agregar al usuario proveedor la opción visualizar o no el monto "estimado" o "máximo disponible" según lo haya determinado el comprador al momento de generar la cotización.
  4. Cambio calendario selección de fecha y hora de cierre
  5. Ocultar opción de generar cotizaciones y compras ágiles parciales.
  6. Otras mejoras de usabilidad.

En la ficha de la Compra Ágil, debe considerar información de causas del Tribunal de Contratación Pública, debe consultar esta Información desde la componente transversal del Tribunal de Contratación Pública con el número y tipos de demandas recibidas en el proceso, cuando corresponda. Al hacer clic sobre el ROL de alguna demanda el usuario es redireccionado a la ficha de esa demanda, del sistema del Tribunal de Contratación Pública.

Imagen referencial

No aplica

Consideraciones técnicas

Se debe crear nuevo front en escritorio de comprador de calendario para seleccionar fecha y hora de cierre de los procesos o para ampliar plazo de cierre.

Se debe crear front y back escritorio comprador que permita al usuario comprador seleccionar si el valor que estimado o máximo disponible desea que este oculto o visible en la cotización para la vista del proveedor al momento que este último oferte.

Se debe crear front y back escritorio comprador que permita al usuario comprador seleccionar si el valor que está publicando es un valor estimado (no teniendo un mínimo o máximo definido) o se trata del máximo disponible para realizar la compra (no pudiendo el valor ofertado sobrepasar ese valor)

Se debe crear front y back que permita al usuario proveedor visualizar al momento de revisar el detalle de la cotización si el valor visible es un valor estimado o se trata de un valor máximo disponible que permite realizar la oferta de manera informada.

Debe considerar consumir información desde la API del Tribunal de Contratación Pública, para la información de las causas asociadas al proceso de contratación

  • Consideraciones de la Mesa de Arquitectura para este Desarrollo

                 i.          Ambientes en que se desplegará la solución:(Desarrollo, Preproducción, Producción)

                ii.          Plataformas Mercado Público

               iii.          Lenguaje de Desarrollo: ReactJS, NodeJS, Java17

               iv.          Infraestructura: Cloud con integraciones a Onpremise

                v.          Motor de BBDD: DynamoDB, SQLServer

               vi.          Política de Respaldos: La DCCP informará las políticas de respaldo

3.        Incorporación de mecanismo de compra “Diálogos Competitivos”

-        Objetivo general: Desarrollar e implementar los cambios necesarios a los módulos actuales del sistema de información para poder realizar adquisiciones mediante el proceso especial de contratación Diálogos Competitivos

-        Objetivo Específico:

  1. Poder identificar los procesos que corresponde a este nuevo procedimiento de contratación.
  2. Generar trazabilidad a lo largo de todo el proceso de adquisición

-        Requerimientos:

Requerimiento 1

Crear un nuevo procedimiento de diálogo competitivo

Escenario de uso

Usuario comprador desea crear un nuevo proceso de adquisición ya que realizó la definición de su producto y cuenta con la vigilancia técnica requerida.

Descripción

A través del actual formulario de licitación de monto igual o superior a 100 UTM, el usuario comprador podrá generar un nuevo dialogo Competitivo

Criterios generales

En el paso 1 de la creación de una licitación se deberá modificar la opción de “Otros procesos” por “Licitación Privada”

Imagen referencial

Consideraciones técnicas

Lenguajes: Visual Basic|

Se debe modificar módulo actual de Licitaciones

Requerimiento 2

Crear Dialogo Competitivo - Preselección de proveedores

Escenario de uso

El usuario comprador decide qué tipo de proceso de adquisición realizar

Descripción

El usuario comprador podrá seleccionar entre Contrato para la Innovación con preselección, Contrato para la Innovación sin preselección, Diálogos Competitivos.

Criterios generales

Si el usuario comprador selecciona Licitación pública las opciones de tipo de proceso serán:

  • Contrato para la Innovación con preselección
  • Contrato para la Innovación sin preselección
  • Diálogos Competitivos

Si el usuario comprador selecciona Licitación privada las opciones de tipo de proceso serán:

  • Contrato para la Innovación con preselección
  • Diálogos Competitivos

Imagen referencial

Consideraciones técnicas

Lenguaje: Visual Basic

Se debe modificar módulo actual de Licitaciones

Requerimiento 3

Crear Diálogo competitivo – Creación ID específico contrato para la innovación

Escenario de uso

Tipo de proceso ya seleccionado en etapa anterior.

Descripción

Paso inicial de carácter obligatorio

Criterios generales

Los contratos para la innovación utilizarán el mismo formulario de licitaciones, pero debiesen con un ID diferente, para que puedan ser identificados de forma simple y rápida, ejemplo: “1497-20-CI24"

Imagen referencial

No aplica

Consideraciones técnicas

Modificaciones transversales a los módulos:

-        Licitaciones (Visual Basic)

-        Oferta (Visual Basic)

-        Buscador.Licitaciones (C#)

-        Base de datos (SQL)

-        Otros que puedan resultar del análisis

Esto para que las reglas particulares que tienen los distintos tipos de licitaciones funcionen con este nuevo tipo, dado que se agregará como un nuevo tipo de licitación

Requerimiento 4

Crear Diálogo competitivo - Enlazar Consultas al Mercado

Escenario de uso

Usuario comprador se encuentra creando un nuevo diálogo competitivo y tiene que enlazar las consultas al mercado ya realizadas (Condición obligatoria)

Descripción

A través del actual formulario de licitación, el usuario comprador podrá generar un nuevo diálogo competitivo, pero es necesario enlazar la o las Consultas al Mercado que se hayan realizado previamente.

Criterios generales

El campo para enlazar las Consultas al Mercado realizadas debe permitir ingresar el ID de una o varias consultas, dependiendo de cuantas realizó el usuario comprador

Imagen referencial

Consideraciones técnicas

Implica cambio en modelo de base de datos y modificación en módulo de Licitaciones (Visual Basic)

Otros que puedan resultar del análisis

Requerimiento 5

Preselección de proveedores

Escenario de uso

Usuario comprador generó un Diálogo Competitivo y realiza el proceso de publicación, invitación a participar

Descripción

El usuario comprador selecciona uno o más proveedores, el estado del proceso de adquisición deberá llamarse “Proveedor seleccionado”

Criterios generales

En la ficha no se debe mostrar en vista pública el listado de proveedores/propuestas. Se debe notificar internamente al proveedor que fue seleccionado o no. El único cambio corresponde al estado del proceso según lo indicado en el campo anterior. No debería mostrarse los íconos de apertura, cuadro de oferta ni aclaración de ofertas

Imagen referencial

Consideraciones técnicas

modificación en módulo de Licitaciones, se debe hacer traducción de estados y lenguaje para tipo de licitación, además de cambios en reglas de negocios

Otros que puedan resultar del análisis

Requerimiento 6

Enlace de licitación pública con privada

Escenario de uso

Sólo se da cuando se selecciona un diálogo competitivo y cuando se crea una licitación privada a partir de una licitación pública

Descripción

Ficha de licitación privada debe contener campo para que comprador ingrese link de licitación pública proveniente, el cual debe existir en MP independiente de su estado (desde cierre en adelante, ej: adjudicada, desierta, revocada), salvo si la licitación está suspendida (por TCP)

Criterios generales

Debe validar que la licitación que exista, que el estado de esta sea válido según indicado en descripción.

Imagen referencial

Consideraciones técnicas

modificación en módulo de Licitaciones, se debe hacer traducción de estados y lenguaje para tipo de licitación, además de cambios en reglas de negocios.

Otros que puedan resultar del análisis

Cambios en modelo de base de datos.

Requerimiento 7

Vista pública

Escenario de uso

Posterior a la adjudicación de la licitación privada y envío de la OC

Descripción

Se deberá mantener en vista pública el listado de proveedores seleccionados (no las ofertas)

Criterios generales

Se deberá mantener en vista pública el listado de proveedores seleccionados (no las ofertas) y el estado de la aceptación de la OC y la fecha de los proveedores adjudicados. También deberá señalarse el ID de la licitación pública procedente.

Deberá actualizarse el estado de la ficha a “Adjudicada”

Imagen referencial

Consideraciones técnicas

Lenguajes: Visual Basic

Módulos:

-        BID (Ofertas)

-        Buscador.Licitaciones

-        Procurement

-        Otros que puedan resultar del análisis

4.        Incorporación de mecanismos de compra “Contratos para la innovación”

-        Objetivo general: Realizar los cambios necesarios a los módulos actuales del sistema de información para poder realizar adquisiciones mediante el proceso especial de contratación Contratos para la innovación

-        Objetivo Específico:

  1. Poder identificar los procesos que corresponde a este nuevo procedimiento de contratación
  2. Generar trazabilidad a lo largo de todo el proceso de adquisición

-        Requerimientos:

Requerimiento 1

Crear un nuevo procedimiento de contrato para la innovación

Escenario de uso

Usuario comprador desea crear un nuevo proceso de adquisición ya que realizó la definición de su producto y cuenta con la vigilancia técnica requerida.

Descripción

A través del actual formulario de licitación de monto igual o superior a 100 UTM, el usuario comprador podrá generar un nuevo contrato para la innovación.

Criterios generales

En el paso 1 de la creación de una licitación se deberá modificar la opción de “Otros procesos” por “Licitación Privada”

Imagen referencial

Consideraciones técnicas

Lenguajes:

VisualBasic

Considerar que el espíritu del cambio es poder ingresar al nuevo mecanismo mediante el módulo actual de Licitaciones.

Requerimiento 2

Crear Contrato para la Innovación - Preselección de proveedores

Escenario de uso

El usuario comprador decide qué tipo de proceso de adquisición realizar

Descripción

El usuario comprador podrá seleccionar entre Contrato para la Innovación con preselección, Contrato para la Innovación sin preselección, Diálogos Competitivos.

Criterios generales

Si el usuario comprador selecciona Licitación pública las opciones de tipo de proceso serán:

  • Contrato para la Innovación con preselección
  • Contrato para la Innovación sin preselección
  • Diálogos Competitivos

Si el usuario comprador selecciona Licitación privada las opciones de tipo de proceso serán:

  • Contrato para la Innovación con preselección
  • Diálogos Competitivos

Imagen referencial

Consideraciones técnicas

Lenguaje:

Visual Basic

Modificación a módulo Licitaciones.

Requerimiento 3

Crear Contrato para la Innovación – Creación ID específico contrato para la innovación

Escenario de uso

Tipo de proceso ya seleccionado en etapa anterior.

Descripción

Paso inicial de carácter obligatorio

Criterios generales

Los contratos para la innovación utilizarán el mismo formulario de licitaciones, pero debiesen con un ID diferente, para que puedan ser identificados de forma simple y rápida, ejemplo: “1497-20-CI24"

Imagen referencial

No aplica

Consideraciones técnicas

Modificaciones transversales a los módulos:

-        Licitaciones

-        Oferta

-        Buscador.Licitaciones

-        Base de datos

Esto para que las reglas particulares que tienen los distintos tipos de licitaciones funcionen con este nuevo tipo.

Requerimiento 4

Crear Contrato para la Innovación - Enlazar Consultas al Mercado

Escenario de uso

Usuario comprador se encuentra creando un nuevo Contrato para la Innovación y tiene que enlazar las consultas al mercado ya realizadas (Condición obligatoria)

Descripción

A través del actual formulario de licitación, el usuario comprador podrá generar un nuevo contrato para la innovación, pero es necesario enlazar la o las Consultas al Mercado que se hayan realizado previamente.

Criterios generales

El campo para enlazar las Consultas al Mercado realizadas debe permitir ingresar el ID de una o varias consultas, dependiendo de cuantas realizó el usuario comprador

Imagen referencial

Consideraciones técnicas

Implica cambio en modelo de base de datos y modificación en módulo de Licitaciones

Requerimiento 5

Preselección de proveedores

Escenario de uso

Usuario comprador generó un Contrato para la Innovación con preselección o un proceso de Diálogos Competitivos y realiza el proceso de publicación, invitación a participar

Descripción

El usuario comprador selecciona uno o más proveedores, el estado del proceso de adquisición deberá llamarse “Proveedor seleccionado

Criterios generales

En la ficha no se debe mostrar en vista pública el listado de proveedores/propuestas. Se debe notificar internamente al proveedor que fue seleccionado o no. El único cambio corresponde al estado del proceso según lo indicado en el campo anterior. No debería mostrarse los íconos de apertura, cuadro de oferta ni aclaración de ofertas

Imagen referencial

Consideraciones técnicas

Modificación en módulo de Licitaciones, se debe hacer traducción de estados y lenguaje para tipo de licitación

Requerimiento 6

Enlace de licitación pública con privada

Escenario de uso

Sólo se da cuando se selecciona un contrato de innovación con preselección, aplica para diálogo competitivo y cuando se crea una licitación privada a partir de una licitación pública

Descripción

Ficha de licitación privada debe contener campo para que comprador ingrese link de licitación pública proveniente, el cual debe existir en MP independiente de su estado (desde cierre en adelante, ej: adjudicada, desierta, revocada), salvo si la licitación está suspendida (por TCP)

Criterios generales

Debe validar que la licitación que exista, que el estado de esta sea válido según indicado en descripción.

Imagen referencial

Consideraciones técnicas

Cambios en modelo de base de datos, modificaciones a actual módulo de licitaciones

Requerimiento 7

Etapa dos del proceso de adquisición mediante licitación privada o bien realiza un contrato para la innovación sin preselección

Escenario de uso

Usuario comprador avanza al paso número 2 del formulario de adquisición

Descripción

El usuario comprador debe contar con la información de que el proceso de apertura constará de dos etapas, preselección de proveedores y Contratos para la innovación

Criterios generales

Debe visibilizar la preselección de proveedores y contratos para la innovación

Imagen referencial

Consideraciones técnicas

Lenguaje: VisualBasic

Modificaciones a actual módulo de licitaciones

Requerimiento 8

Emitir una orden de compra para un Contrato para la Innovación

Escenario de uso

A través del módulo de órdenes de compra el usuario comprador podrá seleccionar que esta nueva orden corresponde a un Contrato para la Innovación

Descripción

El usuario comprador, al momento de crear una orden de compra, en el paso 2, deberá indicar que es del tipo “Contrato para la innovación”

Criterios generales

Al momento de seleccionar que la orden de compra corresponde a un Contrato para la Innovación, esta OC deberá generarse con un código especial y en el paso n° 8 del módulo, Datos de la licitación, me permita buscar por ID y seleccionar a los proveedores preseleccionados de dicho proceso.

Imagen referencial

Consideraciones técnicas

Lenguaje: Visual Basic

Componentes a modificar:

-        PurchaseOrder (Orden de compra)

-        Base de datos (Considerar tabla de relación entre correlativo y organizaciones)

Requerimiento 9

Vista pública

Escenario de uso

Posterior a la selección y envío de la OC

Descripción

Se deberá mantener en vista pública el listado de proveedores seleccionados (no las ofertas)

Criterios generales

Se deberá mantener en vista pública el listado de proveedores seleccionados (no las ofertas) y el estado de la aceptación de la OC y la fecha. También deberá señalarse el ID de la licitación pública procedente.

Deberá actualizarse el estado de la ficha a “En desarrollo de los contratos para la innovación”

Imagen referencial





Consideraciones técnicas

Se debe modificar modulo actual de Licitaciones

III.      Requerimiento transversal

Requerimiento 1

Infraestructura como código

Escenario de uso

Se requiere ambiente de desarrollo y/o preproducción para realizar pruebas antes de la puesta en producción. Este requerimiento es transversal para los proyectos definidos como Cloud y debe ser considerado en los requerimientos funcionales previos

Descripción

El sistema debe permitir la implementación automatizada y reproducible de la infraestructura necesaria para el ambiente de pruebas a través de la utilización de herramientas y prácticas de "Infraestructura como Código" (IaC). Esto garantizará que el ambiente de pruebas se pueda configurar de manera consistente, rápida y confiable, reduciendo la posibilidad de errores humanos y acelerando los procesos de pruebas.

Criterios generales

1. El código de infraestructura debe estar almacenado en el repositorio de control de versiones de la Institución (azuredevops) y seguir las mejores prácticas de gestión del código fuente además de los lineamientos dados por el departamento de Arquitectura y Desarrollo.

2. El código de infraestructura debe ser declarativo y permitir la definición y configuración de los recursos necesarios para el ambiente de pruebas, incluyendo servidores, redes, almacenamiento, configuraciones de seguridad, entre otros.

3. Se deben utilizar herramientas y tecnologías modernas para la implementación del IaC, las cuales podrán ser propuestas o dadas por la Institución.

4. El proceso de implementación de la infraestructura como código debe ser completamente automatizado y reproducible, de manera que se pueda ejecutar fácilmente con simples comandos o algún tipo de disparador.

5. El código de infraestructura debe ser modular y escalable, permitiendo la fácil incorporación de nuevos componentes o recursos en el ambiente de pruebas sin afectar la estabilidad y funcionalidad existente.

6. Se deben establecer prácticas de revisión y aprobación del código de infraestructura antes de su implementación, con el fin de garantizar la calidad y consistencia del mismo.

7. Se debe mantener un registro de cambios y versiones del código de infraestructura, permitiendo la trazabilidad y la posibilidad de revertir cambios en caso de ser necesario.

8. La infraestructura como código debe integrarse con otros procesos y herramientas existentes en el entorno de pruebas, como el despliegue continuo (CI/CD), la gestión de configuraciones y la automatización de pruebas.

9. Debe considerar los lineamientos de ChileCompra para el modelo de datos, uso de soluciones de componentes transversales.


ANEXO B: Herramientas Tecnológicas disponibles.

A continuación, se listan las herramientas disponibles para uso durante el desarrollo de la iniciativa en la institución:

  1. Herramientas disponibles

  1. Software de revisión de código Coverity Softegrity (IDE programación y Pipeline) u otro de similares características disponible por DCCP.
  2. Lenguajes: Java V17, ReactJS, NodeJS, Python. .NET 4.8
  3. Sistema de gestión de llaves de cifrado (Marca)
  4. Baúl de secretos (Marca), almacena String de conexión a la Infraestructura
  5. RedHat Openshift Container Platform Desarrollo de Spring framework, java, microservicios y front end react.js
  6. Framework dotNet, Spring framework, Magento Ecommerce 2x
  7. Algoritmos de autenticación (JWT, OpenID y Oauth 2)
  8. SSO de Redhat (Keycloack)
  9. Motor de base de datos documental y relaciona (SQL-server,
  10. Elasticsearch, MariaDB, PostgreSQL)
  11. Application Server, IIS y Tomcat
  12. Kubernetes, Podman y Docker
  13. Azure Devops (GIT y Pipeline)
  14. Amazon Web Services
  15. Jira y Confluence
  16. Postman

  1. Estándar de Desarrollo Seguro DCCP (OWASP):

Los siguientes son los lineamientos de seguridad a seguir y utilizar durante el desarrollo de la iniciativa:

  • TOP 10 - Cumplimiento obligatorio
  • Análisis de revisión de código de seguridad
  • Cerrar brechas clasificadas por Coverity como altas y críticas.
  • Utilización de los estándares, guías y principio de desarrollo seguro de la OWASP foundation, entre los cuales podemos mencionar:
    • Estándar de verificación de seguridad en aplicaciones ASVS.
    • Guía de revisión de código.
    • Guía de pruebas de seguridad.
    • Modelo de madures de aseguramiento de software
    • Asistencia obligatoria la charla de desarrollo seguro dictada por la DCCP.

  1. Arquitectura:

Los siguientes son los lineamientos de arquitectura a seguir y utilizar durante el desarrollo de la iniciativa:

  • Desarrollo orientado a Objetos (Obligatorio)
  • Análisis de revisión de código de Arquitectura
  • El proveedor debe cerrar brechas clasificadas por Coverity como altas
  • Documentación en formato de arquitectura igual o similar a UML OMT
  • Diagrama de clases.
  • Diagrama de componentes.
  • Diagrama de actividades.
  • Diagrama de despliegue
  • Diagramas de contexto
  • Diagrama modelo de datos
  • Documentación general
  • Diagrama de Flujo, identificando claramente la integración con otros sistemas.
  • Diagrama de arquitectura
  • Modelo y Diccionario de datos
  • Informe de Coverity abordando(resueltos) el 100% de los issues Altos
  • Documentación de la implementación, manuales y descripción de los productos implementados y su funcionalidad.

  1. Patrón de Arquitectura: Microservicios.

Para los microservicios, se definen los siguientes lineamientos:

  • Mapstruct, uso de Mapstruct para aplicar el patrón Mapper, y facilitar la conversión de objetos entidades a objetos de dominio.
  • Springdoc, uso de la librería Springdoc para la generación del
  • documento swagger (json y yaml), y la interfaz gráfica swagger.
  • Api Restful
  • Uso de capa controlador o web, capa servicio o dominio, capa
  • repositorio o persistencia.
  • Camel Case: Esta práctica de escritura sin espacios ni puntuación, donde se emplea las letras capitales (mayúsculas) para la separación de palabras, es la que se debe emplear en la implementación.
  • Upper camel case: La primera letra debe ser capital. Esta convención debe ser acogida para la definición de las clases e interfaces. Ejem.: Product, Account, User
  • Lower camel case: La primera letra debe ser minúscula. Dicha convención debe ser empleada para la definición de los métodos que conforman cualquier clase. Ejm.: createProduct, getAccountById, indUserByName
  • Maven como gestor de dependencias a utilizar. La gestión se lleva a cabo a través de archivos .xml
  • Mapper pattern: Abstraer y evitar entregar información sensible es el objetivo de este patrón. Básicamente para llevarlo a cabo, toda la información que procesa la Base de Datos no puede ser expuesta a la capa controlador.
  • Aplicación autocontenida: Refiérase a la aplicación que tiene su propio servidor de aplicaciones con una configuración totalmenteindependiente. Por defecto: Tomcat.
  • Spring Boot: Proyecto de Spring para aplicaciones autocontenidas
  • Ocp4 pipeline: la actualización más reciente del pipeline para hacer despliegues hacía el entorno OCP4 puesto a disposición por la DCCP, además de estar configurado bajo la estrategia de trabajo declarada por Gitflow.
  • Spring JPA: Proyecto de Spring para configuración a Bases de datos relacionales
  • mssql-jdbc: librería para establecer la conexión al motor de BD SQL Server
  • Spring Boot Starter: Brinda dependencias de testing como: JUnit,
  • Mockito, Hamcrest, AssertJ.
  • SSO disponible por la DCCP: capa para securitizar la API expuesta por el aplicativo.
  • Lombok: Generación automática de métodos get y set.
  • Springdoc: Generación automática del documento swagger e interfaz gráfica de pruebas
  • Uso de la anotación @EnableTransactionManagement para administración de transacciones (rollback)
  • Postman collection: Colección de solicitudes http preconfiguradas que indican como van a ser consumidos los distintos endpoints de una API Rest. Se solicita que se adjunte en la raíz del repositorio git, el archivo.json que hace referencia a la colección importada desde Postman.


ANEXO C: Diagrama de Arquitectura


ANEXO D: Información referencial de equipos de trabajo y soluciones

Con el objeto de proporcionar más información para la oferta de los proveedores, se propocionan los siguientes datos:

  1. Tabla referencial de cantidad de perfiles por mes

Línea de Servicio N°1

Cantidad de profesionales

Des. Backend

Des.

.NET

Des. Frontend

DevOps

LT

Des. AWS

TOTAL

 Marzo 2024   

0

0

0

0

0

0

0

 Abril 2024   

0

0

0

0

0

0

0

 Mayo 2024    

5

1

3

1

1

1

12

 Junio 2024   

5

1

3

1

1

1

12

 Julio 2024   

5

1

3

1

1

1

12

 Agosto 2024  

5

1

3

1

1

1

12

 Septiembre 2024

5

1

3

1

1

1

12

 Octubre 2024 

4

1

3

1

1

1

11

 Noviembre 2024

2

0

2

1

1

1

7

 Diciembre 2024

2

1

2

1

1

1

8

 Enero 2025

2

0

1

1

1

1

6

Línea de Servicio N°2

Cantidad de profesionales

Des. Backend

Des.

.NET

Des. Frontend

DevOps

LT

Des. AWS

TOTAL

 Marzo 2024   

0

0

0

0

0

0

0

 Abril 2024   

0

0

0

0

0

0

0

 Mayo 2024    

6

3

3

1

1

1

15

 Junio 2024   

6

3

3

1

1

1

15

 Julio 2024   

6

3

3

1

1

1

15

 Agosto 2024  

6

2

3

1

1

1

14

 Septiembre 2024

6

2

3

1

1

1

14

 Octubre 2024 

6

2

3

1

1

1

14

 Noviembre 2024

3

2

2

1

1

1

10

 Diciembre 2024

3

2

2

1

1

1

10

 Enero 2025

2

1

1

1

1

1

7

  1.  Horas referenciales por perfil

Línea de Servicio N°1

              

Meses / Roles

Des. Backend

Des

.NET

Des. Frontend

Ing. DevOps

Líder Téc.

Des. AWS

 

 Mayo 2024    

860

172

516

172

172

172

 Junio 2024   

860

172

516

172

172

172

 Julio 2024   

895

179

537

179

179

179

 Agosto 2024  

740

148

444

148

148

148

 Septiembre 2024

470

94

282

94

94

94

 Octubre 2024 

716

179

537

179

179

179

 Noviembre 2024

328

0

328

164

164

164

 Diciembre 2024

328

164

328

164

164

164

 Enero 2025

342

0

171

171

171

171

Totales

5.539

1.108

3.659

1.443

1.443

1.443

Línea de Servicio N°2

Meses / Roles

Des. Backend

Des.

.NET

Des. Frontend

Ing. DevOps

Líder Téc.

Des. AWS

 

 Mayo 2024    

1.032

516

516

172

172

172

 Junio 2024   

1.032

516

516

172

172

172

 Julio 2024   

1.074

537

537

179

179

179

 Agosto 2024  

888

296

444

148

148

148

 Septiembre 2024

564

188

282

94

94

94

 Octubre 2024 

1.074

358

537

179

179

179

 Noviembre 2024

492

328

328

164

164

164

 Diciembre 2024

492

328

328

164

164

164

 Enero 2025

342

171

171

171

171

171

Totales

6.990

3.238

3.659

1.443

1.443

1.443

 

2.- PUBLÍQUESE el llamado a licitación en el sistema www.mercadopublico.cl, dentro del plazo establecido en las bases que se aprueban mediante la presente resolución, una vez que la misma se encuentre totalmente tramitada.

 

 

Anótese, Regístrese y Comuníquese,

 

 

DORA RUIZ MADRIGAL

DIRECTORA (S)

DIRECCIÓN DE COMPRAS Y CONTRATACIÓN PÚBLICA

 

RMZ/VCS/JPM/CAP/RBS/BPG

 

Distribución:

  • Dirección
  • Fiscalía
  • Departamento de Administración y Finanzas
  • Departamento de Arquitectura de Software y Desarrollo de Software
  • Departamento Mercado Público
  • Departamento de Gestión de Proyectos
  • Área de Estrategia y Gestión Institucional

 

Nombre Firmante: Haga clic o pulse aquí para escribir texto.

Fecha: Haga clic o pulse aquí para escribir texto.

ID: Haga clic o pulse aquí para escribir texto.

Url: Haga clic o pulse aquí para escribir texto.



[1] Un "incidente de datos" se refiere a eventos que comprometen la seguridad de la información almacenada, procesada o transmitida a través de sistemas informáticos. Estos incidentes pueden incluir violaciones de datos, ataques de malware, phishing, denegación de servicio, errores de configuración y pérdida o robo de dispositivos, entre otros.

10. Demandas ante el Tribunal de Contratación Pública
No cuenta con demandas ante el Tribunal de Contratación Pública.