Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 11/02/2021 in all areas

  1. From: DSPCIT - Certificação de Software Subject: Despacho n.º 8632/2014 - emissão de documentos com DATA ANTERIOR Date: Monday, November 15, 2021, 19:25 No que se refere à questão exposta na sua mensagem, informa-se que, nos termos do n.º 4 do art.º 7 do Decreto-Lei n.º 28/2019, de 15 de fevereiro e dos pontos 1.6 e 3.4.2 do Despacho n.º 8632/2014, de 03 de julho do Diretor-Geral da Autoridade Tributária e Aduaneira, os documentos fiscalmente relevantes são emitidos cronologicamente sendo numerados e datados de forma progressiva e contínua, dentro de cada série. A emissão de um documento não corresponde a um mero formalismo, constituindo o suporte documental de uma determinada realidade que ocorre num determinado momento. Desconhecendo-se o motivo que possa levar o emitente a averbar uma data superior à corrente que, por defeito, se encontra definida e para a qual, eventualmente, foi alertado, ainda que se admita que se trate de uma antecipação de uma realidade que tenha tomado por certa no momento da emissão, um documento assim emitido não deixa de se inserir na sequência cronológica da série documental utilizada. Acresce que a sua anulação deve ter um fundamento objetivo inerente à operação nele retratada, carecendo que o seu teor não corresponda à realidade, não podendo constituir um mero expediente para resolução de um pretenso problema, a necessidade e emitir um outro documento na data corrente, quando poderá utilizar outra série para o efeito. Nestes termos, a anulação de um documento, ainda que seja o último da série documental em que se insira, não pode permitir que a sequenciação cronológica seja comprometida, i.e., o documento subsequente obrigatoriamente será da mesma ou de data superior à do documento anulado.
    5 points
  2. Aqui está: https://www.occ.pt/pt/noticias/comunicado-da-bastonaria-ajustamentos-do-calendario-fiscal-e-outras-disposicoes/
    4 points
  3. Novidades, Despacho do SEAAF de ontem com adiamentos de prazos: Notícias - Comunicado da bastonária - Ajustamentos do calendário fiscal e outras disposições - OCC - Ordem dos Contabilistas Certificados Importante para nós: - Fica suspensa, em 2022, a comunicação de séries. Em 2022, a obrigação de aposição do ATCUD nas faturas e outros documentos fiscalmente relevantes é meramente facultativa; - A comunicação dos inventários valorizados apenas será obrigatória em 2023; A comunicação dos inventários relativamente a 2021 será feita nos mesmos termos dos inventários relativos a 2020; - Até 30 de junho de 2022, devem ser aceites faturas em PDF, as quais são consideradas faturas eletrónicas para efeitos fiscais.
    4 points
  4. @jasbe @ZeTorres: Um de vocês, ou os dois, acordaram com os pés fora da manta... Tenham lá calma e medir pilinhas fica para as PMs, aqui é para debater problemas a sério. Já tenho dito noutras alturas, a aplica-se agora também: Aqui não há crianças, somos todos adultos, e devemos saber comportar-nos como tal. @jasb: Verifica a resposta do @marcolopes. Não, "quase toda a gente" NÃO usa espaços na série. O que está à esquerda da barra não é a série, é o conjunto CID + <espaço> + Série, segundo documentação regulatória da AT. Podes ter a mesma série em vários tipos de documento, logo que o CID seja diferente neles todos. Daí ser normal encontrares FT 21/123 e NC 21/123 - A série é a mesma '21', o que muda é o CID. A dúvida que surge na comunicação de séries é quando tens dois CID's diferentes e a mesma série dentro do mesmo tipo de documento. Ao não contemplar o CID na comunicação de séries, a AT criou um potencial problema para toda a gente que se baseava na norma do SAFT para criar a sua estrutura identificatória de documentos. Se tiveres FT1 21/123 e FT2 21/123, para o SAFT é perfeitamente legal, mas não irás conseguir comunicar as duas séries dessa forma. Para remendar esse problema, uma sugestão é repetir o CID na série, tornando na prática a série diferente para cada tipo, como por exemplo assim: FT1 FT1_21/123 e FT2 FT2_21/123. Obviamente isto é feio e redundante, pelo que não era mau que a AT seguisse os seus próprios parâmetros e aceitasse o CID como diferenciador na comunicação de séries. E devoluções após ano e meio é perfeitamente normal. Numa avaria em garantia, se te trocarem o equipamento, podem fazer-te uma NC do equipamento antigo e uma nova FT para o novo. Não vamos envereder em absolutismos, porque nuances existem em cada tipo de negócio, e é impossível a cada um de nós conhecê-las a todas.
    4 points
  5. ATCUD/QRCODE "A Autoridade Tributária e Aduaneira (AT) agradece o seu contacto. De acordo com o Despacho nº 351/2021.XXII de 10/11/2021 e Ofício Circulado N.º: 30243, a comunicação de séries documentais será suspensa em 2022, sendo a aposição do ATCUD facultativa. Esta suspensão abrange igualmente, em 2022, os documentos impressos em tipografia autorizada. No entanto, a aposição do Código QR em documentos fiscalmente relevantes, será obrigatória a partir de 1 de janeiro de 2022. Qualquer alteração sobre esta matéria, a ocorrer, será disponibilizada no Portal das Finanças. Com os melhores cumprimentos AT- Autoridade Tributária e Aduaneira"
    3 points
  6. O ofício circulado nem sequer menciona o QRCode, não se pode ir por aí. O X da questão está na parte que não marcaste a bold: "e um código único de documento" - este é o ATCud. No nº 3 são mencionados os dois conceitos em separado: QRCode e ATCUD. Se se suspende a parte do ATCUD, e se fizeram questão de especificar que foi essa parte que suspenderam, não vejo como o QRCODE possa ter sido adiado. Acho que podiam ser mais especificos: "Isto foi adiado, isto não foi". Mas é o que é.
    3 points
  7. https://github.com/phax/phive https://github.com/phax/phive-rules
    2 points
  8. No site da espap tem um validador schematron para o CIUS pt: https://www.espap.gov.pt/spfin/normas/Paginas/normas.aspx
    2 points
  9. Relativamente a esta questão de considerar, ou não, os documentos anulados na verificação cronológica dos documentos: se não tivermos em consideração os documentos anulados, e se estes forem de meses diferentes, como proceder aquando do envio do SAF-T à AT? Por exemplo: Mês de Outubro: FAC 2021/1 - 06-10-2021 FAC 2021/2 - 07-10-2021 FAC 2021/3 - 25-12-2021 -> Anulado FAC 2021/4 - 09-10-2021 Quando exportarmos o SAF-T mensal de Outubro o que acontece ao documento FAC 2021/3 (que é de Dezembro)? Se o exportamos estamos a inserir documentos de outro mês, se não exportamos há um salto na numeração (mais, se houver verificação de assinaturas não vão validar, já que não estamos a exportar todos os documentos emitidos). Quem está a permitir isto nos seus programa, como está a resolver esta situação?
    2 points
  10. Nós não permitimos documentos com data anterior á do ultimo, ponto final. Seja anulado ou não.
    2 points
  11. No contexto do CIUS, o PDF não tem de ser assinado... (é o meu entendimento) O "documento" legal é o CIUS... o PDF embebido é "exigido" como forma de análise visual do documento, para conferência, e não é através do mesmo que devem ser efectuadas quaisquer operações de integração. Quando o PDF é colocado "à disposição" para download, estamos a falar da factura electrónica PDF, e não da FE-AP! Nesse caso, mesmo que seja emitido um CIUS, o "documento" legal é o PDF, mas são conceitos diferentes FE - PDF (assinado) FE-AP - CIUS (assinado) com PDF embebido para conferência
    2 points
  12. https://github.com/marcolopes/dma/tree/master/org.dma.services.at/certificates
    2 points
  13. Dos dois... diria dos 3! BROKERS (um caos), empresas públicas (algumas nem implementaram sequer) e fornecedores da AP (muito por causa de tudo o resto!)
    1 point
  14. https://svc.feap.gov.pt/Doc.Client/public/CIUSvalidation/PT?language=pt
    1 point
  15. em ves de select bo colocar select FT msel = [select cl.pais from cl(nolock) where cl.no=]+astr(FT.NO)+[]
    1 point
  16. São duas coisas diferentes: - A faturação eletrónica no âmbito da administração pública (FE-AP). Está a ser discutido aqui. - A faturação eletrónica "geral": está legislada no Decreto-Lei nº 28/2019. O adiamento referido acima (até 30 de junho de 2022) diz respeito a isto. Até lá os documentos em pdf, enviados por email, são considerados válidos fiscalmente. Posteriormente, terão de cumprir todas as regras indicadas nesse decreto-lei.
    1 point
  17. Eu diria que não consegues colocar lá com o valor do IVA a zero. Quase de certeza vai dá erro na validação. Além do mais, esses lançamentos feitos à conta 24341 - IVA regularizado a favor da empresa, têm de ser verificados pelo Contabilista Certificado, já que, de acordo com o artigo 78º do CIVA, o IVA dessas Notas de Crédito só pode ser deduzido quando se está na posse de cópia assinada pelo cliente, ou outro meio de prova de que este teve conhecimento da sua emissão. Do lado do cliente, este terá de regulazizar esse mesmo IVA na conta 24342 - IVA regularizado a favor do estado, que cairá no Campo 41, e será evidenciada no respetivo Anexo ao Campo 41 da DPIVA. A AT deverá comparar o Anexo ao Campo 40 do emitente com os respetivos Anexos ao Campo 41 de cada um dos clientes e as coisas devem coincidir, para garantir que os emitentes não andam a emitir Notas de Crédito sem conhecimento dos clientes, para reduzir o valor do IVA a pagar.
    1 point
  18. https://info.portaldasfinancas.gov.pt/pt/destaques/Paginas/Codigo_QR_20201029.aspx O Código de Barras Bidimensional (Código QR) previsto no nº 3 do artigo 7º do Decreto-Lei 28/2019, deve passar a integrar todas as faturas e outros documentos fiscalmente relevantes, a partir de 01 de janeiro de 2021. https://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/Novas_regras_faturacao/Documents/FAQ_DL28_2019_2019_10_01.pdf O que são documentos fiscalmente relevantes para efeitos do DL 28/2019, de 15 de fevereiro? R. São «documentos fiscalmente relevantes», os documentos de transporte, recibos e quaisquer outros documentos emitidos que, independentemente da sua designação, sejam suscetíveis, nomeadamente, de apresentação ao cliente e que possibilitem a conferência de mercadorias ou de prestações de serviços.
    1 point
  19. O Anexo ao Campo 40 da DPIVA é um mapa que evidencia e complementa a informação de todos os valores que foram lançados no referido Campo 40. Neste Campo 40 (Conta 24341) lançam-se os IVAs regularizados por Notas de Crédito emitidas a clientes referentes a: faturas que foram total ou parcialmente devolvidas, descontos pós-fatura, etc. Se uma Nota de Crédito não tiver IVA, não tem porque ser lançada no Campo 40 e por isso não tem de ser evidenciada no respetivo Anexo.
    1 point
  20. Todos os fiscalmente relevantes, leia-se, todos os que vão no SAFT.
    1 point
  21. Duvidas dissipadas! (Ainda virá alguém dizer que é uma montagem...) Tenho lido muitas lamentações pelo trabalho perdido... nada se perdeu, já está feito para quando entrar em vigor! Sou defensor que em caso de dúvida, é preferível a mais do que a menos!
    1 point
  22. Tens razão Marco. O artigo 7.º, n.º 3 do Decreto-Lei n.º 28/2019, diz isto: Não tinha reparado, que mencionava o código único do documento. Nesse caso a interpretação é clara sim. Do artigo 7.º, n.º 3 do Decreto-Lei n.º 28/2019, só fica adiado o código único do documento. Eu é que fiz confusão ao não ler devidamente o ponto 3.
    1 point
  23. O facto do oficio Circulado mencionar exclusivamente o ATCUD, valida a teoria do Marco. Caso contrário deveria tambem referir o QrCode ou então a suspensão do artigo por completo sem mencionar um ou outro. Quanto a mim o QRCode não é adiado.
    1 point
  24. Desculpa, mas eu não vejo confusão nenhuma! E não vejo qualquer engano. Eles mencionam o artigo 7.º, n.º 3 do Decreto-Lei n.º 28/2019 no que toca à comunicação de séries e à obrigação de aposição do código único de documento (ATCUD). Qual é a dúvida? Eles esclareceram o necessitava de ser esclarecido! 1) O adiamento do ATCUD adia a COMUNICAÇÃO de SÉRIES DOCUMENTAIS? SIM! (este era o dilema!) 2) O adiamento do ATCUD e das SÉRIES documentais adia o QRCODE? NÃO!
    1 point
  25. Bom dia a todos, Na minha opinião não faz sentido adiarem o QRCode até porque também está em jogo "benefícios fiscais" que os contribuintes estão a espera. Mas isso é só a minha opinião claro. Daqui há pouco vou almoçar bem e não pensar mais nesta coisa das serie 🙂 Um bom fim de semana a todos.
    1 point
  26. Ora eu discordo, a lei está bem clara. Sendo certo que o artigo nº3 do Art 7º é sobre o ATCUD e QRCode. No despacho seaaf 351-2021-xxii diz assim: Em 2022 fique suspensa, quanto à comunicação de séries e à obrigação de aposição do ATCUD, a obrigatoriedade do disposto no nº3 do artigo 7 e no artigo 35 do Decreto-Lei nº28/2019, de 15 de fevereiro, na sua redação atual, sendo a oposição do ATCUD em todas as faturas e outros documentos ficalmente relevantes considerada facultativa; "Quanto à ..." só e só ao ATCUD, não é feita referencia ao QRCode, logo se não é alterado nada em relação ao QRCode é para se aplicar o que está definido, ou seja, entra em vigor a 1/1/2022. Este é o meu entendimento...
    1 point
  27. E conforme o Marco Lopes previa, a Faturação Eletrónica também voltou a ser adiada !!!
    1 point
  28. Pelos vistos saiu um decreto que adia a comunicação das series. Estou a procura dele, logo que encontre o dito cujo posto o link.
    1 point
  29. TL;DR: Não há um "melhor programa", depende de vários factores, incluindo preferência pessoal. O Code::Blocks é, contudo, um exemplo potencialmente acessível. Resposta completa: Depende da plataforma para onde queres programar (Windows, Linux, macOS, FreeBSD...). Contudo, pessoalmente recomendo uma combinação de compilador + editor de texto. Vamos então por partes. Compilador: Programa que traduz o código escrito em C (ou outra linguagem) em código máquina (binário) que o computador perceba e saiba executar. No Linux este seria o gcc. Editor de texto: Programa dedicado à escrita e edição de código, sendo geralmente independente da linguagem. Uma excelente opção é o Visual Studio Code. A ideia é simples: escrever o código no editor de texto e depois compilar com recurso ao compilador. Outra alternativa é usar um IDE (Integrated Development Environment). Este inclui o compilador e o editor de texto num só programa, mas com a desvantagem de ser dedicado a uma pequena seleção de linguagens. Alguns deles podem ser extremamente pesados. O Code::Blocks é um exemplo de IDE para programar em C (entre outras linguagens). Cumprimentos.
    1 point
  30. Desculpa....o tico e o teco andam queimados😂. Tens toda a razão. Acho que é de ler tanta legislação......
    1 point
  31. Não foi o que eu disse? Eu disse que era muito mais facil ...
    1 point
  32. Penso que isso já foi aqui debatido pelo @americob e outro colega, e comentado por mim, acordo de cavalheiros é emitir uma Nota de Crédito, como muitos fazem, praticamente todos, sem cumprir a alínea 5 do Art. 78º do CIVA, e depois chega à contabilidade e dá bronca. É um facto que em determinada altura a NC e a ND passaram a documentos retificativos, e a AT parece que passou a demonizar a "Anulação de Documentos", contudo ela existe, está prevista sem recurso à NC, tanto no SAFT como na Legislação, caso contrário não era necessário haver no SAFT o estado do Documento Anulado ou Normal. Exemplo, emites e entregas uma FT a um cliente, 2 dias depois dás por um erro e (como todos fazem) envias uma NC ao cliente sem cumprir alinea 5 do Art. 78º do CIVA, e pensas que fica tudo bem, ou pior, nem sequer envias ao cliente. Mais tarde és notificado pela AT para entregar o imposto porque 1 dia depois de teres emitido a FT o cliente fechou actividade. Isto acontece mais vezes do que aquilo que se possa pensar. Daí, todas as NCs deverem ser assinadas pelos clientes e devolvidas a quem as emitiu, precisamente para cumprir a alínea 5 do art 78º do CIVA. E depois ainda há outras situações que penso que o @americob já tinha referido e bem, se é possível ou não deduzir o IVA da NC. Mas aí não sou a melhor pessoa para explicar.
    1 point
  33. Penso que isso será mais um "acordo de cavalheiros" do que outra coisa. Já a possibilidade de ANULAR ou obrigação de emissão de NOTA de CRÉDITO ou DÉBITO está explícito na "lei" O Código do Imposto sobre o Valor Acrescentado (CIVA) estabelece no n.º7 do artigo 29.º que, quando o valor tributável de uma operação ou o imposto correspondente sejam alterados por qualquer motivo, incluindo inexatidão, deve ser emitido documento retificativo de fatura. sem prejuízo da possibilidade de anulação da fatura inicial e sua substituição por outra, quando a retificação se deva a outros motivos. Portanto... se "mexer" com "valores", o documento não pode ser anulado. Caso contrário (datas, observações, descrições, etc, etc) sim. Mas isto é um "à parte" relativamente ao mais recente tema de conversa (ANULAÇÃO por motivo de data de documento errada)
    1 point
  34. Se passou uma factura "por engano" (data) deve anular... ao anular, pode emitir outra, DESDE que essa outra NÃO tenha data ANTERIOR à factura anulada! Desta forma, esse problema nunca se colocará ao emitir SAFT (seja de comunicação ou de AUDITORIA - no caso do SAFT de auditoria é ainda mais grave, porque a validação da cadeia de HASH vai falhar redondamente, caso o "documento anulado" não esteja contido no período!) Portanto, um documento emitido por engano, digamos, em NOVEMBRO com data de DEZEMBRO deve ser exportado do SAFT de dezembro... mas, dando permissividade para continuar a usar uma série onde a ordem cronológica foi violada (através da anulação do documento com data de DEZEMBRO e emissão de novo documento com data de NOVEMBRO), tudo isso cai por terra, pois irá existir um "buraco" na numeração no SAFT de NOVEMBRO, e um documento fora da ordem cronológica e de numeração no SAFT de DEZEMBRO! Caso a série seja descontinuada / fechada (como manda a lei) não se coloca qualquer cenário problemático, uma vez que o documento emitido em DEZEMBRO será comunicado em dezembro (no período devido) e não haverão outros documentos a comunicar naquela mesma série! Portanto, quem está a permitir a anulação e continuação da utilização da mesma série, ou teve muita sorte até agora, ou tem os clientes a comunicar / exportar ficheiros SAFT com buracos na numeração e por sua vez com cadeias de HASH inválidas.
    1 point
  35. Tens toda a razão. No teu código, eu apenas optaria por colocar o textcolor e textbackground dentro do procedimento usando mais 2 argumentos para passar os valores das cores. @mateusalves, pelo que vi, parece-me que estás a iniciar nisto do Pascal e a "brincar" para aprender. Se for o caso vai aproveitando as dicas que te damos aqui 😉 Assim sendo, aqui qualquer coisinha: Esses WHILE's para mim estão mesmo a pedir um ciclo FOR. Poupa-te em código e fica mais perceptível. Vou fazer o vermelho e depois podes aplicar o mesmo método nos outros ciclos WHILE // c2:=57; --> Não é preciso // l2:=0; ---> Não é preciso // Com o ciclo FOR não necessitas de inicializar, re-inicializar nem incrementar as variavies For c2:=57 DownTo 30 do //preencher o vermelho em falta begin For l2:=0 to 25 do begin // aqui usaria um procedimento semelhante ao do @nunopicado em vez do código abaixo delay(ATRASO1); gotoxy(c2,l2); textcolor(RED); textbackground(RED); write('.'); end; end;
    1 point
  36. Nos meus clientes isso é o prato do dia, ou porque se enganam na data ou porque a data do PC vai para a data de fabrico por falta de bateria. Vai ser um problema para eles agora com a certificação das séries. Era mais fácil depois do documento anulado, deixar criar documentos nessa série. Neste momento não deixo criar, porque nunca vi nada na lei que clarificasse esse ponto. Mas isso iria resolver muitos problemas e descomplicar o sistema.
    1 point
  37. Também tenho clientes desses. Dificilmente vais encontrar uma portaria ou decreto que diga especificamente que o mesmo se aplica a documentos anulados. Eu acho que o despacho não é omisso. Simplesmente não comtempla essa hipótese especificamente, logo aplica-se a "generalidade". Penso que é assim que funciona a lei. Um exemplo (um bocado ridículo mas...) a lei diz que é crime matar outra pessoa mas não diz se é á facada ou ao tiro ou pontapé. Logo aplica-se a toda a forma de morte. Penso eu de que... 😁
    1 point
  38. Tens o Despacho n.º 8631/2014:
    1 point
  39. Boas @marcolopes, de informação que tenho ninguem (ESPAP, ILINK, SAPHETY, YET) me pediu o pdf assinado. Os outros brokers não sei. De fato ainda existe muita gente que não entende o conceito FE e FE-AP ... mas é isso mesmo. Era bom mais post tão explicitos.
    1 point
  40. Pegando no que te disse o @nunopicado, colocas isto em todos os ciclos if KeyPressed then case ReadKey do #0: ReadKey; // Serve para limpar o buffer caso seja pressionada uma tecla especial #27: textcolor(WHITE); textbackground(BLACK); gotoxy(1,26);write('P');delay(ATRASO2);gotoxy(1,26);write('Po');delay(ATRASO2); gotoxy(1,26);write('Por');delay(ATRASO2);gotoxy(1,26);write('Por ');delay(ATRASO2); gotoxy(1,26);write('Por M');delay(ATRASO2);gotoxy(1,26);write('Por Ma');delay(ATRASO2); gotoxy(1,26);write('Por Mat');delay(ATRASO2);gotoxy(1,26);write('Por Mate');delay(ATRASO2); gotoxy(1,26);write('Por Mateu');delay(ATRASO2);gotoxy(1,26);write('Por Mateus');delay(ATRASO2); gotoxy(1,26);write('Por Mateus ');delay(ATRASO2);gotoxy(1,26);write('Por Mateus A');delay(ATRASO2); gotoxy(1,26);write('Por Mateus Al');delay(ATRASO2);gotoxy(1,26);write('Por Mateus Alv');delay(ATRASO2); gotoxy(1,26);write('Por Mateus Alve');delay(ATRASO2);gotoxy(1,26);write('Por Mateus Alves');delay(ATRASO2); clrscr; end; Mas isto é programação "spaghetti". Usa procedimentos e funções.
    1 point
  41. De acordo com OCC, a bastonária garantiu que tudo o que está o Orçamento, terá irremediavelmente ser publicado em portaria, despacho, o que seja. Por outro lado temos de pensar um pouco além da produção de software. Recordo que as faturas manuais sem o ATCUD são válidas apenas até 31 de dezembro, e a AT ainda não disponibilizou o acesso para poderem criar o ATCUD, tal como a nós. O adiamento nunca é por nossa causa, é sempre por incapacidade da AT de implementar. O que me entristece realmente é chegar à conclusão que isto cada vez mais é um país para ou espertos ou preguiçosos... ainda não sei bem. Refiro-me concretamente aos que não fazem nada porque estão sempre à espera que seja adiado. Nós aqui debatemos, ajudamo-nos para garantir que temos tudo dentro da lei. Perdemos horas a tentar comunicar com serviços com erros inaceitáveis, como seja erros na documentação, implementações a conta-gotas. Neste caso em particular muitos de nós comigo incluído tivemos de alterar a estrutura da aplicação por causa de regras relativas às séries serem únicas por tipo de documento, que eu não consigo encontrar em lado nenhum! Se estava mal como foi possível muitos de nós usarem durante anos?! Continuo a defender que o estado em vez de continuar a atirar todas as implementações para o fim do ano, em que ainda por cima o dia um é feriado, deveria ter a parte deles pronta até fevereiro, por exemplo, e nos podermos implementar até ao fim do ano, mas podendo a partir dessa data começar a dar seguimento às implementações em produção. Já pensaram que quem tem programas para áreas que trabalham no dia um, terão de estar em regime de prontidão para precaverem algum tipo de erro inesperado, que poderá ser pura e simplesmente uma falha de comunicação com a AT, falha de Internet, etc., etc. Peço desculpa por este longo post mas continua a sentir-me um fantoche nas mãos da AT! Cumprimentos a todos
    1 point
  42. se é para fazer trabalhos académicos, ficas bem servido com o CLion
    1 point
  43. Bom dia, Acho que toda a gente já percebeu que a Retenção é sempre feita no Recibo. Por exemplo: quando há alteração da taxa de retenção de 20% num ano para 25% no seguinte a taxa que consta de uma fatura de Dezembro é meramente indicativa se ela for paga ainda em Dezembro o valor a reter é mesmo os 20% que nela consta mas se for paga em Janeiro do ano seguinte a retenção já será de 25% que é o que está em vigor na data do pagamento, independentemente do que dela consta por isso, o total da Fatura é sempre o valor sem ter em conta a Retenção Se for uma Fatura/Recibo, mesmo neste caso em que o papel é o mesmo, terá sempre internamente um valor total para a Fatura e um valor total para o Recibo.
    1 point
  44. Obrigados a todos pela vossa ajuda. Concluindo: nettotal - 100 taxpayable - 23 Grosstotal - 123 ( Valor com qual é gerado a HASH ) withholdingtax - 25 E os impostos Tipo IRS - não aparecem nas linhas como se Fossem artigos. É que tenho visto alguns softwares certificados onde os impostos (IRS, etc...) aparecem como linhas da factura. Correcto? ais uma vez obrigado pela vossa colaboração.
    1 point
  45. Se reparares 4.1.4.19.3. * Total do documento com impostos (GrossTotal) menciona "Este campo não deve refletir eventuais retenções na fonte constantes no campo 4.1.4.20 – Retenção na fonte (WithholdingTax)". Na pratica esta é uma factura como qualquer outra, excepto que tens que colocar o valor da retenção no campo WithholdingTax, de resto tudo é calculado como uma factura normal. O hash é calculado sobre os 123 €, como em qualquer outro documento. Penso que o importante é mostrar no impresso o valor da retenção do documento.
    1 point
  46. Boas pessoal!!! Bem,eu tenho que fazer um simulador do lançamento de uma bola de golfe, tendo em conta a velocidade inicial e blablabla..cenas da fisica. Essa parte ja está feita. O programa é este: http://img9.imageshack.us/img9/8039/35964231.png O meu problema está ali nas edit's do lado direito, o número de casas decimais está livre e eu queria restringir só a 2 casa decimais. Não se isto que vou dizer é relevante, mas penso que sim. O programa faz os cálculos e depois para passar para a edit eu passo directamente, usando a funçao "floattostr", não faço tratamento do número. Alguém sabe como faço para aparecerem apenas 2 casas decimais?? Obrigado
    1 point
  47. Boas, "Vou experimentar, mas aquilo que disseste sobre a tabela e o que "desenhaste" é em DOS e eu estou a trabalhar em ambiente gráfico." Então é só aplicares o que o Turkis te explicou.
    1 point
  48. Vou experimentar, mas aquilo que disseste sobre a tabela e o que "desenhaste" é em DOS e eu estou a trabalhar em ambiente gráfico. Mas obrigado pela ajuda!!!
    1 point
  49. o eurodns.com ofrece uma ferramenta de atualizar o ip
    1 point
×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.