Punkty do sprawdzenia w umowie, gdy rozwój systemu jest prowadzony na zasadzie półzlecenia

Obecnie, stopień wykorzystania IT w życiu codziennym i działalności społeczno-gospodarczej w naszym kraju gwałtownie rośnie, wraz z dynamicznym rozwojem wydajności komputerów i rozpowszechnieniem Internetu. W związku z tym, społeczne skutki zatrzymania lub obniżenia funkcji usług i operacji z powodu awarii systemów informacyjnych rosną z dnia na dzień, a poprawa niezawodności i bezpieczeństwa systemów staje się dużym wyzwaniem.

Z drugiej strony, kumulacja umów dotyczących rozwoju systemów IT, które nie były przewidywane w momencie ustawodawstwa, często prowadzi do niejasności treści transakcji. Wizualizacja transakcji opartych na bliskiej komunikacji między zamawiającym (użytkownikiem) a wykonawcą (dostawcą), oraz jasne określenie podziału ról i relacji odpowiedzialności, stają się wyzwaniem.

Ponadto, wraz z tym, jak systemy informacyjne zaczęły być budowane na podstawie różnorodnych kombinacji elementów, zaczęły one obejmować ryzyko związane z kombinacjami, które nie istniały wcześniej.

W celu poprawy niezawodności i bezpieczeństwa takich systemów informacyjnych, Ministerstwo Gospodarki, Handlu i Przemysłu (METI) opublikowało wytyczne, w których przedstawiono model umowy dotyczącej rozwoju systemów, z komentarzami do każdego punktu.

W tym artykule, przytaczając klauzule modelowej umowy Ministerstwa Gospodarki, Handlu i Przemysłu, omówimy punkty do sprawdzenia w umowie, gdy zawierana jest umowa typu quasi-delegacyjnego w zakresie rozwoju systemów IT.

System development and quasi-mandate contract

What is a quasi-mandate contract?

Quasi-mandate contract is defined in the Civil Code by applying the provisions of the mandate contract.

Section 10 Mandate
Article 643 A mandate is created by one party entrusting the other party to perform a legal act, and the other party accepting this, thereby producing its effect.
Article 656 The provisions of this section shall be applied mutatis mutandis to the entrustment of non-legal affairs.

A quasi-mandate contract is a contract with the purpose of one party performing administrative tasks entrusted by another party. The trustee has a duty to perform the work with the care of a good manager (duty of care). The duty of care, simply put, means “doing your best”.

Difference from a contract

In a quasi-mandate contract, as mentioned above, the trustee has a duty of care, but unlike a contract, does not have a duty to complete the work. Therefore, if there is no clear object, the trustee does not bear the warranty liability for defects.
However, since the trustee has a duty of care, in cases of negligence or fatal lack of attention, there may be cases where the trustee bears liability for damages based on non-performance of obligations, or the contract is cancelled.

As mentioned above, in a quasi-mandate contract, the trustee does not have a duty to complete the work. On the other hand, in a contract, the trustee has a duty to complete the work. The following article explains the case of concluding system development in a contract type.

https://monolith.law/corporate/checkpoints-for-contracts-of-system-development[ja]

Model klauzul umowy o zlecenie i punkty kontrolne

Wsparcie w tworzeniu definicji wymagań

(Realizacja usługi wsparcia w tworzeniu definicji wymagań)
Artykuł 〇 Druga strona, po zawarciu indywidualnej umowy określonej w artykule 〇, świadczy usługę wsparcia w tworzeniu definicji wymagań (zwanej dalej “usługą wsparcia w tworzeniu definicji wymagań”) na podstawie dokumentów koncepcyjnych systemu informacyjnego, planów systematyzacji itp. stworzonych przez pierwszą stronę.

2. Druga strona, na podstawie swojej specjalistycznej wiedzy i doświadczenia w zakresie technologii przetwarzania informacji, zapewnia wsparcie w postaci badań, analiz, organizacji, propozycji i doradztwa, aby prace pierwszej strony były realizowane sprawnie i prawidłowo.

Definicja wymagań to proces kompilacji specyfikacji wymagań systemu (funkcji, które powinny być realizowane przez oprogramowanie), który użytkownik zamierza zbudować, i jest to zadanie, które w dużym stopniu zależy od treści pracy użytkownika. W tym rozdziale, zakładamy, że definicję wymagań tworzy użytkownik, a dostawca wspiera ten proces w formie umowy quasi-zlecenia. Jednakże, nawet jeśli jest to umowa quasi-zlecenia, dostawca nie jest zwolniony z jakiejkolwiek odpowiedzialności, ponieważ jako zleceniobiorca ma obowiązek dołożyć należytej staranności. Jeżeli zaniedba ten obowiązek i wsparcie w tworzeniu definicji wymagań nie zostanie prawidłowo zrealizowane, dostawca ponosi odpowiedzialność za niewykonanie zobowiązań z tytułu naruszenia obowiązku dołożenia należytej staranności.

(Zawarcie indywidualnej umowy dotyczącej usługi wsparcia w tworzeniu definicji wymagań)
Artykuł 〇 Pierwsza i druga strona, w odniesieniu do usługi wsparcia w tworzeniu definicji wymagań, ustalają warunki transakcji określone w artykule 〇, punkt 〇, po przeprowadzeniu negocjacji, i zawierają indywidualną umowę dotyczącą usługi wsparcia w tworzeniu definicji wymagań.

Zakres usługi wsparcia w tworzeniu definicji wymagań jest ustalany w indywidualnej umowie zgodnie z warunkami określonymi w poprzednim artykule.

(Spotkanie dotyczące rozważania definicji wymagań)
Artykuł 〇 Pierwsza strona organizuje spotkanie dotyczące rozważania definicji wymagań (zwane dalej w tym rozdziale “spotkaniem dotyczącym rozważania definicji wymagań”) w celu wyjaśnienia lub potwierdzenia kwestii niezbędnych do stworzenia definicji wymagań, z taką częstotliwością, jaką uważa za konieczną, a druga strona uczestniczy w tym spotkaniu i realizuje usługę wsparcia w tworzeniu definicji wymagań.

2. Druga strona również może zorganizować spotkanie dotyczące rozważania definicji wymagań, jeżeli uzna to za konieczne do realizacji usługi wsparcia w tworzeniu definicji wymagań, a pierwsza strona uczestniczy w tym spotkaniu.

W celu stworzenia definicji wymagań, która definiuje wymagania biznesowe i funkcjonalne oraz niefunkcjonalne wymagania systemu, konieczna jest współpraca między działem biznesowym użytkownika, działem systemów informacyjnych i dostawcą. Z uwagi na to, że ten proces jest umową quasi-zlecenia, w punkcie 1 określono, że organizatorem jest użytkownik, a dostawca, który świadczy wsparcie, uczestniczy w tym procesie. Wyjaśnienie lub potwierdzenie kwestii niezbędnych do stworzenia definicji wymagań odbywa się na spotkaniu dotyczącym rozważania definicji wymagań, a użytkownik i dostawca są związani wynikami tego spotkania.

Punkt 2 określa, że dostawca również może zorganizować spotkanie dotyczące rozważania definicji wymagań, jeżeli uzna to za konieczne do realizacji usługi wsparcia w tworzeniu definicji wymagań.

(Zatwierdzenie definicji wymagań)
Artykuł 〇 Gdy pierwsza strona zakończy tworzenie definicji wymagań, pierwsza i druga strona sprawdzają, czy definicja wymagań jest zgodna z decyzjami podjętymi na spotkaniu dotyczącym rozważania definicji wymagań określonym w poprzednim artykule, w okresie określonym w indywidualnej umowie (zwany dalej “okresem sprawdzania definicji wymagań”), a jako dowód potwierdzenia zgodności, osoby odpowiedzialne z obu stron podpisują i pieczętują definicję wymagań. Jednakże, jeżeli w wyniku sprawdzenia stwierdzi się, że definicja wymagań nie jest zgodna z decyzjami podjętymi na spotkaniu dotyczącym rozważania definicji wymagań, pierwsza strona tworzy poprawioną wersję w określonym po konsultacjach terminie, a pierwsza i druga strona ponownie przeprowadzają powyższe sprawdzenie i procedurę potwierdzenia.

2. Definicja wymagań jest uważana za zatwierdzoną po potwierdzeniu przez obie strony, zgodnie z poprzednim punktem.

3. Jeżeli w wyniku poprawek określonych w punkcie 1 konieczne jest zmienienie warunków indywidualnej umowy, takich jak okres realizacji prac, opłata za zlecenie itp., procedura ta jest realizowana zgodnie z artykułem 〇.

Definicja wymagań to faza, w której użytkownik otrzymuje wstępne szacunkowe kosztorysy od dostawcy i ustala wymagania niezbędne do realizacji projektowania systemu itp. Jeżeli wymagania są niejasne, dostawca może mieć trudności z dokładnym oszacowaniem, a w późniejszej fazie rozwoju mogą wystąpić problemy. Ten artykuł określa procedurę, w której użytkownik i dostawca sprawdzają definicję wymagań, która stanowi podstawę dla późniejszych prac rozwojowych, a osoby odpowiedzialne potwierdzają ją poprzez podpisanie i pieczętowanie. W przypadku, gdy w wyniku sprawdzenia definicji wymagań stwierdzi się, że konieczne są poprawki, w punkcie 1 określono procedurę w takim przypadku.

Punkt 2 jasno określa, że definicja wymagań jest zatwierdzona po potwierdzeniu przez obie strony.
Punkt 3 określa, że jeżeli w wyniku poprawek określonych w punkcie 1 konieczne jest zmienienie warunków indywidualnej umowy, takich jak zwiększenie ilości pracy dostawcy, przedłużenie harmonogramu itp., należy dokonać odpowiednich zmian.

(Zakończenie prac i potwierdzenie)
Artykuł 〇 Druga strona, w ciągu ○ dni po zatwierdzeniu definicji wymagań określonej w poprzednim artykule, sporządza raport końcowy i składa go pierwszej stronie.

2. Pierwsza strona, w okresie określonym w indywidualnej umowie (zwany dalej “okresem sprawdzania zakończenia usługi wsparcia w tworzeniu definicji wymagań”), sprawdza ten raport końcowy.

3. Jeżeli pierwsza strona nie ma zastrzeżeń co do treści tego raportu końcowego, podpisuje i pieczętuje potwierdzenie zakończenia prac i przekazuje je drugiej stronie, potwierdzając zakończenie usługi wsparcia w tworzeniu definicji wymagań.

4. Jeżeli pierwsza strona nie zgłosi zastrzeżeń na piśmie z konkretnym uzasadnieniem w okresie sprawdzania zakończenia usługi wsparcia w tworzeniu definicji wymagań, uważa się, że potwierdziła zakończenie prac po upływie okresu sprawdzania zakończenia usługi wsparcia w tworzeniu definicji wymagań.

Z uwagi na to, że ten proces jest umową quasi-zlecenia, ten artykuł określa procedurę sprawdzania, czy dostawca prawidłowo wykonał prace wsparcia zgodnie z obowiązkiem dołożenia należytej staranności, na podstawie raportu końcowego, który dokumentuje treść prac.
Punkt 1 określa obowiązek dostarczenia raportu końcowego.
Punkt 2 jasno określa okres sprawdzania raportu końcowego, aby uniknąć opóźnień w jego sprawdzeniu.
Punkt 3 określa, że zakończenie usługi wsparcia w tworzeniu definicji wymagań jest potwierdzane przez użytkownika poprzez podpisanie i pieczętowanie potwierdzenia zakończenia prac.
Punkt 4 określa domniemanie potwierdzenia zakończenia prac, jeżeli użytkownik nie zgłosi zastrzeżeń na piśmie w okresie sprawdzania zakończenia usługi wsparcia w tworzeniu definicji wymagań. Ten przepis uwzględnia fakt, że jeżeli użytkownik z jakiegoś powodu nie przeprowadzi procedury potwierdzenia na czas, może to spowodować opóźnienie w dalszych pracach lub rozpoczęcie dalszych prac bez jasnego potwierdzenia, co może prowadzić do niejasności w relacjach odpowiedzialności między użytkownikiem a dostawcą.

Tworzenie dokumentacji zewnętrznego projektu

(Realizacja usług wspierających tworzenie dokumentacji zewnętrznego projektu)
Artykuł 〇: Strona B, po zawarciu indywidualnej umowy określonej w artykule 〇, świadczy usługi wspierające tworzenie dokumentacji zewnętrznego projektu przez stronę A (zwane dalej “usługami wspierającymi tworzenie dokumentacji zewnętrznego projektu”).

2. Strona B, na podstawie specjalistycznej wiedzy i doświadczenia w zakresie technologii przetwarzania informacji, zapewnia wsparcie w postaci badań, analiz, organizacji, propozycji i porad, aby prace strony A były realizowane płynnie i prawidłowo, z zachowaniem należytej staranności administratora.

Tworzenie dokumentacji zewnętrznego projektu to zadanie polegające na opracowywaniu zasad użytkowania interfejsów, takich jak ekrany i raporty. Dokumentacja zewnętrznego projektu powinna zawierać wszystkie informacje, które umożliwią dostawcy rozwijanie programu na jej podstawie. Dokumentacja zewnętrznego projektu zawiera szczegółowe informacje o zastosowaniu formularzy, ale to użytkownik, który decyduje o zawartości pracy, ma prawo do zmiany specyfikacji. Dlatego ten artykuł zakłada, że użytkownik jest odpowiedzialny za ukończenie dokumentacji zewnętrznego projektu, a dostawca, jako pełnomocnik w umowie quasi-mandatowej, wspiera go w tym procesie. Jednakże, mimo że jest to quasi-mandat, dostawca nie jest zwolniony z odpowiedzialności i ma obowiązek należytej staranności. Dlatego, jeśli nie spełni tego obowiązku i nie udzieli odpowiedniego wsparcia w tworzeniu dokumentacji zewnętrznego projektu, może ponieść odpowiedzialność za niewykonanie zobowiązań z tytułu naruszenia obowiązku należytej staranności.

(Zawarcie indywidualnej umowy dotyczącej usług wspierających tworzenie dokumentacji zewnętrznego projektu)
Artykuł 〇: Strony A i B, w odniesieniu do usług wspierających tworzenie dokumentacji zewnętrznego projektu, ustalają warunki transakcji określone w artykule 4, ustęp 1, po konsultacjach i zawierają indywidualną umowę dotyczącą usług wspierających tworzenie dokumentacji zewnętrznego projektu.

Zakres usług wspierających tworzenie dokumentacji zewnętrznego projektu jest ustalany w indywidualnej umowie.

(Zewnętrzne spotkania projektowe)
Artykuł 〇: Strona A, w celu wyjaśnienia lub potwierdzenia kwestii niezbędnych do tworzenia dokumentacji zewnętrznego projektu, organizuje spotkania dotyczące tworzenia dokumentacji zewnętrznego projektu (zwane dalej w tym rozdziale “spotkaniami projektowymi”) w częstotliwości uznanej za konieczną, a strona B uczestniczy w nich i realizuje usługi wspierające tworzenie dokumentacji zewnętrznego projektu.

2. Strona B również może zorganizować spotkania projektowe, jeśli uzna to za konieczne do realizacji usług wspierających tworzenie dokumentacji zewnętrznego projektu, a strona A uczestniczy w nich.

3. Jeśli, w wyniku dyskusji podczas spotkań projektowych, strona A zamierza zmienić treść dokumentacji wymagań, a zmiana ta wymaga zmiany warunków indywidualnej umowy, takich jak okres realizacji i opłata za zlecenie, procedura ta jest realizowana zgodnie z artykułem 〇 (zmiana treści niniejszej umowy i indywidualnej umowy).

Tworzenie dokumentacji zewnętrznego projektu, która określa interfejsy, takie jak ekrany i raporty, wymaga współpracy między użytkownikiem a dostawcą. Ponieważ ten proces jest quasi-mandatem, ustęp 1 określa, że organizatorem jest użytkownik, a dostawca uczestniczy w nim. Wszystkie kwestie dotyczące wyjaśnienia lub potwierdzenia kwestii niezbędnych do tworzenia dokumentacji zewnętrznego projektu są omawiane podczas spotkań projektowych, a dostawca i użytkownik są związani wynikami tych dyskusji. Ustęp 2 określa, że dostawca również może zorganizować spotkania projektowe, jeśli uzna to za konieczne do realizacji usług wspierających tworzenie dokumentacji zewnętrznego projektu. Ustęp 3 określa, że jeśli, w wyniku dyskusji podczas spotkań projektowych, użytkownik zamierza zmienić treść dokumentacji wymagań, a zmiana ta wpływa na warunki indywidualnej umowy, takie jak okres realizacji i opłata za zlecenie, procedura ta jest realizowana zgodnie z procedurą zmiany treści niniejszej umowy i indywidualnej umowy.

(Zatwierdzenie dokumentacji zewnętrznego projektu)
Artykuł 〇: Gdy strona A zakończy tworzenie dokumentacji zewnętrznego projektu, strony A i B sprawdzają, czy dokumentacja zewnętrznego projektu jest zgodna z dokumentacją wymagań zatwierdzoną zgodnie z artykułem 〇 i decyzjami podjętymi podczas spotkań projektowych określonych w poprzednim artykule, w okresie określonym w indywidualnej umowie (zwany dalej “okresem sprawdzania dokumentacji zewnętrznego projektu”), a jako dowód potwierdzenia zgodności, osoby odpowiedzialne z obu stron podpisują i pieczętują dokumentację zewnętrznego projektu. Jeśli jednak, w wyniku sprawdzenia, odkryto, że dokumentacja zewnętrznego projektu nie jest zgodna z dokumentacją wymagań zatwierdzoną zgodnie z artykułem 〇 lub decyzjami podjętymi podczas spotkań projektowych, strona A tworzy poprawioną wersję w określonym po konsultacjach terminie, a strony A i B ponownie przeprowadzają powyższe sprawdzenie i procedurę potwierdzenia.

2. Dokumentacja zewnętrznego projektu jest uważana za zatwierdzoną po potwierdzeniu przez obie strony zgodnie z ustępem 1.

3. Jeśli, w wyniku poprawek określonych w ustępie 1, konieczne jest zmienienie warunków indywidualnej umowy, takich jak okres realizacji i opłata za zlecenie, procedura ta jest realizowana zgodnie z artykułem 〇 (zmiana treści niniejszej umowy i indywidualnej umowy).

Ten artykuł określa procedurę, w której użytkownik i dostawca sprawdzają dokumentację zewnętrznego projektu stworzoną przez użytkownika, a osoby odpowiedzialne z obu stron zatwierdzają ją poprzez podpisanie i pieczętowanie. Może się zdarzyć, że w wyniku sprawdzenia dokumentacji zewnętrznego projektu konieczne będą poprawki, dlatego ustęp 1 zawiera postanowienia dotyczące tej procedury.

Ustęp 2 jasno określa, że dokumentacja zewnętrznego projektu jest zatwierdzana po potwierdzeniu przez obie strony. Ustęp 3 określa, że jeśli w wyniku poprawek określonych w ustępie 1 konieczne jest zmienienie warunków indywidualnej umowy, takie jak okres realizacji i opłata za zlecenie, procedura ta jest realizowana zgodnie z procedurą zmiany treści niniejszej umowy i indywidualnej umowy.

(Zakończenie prac i potwierdzenie)
Artykuł 〇: Strona B, w ciągu ○ dni po zatwierdzeniu dokumentacji zewnętrznego projektu określonej w poprzednim artykule, sporządza raport końcowy i składa go stronie A.

2. Strona A sprawdza ten raport końcowy w okresie określonym w indywidualnej umowie (zwany dalej “okresem sprawdzania zakończenia usług wspierających tworzenie dokumentacji zewnętrznego projektu”).

3. Jeśli strona A nie ma zastrzeżeń do treści tego raportu końcowego, podpisuje i pieczętuje potwierdzenie zakończenia prac i przekazuje je stronie B, potwierdzając tym samym zakończenie usług wspierających tworzenie dokumentacji zewnętrznego projektu.

4. Jeśli strona A nie zgłosi zastrzeżeń na piśmie z konkretnym uzasadnieniem w okresie sprawdzania zakończenia usług wspierających tworzenie dokumentacji zewnętrznego projektu, uważa się, że potwierdziła zakończenie prac po upływie okresu sprawdzania zakończenia usług wspierających tworzenie dokumentacji zewnętrznego projektu.

Ponieważ ten proces jest quasi-mandatem, ten artykuł określa procedurę, w której dostawca, na podstawie obowiązku należytej staranności, sprawdza, czy prawidłowo wykonał prace wspierające, na podstawie raportu końcowego zawierającego zapisy dotyczące wykonanych prac. Ustęp 2 jasno określa okres sprawdzania, aby uniknąć opóźnień w sprawdzaniu raportu. Ustęp 3 określa, że potwierdzenie zakończenia usług wspierających tworzenie dokumentacji zewnętrznego projektu jest dokonywane poprzez podpisanie i pieczętowanie potwierdzenia zakończenia prac przez użytkownika. Ustęp 4 zawiera postanowienia dotyczące domniemania potwierdzenia zakończenia prac, jeśli użytkownik nie zgłosi zastrzeżeń na piśmie z konkretnym uzasadnieniem w okresie sprawdzania zakończenia usług wspierających tworzenie dokumentacji zewnętrznego projektu. Ta klauzula ma na celu uniknięcie sytuacji, w której użytkownik z jakiegoś powodu nie przeprowadza procedury potwierdzenia na czas, co może spowodować opóźnienie w dalszych pracach lub rozpoczęcie dalszych prac bez jasnego potwierdzenia, co może spowodować niejasności w relacjach między użytkownikiem a dostawcą.

Usługi w zakresie rozwoju oprogramowania

Następnym etapem po zasadach dotyczących projektowania zewnętrznego systemu, które jest podstawowym projektem, są zasady dotyczące projektowania wewnętrznego systemu, które jest szczegółowym projektem. W procesie projektowania wewnętrznego systemu, zwykle jest już zdefiniowany cel rozwoju i specyfikacje na podstawie prac wykonanych do tej pory, dlatego w modelowym kontrakcie Ministerstwa Gospodarki, Handlu i Przemysłu (METI) jest to zdefiniowane jako kontrakt na zlecenie. Szczegóły są omówione w poniższym artykule.

https://monolith.law/corporate/checkpoints-for-contracts-of-system-development[ja]

Usługi wsparcia przygotowania i migracji oprogramowania

(Realizacja usług wsparcia przygotowania i migracji oprogramowania)
Artykuł 〇. Strona B, po zawarciu indywidualnej umowy określonej w artykule, wykonuje na rzecz strony A niezbędne wsparcie (zwane dalej “usługami wsparcia przygotowania i migracji oprogramowania”) w zakresie testów systemowych, wsparcia wdrożenia i akceptacji oraz testów operacyjnych przeprowadzanych przez stronę A w celu rzeczywistego wykorzystania oprogramowania.

2. Strona B, opierając się na specjalistycznej wiedzy i doświadczeniu w zakresie technologii przetwarzania informacji, zapewnia wsparcie z należytą starannością administratora, aby prace strony A były realizowane sprawnie i efektywnie.

W niniejszym artykule i poniżej określono postanowienia dotyczące przygotowania i migracji oprogramowania w modelu quasi-delegacyjnym. Na etapie wsparcia wdrożenia i akceptacji systemu, zazwyczaj to użytkownik jest stroną aktywnie działającą, dlatego w modelu umowy Ministerstwa Gospodarki, Handlu i Przemyśłu Japonii (METI), użytkownik jest stroną główną, a dostawca wspiera go w formie quasi-delegacji.
Artykuł 2 określa, że dostawca, jako delegat, ma obowiązek należytej staranności, ponieważ proces ten jest realizowany w modelu quasi-delegacyjnym.

(Zakończenie usług i potwierdzenie)
Artykuł 32. Strona B, w ciągu ○ dni po zakończeniu usług wsparcia przygotowania i migracji oprogramowania, sporządza raport końcowy i przekazuje go stronie A.

2. Strona A przeprowadza kontrolę raportu końcowego w okresie określonym w indywidualnej umowie (zwany dalej “okresem kontroli zakończenia usług wsparcia przygotowania i migracji oprogramowania”).

3. Strona A, jeżeli nie ma wątpliwości co do treści raportu końcowego, podpisuje i pieczętuje potwierdzenie zakończenia usług, przekazuje je stronie B i potwierdza zakończenie usług wsparcia przygotowania i migracji oprogramowania.

4. Jeżeli strona A nie zgłosi sprzeciwu na piśmie z konkretnym uzasadnieniem w okresie kontroli zakończenia usług wsparcia przygotowania i migracji oprogramowania, uważa się, że potwierdziła zakończenie usług po upływie okresu kontroli.

W niniejszym artykule określono procedurę potwierdzenia, czy dostawca, działając jako quasi-delegat, prawidłowo wykonał usługi wsparcia przygotowania i migracji oprogramowania z należytą starannością.
Artykuł 2 stanowi, że dostawca ma obowiązek przedłożyć użytkownikowi raport końcowy w określonym czasie po zakończeniu usług.
Artykuł 3 określa, że użytkownik przeprowadza kontrolę raportu końcowego po określeniu okresu kontroli.
Artykuł 4 określa domniemanie potwierdzenia, jeżeli użytkownik zaniedba potwierdzenie zakończenia usług zgodnie z poprzednimi dwoma artykułami.

Określanie charakteru umowy

Aby określić charakter umowy, należy spojrzeć na całość umowy i rozważyć, czy jej celem jest “dostarczenie gotowego produktu”, czy też “racjonalne wykonanie zadań” przez dostawcę. Ogólnym wyznacznikiem jest to, czy zawartość produktu do zrealizowania jest w pewnym stopniu konkretnie określona i czy projekt jest realizowany w tym kierunku.
Szczegółowe wyjaśnienia dotyczące tego, na co konkretnie zwracać uwagę, znajdują się w poniższym artykule.