Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 12/20/2020 in Posts

  1. Foi hoje publicado o Orçamento de Estado 2021, QR code suspenso e com incentivos. Artigo 404.º: Apoio extraordinário à implementação do ficheiro SAF -T (PT) e código QR b) Em 2021, é suspensa a obrigatoriedade do disposto no n.º 3 do artigo 7.º e no artigo 35.º do Decreto-Lei n.º 28/2019, de 15 de fevereiro, sendo a aposição em todas as faturas e outros documentos fiscalmente relevantes do código de barras bidimensional (código QR) e do código único de documento (ATCUD) considerada facultativa. Documento: Lei nº 75-B/2020 Dre
    4 points
  2. Eu fiz uma alteração a um cliente que comercializa combustíveis. Tenho alguma informação que podes consultar aqui Informação combustíveis . Há um quadro com informação fixa sobre as % que é fixo e meramente informativo. Depois tens que fazer alguns cálculos baseados nas quantidades dos produtos constantes nas facturas de acordo com uma tabela onde consta o imposto aplicado a cada unidade que tens que multiplicar pela quantidade. O que eu fiz foi criar uma tabela, neste caso para o ISP (Imposto sobre produtos petrolíferos) com o valor do imposto. Na ficha do produto indico-
    3 points
  3. Coloquei uma questão no e-balcão para perceber como preencher o campo Q (4 caracteres da hash) do QR Code dos Recibos. Partilho a resposta que recebi:
    3 points
  4. Boas dicas! Não obstante, tenho um reparo a fazer. Só há 2 protótipos da função main() reconhecidos pelos standards mais recentes da linguagem C, sendo eles: int main(void) { } int main(int argc, char **argv) { } É importante referir que funções sem argumentos devem ter explicitado void. Isto deve-se ao facto do gcc (compilador de C da GNU) ser altamente permissivo (e não sei se este comportamento está devidamente documentado no standard, terei de ler). Ou seja, se não indicarmos o void, podemos fazer pérolas destas sem que o gcc se queixe de nada: int soma() { return 42; }
    2 points
  5. Não esquecer que uma coisa é a software house disponibilizar os meios para o cumprimento, outra são os vários intervenientes no processo e meios para o fazer. Nesse caso, e caso de, por exemplo, a impressora ter uma resolução diferente daquela adequada poderá afectar a qualidade e até o tamanho. Ao agente instalador/configurador cabe também essa inspecção e verificação.
    2 points
  6. Eu estou a usar a decrição da linha que está no documento, ou seja, ignoro a decrição que está na tabela de produtos, mesmo que a descrição do campo possa levantar duvidas de interpretação: "Descrição da linha da fatura, ligada à tabela de produtos e serviços." A não ser assim, a impressão do Documento de Transporte pelo programa poderia ser diferente da impressão obtida no Portal eFatura, o que não faria qualquer qualquer sentido.
    2 points
  7. Encontrei o problema. Tenho ativo no envio um traceListener que acrescentava uma tag no header. A validação da AT considera como mais um "actor"... <s:Header> <Security xmlns="http://schemas.xmlsoap.org/ws/2002/12/secext"> <UsernameToken> <Username> <!-- Removed--> </Username> <Password> <!-- Removed--> </Password> <Nonce> <!-- Removed--> </Nonce> <Created>RPzt9pt8md3+EP2WpcBxvBFoalOT1YU4OJAQKmP0nCA=</Created> </UsernameToken> </Security> <ActivityId CorrelationId="6a40bdf0-2468-4875-85ee-3b8
    2 points
  8. Isso não faz sentido nenhum! Nem sei se isso não dá direito a uma investigação por parte da AT. Se não dá então estamos mal...
    1 point
  9. A tua variável pocoes está a ser declarada dentro da função e começa sempre por 2, mesmo que chames isso 5000 vezes o que ele vai fazer é, criar a variável pocoes, meter o valor 2 lá dentro e depois subtrair um. Tens várias formas de fazer isso, em vez de ser uma variável dentro da função, usares uma variável global, em que a metes fora da função e já a consegues mudar sempre que chamas a função pocoes. Podes possivelmente depois brincar um bocado com apontadores e receber um apontador de um inteiro como argumento da função e alteras o valor lá dentro (em C é essencial entender esta mecan
    1 point
  10. Segundo a interpretação do Cfreitas, e eu tendo a concordar, os campos Country e Prefixo VAT são coisas diferentes e não devem ser confundidas. Quer no SAFT quer no QRCode é sempre pedido o Country, pelo que Grécia é sempre "GR". Apenas na VIES e nas Declarações Recapitulativas é pedido o prefixo VAT que para a Grécia é "EL". Nas Faturas, deve ser impresso EL, GR ou as duas coisas? Não tenho a certerza. Mas, como nas declarações aduaneiras, deve-se usar "EL", e como eu incentivo os clientes a consultar a VIES através do programa de faturação para ficarem com o comprovativo
    1 point
  11. Link do validador CIUS-PT, baseado no XSD do UBL 2.1 e pela norma CIUS-PT https://svc.feap.gov.pt/Doc.Client/public/CIUSvalidation/PT?language=pt
    1 point
  12. Tenho visto algumas facturas impressas (e PDFs) com o código QR com dimensões reduzidas. De acordo com a portaria a dimensão mínima é de 30x30mm. Isto afinal é para cumprir ou é só para alguns? PS: Um do exemplos foi uma factura do InvoiceXpress.
    1 point
  13. Na minha opinião sim. O campo Country é o código do país usando a norma ISO 3166-1-alpha-2. Os prefixos dos VAT number, embora maioritariamente coincidentes com esses códigos, não são a mesma coisa. Por exemplo, o código ISO da Grécia é "GR", mas o prefixo para os VAT numbers é "EL". Os prefixos são para usar onde forem devidos. Nas faturas e nas declarações fiscais.
    1 point
  14. Boa tarde caros! O Covid também está a causar chatices nas submissões IVA... Como o IVA foi prorrogado, em dezembro, todas as submissões que eram entregues no período de prorrogação devolviam o seguinte erro: "Indicou declaração dentro do prazo mas a declaração está fora do prazo ou vice-versa". Ou seja o WS erradamente achava que a declaração estava fora do prazo. O mais incrível foi que ao serem submetidas pelo site normal eram aceites. Dá a sensação que a AT se esqueceu de actualizar as políticas nos WS da mesma forma que fizeram com o Portal AT. (Nem sei como é possív
    1 point
  15. Do portal das finanças: A Irlanda do Norte, no que toca a prestações de serviços também é um país terceiro.
    1 point
  16. Parece-me que está aqui um imbroglio. As faturas emitidas a GB (mainland) serão sempre GB e deixam de ser Transmissões Intracomunitárias no Mercado Comum, ou seja, passam a ser Exportações e/ou prestações de serviços a Países Terceiros. As faturas de transmissões de bens para a Irlanda do Norte que tambem pertence ao Reino Unido, passam a usar o prefixo XI que já está previsto no VIES e deverão ir com este prefixo no SAFT no próximo dia 12 de Fevereiro e na Declaração Recapitulativa do IVA já no próximo dia 20 de Fevereiro. As faturas de prestações de serviços para a Irlanda do
    1 point
  17. A questão dos zeros está relacionada com o encoding; NÃO usar Auto, Numeric ou Alphanumeric. Um dos parâmetros da function GenerateQRCode é a taxa de recuperação de erro. E ainda é preciso forçar a versão minima = 9. Por exemplo, na function TVersion.ChooseVersion alterar esta linha for VersionNum := 0 to 40 do para for VersionNum := 9 to 40 do Na Internet existem muitas mutações desta unit que já incluem outras funções e properties para gerir estes parâmetros. Se quiser posso lhe enviar a que estou a utilizar. Não garanto que esteja perfeita, mas bateu certo com todos os exem
    1 point
  18. 1) A aceitação é um contrato em que o destinatário diz SIM (geralmente ao assinar um contrato de serviços... ou confirmar o mesmo através de formulário online... na falta, terá de assinar um PAPEL! 😕 ) 2) Sim, a assinatura do PDF com um certificado válido em nome da empresa é suficiente (aliás, estou a assinar os PDF's com o certificado do PRODUTOR do software... não é válido legalmente no que toca à facturação electrónica, mas pelo menos evita que o PDF seja ADULTERADO! Eu não me sentiria bem ao receber um PDF não assinado) 3) O arquivamento digital é um bico d'obra! Há quem contrat
    1 point
  19. Pessoal estou com várias dúvidas em relação à faturação eletrónica, só agora é que comecei a ver isto com mais atenção e li e reli a resposta que o @marcolopes me tinha dado na altura em que dizia que a faturação eletrónica deverá respeitar as seguintes condições: As minhas dúvidas são as seguintes: - No primeiro ponto a aceitação do destinatário, para isto basta o destinatário "dizer apenas" que sim? ou é necessário alguma espécie de documento a confirmar que o destinatário aceita receber as faturas eletronicamente? - Assinando as faturas (o pdf da mesma) isso já garante
    1 point
  20. Isso não tema ver com o cartão de cidadão ? Eu acho que sim, é tu poderes por um gerente a assinar com o seu cartão... Eu tenho tanta coisa para fazer que nem sei para que lado me virar, mas gostava de dar uma vista de olhos nisto...
    1 point
  21. Concordo e é assim que estou a fazer. A maior confusão é a questão de Isenção ou Não sujeição. Sinceramente, aqui acho que complicaram desnecessariamente.
    1 point
  22. Atenção que os certificados permitidos são realmente específicos para Facturação Electrónica, PDFs não XML, e tanto quanto sei, só duas entidades estão autorizadas a fornecer esses certificados em Portugal. E as duas comercializam os certificados na forma de webservices de assinatura. Não há cá Pens ou smartcards. Outra forma de assinar as facturas será através do sistema SAFE, que também utiliza webservices, e que provavelmente (ainda estou a analisar) usará um certificado emitido pela Multicert que é uma das empresas autorizadas em Portugal. Não é qualquer certificado ou chave priv
    1 point
  23. Se no documento de transporte for discriminado o IVA deverás colocar sim nos campos I,J,K se não aí sim preenches no campo L
    1 point
  24. É verdade que os certificados utilizados, os oficialmente permitidos, são agora muito mais caros. Pela informação que recebi os certificados, ou a assinatura de documentos. vai agora funcionar via webservices. E compram-se aos "pacotes", 500 assinaturas, 1000 assinaturas. O formato antigo de certificado através de ficheiros não é permitido. Pelo menos na questão da factura electrónica. Pelo menos é assim que vão funcionar a DigitalSign e a Multicert que são os dois fornecedores autorizados em Portugal para esse tipo de certificado.
    1 point
  25. Parece que as respostas estão no Serviço de Assinatura de Faturas Eletrónicas (SAFE) (autenticacao.gov.pt) em: https://www.autenticacao.gov.pt/serviço-de-assinatura-de-faturas-eletrónicas-safe-
    1 point
  26. Mais uma vez, uma publicação em cima da hora, com inferência já a partir de 1 de Janeiro. Lá diz o ditado, deixar tudo para a última. Enfim está nos genes dos nossos governantes... https://eco.sapo.pt/2020/12/29/empresas-poderao-assinar-faturas-eletronicas-com-cartao-do-cidadao-ou-chave-movel-digital/
    1 point
  27. A norma deverá estar na redação final do OE 2021. O Prof. Marcelo ainda ontem disse que ainda não o viu. Se o vai promulgar? Disse que não sabe. Mas, é muitissimo provável que sim, até porque, tendo em conta a pressão que fez sobre a oposição para que fosse aprovado no parlamento, não faria sentido outra coisa.
    1 point
  28. Muito obrigado Pedro... era esse mesmo. Deixo no entanto a pergunta aberta para a questão de imprimir usando directamente ESC POS e o que se faz para garantir a versão 9 (quando bytes < 180 ) ... Thanks again!
    1 point
  29. Acho que algures por aqui mandaram um link com esse código adaptado. Única coisa que alterava era que tinha mais um método que dava para passar um array de bytes e dava para definir o ECC e o tamanho. QRCodeGenerator.GenerateQrCode(Encoding.ASCII.GetBytes(qrCodeString), QRCodeGenerator.ECCLevel.M, version) Qualquer coisa deste género. Tens de passar em array de bytes porque o tipo que eles pedem é Byte, a versão tens de ver o tamanho da string, se for menor que 180 tem de ser ir a 9, se não deixas ir a -1 (valor automatico) e ECCLevel com o M. O Size, depois tens um méto
    1 point
  30. Tens barras a mais nesse regex. <input type="text" id="postalCode" placeholder="0000-000" pattern="^\d{4}-\d{3}?$">
    1 point
  31. altera o teu código para usar a noção de owner do form e não parent. Alteras para: private void Form1_Load(object sender, EventArgs e) { this.Top = 0; this.Left = 0; this.Width = System.Windows.Forms.Screen.PrimaryScreen.Bounds.Width; this.Height = System.Windows.Forms.Screen.PrimaryScreen.Bounds.Height; Form2 fr2 = new Form2(); fr2.ShowDialog(this); } e private void button1_Click(object sender, EventArgs e) { ((Form1)this.Owner).btn_adicionar.Visible = true; this.Hide(); }
    1 point
  32. Boas, isso resolves se abrires o form de login como dialog. O problema é que se colocares o form de login a abrir no form load do principal, este fica escondido até fechares o form de login. Se não houver problema, podes fazer assim, no form principal: private void Form1_Load(object sender, EventArgs e) { frmLogin frmlogin = new frmLogin(); frmlogin.ShowDialog(); // if (!frmlogin.AutenticouCorrectamente) { // Login falhado frmlogin.Close(); Application.Exit(); return; } // Login ok } E no form de login, algo assim: public bool AutenticouCorrectamente = false; private void
    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.