Rankings

Tendo em conta que a menção da retenção na fatura é meramente informativa e que a competência de reter é de quem paga, deve fazer o recibo de acordo com o que lhe pagaram. Se, quem lhe paga sabe o que está a fazer, deve fazer os pagamentos da seguinte forma: 266.68 - 66.68 = 200 , para o primeiro pagamento 433.32 - 108.32 = 325 , para o segundo pagamento Os valores das retenções têm de vir mencionados nos pagamentos e ser entregues pelo seu cliente na AT até ao dia 20 do mês seguinte. Esse seu cliente que lhe fez esses pagamentos, é obrigado a enviar-lhe uma declaração em Janeiro do ano seguinte onde deve constar: rendimento: 700 retenção: 175 Esses 175€ devem aparecer pré-preenchidos no seu IRS Modelo 3 no valor das retenções que lhe foram efetuadas. No meu programa, controlo a conta-corrente pelo valor total da fatura. Faço isto por 2 motivos: - a retenção é feita no momento do pagamento, à taxa em vigor no momento do pagamento, e pode ser diferente da taxa usada para informação na fatura. Por exemplo, a taxa era 25% em Dezembro do ano N, mas aumentou para 26% no ano N+1, se o pagamento (ou parte) for efetuado em N+1 já terá de reter 26%. - o cliente pode até não estar obrigado a fazer retenção, por exemplo, por não ter contabilidade organizada e que não se sabia ao fazer a fatura. No recibo, o valor que abate na conta-corrente é o valor recebido + retenção.

É o SAF-T. A Portaria 321-A/2007 (a que criou o SAF-T) regulamenta o dito n.º 8 do artigo 123.º do CIRC (na altura era o 115.º).

Sem saires do mundo Microsoft, a melhor opção creio que recai em SQL Server (com Report Services, que parece que já vem incluído nas versões mais recentes) e C#/ASPX.

Acho que a primeira e a ultima versão que esteve disponível desse FACTEMICLI... foi quando o SAFT ainda estava na versão 1.02_01. Agora já vai na versão 1.04_01, pelo que o que existiu já não deve funcionar. Na altura, a AT foi questionada (procura lá para trás nesta pagina) e a resposta foi que não se justificava manter essa opção. A desculpa baseou-se em que a generalidade dos programas permitiam a comunicação dos DT's por Webservice, e que, em 99% dos casos, os DT's são feitos para serem utilizados na hora e por isso fazia pouco sentido o envio de conjuntos de DT's por ficheiro que só depois de processado devolvia os códigos AT. Na minha opinião, só não há mais programas a comunicar Faturas por Webservice porque ainda não está claro na Lei que todos os programas certificados o possam fazer. Uma leitura estrita da Lei dá a entender que só as Faturas Eletrónicas (cumprindo todos os requisitos de assinatura, integridade, etc.) podem ser comunicadas por esta via. As restantes Faturas continuam a ter de ser comunicadas por SAFT. Embora haja muitos programas no mercado a comunicar Faturas por Webservice sem que estas sejam Faturas Eletrónicas, programas a assinar as Faturas eletrónicas com assinaturas que nem sequer são da empresa emissora, etc.. A lei das Faturas Eletrónicas precisa de clarificação urgentemente. Aliás, pelo que tem saído nos jornais, estas mudanças devem estar para breve, com o QR code e a desmaterialização dos documentos.