¿Qué ley se aplica cuando no se ha pagado la recompensa por el desarrollo del sistema?
Para los proveedores que asumen la tarea de desarrollo de sistemas, uno de los riesgos más grandes podría ser la situación en la que, a pesar de haber entregado el producto, el usuario no paga la recompensa. Los costos de desarrollo de sistemas a menudo implican una gran cantidad de gastos de personal, ya que la mayoría de ellos son profesionales con habilidades, incluyendo programadores. La falta de recuperación de ventas puede convertirse en un problema de vida o muerte en algunos casos. En este artículo, asumiendo el caso en que el usuario no responde al pago de la recompensa, discutiremos los puntos que los proveedores deben considerar desde un punto de vista legal.
Primero, es necesario verificar si se puede solicitar el pago
- A pesar de que el proveedor ha entregado el producto al usuario, el usuario no acepta la entrega, lo que retrasa el proceso de facturación.
- Aunque se creía que la inspección había terminado, hay alguna discrepancia con la percepción del usuario, que se niega a pagar.
Estas situaciones pueden ocurrir en la realidad.
Además, en términos de desarrollo de sistemas, el proceso de revisar las especificaciones del sistema terminado y aceptar la entrega se llama “inspección”. El significado de esta “inspección” y los asuntos a considerar cuando el progreso no es satisfactorio se explican en detalle en el siguiente artículo.
Artículo relacionado: Aplicación de la cláusula de inspección estimada en el desarrollo de sistemas[ja]
Aunque la explicación general sobre la inspección en sí se deja al artículo mencionado anteriormente, desde el punto de vista legal, es necesario considerar si se puede decir que la inspección del usuario se ha completado, teniendo en cuenta las regulaciones sobre la “cláusula de inspección estimada”.
Con esto en mente, los primeros puntos a considerar cuando el usuario no paga son los siguientes:
- ¿El trabajo está terminado o aún está incompleto?
- ¿Es aplicable la responsabilidad por defectos (Artículo 635 del Código Civil japonés)?
La razón por la que se debe verificar primero estos dos puntos es que si el trabajo no está terminado y no se ha confirmado de antemano que no se aplica la responsabilidad por defectos (Artículo 635 del Código Civil japonés), incluso si se inicia un juicio, no se puede esperar que se pague la remuneración.
Entonces, ¿qué debe investigar el responsable del proveedor para considerar estos dos puntos? A continuación, veremos qué documentos deben ser verificados.
Documentos a verificar para determinar la posibilidad de solicitar honorarios
Factura de entrega Si no hay una factura de entrega, se fortalece la suposición de que la entrega no se ha completado y el trabajo no está terminado. |
Documento que notifica los resultados de la inspección Es el documento más importante para determinar si se puede considerar que el trabajo está terminado. Además, si la inspección se ha pospuesto debido a las circunstancias del usuario, sería bueno verificar también cómo se describió la “cláusula de inspección presunta” en el contrato. |
Lista de gestión de tareas Es un documento para conocer qué problemas se han encontrado hasta ahora y cómo se han manejado. También es un documento para entender la situación de los fallos y defectos que se descubrieron después de la entrega, y el estado de las reparaciones para ellos. |
Documentos de definición de requisitos, documentos de diseño y documentos de gestión de cambios, actas de reuniones, etc. Estos son documentos para aclarar qué se debe considerar como un fallo o defecto, al revelar qué entendimiento tenían el usuario y el proveedor al principio. |
Además, para obtener detalles sobre cómo gestionar los cambios en las especificaciones del sistema a desarrollar y cómo crear documentos de gestión de cambios, consulte otro artículo.
Artículo relacionado: Cómo manejar el cambio en el desarrollo del sistema desde una perspectiva legal[ja]
Notificación de cancelación o documento que registra la intención del usuario Es un medio para conocer la intención del usuario que no quiere proceder con la inspección (o no quiere pagar los honorarios). |
A continuación, verifique cuánto puede reclamar como compensación
En principio, el monto que se puede reclamar debería estar indicado en el contrato. Sin embargo, es posible que no exista un contrato adecuado (o un documento equivalente) si se han realizado cambios en las especificaciones o similares después del hecho. En el siguiente artículo, explicamos en detalle cómo recalcular una estimación basada en razones posteriores, como cambios en las especificaciones o adiciones de funciones.
Artículo relacionado: ¿Es posible aumentar el monto estimado después del desarrollo del sistema?[ja]
Aunque este artículo describe cómo recalcular una estimación, especialmente desde el punto de vista de considerar si es posible aumentar el monto de la factura, deberá considerar los siguientes puntos:
- La existencia y contenido de una estimación para el desarrollo adicional y las modificaciones de las funciones
- La reacción del usuario a la estimación
- La existencia de un acuerdo sobre la situación que causó el desarrollo adicional y las modificaciones de las funciones que se registran en la lista de gestión de problemas, y el monto relacionado
En resumen, el proceso consiste en verificar si se puede decir que hubo un acuerdo con el usuario sobre el punto de “hacer un pedido de trabajo por esa cantidad” (es decir, si se puede decir que se ha establecido un contrato).
Finalmente, consideramos los problemas pendientes en caso de litigio
Atención a la posibilidad de una contrademanda
En el desarrollo de sistemas, no es raro que cuando uno de los usuarios o proveedores presenta una demanda contra el otro, este último presente una contrademanda. Es decir, en situaciones donde no se realiza el pago de la remuneración, puede haber algún argumento por parte del usuario.
En primer lugar, aunque el desarrollo del sistema implica varias obligaciones de cooperación por parte del usuario, no debemos olvidar que el proveedor, como experto en desarrollo de sistemas, tiene una amplia discreción y una gran responsabilidad. En cuanto a la obligación de gestión de proyectos que el proveedor tiene en el desarrollo del sistema, se explica en detalle en el siguiente artículo.
Artículo relacionado: ¿Qué es la obligación de gestión de proyectos en el desarrollo de sistemas?[ja]
En otras palabras, es necesario considerar cuidadosamente si es posible atribuir la culpa a los usuarios que unilateralmente no pagan la remuneración. Al observar los casos judiciales pasados, se han confirmado numerosos casos en los que, aunque inicialmente el proveedor presentó una demanda para solicitar el pago de la remuneración, el usuario a su vez solicitó la restauración al estado original y la indemnización por daños y perjuicios.
Es necesario considerar si realmente hay beneficios comerciales
Incluso si los argumentos del proveedor son aceptados y se reconoce en el juicio que es posible solicitar el pago de la remuneración, si la situación se complica hasta el punto de llegar a juicio, se espera que la continuación de las transacciones futuras sea prácticamente difícil. Además, incluso si se reconoce su argumento en el juicio, debe estar preparado para que tome bastante tiempo recibir la remuneración. Si consideramos el tiempo y el costo de llevar a cabo un juicio, a menudo es más razonable y mejor hacer esfuerzos para encontrar un punto de compromiso.
Resumen
Si un usuario no cumple con el pago de una recompensa, se requiere la revisión de varios tipos de documentos para considerar el problema legalmente. Además, no es suficiente simplemente tener una buena gestión de documentos, también es necesario considerar qué tipo de riesgos y desventajas puede enfrentar la organización si finalmente decide proceder con una demanda.
Es cierto que la gestión rigurosa de los documentos diarios suele ser una tarea a nivel de campo. Sin embargo, si se decide proceder con una demanda basada en los documentos y materiales almacenados, esto puede convertirse en una decisión empresarial importante. En tales situaciones irregulares, es esencial comprender todo el proceso, junto con el hecho de que se pone a prueba la cohesión y la fuerza organizativa entre el campo y la administración.
Category: IT
Tag: ITSystem Development