O que é a aceitação do desenvolvimento do sistema e quando se aplica a cláusula de aceitação presumida

Num cenário de desenvolvimento de sistemas, a fase de “aceitação” é onde os problemas legais tendem a surgir com mais frequência.

“Aceitação” refere-se à obrigação de inspeção e verificação que surge do lado do cliente quando o fornecedor entrega o produto final. Se, por exemplo, o cliente não realizar a “aceitação” após a entrega, o fornecedor, ou seja, o vendedor, pode encontrar-se numa posição legalmente instável.

Para resolver esses problemas, é comum que os contratos incluam uma cláusula de “aceitação presumida”.

Neste artigo, vamos explicar quando a “aceitação presumida” é aplicada, com base em casos reais.

O que é a aceitação no desenvolvimento de sistemas?

Em primeiro lugar, a “aceitação” num projeto de desenvolvimento de sistemas refere-se ao processo em que o utilizador, que é o cliente, inspeciona e verifica se o produto entregue pelo fornecedor (neste caso, referindo-se ao sistema de TI) está de acordo com as especificações pretendidas.

Do ponto de vista do desenvolvedor, pode ser considerado como um processo de teste para confirmar se o trabalho foi realmente concluído.

O trabalho de desenvolvimento de sistemas de TI, devido à natureza do trabalho, pode facilmente dar ao fornecedor uma grande margem de discricionariedade, o que pode levar a discrepâncias entre o produto que foi realmente produzido e o que o utilizador solicitou.

Em termos gerais, a aprovação na aceitação significa que o utilizador confirmou que o produto que corresponde ao que ele solicitou (ou ao propósito para o qual solicitou o desenvolvimento do sistema) foi realmente entregue.

Na prática, mesmo que se possa prever que defeitos no sistema possam ser descobertos posteriormente, muitos contratos estabelecem a aprovação na aceitação como condição para o pagamento da remuneração.

Atenção à cláusula de aceitação presumida

Quando ocorre um problema na fase de aceitação, tanto o utilizador como o fornecedor podem encontrar-se numa situação complicada.

Por exemplo, o que acontece se o fornecedor tiver produzido o produto final e já o tiver apresentado, mas o responsável do lado do utilizador, por razões pessoais, não proceder à aceitação?

Para lidar com tais situações, é comum incluir no contrato de desenvolvimento de sistemas uma cláusula conhecida como “cláusula de aceitação presumida”.

O que é a cláusula de aceitação presumida?

(Aceitação do software em questão) Artigo 28
Para o software em questão, entre os produtos entregues, o primeiro contratante deve inspecionar, dentro do período estipulado no contrato individual (doravante referido como “período de inspeção”), com base nas especificações de inspeção do artigo anterior, se o software em questão está em conformidade com as especificações do sistema.

2. Se o software em questão passar na inspeção do parágrafo anterior, o primeiro contratante deve assinar e carimbar o certificado de aprovação da inspeção e entregá-lo ao segundo contratante. Além disso, se o software em questão não passar na inspeção do parágrafo anterior, o primeiro contratante deve entregar rapidamente ao segundo contratante um documento escrito que explique claramente as razões específicas para a falha, e solicitar correções ou complementos. Quando as razões para a falha são reconhecidas, o segundo contratante deve corrigir gratuitamente e entregar ao primeiro contratante dentro do prazo acordado após a discussão, e o primeiro contratante deve realizar novamente a inspeção estipulada no parágrafo anterior, na medida necessária.

3. Mesmo se o certificado de aprovação da inspeção não for entregue, se o primeiro contratante não apresentar objeções por escrito com razões específicas durante o período de inspeção, o software em questão será considerado como tendo passado na inspeção estipulada neste artigo.

4. A aprovação da inspeção estipulada neste artigo será considerada como a conclusão da aceitação do software em questão.

https://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo.pdf

Além disso, do ponto de vista jurídico, o termo “considerado” no parágrafo 3 é um ponto a ser destacado. Quando visto como um termo jurídico, “considerar” e “presumir” têm significados completamente diferentes.

Considerar…
→ Mesmo que na realidade não seja ○○, é tratado como se fosse ○○ do ponto de vista jurídico.

(Exemplo) Se operar um smartphone durante um exame, é “considerado” como batota.
→ Independentemente de se a operação do smartphone era realmente batota ou não, são tomadas medidas como se fosse batota.

Presumir…
→ A menos que haja provas específicas para negar o fato de que é ○○, ○○ é tratado como um fato.

(Exemplo) Se olhar para um smartphone durante um exame, é “presumido” como batota.
→ É presumido que houve batota como regra, mas se puder provar que era para um propósito diferente de batota, esse julgamento pode ser revertido posteriormente. (No entanto, normalmente não se ouve tal anúncio num local de exame.)

Em outras palavras, o obstáculo para reverter “presumir” e “considerar” é muito diferente. O significado de “ser tratado da mesma forma que se tivesse passado na aceitação, independentemente do fato de ter passado na aceitação ou não” está incluído aqui.

Exemplos de casos judiciais relacionados à cláusula de aceitação presumida

Há exemplos no passado em que a cláusula de aceitação presumida teve um significado decisivo num julgamento. Por exemplo, a sentença citada abaixo é de um caso em que o utilizador não procedeu à aceitação dentro do período estipulado e posteriormente apresentou uma ação alegando que a função necessária não estava implementada. No entanto, o tribunal decidiu, com base na cláusula de aceitação presumida, que a entrega já tinha sido concluída.

No contrato em questão, a empresa Y foi obrigada a inspecionar o sistema em questão imediatamente após a entrega e a notificar por escrito a aceitação dentro de 10 dias, e se não houver notificação até a data acima, será considerado que a aceitação foi aprovada, e uma vez que não se pode reconhecer que houve notificação de partes não conformes na inspeção neste caso, pode-se reconhecer o fato de entrega e aceitação.

Julgamento do Tribunal Distrital de Tóquio, 29 de fevereiro de 2012 (Ano 24 da era Heisei)

Por outro lado, mesmo que esta cláusula de aceitação presumida esteja em vigor, existem casos judiciais que negaram a sua aplicação e reconheceram a violação do dever por parte do fornecedor.

O caso da sentença citada abaixo é diferente do exemplo de julgamento acima mencionado, na medida em que a cooperação do fornecedor era necessária para proceder à aceitação, mas o fornecedor não cooperou.

O demandante (fornecedor) alega que, de acordo com o parágrafo 4 do artigo 9 do contrato de desenvolvimento de software em questão, o demandado (utilizador) é considerado como tendo aceitado o produto final porque não notificou os resultados da inspeção dentro de 10 dias após a entrega do produto final. No entanto, para que tal resultado ocorra, a cooperação do demandante é essencial, e o demandante não cooperou com o demandado para tal inspeção, por isso, neste caso, mesmo que o demandado não tenha notificado os resultados da inspeção dentro de 10 dias após a entrega do produto final, não se pode considerar que o demandado aceitou o software em questão de acordo com o parágrafo 4 do artigo 9 do contrato de desenvolvimento de software em questão.

Julgamento do Tribunal Distrital de Tóquio, 23 de junho de 2004 (Ano 16 da era Heisei)

Acredita-se que o propósito do sistema da cláusula de aceitação presumida é libertar rapidamente o fornecedor de uma posição instável, como “apesar de querer avançar rapidamente para a aceitação, o trabalho está atrasado porque não pode avançar devido à conveniência unilateral do lado do utilizador”, e manter a relação entre as duas partes justa.

Portanto, não se pode dizer que “usando a cláusula de aceitação presumida como escudo, vamos de alguma forma ganhar tempo e adiar a aceitação em si, e empurrar qualquer produto defeituoso como está”.

Uma vez que é “considerado” que a aceitação foi aprovada, o utilizador deve pagar a remuneração pelo desenvolvimento do sistema. Levando em consideração esta seriedade, acredita-se que o tribunal visa fazer um julgamento justo, levando em consideração a situação de cooperação do lado do fornecedor.

Como suporte para tais decisões, as atas que acompanham o progresso do desenvolvimento do sistema podem ser evidências importantes em alguns casos. Para mais detalhes sobre isto, consulte o artigo abaixo.

Além disso, para saber quais são as obrigações abrangentes que o fornecedor, como especialista em desenvolvimento de sistemas, tem para com o projeto, consulte o artigo abaixo.

Embora a aceitação seja, em princípio, algo que o lado do utilizador deve fazer, o lado do fornecedor, como especialista em desenvolvimento de sistemas, deve cooperar de várias maneiras com a aceitação. Este ponto será naturalmente compreendido tendo em conta o conteúdo do artigo abaixo.

Padrões de defeitos encontrados na aceitação

No entanto, é possível que sejam descobertas falhas no sistema (na linguagem jurídica, muitas vezes usamos a palavra “defeito”) na fase de aceitação. Para questões legais neste caso, por favor, consulte o artigo abaixo.

https://monolith.law/corporate/defect-warranty-liability[ja]

Resumo

Na área de desenvolvimento de sistemas, a “aceitação” indica, em princípio, a conclusão do cumprimento das obrigações por parte do fornecedor, sendo, portanto, extremamente importante tanto para o utilizador como para o fornecedor. Para evitar problemas graves, tanto o cliente como o fornecedor devem ter um bom entendimento da “cláusula de aceitação presumida”.

Além disso, em caso de eventualidades como a aceitação não correr de forma suave, é importante que ambas as partes, desde a fase de contrato, alinhem cuidadosamente as suas expectativas, especialmente em relação às disposições relacionadas com a aceitação.