\n\u30fbEl retraso en la entrega se basa en la intenci\u00f3n o negligencia del vendedor, y hay una raz\u00f3n para atribuir la culpa al vendedor.Adem\u00e1s, dado que es com\u00fan que el desarrollo del sistema sea un proyecto en el que tanto el usuario como el vendedor tienen obligaciones, puede haber casos en los que se reconozca una violaci\u00f3n de la obligaci\u00f3n por parte de ambos, el vendedor y el usuario, y la compensaci\u00f3n por da\u00f1os y perjuicios se compensa.<\/p>\n\n\n\n
El punto clave de la discusi\u00f3n es que la historia no es tan simple como “no cumplir con la fecha de entrega = incumplimiento de la obligaci\u00f3n”.<\/strong> Aunque se hable de retraso en la entrega, las razones pueden variar, ya sea por culpa del vendedor o del usuario. Hay una gran diferencia entre el “retraso en la fecha l\u00edmite” como hecho formal y el “retraso en el cumplimiento” que constituye una violaci\u00f3n sustancial de la obligaci\u00f3n.<\/p>\n\n\n\n<\/span>Casos judiciales sobre el retraso en el cumplimiento<\/span><\/h2>\n\n\n\n A continuaci\u00f3n, veremos casos judiciales en los que se discuti\u00f3 si es posible perseguir la responsabilidad por incumplimiento de deuda debido a retrasos en la entrega. Aunque se trata de una disputa sobre la fecha de entrega, la esencia de la misma no cambia en otros conflictos, es decir, es importante organizar el caso teniendo en cuenta los fundamentos del desarrollo del sistema, como el “deber de cooperaci\u00f3n del usuario” y el “deber de gesti\u00f3n del proyecto”.<\/p>\n\n\n\n
<\/span>Caso en el que el retraso en el cumplimiento fue compensado por la violaci\u00f3n del deber de cooperaci\u00f3n del usuario y la negligencia<\/span><\/h3>\n\n\n\nEn el caso de la sentencia citada a continuaci\u00f3n, el usuario se convirti\u00f3 en demandante y present\u00f3 una demanda debido al retraso en la entrega del proveedor. Esta demanda fue parcialmente aceptada en el juicio, pero al mismo tiempo, se indic\u00f3 que una de las razones era la falta de cooperaci\u00f3n adecuada por parte del usuario, y se indic\u00f3 que el 40% del da\u00f1o causado por el retraso en la entrega era responsabilidad del usuario.<\/p>\n\n\n\n
\nDespu\u00e9s de considerar lo anterior, se puede decir que el demandante, el usuario, no tom\u00f3 decisiones oportunas y adecuadas, como no resolver los problemas pendientes solicitados por el demandado antes de la fecha l\u00edmite, y que hubo momentos en los que no cooper\u00f3 adecuadamente. Sin embargo, en cuanto a la afirmaci\u00f3n del demandado sobre la violaci\u00f3n del deber de cooperaci\u00f3n debido a las solicitudes de adici\u00f3n o cambio de funciones del demandante, el usuario, aunque se reconoce que el demandante, el usuario, hizo solicitudes que resultaron en adiciones y cambios en el contenido del desarrollo previsto en el documento de dise\u00f1o b\u00e1sico del presente caso, no se puede decir que esto constituye una violaci\u00f3n del deber de cooperaci\u00f3n del demandante, el usuario, y la afirmaci\u00f3n del demandado no tiene fundamento. Adem\u00e1s, en cuanto a la afirmaci\u00f3n del demandado sobre la violaci\u00f3n del deber de cooperaci\u00f3n debido a las demandas excesivas del demandante, el usuario, no se puede reconocer que el demandante, el usuario, hizo demandas excesivas en comparaci\u00f3n con las tarifas de comisi\u00f3n del contrato de desarrollo del sistema de c\u00e1lculo electr\u00f3nico del presente caso, y no hay raz\u00f3n. Por el contrario, se puede decir que hubo aspectos inapropiados en la gesti\u00f3n del proyecto del demandado, como el hecho de que el demandado comprendi\u00f3 el n\u00famero de procesos despu\u00e9s de enero de 1999 (el n\u00famero de “procesos” a partir de julio o agosto del mismo a\u00f1o) y que hizo una propuesta para reducir los procesos y asumir una comisi\u00f3n adicional injusta despu\u00e9s del 31 de mayo del mismo a\u00f1o. <\/p>\nSentencia del Tribunal de Distrito de Tokio, 10 de marzo de 2004<\/cite><\/blockquote>\n\n\n\nEn la sentencia anterior, se reconoci\u00f3 el retraso en el cumplimiento debido al retraso en la entrega del proveedor, pero se indic\u00f3 que una de las causas era que el usuario no hab\u00eda resuelto los problemas pendientes planteados por el proveedor, y se acept\u00f3 la demanda del usuario al “recortar” el 60% del da\u00f1o reclamado por el usuario. Este es el mismo tratamiento de “compensaci\u00f3n por negligencia” que en los accidentes de tr\u00e1fico en los que tambi\u00e9n hay culpa por parte de la v\u00edctima.<\/strong><\/p>\n\n\n\nEn esta sentencia, la frase “deber de cooperaci\u00f3n” aparece m\u00e1s de 40 veces en todo el texto, incluyendo el \u00edndice. Desde el punto de vista legal, se podr\u00eda decir que la esencia del asunto es c\u00f3mo dividir el deber de gesti\u00f3n del proyecto del proveedor y el deber de cooperaci\u00f3n del usuario.<\/p>\n\n\n\n
<\/span>Caso en el que se reconoci\u00f3 completamente el retraso en el cumplimiento<\/span><\/h3>\n\n\n\nA continuaci\u00f3n, citamos la sentencia de un caso en el que se demostr\u00f3 completamente la responsabilidad del proveedor por el retraso en la entrega, y se reconoci\u00f3 la responsabilidad por incumplimiento de deuda debido al retraso en el cumplimiento. En este caso, el usuario rescindi\u00f3 el contrato cuando el sistema estaba casi terminado, y el proveedor present\u00f3 una demanda, pero el usuario argument\u00f3 que el retraso en la entrega era la causa del conflicto.<\/p>\n\n\n\n
\nNo se puede negar que el demandado dio varias instrucciones de cambio para el sistema de dise\u00f1o, y que esto retras\u00f3 la finalizaci\u00f3n hasta cierto punto. En particular, el demandado dio la instrucci\u00f3n final de cambio el 23 de junio de 2005, por lo que se reconoce que no se puede culpar al demandante por el hecho de que la funci\u00f3n de “c\u00e1lculo autom\u00e1tico para los elementos detallados de las piedras laterales” basada en esa instrucci\u00f3n no est\u00e9 completa. Sin embargo, los dem\u00e1s cambios de instrucci\u00f3n del demandado se hicieron hasta principios de abril del mismo a\u00f1o, y no se reconoce ninguna circunstancia que deba interpretarse como que se cambi\u00f3 el plan para completar el sistema de dise\u00f1o (excepto la parte debido a la instrucci\u00f3n de cambio del demandado el 23 de junio del mismo a\u00f1o). No se puede reconocer que el demandante hab\u00eda completado el sistema de dise\u00f1o a un nivel que permitiera su operaci\u00f3n real a finales de junio de 2005, excluyendo la parte debido a la instrucci\u00f3n de cambio del 23 de junio del mismo a\u00f1o, y se reconoce que partes importantes del sistema, como la incapacidad para mostrar im\u00e1genes o la funci\u00f3n de b\u00fasqueda no funcionaba, estaban incompletas. (Omisi\u00f3n) Se puede inferir que el demandante no gestion\u00f3 adecuadamente los procedimientos de trabajo asociados con el desarrollo del sistema. Por lo tanto, no se puede reconocer que la principal raz\u00f3n por la que el demandante no pudo cumplir con la fecha de entrega se debi\u00f3 a las instrucciones del demandado, y no se puede reconocer que no hay razones que deban ser atribuidas al demandante. <\/p>\nSentencia del Tribunal de Distrito de Tokio, 16 de febrero de 2007<\/cite><\/blockquote>\n\n\n\nEn esta sentencia, se indic\u00f3 que no se puede culpar al proveedor por el hecho de que la funci\u00f3n que no estaba completa debido a la instrucci\u00f3n de cambio de especificaciones dada una semana antes de la fecha de entrega. Sin embargo, teniendo en cuenta que:<\/p>\n\n\n\n
\nLas instrucciones de cambio dadas hace varios meses a\u00fan no han sido atendidas<\/li>\n\n\n\n Despu\u00e9s de que se dieron las instrucciones anteriores, el proveedor tambi\u00e9n envi\u00f3 un correo electr\u00f3nico indicando la fecha prevista de finalizaci\u00f3n<\/li>\n\n\n\n Las partes incompletas son partes importantes del sistema, como la implementaci\u00f3n de la visualizaci\u00f3n de im\u00e1genes y la funci\u00f3n de b\u00fasqueda, y el hecho de que no se ha respondido a esto es un elemento que respalda la violaci\u00f3n del deber de gesti\u00f3n del proyecto<\/li>\n<\/ul>\n\n\n\nSe reconoci\u00f3 la responsabilidad por incumplimiento de deuda debido al retraso en el cumplimiento.<\/strong><\/p>\n\n\n\n<\/span>Lo que se puede aprender de ambos juicios<\/span><\/h3>\n\n\n\nAl considerar ambos juicios, se puede decir que el problema de la “fecha de entrega” en el desarrollo del sistema es, en \u00faltima instancia, un problema de c\u00f3mo trazar la l\u00ednea entre el deber de cooperaci\u00f3n del usuario y el deber de gesti\u00f3n del proyecto del proveedor. <\/strong>En otras palabras, desde el punto de vista legal, el retraso en el cumplimiento es un tipo de responsabilidad por incumplimiento de deuda, por lo que la cuesti\u00f3n de si hubo alguna violaci\u00f3n del deber por parte del proveedor se convierte naturalmente en un punto de disputa. Y para considerar si el da\u00f1o que se ha materializado como resultado (es decir, la p\u00e9rdida del usuario debido al retraso en la entrega) puede ser atribuido al proveedor, tambi\u00e9n es necesario considerar c\u00f3mo interpretar el deber de cooperaci\u00f3n del usuario.<\/p>\n\n\n\n<\/span>Resumen<\/span><\/h2>\n\n\n\nAl escuchar la frase “retraso en el cumplimiento”, es posible que a primera vista parezca una mera reformulaci\u00f3n de “retraso en la entrega” debido a la connotaci\u00f3n de las palabras. Sin embargo, el retraso en el cumplimiento es una forma de incumplimiento de la obligaci\u00f3n. Por lo tanto, es m\u00e1s apropiado entenderlo como una “violaci\u00f3n de la obligaci\u00f3n de gesti\u00f3n de proyectos”.<\/strong><\/p>\n\n\n\nEn cuanto a los problemas de “plazo de entrega” en los proyectos de desarrollo de sistemas, es importante no quedarse atrapado solo en la superficialidad de los plazos de entrega, sino replantear y organizar estos problemas en t\u00e9rminos de la obligaci\u00f3n del proveedor de gestionar el proyecto y la obligaci\u00f3n del usuario de cooperar.<\/p>\n","protected":false},"excerpt":{"rendered":"
Un proyecto de desarrollo de sistemas es, en cierto sentido, siempre una lucha contra el plazo de entrega. Desde un punto de vista legal, en el desarrollo de sistemas, podemos considerar los “ri […]<\/p>\n","protected":false},"author":1,"featured_media":58889,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[19,31],"acf":[],"_links":{"self":[{"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts\/58814"}],"collection":[{"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/comments?post=58814"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts\/58814\/revisions"}],"predecessor-version":[{"id":58893,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts\/58814\/revisions\/58893"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/media\/58889"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/media?parent=58814"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/categories?post=58814"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/tags?post=58814"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}