Acórdãos TCAN

Acórdão do Tribunal Central Administrativo Norte
Processo:02341/19.4BEBRG
Secção:1ª Secção - Contencioso Administrativo
Data do Acordão:11/21/2025
Tribunal:TAF de Braga
Relator:TIAGO MIRANDA
Descritores:TEMAS DA PROVA;
EXCEPÇÃO DE NÃO CUMPRIMENTO DO CONTRATO;
Sumário:
I - Os temas da prova são apenas um instrumento processual instrutório que permite mencionar mais ou menos genericamente a matéria de facto julgada relevante e controvertida e, a contrario sensu, a julgada já assente. Não se substituem aos factos individuais e concretos em que a pretensões das partes não podem deixar de assentar (da mihi facto dabo tibi jus) conforme artigo 5º do CPC. Assim, a indevida omissão de pronúncia sobre factos susceptíveis de relevarem para qualquer das soluções plausíveis da causa só ocorre relativamente a factos alegados e instrumentais ou complementares dos alegados, se reunidas as sobreditas condições para estes serem atendíveis, já não relativamente a “temas de prova”.

II – Uma vez que estava alegado na contestação e relevava para a invocação, pela Ré, da exceptio non adimpleti contractus, impunha-se que o Tribunal a quo seleccionasse como relevante e se pronunciasse sobre a prova do seguinte facto:
“O Sistema não executa:
1. “Solução Web descentralizada de avaliação, com suporte para o SIADAP, com autenticação integrada sobre uma Active Directory e com suporte para multientidade na mesma instância da aplicação: não existindo o suporte para SIADAP.”

III – Não o fazendo, a sentença padece da nulidade cominada no artigo 615º nº 1 alª b) do CPC, suprível mediante decisão deste tribunal de recurso, nos termos do artigo 149º nº 1 do CPTA.

IV - Provado que à data de 20/8/2019, isto é, após três anos de execução do contrato, o sistema fornecido e apoiado pela Autora ainda não executava uma “Solução Web descentralizada de avaliação, com suporte para o SIADAP, com autenticação integrada sobre uma Active Directory e com suporte para multientidade na mesma instância da aplicação” exigida pelas cláusulas 16ª do Caderno de encargos e 5º do contrato; que a Autora, ante comunicação desse defeito pela Ré, .confirmou que o sistema não executava a “solução”, mas, em vez de se dispor a suprir a falta, comunicou que tal não fazia parte da proposta pelo que teria de ser objecto de novo contrato, o que corresponde a uma recusa de executar a correspondente parte da prestação contratual; que a Ré advertiu a Autora da sua insatisfação e do que considerava serem os aspectos em falta ou em defeito, entre eles, expressamente, este do SIADAP, informando-a de que iria fixar um prazo para o um prazo para a supressão, sob pena de resolução do contrato; e que, quando a Ré se absteve de pagar as facturas enviadas pela Autora estavam decorridos três de cinco anos de vigência do contrato e pagos 45% do preço total, não ofende a proporcionalidade e o dever de boa fé contratual por parte da Ré, a invocação, por esta da exceptio non adimpleti contractus quanto à parte restante do preço.*
* Sumário elaborado pelo relator
(art. 663º, n.º 7 do Cód. Proc. Civil)
Votação:Maioria
Decisão:Conceder provimento ao recurso.
Aditamento:
Parecer Ministério Publico:
1
Decisão Texto Integral:Acordam em conferência os Juízes Desembargadores que compõem a Secção de Contencioso Administrativo do Tribunal Central Administrativo Norte:


I - Relatório

[SCom01...].. Ré nos autos em epígrafe, em que é Autora [SCom02...] UNIPESSOAL, LDA, com sede em ..., interpôs o presente Recurso de Apelação da sentença do TAF do Porto, de 07/03/2022, que, julgando a acção procedente, a condenou a “a proceder ao pagamento do valor constante das facturas apresentadas, € 114.021,00, de capital em dívida, acrescida de juros, à taxa legal prevista para as dívidas comerciais, desde a data de vencimento de cada uma das facturas e até ao efectivo e integral pagamento.”.

As conclusões da alegação da Recorrente têm o seguinte teor:
«CONCLUSÕES
1° Em sede de despacho saneador foram fixados dezassete temas de prova, mas a sentença recorrida não se pronunciou sobre muitos destes temas (apesar de mesmo os temas não provados terem relevância em termos do que cada parte alegou em favor da sua respectiva tese).
2° O artigo 90° n° 3 do CPTA é inequívoco quando obriga a sentença a discriminar entre factos provados e factos não provados, o que não foi efectuado e é comprovado na pág. 32 da sentença recorrida onde se escreveu que "...a restante matéria alegada pelas partes não foi julgada indiciariamente provada ou não provada, por constituir conceito de direito, matéria conclusiva ou não relevar para a decisão da causa."
3° No entendimento da Recorrente não foi efectuada prova sobre os seguintes temas:
- 1: nada foi apurado a este propósito, tratando-se de factualidade alegada pela Recorrida;
- 2 a), b) e e): nada foi apurado a este propósito, tratando-se de factualidade alegada pela Recorrida;
- 3 c) e e): nada foi apurado a este propósito, tratando-se de factualidade alegada pela Recorrida;
- 4: nada foi apurado a este propósito, tratando-se de factualidade alegada pela Recorrida;
- 5: nada foi apurado a este propósito, tratando-se de factualidade alegada pela Recorrida;
- 6: nada foi apurado a este propósito, tratando-se de factualidade alegada pela Recorrida;
- 8 b): nada foi apurado a este propósito, tratando-se de factualidade alegada pela Recorrida.
4° Ao não fazer a discriminação dos temas não provados a sentença recorrida violou o artigo 90°/n° 3 do CPTA.
5° Na fundamentação da decisão de facto a sentença recorrida reportou-se a factualidade que não consta do elenco dos factos provados e não considerou provada outra factualidade a que as testemunhas se referiram e que nalguns casos constam ainda de documentos.
6° No facto provado 31 a sentença recorrida não indicou o momento a partir do qual se iniciaram os pedidos de assistência, sendo esta informação tão relevante que a sentença recorrida, na pag. 41, refere que só decorridos 3 anos da data de início do contrato (isto é, só em 2019) é que a Recorrente invocou a existência de defeitos.
7° Na sua réplica a Recorrida juntou documentos que comprovam que a Recorrente começou a invocar defeitos em Agosto de 2017 (o primeiro pedido de assistência em hepldesk surgiu em 11.08.2017) e continuou pelos anos de 2018 e 2019, motivo pelo qual não é acertada a afirmação da pag. 41 da sentença recorrida.
8° Quanto ao número de pedidos de assistência, o facto provado 31 aludiu a mais de uma centena, sendo certo que a testemunha «AA» apontou 137 pedidos (pag. 33 da sentença) e a testemunha «BB» apontou 143 pedidos, razão pela qual deve o facto em apreço ser reformulado e completado nos seguintes termos: “No decurso da relação contratual, concretamente a partir de 11 de Agosto de 2017, a Ré apresentou mais de cento e trinta pedidos de assistência em helpdesk.", o que se requer.
9° Quanto ao facto provado 33 a sentença recorrida fez uma selecção de pedidos que julgou mais relevantes para a causa sem indicar qual o critério da sua decisão e a ausência desta informação configura insuficiência de fundamentação, pois é imprescindível conhecer qual o critério utilizado, especialmente por estar em causa a matéria dos pedidos de assistência e o exercício do direito da Recorrente na invocação de defeitos.
10° A sentença recorrida é nula quanto ao facto provado 33, nos termos do artigo 615°/n° 1 b) do CPC, por ausência de especificação sobre os fundamentos de facto.
11° Os depoimentos das testemunhas «CC» (cf. as passagens 12m09s, 13m40s, 20m01s, 20m50s, 26m15s, 29m30s, 41m43s e 01h09m03s do depoimento prestado no dia 23.11.2021, na sessão da tarde, com início ao minuto 3 e término à 1h14m20s), «DD» (cf. as passagens 01h19m26s, 01h19m43s, 01h22m20s, 01h25m10s, 01h28m20s e 01h30m03s do depoimento prestado no dia 23.11.2021, na sessão da tarde, com início à 1h15m02s e término à 1h55m45s) e «AA» (cf. as passagens 02h00m15s, 02h01m36s, 02h02m40s, 02h03m50s, 02h04m40s e 02h10m11s do depoimento prestado no dia 23.11.2021, na sessão da tarde, com início à 1h56m20s e término à 2h37m16s) são prova bastante para demonstrar os pedidos de assistência em helpdesk com relevância para a causa, as funcionalidades que não operavam, a perda de dados e o incumprimento de especificações constantes do caderno de encargos na medida em que identificam diversas situações concretas e são bastante precisos (com exemplos, identificando um conjunto de anomalias e defeitos que, diariamente, se verificavam a quem manuseava o programa).
12° Na pág. 35 da sentença recorrida foi escrito que a alegação de “perda de dados" é conclusiva, não podendo a Recorrente concordar com esta asserção porque se da utilização de um software resulta a perda de dados antes introduzidos tal significa que o programa não reteve a informação que fora introduzida por um utilizador e isto é um facto (bem grave).
13° Os primeiros defeitos são reportados em Agosto de 2017 e o contrato foi outorgado em 15 de Novembro de 2016, pelo que errou a sentença recorrida quando na pág. 41 afirma que os defeitos só foram invocados três anos após a outorga do contrato.
14° Um ponto decisivo para a decisão sobre a matéria de facto vem identificado na pág. 34 da sentença como sendo a falta de credibilidade das testemunhas «CC», «DD» e «AA» por terem revelado desconhecimento do período que antecedeu a contratação do software pela Recorrente; no entanto, é impossível as testemunhas «DD» e «AA» terem conhecimento do que se passou em 2016 porque só foram admitidas a trabalhar na [SCom01...] em 2019.
15° Como decorre dos factos provados 1 a 4, a comunicação da Recorrida com a Recorrente foi apenas com o seu então Director-Geral e tais comunicações mais não são do que uma apresentação comercial do programa, mas o que releva para estes autos é o contrato firmado entre as partes, as obrigações ali previstas e a sua execução (até porque o Director-Geral nem capacidade tinha para vincular a empresa).
16° A tese da Recorrida assenta na circunstância de que com a saída do Director-Geral da Recorrente é que os problemas quanto ao funcionamento do programa surgiram, mas esta tese não se provou porque quando o Director-Geral saiu da empresa a parametrização ainda não estava concluída (cf. minuto 12 e 09s do depoimento da testemunha «CC») e, tal como consta dos emails juntos com a réplica, em Maio de 2017 ainda andava a Recorrida a marcar com o Director-Geral a data para ministrar a formação (a qual só ocorreu só ocorreu em Dezembro de 2018 como decorre do facto provado 16).
17° Tendo por suporte as passagens transcritas dos depoimentos das testemunhas «CC», «DD» e «AA», conjugadas com os documentos da oposição, requer-se, ao abrigo do disposto no artigo 149° do CPTA e no artigo 640°/n° 1 e 2 do CPC, o aditamento à matéria de facto provada da seguinte factualidade:
- Facto 39: O software não produz relatórios para a ERSAR.
- Facto 40: O módulo SIADAP não funciona.
- Facto 41: Entre 2017 e 2019, em inúmeras ocasiões de aplicação e funcionamento de fórmulas matemáticas, o software gerou resultados errados - por exemplo, ticket 907, ticket 1040, ticket 1045, ticket 1052, constantes do doc. n° 4 junto com a oposição.
- Facto 42: O software não permite o interface com outras aplicações, nomeadamente webservices e API's.
- Facto 43: Entre 2017 e 2019, em inúmeras ocasiões os utilizadores introduziram dados no software e no dia seguinte, fosse por consequência de actualizações, fosse por outras causas, os mesmos perderam-se - por exemplo, ticket 1050, ticket 1084, constantes do doc. n° 4 junto com a oposição.
18° Face à factualidade cujo aditamento se requereu a actuação da Recorrente no que concerne à invocação da excepção de não cumprimento do contrato está legitimada, pois a Recorrida não cumpriu pontualmente com as obrigações decorrentes do contrato firmado com a Recorrente, por aplicação do disposto na sua cláusula 5a/n° 1 e cláusulas 1a e 16a do caderno de encargos (por remissão) e não cumpriu de forma constante, ao longo de 3 anos, com o contratualmente acordado (não tendo o software funcionado com todas as funcionalidades previstas em sede de contrato e caderno de encargos).
19° Sem prescindir, e na eventualidade de não ser atendida a alteração à matéria de facto ainda assim considera a Recorrente que deveria ter sido julgada válida a excepção de não cumprimento por si invocada.
20° O preço do contrato era de € 161.916,00 (sem IVA), a ser pago em 5 prestações anuais (cláusulas 2a e 3a do contrato) e a Recorrente liquidou duas das cinco prestações, isto é, pagou € 69.216,00 (o correspondente a 45% do preço), conforme decorre dos factos provados 10, 12, 18, 36 e 37.
21° Ao longo de três anos a Recorrente submeteu mais de cem pedidos de assistência em helpdesk (cf. factos provados 31 a 33) e o software não produz relatórios dinâmicos (cf. facto provado 34), funcionalidade prevista em caderno de encargos, o que bem demonstra que algo sério e consistente se passava com o funcionamento do software, tendo feito com que a Recorrente efectuasse, em Agosto de 2019, uma interpelação à Recorrida a fixar um prazo para a eliminação dos defeitos.
22° A aplicação do Direito aos factos provados por parte da sentença recorrida não se mostra a mais adequada, pois perante a factualidade provada conclui-se que a Recorrente só tinha o instrumento da excepção de não cumprimento para forçar a Recorrida a respeitar o contrato (a única outra opção ao seu dispor seria a resolução do contrato, a qual é bem mais gravosa para as partes).
23° A excepção de não cumprimento perspectiva-se como equilibrada para uma parte que já pagou 45% do preço contratual, que se depara com um software complicado e que em vez de a auxiliar na sua actividade só lhe traz problemas e dificuldades diárias no funcionamento.
24° Ao longo de três anos, mais precisamente até ao momento em que a Recorrida intenta a injunção (Outubro de 2019), a Recorrente procurou que o software funcionasse, recebendo formação e apresentando mais de uma centena de pedidos de assistência.
25° Em Outubro de 2019 a Recorrente só estava em atraso com uma prestação (e não com três) e foi na pendência do processo (atrasado na sua tramitação pela pandemia Covid) que se venceram mais duas prestações, motivo pelo qual a legitimidade do uso da excepção de não cumprimento não pode deixar de ser analisada e ponderada no momento da sua invocação.
26° A Recorrente estava em dívida com uma prestação e nunca disse que não pagaria, o que clama (até porque já havia liquidado quase 70 mil euros) é que se lhe reconheça o direito a pagar por um serviço/produto apto para o fim contratado, razão pela qual se afigura proporcional, equilibrada, razoável e lícita a invocação da excepção de não cumprimento do contrato.
27° Ao decidir em sentido inverso a sentença recorrida incorreu em erro de julgamento de Direito, concretamente do artigo 428°/n° 1 do Código Civil.
TERMOS EM QUE deve o presente recurso ser julgado procedente, revogando-se a douta sentença recorrida e substituindo-a por outra que julgue válida a excepção de não cumprimento invocada pela Recorrente, assim se fazendo JUSTIÇA.»

A Autora, Recorrida, apresentou resposta à alegação do Recorrente que rematou com as seguintes conclusões.
«A título prévio: a reprodução dos depoimentos e documentos, pela sua clareza e limpidez visou facultar a este Tribunal, de modo leal, os termos da prova, sem selecções atomísticas e cirúrgicas, procurando facilitar a tarefa do julgador, ainda que aumentando a extensão da peça. Optou-se por sacrificar o tamanho, em favor da seriedade.
1. A Recorrente celebrou um contrato com a Recorrida nos termos do qual adquiriu um conjunto de máquinas informáticas e recebeu apoio técnico na sua utilização.
2. Para tal deveria pagar um preço, que aceitou, em 5 prestações anuais.
3. A Recorrente apenas pagou 2 prestações.
4. A implementação do software pressuponha que a Recorrente parametrizasse o mesmo, definindo um conjunto de variáveis, conferisse permissões aos seus colaboradores, exigisse dos mesmos a utilização do software, ministrasse a formação suficiente junto dos mesmos.
5. A Recorrente apenas o fez de forma parcial.
6. A sociedade Recorrente, 6 meses antes de celebrar o contrato em causa, analisou, experimentou, solicitou ajustamentos, utilizou as referidas "máquinas”, fazendo a denominada prova de conceito.
7. No final desse processo de avaliação e verificação, entendeu que o produto ia ao encontro do que pretendia e celebrou o contrato.
8. Ou seja, antes de celebrar o contrato, teve oportunidade de verificar como funcionava, de utilizar, de determinar aperfeiçoamentos e adaptações consoante a sua vontade, os objectivos que definiu.
9. Só após esses 6 meses de experimentação e utilização tomou a decisão de contratar, mais concretamente em 15 Novembro de 2016.
10. Em 2019, em data concretamente desconhecida, mas acreditando ter sido no início do ano, a Recorrente decidiu utilizar outro sistema informático.
11. Razão pela qual optou por não pagar à Recorrida.
12. A Recorrida insistia no pagamento.
13. Em meados do ano de 2019 (Julho e Agosto), como meio de justificar o seu comportamento incumpridor, a Recorrente iniciou uma encenação de alegados defeitos do programa, volvidos que estavam 3 anos de utilização do software (recorde-se que é o mesmo programa que teve oportunidade escalpelizar, analisar e utilizar 6 meses antes de o adquirir).
14. Entre 2016 e 2021 a Recorrente sempre utilizou o software, inclusive durante o julgamento do processo.
15. Não existe erro de julgamento.
16. Não se pode confundir pedidos de apoio à implementação do software, com defeitos do programa.
17. Logo, é censurável, e intelectualmente desonesto afirmar ou indiciar que pedidos de apoio são defeitos.
18. Inexistem as nulidades invocadas pela Recorrente.
19. Contrariamente ao alegado pela Recorrente foi feita prova sobre os temas da prova 1, 2 a), b), e), 3 c) e e), 4, 5, 6, 8 b).
20. Os pedidos de assistência não são defeitos do programa, mas resultam de actos imputáveis à recorrente:
a. Por não ter dado a devida formação aos seus funcionários;
b. Por não ter querido contratar formação;
c. Por não ter conferido as permissões informáticas;
d. Por colocar fórmulas erradas;
e. Por não assegurar que guardava os dados;
f. Por não saber visionar os dados que constavam da plataforma;
g. Por não fazer opções decisivas na implementação do programa;
h. Por manter duas gerações de indicadores, sujeitam os seus funcionários a uma duplicação de inserção de dados, e de erros;
21. O alarde de pedidos de apoio não pode ser confundido com defeitos.
22. O facto 33 está por natureza, ou seja, pela documentação ali reproduzida, justificado e demonstrado.
23. O teor dos factos acima expostos estão especialmente demonstrados pelas comunicações escritas e pelo depoimento da testemunha «AA» (Minuto 01:22:00).
24. Os factos pretendidos pela Recorrente como tendo ficado provados são falsos, não ficaram demonstrados, pelo contrário, foi o oposto.
25. À Recorrente não assistia a legitimidade de invocar a excepção de não cumprimento prevista no art° 428° do CC., porquanto esta encontrava-se em incumprimento, numa dupla vertente, porque não implementou o programa na sua plenitude, porque não criou as condições técnicas e humanas para retirar do mesmo a maior quantidade de resultados, mas também porque deixou de pagar as prestações a que estava obrigada, apesar de continuar a utilizar o programa.
26. Acresce que o contrato em apreço não era um contrato de empreitada, mas sim de aquisição de um programa de software.
27. O programa era apto ao fim contratado, mas não trabalha sozinho, por si, necessita de ser carregado com a informação, com as fórmulas, com os parâmetros e objectivos que a Recorrente pretendia.
28. Inexiste qualquer erro de julgamento.
29. A título subsidiário, e caso este Tribunal equacione alterar a decisão quanto aos factos e/ou quanto ao direito, então desde já requer-se que se aditem os factos que abaixo se indicarão e que, salvo melhor entendimento também deveriam ser considerados como provados:
Facto 39
Desde 15.06.2015 que a [SCom01...]/Recorrente vinha analisando os programas informáticos (mais tarde adquiridos), transmitindo as suas necessidades, experimentando o programa, desenhando a configuração do mesmo, conforme atestam as comunicações juntas, as reuniões havidas, as acções de formação prévia, as opções e orientações dadas pela [SCom01...]/Recorrente.
Facto 40
A [SCom01...] não tomou decisões e opções fundamentais à implementação do projecto.
Facto 41
Em Dezembro de 2018, a [SCom01...] ainda estava a dar formação aos seus colaboradores.
Facto 42
Em Dezembro de 2018, a [SCom01...] ainda estava a planear a implementação do software.
Facto 43
Em Dezembro de 2018, a [SCom01...] nomeou um líder de projecto, Eng. «EE».
Facto 44
Em Julho de 2019, quando a [SCom01...] convoca uma reunião, nesse momento estava uma factura por pagar.
Facto 45
O programa SIADP estava disponível para a Recorrente, fazendo do programa adquirido.
Facto 46
A [SCom01...] nunca solicitou a implementação do SIADAP.
Facto 47
Em Maio de 2019 a [SCom01...] reconhecia que ainda não tinha conseguido implementar o sofware.
Facto 48
Em 10.07.2019 a [SCom01...] convoca uma reunião para alinhamento do sistema com o CE, proposta e contrato; desenvolvimento e actualizações do sistema.
Facto 49
Em Agosto de 2019, durante uma reunião, a Directora Geral «CC» invoca que se tinham perdido dados e o colaborador da Recorrida, abrindo o computador, demonstrou que os dados estavam na plataforma, não se tinham perdidos, e que apenas estavam consultáveis noutra permissão.
Facto 50
A Directora Geral «CC» não sabia aceder a determinadas áreas da plataforma.
Facto 51
Quem definia as fórmulas de cálculo era a [SCom01...].
Facto 52
A [SCom01...] definiu erradamente fórmulas que geraram erros de cálculo.
Facto 53
A [SCom01...] solicitou e obteve novas funcionalidades da Recorrida, sem qualquer tipo de acréscimo ou custo para a Recorrente.
Facto 54
A [SCom02...] ao longo do contrato teve que assegurar encargos com servidores e plataformas da Microsoft.
Facto 55
O programa de software objecto do contrato sempre permitiu elaborar e apresentar os ficheiros de indicadores exigidos pelo regulador ERSAR. 
Nestes termos, e com o mui suprimento deste Tribunal, resta à ora Recorrida pugnar pela manutenção da decisão de reconhecer o direito ao pagamento do preço e de juros de mora, mantendo-se a decisão ora em apreciação nesta parte, mas alterando-se na parte dos factos provados, acrescentando-se os acima elencados. 

A Recorrente [SCom01...] veio ainda juntar um articulado que designou como contra-alegações ao recurso subordinado interposto pela Autora e Recorrente [SCom02...] UNIPESSOAL, LDA.

O Digno Magistrado do Ministério Público neste Tribunal foi notificado apara os efeitos do artigo do artigo 146º CPTA.

Dispensados os vistos, nos termos do artigo 657º nº 4 do CPC, cumpre apreciar e decidir.

II - Âmbito do recurso e questões a decidir
1 – Do suposto recurso subordinado da Recorrida [SCom02...] UNIPESSOAL, LDA
Nas suas contra-alegações, inclusive, mas respectivas conclusões, a Autora requereu “29. A título subsidiário, e caso este Tribunal equacione alterar a decisão quanto aos factos e/ou quanto ao direito, então (…) que se aditem os factos que abaixo se indicarão e que, salvo melhor entendimento também deveriam ser considerados como provados:”, seguindo-se a exposição de catorze proposições, alegadamente de matéria de facto.
Por sua vez, como se relatou, a Recorrente apresentou contra-alegações relativas ao “recurso subordinado interposto pela Autora e Recorrente [SCom02...] UNIPESSOAL, LDA”.
O despacho da Mª Juiz a qua apenas se refere ao recurso da Ré, que admite.
Sucede que, antes de mais, em momento algum da contra-alegação se menciona recorrer-se da sentença. Acresce que o recurso subordinado apenas é admissível relativamente a sentença em que ambos as partes decaíram, (artigo 633º do CPC). Não é isso que in casu ocorre, pois, na sentença recorrida, a acção procede totalmente.
Deste modo, a contra-alegação da Autora não pode ser assimilada ao conceito de recuso subordinado.
Poderá assimilar-se, a contra-alegação, ao conceito de ampliação do recurso, previsto no artigo 636º do CPC?
Prima facie, dir-se-ia que não, pois não resulta da sentença que algum fundamento do pedido tenha claudicado (nº 1) e não é arguida, pelo menos de modo expresso, a nulidade da sentença, nem é impugnado o decidido “sobre pontos determinados da matéria de facto não impugnados pelo recorrente” (nº 2).
Porém, se a falta de especificação de determinados factos, tidos por atendíveis e provados, é causa de nulidade da sentença por falta de especificação de fundamentos de facto, nos termos da alª b) do artigo 615º nº 1 b) do CPVC, como infra teremos ocasião de explicitar, então, o fundamento da pretensão subsidiariamente formulada pela Recorrida na sua contra-alegação constitui uma alegação da correspondente nulidade da sentença, pelo que integra o pressuposto de ampliação do recurso previsto nº nº 1 do artigo 636ª.
O direito da Recorrente a responder à ampliação, previsto no artito 638º 8 do CPC, está assegurada pelas suas “contra-alegações” ao “recurso subordinado”.
Como assim, nada obstando, convolamos a 29º conclusão da contra-alegação do da Recorrida em pedido de ampliação do recurso nos termos do nº 1 do artigo 636º do CPC, que oportunamente apreciaremos.
*
Na conclusão nº 5 do recurso, a Recorrente alega que, na fundamentação da decisão de facto, a sentença se reporta a factualidade que não consta do elenco dos factos provados, sem especificar que factos integram essa “factualidade” que não consta dos factos provados.
A recorrente alega este suposto vício da sentença, mas não lhe comina qualquer sanção jurídica nem conclui por qualquer erro no julgamento a isso devido.
Em abstracto, a alusão, na fundamentação de facto, designadamente na discussão da prova verbal, a factos não seleccionados como provados não constitui só por si factor de nulidade da sentença (cf. o artigo 615º do CPC).
Trata-se assim de uma critica juridicamente inconsequente, inútil, à sentença recorrida, pelo que não tem que nem deve ser apreciada no recurso.
A sue tempo trataremos de distopia quejanda, mas na fundamentação direito.

Conforme jurisprudência pacífica, o âmbito do recurso é delimitado pelo objecto das conclusões das alegações.
Assim:
As questões colocadas a este Tribunal são, por ordem lógica, as seguintes:
1ª Questão
A sentença recorrida é nula quanto ao facto provado 33, nos termos do artigo 615º/nº 1 b) do CPC, por ausência de especificação sobre os fundamentos da selecção que aí é feita de pedidos de assistência ao serviço de helpdesk da Recorrida?
2ª Questão
A sentença recorrida violou o artigo 94º nº 3 do CPTA, pois, quanto a matéria de facto não provada, apenas mencionou que “a restante matéria alegada pelas partes não foi julgada indiciariamente provada ou não provada, por constituir conceito de direito, matéria conclusiva ou não relevar para a decisão da causa”, com o que deixou de se pronunciar – no sentido de não ter sido produzida qualquer prova, pois nada foi apurado a este propósito – quanto aos temas de prova 1; 2 a), b), e); 3 c), e); 4; 5; 6; 8 b), todos relativos a factualidade alegada pela Recorrida?
3ª Questão
A sentença recorrida erra no julgamento em matéria de facto, quanto ao facto provado 31, porquanto, na redacção, não deu como provado que a recorrente começou a invocar defeitos logo em 11/8/2017, data do primeiro pedido de assistência em Helpdesk “e continuou pelos anos de 2018 e 2019”, conforme documentos juntos com a Réplica, e os pedidos de assistência foram mais de cento e trinta, conforme resulta da conjugação do próprios depoimento da testemunha «AA», invocado na sentença o qual apontou 137 pedidos, e «BB», que apontou 143,tudo por que este ponto da matéria de facto provado deve ser reformulado, nos seguintes termos:
No decurso da relação contratual, concretamente a partir de 11 de Agosto de 2017, a Ré apresentou mais de cento e trinta pedidos de assistência em helpdesk.”?
4ª questão
Considerando que, ao contrário do afirmado na sentença recorrida, a alegação de “perda de dados”, é uma alegação de facto, e atentas passagens dos depoimentos das testemunhas «CC», «DD» e «AA», conjugadas com os documentos da oposição, conjugadas com os documentos juntos com a oposição ao requerimento de injunção, cumpria especificar e julgar como provados – e há agora que aditar à matéria de facto provada, nos termos do artigo 149º do CPA e do artigo 640º nºs 1 e 2 do CPC, os seguintes factos:
- Facto 39: O software não produz relatórios para a ERSAR.
- Facto 40: O módulo SIADAP não funciona.
- Facto 41: Entre 2017 e 2019, em inúmeras ocasiões de aplicação e funcionamento de fórmulas matemáticas, o software gerou resultados errados - por exemplo, ticket 907, ticket 1040, ticket 1045, ticket 1052, constantes do doc. n° 4 junto com a oposição.
- Facto 42: O software não permite o interface com outras aplicações, nomeadamente webservices e API's.
- Facto 43: Entre 2017 e 2019, em inúmeras ocasiões os utilizadores introduziram dados no software e no dia seguinte, fosse por consequência de actualizações, fosse por outras causas, os mesmos perderam-se - por exemplo, ticket 1050, ticket 1084, constantes do doc. n° 4 junto com a oposição.

5ª Questão (objecto da ampliação do recurso)
Cumpria especificar e julgar como provados, na sentença recorrida – e há agora que aditar à matéria de facto provada, como provados, os “factos” descritos sob os nºs 39 a 56 na conclusão 29 das contra alegações da Recorrida?

6ª Questão
Em face da matéria de facto resultante das respostas às questões antecedentes, e mesmo tão só em face dos factos dados como provados na sentença recorrida, impõe-se concluir que a mesma incorre em erro no julgamento de direito, pois estavam reunidos os pressupostos da invocação, pela Recorrente da excepção de não cumprimento do contrato, consagrada no artigo 428º nº 1 do CCivil?


III – Apreciação do Recurso
A decisão da 1ª instância em matéria de facto foi a seguinte:
«1. Em 08 de Abril de 2016, .a.........@...... remeteu email para «FF», com o conhecimento de «BB», com o assunto: “Dados para configuração da [SCom01...] no Aqua Peformance”, e com o seguinte teor:
Boa tarde,
No seguimento, e com o intuito de criar o ambiente para o vosso acesso ao AquaPeformance precisava que me enviassem a seguinte informação:
• Sigla, ou prefixo pretendido para os logins
o É obrigatório, para a definição dos logins dos utilizadores no organismo;
o Não podem ser escolhidas as seguintes siglas já existentes: adc, simas, smas;
o Ex: Com um prefixo “adc”, e um nome de utilizador “pperdigao”, o username ficará “adc.pperdigao
• Tipologia da área de intervenção da [SCom01...] (Área Predominantemente Urbana, Área Mediamente Urbana ou Área Predominantemente Rural);
• UserName e e-mail pretendido para o 1o utilizador a ser criado na aplicação
o Este utilizador terá o privilégio de administração/gestão de utilizadores e permissões;
o Este utilizador poderá criar depois os restantes utilizadores da [SCom01...]; o Contacto técnico da [SCom01...] (mail e/ou telefone);
(...),” — cf. documento junto a fls. 223 do SITAF;

2. Em 12 de Abril de 2016, .b.........@...... respondeu ao e-mail referido no ponto antecedente com a indicação da seguinte resposta:
“(…)
Vejam pf se concordam.
• Sigla, ou prefixo pretendido para os logins: agr
• Tipologia da área de intervenção da [SCom01...] (Área Urbana, Área Mediamente Urbana ou Área Predominantemente Rural): Área Predominantemente Urbana
• UserName e e-mail pretendido para o 1º utilizador a ser criado na aplicação: 643; .c.........@.....
• Contacto técnico da [SCom01...] (mail e/ou telefone): .c.........@..... (...)” - cf. documento de fls. 223 do SITAF;

3. Em 12 de Abril de 2016, .a.........@...... remeteu e-mail para «FF», com o assunto “AquaPerformance — Sessão dos dias 14 e 15 de Abril", do qual se extracta o seguinte:
Bom dia Eng.° «FF»,
No seguimento da reunião do passado dia 7, e não tendo ficado definida hora de início para a sessão prevista para os próximos dias 14 e 15, vinha por este meio sugerir que iniciemos a sessão às 9h30. Agradeço confirmação da mesma, ou sugestão de outra hora de início, que melhor se adeqúe aos vossos horários.
Caso pretendam fazer testes já num ambiente final, necessito que me enviem os dados que solicitei em e-mail no passado dia 8, até ao final do dia de hoje, para que possamos proceder à configuração do ambiente” — cf. documento de fls. 226 do SITAF;

4. Em 26 de Abril de 2016, .d.........@..... remeteu e-mail para .b.........@...... com o assunto “[SCom01...] — Revisão dos serviços adicionais”, e com o seguinte teor:
“(…)
Em anexo vai o planeamento de implementação actualizado, com os serviços adicionais previstos para a [SCom01...], revisto com as novas funcionalidades referidas na sessão de trabalho dos passados dias 14 e 15 de Abril.
O número de dias de trabalho passou de 50,25 homens/dia para 64,5 homens/dia. Os conteúdos definidos poderão ser revistos de forma coerente, aplicando-se a valorização total dos componentes seleccionados.
O custo dos serviços constantes do anexo é de 30.960,00 €.
As deslocações e estadias são facturadas à parte e acordadas previamente com a [SCom01...].
Sugerimos um pacote adicional de 80 horas (4.800,00 €). Em caso da adjudicação dos serviços e do pacote de horas, oferecemos um pacote adicional de 40 horas.
Aguardo o seu feed-back e sobre a forma de formalização deste projecto” — cf. documento de fls. 229 do SITAF;

5. Em 19 de Agosto de 2016, a Ré convidou a Autora a apresentar proposta contratual. nos seguintes termos:
CONVITE PARA APRESENTAÇÃO DE PROPOSTA
1. Objecto
Nos termos do artigo 259º do código dos Contratos Públicos, a [SCom01...], convidam V. Exa., a apresentar proposta para a aquisição de 2 máquinas do Software STRATUS — Lote 68 — Pacotes de Software — Balanced Scorecard, Portfólio de Indicadores Operacionais baseados no IWA, Portfólio de Indicadores ERSAR, Stratus — Plano de Actividades, que inclui serviços de manutenção de 36 meses que se encontra integrado no “AQ de licenciamento de software e serviços conexos”, com um prazo de execução de 10 dias;’ — cf., documento n.° 1 junto com a Oposição da Ré;
6. Do Caderno de Encargos junto ao convite remetido à Autora, e referido no ponto anterior, consta designadamente o seguinte:
Cláusula 1ª
Objecto
O presente Caderno de Encargos compreende as cláusulas a incluir no contrato a celebrar na sequência de procedimento que tem por objecto principal a aquisição de 2 máquinas do Software STRATUS — Lote 68 — Pacotes de Software — Balanced Scorecard, Portfólio de Indicadores Operacionais baseados no IWA, Portfólio de Indicadores ERSAR, Stratus — Plano de Actividades, que inclui serviços de manutenção de 36 meses, que se encontra integrado no “AQ de licenciamento de software e serviços conexos”, com todas as funcionalidades descritos no Capítulo VI do Caderno de Encargos.
Cláusula 2ª
Contrato
1 — O contrato é composto pelo respectivo clausulado contratual e os seus anexos.
2 — O contrato a celebrar integra ainda os seguintes elementos:
a) Os suprimentos dos erros e das omissões do Caderno de Encargos identificados pelos concorrentes, desde que esses erros e omissões tenham sido expressamente aceite pelo órgão competente para a decisão de contratar;
b) Os esclarecimentos e as rectificações relativos ao Caderno de Encargos;
c) O presente Caderno de Encargos;
d) A proposta adjudicada;
e) Os esclarecimentos sobre a proposta adjudicada prestados pelo adjudicatário.
3 — Em caso de divergência entre os documentos referidos no número anterior, a respectiva prevalência é determinada pela ordem pela qual são aí indicados.
4 — Em caso de divergência entre os documentos referidos no n.°2 e o clausulado do contrato e seus anexos, prevalecem os primeiros, salvo quanto aos ajustamentos propostos de acordo com o disposto no artigo 99.° do Código dos Contratos Públicos e aceitos pelo adjudicatário nos termos do disposto no artigo 101.° desse mesmo diploma legal.
(...)
Cláusula 3.º
Prazo de execução do contrato
1 — O prazo de execução do contrato objecto do persente procedimento é de 10 (dez) dias a contar da sua assinatura.
2 — O contrato mantém-se em vigor até à conclusão da prestação de serviços contratada, em conformidade com os respectivos termos e condições e o disposto na lei.
(...)
Cláusula 4.ª
Obrigações do adjudicatário
1 — Sem prejuízo de outras obrigações previstas na legislação aplicável, no Caderno de Encargos ou nas clausulas contratuais decorrem para o adjudicatário as seguintes obrigações principais: fornecimento, instalação e entrada em funcionamento de Sistema Integrado de Gestão de Performance, com Balanced Scorecard, Portfólio de Indicadores Operacionais baseados no IWA, Portfólio de Indicadores ERSAR e Plano de Actividades.
2 — Durante o período de 36 meses mais 24 meses de oferta, conforme proposta do segundo Outorgante, perfazendo assim um total de 60 meses, o adjudicatário deve assegurar a manutenção evolutiva da ferramenta, bem como a assistência em help-desk.
3 — A título acessório, o prestador de serviços fica ainda obrigado, designadamente, a recorrer a todos os meios necessários e adequados à prestação do serviço, bem como ao estabelecimento do sistema de organização necessário à perfeita e completa execução das tarefas a seu cargo.
(...)
Cláusula 7. °
Preço contratual
1 — Pela prestação de serviços objecto do presente contrato, bem como pelo cumprimento das demais obrigações constantes do presente Caderno de Encargos, a [SCom01...] deverá pagar ao adjudicatário o preço constante da proposta adjudicada acrescida de IVA à taxa legal em vigor.
2 — O preço referido no número anterior inclui todos os custos, encargos e despesas cuja responsabilidade não esteja expressamente atribuída ao contraente público, nomeadamente quaisquer encargos decorrentes da utilização de marcas registadas, patentes ou licenças.
(...)
Cláusula 8.ª
Condições de pagamento
1 — A quantia devida pela [SCom01...] nos termos da cláusula anterior, deve ser paga em 5 prestações anuais, no prazo máximo de 30 dias após a recepção pela [SCom01...] das respectivas facturas, que serão emitidas no início de cada ano contado após assinatura do contrato.
2 - A [SCom01...] reserva-se o direito de efectuar o pagamento total em qualquer momento.
3 — Em caso de discordância por parte da [SCom01...] quanto ao valor indicado na factura, deve esta comunicar ao adjudicatário, por escrito, os respectivos fundamentos, ficando o adjudicatário obrigado a prestar os esclarecimentos necessários ou proceder à emissão de nova factura corrigida.
4 — Desde que devidamente emitidas e observado o disposto no n° 1, as facturas são pagas através de transferência bancária.
(...)
Cláusula 9.ª
Penalidades contratuais
1 — Pelo incumprimento de obrigações emergentes do contrato, a [SCom01...], pode exigir do adjudicatário o pagamento de uma sanção pecuniária, de montante afixar em função da gravidade do incumprimento, nos seguintes termos:
- pelo incumprimento das datas e prazos de entrega dos elementos a produzir referentes ao contrato, em função do prazo indicado, até 10% do valor global do contrato.
(...)
Cláusula 16.a
Funcionalidades
A [SCom01...] pretende adquirir um Sistema Integrado de Gestão de Performance, com Balanced Scorecard, Portfólio de Indicadores Operacionais baseados no IWA, Portfólio de Indicadores ERSAR e Plano de Actividades, com todas as funcionalidades descritos no Capítulo VI do Caderno de Encargos, com as seguintes funcionalidades (Todas elas obrigatórias):
- Sistema integrado de gestão de performance com verticalização para a área das águas e resíduos, adequado para entidades gestoras dos sistemas públicos.
- Solução Web descentralizada de avaliação, com suporte para o SIADAP, com autenticação integrada sobre uma Active Directory e com suporte para multientidade na mesma instância da aplicação.
- Possibilidade de definição, geração e acompanhamento de um Scorecard, bem como de hierarquização de indicadores e processo de aprovação hierárquico ou funcional.
- Suporte à definição e acompanhamento de um plano de actividades, com associação de recursos financeiros, humanos e materiais.
- Disponibilidade de relatórios sofisticados, pré-definidos ou resultantes de exploração multidimensional.
- Configuração de alarmes por e-mail para a calendarização do processo de avaliação.
- Disponibilização de cubos, para análise abrangente da informação.
- Facilidade de integração com outras aplicações existentes. Sistema aberto e web services disponíveis para geração de processos automáticos de monitorização de dados.
- Portfólios de indicadores e variáveis operacionais e de avaliação da ERSAR, com sistema web de alimentação da informação necessária para o cálculo dos indicadores. Possibilidade de utilização destes indicadores na avaliação da entidade ou unidades orgânicas.
- Parametrização extrema do sistema - Disponibilização de BackOffices para definição de funcionalidades da aplicação.
- Possibilidade de definição de portfólios de indicadores, e variáveis transversais, para avaliação da organização e unidades orgânicas.
- Suporte à definição de objectivos estratégicos e tácticos, alinhados entre si com base em critérios, com os seus respectivos indicadores plurianuais.
- Possibilidade de definição de scorecards anuais para as várias unidades orgânicas da organização.
- Garantir a possibilidade de criar reformulações da orgânica da organização, e dos scorecards por unidade orgânica, mantendo a coerência e ligação entre estas.
- Permitir definir templates de indicadores, que possam ser reutilizados nos vários scorecards da organização.
- Possuir uma área centralizada de definição de variáveis partilhadas ou comuns, e que possam posteriormente ser utilizadas em todos os indicadores da aplicação.
- Suportar fórmulas nos indicadores que utilizem as variáveis de sistema, permitindo as mais variadas combinações destas, como: períodos homólogos, acumulados ao ano, acumulados desde sempre, médias, mínimos e máximos.
- Permitir criar classificações para os objectivos e indicadores, de forma a poder filtrar ou organizar os objectivos e indicadores nos relatórios segundo estas classificações.
- Permitir definir várias metas por cada indicador, e também vários valores de referência - internos e externos (por exemplo ERSAR).
- Permitir obter a classificação dos indicadores com base numa escala de avaliação continua ou discreta, que possa ser personalizada.
- Suportar a definição das acções, projectos de investimento, ou actividades, para cada unidade orgânica, que concretizam os objectivos definidos, e associar recursos financeiros, humanos e materiais a estas.
- Permitir definir indicadores de medição do grau de concretização dos projectos de investimento definidos, e calcular estes indicadores a partir de uma fórmula que utilize variáveis de sistema ou de carregamento manual.
- Disponibilizar forma de definir e gerir tabelas e formulários de dados de uma forma dinâmica, com gestão de permissões, e permitir a fórmula de cálculo das variáveis de sistema, a partir dos dados carregados nestas tabelas de informação.
- Disponibilizar de raiz os indicadores e dados da qualidade de serviço da ERSAR, definidos no guia técnico 19 da ERSAR, e permitir utilizar os dados no cálculo de outros indicadores internos que se pretendam definir.
- Disponibilizar área para carregamento mensal dos dados solicitados pela ERSAR, com impacto e análise mensal dos indicadores respectivos, a produção dos ficheiros Excel de envio para a entidade reguladora no final do ano.
- Disponibilizar uma interface web baseada em HTML 5 que permita visualizar a performance das várias unidades orgânicas e das respectivas acções, nomeadamente visualizar os indicadores e sua fórmula de cálculo, dependendo das permissões dos colaboradores.
- O produto deve ser disponibilizado em regime de ASP suportado na plataforma AZURE da Microsoft (…)” — cf. documento n.° 1 junto com a Oposição;

7. Em 04 de Novembro de 2016, .a.........@..... remeteu e-mail para «FF», com o assunto “AquaPerformance — Sessão de formação/trabalho”, e com o seguinte teor:
Bom dia,
Serve o presente para confirmar a sessão de formação/trabalho para a próxima segunda e terça-feira, dia 7 e 8 de Novembro.
Para esta sessão ser mais produtiva penso que deveríamos pegar num exemplo vosso, não muito grande dado o tempo disponível, para seguirmos todo o processo de criação do mesmo no AquaPerformance. Seria assim necessário um indicador, as variáveis de cálculo do mesmo, e a tabela de dados que a alimentam.
Caso exista algum inconveniente nas datas acordadas peço que me indiquem ASAP. Obrigado,” — cf. documento junto a fls. 235 do SITAF;

8. Em 07 de Novembro de 2016, .a.........@..... remeteu e-mail para «FF», com o assunto “Template de criação de portfólio de indicadores”, com o seguinte teor:
Boa noite,
No seguimento da sessão de formação de hoje, e tal como solicitado, junto envio template de criação de portfólio que, se for preenchido, permitirá o carregamento do portfólio de indicadores.” — cf. documento junto a fls. 240 do SITAF;

9. Em 14 de Novembro de 2016, .a.........@..... remeteu para «FF» e-mail com o assunto “Plano de Trabalhos”, e com o seguinte teor:
Bom dia Eng.° «FF»,
No seguimento da formação da semana passada, e da solicitação de um plano de trabalhos, venho por este meio indicar-lhe os próximos passos previstos.
Neste momento, a nível de trabalhos de configuração e formação, está previsto apenas mais um dia de formação. Este dia poderá ser utilizado da forma que considerarem mais relevante, sendo que há duas áreas que sugiro que sejam tomadas em conta:
- Carregamento de dados (ERSAR ou outros) na aplicação, nas tabelas de dados, e por monitorização de variáveis. Esta sessão, deveria ocorrer apenas depois do portfólio carregado, e de algumas das tabelas de dados internas criadas, para ser dada sobre um ambiente produtivo;
- Definição e carregamento de BSC por parte dos responsáveis das unidades orgânicas. Esta sessão foi indicada que poderia não ser relevante, sendo que a sê-lo, faz sentido que apenas ocorra depois do carregamento do Vosso portfólio de indicadores.
Este dia poderá ser utilizado para estas duas sessões, ou apenas para uma, dependendo dos Vossos objectivos.
Todos os trabalhos adicionais falados, tais como carregamento de dados iniciais, integrações, e as funcionalidades adicionais solicitadas, encontram-se planeados nas tarefas adicionais, e previstas na proposta de trabalhos adicionais já enviada. Aguardamos ainda novidades relativamente a este tópico, já que deste dependem vários dos próximos trabalhos a desenvolver.
Caso tenha mais alguma questão, não hesite em nos contactar.
Atentamente,” — cf. documento junto a fls. 242 do SITAF;

. Em 15 de Novembro de 2016, a Autora celebrou com a Ré um contrato de fornecimento e prestação de serviços, do qual consta, designadamente, o seguinte:
CONTRATO DE FORNECIMENTO E PRESTAÇÃO DE SERVIÇOS
PRIMEIRO OUTORGANTE: (...) [SCom01...] EM (...)
SEGUNDO OUTORGANTE: (...) [SCom02...] UNIPESSOAL, LDA (...)
PELO PRIMEIRO FOI DITO: Que por deliberação dos Administradores Executivos de 7 de Novembro de 2016, foi adjudicada no âmbito de um dos Acordo Quadro da Entidade de Serviços Partilhados da Administração Pública, I.P., à Empresa representada pelo segundo outorgante a Aquisição de 2 máquinas do Software STRATUS — Lote 68 — Pacotes de Software — Balanced Scorecard, Portfólio de Indicadores Operacionais baseados no IWA, Portfólio de Indicadores ERSAR — Stratus — Plano de Actividades, que inclui serviços de manutenção de 36 meses (...)

Cláusula 1ª
Objecto do contrato
Aquisição de 2 máquinas do Software STRATUS — Lote 68 — Pacotes de Software — Balanced Scorecard, Portfólio de Indicadores Operacionais baseados no IWA, Portfólio de Indicadores ERSAR, Stratus — Plano de Actividades, que inclui serviços de manutenção de 60 meses, conforme proposta datada de 14 de Setembro de 2016.
Cláusula 2a
Preço
1 — O preço, com exclusão do IVA, resultante deste contrato é de 161.916,00 (Centro e sessenta e um mil novecentos e dezasseis euros).
2 — O preço referido no número anterior inclui todos os custos, encargos e despesas cuja responsabilidade não esteja expressamente atribuída ao contraente público, nomeadamente qualquer encargo decorrente da utilização de marcas registadas, patentes ou licença.

Cláusula 3a
Condições de Pagamento
1 — A quantia devida pela [SCom01...] nos termos da cláusula anterior, deve ser paga em 5 prestações anuais, no prazo máximo de 30 dias após a recepção pela [SCom01...] das respectivas facturas, que serão emitidas no início de cada ano contado após assinatura do contrato.
2 - A primeira factura referente à primeira prestação, será emitida após assinatura do contrato, no montante de € 38.316,00 (trinta e oito mil, trezentos e dezasseis mil euros), acrescidos de IVA à taxa legal em vigor.
As restantes 4 (quatro) prestações serão facturadas no início de cada ano, contado da assinatura deste contrato, no montante de 30.900,00 (trinta mil e novecentos euros), acrescidos de IVA.
(...)
Cláusula 4a
Prazo de execução do contrato
1 — O prazo de execução deste contrato é de 10 (dez) dias a contar da sua assinatura.
2 — O contrato mantém-se em vigor até à conclusão da prestação de serviços contratada, em conformidade com os respectivos termos e condições e o disposto na lei.

Cláusula 5a
Obrigações do adjudicatário
1 — Sem prejuízo de outras obrigações previstas na legislação aplicável, no Caderno de Encargos ou nas cláusulas contratuais decorrem para o adjudicatário as seguintes obrigações principais: fornecimento, instalação e entrada em funcionamento de Sistema Integrado de Gestão de Performance, com Balanced Scorecard, Portfólio de Indicadores Operacionais baseados no IWA, Portfólio de Indicadores ERSAR e Plano de Actividades.
2 — Durante o período de 36 meses mais 24 meses de oferta, conforme proposta do segundo Outorgante, perfazendo assim um total de 60 meses, o adjudicatário deve assegurar a manutenção evolutiva da ferramenta, bem como a assistência em help-desk.
3 — A título acessório, o prestador de serviços fica ainda obrigado, designadamente, a recorrer a todos os meios necessários e adequados à prestação do serviço, bem como ao estabelecimento do sistema de organização necessário à perfeita e completa execução das tarefas a seu cargo.
(...)
Cláusula 8a
Penalidades contratuais
1 — Pelo incumprimento de obrigações emergentes do contrato, a [SCom01...], pode exigir do adjudicatário o pagamento de uma sanção pecuniária, de montante a fixar em função da gravidade do incumprimento, nos seguintes termos:
- Pelo incumprimento das datas e prazos de entrega dos elementos a produzir referentes ao contrato, em função do prazo indicado, até 10% do valor global do contrato. (...)

Cláusula 12ª
Disposições Finais
Em tudo que não esteja integralmente previsto neste contrato aplica-se o disposto no Caderno de Encargos e no Código dos Contratos Públicos e restante legislação e regulamentação aplicável, nomeadamente no que respeita à segurança, higiene e saúde no trabalho, bem como à responsabilidade civil perante terceiros.
(...)”. — cf. documento n.° 1 junto com a petição aperfeiçoada, a fls. 162 e seguintes do SITAF;

11. Competia à Ré a parametrização do software, o que incluía a definição e inserção de fórmulas de cálculo, e a inserção dos dados — prova testemunhal;

12. A Autora emitiu as facturas n.°s 2016/2016048 e 2017/17054, no valor de, respectivamente, € 47.128,68 e € 38.007,00, as quais foram pagas pela Ré — cf. documentos n.°s 2 e 3 juntos com a petição aperfeiçoada, a fls. 167 e 168 do SITAF, e por acordo (artigo 13." da petição aperfeiçoada e artigo 1.° da contestação aperfeiçoada);

13. Em 04 de Janeiro de 2017, «FF» remeteu e-mail para «AA», com o conhecimento de «GG», subordinado ao assunto “Dúvidas variáveis Aquaperformance”, do qual se extracta o seguinte:
“«AA»
Temos dúvidas em relação à montagem (ou não) da arquitectura de algumas variáveis, designadamente as que compõem o Balanço e a DR.
A nossa questão prende-se com a alimentação das variáveis Pai. Se as identificarmos como tal, deixaremos de as alimentar automaticamente a partir do ERP e passarão a ser calculadas através da soma das filhas? Se sim, corremos o risco de calcular valores diferentes dos constantes no ERP, caso aquele sistema passe a incluir outras filhas não reproduzidas por lapso actualmente no Aquaperformance.
O ideal (para nós) seria a montagem da arquitectura (identificação de pais e filhas), para organização da informação, mas a alimentação da totalidade das contas, incluindo pai, para as variáveis seleccionadas, directamente através do ERP (p. ex.).
Aproveitamos para enviar uma primeira versão do template com as variáveis preenchidas, para que nos possa informar se estamos a interpretar o separador correctamente, ou dar algumas orientações.” — cf. documento junto a fls. 245 do SITAF;

14 . Em 16 de Janeiro de 2017, .a.........@..... remeteu e-mail para «FF» com o conhecimento de «GG», em resposta ao e-mail referido no ponto anterior, com o seguinte teor:
Boa tarde,
Da minha análise, eu diria que está quase tudo correcto, tirando algumas fórmulas. Como falado telefonicamente, todas as variáveis, mesmo que sejam directas, devem constar da tabela de variáveis da fórmula.
Deixo então as minhas notas:
- Atenção que têm fórmulas com texto (AGR019, AGR068, AGR069, AGR335, AGR378, AGR379).
- Há indicadores com uma variável “dia útil”. Isto terá que ser convertido numa variável.
- Há indicadores que referenciam variáveis com códigos inexistentes (AGR335 referencia contas financeiras que não existem).
- As variáveis não podem ter no seu código símbolos matemáticos (AGR252, AGR253, AGR288, AGR289, AGR290). Sugere-se alteração para por exemplo dAA33b_i e dAA33b_i1.
- Há pelo menos um indicador com um + no final, tornando-o uma fórmula inválida (AGR424)
Nota adicional: Por uma questão matemática, as variáveis não podem iniciar por um número, pelo que, caso pretendam ter uma variável para as contas financeiras, que tenha o código da conta, terão que colocar no seu código um prefixo (por exemplo SNC71).
Há dois ou três pontos que não estão previstos, mas que nós podemos poderemos corrigir a posteriori, quando recebermos o ficheiro final. A saber: a fórmula não deve ter espaços, e a multiplicação é feita com o *, em vez de um x — pode-se confundir com uma variável.” — cf. documento junto a fls. 245 do SITAF;

15 . Em 12 de Abril de 2017, .a.........@..... remeteu e-mail para «FF» e «GG», com o conhecimento de «BB», e o assunto “Disponibilização de interface para carregamento dos dados ERSAR da 3ª geração”, do qual se retira, o seguinte:
Bom dia,
No seguimento do lançamento da 3a geração de indicadores da ERSAR, informo que foi disponibilizada a interface de carregamento dos dados para a mesma. Também procedemos à migração dos dados carregados no módulo da 2ª geração, referentes aos anos de 2016 e 2017. No entanto, como houveram (sic) bastantes alterações, há muitos dados incompletos, e dados que simplesmente não existiam.
Como se trata de uma área completamento redesenhada, e criada de raiz, poderá necessitar de alguns ajustes, pelo que, caso detecte alguma questão que considere necessitar de correcção, peço que use o nosso sistema de Helpdesk para reportar essa mesma questão.
Para aceder a esta nova área poderão utilizar o link que anteriormente utilizavam, e que se encontra na homepage da aplicação, ou então a seguinte morada: http:IIaquapeformance.[SCom02...].ptlERSARData. Isto trata-se da primeira fase do processo de disponibilização do suporte para a 3ª geração dos indicadores da ERSAR, e nesta fase ainda não é possível gerar os ficheiros Excel de dados.
A segunda fase será o suporte para geração dos ficheiros da ERSAR prevemos que fique disponível no final da próxima semana, ou seja, até ao próximo dia 22.
Posteriormente, numa terceira fase, faremos o carregamento e a configuração do portfólio de indicadores na aplicação. Ainda estamos a verificar da possibilidade de manter uma ligação com os dados da 2ª geração, dentro do possível.
Como o portfólio só será disponibilizado nesta terceira fase, os indicadores actualmente presentes na aplicação continuarão a ser alimentados das tabelas de dados da 2ª geração.
De notar que continuam a ter disponível os dados carregados previamente, em área que se encontra na homepage da aplicação (chamada Dados ERSAR 2G).
Caso tenham alguma questão, não hesitem em nos contactar.” — cf. documento de fls. 271 do SITAF;
16 . Em Dezembro de 2018, houve uma acção de formação nas instalações da Ré — prova testemunhai';

17 . Em 20 de Dezembro de 2018, .a.........@..... remeteu e-mail para «EE», e «AA», com o conhecimento de «CC» e «BB», e com o assunto
Considerações no descontinuar de variáveis da 2ª geração da ERSAR”, do qual se retira, o seguinte: “Bom dia,
Relativamente à necessidade de descontinuar das variáveis da 2a geração da ERSAR, venho por este meio propor uma abordagem/solução.
Considerando que se tem como objectivo que não exista uma quebra com o passado, no que se refere à manutenção do histórico dos indicadores e variáveis, e que exista uma continuidade para o futuro, penso que a única solução será a que indico de seguida, e que poderemos implementar no início do ano, com o Vosso aval.
Tendo como objectivo primordial o descontinuar das variáveis de 2a geração, e assim retirando a actual duplicação de dados, temos que considerar sempre que não podemos perder o histórico. Assim, penso que a solução passa por garantir que as variáveis de 3a geração ficam com os valores de histórico existente na 2a geração. Isto permite, efectivamente, descontinuar as variáveis de 2a geração e manter uma continuidade de histórico.
Mas como as variáveis de 3a geração são calculadas a partir dos dados carregados e a reportar à ERSAR, teremos que garantir que isto não acontece para o histórico. Esta abordagem implica então que a forma de cálculo das variáveis de 3a geração será diferente antes, e a partir de 2019.
O histórico seria então carregado com os valores da 2a geração, e caso pretendam, para possíveis correcções no histórico, podemos colocar a variável de 3a geração a ser calculada, antes de 2019, a partir do local actual de reporte de variáveis de 2a geração. Isto permite que se possa, em qualquer momento, efectuar uma correcção no histórico.
Assim, vemos as seguintes tarefas como necessárias:
- Colocação da fórmula de cálculo das variáveis de 3a geração a partir das tabelas de reporte à ERSAR apenas a partir de 2019. Colocar estas, antes de 2019, a serem calculadas (para correcções de histórico) a partir dos dados já inseridos no módulo ERSAR 2G;
- Carregamento/cálculo do histórico das variáveis de 3a geração;
- Execução de procedimento de alteração de todos os indicadores, incluindo os indicadores da ERSAR de 2a geração, para que estes passem a utilizar as variáveis de 3a geração, em vez das de 2a geração;
- As variáveis de 2a geração que não existem na 3a geração poderão mudar de nome, passando a ser variáveis dAGR (é uma sugestão, não uma obrigação), e passarão a ser carregadas como as restantes variáveis, pela sua medição directa na área indicada durante a formação da semana passada;
- Eliminação das variáveis de 2ª geração não utilizadas.
Agradecemos os Vossos comentários para que possamos planear e implementar os procedimentos necessários à execução de estas alterações, para que a partir do dia 21 de Janeiro, como foi sugerido por Vós, sejam executados — cf. documento junto a fls. 273 do SITAF;

18. Em 11 de Janeiro de 2019, a Autora emitiu a factura n.° 2019/19002, no valor total de € 38.007,00 — cf. documento n.° 4 junto com a petição aperfeiçoada a fls. 169 do SITAF;

19. A factura emitida em 11 de Janeiro de 2019, foi remetida à Ré – por acordo (artigo 13.º da petição aperfeiçoada e artigo 1.º da contestação aperfeiçoada)

20. Em 21 de Janeiro de 2019, .a.........@..... remeteu e-mail para «EE», «AA», «CC» e «GG», com o conhecimento de «BB», com o assunto “AquaPerformance — Questões em aberto”, e com o seguinte teor:
Boa tarde,
No seguimento das sessões efectuadas, e no planeamento nessa altura efectuado, há três pontos para os quais aguardamos informação da Vossa parte.
São estes:
- Resposta ao e-mail que segue em anexo, e que tem questões e decisões críticas a tomar, no seguimento da decisão tomada de descontinuar as variáveis de 2ª geração;
- A recepção do formato pretendido para o relatório a extrair da aplicação com os resultados e metas dos indicadores, para ajudar no planeamento das metas de 2019;
- Recepção do relatório da estratégia pretendido para a extracção da informação carregada na aplicação.
O primeiro ponto é o mais crítico já que deste depende a implementação do processo que, segundo a Vossa Administração, deveria começar a implementado a partir do dia de hoje cf. documento de fls. 277 do SITAF;

21. Em 22 de Janeiro de 2019, «EE» respondeu ao e-mail referido no ponto anterior, referindo, o seguinte:
“Bom dia
Desde já agradecemos o envio do email, mas neste momento estamos a implementar um novo software de gestão, facto que tem absorvido quase a totalidade do nosso tempo.
Os assuntos não estão de forma alguma esquecidos mas apenas serão retomados na próxima semana, pelas nossas estimativas - cf. documento de fls. 277 do SITAF;

22. Em 06 de maio de 2019, .a.........@..... respondeu ao e-mail referido no ponto antecedente, do qual se retira, em concreto, o seguinte:
“Bom dia,
Pergunto se já têm alguma resposta, e se necessitam de algum tipo de apoio para que possamos dar resposta aos ainda tópicos em aberto.
Aproveito e questiono se já efectuaram a submissão dos dados para a ERSAR, e se estão com alguma dificuldade no uso desta área, em que possamos ajudar” — cf. documento de fls. 277 do SITAF;

23 . Em 14 de Maio de 2019, «EE» remeteu e-mail para .a.........@...... com o conhecimento de «DD», «AA» e «CC», com o assunto “Ano de 2019 — Definição e ajuste de Indicadores e variáveis”, e com o seguinte teor:
“ «AA» bom dia
Estamos atrasadíssimos relativamente ao ano de 2019.
Como estamos a rever o nosso sistema integrado de gestão, requeremos o vosso apoio para mais facilmente realizar as definições dos indicadores e variáveis para 2019.
Assim, necessitamos de um Excel com as definições todas dos indicadores e variáveis, para que possamos elaborar esta análise.” — cf. documento de fls. 281 do SITAF;

24 . Em 05 de Junho de 2019, .a.........@..... respondeu ao e-mail referido no ponto 22. propondo o seguinte:
Bom dia,
Tendo em conta a intenção demonstrada, no seguimento das sessões que ocorreram no passado mês de Dezembro, de implementar o projecto, e como este não tem andado à velocidade que todos gostariam que andasse, pergunto se não faz sentido fazer uma reunião conjunta para ver se há alguma forma, ou ajuda que possamos dar, para tentar acelerar o processo.” - cf. documento a fls. 281 do SITAF;

25 . Em 27 de Julho Lapso. Querer-se-ia escrever Junho. de 2019, .e.........@..... remeteu e-mail para
.d.........@...... com o assunto “Proposta de reunião com a [SCom02...]”, com o seguinte teor:
Boa tarde Eng. «HH»,
Ficou hoje decidido na Administração que era urgente a realização de uma reunião com a [SCom02...], pelo que proponho uma reunião para o dia 15 ou 16 de Julho, pelo que solicito que informa a sua disponibilidade, propondo uma hora preferencialmente num dos 2 dias propostos.” - cf. documento de fls. 283 do SITAF;

26. Em 16 de Julho de 2019 teve lugar uma reunião. onde a Ré informou que iria fixar um prazo para o cumprimento do contrato, sob pena de proceder à sua resolução — prova testemunhal;

27. Em 19 de Agosto de 2019, foi dirigido e-mail por .d.........@...... para .e.........@...... com o conhecimento de .f.........@...... e o assunto “Aprovação e pagamento da factura FA 2019/19002 emitida a 11-01-2019”, com o seguinte teor:
Exmos. Srs. Administradores da [SCom01...],
Antes do mais os nossos cumprimentos cordiais.
Vimos pelo presente solicitar mais uma vez, a aprovação da factura para o pagamento da factura FA 2019/19002, emitida a 11-01-2019, nos termos do contrato celebrado e vencida a 10-02-2019, no valor de 30.900,00 euros.
Caso não seja liquidado o valor da factura até 1 de Setembro, passaremos para o escritório de advogados que nos apoia juridicamente, o processo de cobrança desta factura, no sentido de evitarmos o nosso envolvimento pessoal, que entendemos não ser desejável” — fr. documento a fls. 244 do SITAF;

28 . Por carta datada de 20 de Agosto de 2019, a Ré dirigiu à Autora uma carta com o assunto:
Contrato de fornecimento e prestação de serviços para aquisição de duas máquinas de software Stratus — Lote 68 — Pacotes de Software — Balanced Scorecard, Portfólio de Indicadores Operacionais baseados no IWA, Portfólio de Indicadores ERSAR, Stratus — Plano de Actividades, incluindo serviços e manutenção”, e com o seguinte teor:
Exma. Gerência,
Na sequência da reunião do passado dia 16 de Julho, ficou acordado que, face à actual incapacidade de o serviço contratado corresponder ao solicitado pela [SCom01...], seria elaborado um documento explicitando as funcionalidades que ainda não são executadas pelo Sistema e as que o são de forma apenas parcial.
Assim, à data de hoje constatamos que o Sistema não executa as seguintes funcionalidades:
1. Solução Web descentralizada de avaliação, com suporte para o SIADAP, com autenticação integrada sobre uma Active Directory e com suporte para multientidade na mesma instância da aplicação: não se identificou a existência do suporte para SIADAP, a autenticação integrada com a Active Directory não funciona, não cumprindo o requisito.
2. Disponibilidade de relatórios sofisticados pré-definidos ou resultantes de exploração multidimensional: no conceito de que os relatórios sofisticados se consubstanciariam em relatórios dinâmicos com análise multidimensional, o sistema não cumpre o requisito, existindo apenas os relatórios pré-definidos e estáticos, não sendo possível à [SCom01...] alterar a sua estrutura,
3. Configuração de alarmes por e-mail para a calendarização do processo de avaliação: foram criados dois alertas de Indicadores e variáveis, mas os alertas por email não foram enviados, não cumprindo o requisito.
4. Disponibilização de cubos, para análise abrangente da informação: não se identificou a disponibilização de cubos para realização das análises, não cumprindo o requisito.
5. Facilidade de integração com outras aplicações existentes. Sistema aberto e web services disponíveis para geração de processos automáticos de monitorização de dados: não se identificou a existência de web services ou API de interligação de dados, não cumprindo o requisito.
6. Parametrização extrema do sistema - Disponibilização de BackOffices para definição de funcionalidades da aplicação: não se identificou a localização da definição de funcionalidades do sistema, não cumprindo o requisito,
7. Permitir criar classificações para os objectivos e indicadores, de forma a poder filtrar ou organizar os objectivos e indicadores nos relatórios segundo estas classificações: não foi identificado o cumprimento deste requisito.
8. Permitir definir várias metas por cada indicador, e também vários valores de referência - internos e externos (por exemplo ERSAR): não foi identificado o cumprimento deste requisito.
Existem ainda outras funcionalidades que são executadas de forma incompleta, tais como:
1. Suportar fórmulas nos indicadores que utilizem as variáveis de sistema, permitindo as mais variadas combinações destas, como: períodos homólogos. acumulados ao ano, acumulados desde sempre, médias, mínimos e máximos: foram identificados erros no cálculo e nas fórmulas. retirando a credibilidade e confiança nas centenas de indicadores resultantes de cálculos, não cumprindo o requisito.
2. Disponibilizar forma de definir e gerir tabelas e formulários de dados de uma forma dinâmica, com gestão de permissões, e permitir a fórmula de cálculo das variáveis de sistema, a partir dos dados carregados nestas tabelas de informação: não foi identificado o cumprimento deste requisito, nomeadamente utilizadores que registam dados mas que não os podem ver, tabelas em que é vedado o acesso à configuração entre outros.
3. Disponibilizar de raiz os indicadores e dados da qualidade de serviço da ERSAR, definidos no guia técnico 19 da ERSAR, e permitir utilizar os dados no cálculo de outros indicadores internos que se pretendam definir: não foi possível gerar com êxito os ficheiros de reporte à ERSAR através desta aplicação, não cumprindo o requisito.
4. Disponibilizar área para carregamento mensal dos dados solicitados pela ERSAR, com impacto e análise mensal dos indicadores respectivos, a produção dos ficheiros Excel de envio para a entidade reguladora no final do ano: não foi identificado o cumprimento deste requisito pelo exposto no ponto anterior.

Cumulativamente, alertamos ainda para as seguintes funcionalidades. que pese o facto de ainda não terem sido testadas, solicitamos que seja verificada a sua operacionalidade:
1. Suporte à definição e acompanhamento de um plano de actividades, com associação de recursos financeiros. humanos e materiais;
2. Suportar a definição das acções, projectos de investimento, ou actividades, para cada unidade orgânica, que concretizam os objectivos definidos, e associar recursos financeiros, humanos e materiais a estas;
3. Permitir definir indicadores de medição do grau de concretização dos projectos de investimento definidos, e calcular estes indicadores a partir de uma fórmula que utilize variáveis de sistema ou de carregamento manual.

Acresce ao exposto anteriormente a falta de estruturação e clareza na nomenclatura de variáveis e indicadores, que conjugada com a diversidade e cruzamento de dados entre as diversas tabelas resulta numa aplicação pouco confortável na utilização, quer a nível de carregamento de dados, quer a nível de análise dos mesmos.
Conforme referido no ponto anterior foram reiteradamente identificados erros no cálculo de indicadores que, tal como referido na reunião do passado dia 16/07, retiram a confiança num sistema que se pretende de análise de nível superior de dados e Indicadores para a tomada de decisão real time.
Verificaram-se ainda actualizações da aplicação que originaram a perda de dados anteriormente introduzidos.
Neste enquadramento, solicitamos que impreterivelmente, até 20 de Setembro do corrente ano sejam colocadas em funcionamento pleno e de forma fiável todas as funcionalidades acima listadas.
Em acréscimo solicitamos que nos indiquem 3 empresas do sector de actividade da [SCom01...] que usem o v/ sistema para troca de experiências na utilização do mesmo e agendamento das respectivas visitas” - cf. documento n.º 5 junto com a Oposição;

29. Por carta datada de 19 de Setembro de 2019, a Autora respondeu à carta referida no ponto 27, nos seguintes termos:
“Tomámos em boa nota a comunicação de V.Exas. acima melhor identificada.
Após a leitura atenta da mesma podemos deixar de manifestar a estranheza quanto ao seu teor e objecto, tendo em conta os recentes encontros havidos, nomeadamente uma acção de formação de revisão de novas funcionalidades e esclarecimento de dúvidas sobre a aplicação em apreço ocorrida de 13 a 14 de Dezembro de 2018, bem como o almoço de trabalho ocorrido em 14 de Dezembro de 2018, no qual foi abordado interesse de um aprofundar da parceria existente.
Sem prejuízo do que se dirá a final, e atenta as referências acerca do funcionamento do software Stratus Lote 68 - Pacote de Software Balanced Scorecard, Portfólio Indicadores Operacionais baseados no IWA, Portfólio de Indicadores ERSAR, Stratus-Plano de Actividades diremos o seguinte, seguindo para o efeito o elenco apresentado em tal comunicação:
1.
Caderno de encargos:
Solução Web descentralizada de avaliação, com suporte para o SIADAP, com autenticação integrada sobre uma Active Directory e com suporte para multientidade na mesma instância da aplicação:
[SCom01...]:
Não se identificou a existência do suporte para SIADAP. A autenticação integrada com o Active Directory não funciona, não cumprindo o requisito.
Resposta [SCom02...]:
O suporte SIADAP existe. A autenticação via Active Directory é possível, bastando para isso, fazer as devidas configurações. Decorridos 3 anos sobre a contratação, e uma vez que até à data em que recebeu a comunicação a que agora se responde, a [SCom01...] nunca solicitou a sua implementação. De certo modo compreende tendo em conta que a inclusão do SIADAP no pacote em apreço constituiu, em rigor, uma oferta da [SCom02...].
A [SCom01...] pretende implementar o SIADAP?
Em caso afirmativo, informa-se que o módulo do SIADAP implica uma instalação e configuração específicas que não foram incluídas na proposta.
Essa instalação e configuração, bem como a formação de formadores tem de ser objecto de proposta. Agradecemos por isso que nos informem se pretendem que seja enviada a proposta correspondente.
Mais se informa que esta aplicação já sofreu várias alterações profundas, por via das sucessivas alterações legislativas e como forma de dar cumprimento às mesmas, pelo que a versão objecto do contrato já não está actual, no entanto a [SCom02...] disponibilizará a versão actual.
Nesta medida, é nosso entendimento que este requisito se encontra plenamente satisfeito, e que apenas não foi objecto de utilização por motivos apenas a [SCom01...] poderá esclarecer
2.
Caderno de encargos:
Disponibilidade de relatórios sofisticados, pré-definidos ou resultantes de exploração multidimensional; no conceito de que os relatórios sofisticados se consubstanciam em relatórios dinâmicos com análise multidimensional
[SCom01...]:
O sistema não cumpre o requisito, existindo apenas os relatórios pré-definidos e estáticos, não sendo possível à [SCom01...] alterar a sua estrutura.
Resposta [SCom02...]:
A frase “no conceito de que os relatórios sofisticados se consubstanciam em relatórios dinâmicos com análise multidimensional” não consta do caderno de encargos.
- Disponibilidade de relatórios sofisticados, pré-definidos ou resultantes de exploração multidimensional,
O Cubo que referem existe. Decorridos 3 anos o mesmo nunca foi solicitado.
Admitimos que nunca tenha sido solicitado atenta a evolução que o produto disponibilizado confere. De Facto, o reforço ao cockpit de gestão que implementámos e aos relatórios detalhados em Excel, como a própria [SCom01...] afirmou de forma clara na fase de prototipagem antes da adjudicação, como sendo necessários, permitiu dar resposta ao pretendido.
De notar que tendo passado a estar disponível em relatório Excel, gerado a partir do cockpit e que já permite, por utilizar a tecnologia de tabelas dinâmicas, adicionar e remover colunas e filtros, julgamos que vai inteiramente ao encontro do pretendido com elevadas vantagens.
Em suma, o cubo referido existe mas para além disso disponibilizámos para os clientes como a [SCom01...], que viessem a pretender análises dimensionais, uma tecnologia web de exploração dimensional dos danos relacionais, Tais dimensões dependem dos requisitos do cliente.
Já informámos a [SCom01...] que teríamos a possibilidade de construir os relatórios correspondentes, sem custos adicionais.
Podemos enviar o ficheiro Excel que permite a exploração do cubo referido anteriormente, embora nos pareça que os relatórios entretanto disponibilizados, e que são de facto utilizados, e a tecnologia referida serão bem mais efectivas para o suporte ao negócio da empresa.
Consideramos assim o requisito inteiramente satisfeito.
3.
Caderno de encargos:
Configuração de alarmes por e-mail para a calendarização do processo de avaliação.
[SCom01...]:
Foram criados dois alertas de indicadores e variáveis, mas os alertas por email não foram enviados, não cumprindo o requisito. Resposta [SCom02...]:
O processo de avaliação referido é referente ao SIADAP, mas estes também existem no BSC, como pode ser verificado e é comprovado pela indicação de terem sido criados.
Ou seja, a possibilidade de criação de alertas existe.
Até à data de envio da carta a que ora se responde não nos havia sido comunicado qualquer existência de erro nesta matéria. Com tal indicação procedeu-se a uma verificação e foram executadas as alterações de modo a eliminar tais erros, ficando por isso a questão totalmente solucionada. Tratando-se de programas informáticos é normal que surjam bugs, daí a importância de nos darem nota da existência que permitam a sua correcção.
Em suma, com o vosso reporte foi solucionada a questão, neste momento os alertas estão criados.
Alertamos mais uma vez que a existência do nosso serviço de Helpdesk, serve exactamente para dar resposta a questões como esta, estando sempre disponível.
Desde o passado dia 13/09/2019 que a questão está solucionada.
Consideramos que o requisito está satisfeito.
4.
Caderno de encargos:
Disponibilização de cubos, para análise abrangente da informação.
[SCom01...]:
Não se identificou a disponibilização de cubos para a realização das análises, não cumprindo o requisito.
Resposta [SCom02...]:
Esta questão, por ser idêntica, está respondida no ponto acima “Disponibilidade de relatórios sofisticados, pré-definidos ou resultantes de exploração multidimensional”.
Consideramos que o requisito está satisfeito.
5.
Caderno de encargos:
Facilidade de integração com outras aplicações existentes. Sistema aberto e web services disponíveis para geração de processos automáticos de monitorização de dados.
[SCom01...]:
Não se identificou a existência de web services ou API de interligação de dados, não cumprindo o requisito.
Resposta [SCom02...]:
Os web Services sempre estiveram disponíveis, mas como foi decidido que a integração seria só iniciada depois da estabilização dos indicadores e dos dados, nunca foi uma necessidade até ao momento.
A versão actual da aplicação disponibiliza um novo mecanismo de integração automática de dados para as tabelas de dados, com base nos web services, e que são um upgrade significativo [da]versão anterior.
Anexamos a descrição da solução que permite ainda maior flexibilidade na integração de dados. (Anexo I).
Este mecanismo de integração automática utiliza um web service que, se pretendido, também poderão utilizar internamente para criar mecanismos de integração automática.
Os novos web services podem ser consultados aqui:
(...)
Consideramos que o requisito está totalmente cumprido.
6.
Caderno de encargos:
Parametrização extrema do sistema — Disponibilização de BackOffices para definição de funcionalidades da aplicação.
[SCom01...]:
Não se identificou a localização da definição de funcionalidades do sistema, não cumprindo o requisito.
Resposta [SCom02...]:
Não compreendemos esta questão, uma vez que existem várias áreas de configuração, como a área de configurações Gerais (...) nomeadamente na sua área de Configurações, existindo áreas equivalentes para o Plano de Actividades e Avaliação dos Colaboradores.
Ou seja, a funcionalidade existe e está disponível como, por mera facilidade, se demonstra pela indicação dos links.
Consideramos por isso que o requisito está integralmente satisfeito.
7.
Caderno de encargos:
Permitir criar classificações para os objectivos e indicadores, de forma a poder filtrar ou organizar os objectivos e indicadores nos relatórios segundo estas classificações.
[SCom01...]:
Não foi identificado o cumprimento deste requisito.
Resposta [SCom02...]:
Os objectivos, indicadores e variáveis podem ser classificados, por grupos de atributos configuráveis. Os relatórios que listam indicadores e variáveis permitem filtrar por classificações.
Os objectivos, por estarem associados a um BSC estarão organizados por perspectiva, existindo, no entanto, um relatório de listagem de BSC agrupado por classificações.
Estas classificações podem ser criadas na área de Configurações Gerais
(...), tab Atributos.
Consideramos por isso que o requisito está satisfeito.
8.
Caderno de encargos:
Permitir definir várias metas por cada indicador- e também vários valores de referência — internos c externos (por exemplo ERSAR)
[SCom01...]:
Não foi identificado o cumprimento deste requisito.
Resposta [SCom02...]:
No portfólio de indicadores é possível definir metas dos indicadores, para várias dimensões de análise (configuráveis), estando já pré configuradas a interna e a da ERSAR.
[Imagem que aqui se dá por reproduzida]
Consideramos por isso que o requisito está e sempre esteve cumprido.
9.
[SCom01...]: Existem ainda outras funcionalidades que são executadas de forma incompleta, tais como:
Caderno de encargos:
Suportar fórmulas nos indicadores que utilizem as variáveis de sistema, permitindo as mais variadas combinações destas. como: períodos homólogos, acumulados ao ano, acumulados desde sempre, médias, mínimos e máximos.
[SCom01...]:
Foram identificados erros no cálculo e nas fórmulas, retirando a credibilidade e confiança nas centenas de Indicadores resultantes de cálculos, não cumprindo o requisito.
Resposta [SCom02...]:
O tipo de fórmulas suportadas é o Indicado, como é comprovado pelos 563 indicadores configurados pela [SCom01...], no sistema. No nosso HelpDesk, a título de exemplo, desde o início de 2019, foram-nos reportados 5 problemas desta natureza, que foram todos resolvidos em menos de 2h.
Adicionalmente, é de notar que os "erros" detectados não foram erros de cálculo em nenhuma das fórmulas dos indicadores, até porque estas são da inteira fixação e gestão da [SCom01...] (logo, apenas os serviços internos da [SCom01...] poderão explicar a situação), ou no cálculo destes, mas sim questões pontuais na forma de cálculo de dados da ERSAR, que, como é conhecido, muda anualmente.
Nesse reporte de "erros", em rigor não eram erros, mas sim falta de cálculo.
Estas situações ocorreram num universo de 563 indicadores e 1308 variáveis. Reportadas as situações foram as mesmas prontamente solucionadas.
Nesta medida este requisito foi absolutamente satisfeito, não se podendo olvidar que estamos perante um universo variável e evolutivo ao qual a [SCom02...] tem vindo a dar satisfação.

11.
Caderno de encargos:
Disponibilizar de raiz os Indicadores e dados da qualidade de serviço da ERSAR, definidos no guia técnico 19 da ERSAR. E permitir utilizar os dados no cálculo de outros indicadores internos que se pretendam definir.
[SCom01...]:
Não foi possível gerar com êxito os ficheiros de reporte à ERSAR através desta aplicação, não cumprindo o requisito.
Resposta [SCom02...]:
A funcionalidade está completamente disponível.
Não foi reportado no nosso sistema de HelpDesk qualquer problema relacionado com a geração do ficheiro ERSAR, por parte da [SCom01...],
Apesar disso, tendo em conta que na última reunião foi-nos dito pela primeira vez, que a [SCom01...] tem um ficheiro distinto das demais entidades gestoras, admitimos que tal circunstância poderá gerar a alegada dificuldade.
Reiteramos que o nosso HelpDesk está todos os anos, por altura da integração dos dados na plataforma da ERSAR, disponível 24 horas, 7 dias por semana disponível para qualquer dificuldade nesta matéria, e caso tivesse sido reportado teria sido prontamente resolvido e, se necessário fosse, teria sido disponibilizado à [SCom01...] um ficheiro com os dados carregados, em tempo que estimamos não superior a 1h, sem necessidade de qualquer esforço interno da [SCom01...].
Notamos ainda que a versão actual do ficheiro gerado pela aplicação já utiliza o ficheiro standard para que seja 100% standard e compatível.
Caso façam ou necessitem de alterações ao ficheiro, devem sempre informar a [SCom02...] para que tenhamos isso em conta. Todos os anos a ERSAR procede a alterações ao ficheiro, que resultam da mais recente actualização e a [SCom02...] reflecte essas alterações na geração do ficheiro. Como acima foi dito, tendo a [SCom01...] negociado ou acertado algum tipo de especialidade com a ERSAR, naturalmente que teremos que ter um conhecimento prévio e atempado para que não haja incongruências.
Consideramos por isso que o requisito contratualmente definido está e esteve sempre cumprido.

12.
Caderno de encargos:
Disponibilizar área para carregamento mensal dos dados solicitados pela ERSAR, com impacto e análise mensal dos indicadores respectivos, a produção dos ficheiros Excel de envio para a entidade reguladora no final do ano.
[SCom01...]:
Não foi identificado o cumprimento deste requisito pelo exposto no ponto anterior.
Resposta [SCom02...]:
Como foi referido no ponto anterior, esta área existe e a produção dos ficheiros é, e sempre foi, possível, sendo um ficheiro sempre gerado.
Inclusivamente pode ser gerado em qualquer período do ano para que tenham uma imagem há [sic] data em que é gerado o carregamento mensal dos dados também está garantido.
Este requisito está por isso satisfeito.

13.
[SCom01...]: Cumulativamente, alertamos ainda para as seguintes funcionalidades, que pese o facto de ainda não terem sido testados, solicitamos que seja verificada o sua operacionalidade
Caderno de encargos:
Suporte à definição e acompanhamento de um plano de actividades, com associação de recursos financeiros, humanos e materiais. [SCom01...]:
Resposta [SCom02...]:
Por diversas vezes propusemos formação no Plano de Actividades, mas nunca foi considerado oportuno pela [SCom01...].
Pretende a [SCom01...] avançar com a implementação desta funcionalidade?
Em caso afirmativo aguardamos a identificação do chefe de projecto e indicação de quando pretende avançar, para que possamos avaliar o esforço envolvido.
Requisito satisfeito.

14
Caderno de encargos:
Suportar a definição das acções. projectos de investimento, ou actividades, para cada unidade orgânica, que concretizam os objectivos definidos, e associar recursos financeiros. humanos e materiais a estas.
[SCom01...]:
Resposta [SCom02...]:
Este requisito é satisfeito pelo módulo do Plano de Actividades.
Por diversas vezes propusemos formação no Plano de Actividades, mas nunca foi considerado oportuno pela [SCom01...].
Pretende a [SCom01...] avançar com a implementação desta funcionalidade? Em caso afirmativo aguardamos a identificação do chefe de projecto e a indicação de quando pretende avançar, para que possamos avaliar o esforço envolvido.
Requisito satisfeito.

16.
[SCom01...]:
Acresce ao exposto anteriormente a falta de estruturação e clareza na nomenclatura de variáveis e indicadores, que conjugada com a diversidade e cruzamento de dados entre as diversos tabelas resulta numa aplicação pouco confortável na utilização, quer a nível de carregamento de dados, quer a nível de análise dos mesmos.
Resposta [SCom02...]:
A clareza dos indicadores e a sua nomenclatura é da responsabilidade da [SCom01...], não tendo sido definida ou criada pela [SCom02...].
A este propósito notamos que já há alguns meses que a [SCom02...] alerta e solicita de forma continuada que seja tomada uma decisão quanto ao tema da duplicação de dados, decorrente da existência de 2a e 3a geração de indicadores da ERSAR (que como estarão recordados foi uma opção da [SCom01...]).
Conscientes que a existência da 2.ª e 3.ª geração de dados pode prejudicar a utilização e provocar confusões desnecessárias, procurámos e insistimos numa tomada de decisão que não ocorreu. Sabendo do impacto que tem e que penaliza a utilização que é feita pelos operacionais da [SCom01...], a falta de definição da [SCom01...] quanto ao que pretende exactamente impediu que pudéssemos executar os ajustes necessários, situação que já se prolonga há largos meses.
Não cabe à [SCom02...] tomar uma decisão sobre o que fazer neste ponto.
Reiteramos assim a importância de tal definição e aproveitamos para questionar a [SCom01...] acerca da tomada de decisão neste ponto e, em caso negativo, questionamos quando é que poderemos ter da parte da [SCom01...] tal definição do que se pretendem implementar.
Os e-mails que referem esta questão encontram-se no Anexo II, no final deste documento.

17.
[SCom01...]:
Conforme referido no ponto anterior foram reiteradamente identificados erros no cálculo de indicadores que, tal como referido na reunia do passado dia 16/07, retiram a confiança num sistema que se pretende de análise de nível superior de dados e Indicadores para a tomada de decisão real time.
Resposta [SCom02...]:
A resposta a este ponto já foi feita no tópico acima identificado "Foram identificados erros no cálculo e nas fórmulas, retirando o credibilidade e confiança nas centenas de indicadores resultantes de cálculos...”.
Damos por reproduzidas as explicações ali constantes.
Consideramos assim estas conclusões são totalmente infundamentadas.

18.
[SCom01...]:
Verificaram-se ainda actualizações da aplicação que originaram a perda de dados anteriormente introduzidos.
Resposta [SCom02...]:
Não temos nota de uma efectiva perda de dados,
Apenas nos foi reportada uma única vez que teria existido uma perca de dados, todavia não nos explicaram que dados, como é que tal ocorreu, qual o contexto e acções que foram realizadas e outros elementos que pudessem ou permitissem verificar a situação. Ocorreram outras situações, todavia nunca foram de "perda" de dados, mas sim uma mudança de acesso de visualização destes, ou uma actualização de dados feita indevidamente.
— Cf. documento n.° 6, junto com a Oposição;

30. Em 16 de Outubro de 2019, a Autora apresentou requerimento de injunção junto do Balcão Nacional de Injunções, com vista ao pagamento da quantia de € 40.534,25 — cf. documento a fls. 1 e seguintes do SITAF;

31. No decurso da relação contratual a Ré apresentou mais de uma centena de pedidos de assistência em helpdesk — cf. documento n.º 4, junto com a contestação, e documentos juntos a fls. 291 a 369 do SITAF, e prova testemunhal;
32. Os pedidos de assistência em helpdesk foram dados como fechados pela Autora — cf. documento n.° 4, junto com a contestação, e documentos juntos a fls. 291 a 369 do SITAF, e prova testemunhal;

33. Dentro dos pedidos de assistência em helpdesk, e com relevo para a presente causa, destacam-se os seguintes tickets:
“- # 906, de «CC», com o seguinte teor: “Nos últimos dias carreguei/alterei quer valores de varáveis, metas e outras configurações.
Pelo menos as alterações efectuadas durante o fim de semana não produziram ainda qq efeito. Solicito processamento urgente "; e após esclarecimentos prestados a pedido de «AA», a seguinte resposta: “Ao verificar os valores do indicador AA10ab_2G verificamos que este foi recalculado ontem de manhã e o mês de Dezembro até hoje, pelo que vejo por um reprocessamento chamado por vós. A variável dAA32 não mudou de valores. Os valores aparentam estar de acordo com o carregado. Relativamente ao AGR197. A aplicação não faz o reprocessamento de históricos de 2012 todos os dias. Por omissão, diariamente, apenas o faz para os últimos 24 meses, para garantir o processamento do ano anterior ao actual. Neste caso o que devem fazer é solicitar-nos este reprocessamento. Já foi reprocessado e poderá confirmar que os dados foram recalculados, mas atenção que segundo o histórico, nos dados de 2012, esta variável só foi alterada hoje de manhã.
Relativamente ao indicador RU11ab_2G. O problema está que mudaram a forma de carregamento das variáveis, e isto gerou entradas repetidas nas tabelas AA, AR e RU.
Não sei se tem isto presente visto isto só ter sido falado durante a formação, mas existe a possibilidade de carregar os dados deforma parcial, com base em grupos de permissão. E os dados carregados por cada grupo de permissão não poderá ver os dados carregados por outro. No vosso caso, como administradores, podem ver os dados carregados por todos os grupos e, se seleccionarem o grupo "<Todos>" verão tudo o que foi carregado, por todos os utilizadores (ver imagem abaixo). Ao carregarem dados com o grupo seleccionado irão carregar dados como sendo desse grupo e as pessoas desse grupo poderá ver os dados carregados. Se seleccionarem o grupo <Todos> e carregarem dados apenas os administradores poderão ver estes dados.
O que aconteceu é que os dados inicialmente carregados estão carregados pelo grupo de utilizadores AGR_Todos. No carregamento efectuado carregou com o grupo "<Todos>". Isto significa que ficaram com dois valores carregados para a mesma variável. O sistema, nestes casos, utiliza o primeiro valor carregado. Daí a variável não ter sofrido alterações de valor.
Depois, parece-nos que estão a importar o ficheiro várias vezes, e os valores estão a ficar repetidos. Isto porque não exportam os dados e alteram, ou então porque não apagam os dados antes de os importar novamente.
Pretendem que removamos todas os dados registados excepto as últimas entradas?"; e insistência de «CC», com o seguinte teor: “Desculpe mas não entendo nada do que explicou. qq carregamento feito por mim é no grupo "todos" portanto tem que prevalecer sobre todos os outros além disso não criei novos dados, somente corrigi dados anteriores. como administradora qq minha alteração terá que ser validada sobre qq outra.
Hoje, quando verifiquei, novamente, a falta do processamento efectivamente voltei a carregar contudo já o tinha feito pelo menos 2 x"; e nova resposta de «AA» “Já entendemos o problema. No passado dia 17/05 foram dadas permissões a este grupo AGR_Todos a estas tabelas. Até a essa altura, apenas os administradores carregavam dados. O que acontece é que isto teve o impacto dos dados previamente carregados não ficarem disponíveis para estes, e gerou estas incoerências de dados novamente carregados, e gravados, visto agora ficarem associados a este grupo de acesso.
Nota: O facto de existirem dados diferenciados por grupos de permissões foi uma decisão tomada por Vós no início do projecto. No entanto, esta poderá ser desactivada caso o pretendam.
Neste caso, gerou este problema porque as permissões foram dadas já depois do carregamento de dados.
Pedia só a Vossa confirmação de que podemos eliminar os dados que estão a mais, ou seja, os mais antigos, ficando apenas os mais recentes.
Aproveito e pergunto se os dados foram carregados por Excel ou actualizados directamente na aplicação.”;

- # 1034, de «DD», com o seguinte teor “Cálculo do Indicador (tabela) Deveria presentar o resultado de 73.43, que resulta da divisão da dAR12ab_2G/dAR14ab_2G. Ambas tem carregados valores para o período em análise. Agradeço que me indiquem o motivo para não estar a calcular."; e resposta de «AA» “O motivo é a falta de carregamento da variável dAR13b. Esta não está carregada para este mês. Mais se informa que esta apenas tem valores registados com um número diferente de 0 em Setembro de 2018.”;
- # 1039, de «DD», do qual consta “Variável sem valor, e tem carregamentoA variável dRU57b, está carregada nos meses de Junho a Dezembro, por favor ver o seu carregamento em: (link) no entanto está a exibir Blank de Junho a Dezembro”; e resposta de «AA» “O dado dRU57b é calculado a partir da tabela RU — Lavagens, e não da tabela referida. E na tabela de RU — Lavagens apenas estão registados os contentores de superfície, sendo que para este dado são contabilizados os contentores subterrâneos”;
- # 1040, de «DD», do qual consta “Variável dAR44b — Inundações: com introdução de dados, p.f. ver em (link) no entanto quanto extraído (quadro)"; resposta de «AA» “Agradeço o reporte do problema. Estivemos a verificar e havia uma falha no cálculo de estes dados, que foi entretanto corrigido. Agradecemos verificação e feedback”;
- # 1043, de «EE», do qual consta “Valor não aparece calculado na variável dAA28ab, mesmo com valores” “Não consigo descobrir de onde vem este valor. No mês 9 temos 3 variáveis: dAA28, dAA28b e ontem registei para teste dAA28ab com o mesmo valor, mas este hoje não aparece na variável “dAA28ab”.
Ver imagens em anexo.
Como conseguimos saber deforma inequívoca onde devemos colocar o valor de determinada variável Ersar? Na tabela AA ou tabelas AA - xpto?
O valor recolhido da variável vem da 2G ou 3G?”; e resposta de «AA» “Para Vossa referência, segue em anexo uma lista de todas as variáveis da ERSAR e as tabelas utilizadas no cálculo destas. As variáveis podem aparecer mais do que uma vez, indicando que é utilizada mais do que uma tabela no cálculo desta. Penso que isto poderá ser muito útil em dúvidas deste tipo. Apenas as variáveis que têm o sufixo _2G é que são recolhidas da componente 2G. Todas as restantes são 3G. Segundo a tabela que envio, a variável dAA28ab é calculada a partir dos dados carregados na tabela "AA - ETA", e portanto é nesta que devem ser carregados os dados.”;

- # 1045, de «EE», do qual consta “A variável dAGR510 não é calculada em Dez2018, tabela dados AquaPerformance ‘Variáveis DPT Manutenção”, embora tenha calculado nos meses anteriores. Este é apenas um exemplo pois são várias”; resposta de «AA» “Efectivamente havia uma falha numa configuração, que fazia com que o processamento de dados alterados não fosse feito correctamente. As minhas desculpas pelo sucedido. Já está normalizado e os dados já deverão estar todos calculados”;
- # 1048, de «DD», com o teor “Variável carregada a Dezembro sem valor ’ “A Variável dAGR613, tem valor introduzido na tabela em Dezembro figura abaixo). No entanto não está a ser exibido, ver imagens em anexo”; e resposta de «AA» “A variável está medida. O que se passa é que a unidade de medida desta é m3, e esta unidade de medida está configurada como um número inteiro. E portanto, sendo o valor 0,216, este é arredondado para 0, que é o valor apresentado.
Portanto, o que deverão fazer é mudar a unidade de medida desta variável para a correcta.
Depois disto, quando for processado, o valor já deverá ser registado correctamente”;
- # 1050, de «DD», com o teor “Por favor, o indicador AGR386 — Custo Médio da Energia — Acum. Ano encontra-se com resultado em todos os meses, no entendo [entanto], no relatório do Scorecard não emite resultado — figuras abaixo”; resposta de «AA» ‘Efectivamente havia uma falha, que ocorria caso a fórmula do indicador não transitasse para o BSC, que é o caso. Já efectuamos a correcção todos os dados nesta situação foram reprocessados”;
- # 1084, de «DD», do qual consta “a variável dAGR473, já teve resultado em 2018, pois tenho relatórios com o seu resultado, mas neste momento o seu resultado está ND, ver figura abaixo:”; resposta de «AA» ‘Efectivamente, decorrente de uma actualização efectuada no passado dia 12, houve alguns dados que foram incorrectamente calculados. Esta actualização foi corrigida no dia seguinte, mas os danos [dados?] não tinham sido reprocessados. Já foram e já deverão apresentar resultados- cf. documento n° 4 junto com a Oposição, e tickets juntos com a Réplica, a partir de fls. 309 do SITAF;

34 . O software não permitia gerar relatórios dinâmicos — prova testemunhal;

35 . A Ré não concluiu a parametrização do software — prova testemunhal;

36. Em 06 de Janeiro de 2020, a Autora emitiu a factura n.° 2020/20002, no valor de € 38.007,00 — cf. documento junto a fls. 403 do SITAF;

37. Em 28 de Setembro de 2021, a Autora emitiu a factura n.° 2021/21023, no valor de € 38.007,00 — cf. documento junto a fls. 3536 do SITAF;

38. A Ré não pagou as facturas emitidas em 11 de Janeiro de 2019, em 06 de Janeiro de 2020, e em 28 de Setembro de 2021 — por acordo (artigo 15 da petição aperfeiçoada e artigo 1.º da contestação aperfeiçoada; e requerimentos de ampliação do pedido e causa de pedir e resposta, a fls. 395, 410, 3534 e 3543 do SITAF).
*
MOTIVAÇÃO
Antes de mais, cumpre dizer que a restante matéria alegada pelas partes não foi julgada indiciariamente provada ou não provada, por constituir conceito de direito, matéria conclusiva ou não relevar para a decisão da causa.
A convicção deste tribunal formou-se com base nos elementos devidamente identificados em cada uma das alíneas do probatório, resultando da análise crítica da prova produzida nos autos, com a referência à documentação constante dos mesmos.
De notar que o tribunal decidiu valorar o documento n.° 4 junto com a Oposição, na parte em que o mesmo se demonstra legível, por se tratarem [sic] de pedidos de helpdesk, os designados tickets, remetidos para a Autora, pelo software informático objecto dos presentes autos, motivo pelo qual não os pode desconhecer. Mais, a própria Autora procedeu à junção de alguns destes tickets com a sua Réplica, existindo, assim, duplicação de parte dos tickets transcritos.
No mais, nomeadamente nos pontos 11, 16, 26, 31, 32, 34 e 35, a convicção do tribunal baseou-se essencialmente numa apreciação livre e à luz das regras de experiência comum, dos depoimentos prestados em sede de audiência de julgamento, pelas testemunhas arroladas pelas partes, cuja identificação consta da acta a fls. 3549 dos presentes autos.
Quanto à prova testemunhal, o Tribunal ouviu as testemunhas da Autora, «BB», sócio-gerente da Autora, «AA», consultor informático, e as testemunhas da Ré, «CC», Directora Geral da [SCom01...], desde Setembro de 2017, «DD», funcionária da [SCom01...], desde Janeiro de 2019, «AA», consultar para a [SCom01...], de Julho de 2018 a Janeiro de 2019, altura em que integrou os quadros da [SCom01...], e «EE», consultor informático da [SCom01...].
Impondo-se sublinhar o depoimento prestado pela testemunha da Autora, «AA», o qual relevou conhecimento directo dos factos em discussão, e que dessa forma influenciou a apreciação da matéria controvertida nos autos.
Com efeito, destaca-se do referido depoimento que em momento anterior à celebração do contrato foi realizada uma “Prova de Conceito” ao software em causa nos presentes autos, e só após verificado se o software cumpria com os requisitos é que ocorreu a celebração do contrato. Todavia, tal relação contratual implicava obrigações para a Ré, concretamente as obrigações de parametrização dos dados, as quais nunca foram concluídas. Tal como a passagem da 2.a geração de indicadores da ERSAR para a 3.a geração se viu frustrada face à inércia da Ré. A testemunha foi ainda isenta ao admitir que os pedidos de helpdesk, que indicou terem sido no número de 137 foram todos satisfeitos, sendo certo que satisfeito significa apenas respondido, e que caso os visados entendessem que a resposta não era suficiente teriam de continuar a responder ao pedido de helpdesk criado, ou instruir novo pedido de helpdesk.
Com efeito, foi assumido pela quase totalidade dos depoimentos que a parametrização dos dados era da responsabilidade da Ré, e que essa parametrização incluía a definição e inserção das fórmulas de cálculo e a inserção de dados, tal como foi reconhecido que a parametrização nunca foi concluída, facto este admitido, nomeadamente por «CC», Directora Geral da [SCom01...], e responsável pela gestão do contrato objecto dos presentes autos, desde Setembro de 2017.
No que respeita aos pedidos de helpdesk, também «BB» estimou tais pedidos no número de 143, referindo que todos os pedidos foram fechados, ou seja, confirmando, novamente e na convicção que se formou junto deste tribunal, que os pedidos podiam ser fechados, sem que tenham sido efectivamente resolvidos, indo assim ao encontro do depoimento prestado por «CC» e «DD».
Tanto «BB», como «AA», confirmaram que em Dezembro de 2018 houve uma acção de formação, a que se terá seguido um almoço, e não uma reunião onde tenham sido apontados defeitos ao software. Com efeito, a única testemunha da Ré a indicar tal facto foi «AA», pois que tanto «CC» como «DD» não conseguiram precisar no tempo a realização das reuniões.
No que respeita à ocorrência de uma reunião em Julho de 2019, todas as testemunhas, excepto «EE», pois não esteve presente, afirmaram que a mesma ocorreu e que foi nesta reunião que a Ré confrontou a Autora com uma lista de coisas que não estavam a funcionar, ou que estavam mal, e ainda com a alegação de perda de dados.
De sublinhar, ainda, que as testemunhas apresentadas pela Ré revelaram total desconhecimento do período que antecedeu a contratação do software da Autora, o que colocou, desde logo, em causa a sua credibilidade, nomeadamente no que respeita à interpretação que faziam do contrato e à imputação de responsabilidade à Autora pelo software em questão, pois que não acompanharam a negociação do contrato e a sua implementação.
Acresce que, o depoimento de «CC», de «DD» e de «AA»,
permitiu formar a este Tribunal a convicção de que o software era, de facto, de difícil utilização, mas a nenhum tempo foi assegurado pela Ré o cumprimento da sua obrigação de parametrização de dados. Não obstante a dificuldade de manuseamento do software, a testemunha «CC», responsável pela gestão deste contrato, afirmou de forma peremptória que, apesar de nunca ter tido qualquer formação por parte da Autora para trabalhar com o software, não carecia de formação especializada para o efeito, tendo sido suficiente a formação dada pelo seu antecessor «FF» e pelo Dr. «GG». Afirmação esta que coloca desde logo em causa o seu testemunho, por ser contraditório afirmar que a aplicação era de difícil utilização, mas para manuseá-la não carecia de nenhuma formação em específico.
Estas três testemunhas referiram que o software perdia dados, e daquilo que o tribunal conseguiu alcançar do confronto dos tickets de helpdesk com os depoimentos prestados pelas testemunhas, a alegada “perda de dados” (alegação esta que cumpre salientar ser conclusiva, e que por tal motivo não consta do probatório), reportava-se a diferentes tipos de situações, desde o dado inserido que não é visualizado porque a pessoa não tem permissões para esse efeito, conforme referido por «AA» (cf. ticket #906, facto 33 do probatório), ao dado inserido que não foi calculado porque não foi inserido no sítio correcto (cf. tickets #1034, 1039, 1043, facto 33 do probatório), ou então, à existência de uma actualização da aplicação que não permitiu o cálculo correcto dos dados (cf. ticket#1084, facto 33 do probatório).
Estas testemunhas também referiram que aplicação teria “bugs” ou erros, nomeadamente que após a introdução das fórmulas, a aplicação não as calculava correctamente, facto que foi reportado nos tickets de helpdesk # 1040, 1045, 1050 e 1084, do facto 33 do probatório. Tal como afirmaram que o software não permitia a extracção de relatórios para todos os indicadores da ERSAR, não obstante «CC» e «DD» terem referido que a parametrização de dados, da sua responsabilidade, não se encontrava concluída.
Mais, «DD» e «AA» avançaram que os relatórios, que se pretendiam dinâmicos, no sentido de permitirem o relacionamento dos dados introduzidos (como p.ex. colunas e anos a comparar), não correspondiam aos que eram disponibilizados pelo software, os quais eram estáticos, só sendo possível a produção de relatórios que estivessem previstos na plataforma. Referiram, ainda, que o pretendido com o software era a extracção de um relatório, no final do ano, para reporte à ERSAR de forma automática, funcionalidade esta que nunca foi disponibilizada. «AA» informou, ainda, que, pelo menos uma vez desde que o mesmo iniciou funções junto da [SCom01...], haviam procedido carregamento de todos os dados e, mesmo assim, o software [não]conseguiu gerar relatórios.
Os três culpabilizaram, assim, o software. Mais, concluíram «DD» e «AA» que face aos erros detectados, foram perdendo confiança no software.
Já «EE» prestou um depoimento com base no conhecimento indirecto dos problemas do software, tendo referido que observou, apenas, algumas das situações, nomeadamente a introdução de dados. Ainda assim, a testemunha de forma espontânea e informou os autos de que, ainda no ano de 2019, a [SCom01...] deixou de utilizar a ferramenta, porque mudaram de plataforma, algures no decurso desse ano, mas não conseguiu precisar. E que a partir de tal data, nunca mais recebeu pedidos de apoio na criação de utilizadores.»

Apreciemos, então, as questões acima enunciadas e vejamos o que concluir dessa apreciação quanto ao mérito do recurso e do objecto da acção.

1ª Questão
A sentença recorrida é nula quanto ao facto provado 33, nos termos do artigo 615º/nº 1 b) do CPC, por ausência de especificação sobre os fundamentos da selecção que aí é feita de pedidos de assistência ao serviço de helpdesk da Recorrida?

Dispõe a alínea b) do artigo 615º nº1 do CPC que a sentença é nula quando “não especifique os fundamentos de facto e de direito que justificam a decisão”.
Nos pontos 31 a 33 da enunciação da matéria de facto julgada provada decidiu-se jugar provado o seguinte, nos seguintes termos:
“31 - No decurso da relação contratual a Ré apresentou mais de uma centena de pedidos de assistência em helpdesk — cf. documento n.4, junto com a contestação, e documentos juntos a fls. 291 a 369 do SITAF, e prova testemunhal;
32. Os pedidos de assistência em helpdesk foram dados como fechados pela Autora — cf. documento n.° 4, junto com a contestação, e documentos juntos a fls. 291 a 369 do SITAF, e prova testemunhal;
33. Dentro dos pedidos de assistência em helpdesk, e com relevo para a presente causa, destacam-se os seguintes tickets:”
Segue-se uma selecção de “tickets” julgados relevantes.
Se bem entendemos, a Recorrente sustenta que a Mª Juiz a qua devia ter expressado as razões por que decidiu que estes e não outros tickets relevam para a decisão, daí a alegação de nulidade por falta da especificação de um fundamento de facto.
Nada temos a opor à concepção a uma nulidade parcial da sentença. Tão pouco alinhamos com quem defende que só uma absoluta falta de fundamentos de facto de toda a sentença integra a nulidade cominada na sobredita norma, quer porque ali não se fala de sentença, mas de decisão, quer porque esse, digamos, “maniqueismo interpretativo” deixaria sem a devida tutela o direito das partes a que sejam fundamentadas todas as decisões que as afectam (artigo 154º nº 1 do CPC).
Porém, não é o caso.
Na verdade, o que a Mª Juiz dá por provado é todos os pedidos constantes do documento nº 4 da contestação, e como prova disso invoca este documento, isto é, fundamenta essa decisão de facto com o documento. O facto de “destacar” alguns dos pedidos e os transcrever de modo nenhum significa que os outros, constantes do documento, não estejam adquiridos para a matéria de facto, como provados, e não possam ser esgrimidos pela recorrente como fundamentação do juízo que pretende fazer sobre o mérito da sentença.
Como assim, a alegação de nulidade da sentença com o sobredito fundamento improcede.

2ª Questão
A sentença recorrida violou o artigo 94º nº 3 do CPTA, pois, quanto a matéria de facto não provada, apenas mencionou que “a restante matéria alegada pelas partes não foi julgada indiciariamente provada ou não provada, por constituir conceito de direito, matéria conclusiva ou não relevar para a decisão da causa”, com o que deixou de se pronunciar – no sentido de não ter sido produzida qualquer prova, pois nada foi apurado a este propósito – quanto aos temas de prova 1; 2 a), b), e); 3 c), e); 4; 5; 6; 8 b), todos relativos a factualidade alegada pela Recorrida?

Tão pouco nesta alegação a Recorrente explicita a sanção do Direito para a alegada omissão.
Nos termos da alª d) do nº 1 do artigo 615º do CPC, a sentença é nula quando “O juiz deixe de pronunciar-se sobre questões que devesse apreciar ou conheça de questões de que não podia tomar conhecimento.”
Porém, a aplicação desta norma in casu está prejudicada por uma doutrina, tão vetusta, quão dominante Referimo-nos, à doutrina, recebida uniformemente na jurisprudência, que Alberto dos Reis, expressou no seu Código de Processo civil Anotado, Coimbra Editora, reimpressão em 1984 de um original publicado entre 1948 e 1951, V volume, paginas 137, 139 e 151, de que, em suma, a nulidade da sentença por omissão de pronúncia sobre questões que o juiz devesse apreciar só ocorre quando o mesmo não se pronuncia sobre pedidos, causas de pedir e excepções invocadas., sobre o conceito de “questões” nela empregue, a qual prejudica que se possa considerar “questão” para efeitos da sobredita norma, a “questão de facto” que na verdade é a pergunta sobre a prova de um facto. Em tal pressuposto, esta alegada omissão de pronúncia, não é sancionada por aquela norma.
Não vemos que a omissão de pronúncia sobre a prova de factos que deviam ser considerados possa reconduzir-se a erro no julgamento em matéria de facto. Do que se trata, numa omissão de pronúncia, é de um não julgamento, pelo que tão pouco tem sentido falar em erro de julgamento.
Ocorre, então, para sancionar a omissão, recorrer à já citada alínea b) do nº 1 do mesmo artigo 615º, no sentido de que a omissão de pronúncia sobre factos alegados e relevantes para a decisão sempre resulta numa omissão, pelo menos parcial, da “especificação” de fundamentos de facto da sentença, que dita a nulidade parcial e ou total da mesma, consoante a omisso bula com todo ou apenas parte do julgamento do objecto da causa.
Assim, convimos em que o que a Recorrente argúi, na alegação subjacente a esta questão, é uma nulidade da sentença, nos termos do artigo 615º nº 1 alª b) do CPC, por falta de especificação de fundamentos de facto da sentença, pelo que a questão sub judito tem, em ultimo termo por objecto, a nulidade da sentença por omissão de pronuncia sobre os temas da prova acima especificados.
Posto isto, vejamos se procede:
Esta questão labora no pressuposto de que o objecto da decisão da matéria de facto são os temas de prova enunciados a seguir ao despacho saneador, conforme o disposto no artigo 596º do CPC.
Não é assim: objecto da decisão em matéria de facto são, conforme o artigo 5º nº 1 e 2 do CPC os factos alegados pelas partes e relevantes para a apreciação da causa em alguma da das soluções plausíveis, bem como os factos instrumentais e os factos que sejam complemento ou concretização dos que as partes hajam alegado e resultem da instrução da causa, desde que sobre eles – isto é, sobre a sua atendibilidade e sobre a sua prova, tenham tido a possibilidade de se pronunciar.
Os temas da prova são apenas um instrumento processual instrutório que permite mencionar mais ou menos genericamente a matéria de facto julgada relevante e controvertida e, a contrario sensu, a julgada já assente. Não se substituem aos factos individuais e concretos em que a pretensões das partes não podem deixar de assentar (da mihi facto dabo tibi jus), conforme artigo 5º do CPC.
Assim, a omissão de pronúncia sobre factos susceptíveis de relevarem para qualquer das soluções plausíveis da causa, designadamente as sustentadas por qualquer das partes só corre relativamente a factos alegados e instrumentais ou complementares dos alegados, se reunidas as sobreditas condições para serem atendíveis.
Ora, a recorrente não concretiza quaisquer factos alegados (quanto aos instrumentais ou complementares a alegação está prejudicada dado que sustenta que não se produziu qualquer prova relativamente aos principais), que devessem ter sido seleccionados como relevantes para alguma das soluções plausíveis da lide, e não provados. Desta feita deixa infundamentada a sua alegação de nulidade da sentença por omissão de pronúncia em matéria de facto.
A matéria da nulidade da sentença não é de conhecimento oficioso, a não ser no caso da falta de assinatura do juiz: tal é o que decorre da conjugação dos nº 4 do mesmo artigo 615º com o artigo 196º do mesmo código, pelo que não nos cumpre apreciar causas de nulidade diversas do alegado pela Recorrente.
Assim, a resposta a presente questão é negativa.

3ª Questão
A sentença recorrida erra no julgamento em matéria de facto, quanto ao facto provado 31, porquanto, na redacção, não deu como provado que a recorrente começou a invocar defeitos logo em 11/8/2017, data do primeiro pedido de assistência em Helpdesk “e continuou pelos anos de 2018 e 2019”, conforme documentos juntos com a Réplica, e os pedidos de assistência foram mais de cento e trinta, conforme resulta da conjugação do próprios depoimento da testemunha «AA», invocado na sentença o qual apontou 137 pedidos, e «BB», que apontou 143,tudo por que este ponto da matéria de facto provado deve ser reformulado, nos seguintes termos:
No decurso da relação contratual, concretamente a partir de 11 de Agosto de 2017, a Ré apresentou mais de cento e trinta pedidos de assistência em helpdesk.”?

Recordemos o teor do facto 31:
No decurso da relação contratual a Ré apresentou mais de uma centena de pedidos de assistência em helpdesk — cf. documento n.04, junto com a contestação, e documentos juntos a fls. 291 a 369 do SITAF, e prova testemunhal;
A Recorrente alega que “A Mma. Juiz "a quo" não atentou nos documentos juntos pela Recorrida na sua réplica, surgindo o primeiro pedido de assistência em helpdesk em 11.08.2017, ou seja, ao fim de nove meses de vigência do contrato,” e que, conforme a, a prova testemunhal invocada na mesma sentença, “a testemunha «AA» apontou 137 pedidos (pág. 33 da sentença) e a testemunha «BB» apontou 143 pedidos”, de tudo o que resultava deverem ser julgado provados os termos por si desta feita propostos.
Julgamos que desta feita cumpre com os ónus que decorrem do artigo 640º do CPC para o recorrente em matéria de facto, porque os documentos estão individualizáveis e a prova testemunhal vem invocada nos próprios termos em que foi referida na fundamentação de facto da sentença recorrida, pelo que cumpre apreciar e decidir subre esta alegação.
Quanto ao número de pedidos de apoio da helpdesck, é certo que é mais densa, a redacção da Recorrente. Porém, visitada a contestação, verificamos que o que vem alegado neste articulado é tão só e precisamente que a Ré apresentou “mais de cem pedidos de assistência” (cf. artigo 10ª da contestação). À Mª Juiz a qua cumpria cingir-se quantitativamente ao alegado, segundo o principio do dispositivo e o disposto no artigo 5º nº 1 do CPC. Nesta parte, portanto, a pretensão da recorrente não procede. Quanto ao início dos pedidos, trata-se de uma densificação relevante, do ponto de vista da Recorrente, que pretende demonstrar, com ela, que é errado o juízo da sentença recorrida, constante da discussão de direito, de que só em 2019, decorridos 3 anos da data de início do contrato, é que a Recorrente invocou a existência de defeitos, e que não ultrapassa o âmbito do alegado. A prova documental do facto é bastante, pois trata-se de documentos não impugnados. Como assim, é de atender, nesta parte, a pretensão da recorrente, pelo que o facto provado 31, passa a ter a redacção seguinte:
31 - “No decurso da relação contratual, concretamente a partir de 11 de Agosto de 2017, a Ré apresentou mais de uma centena de pedidos de assistência em helpdesk.”

4ª questão
Considerando que, ao contrário do afirmado na sentença recorrida, a alegação de “perda de dados”, é uma alegação de facto, e atentas passagens dos depoimentos das testemunhas «CC», «DD» e «AA», conjugadas com os documentos da oposição, conjugadas com os documentos juntos com a oposição ao requerimento de injunção, cumpria especificar e julgar como provados – e há agora que aditar à matéria de facto provada, nos termos do artigo 149º do CPA e do artigo 640º nºs 1 e 2 do CPC, os seguintes factos:
- Facto 39: O software não produz relatórios para a ERSAR.
- Facto 40: O módulo SIADAP não funciona.
- Facto 41: Entre 2017 e 2019, em inúmeras ocasiões de aplicação e funcionamento de fórmulas matemáticas, o software gerou resultados errados - por exemplo, ticket 907, ticket 1040, ticket 1045, ticket 1052, constantes do doc. n° 4 junto com a oposição.
- Facto 42: O software não permite o interface com outras aplicações, nomeadamente webservices e API's.
- Facto 43: Entre 2017 e 2019, em inúmeras ocasiões os utilizadores introduziram dados no software e no dia seguinte, fosse por consequência de actualizações, fosse por outras causas, os mesmos perderam-se - por exemplo, ticket 1050, ticket 1084, constantes do doc. n° 4 junto com a oposição.

A) Discussão da questão
Posto que iuris novit curia (artigo 5º nº 3 do CPC) diremos, antes de mais, em conformidade com o já exposto a propósito da 2ª questão, que a Recorrente alega aqui uma falta de especificação de factos atendíveis e relevantes para a decisão da causa a seu contento, falta que, em nosso entender, é juridicamente sancionada com nulidade da sentença nos termos do artigo 615º nº 1 alª b) do CPC.
Assim, retomando o disposto no nº 1 do artigo 5º do CPC – e tendo presente, ainda, o princípio da aquisição processual – importa, antes de mais, averiguar se os factos alegadamente em falta na decisão recorrida são matéria de facto e, se sim, se estão por algum modo alegados el algum dos articulados.
Ora:
Os “factos” 41e 43, em tudo o que vai para além dos “exemplos” enunciados, não podem, in casu, ser tratados como matéria de facto, pois a sua descrição é irredutivelmente conclusiva em toda a medida em que não identificam nem situam, concretamente no tempo os demais “inúmeros”, episódios referidos, pelo que apenas consideraremos alegado como estando em falta a menção, como provados, dos factos exemplo ali citados.
Assim, o facto 41 em falta seria:
Os ticket 907, ticket 1040, ticket 1045 e ticket 1052, constantes do doc. n° 4 junto com a oposição, tiveram como objecto a aplicação e o funcionamento de fórmulas matemáticas, em que o software gerou resultados errados.
O facto 43, seria:
Os ticket 1050 e ticket 1084, constantes do doc. n° 4 junto com a oposição tem por objecto episódios em que os utilizadores introduziram dados no software e no dia seguinte, fosse por consequência de actualizações, fosse por outras causas, os mesmos perderam-se.
Os demais propostos artigos esgotam-se em factos concretos.
Vejamos, então, se a factualidade supra, assim expurgada da matéria espúria, foi alegada, pelas mesmas ou por ouras palavras ou proposições.
Lida a Contestação, deparamos, nos artigos 15 a 18, com a alegação de que a Ré enviou uma carta à Autora, em 20/8/2019, na qual elencava as situações por solucionar quase três anos depois do contrato se ter iniciado (cf. doc. nº 5 junto com a oposição a injunção) na qual, além do mais, se a apontavaque por força de actualizações da aplicação perderam-se inúmeros dados”.
Trata-se, aqui também, de uma proposição irredutivelmente conclusiva, por isso que não situa no tempo nem individualiza um só dado ou conjunto de dados e o fenómeno do seu desaparecimento informático. Assim, esta alegação não pode assimilar-se ao facto 43, apesar de ele consistir num episódio de perda de dados. Não se diga que se trata de um facto concretizador daquela alegação, para os efeitos do nº 2 alª b) do artigo 5º do CPC. Desde logo, a relação de concretização prevista pela norma, é, expressamente, entre factos, não entre juízos e factos, depois, e sobretudo, nada na acta da audiência final ou no demais processado permite ter por certo, nem a Recorrente o alega, que a Autora tenha sido advertida da intenção da Ré de se valer deste facto concreto, de maneira a pronunciar-se sobre a prova do mesmo e a sua atendibilidade e os seus efeitos jurídicos.
Naturalmente, tão pouco na réplica e na Petição se encontra qualquer alegação desse proposto facto concreto 43.
Assim, o proposto facto 43 não integra matéria de facto atendível pela sentença recorrida.
A mesma carta referida nos artigos 16º e seguintes da contestação contém a seguinte referência a erros: “(…) foram identificados erros no cálculo e nas fórmulas, retirando a credibilidade e confiança nas centenas de indicadores resultantes de cálculos, não cumprindo o requisito” (cf. alínea B).1 do artigo 16º).
Por outro lado, no próprio articulado deparamos com a seguinte alusão:
“24. O facto é que à data de hoje nenhum dos departamentos da Ré consegue trabalhar com o Sistema, pois continuam diariamente a verificar-se erros e anomalias várias, conforme informação prestada na passada semana na sequência de pedido de ponto de situação solicitado pelo Conselho de Administração”.
(…)
33. A Directora-Geral informou que para extrair os dados do Aquaperformance solicitou na aplicação um ficheiro de excel, que não foi gerado, exibindo erro; colocou um ticket para obter resposta ao erro gerado, tendo sido respondido que havia falha na configuração no novo ambiente; detectou ainda "bugs" no novo ambiente relativos a dados.”
As alegações correspondentes ao artigo 16º B) -1 e ao artigo 24º da contestação são irredutivelmente conclusivas, pelos mesmos motivos já desenvolvidos a propósito do proposto facto provado 43, e por isso inaproveitáveis como alegação de facto assimilável no proposto facto provado 41. Já a do artigo 33, embora trate de um facto concreto, de comum com o proposto facto 41 apenas tem o emprego de um substantivo da mesma família etimológica do particípio “errado”. Os factos em causa são de natureza diversa: enquanto no proposto facto 41 se trata de resultados obtidos, mas errados, no artigo 33 da contestação trata-se de um não resultado: “solicitou na aplicação um ficheiro de excel, que não foi gerado, exibindo erro”.
Nos demais articulados – que são a PI e a Réplica – também se não topa com a alegação de quejando facto.
Pelo exposto, tão pouco o proposto facto 41 tinha de ser atendido na decisão recorrida.
Restam os propostos factos provados 39, 40 e 42.
Comecemos pelo 39:
Na contestação deparamos apenas com a seguintes alegação de facto susceptível de apreciação deste ponto de vista.
Artigo 25: O Departamento de Engenharia informou que (…) mantém-se a questão da falta de ajustamento ao modelo de dados existente no SIG e dos dados de reporte ao ERSAR; e nos últimos dois meses tem tido dificuldade em carregar uma parte da informação (tabelas ERSAR AA, AR e RU).
Trata-se de uma afirmação genérica e com objecto cronologicamente difuso, por isso insusceptível, também ela, de um juízo de prova. Não sabemos que factos concretos integram a falta de ajustamento ao modelo de dados existente na SIG e quando e quem teve dificuldade, devido a tal, em carregar arte da informação – aliás, que parte, de que informação?
Assim, pelas mesmas razões expostas a propósito dos factos propostos 41 e 43, esta alegação não é susceptível de ser assimilada como alegação do proposto facto 39.
Vejamos o proposto facto 40:
Na carta alegada e transcrita no artigo 16º da contestação consta o seguinte.
“A) Funcionalidades que o Sistema não executa:
1. “Solução Web descentralizada de avaliação, com suporte para o SIADAP, com
autenticação integrada sobre uma Active Directory e com suporte para multientidade na mesma instância da aplicação: não se identificou a existência do suporte para SIADAP.”
Tal transcrição da carta, embora não seja um facto directamente alegado é-o mediatamente, pelo que pode considerar-se como alegação do facto, a bem de uma apreciação do fundo da causa.
O proposto facto 39 é-lhe assimilável, sendo certo que releva, pelo menos do ponto de vista da Ré, para a tese deste, de que lhe assiste o direito a socorrer-se da “exceptio non adimpleti”.
Assim sendo, julgamos que está em falta na sentença uma pronúncia sobre a prova de tal facto, se bem que se imponha preservar os termos em que é referido na contestação.
Havia, portanto, que emitir pronúncia sobre a prova ou não prova do seguinte facto:
O Sistema não executa:
1. “Solução Web descentralizada de avaliação, com suporte para o SIADAP, com autenticação integrada sobre uma Active Directory e com suporte para multientidade na mesma instância da aplicação: não existindo o suporte para SIADAP.”
Por fim, vejamos o proposto facto 42:
O software não permite a interface com outras aplicações, nomeadamente webservices e API's.”
Percorrida toda a contestação não deparamos com alegação deste facto. Apenas se alegou (e provou) que o contrato previa que o sistema a fornecer “disponibiliza(.) uma interface web baseada em HTML 5 que permita visualizar a performance das várias unidades orgânicas e das respectivas acções, nomeadamente visualizar os indicadores e sua fórmula de cálculo, dependendo das permissões dos colaboradores.
- O produto deve ser disponibilizado em regime de ASP suportado na plataforma AZURE da Microsoft."
Assim sendo, tão pouco este facto podia ser atendido na sentença recorrida.
Como vimos, impunha-se seleccionar, como alegado e relevante, o proposto facto 40, e uma decisão sobre a sua prova ou não prova, pelo que, nessa medida importa declarar nula a sentença, nos termos do artigo 615º nº 1 alª b) do CPC – cf. supra - devido a essa omissão.
Ora:
B) - Cumprimento do artigo 149º nº 1 do CPTA quanto ao facto omisso
Dispõe, o nº 1 do artigo 149º do CPTA, que “ainda que declare nula a sentença, o tribunal de recurso não deixa de decidir o objecto da causa, conhecendo de facto e direito”.
Há que dar cumprimento a este comando.
Trata-se da versão “processual administrativa” do julgamento em “substituição ao tribunal recorrido”, também preconizada no CPC, actualmente no artigo 665º, se bem que em termos não totalmente sobreponíveis, seja literal, seja semanticamente.
Desde logo, o nº 1 do artigo 665º do CPC, à semelhança do que já dispunha, na última e em anteriores redacções, o artigo 715º do código anterior, prevê que, “ainda que declare nula a decisão que põe termo ao processo, o tribunal de recurso deve conhecer do objecto da apelação”.
Comparando a literalidade das duas normas, verifica-se que a norma do CPTA manda conhecer do “objecto da causa”, enquanto a do CPC manda conhecer do “objecto da apelação”. Depois, passando à totalidade de cada artigo, enquanto o CPC, indiscriminadamente, manda que o tribunal de recurso, antes de decidir em substituição, dê contraditório às partes, o CPTA, evitando a redundância em que aquele comando indiscriminado pode resultar, especifica o dever de contraditório apenas relativamente aos casos em que haja que produzir e tenha sido produzida nova prova.
Considerando que a norma do CPC – melhor, a norma correspondente do antigo CPC – é anterior à do CPTA, mesmo na versão original desta (Lei nº 15/2002 de 22/2), dir-se-ia resultar, da saliente diferença entre as redacção dos nºs 1 dos dois artigos, que, enquanto a do CPC (“deve conhecer do objecto da apelação”) – impunha ao tribunal de recurso conhecer das demais questões, designadamente as de mérito, suscitadas no recurso, já o legislador do CPTA quis outrossim, demarcando-se daquela opção legislativa, impor ao tribunal de recurso que conhecesse do objecto da acção, ab initio e ex novo, como que num “reset” da fase processual da elaboração da sentença.
Julgamos, porém, ante a epígrafe do artigo do CPC - “substituição ao tribunal recorrido” – e os termos do seu nº 2, que referem, deste feita claramente, uma autêntico julgamento inicial de questões não apreciadas pelo tribunal a quo, que o legislador processual civil quis, essencialmente, que o tribunal de recurso conhecesse do mérito do recurso e ou da causa, fosse criticando a sentença declarada nula abstraindo disso ou aproveitando uma parte não inquinada pelo vicio, disso susceptível, a partir de outros fundamentos do recurso (nº 1 do artigo 665º), fosse apreciando ex novo as questões eventualmente silenciadas na sentença recorrida (nº 2).
Assim sendo, o nº 1 do artigo 149º do CPTA, quando se refere ao dever do tribunal de recuso de “decidir o objecto da causa (…) de facto e de direito” não diverge substancialmente do nº 1 do artigo 665º do CPC, antes apresenta uma disposição mais clara naquele mesmo sentido de, materialmente, o objecto a apreciar ser o mérito e da causa, em função do recurso, mediante a substituição do tribunal a quo pelo ad quem no exercício de uma competência que, em regra, é apenas do substituído, sem prejuízo de, onde a sentença recorrida for aproveitável no sentido de não ter de se produzir uma nova sentença, assim se haver de fazer.
Ora:
A causa da nulidade que acima surpreendemos na sentença recorrida reside na falta de especificação, como provado ou não provado, de um único facto. Não contende com a restante decisão de facto. Tão pouco se nos mostra necessário, para o julgamento da causa nos termos do artigo 149º nº 1 do CPTA, alterar a decisão em matéria de facto, salvo a devida apreciação da prova quanto ao facto em falta.
Assim, supriremos a nulidade da sentença pronunciando-nos sobre a questão da prova do proposto facto 40, alterando, desta feita e por este modo a decisão em matéria de facto.
Vejamos, então:
Tratando-se de suprir uma omissão de julgamento em matéria de facto, e não da impugnação de um juízo probatório tido por errado, não ocorre, in casu, considerar os ónus que o artigo 640º do CPC faz impender sobre o impugnante do decidido em matéria de facto.
Há, isso sim, que julgar, já que o tribunal recorrido não o fez, se o proposto facto provado, acima “redigido” ficou provado, isto é, se ficou provado que o sistema fornecido pela Autora aa Ré não executava uma “Solução Web descentralizada de avaliação, com suporte para o SIADAP, com autenticação integrada sobre uma Active Directory e com suporte para multientidade na mesma instância da aplicação: não existindo o suporte para SIADAP.
A recorrente invoca, indiscriminadamente, para todos os propostos factos, passagens transcritas dos depoimentos das três testemunhas indicadas, ou sejam, as testemunhas «CC», «DD», «AA».
Quanto ao modulo SIADAP apenas o depoimento daquele último se lhe refere: A avaliação do SIADAP, o sistema de avaliação da função pública, não funcionava
Tal meio de prova, além de retratar a convicção de uma simples testemunha sobre um objecto técnico, procede de um trabalhador dependente da Ré, pelo que o julgamos insuficiente para o facto ser julgado como provado.
Porém, do teor das comunicações entre as partes, transcritas nos factos provado 28 e 29, designadamente, do ponto 1 da comunicação (da Autora para o Reu,) embora resulte um desacordo das partes quanto à existência do suporte SIADAP, é possível concluir que a própria Autora aceitava que em de 20 de Agosto de 2019 o sistema ainda não executava a Solução Web descentralizada de avaliação, com suporte para o SIADAP, com autenticação integrada sobre uma Active Directory e com suporte para multientidade na mesma instância da aplicação. Com efeito, o autor da missiva da autora admite isso mesmo, posto que imputando as causas aa Ré e alegando que as configurações necessárias para a execução não faziam parte da proposta adjudicada.
Assim, aos factos julgados provados e relevantes para a decisão da causa este Tribunal adita o seguinte:
39 – À data de 20/8/2019 o sistema fornecido pela Autora ainda não executava a Solução Web descentralizada de avaliação, com suporte para o SIADAP, com autenticação integrada sobre uma Active Directory e com suporte para multientidade na mesma instância da aplicação.

5ª Questão (objecto da ampliação do recurso)
Cumpria especificar e julgar como provados, na sentença recorrida – e há agora que aditar à matéria de facto provada, como provados, os “factos” descritos sob os nºs 39 a 56 na conclusão 29 das contra-alegações da Recorrida?

Recordemo-los:
«Facto 39
Desde 15.06.2015 que a [SCom01...]/Recorrente vinha analisando os programas informáticos (mais tarde adquiridos), transmitindo as suas necessidades, experimentando o programa, desenhando a configuração do mesmo, conforme atestam as comunicações juntas, as reuniões havidas, as acções de formação prévia, as opções e orientações dadas pela [SCom01...]/Recorrente.
Facto 40
A [SCom01...] não tomou decisões e opções fundamentais à implementação do projecto.
Facto 41
Em Dezembro de 2018, a [SCom01...] ainda estava a dar formação aos seus colaboradores.
Facto 42
Em Dezembro de 2018, a [SCom01...] ainda estava a planear a implementação do software.
Facto 43
Em Dezembro de 2018, a [SCom01...] nomeou um líder de projecto, Eng. «EE».
Facto 44
Em Julho de 2019, quando a [SCom01...] convoca uma reunião, nesse momento estava uma factura por pagar.
Facto 45
O programa SIADP estava disponível para a Recorrente, fazendo do programa adquirido.
Facto 46
A [SCom01...] nunca solicitou a implementação do SIADAP.
Facto 47
Em Maio de 2019 a [SCom01...] reconhecia que ainda não tinha conseguido implementar o software.
Facto 48
Em 10.07.2019 a [SCom01...] convoca uma reunião para alinhamento do sistema com o CE, proposta e contrato; desenvolvimento e actualizações do sistema.
Facto 49
Em Agosto de 2019, durante uma reunião, a Directora Geral «CC» invoca que se tinham perdido dados e o colaborador da Recorrida, abrindo o computador, demonstrou que os dados estavam na plataforma, não se tinham perdidos, e que apenas estavam consultáveis noutra permissão.
Facto 50
A Directora Geral «CC» não sabia aceder a determinadas áreas da plataforma.
Facto 51
Quem definia as fórmulas de cálculo era a [SCom01...].
Facto 52
A [SCom01...] definiu erradamente fórmulas que geraram erros de cálculo.
Facto 53
A [SCom01...] solicitou e obteve novas funcionalidades da Recorrida, sem qualquer tipo de acréscimo ou custo para a Recorrente.
Facto 54
A [SCom02...] ao longo do contrato teve que assegurar encargos com servidores e plataformas da Microsoft.
Facto 55
O programa de software objecto do contrato sempre permitiu elaborar e apresentar os ficheiros de indicadores exigidos pelo regulador ERSAR.» 

Antes de mais, dá-se aqui por reproduzido tudo o que expôs na discussão da anterior questão quanto à qualificação jurídica da alegação de falta de especificação de facto atendíveis, quanto à precedência lógica da questão de saber se determinados factos foram omissos e essa outra de saber se foram provados, quanto à irrelevância, para estas questões, dos ónus dispostos, para o recorrente, no artigo 640º nºs 1 e 2 do CPC e quanto à necessidade de se tratar de matéria atendível nos termos dos nºs1 e 2 do artigo 5º do CPC e de factos concretos, não de alegações difusas ou genéricas, ainda que sobre matéria não jurídica.
Importa ainda frisar que não se verifica a omissão da especificação como provado ou não provado de um facto cuja prova ou não prova resulte logicamente da prova ou da não prova de outro ou outros, seja por prejudicialidade, seja por necessidade.
Posto isto, vejamos, antes de mais, se e que artigos desta feita alegadamente omissos não são verdadeiramente matéria de facto.
É isso que acontece com o facto 39 (trata-se de uma conclusão sobre factos concretos (pedidos, programas, reuniões que não se concretiza no número nem se situa no tempo), 40 (não sabemos que decisões e opções seriam essas que em concreto se impunha tomar), 42 (não sabemos quais acções e procedimentos concretos, de que órgãos ou colaboradores da [SCom01...] integravam esta actividade de planear a implementação do software, 47 (afirmação insuprivelmente conclusiva: não sabemos por que declarações, de quem, dirigidas a quem, é que o suposto reconhecimento se deu), 50 (a alegação é conclusiva porque não são concretizadas as áreas da plataforma a que, alegadamente, a directora geral «CC» não sabia aceder) 52 (trata-se de uma afirmação genérica e difusa, não sabemos quando, quantas vezes e que fórmulas, definidas pela [SCom01...], geraram erros de cálculo), 53 (novamente uma afirmação genérica e geral e abstracta: não sabemos quando e quais novas funcionalidades a [SCom01...] solicitou e obteve da Recorrida sem qualquer tipo de acréscimo ou custo para a si, 54 (afirmação conclusiva e genérica: não sabemos que encargos, pecuniários teve a Autora [SCom02...] que assegurar e em que consistiam – que pagamentos fez e a quem?
Tanto basta para estes putativos factos não estarem omissos e, logo, não terem de nem poderem ser aditados à decisão de facto, seja como provados, seja com não provados.
Vejamos, agora, se e quais das restantes proposições pretensamente omissas, apesar de serem matéria de facto, o não estão, seja porque a sua prova está prejudicada por outra, seja por que a sua prova é uma mera decorrência a lógica da prova de factos julgados como tal.
Note-se, a este propósito, que a Requerente da ampliação do recurso não impugnou qualquer item da decisão em matéria de facto, quer dizer, conformou-se com o julgamento como provados de todos os factos dados como tal na sentença recorrida, que, portanto, não está em causa.
Tal sucede com o facto 44 (é algo que decorre logica e cronologicamente dos factos provados 18 e 19 e do pedido de injunção que está na origem desta acção administrativa; com o facto 45 (está prejudicado pela prova do facto 39, já aditado por este tribunal à matéria de facto (cf. supra), com a motivação acima exposta;
Sobram os factos contidos nos propostos artigos 41, 43, 46, 48, 49 e 51.
Vejamos se foram alegados, seja na Petição, seja na Réplica.
No artigo 75º da réplica a Autora alegou, a título de exemplo do alegado em 74, o seguinte:
“ a. Se as máquinas de software tem uma funcionalidade (SIADAP ou o Cubo) que, ao longo de 3 anos, a Ré nunca configurou nem utilizou, estranho é que em Agosto de 2018, no último ano do contrato, se venha a lembrar da sua existência.
Esta afirmação, porém, não é coincidente nem mesmo assimilável a essa outra do proposto “Facto 46: A [SCom01...] nunca solicitou a implementação do SIADAP”, pois ali dava-se por pressuposto que a Ré podia configurar e implementar por si só a funcionalidade SIADAP, enquanto aqui se supõe que isso carecia da intervenção da Autora, carência que os factos provados vieram a confirmar (factos provados 38 e 39).
No artigo 75º alª g) da Réplica, a Autora alegou que “g. É à Ré que cabe fixar as fórmulas dos indicadores (num universo de 563) com 1308 variáveis”. Esta alegação, embora contenha um juízo sobre a quem cabia, também contém a afirmação de que era a Ré quem fixava as fórmulas dos indicadores, pelo que lhe é assimilável a alegação do proposto facto 51.
Quanto aos demais sobreditos factos não se topa, seja na PI, seja na réplica a menor referência, quer nominal, quer semântica.
Atento tudo até aqui exposto, a resposta à primeira dimensão da questão em análise é afirmativa apenas no tocante ao proposto facto 51, sendo negativa quanto a todos os demais.
Quer dizer (cf. supra), a sentença recorrida padece de nulidade nos termos do artigo 615º nº1 alª b) do CPC também por omissão de especificação, como provado ou não provado, do seguinte facto:
Quem definia as fórmulas de cálculo era a [SCom01...]
Cumpre, então, nos pressupostos ab initio anunciados por remissão para a discussão da 4ª questão, apreciar se tal facto se provou.
A Requerente invoca a prova testemunhal. Já vimo que não se lhe aplica o artigo 640º do CPC.
Reproduzida a prova testemunhal, verificamos que apenas a testemunha «AA», colaborador da A, a pergunta feita - Quem é que define as fórmulas? – respondeu: É a [SCom01...], claro, normalmente nós ajudamos, mas não, nunca— mas não, erros de cálculo não, isso não é possível. A este elemento acresce um documental: no email de Dezembro de 2018, constante do Doc. de páginas 273 do SITAF e transcrito no corpo das contra-alegações (parágrafo 18), o mesmo «AA» escreve, entre o mais, o seguinte a colaboradores da Ré:
“(…)
Assim, vemos as seguintes tarefas como necessárias:
- Colocação da fórmula de cálculo das variáveis de 3a geração a partir das tabelas de reporte à ERSAR apenas a partir de 2019. Colocar estas, antes de 2019, a serem calculadas (para correcções de histórico) a partir dos dados já inseridos no módulo ERSAR 2G;
- Carregamento/cálculo do histórico das variáveis de 3a geração;
- Execução de procedimento de alteração de todos os indicadores, incluindo os indicadores da ERSAR de 2a geração, para que estes passem a utilizar as variáveis de 3a geração, em vez das de 2a geração;
- As variáveis de 2a geração que não existem na 3a geração poderão mudar de nome, passando a ser variáveis dAGR (é uma sugestão, não uma obrigação), e passarão a ser carregadas como as restantes variáveis, pela sua medição directa na área indicada durante a formação da semana passada;
- Eliminação das variáveis de 2a geração não utilizadas.
Agradecemos os Vossos comentários para que possamos planear e implementar os procedimentos necessários à execução de estas alterações, para que a partir do dia 21 de Janeiro, como foi sugerido por Vós, sejam executados.
Atentamente,
O trecho por nós sublinhado labora num pressuposto consensual de que a elaboração das fórmulas era tarefa atribuída pelas partes, pelo menos tacitamente, à Ré e por ela adesempenhada.
Da conjugação destes dois elementos, sem que nada os contradiga, julgamos que resulta provado o seguinte facto, a que se atribui, desta feita, o nº 40:
“Quem definia as fórmulas era a [SCom01...], normalmente com a ajuda dos colaboradores da Autora.”

6ª Questão
Em face da matéria de facto resultante das respostas às questões antecedentes, e mesmo tão só em face dos factos dados como provados na sentença recorrida, impõe-se concluir que a mesma incorre em erro no julgamento de direito, pois estavam reunidos os pressupostos da invocação, pela Recorrente, da excepção de não cumprimento do contrato, consagrada no artigo 428º nº 1 do CCivil?

Em ordem à resposta afirmativa a esta questão, a recorrente alega que, como afinal se provou, os pedidos de assistência da Ré começaram logo em Agosto de 2017 e não apenas três anos depois do inicio da execução do contrato, como erradamente se menciona na sentença; que a Recorrida não cumpriu pontualmente com as obrigações decorrentes do contrato firmado com a Recorrente, por aplicação do disposto na sua cláusula 5ª n° 1 e cláusulas 1ª e 16ª do caderno de encargos (por remissão) e não cumpriu de forma constante, ao longo de 3 anos, com o contratualmente acordado (não tendo o software funcionado com todas as funcionalidades previstas em sede de contrato e caderno de encargos)”; que atentos os demais factos provados, designadamente que, do preço do contrato, € 161.916,00 (sem IVA), a ser pago em 5 prestações anuais, já estão pagos 69 216, € (45%), conforme factos 10, 12, 18, 36 e 37, ao longo de três anos a Recorrente submeteu mais de cem pedidos de assistência em helpdesk (cf. factos provados 31 a 33) e o software não produz relatórios dinâmicos (cf. facto provado 34), funcionalidade prevista em caderno de encargos, algo sério e consistente se passava com o funcionamento do software, tendo feito com que a Recorrente efectuasse, em Agosto de 2019, uma interpelação à Recorrida a fixar um prazo para a eliminação dos defeitos.
A fundamentação de direito da sentença recorrida, à parte as considerações sobre a natureza do contrato e o instituto da exceptio, é redutível ao seguinte excerto:
“Apesar de não resultar da factualidade provada, não resulta posto em causa, em nenhum tempo, que o software não tenha sido fornecido, instalado e colocado em funcionamento. Pelo que esta obrigação principal foi cumprida pela Autora.
Todavia, invoca a Ré o cumprimento defeituoso da prestação da Autora, por o software não cumprir com as funcionalidades contratualizadas. A excepção de não cumprimento do contrato surge regulada nos artigos 428.° e seguintes, do Código Civil, e é uma excepção peremptória de direito material, que tem em vista assegurar o equilíbrio das prestações contratuais, pelo que é invocável, por regra, nos contratos bilaterais, perante situações de incumprimento ou de cumprimento defeituoso.
O n.° 1, do artigo 428.°, do Código Civil, prescreve que “Se nos contratos bilaterais não houver prados diferentes para o cumprimento das prestações, cada um dos contraentes tem a faculdade de recusar a sua prestação enquanto o outro não efectuar a que lhe cabe ou não oferecer o seu cumprimento simultâneo.”
Pelo que, importa averiguar se as prestações em causa nos presentes autos são, ou não, o sinalagma uma da outra.
Conforme foi já referido, a obrigação principal da Autora, é a de fornecer, instalar e colocar em funcionamento o Sistema Integrado de Gestão de Performance, com Balanced Scorecard, Portfólio de Indicadores Operacionais baseados no IWA, Portfólio de Indicadores ERSAR e Plano de Actividades, e é obrigação acessória assegurar a manutenção evolutiva da ferramenta, bem como a assistência em helpdesk (fr. cláusula 4.a do Caderno de Encargos, facto 10 do probatório).
Por sua vez, é obrigação da Ré, pagar o preço contratual. De acordo com a cláusula 3.a do contrato celebrado, o preço deve ser pago em cinco prestações anuais, no prazo máximo de 30 dias, após a recepção pela Ré das respectivas facturas, a emitir no início de cada ano.
Portanto, o preço contratual reporta-se ao fornecimento, instalação e entrada em funcionamento do software e à prestação de serviços de manutenção e assistência ao mesmo, durante o período de 5 anos, sendo faseado o seu pagamento em 5 prestações anuais.
O que significa que as obrigações em causa nos presentes autos são, efectivamente, sinalagmáticas, estando unidas por um vínculo de reciprocidade e interdependência, pois que o preço a pagar faseadamente é devido pelo fornecimento, instalação e entrada em funcionamento do software e pela prestação de serviços de manutenção e de assistência.
No que ao segundo requisito concerne, diz-nos António Menezes Cordeiro que só quando não hajam [SIC] prazos diferentes para o cumprimento da obrigação, é que é possível usar da excepção. A doutrina admite, contudo, a interpretação extensiva da lei, no sentido de que a excepção poderá, ainda, ser utilizada quando a parte remissa esteja já em mora, uma vez que o seu cumprimento devia ter ocorrido em primeiro lugar, podendo a outra parte prevalecer-se da excepção — ob. cit., página 293.
Ora, é este o caso dos nossos autos, pois que sendo diferentes os prazos de cumprimento das obrigações, alega a Ré que por a Autora não ter cumprido com a sua obrigação, ou melhor, por ter cumprido de forma defeituosa a sua obrigação, pois que o software não se encontra em pleno funcionamento e apresenta defeitos, tem a mesma direito a prevalecer-se da excepção de não cumprimento, enquanto não se verificar o cumprimento da Autora, ou seja, não irá proceder ao pagamento do preço cujo pagamento faseado foi acordado, por que [SIC] não se verificou, ainda, o cumprimento da obrigação da Autora.
Para a excepção operar é preciso que estejamos perante um não cumprimento, devendo este não cumprimento ser temporário, e impondo-se ao julgador obstar ao funcionamento da excepção, quando tal exercício vá contra a boa fé. Tratando-se de uma obra defeituosa, o alcance da excepção deve ser proporcional à gravidade da inexecução, sob pena de abuso de direito. O que significa que
“Deve haver proporcionalidade no exercício da exceptio; esta não cabe a quem se tenha colocado em falta ou a quem ocasione o não-cumprimento; a confiança e a lealdade devem ser respeitadas” — fr. ob. cit., páginas 294 a 297.
Ora, a Ré alega, em síntese, que desde o início da relação contratual que a Autora não assegurou o cumprimento do contrato, pois que o software adquirido, ainda hoje, não cumpre com as funcionalidades que devia. Para tanto, invocou que foram vários os pedidos de assistência não resolvidos, que teria havido uma reunião, pelo menos em Dezembro de 2018 em que a Ré informou a Autora do reiterado cumprimento defeituoso do contrato, e que reiterou tal informação em reunião tida em Julho de 2019 e, posteriormente, em Agosto de 2019 interpelou-a, por escrito, ao cumprimento.
Decorre do n.° 1, do artigo 342.°, do Código Civil, que o ónus da prova da existência de defeitos no software é do comprador, ou seja, da aqui Ré.
Todavia, e conforme resulta da factualidade provada, a única prova que a Ré fez quanto à existência de defeitos no software, prende-se com os tickets de helpdesk, dos quais resultam que, efectivamente, o software, por vezes, não processava as fórmulas introduzidas pela Ré. Os restantes defeitos apontados ao software, da prova que resulta feita, prendem-se, maioritariamente com erros na utilização da plataforma, ou seja, com erros feitos pelos técnicos da Ré que utilizavam a plataforma, por ou não saberem onde inserir os dados para obterem a informação pretendida, ou por não disporem de permissões para a obtenção dos resultados pretendidos.
Acresce que, no que aos relatórios concerne, não resulta do contrato que o software deve-se produzir relatórios dinâmicos. Com efeito, as partes preferiram o recurso ao termo “sofisticados”, podendo tal sofisticação passar, ou não, por essa característica, mas que não vem, efectivamente, especificada no contrato.
É certo que, o facto de o software produzir informação errada, nomeadamente por as fórmulas não estarem a ser processadas de forma certa pelo software, contribui para a descredibilização do software junto da Ré. Todavia, essa descredibilização passou também pelo facto de quem operava com o software não saber mexer no mesmo. Com efeito, das respostas dos tickets resulta que, por vezes, quem inseria os dados, inseria-os no campo errado, ou então não possuía permissões para visualizar os dados.
De facto, perante a prova produzida, formou-se a convicção deste Tribunal de que o software era de difícil utilização, não tendo havido formação ou interesse em obter a formação necessária para operar com o mesmo. O que desde logo inviabilizou o correcto funcionamento do software.
Acresce que, no que aos relatórios concerne, não se vislumbra como é que o software podia produzir um relatório fidedigno, sem que antes as parametrizações do mesmo, da responsabilidade da Ré, estivessem concluídas.
Mais, a relação contratual estabelecida entre a Ré e a Autora data de 2016, e apenas em 2019, ou seja, decorridos 3 anos, é que a Ré invoca a existência de defeitos. É certo que alegou tê-lo feito em momento anterior, mas a prova apresentada não foi suficiente para concluir de tal forma. Além de que, a prova da denúncia dos defeitos pelos tickets de helpdesk é insuficiente, do ponto de vista da proporcionalidade exigida, para poder fazer operar a excepção.
De referir, ainda, que ao ter-se colocado em falta no cumprimento da sua obrigação de parametrização dos dados, a Ré contribuiu para o não cumprimento da Autora, e desta forma, não é possível fazer operar a exceptio, por a utilização da mesma se demonstrar desproporcionada. E nem se diga, em prol da Autora, que o software nunca cumpriu com a função a que se destinava, pois que falhando o cumprimento daquela obrigação de parametrização, obrigação esta que se mostra de primária e necessária ao efectivo funcionamento do software, dificilmente poderia o software cumprir com a sua finalidade.
Em face do exposto, e sem necessidade de mais considerações, é de ser tida como improcedente a excepção de não cumprimento.»
É, este, um discurso impecável nas exposições teóricas, mas com algumas falhas quando se trata de aplicar o direito aos factos julgados provados.
Assim, invocam-se, como fundamento da decisão, factos que não foram seleccionados como provados, como se o estivessem, designadamente, apesar de estar provada apenas a troca de mensagens descrita nos artigos 28 e 29, labora-se sobre respostas do Autora como se estivessem provadas, chegando-se a concluir dessas respostas, aliás, referidas difusamente, sem as especificar, que a maioria das supostas infuncionalidades do sistema é imputável aa Ré. Este erro nas premissas resulta numa fundamentação falaciosa em toda a medida em que os factos invocados não foram julgados provados e não se concretizou as improdutividades do sistema que seriam imputáveis aa Ré.
Designadamente, embora esteja provado que a parametrização de dados era encargo da Ré e que esta nunca concluiu a parametrização, não se provou se e que funções do sistema estavam indisponíveis por causa de uma omissão de parametrização de dados; e de que dados. Porém, na sentença pressupõe-se que a falta de parametrização foi causa das dificuldades e impossibilidades na utilização do sistema.
Depois, na motivação da decisão de facto a Mª Juiz a qua disse que “Antes de mais, cumpre dizer que a restante matéria alegada pelas partes não foi julgada indiciariamente provada ou não provada, por constituir conceito de direito, matéria conclusiva ou não relevar para a decisão da causa”, mas maia adiante, na fundamentação de direito, diz: “Mais, a relação contratual estabelecida entre a Ré e a Autora data de 2016, e apenas em 2019, ou seja, decorridos 3 anos, é que a Ré invoca a existência de defeitos. É certo que alegou tê-lo feito em momento anterior, mas a prova apresentada não foi suficiente para concluir de tal forma(sublinhado nosso).
À parte a inoquidade da alusão a uma prova meramente indiciária ao lado da prova tout court, a segunda daquelas afirmações significa que, afinal, algo de relevante para a decisão da causa ficou por provar, o que é contraditória com a primeira, segundo a qual a matéria de facto não julgada como provada ou não era de facto ou era irrelevante para a decisão da causa.
Esta contradição não implica a nulidade da sentença, quanto por mais não seja porque tal não foi arguido.
Porém, estas perplexidades ditam que os sobreditos elementos da fundamentação de direito não podem ser por este tribunal sufragados.
Posto tudo o que – desta feita esclarecedoramente, pelo que nos dispensamos de o repetir ou replicar – se expõe na sentença recorrida, em geral, sobre o instituto da exceptio, relavam para a decisão do presente caso a proporcionalidade entre os efeitos, para cada parte, da procedência da excepção, por um lado, e a gravidade dos defeitos no cumprimento, por outro, bem como a compatibilidade da sua invocação com o dever de boa fé contratual de ambas as partes, consagrado, como princípio, no artigo 762º do CCivil (“no cumprimento da obrigação, assim como no exercício do direito correspondente, devem as partes proceder de boa fé).
A recorrente entende que, uma vez que já pagou 45% do preço global do contrato, e ainda faltam (faltavam) dois anos para o termo da sua execução sucessiva, existe essa proporcionalidade, atentos os provados defeitos da prestação do Autora.
Na sentença recorrida, abstraindo agora dos argumentos inconsistentes que já descartámos, entende-se que não ocorriam essa proporcionalidade nem boa fé da Ré, uma vez que é incontroverso que a obrigação, dita principal, de fornecer a plataforma no devido tempo foi cumprida e que a Ré se serviu da prestação durante três anos sem lhe apontar defeito.
A Recorrente e Ré, com fundamento na alteração do facto provado 31, diz que este último argumento assenta num erro de facto, pois os tickets para a helpdesck começam logo em Agosto de 2017. Mas não tem razão, pois uma coisa é alegar expressamente, numa reunião e depois numa carta de 2019 que a plataforma tem determinados defeitos pelos quais incumpre com o caderno de encargos, outra, bem diversa – e irrelevante para um cumprimento defeituoso – um qualquer colaborador da Réu apresentar um pedido de assistência à Helpdesk. Por outro lado, o envio de mais de uma centena de tikets de pedido de ajuda à helpdesck, ao longo de 3 anos, não permite concluir por um cumprimento defeituoso da prestação do serviço, quer porque o número não parece, sem mais factos, excessivo, quer porque nada permite saber quantos e quais dos pedidos se deveram a defeitos e ou erros de concepção ou de execução do sistema informático.
Assim, improcede a alegação de que a sentença erra de direito quando diz que a alegação da exceptio pela Ré não tem por si a proporcionalidade e a boa fé porque só ao fim de três anos de uso pacifico da “ferramenta” veio apontar defeitos no cumprimento da prestação.
Sucede, porém, que nesta instância vai julgado relevante e provado que à data de 20/8/2019, isto é, após três anos de execução do contrato, o sistema fornecido e apoiado pela Autora ainda não executava uma “Solução Web descentralizada de avaliação, com suporte para o SIADAP, com autenticação integrada sobre uma Active Directory e com suporte para multientidade na mesma instância da aplicação”.
Acresce que também está provado que na carta de resposta à correspondente queixa da Ré conforme artigo 29º dos factos provados, a Autora, depois de sustentar que existe o suporte para o SIADAP, confirmou que o sistema não executava a “solução”, mas, em vez de se dispor a executar a função, comunicou que não era sua obrigação suprir tal situação, que esta função não fazia parte da proposta pelo que teria de ser objecto de novo contrato:
Recordemos o teor da resposta da Autora:
“Resposta [SCom02...]:
O suporte SIADAP existe. A autenticação via Active Directory é possível, bastando para isso, fazer as devidas configurações. Decorridos 3 anos sobre a contratação, e uma vez que até à data em que recebeu a comunicação a que agora se responde, a [SCom01...] nunca solicitou a sua implementação. De certo modo compreende tendo em conta que a inclusão do SIADAP no pacote em apreço constituiu, em rigor, uma oferta da [SCom02...].
A [SCom01...] pretende implementar o SIADAP?
Em caso afirmativo, informa-se que o módulo do SIADAP implica uma instalação e configuração específicas que não foram incluídas na proposta.
Essa instalação e configuração, bem como a formação de formadores tem de ser objecto de proposta. Agradecemos por isso que nos informem se pretendem que seja enviada a proposta correspondente.
Certo é, porém, que esta função era exigida incondicionalmente – para estar disponível ab initio – pelas clausulas 16ª do caderno de encargos e 5ª do contrato, pelo que a resposta da Autora, nessa carta, não só carece de fundamento jurídico, como não releva da melhor fé na execução do contrato.
Mais, desta feita a Ré deparou-se com uma recusa expressa da Autora a executar a correspondente parte da prestação contratual. Ora, a solução informática para aplicar o SIADAP, enquanto sistema de avaliação do desempenho dos trabalhadores da Ré, mostra ser uma funcionalidade de sensível importância numa ferramenta informática que se pretendia holística.
Cumpre notar, ainda, que, conforme factos 28 e 29, a Ré advertiu a Autora da sua insatisfação e do que considerava serem os aspectos em falta ou em defeito, entre eles, expressamente, este do SIADAP, informando-a de que iria fixar um prazo para o um prazo para a supressão, sob pena de resolução do contrato, com o que procedeu com boa fé contratual.
Quando a Ré se absteve de pagar as facturas enviadas pela Autora estavam decorridos três de cinco anos de prestação de serviços e pagos 45% do preço total.
Tudo visto e ponderado, julgamos que não ofende a proporcionalidade e o dever de boa fé contratual por parte da Ré, a invocação, por esta, da exceptio non adimpleti contractus quanto à parte restante do preço.
Daqui se conclui que julgamos que a acção devia improceder, por proceder a excepção.

IV - Conclusão, quanto ao recurso e a acção
Do exposto quanto à questão 5ª, em que se esgota o objecto da ampliação do recurso, requerida pela Autora e Recorrrida [SCom02...] Unipessoal, Lda, resulta tão só o aditamento, aos factos provados, do novel facto 40, o que não lhe vale uma procedência da ampliação do recurso pois, apesar disso, do exposto quanto à questão 6ª resulta que o recurso haverá de improceder, passando a acção a improceder.

V – Custas
As custas do recurso e da acção haverão de ser suportadas, na totalidade, pela Recorrida, que sai de todo vencida: artigo 527º do CPC.

VI- Dispositivo
Pelo exposto, acordam em conferência os juízes da Secção do Contencioso Administrativo deste Tribunal em conceder provimento ao recurso, julgar procedente a excepção de não cumprimento do contrato pela Autora e, em consequência, improcedente a acção.
Custas: em ambas as instâncias, pela Recorrida.
Porto, 21/11/2025

Tiago Afonso Lopes de Miranda
Maria Helena Maria Helena Barbosa Ferreira Canelas
Maria Clara Alves Ambrósio
«Declaração de voto:

Voto a decisão, não acompanhando, todavia, a tese da nulidade quanto à 4ª Questão e bem assim quanto à 5ª Questão. Saber se na sentença deviam ter sido dados como provados factos que não foram elencados no probatório, tanto a imputação feita pela Recorrente, como a invocada pela Recorrida em ampliação do objeto de recurso, de que os factos que identificam devem ser aditados, é subsumível em erro quanto ao julgamento da matéria de facto, não em nulidade da sentença por falta de especificação dos fundamentos de facto a que alude o 615.º, n.º al. b) do CPC, pelo que enfrentaria a questão sob a perspetiva de erro de julgamento.»
Maria Helena Maria Helena Barbosa Ferreira Canelas