Чендлер; Контрактне законодавство Партнера Rechtsanwälte щодо програмного забезпечення Запити на виконання у випадку, якщо вони не приймаються
У попередній статті від 2010 року ми вже повідомляли про випадок BGH від 25 березня 2010 року (Az. VII ZR 224/08). Ця тема досі актуальна для наших клієнтів. Тому я хотів би ще раз поглянути на рішення та пояснити, чи повинен постачальник ІТ-послуг задовольнити одне лише прохання про належне виконання контракту, не маючи жодних підказок щодо того, яка частина програмного забезпечення ще не працює належним чином.
Запит на виконання згідно із законом про трудові контракти
У випадку договору на виконання робіт та надання послуг, підрядник, тобто постачальник ІТ-послуг, виробляє програмне забезпечення відповідно до специфікації (якщо така є, інакше відповідно до домовленостей між двома договірними сторонами).
Це відбувається протягом певного часу. Якщо це перевищено, і замовник програмного забезпечення стає нетерплячим, він в якийсь момент встановить кінцевий термін для завершення контрактної послуги.
Ефективний запит на продуктивність
Якщо у клієнта є ефективний запит на виконання, якщо він лише загалом каже постачальнику ІТ-послуг: "Будь ласка, виконайте контракт xxx, інакше ми відмовляємося від контракту"?
BGH каже: В основному так.
Тому що на відміну від скарги, яка лише після прийняття відбувається, і хто повинен описати конкретну помилку, це відбувається попереду прийняття лише запиту про надання послуги, оскільки вона заборгована за контрактом.
Але ...
Що робити, якщо постачальник ІТ-послуг вважає, що вони створили та впровадили програмне забезпечення відповідно до контракту, тобто що вони належним чином виконали контракт? Чи може замовник все ще посилатися на запит: "Будь ласка, виконайте контракт xxx, інакше ми відмовляємося від контракту"? Яким чином постачальник ІТ-послуг повинен належним чином виконувати контракт, якщо він навіть не знає, в чому проблема?
Деякі наші колеги, схоже, сприймають це по-іншому, але я стверджую, що це загальне прохання Ні достатньо!
У справі Федерального суду від 25.03.2010 року постачальник ІТ-послуг також запитував попереду прийняття дуже конкретного опису кожного окремого дефекту, тобто конкретного відхилення фактичного стану від цільового стану. Зрозуміло, що BGH припинив цей запит. Як замовник повинен описати кожен окремий дефект, якщо він навіть не прийняв програмне забезпечення як таке, що відповідає договору? Лише після прийняття програмне забезпечення стає конкретним для замовника.
Однак в окремих випадках може бути недостатньо лише вимагати виконання контракту, якщо постачальник ІТ-послуг очевидно і з його точки зору законно припускає, що він все-таки виконав контракт. Тоді замовник повинен принаймні вказати, яка функціональність ще не відповідає договору.
На мою думку, про це можна зробити висновок з обговореного тут BGH, який говорить:
«Він [постачальник ІТ-послуг] повинен мати можливість вирішити, чи хоче він прийняти наслідки неналежного виконання або запобігти цьому, вживаючи заходів у встановлений термін. Однак правда, що запит на виконання не може виконати цю мету і є неефективним, якщо підприємець, на його думку, надав послугу в повному обсязі і з піднятої скарги не може зрозуміти, чому замовник не приймає її як відповідну договору.
Однак, всупереч думці апеляційного суду, з цього не можна зробити висновок, що прохання про виконання із зазначеним терміном вже є неефективним, якщо замовник не детально перераховує недоліки у виконанні. Це обмежує вимогу щодо запиту на виконання, оскільки замовник часто не може зробити це через відсутність власної експертизи.
Швидше, цього достатньо, якщо в цьому випадку він скаржиться на відсутність функціональних можливостей. Відповідно, Федеральний суд розглянув запит на заповнення базової версії програмного забезпечення в узгодженому обсязі як достатній, без того, щоб замовник повинен був вказати будь-які наявні дефекти програмного забезпечення ".
BGH продовжує:
“Можуть бути випадки, коли Беручи до уваги особливі договірні відносини та проблеми з виконанням контракту, потрібно додаткове уточнення запиту на виконання може бути. Тут такого випадку немає.
Згідно з узгодженим поданням сторін у записках від 30 травня 2008 року та 18 липня 2008 року, проект просунувся настільки далеко, що була створена не тільки концепція адаптації програмного забезпечення, але вже був розроблений і встановлений прототип. Відповідно до «[…] контракту» від 28 липня 2004 р., Розробка «пілотного проекту», який може бути прийнятий, і подальшого «розгортання» для всієї організації [покупця] все ще очікували. Це було очевидно для відповідача як розробника проекту. Крім того, відповідно до подання позивача сторони мали таке, що можна припустити за відсутності суперечливих висновків апеляційного суду, у спільно веденому списку фіксувалося, які помилки все-таки потрібно було усунути. Не потрібно було посилатися на перелік помилок, який був чинним на момент написання листа від 5 жовтня 2004 року. Відповідач знав цей перелік; попередні списки помилок були помітно застарілими ".
Це дало зрозуміти постачальнику ІТ-послуг у випадку BGH, чому замовник припустив, що контракт ще не був виконаний. У цьому конкретному випадку, як чітко пояснює BGH, не було потреби вказувати помилки програмного забезпечення у запиті на продуктивність.
Те, що BGH уточнює у своєму керівному принципі, що до офіційного повідомлення не потрібно вказувати детальні недоліки до прийняття програмного забезпечення, не означає, що це стосується кожного випадку. Справа не лише в керівних принципах, які містяться в судженнях, а в мотивах рішення. І це не означає, що замовнику потрібно лише вимагати виконання контракту без додаткових деталей. Це також було б абсолютно недоцільно.
У цьому сенсі: щасливого нового року.
Зв'язок
Kramer & Partner mbB Гамбург
Mönckebergstrasse 10 (Barkhof)
20095 Гамбург
Телефон: 040 - 349 603 39
Факс: 040 - 349 603 20
Електронна адреса: [email protected]
Галузь:
Kramer & Partner mbB Берлін
Рахель-Гірш-вул. 10
10557 Берлін
Телефон: 030 - 5900 838 13