Zival´S
S.A. c. Samia, Marcelo Fabián s/ ordinario
Cámara Nacional de Apelaciones en
lo Comercial, sala A
30/04/2015
Contratos Informáticos - Provisión de “Software”. Obligación de Resultado – Pericia Informática.
Comentario:
En los contratos vinculados a la provisión de “software” o de programas informáticos, el proveedor ofrece una máquina, un sistema, bien o servicio informático, basándose en la utilidad que brinda, y el adquirente busca satisfacer una necesidad funcional: una “solución”.
Bajo tal entendimiento de cosas, la doctrina y jurisprudencia coinciden en cuanto a que el proveedor informático contrae una “obligación de resultado” que se traduce en asegurar la aptitud de tales elementos a los requerimientos hechos por el cliente, para que con ellos este último llene la utilidad que persigue.
Basta a este último demostrar la falta de obtención de esa utilidad, es decir, el mero incumplimiento material o estructural de la obligación asumida, para que, al igual que en cualquier hipótesis de responsabilidad objetiva, surja una presunción de adecuación causal contra el proveedor. Tal es el hecho constitutivo de la pretensión que el acreedor demandante debe probar de acuerdo con el artículo 377 del Código Procesal.
En el caso “Zival's S.A. vs. Samia, Marcelo Fabián s. Ordinario” se declara rescindido el contrato de "desarrollo de software a medida" celebrado entre las partes y condena al demandado a restituir a la empresa actora las sumas abonadas en virtud de aquél, toda vez que el examen de los elementos probatorios permite concluir que el objeto del contrato -elaboración y desarrollo de un software "a medida" de los requerimientos de la accionante, cuyos módulos se entregarían en forma mensual y que luego se integrarían en un único software no fue cumplido, siendo imputable a él tal incumplimiento.
Sumario
Es de la esencia de los contratos vinculados a la provisión de software o de programas informáticos, mucho más cuando se trata de programas o sistemas desarrollados a la medida de un cliente en particular, como el de la especie, la obtención de una prestación de servicio informático que responda a las necesidades del usuario.
Desde tal perspectiva, este último espera un resultado funcional útil que derive de la aplicación de la máquina, el programa de su actividad, el sistema, red, bien o servicio informático de que se trate.
En los términos indicados, la utilidad perseguida por el requirente o usuario es en sí mismo un objetivo que está presente no sólo en la provisión del hardware o del software, sino también en el mantenimiento del sistema y otros aspectos propios de la actividad de quien provee bienes o servicios de informática.
El proveedor, en suma, ofrece una máquina, un sistema, bien o servicio informático basándose en la utilidad que brinda, y el adquirente busca satisfacer una necesidad funcional.
Bajo tal entendimiento de cosas, la doctrina y la jurisprudencia coinciden en cuanto a que el proveedor informático contrae una “obligación de resultado”, que se traduce en asegurar la aptitud de tales elementos a los requerimientos hechos por el cliente para que con ellos este último llene la utilidad que persigue.
Cabe recordar, en este punto, que las “obligaciones de resultado” son aquéllas en las cuales el deudor está obligado a asegurar una finalidad determinada
Pues bien, en el caso particular que nos ocupa, cabe afirmar que todas las obligaciones que el demandado asumió frente a la actora fueron “de resultado”.
Lo contratado fue la provisión de un software “a medida” a requerimiento del usuario, denominado “Sistema de Administración Integral” (“S.A.I.”)
Todo software -aun si se tratara de un programa standard-, debe reunir, como mínimo, determinados requisitos que se consideran configurativos de una adecuada prestación, entre los cuales se encuentra, por ejemplo, el hecho de que debe ser fiable, esto es, capaz de funcionar sin errores dentro de los parámetros generalmente aceptados de fallas; a lo que se suma que debe ser adecuado a las necesidades/exigencias del cliente y que debe cumplir, a su vez, con ciertas pautas mínimas de funcionamiento en orden al número de operaciones, tiempo de acceso, tiempo de respuesta, etc.
De allí que la obligación del proveedor del programa de computación no deje de ser “de resultado” -ni siquiera- por el hecho de que sea una versión standard y con mayor razón aún tal regla es exigible si se trata de una versión “a medida” desarrollada a requerimiento del usuario de acuerdo a un contrato.
Dentro de este esquema, y asumido que cabe encuadrar las prestaciones asumidas por el proveedor informático dentro de “obligaciones de resultado”, en las que el deudor asegura el logro del interés final pretendido por el acreedor, ello implica que basta a este último demostrar la falta de obtención de ese interés, es decir, el mero incumplimiento material o estructural de la obligación asumida, para que, al igual que en cualquier hipótesis de responsabilidad objetiva, surja una presunción de adecuación causal contra el deudor. Tal es el hecho constitutivo de la pretensión que el acreedor demandante debe probar de acuerdo al Cód. Proc. Civ. y Comercial:377.
Por su lado, cumplida por el acreedor la carga probatoria indicada, se traslada al deudor la carga de demostrar cualquiera de los hechos impeditivos o extintivos incorporados al derecho en el que base su defensa o excepción, es decir, la ausencia de cualquiera de los elementos constitutivos del acto ilícito contractual nacido del incumplimiento de una obligación de resultado, con aptitud para romper el nexo causal. En caso de no satisfacerse esta exigencia juega en contra la regla del onus probandi, en razón de haberse omitido la conducta probatoria del caso según lo prescripto por el citado art. 377 de la ley de rito.
Es que, a diferencia de las obligaciones de medios, en los deberes de resultado, el deudor asegura la obtención de la finalidad tenida en miras por el acreedor al momento de la contratación.
En su virtud, el cumplimiento requiere invariablemente la obtención de esa finalidad última cuya obtención ha asegurado el deudor, asumiendo tácitamente los riesgos u obstáculos inherentes al desenvolvimiento del plan de prestación.
La frustración del resultado genera la responsabilidad objetiva del solvens, con indiferencia de la conducta diligente que éste haya eventualmente desarrollado en el tránsito del plan de prestación.
El planteo no significa prescindir del comportamiento del obligado como componente estructural del objeto de la obligación. Sin perjuicio de ello, en esta especie de relación jurídica es trascendente el interés final, el resultado o la utilidad debida al acreedor .
En mérito de ello, el incumplimiento estructural, configurado por la falta de obtención del resultado, se identifica con el incumplimiento funcional, del cual emerge la responsabilidad del obligado. Ello así, le está vedado al deudor la exoneración de la responsabilidad mediante la prueba de su no culpa, habida cuenta que la fractura del nexo causal requiere la prueba de una causa ajena (hecho del propio acreedor, no imputable al deudor, de un tercero independiente o del caso fortuito o fuerza mayor). Esta eximente, también denominada causa extraña no imputable al deudor, en la responsabilidad contractual, abarca las tres (3) especies aludidas, desvía el origen del daño a un centro de imputación distinto y, en consecuencia, genera la eximición de la responsabilidad por ruptura del enlace causal.
El análisis revela que las obligaciones de resultado -o de fines- son de naturaleza objetiva.
El incumplimiento funcional, por tanto, apareja una responsabilidad de la misma especie, fundada en el factor de atribución objetivo denominado garantía o crédito a la seguridad con sustento en los arts. 1197 y 1198 del Cód. Civil.
En conclusión, la culpa está, de este modo, fuera de cuestión, sea como criterio de atribución o como eximente del deber de responder.
Es de observar, todavía, que la aplicación del criterio precedentemente expuesto se aprecia como esencialmente justo en supuestos como el de autos, desde que al proveedor informático le es mucho más fácil acreditar cuál es el defecto que provocó el fracaso que al usuario la prueba de la culpa del prestador.
Cabe aquí recordar la brecha tecnológica que separa a las partes en contrataciones del tipo de las aquí consideradas, para apreciar la necesidad de que también deba jugar la regla probatio incumbit facilius probanti, o sea, que aquél que se encuentra en mejores condiciones para demostrar el origen de un daño es quien debe ser gravado con la carga de prueba.
En ese marco, cabe concluir señalando que las particularidades de la contratación informática (dentro de las cuales se pueden mencionar la desigualdad de conocimientos informáticos de las partes, la utilización de contratos predispuestos, las expectativas de los usuarios fincadas en la obtención de un resultado útil para la gestión de su empresa, entre otros), a lo que se adiciona los graves daños que puede sufrir una empresa como consecuencia del disfuncionamiento de un hardware o un software y la dificultad probatoria de quienes se encuentran en inferioridad de conocimientos frente al experto (proveedor informático), hace que se torne exigible en este tipo de supuestos un funcionamiento estricto del standard de la buena fe contenido en el art. 1198 del Cód. Civil.
De su lado, el peritaje de ingeniería en sistemas de información producido a fs. 216/8 confirma que el objeto del contrato celebrado entre las partes era la elaboración y desarrollo de un software “a medida” a requerimiento de la accionante, denominado S.A.I. (Sistema de Administración Integral), compuesto de módulos que debían interactuar entre sí, conformando un único Sistema de Gestión Integral.
Asimismo, de la compulsa practicada por el perito sobre el disco rígido depositado en la escribanía con fecha 27/04/2009, surgía que el software que se encontraba en dicho disco no cumplía con el objeto del contrato; agregando que desconocía las causas por no haber participado en las etapas de contratación, análisis, desarrollo e implementación de éste (véase respuesta al punto pericial 2°, propuesto por la accionante, a fs. 217).
Enfatizó -seguidamente- el experto que el contenido del disco rígido no respondía al objeto del contrato, aclarando que existían en éste partes de un sistema que no se encontraba en funcionamiento (v. respuesta al punto pericial 3°, de fs. 217).
Explicó así que el grado de avance del programa, en relación al objeto contractual, era de un 25 %. Aclaró, a su vez, que el software que se encontraba en el disco rígido compulsado no contaba con una interface gráfica que permitiese ser utilizada por un operador (véanse respuestas a puntos de pericia 4° y 5° de fs. 217/8). Señaló además que en el disco rígido se encontraban instalados pero no operativos únicamente los módulos: “Inventario (stock)”, “Clientes” y “Proveedores” (véase respuesta al punto 6° de fs. 218, la pericia bajo estudio). Frente a la impugnación formulada por la parte demandada a fs. 222/4, el experto aclaró que en el disco rígido objeto del informe pericial se encontraba: i) un software de base de datos instalado; ii) un servidor de aplicaciones instalado; iii) los módulos “Inventario”, “Clientes” y “Proveedores” instalados sin funcionar; iv) módulos: “Ventas”, “Compras”, “Impuestos”, “Sueldos y Jornales”, “Facturación”, “Gestión de Cajas”, “Imputaciones Contables”, “Importaciones y Exportaciones”, “Costos”, “Cuentas Corrientes”, “Manejo de Editoriales”, Derechos de Autor” y “Manejo de Retenciones” sin instalar (véanse respuestas 2° y 3° de las impugnaciones a la pericia, a fs. 229/30 y fs. 231).
Continuó afirmando el experto, en su contestación a las impugnaciones planteadas, que el objeto del contrato era un sistema con todos los módulos funcionando correctamente e interrelacionados (véase respuesta 2° de fs. 229/30). Explicó, en ese marco, que cuando adujo desconocer las causas de porqué un proyecto de sistemas podía no tener éxito, se refería a que esas causas eran difíciles de determinar y podían variar desde la mala elección de un proveedor en la etapa de contratación, ya fuese porque carecía de experiencia, o bien, la envergadura del sistema lo superaba, o por fallas en las etapas de análisis, desarrollo e implementación; aclarando que en la etapa de análisis era necesario que el comprador del sistema se involucrase y dedicase mucho tiempo, para que el producto final fuese exitoso (v. respuesta 2° de fs. 230).
Concluyó el experto en que, con base en el trabajo realizado hasta ese entonces, para lograr que el sistema descripto estuviese instalado y funcionando, faltaba aproximadamente el 75 % más de trabajo respecto de lo realizado hasta ese momento, cuantificado en horas hombre de un profesional de sistemas con experiencia en la tarea a realizarse (véase respuesta 4°, de fs. 231). Finalizó refiriendo el experto que podría indicarse que el motivo de la falta de ejecución o las razones por las cuales el sistema no era operativo, era que faltaban horas de trabajo de personal idóneo para terminar el sistema y dejarlo operativo y en funcionamiento (véase respuesta 6° de fs. 231/2).
Texto completo:
Zival´S
S.A. c. Samia, Marcelo Fabián s/ ordinario
Cámara Nacional de Apelaciones en
lo Comercial, sala A
30/04/2015
¿Es arreglada a derecho la sentencia apelada?
El doctor Kölliker Frers dijo:
(1) “Zival´s S.A.” promovió acción ordinaria contra Marcelo Fabián Samia a fin de obtener la resolución del contrato que los vinculara, así como el reintegro de la suma de pesos sesenta y tres mil ($63.000), con más sus respectivos intereses y costas.
Adujo ser una sociedad que explotaba en plaza un negocio de venta de discos compactos y libros con varias sucursales en el país y que, en ese marco, suscribió con el demandado, el día 24/08/2007, un contrato que denominaron de software “a medida” cuyo ejemplar original se acompañaba con dicha presentación. Indicó que, tal como surgía en el mentado contrato, el accionado asumió el rol de “desarrollador”, mientras que su parte el de “usuario”; aclarando que el objeto de dicho contrato era la elaboración y desarrollo de un programa a la medida de los requerimientos del usuario al que calificaron “S.A.I.” (“Sistema de Administración Integral”).
Explicó que, de acuerdo a lo estipulado en la cláusula segunda (2a) del convenio, el demandado asumió -en su carácter de “desarrollador”- la obligación de efectuar entregas y/o demostraciones mensuales de los módulos ya creados, como así también la de realizar análisis mensuales, que luego integrarían un único software, para poder verificar así su funcionamiento.
Destacó que, de conformidad con la cláusula octava (8a), las partes convinieron que por la elaboración y desarrollo del sistema que culminaría con la entrega de un sistema de software integral, el usuario debía abonar un adelanto de $20.000 por el comienzo de obra y cuotas mensuales de $6.000 cada una, entre los días 1 y 5 de cada mes, dejándose asentado que la finalización de la primera versión del desarrollo debía entregarse antes del 31/12/2008.
Aseveró que, en ese contexto, de acuerdo con la cláusula 14° del contrato, el desarrollador debía ir entregando los programas del sistema integral progresivamente a través del tiempo en pequeños módulos.
Manifestó, asimismo, que en la cláusula vigésima (20a) los contratantes estipularon que el desarrollador debía establecer las condiciones técnicas mínimas, tanto del hardware como del software que debían tener los equipos del usuario para que el sistema funcionase en forma efectiva.
Continuó afirmando que, en cumplimiento de sus obligaciones, su parte abonó al accionado la suma de $63.000 de conformidad con las facturas que acompañó con el escrito inicial, no obstante lo cual y pese al vencimiento del plazo máximo contractualmente pactado (31/12/2008), el demandado no cumplió con los compromisos a su cargo, no habiendo -ni siquiera- entregado un módulo o una demostración del sistema de administración integral que le encomendara; por lo que incumplió con el objeto del contrato.
Indicó que, frente al fracaso de las tratativas extrajudiciales tendientes a obtener el cumplimiento de las obligaciones comprometidas, y no habiéndose previsto pacto comisorio expreso, su parte intimó con fecha 12/02/2009 a la contraria para que en el plazo de quince (15) días procediese a cumplimentar las obligaciones a su cargo, bajo apercibimiento dar por rescindido (rectius: resuelto) el contrato por su exclusiva culpa; según rezaba la carta documento acompañada con el escrito inaugural.
Señaló que, ante el fracaso de dicha misiva, remitió una nueva que el demandado contestó con fecha 10/03/2009, negando el incumplimiento atribuido y pretendiendo restarle eficacia cancelatoria a los pagos oportunamente realizados por su parte. Añadió que dicha epístola fue respondida por su parte por idéntico medio el día 16/03/2009 negando sus términos y dejando constancia de que lo que se colocó a disposición en la carta documento remitida por el accionado no cumplía con el objeto del contrato; razón por la cual se lo intimaba a hacerle entrega del sistema de gestión integral debidamente instalado y en funcionamiento, bajo apercibimiento de dar por rescindido (rectius: resuelto) el contrato por su exclusiva culpa.
Refirió que, frente a ello, el accionado remitió a su parte una carta documento datada el 20/03/2009, comunicándole que procedería a entregar ochocientas (800) horas laboradas, pretendiendo -de ese modo- no sólo variar el objeto del contrato, sino -además- justificar el incumplimiento que, a la postre, se encontraba debidamente acreditado; lo que motivó el envió de una nueva misiva de su parte el día 26/03/2009, que fue respondida por la contraria el 30/03/2009.
Explicó que se labraron sucesivamente las actas de constatación notarial de fechas 26/03/2009, 20/04/2009 y 27/04/2009, de las que surgía que, pese a haberse puesto a disposición del accionado el equipo requerido, aún no se había hecho entrega del sistema de administración integral objeto del contrato, por no haberse contado con tiempo suficiente, debido a la existencia de un inconveniente habitual en la instalación de ese tipo de software.
Fue, en ese contexto, que solicitó -según adujo- que se extrajese el disco rígido de la máquina con todo lo instalado a los fines de ser entregado en depósito a la escribana pública M. C. A., conforme recibo que se adjuntaba con el escrito de demanda.
Finalmente, destacó que, con fecha 27/04/2009, remitió carta documento al accionado dando por rescindido el contrato por su exclusiva culpa e intimándolo a restituirle las sumas oportunamente sufragadas por su parte, prestación que nunca fue satisfecha por su contraria.
En definitiva, solicitó que se hiciese lugar a la demanda, teniéndose por rescindido (rectius: resuelto) el contrato y condenando al demandado a restituir a su parte la suma de $63.000 abonada en su momento por su parte, con más sus respectivos intereses y costas.
(2) Corrido el pertinente traslado de ley, compareció al juicio el accionado Marcelo Fabián Samia, quien contestó la demanda a fs. 112/22, oponiéndose al progreso de la pretensión y solicitando el rechazo de ella, con costas a cargo de la accionante.
Luego de efectuar una negativa general y pormenorizada de todos y cada uno de los hechos alegados en el escrito de inicio que no hubiesen sido objeto de un expreso reconocimiento, desconoció -en particular- que la actora hubiese cumplido con el contrato celebrado. Negó asimismo que su parte, en su rol de “desarrollador”, debiese efectuar entregas mensuales; toda vez que la cláusula quinta (5a) era clara al señalar que el planeamiento se basaba en un análisis de los requerimientos, por lo que lo previsto resultaba un cálculo meramente aproximado, encontrándose sujeto a revisiones.
Alegó que sólo uno de los pagos efectuados por el usuario fue realizado en término y que a partir de allí interrumpió los sucesivos pagos desde el mes de diciembre de 2007 hasta abril de 2008, forzando a su parte a una “demostración” para continuar con el cumplimiento de sus obligaciones. Agregó que en el contrato se dejó constancia de que a fines del mes de diciembre de 2008 debía hacerse entrega de una primera versión que correspondía a las ochocientas (800) horas de trabajo consignadas en el presupuesto que integraba el contrato y que se encontraban ampliamente vencidas, sin haber abonado la contraria las tres (3) últimas cuotas.
Hizo hincapié en que su parte continuó trabajando en la instalación del sistema de gestión integral, no obstante la mora del usuario en el cumplimiento de los pagos a su cargo. En tales condiciones, negó que la accionante hubiese cumplido con la totalidad de las obligaciones comprometidas, puesto que había incurrido en la mora en el cumplimiento del cronograma de pagos acordado.
Desconoció, por lo demás, que su parte no hubiese entregado siquiera un módulo o una demostración del sistema, agregando que se adaptó un sistema de otro cliente para demostrar la tecnología creada; de conformidad con el CD acompañado con dicha presentación.
Expresó que la relación con “Zival´s S.A.” comenzó cuando ésta le requirió la creación de una nueva tecnología que permitiese mantener la información en tiempo real en un local de ventas más allá de su distribución geográfica a un costo mínimo. Ello implicaba que si se modificaba el inventario los demás vendedores del local debían poder apreciarlo y, por otra parte, ello debía ser informado a los demás negocios para evitar que vendiesen un producto que ya no estaba disponible.
Puso de resalto que, por las características especiales del desarrollo, sus pruebas y verificaciones debían realizarse en entornos reales para la puesta en marcha de los programas incorporados, lo cual debía hacerse por medio de comprobaciones que debían acordarse con el personal de “Zival´s S.A.” y agregarse al presupuesto si los tiempos no podían absorberse dentro de la planificación estimada.
Indicó que, frente a la complejidad que representaba el desarrollo de la nueva tecnología, debió desarrollar un servidor llamado “ServidorRMI” que lograba tener la información en tiempo real para las terminales según el requerimiento del cliente, aclarando que ello le consumió la mitad del tiempo presupuestado, lo que fue debidamente informado a la accionante.
Sostuvo que si bien había incorporado un colaborador a su propio costo para que relevase los aspectos funcionales del sistema, lo cierto era que el cliente se manifestó insatisfecho, por lo que decidió continuar el desarrollo en forma personal.
Aseveró que debió integrar el servidor creado con otro de distribución libre llamado “JBoss” y que cuando lo comunicó a “Zival´s S.A.” ésta le respondió que los pagos cesarían hasta tanto que no recibiese una demostración sobre el funcionamiento del sistema. Añadió que, como todavía no se habían creado las partes del sistema que atendían los requerimientos funcionales, y al ser el usuario un profesional fuera del ambiente de sistemas, tuvo que adaptar un sistema a la tecnología creada y ello importó una demora de tres (3) meses.
Puso de resalto que, a partir de ese entonces, las horas que presupuestó a “Zival´s S.A.” se agotaron; pese a lo cual, por conversaciones mantenidas con su cocontratante en las que le aseguraron que el software se vendería por lo menos en tres (3) negocios más, optó por continuar con el proyecto pese a que diversas circunstancias personales le ocasionaron retrasos en su tarea.
Adujo que, a pesar de haber requerido ciertos datos a “Zival´s S.A.” a los fines de solucionar ciertos problemas de incoherencias en la información, señaló que los recibió recién después del vencimiento del contrato y que, al examinarlos advirtió que se encontraban en tal mal estado que no podía realizarse una importación directa desde ninguna herramienta informática.
Manifestó que intentó avanzar en el aspecto funcional pero que siempre existían problemas de falta de integración en la información suministrada. Explicó los detalles técnicos relativos a los requerimientos del cliente, al desarrollo de un servidor en tiempo real, sus distintas etapas y su modo de integración, para concluir indicando que los archivos entregados tenían tantos problemas que su migración terminó siendo imposible por cualquier medio automatizado; agregando que ésto obligó a diseñar programas especiales para interpretar los datos porque venían en mal formato, desplazados para su lectura e inconsistentes para las transformaciones.
Refirió que cuando se realizaron las pruebas de instalación, los programas fallaron, toda vez que los datos migrados tenían inconvenientes en valores de campos que quedaban nulos, lo cual derivó en que el desarrollo funcional no fuera posible.
Puso de resalto que intentó instalar el trabajo realizado hasta ese momento pero no pudo hacerlo porque no se le otorgó tiempo para ello. Así, aseguró que de su parte siempre hubo buena fe en el cumplimiento de las obligaciones contractuales asumidas y que, contrariamente, la actora incumplió con los pagos acordados, dando por finalizado el contrato de manera imprevista y violenta; de modo tal de crear una situación de incumplimiento de su parte a fin de no continuar involucrado en el proyecto ni cumplir con las obligaciones a su cargo.
Paralelamente, reconvino a la contraria por la suma de $18.000 correspondiente a tres (3) cuotas de $6.000 que -a su entender- se encontraban impagas.
Finalmente, solicitó el íntegro rechazo de la acción y la admisión de la reconvención, con expresa imposición de costas a cargo de la contraria.
(3) Por último, abierta la causa a prueba, sustanciado el proceso y producidas las ofrecidas del modo que da cuenta la certificación actuarial de fs. 236 y vta. y 238 vta., se pusieron los autos para alegar, habiendo hecho uso de tal derecho tanto la parte actora como la demandada, conforme piezas que lucen agregada a fs. 247/53 y 244/5 vta.; dictándose -finalmente- sentencia definitiva a fs. 261/69 vta.
En el fallo apelado, el Señor Juez de grado: i) hizo lugar a la demanda promovida por “Zival´s S.A.” contra Marcelo Fabián Samia, declarando rescindido (rectius: resuelto) el contrato de “desarrollo de software a medida” celebrado y condenando a este último a abonar a la primera la suma de pesos sesenta y tres mil ($63.000), con más sus respectivos intereses, a computarse a la tasa activa que percibe el Banco de la Nación Argentina (BNA) para sus operaciones de descuento a treinta (30) días, sin capitalizar, desde la fecha de la emisión por parte del demandado de las facturas copiadas a fs. 79/85 y hasta su efectivo pago; imponiendo además las costas del proceso al mencionado accionado en su condición de vencido en el litigio (Cód. Proc. Civ. y Comercial: 68) y; ii) rechazó la reconvención deducida por el demandado contra la accionante, con costas a cargo del primero.
Para así decidir, el Señor Juez a quo consideró que era preciso, preliminarmente, delimitar el vínculo que se originó entre las partes; destacando que se trató en el sub lite de un “contrato informático” o “contrato sobre informática”. Señaló, en tal sentido, que éste ha sido definido como “todo acuerdo en virtud del cual se crean, conservan, modifican o extinguen obligaciones relativas al tratamiento automatizado de información”; añadiendo que dentro de este tipo de contratos se encontraba uno específicamente relativo a un “software aplicativo”; es decir aquél programa específico que permitía llevar a cabo una determinada función.
En ese contexto señaló que el contrato de software “a medida” acompañado por la actora a fs. 2/8 daba cuenta de que “Zival´s S.A.” contrató a Marcelo Fabián Samia para la elaboración y desarrollo de un software a medida denominado S.A.I. (Sistema de Administración Integral) donde los clientes con sus interfaces gráficas accederían a un servidor de aplicaciones que se conectaría con una base de datos que almacenaría la información derivada de la administración general de la empresa con sus sucursales (véanse constancias de fs. 52/56 acompañadas por la actora que el accionado hizo suyas).
Señaló el sentenciante que el referido contrato debía contener los módulos de “Ventas”, “Inventario (stock)”, “Compras”, “Impuestos”, “Sueldos y Jornales”, “Facturación”, “Gestión de Cajas”, “Imputaciones Contables”, “Proveedores”, “clientes”, “Importaciones y Exportaciones”, “Costos”, “Cuentas Corrientes”, “Manejo de Editoriales”, “Derechos de Autor” y “Manejo de Retenciones” que se entregarían y mostrarían en forma mensual y luego se integrarían en un único software.
Indicó así que, por la elaboración y desarrollo del sistema que culminaría con la entrega del software integral, el usuario debía abonar un adelanto de $20.000 por comienzo de obra y cuotas mensuales de $6.000; importes que efectivamente cabía tener por abonados en atención a que el demandado hizo suya la documentación aportada por la actora, entre las que se encontraba: 1) la factura n° 0001-00000105 de fecha 24/08/2007 en concepto de “anticipo desarrollo de sistema de gestión” por la suma de $20.000, 2) la factura n° 0001-00000106 datada el 05/10/2007 en concepto de “cuota 1 de 10 por desarrollo de sistema” por la suma de $6.000, 3) la factura n° 0001-00000109 de fecha 25/10/2007 en concepto de “cuota 2 de 10 por desarrollo de sistema S.I.A.” por la suma de $6.000, 4) la factura n° 0001-00000111 de fecha 27/11/2007 en concepto de “cuota 3 de 10 del desarrollo del sistema S.I.A” por la suma de $6.000, 5) la factura n° 0001-00000115 del 15/04/2008 en concepto de “honorarios” por la suma de $6.000, 6) la factura n° 0001-00000116 de fecha 06/05/2008 en concepto de “honorarios” por la suma de $6.000, y 7) la factura n° 0001-00000117 fechada el 12/06/2008 en concepto de “dos cuotas del sistema S.A.I. y reconocimiento de costos adicionales” por la suma de $13.000.
Destacó que, en ese marco, correspondía determinar si los incumplimientos invocados realmente existieron y si éstos justificaron la rescisión del contrato por parte de la actora. Adujo, en tal sentido que, según surgía de la peritación en ingeniería informática obrante a fs. 216/8, el accionado no cumplió con la tarea encomendada y que el software que se encontraba inserto en el disco rígido no cumplía con el objeto del contrato. Añadió que, de acuerdo a la pericia, existían en dicho disco rígido partes de un sistema que no se encontraba en funcionamiento; destacando que el grado de avance era de solo un 25% (v. respuesta al punto de pericia n° 4 ofrecido por la actora, a fs. 217).
Resaltó que a ello se añadía cuanto surgía del acta de constatación notarial de fs. 34, en la que el propio demandado, con fecha 27/04/2009, reconoció que no pudo hacer entrega de la máquina con el sistema de gestión integral instalado en su totalidad, por no haber contado con el tiempo suficiente para realizarla y que ésto se debía a un inconveniente habitual en la instalación de ese tipo de software.
Aclaró que tales conclusiones coincidían con lo declarado por la testigo María Constanza Abuchanab -quien tuviera en su poder el disco rígido conteniendo el software objeto de autos desde el 27/04/2009 hasta que le fue requerido por el Juzgado de origen- (v. respuesta a la pregunta n° 1 ofrecida por la actora, a fs. 175).
Arguyó -entonces- que podía concluirse que lo desarrollado no cumplía con el Sistema de Administración Integral convenido, resultando aplicable analógicamente al caso lo previsto para el contrato de locación en lo referente a que el locador debía entregar la cosas en buen estado, desde que le garantizaba al locatario su uso y goce (CCiv:1514).
Indicó que, en los casos de provisión de software como el de la especie, el accionado debió entregar a la actora un software con las características acordadas, y apto para el destino que el usuario quería otorgarle.
Destacó que, contrariamente, el experto dio cuenta de que ello no ocurrió en la especie al dictaminar que el software que se encontraba en el disco rígido objeto de dicho informe no contaba con una interfaz gráfica que permitiese ser utilizada por un operador (v. respuesta al punto de pericia n° 5 ofrecido por el accionante, a fs. 218).
Hizo hincapié el a quo que el proveedor informático contraía una “obligación de resultado”, que se traducía en asegurar la aptitud de tales elementos a los requerimientos hechos por el cliente para que con ellos este último llenase la utilidad que perseguía, aclarando que, en ese marco.
Marcelo Fabián Samia se obligó a asegurarle a “Zival´s S.A.” una finalidad determinada mediante el Sistema de Administración Integral, y ello significó un compromiso consistente en proveer un programa que le fuera útil en la gestión de su empresa.
Manifestó que, en tales condiciones, la responsabilidad emergente de la informática no podía escapar de los lineamientos generales de la responsabilidad civil; mas en el caso de los contratos informáticos se trataba de una responsabilidad de tipo objetiva, en tanto la obligación del proveedor era de resultado; toda vez que el software debía cumplir en forma satisfactoria la función para la cual se lo creó.
Explicó que -de ese modo- el usuario sólo debía demostrar la falta de obtención del interés que motivó el contrato; dicho de otro modo, el incumplimiento material o formal.
Aclaró que, por su parte, el proveedor para eximirse de responsabilidad debía acreditar que el incumplimiento se debía a una causa exógena, esto es, a un caso fortuito, culpa del usuario o de un tercero, indicando que su responsabilidad era de tipo contractual.
Estimó que, en ese orden, la actora demostró que el software que el accionado desarrollara a su solicitud no se encontraba operativo, es decir, que éste no le resultaba de utilidad alguna, dando cuenta con ello del incumplimiento en el que había incurrido demandado en la ejecución del programa de software solicitado.
Argumentó así el anterior sentenciante que, no habiendo las partes acordado expresamente acerca de la facultad de resolver el contrato objeto de autos, la cuestión debía analizarse a la luz de las reglas que la ley establecía para el pacto comisorio tácito.
Entendió que, sobre tales bases, la requirente podía reclamar el cumplimiento de la prestación o bien pretender la resolución del contrato, más para ello primero debía intimar el cumplimiento bajo apercibimiento de resolver. Añadió que el requerimiento al que aludía el CCom:216 constituía una carga que el interesado debía satisfacer para lograr la resolución contractual por incumplimiento de la contraparte.
Puso de resalto que la carta documento de fecha 26/02/2009 cumplió con lo requerido por dicho artículo (CC: 216), en tanto mediante ésta la actora intimó al accionado a cumplir con sus obligaciones contractuales bajo apercibimiento de dar por rescindido el contrato por su exclusiva culpa y, al no obtener respuesta favorable, hizo efectivo el apercibimiento mediante carta documento de fecha 27/04/2009 y dio por rescindido el contrato por su exclusiva culpa. Concluyó así que la demanda debía prosperar en todas sus partes.
Asimismo, en cuanto a la reconvención -por medio de la cual el demandado reconvino a la actora por el cobro de la suma de $18.000 correspondiente a tres (3) cuotas del contrato de desarrollo de software que se encontrarían impagas-, destacó que, al haber quedado acreditado que el accionado no cumplió con la tarea comprometida (CCiv:510), podía colegirse que no se encontraba habilitado a requerir el precio de lo convenido (CCiv:1201). Añadió que como la actora rescindió el contrato que la uniera con el demandado, no podía admitirse como válido que adeudase cuota alguna en virtud de dicho contrato; razón por la cual la reconvención deducida debía ser rechazada.
Concluyó así el sentenciante que, como consecuencia de todo ello, correspondía -por un lado- hacer lugar a la demanda declarando rescindido (rectius: resuelto) el contrato de “desarrollo de software a medida” celebrado y condenando a Marcelo Fabián Samia a restituir a “Zival´s S.A.” la suma de $63.000, con más sus respectivos intereses, calculados según las pautas explicitadas en el fallo y las costas del proceso. Desestimó como contrapartida la reconvención deducida por el accionado contra la actora, con costas a cargo de aquél.
III. Los agravios.
Contra dicho pronunciamiento se alzó únicamente el demandado, mediante la apelación deducida a fs. 279, recurso que sustentó a través del memorial obrante a fs. 317/20 vta., cuyo traslado fue contestado por la accionante, a fs. 323/8.
Se agravió el recurrente de que el Magistrado de grado hubiera efectuado una lectura parcial del contrato de software “a medida” suscripto entre las partes, lo que habría ocasionado un error en la interpretación de éste. Señaló, en tal sentido, que la actora omitió adjuntar con el escrito de demanda una parte integrante del mencionado contrato, esto es, el presupuesto, en el que se detallaban las pautas y precisiones técnicas para la realización de las tareas encomendadas, las cuales detalló.
Se quejó asimismo de que el anterior sentenciante hubiera efectuado una nula referencia a la pericia técnica practicada en la causa, con sus correspondientes impugnaciones; particularmente aquella relativa a que el experto no procedió a un análisis profundo del contenido del disco rígido peritado y no determinó -tampoco- cuáles líneas de código escrito se encontraban en aquél, como parte del software. Aseveró, en tal sentido, que el a quo tampoco apreció que el experto admitió -en su respuesta a la impugnación presentada por su parte- que el software de base de datos se encontraba instalado, así como el servidor de aplicaciones y los módulos “Inventario”, “Clientes” y “Proveedores”.
Objetó, por su parte, que el Magistrado de grado no hubiese valorado que la actora -en su condición de usuaria del sistema- debía entregar la totalidad de los datos necesarios para la conclusión del trabajo asignado a su parte, lo que no aconteció en la especie, toda vez que “Zival´s S.A.” únicamente habría aportado información parcial e incompleta, impidiendo la conclusión de la tarea encomendada.
Criticó, por último, que el a quo no hubiese apreciado que el incumplimiento contractual atribuido a su parte se debió con exclusividad a la reticencia en la entrega de los datos necesarios para ser incorporados en el sistema por parte de la actora, sin los cuales no podían ser ejecutados los programas requeridos. Señaló, entonces, que el referido incumplimiento tuvo origen en la falta de colaboración de la usuaria del sistema.
(1.) El thema decidendi.
Preliminarmente, corresponde comenzar por puntualizar que, a la luz de los agravios precedentemente descriptos, se advierte que el accionado no se quejó del rechazo de la reconvención por parte del Juez de grado, motivo por el cual es dable dejar aclarado ante todo que, al ser ésta una cuestión que no se halla controvertida ante esta Alzada, no corresponde que la Sala ingrese en su tratamiento en razón de haber adquirido firmeza la sentencia sobre ese particular.
Hecha esta aclaración, entiendo que el thema decidendi reside en dilucidar si resultó acertada la decisión del Señor Juez de grado consistente en receptar la demanda, declarando rescindido (rectius: resuelto) el contrato de “desarrollo de software a medida” celebrado entre las partes condenando al accionado a restituir a “Zival´s S.A.” las sumas abonadas en virtud de aquél, o bien si correspondía desestimar esas pretensiones sobre la base de no haber mediado en realidad un incumplimiento de su parte sino que la causa de la frustración del contrato residió en el comportamiento de la actora de suspender el cronograma de pagos y dejar de aportar la información comprometida para el desarrollo exitoso del programa y la debida conclusión del proyecto encomendado.
A la elucidación de esa cuestión -central para la solución del conflicto- corresponde entonces pasar a abocarse seguidamente.
(2.) Aclaración preliminar.
Lo primero que debo señalar antes de entrar de lleno en el análisis de la problemática planteada es que una minuciosa lectura del memorial presentado por el accionado a fs. 317/20 vta. permite observar -ante todo- que la endeble argumentación desarrollada en dicha pieza, no constituye -en rigor- una crítica concreta, seria y razonada de las apreciaciones que dan sustento al pronunciamiento atacado en los términos exigidos por la ley ritual, con lo que -en principio- no se advierte satisfecha la carga impuesta al recurrente por el Cód. Proc. Civ. y Comercial: 265.
Sin embargo, este Tribunal siempre se ha guiado en este campo con un criterio de amplia tolerancia para ponderar la suficiencia de la técnica recursiva exigida por el citado art. 265 de la ley adjetiva, por entender que esa amplitud de criterio es la que más adecuadamente armoniza el cumplimiento de los requisitos legales impuestos por la norma jurídica antes citada, con la garantía de la defensa en juicio que tiene en nuestro orden jurídico raigambre constitucional (CN: 18).
De allí entonces que el criterio de apreciación a este respecto debe ser necesariamente amplio, atendiendo a que, por lo demás, los agravios no requieren formulaciones sacramentales, alcanzando así la suficiencia requerida por la ley procesal cuando contienen, en alguna medida, aunque sea precaria, una crítica concreta, objetiva y razonada a través de la cual se ponga de manifiesto el error en que se ha incurrido -o que se atribuye a la sentencia- y al mismo tiempo se refuten las consideraciones o fundamentos en que aquella fue sustentada para, de esta manera, descalificarla como acto jurisdiccional.
Pero también se ha dicho, en forma reiterada, que no obstante tal amplitud en la apreciación de la técnica recursiva, existe un mínimo por debajo del cual las consideraciones o quejas traídas carecen de entidad jurídica como “agravios” en el sentido que exige la ley de forma, tal como ocurre en el sub-examine, en donde el apelante no plantea otra cosa que una mera disconformidad con lo decidido en la anterior instancia. Y es -en esa línea de pensamiento- que no resulta legalmente viable discutir el criterio judicial que da sustento a la sentencia que se cuestiona si no se apoya la oposición en un basamento idóneo o sin que sean aportadas razones jurídicas que permitan dar sustento a un distinto punto de vista (cfr. esta Sala, 27/08/1999, in re “Superintendencia de Riesgos de Trabajo c. Omega ART S.A.”, entre muchos otros).
En ese marco, no puede dejar de tenerse presente que el demandado recurrente no controvirtió ninguno de los aspectos medulares que tuvo en cuenta el juez en su sentencia para considerar configurada la responsabilidad de dicha parte, sino que se limitó a efectuar consideraciones genéricas y meras discrepancias que en nada contribuyen a robustecer su estrategia defensiva. En esa inteligencia, se aprecia que el accionado no logró desvirtuar primeramente que, según surgía de la peritación en informática obrante a fs. 216/8, el software suministrado por el accionado que obraba en el disco rígido extraído del equipamiento informático de la actora no respondía al objeto comprometido en el contrato, coexistiendo en éste partes de un sistema que no se encontraba en funcionamiento, más allá de que el grado de avance del desarrollo del programa proyectado no era superior a un 25 %.
Tampoco rebatió el accionado el argumento conforme al cual de acuerdo con el acta de constatación notarial glosado a fs. 34, el propio accionado admitió, con fecha 27/04/2009, que no había podido hacer entrega de la máquina con el sistema de gestión integral instalado en su totalidad por no haber contado con el tiempo suficiente para realizarla debido a un inconveniente habitual en la instalación de ese tipo de software.
Tampoco controvirtió idóneamente el recurrente la conclusión del experto en informática en el sentido de que lo desarrollado no cumplía con el sistema de administración integral convenido; habida cuenta que el software que se encontraba en el disco rígido no contaba con una interfaz gráfica que permitiese ser utilizada por un operador y que por lo tanto no se encontraba operativo ni le resultaba de utilidad alguna a la actora, dando ello suficiente cuenta del incumplimiento del demandado y de la justificación de la facultad rescisoria ejercida por esta última.
Lo hasta aquí referido constituye evidencia más que suficiente para concluir que la queja de la apelante carece de la debida entidad en el plano ritual como para ser seriamente considerada como tal por este Tribunal.
Sin embargo, más allá de que lo precedentemente aseverado bastaría para decidir sin más el rechazo del recurso bajo estudio, en honor al respeto y tolerancia que, como ya se dijo, esta Sala siempre ha tenido con el ejercicio del derecho de defensa en juicio juzgando con amplitud la exigencia contenida en el Cód. Proc. Civ. y Comercial:265, habré de abordar aunque más no sea someramente la queja ensayada a efectos de despejar cualquier duda acerca de la improcedencia de la pretensión recursiva. Comenzaré para ello con hacer una breve referencia a la esencia jurídica del contrato informático celebrado entre las partes poniendo especialmente el acento en la índole de la responsabilidad que le cabe al proveedor en el marco de ese vínculo negocial.
Veamos.
(3.) Naturaleza jurídica del contrato de provisión software e índole de la responsabilidad emergente del mismo para el proveedor informático.
Es de la esencia de los contratos vinculados a la provisión de software o de programas informáticos, mucho más cuando se trata de programas o sistemas desarrollados a la medida de un cliente en particular, como el de la especie, la obtención de una prestación de servicio informático que responda a las necesidades del usuario.
Desde tal perspectiva, este último espera un resultado funcional útil que derive de la aplicación de la máquina, el programa de su actividad, el sistema, red, bien o servicio informático de que se trate.
En los términos indicados, la utilidad perseguida por el requirente o usuario es en sí mismo un objetivo que está presente no sólo en la provisión del hardware o del software, sino también en el mantenimiento del sistema y otros aspectos propios de la actividad de quien provee bienes o servicios de informática.
El proveedor, en suma, ofrece una máquina, un sistema, bien o servicio informático basándose en la utilidad que brinda, y el adquirente busca satisfacer una necesidad funcional.
Bajo tal entendimiento de cosas, la doctrina y la jurisprudencia coinciden en cuanto a que el proveedor informático contrae una “obligación de resultado”, que se traduce en asegurar la aptitud de tales elementos a los requerimientos hechos por el cliente para que con ellos este último llene la utilidad que persigue (cfr. esta CNCom., Sala D, 13/05/2008, in re “Argentoil S.A. c. Soft Pack S.A. s/ ordinario”; ídem, Sala B, 16/09/1988, in re “De Ambrosi Lameka S.A. c. Centro de Computación de Datos S.A.C.O.M.A.”; en igual sentido, Parellada, C., “Daños en la actividad judicial e informática desde la responsabilidad profesional”, Buenos Aires, 1990, pág. 273; en igual sentido, Bergel, S., “Informática y responsabilidad civil”, en rev. “Informática y Derecho”, Buenos Aires, 1988, vol. 2, pág. 153, espec. pág. 189; Guastavino, E., “Responsabilidad civil y otros problemas jurídicos en computación”, Buenos Aires, 1987, pág. 80).
Cabe recordar, en este punto, que las “obligaciones de resultado” son aquéllas en las cuales el deudor está obligado a asegurar una finalidad determinada (cfr. Llambías, J., “Tratado de Derecho Civil – Obligaciones”, t. I, Buenos Aires, 1973, n° 171, págs. 209/13; en igual sentido, Cazeaux, P. y Trigo Represas, F., “Derecho de las Obligaciones”, t. 1, La Plata, 1979, págs. 289/90).
Pues bien, en el caso particular que nos ocupa, cabe afirmar que todas las obligaciones que el demandado asumió frente a la actora fueron “de resultado”.
Repárese, en primer lugar, en que lo contratado fue la provisión de un software “a medida” a requerimiento del usuario, denominado “Sistema de Administración Integral” (“S.A.I.”) -véase fs. 2 del contrato de software “a medida” celebrado entre actora y demandado-.
Todo software -aun si se tratara de un programa standard-, debe reunir, como mínimo, determinados requisitos que se consideran configurativos de una adecuada prestación, entre los cuales se encuentra, por ejemplo, el hecho de que debe ser fiable, esto es, capaz de funcionar sin errores dentro de los parámetros generalmente aceptados de fallas; a lo que se suma que debe ser adecuado a las necesidades/exigencias del cliente y que debe cumplir, a su vez, con ciertas pautas mínimas de funcionamiento en orden al número de operaciones, tiempo de acceso, tiempo de respuesta, etc. De allí que la obligación del proveedor del programa de computación no deje de ser “de resultado” -ni siquiera- por el hecho de que sea una versión standard (cfr. esta CNCom., Sala D, 13/05/2008, in re “Argentoil S.A. c. Soft Pack S.A…”; cit. precedentemente; en este preciso sentido: Bergel, S., “Informática y responsabilidad civil”, ob. cit., pág. 190) y con mayor razón aún tal regla es exigible si se trata, como en el sub lite, de una versión “a medida” desarrollada a requerimiento del usuario, “Zival´s” en este caso (véase fs. 2 del contrato celebrado).
Dentro de este esquema, y asumido que cabe encuadrar las prestaciones asumidas por el proveedor informático dentro de “obligaciones de resultado”, en las que el deudor asegura el logro del interés final pretendido por el acreedor, ello implica que basta a este último demostrar la falta de obtención de ese interés, es decir, el mero incumplimiento material o estructural de la obligación asumida, para que, al igual que en cualquier hipótesis de responsabilidad objetiva, surja una presunción de adecuación causal contra el deudor. Tal es el hecho constitutivo de la pretensión que el acreedor demandante debe probar de acuerdo al Cód. Proc. Civ. y Comercial:377.
Por su lado, cumplida por el acreedor la carga probatoria indicada, se traslada al deudor la carga de demostrar cualquiera de los hechos impeditivos o extintivos incorporados al derecho en el que base su defensa o excepción, es decir, la ausencia de cualquiera de los elementos constitutivos del acto ilícito contractual nacido del incumplimiento de una obligación de resultado, con aptitud para romper el nexo causal. En caso de no satisfacerse esta exigencia juega en contra la regla del onus probandi, en razón de haberse omitido la conducta probatoria del caso según lo prescripto por el citado art. 377 de la ley de rito (cfr. esta CNCom., Sala D, 13/05/2008, in re “Argentoil S.A. c. Soft Pack S.A…”; cit. más arriba; ídem, Agoglia, M., Boragina, J. y Meza, J., Responsabilidad por incumplimiento contractual, Buenos Aires, 2003, págs. 188/9 y 193/7).
Es que, a diferencia de las obligaciones de medios, en los deberes de resultado, el deudor asegura la obtención de la finalidad tenida en miras por el acreedor al momento de la contratación. En su virtud, el cumplimiento requiere invariablemente la obtención de esa finalidad última cuya obtención ha asegurado el deudor, asumiendo tácitamente los riesgos u obstáculos inherentes al desenvolvimiento del plan de prestación. La frustración del resultado genera la responsabilidad objetiva del solvens, con indiferencia de la conducta diligente que éste haya eventualmente desarrollado en el tránsito del plan de prestación. El planteo no significa prescindir del comportamiento del obligado como componente estructural del objeto de la obligación. Sin perjuicio de ello, en esta especie de relación jurídica es trascendente el interés final, el resultado o la utilidad debida al acreedor (cfr. Agoglia, María M., “Responsabilidad del proveedor informático”, comentario al fallo de esta CNCom, Sala D, 13/05/2008, in re “Argentoil S.A. c. Soft Pack S.A.”, publicado en AR/ DOc. 2011/2008).
En mérito de ello, el incumplimiento estructural, configurado por la falta de obtención del resultado, se identifica con el incumplimiento funcional, del cual emerge la responsabilidad del obligado. Ello así, le está vedado al deudor la exoneración de la responsabilidad mediante la prueba de su no culpa, habida cuenta que la fractura del nexo causal requiere la prueba de una causa ajena (hecho del propio acreedor, no imputable al deudor, de un tercero independiente o del caso fortuito o fuerza mayor). Esta eximente, también denominada causa extraña no imputable al deudor, en la responsabilidad contractual, abarca las tres (3) especies aludidas, desvía el origen del daño a un centro de imputación distinto y, en consecuencia, genera la eximición de la responsabilidad por ruptura del enlace causal.
El análisis revela que las obligaciones de resultado -o de fines- son de naturaleza objetiva. El incumplimiento funcional, por tanto, apareja una responsabilidad de la misma especie, fundada en el factor de atribución objetivo denominado garantía o crédito a la seguridad con sustento en los arts. 1197 y 1198 del Cód. Civil. En conclusión, la culpa está, de este modo, fuera de cuestión, sea como criterio de atribución o como eximente del deber de responder.
Es de observar, todavía, que la aplicación del criterio precedentemente expuesto se aprecia como esencialmente justo en supuestos como el de autos, desde que al proveedor informático le es mucho más fácil acreditar cuál es el defecto que provocó el fracaso que al usuario la prueba de la culpa del prestador.
Cabe aquí recordar la brecha tecnológica que separa a las partes en contrataciones del tipo de las aquí consideradas, para apreciar la necesidad de que también deba jugar la regla probatio incumbit facilius probanti, o sea, que aquél que se encuentra en mejores condiciones para demostrar el origen de un daño es quien debe ser gravado con la carga de prueba (cfr. esta CNCom., Sala D, 13/05/2008, in re “Argentoil S.A. c. Soft Pack S.A…”; cit. más arriba; en igual sentido, Parellada, C., ob. cit., págs. 274/5 y).
En ese marco, cabe concluir señalando que las particularidades de la contratación informática (dentro de las cuales se pueden mencionar la desigualdad de conocimientos informáticos de las partes, la utilización de contratos predispuestos, las expectativas de los usuarios fincadas en la obtención de un resultado útil para la gestión de su empresa, entre otros), a lo que se adiciona los graves daños que puede sufrir una empresa como consecuencia del disfuncionamiento de un hardware o un software y la dificultad probatoria de quienes se encuentran en inferioridad de conocimientos frente al experto (proveedor informático), hace que se torne exigible en este tipo de supuestos un funcionamiento estricto del standard de la buena fe contenido en el art. 1198 del Cód. Civil.
(4.) Lo probado en la especie
La existencia de un claro incumplimiento del accionado en la obtención del resultado comprometido a través del contrato consistente en el desarrollo de un software a medida de los requerimientos de la accionante.
Pues bien, a la luz de las pautas vertidas supra, tengo para mí que, en el sub lite, no puede discutirse que la actora probó debidamente que el demandado incumplió con la obligación de resultado que había asumido a su cargo en punto a la provisión del programa informático a “medida” objeto de la litis.
Primeramente, del texto del contrato de software “a medida” suscripto por las partes con fecha 24/08/2007 (véase fs. 2/8, de la documentación acompañada por la demandante junto al escrito inaugural), se desprende que los contrayentes convinieron, en la cláusula segunda (2a), que el objeto negocial estaría dado por la elaboración y desarrollo de un software a medida a requerimiento del usuario denominado S.A.I. (Sistema de Administración Integral), dejándose constancia -asimismo- que se entregarían y/o mostrarían en forma mensual los módulos ya creados según obraba en el presupuesto y luego se integrarían en un único software, corroborándose que éste se encontrase funcionando y debidamente verificado, cumpliendo con las pautas que se establecían en dicho acuerdo (véase cláusula segunda (2a), a fs. 2).
Se aclaró también en ese mismo texto que el planeamiento se basaba en un análisis inicial de los requerimientos, por lo que era solo aproximado, estando sujeto a revisión.
Para realizar algún cambio en aquél, ambas partes debían convenir los ajustes necesarios, que eran volcados en un acta que se adjuntaba al contrato y que formaba parte de éste (acta de consenso) -véase cláusula quinta (5a), a fs. 3-.
También se estatuyó que debían realizarse relevamientos que estarían a cargo del desarrollador (el demandado Samia), quien sería responsable de éstos, en tanto este último tuviese acceso a toda la información requerida para dicho trabajo (v. cláusula séptima (7a), en su parte pertinente, a fs. 3).
A su vez, si bien no se contempló un tiempo determinado para la elaboración y desarrollo del sistema, el cual culminaría con la entrega del software integral -en las características establecidas en la cláusula segunda-, sí se fijó como tope para la finalización de la primera versión del desarrollo el 31/12/2008 (véase cláusula octava (8a), obrante a fs. 4).
También se contempló que el desarrollador era responsable únicamente por el trabajo realizado acorde a las circunstancias fácticas existentes (necesidades del usuario, equipo de hardware y software que utilizaba, personas que operaran el sistema y aceptadas por el usuario) -véase cláusula décimo tercera (13a) de fs. 5- y que el retraso calendario en la producción, en tanto que no fuera culpa del desarrollador, implicaría un cambio y/o modificación en la planificación del desarrollo; dejándose asentado que -por un lado- el contrato no tenía cuotas establecidas, sino fecha pre-establecida de finalización, la cual si se extendía en el tiempo por culpa no imputable al desarrollador, aumentaría la cantidad de cuotas y -por otro lado- el software debía ser entregado funcionando y verificado en su operatividad, no pudiendo ser entregado en característica “Beta” (considérase el sistema en característica “Beta” cuando éste se ha concretado y finalizado, mas no todavía verificado) -v. cláusula décimo quinta (15a) de fs. 6-.
Por su parte, del acta de constatación labrada mediante escritura pública n° 162 de fecha 26/03/2009 (véase fs. 72 y vta. de la documentación arrimada con el escrito inicial) se extrae que Samia se hizo presente ante la escribana pública interviniente, en presencia de la actora, y manifestó que concurrió a comenzar la instalación del software para el cual fue contratado, la que consistía en instalar y colocar a ejecutar un programa y hacerlo “correr”, para que cuando éste terminase de correr, seguir instalando otro, y así sucesivamente, dejándose aclarado que dicha instalación podía perdurar más de un día.
Se hizo hincapié, en dicho instrumento, que se solicitó a la requirente una máquina por separado a los fines de asegurar la correcta instalación, pidiendo -a su vez- que dicha computadora tuviese un sistema operativo, estuviese aislada y con una amplia memoria. Se dejó constancia que la requirente aceptaba tal solicitud, conviniendo en encontrarse nuevamente con el requerido en ese mismo domicilio, el día 20/04/2009, a los efectos de proceder este último a la instalación del software.
A su vez, del acta de constatación otorgada el 20/04/2009 mediante escritura pública n° 206, de (véanse fs. 74 y vta.), surge que Samia se comprometió a efectuar en la máquina entregada por “Zival´s -con las especificaciones allí detalladas- la instalación del sistema de gestión integral en cuestión y a hacer entrega de dicho programa debidamente instalado el día 27/04/2009.
Finalmente, del acta de constatación labrada por escritura pública n° 225, de fecha 27/04/2009 (véanse fs. 75 y vta.), emerge que habiendo comparecido Samia a la sede de la actora, manifestó que no podía hacer entrega de la máquina con el sistema de gestión integral instalado en su totalidad por no haber contado con el tiempo suficiente para realizarla; señalando asimismo que ésto se debía a un inconveniente habitual en la instalación de este tipo de software, dando ello lugar a que la parte requirente solicitara que se extrajese el disco rígido de la máquina con todo lo instalado, a los fines de ser entregado en depósito y así poder constatar fehacientemente lo existente en aquél a esa fecha, en orden a lo cual un ingeniero en sistemas de información procedió a retirar de la computadora el disco rígido al que se hizo referencia supra, el cual quedaría en depósito bajo la identificación allí detallada.
Repárese en que las escrituras aludidas precedentemente no sólo no fueron desconocidas por el accionado en ocasión de contestar demanda, sino que -además- fueron expresamente reconocidas por dicha parte a fs. 121 y vta. de su responde, así como por la escribana interviniente en la contestación de oficio brindada a fs. 157. A esto se adiciona que tales instrumentos públicos no fueron argüidos de falsos en momento alguno por las partes interesadas, por lo que hacen plena fe en los términos de los arts. 993 y 994 del Cód. Civil.
De su lado, el peritaje de ingeniería en sistemas de información producido a fs. 216/8 confirma que el objeto del contrato celebrado entre las partes era la elaboración y desarrollo de un software “a medida” a requerimiento de la accionante, denominado S.A.I. (Sistema de Administración Integral), compuesto de módulos que debían interactuar entre sí, conformando un único Sistema de Gestión Integral.
Describió el experto ingeniero los distintos módulos del sistema S.A.I.: “Ventas”, “Inventario”, “Compras”, “Impuestos”, “Sueldos y Jornales”, “Facturación”, “Gestión de Cajas”, “Imputaciones contables”, “Proveedores”, “Clientes”, “Importaciones y Exportaciones”, “Costos”, “Cuentas Corrientes”, “Manejo de Editoriales”, “Derechos de Autor” y “Manejo de Retenciones”., Añadió además que la arquitectura de este sistema S.A.I. era “cliente servidor” , donde desde las máquinas clientes con interfaces gráficas, ubicados en sucursales o en casa central, se accedía a la base de datos del servidor central (sic) -véase respuesta al punto de pericia 1°, ofrecido por la parte actora, a fs. 216/7-.
Asimismo, de la compulsa practicada por el perito sobre el disco rígido depositado en la escribanía con fecha 27/04/2009, surgía que el software que se encontraba en dicho disco no cumplía con el objeto del contrato; agregando que desconocía las causas por no haber participado en las etapas de contratación, análisis, desarrollo e implementación de éste (véase respuesta al punto pericial 2°, propuesto por la accionante, a fs. 217).
Enfatizó -seguidamente- el experto que el contenido del disco rígido no respondía al objeto del contrato, aclarando que existían en éste partes de un sistema que no se encontraba en funcionamiento (v. respuesta al punto pericial 3°, de fs. 217).
Explicó así que el grado de avance del programa, en relación al objeto contractual, era de un 25 %. Aclaró, a su vez, que el software que se encontraba en el disco rígido compulsado no contaba con una interface gráfica que permitiese ser utilizada por un operador (véanse respuestas a puntos de pericia 4° y 5° de fs. 217/8). Señaló además que en el disco rígido se encontraban instalados pero no operativos únicamente los módulos: “Inventario (stock)”, “Clientes” y “Proveedores” (véase respuesta al punto 6° de fs. 218, la pericia bajo estudio). Frente a la impugnación formulada por la parte demandada a fs. 222/4, el experto aclaró que en el disco rígido objeto del informe pericial se encontraba: i) un software de base de datos instalado; ii) un servidor de aplicaciones instalado; iii) los módulos “Inventario”, “Clientes” y “Proveedores” instalados sin funcionar; iv) módulos: “Ventas”, “Compras”, “Impuestos”, “Sueldos y Jornales”, “Facturación”, “Gestión de Cajas”, “Imputaciones Contables”, “Importaciones y Exportaciones”, “Costos”, “Cuentas Corrientes”, “Manejo de Editoriales”, Derechos de Autor” y “Manejo de Retenciones” sin instalar (véanse respuestas 2° y 3° de las impugnaciones a la pericia, a fs. 229/30 y fs. 231).
Continuó afirmando el experto, en su contestación a las impugnaciones planteadas, que el objeto del contrato era un sistema con todos los módulos funcionando correctamente e interrelacionados (véase respuesta 2° de fs. 229/30). Explicó, en ese marco, que cuando adujo desconocer las causas de porqué un proyecto de sistemas podía no tener éxito, se refería a que esas causas eran difíciles de determinar y podían variar desde la mala elección de un proveedor en la etapa de contratación, ya fuese porque carecía de experiencia, o bien, la envergadura del sistema lo superaba, o por fallas en las etapas de análisis, desarrollo e implementación; aclarando que en la etapa de análisis era necesario que el comprador del sistema se involucrase y dedicase mucho tiempo, para que el producto final fuese exitoso (v. respuesta 2° de fs. 230).
Concluyó el experto en que, con base en el trabajo realizado hasta ese entonces, para lograr que el sistema descripto estuviese instalado y funcionando, faltaba aproximadamente el 75 % más de trabajo respecto de lo realizado hasta ese momento, cuantificado en horas hombre de un profesional de sistemas con experiencia en la tarea a realizarse (véase respuesta 4°, de fs. 231). Finalizó refiriendo el experto que podría indicarse que el motivo de la falta de ejecución o las razones por las cuales el sistema no era operativo, era que faltaban horas de trabajo de personal idóneo para terminar el sistema y dejarlo operativo y en funcionamiento (véase respuesta 6° de fs. 231/2).
En resumidas cuentas, el examen de los elementos de convicción reunidos en la causa, permite concluir que el objeto del contrato anudado entre las partes -consistente en la elaboración y desarrollo de un software “a medida” de los requerimientos de la accionante, cuyos módulos se entregarían en forma mensual y que luego se integrarían en un único software- no fue cumplido en la especie, siendo imputable tal incumplimiento al demandado, ante la ausencia de prueba idónea tendiente a demostrar la ruptura del nexo causal entre dicho incumplimiento y la frustración del negocio debido a la falta de entrega en debida forma del programa de software oportunamente contratado.
Recuérdese que, tal como se adelantara, el demandado ofreció un servicio informático adquirido por la sociedad actora basándose en la utilidad que brinda para satisfacer una necesidad funcional. Así las cosas, es claro que el proveedor informático contrajo una “obligación de resultado”, -que se traduce en asegurar la aptitud de tales elementos a los requerimientos hechos por el cliente para que con ellos este último llene la utilidad que persigue- que, por lo hasta aquí dicho, se vio frustrada en el sub lite.
Es que, de conformidad con lo que surge de la peritación en ingeniería en sistemas de información examinada supra, el contenido del disco rígido no respondía al objeto del contrato, a lo que se sumaba que existían en éste módulos de un sistema que no se encontraba en funcionamiento (v. respuesta al punto pericial 3°, de fs. 217).
No está demás recordar que el software que se encontraba en el disco rígido compulsado no contaba con una interface gráfica que permitiese ser utilizada por un operador; a lo que se añade la no poco relevante circunstancia de que el grado de avance del programa, en relación al objeto contractual, era de tan solo un 25 %; faltando para su conclusión aproximadamente el 75 % restante de trabajo respecto de lo realizado hasta el momento de practicarse la pericia, cuantificado en horas hombre de un profesional de sistemas con experiencia en la materia.
Ello, en clara contraposición a lo informado por el demandado en el acta de constatación labrada por escritura pública n° 225, de fecha 27/04/2009, en donde adujo falsamente que restaba instalar sólo un 20 % del sistema por falta de tiempo, lo cual, por lo visto, no era precisamente cierto.
Repárese además que el desarrollador del programa no solo no cumplió su cometido durante el tiempo originariamente pactado para la vigencia del contrato (fecha de inicio de la contratación: 24/08/2007 y fecha de finalización de la primera versión del desarrollo y entrega de ésta a la usuaria: 31/12/2008) -véanse fs. 2 y 4)-, sino que tampoco lo hizo durante los meses por los que fue diferida la entrega del trabajo (casi 4 meses más, conforme a lo establecido en el acta de constatación de fecha 20/04/2009, en la que se prorrogó la fecha de entrega del sistema de gestión integral para el 27/04/2009; plazo este último que tampoco fue cumplido por el demandado, pretendiendo justificar nuevamente la falta de entrega del sistema en el hecho de no haber contado presuntamente con “tiempo suficiente” para concluir el trabajo encomendado) -véanse actas de fs. 74 y vta., así como de fs. 75 y vta., a las que se hiciera referencia supra)-.
A lo anterior se adiciona la circunstancia no menos relevante de que no se ha demostrado que la falta de elaboración íntegra del sistema de software contratado se hubiese debido a una causa imputable a la accionante (según el quejoso: la ausencia de colaboración por parte de la usuaria, al no haber suministrado la totalidad de la información requerida), toda vez que la peritación en ingeniería (prueba eficiente a este respecto) refiere -tal como se anticipara- que el motivo de la falta de ejecución o las razones por las cuales el sistema no era operativo, pudo deberse factiblemente al hecho de que faltaban horas de trabajo de personal idóneo para terminar el sistema, a los fines de dejarlo operativo y en funcionamiento (véase fs. 232).
Fue, entonces, la falta de idoneidad del demandado -y no la ausencia de colaboración de la actora- la causa que explica el por qué del fracaso de la convención contractual pactada en su momento entre los ahora litigantes.
Desde tal perspectiva, siendo nítido que el accionado no acreditó la presunta falta de colaboración en el suministro de información enrostrada a la accionante, entiendo que no se configuró en el sub lite un supuesto que justificase la eximición de su responsabilidad por el incumplimiento de la “obligación de resultado” asumida contractualmente por dicha parte.
Lo hasta aquí expuesto se muestra suficiente, en mi parecer, para tener por correctamente configurado el incumplimiento del accionado con la consiguiente legitimidad de la resolución del contrato dispuesta por el a quo a pedido de la actora, deviniendo -por ende- imperativa la obligación de restituir lo oportunamente abonado por esta última, como una consecuencia natural del distracto acaecido.
(5.) Síntesis.
Como corolario de lo hasta aquí expuesto, corresponde -pues- desestimar el recurso de apelación deducido por el accionado y, como consecuencia de ello, confirmar la sentencia recurrida en todo lo que decide y fue materia de agravio, con costas de Alzada a cargo del apelante dada su condición de vencido en esta instancia (Cód. Proc. Civ. y Comercial: 68).
Por todo lo hasta aquí expuesto propicio -entonces- al Acuerdo:
(1.) Rechazar el recurso de apelación interpuesto por el demandado y, en consecuencia;
(2.) Confirmar la sentencia apelada en todo lo que decide y fue materia de agravio.
(3.) Imponer las costas de Alzada a cargo del apelante, dada su condición de vencido en esta instancia (Cód. Proc. Civ. y Comercial: 68).
Así voto.
Por análogas razones, la doctora Míguez y la doctora Uzal adhieren al voto precedente.
Por los fundamentos del Acuerdo precedente, se resuelve:
(1.) Rechazar el recurso de apelación interpuesto por el demandado y, en consecuencia;
(2.) Confirmar la sentencia apelada en todo lo que decide y fue materia de agravio.
(3.) Imponer las costas de Alzada a cargo del apelante, dada su condición de vencido en esta instancia (Cód. Proc. Civ. y Comercial: 68).
(4.) Conforme el monto resultante para la demanda, calculado a la fecha de la resolución de primera instancia que fija los estipendios, atento las etapas efectivamente cumplidas y merituando la labor profesional desarrollada por su eficacia, extensión y calidad, se confirman en pesos … y en pesos …. los honorarios regulados a fs. 268/269 a favor de la doctora A. V. M., del doctor B. E. A. H., del perito ingeniero en sistemas A. M. T. y de la mediadora I. L. L., respectivamente; y, estando solo apelados por altos, se confirman en pesos … los estipendios fijados en las citadas fojas a favor de la doctora S. M. H. (arts. 6, 7, 9, 10, 19, 37 y 38 de la ley 21.839, modif. por la ley 24.432; art. 3 Dcto. ley 16.638/1957 modif. por ley 24.432; anexo III, art. 1, inc. g), del Decr. 1467/2011, reglamentario de la ley 26.589). De otro lado, respecto a la reconvención, atento el monto comprometido, merituando las labores desarrolladas, se confirman en pesos … y en pesos … los honorarios regulados a fs. 268/269 a favor de la doctora A. V. M. y del doctor B. E. A. H., respectivamente; y, estando solo apelados por altos, se confirman en pesos … los emolumentos establecidos en las mentadas fojas a favor de la doctora S. M. H. (arts. 6, 7, 9, 10, 19, 37 y 38 de la ley 21.839, modif. por la ley 24.432).
(5.) Notifíquese a las partes y devuélvase a primera instancia encomendándole al señor Juez disponer las notificaciones pendientes de la regulación de honorarios.
(6.) A fin de cumplir con la publicidad prevista por el art. 1° de la ley 25.856, según el Punto I.3 del Protocolo anexado a la Acordada 24/13 CSJN y con el objeto de implementar esa medida evitando obstaculizar la normal circulación de la causa, hágase saber a las partes que la publicidad de la sentencia dada en autos se efectuará, mediante la pertinente notificación al CIJ, una vez transcurridos treinta (30) días desde su dictado, plazo durante el cual razonablemente cabe presumir que las partes ya habrán sido notificadas. —
Alfredo A. Kölliker Frers. —Isabel Míguez. — María E. Uzal.