Exigen integración API de UETS en el pliego: ¿Qué es esta integración y cómo debe cotizarse?

Los servicios de UETS no suelen usar arquitectura REST estándar, sino SOAP y WSDL. Hay que renegar con firma de XML, validación de certificados X.509 y los algoritmos de cifrado que exige el PTT. La documentación no está muy actualizada, así que prepárense para pasar horas haciendo parseo de paquetes en el entorno de pruebas.

Al armar el presupuesto metan estas tres cláusulas específicas en el contrato: 1) El trámite del protocolo legal y el seguimiento de la solicitud ante el PTT es 100% responsabilidad del cliente. 2) El equipo de software no responde por pérdida de derechos legales ocasionada por caídas o errores de timeout en los webservices de UETS. 3) Las pruebas de integración se realizarán únicamente sobre la cuenta de test provista por el PTT.

Hace ocho meses hicimos una integración similar para una consultora. La parte de código la terminamos en 12 días laborables, pero PTT tardó exactamente 45 días en aprobar el contrato corporativo y configurar la IP en el entorno de pruebas. En la propuesta no vincules la fecha de entrega a esta burocracia.

En la propuesta jamás camufles este trabajo dentro de otros módulos. Pon una línea independiente con el título 'Módulo de Integración Oficial UETS'. Y ponle un precio de al menos el doble que una integración API normal porque también vas a tener que gestionar tú casi toda la comunicación entre el cliente y PTT.

¿Tu cliente usa la cuenta de UETS como persona física o jurídica? Dar permisos directos de servicio web para cuentas individuales de abogados implica procedimientos distintos a los de cuentas de empresa, ¿han confirmado esto antes con PTT?

Los bufetes de abogados quieren meter cada notificación automáticamente al sistema por API, pero si mañana el servicio no responde y se les pasa el plazo de un juicio al primero que van a culpar es al desarrollador. Si en el contrato no dejas superbien delimitadas las responsabilidades legales, se puede contemplar no meterse en ese fregado.

Hace dos años en un proyecto tratamos esta integración como un simple servicio de SMS y cobramos una miseria por el desarrollo. Luego entre los certificados de seguridad que pedía PTT los cambios de IP del servidor y las respuestas del servicio que cambiaban a cada rato, todo lo que ganamos en el proyecto se nos fue en soporte técnico. Al hacer la propuesta pide sí o sí una cuota anual de mantenimiento y seguimiento.

los procesos de la api de ptt van lentisimos de verdad. mete si o si una clausula en el contrato q diga q los procesos de aprobacion del cliente no entran en el plazo de entrega o te van a presionar diciendo q te has retrasado.

Si lo ves como un proceso, el panorama cambia. La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación.

Este hilo es para archivar. Si no lo pones por escrito desde el principio, luego surgen discusiones.

Me pasó lo mismo.

Yo pasé por esto, déjenme contarlo. El calendario de pagos debe vincularse a las fases del proyecto, no a fechas fijas.

Espero que le sea útil.

Hay un punto que me genera dudas... Establecer un proceso de solicitud de cambios no ralentiza el trabajo, lo agiliza.

Esta es mi opinión, no lo escribo como una verdad absoluta.

Lo probaré.

Tomo nota, gracias.

Os explico cómo se hace en la práctica. La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación.

Ánimo.

Yo también pienso lo mismo. Todos los que se apresuran con integracion api uets se atascan en el mismo punto.

Empezad con una pequeña prueba, no lo integréis todo de golpe. Espero que le sea útil.

Entrando en detalle: Al tomar decisiones, escribe también el peor escenario, no solo el mejor.

Espero que le sea útil.