Italo Giurizzato Junior

Bom dia Raquel, Pelo o que eu entendi é uma foto para cada entrega, não importa se nessa entrega tenhamos uma ou mais notas. Se o destinatário é o mesma pessoa e temos duas notas, deve-se tirar apenas uma foto.

Bom dia Luís, Muito obrigado pela informação, já criei um tópico na área de noticias.

20/12/2019 - ATENÇÃO: SVRS - Desativação dos protocolos SSL, TLS 1.0 e TLS 1.1. A Sefaz Virtual do Rio Grande do Sul (SVRS), para garantir o bom funcionamento do Ambiente de Autorização dos Documentos Fiscais Eletrônicos, deverá desabilitar os protocolos de comunicação mais antigos a partir do dia 16/01/2020. Esta mudança é necessária, não só pela simplificação do ambiente e aumento da segurança, como também pela inviabilidade de configuração dos protocolos de comunicação mais antigos em nova versão do sistema operacional dos servidores. Período de desativação: - Protocolos SSL e TLS 1.1: entre os dias 16 e 21/01/2020. - Protocolo TLS 1.0: entre os dias 21 e 30/01/2020. A partir do dia 30/01/2020, o Ambiente de Autorização dos DF-e deverá suportar unicamente o protocolo de comunicação TLS 1.2, conforme previsto na documentação técnica, vide NT 2016.002 da NF-e e NT 2017.002 do CT-e. Assinado por: Secretaria da Fazenda do Rio Grande do Sul

Boa tarde Alexandre, O mais interessante é a mensagem de erro que não deixa nenhuma margem de duvida sobre o problema. Analisando o XML do seu RPS não encontrei nada que poderia provocar algum tipo de erro. Com relação ao erro da primeira postagem, os campos que aparecem no erro não tem nada haver com a sua tabela que armazena as notas? Pois ele não esta conseguindo executar o INSERT na tabela NOTA.

Bom dia Rodrigo, Primeiramente, muito obrigado pelas informações. Vou analisar o problema referente ao arquivo TXT da versão 1.00 E essa questão do E comercial.

Bom dia Thiago, Pela imagem que você anexou se refere ao DAMDFE feito em Fast Report, correto? Se desejar colaborar com o projeto e fazer essa implementação, ficaremos gratos.

Olá Pessoal, Venho informa-los que já esta disponível em nosso repositório o mais novo componente que agora se integra a suíte ACBr. ACBrNF3e - Nota Fiscal de Energia Elétrica Eletrônica. Esse componente segue os moldes dos demais componentes que emitem DF-e - Documentos Fiscais Eletrônicos. "O Projeto NF3e tem como objetivo a implantação de um modelo nacional de documento fiscal eletrônico (modelo 66) que venha substituir a sistemática atual de emissão da Nota Fiscal/Conta de Energia Elétrica (modelo 6), com validade jurídica garantida pela assinatura digital do emitente, simplificando as obrigações acessórias dos contribuintes e permitindo, ao mesmo tempo, o acompanhamento da emissão em tempo real pelo Fisco." Para saber mais sobre o NF3e convido a todos a visitarem o Portal da Nota Fiscal de Energia Elétrica Eletrônica - SVRS. Temos também em nossa biblioteca toda a documentação referente a esse novo modelo de documento fiscal, clique aqui para acessar nossa biblioteca. O que foi disponibilizado: Fontes do componente ACBrNF3e e os fontes do componente ACBrNF3eDANF3eESCPOS (usado para imprimir o DANF3E). Notem que existe a Nota Técnica 2020/001 onde apresenta 3 layouts de DANF3E, sendo dois no tamanho A4 (Retrato) e um a ser impresso em bobina. Convido a todos a contribuir com a implementação dos DANF3E tamanho A4 (Retrato) e refazer o layout em bobina segundo essa nova NT. Esta disponível também os pacotes de instalação dos dois componentes mencionados acima, tanto para o Delphi quanto para o Lazarus. E como de costume, também foi disponibilizado o programa exemplo tanto para o Delphi quanto para o Lazarus. Observação: O ACBrInstall_Trunk2 ainda não reconhece esse componente, logo a sua instalação deverá ser realizar através dos pacotes disponibilizados. Assim que possível estaremos disponibilizando uma nova versão do ACBrInstall_Trunk2 que vai instalar o ACBrNF3e e o componente para imprimir DANF3E automaticamente.

Boa tarde Volmir, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Filipe, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Natan, Por favor anexe a unit alterada, assim fica mais fácil de nós analisarmos. Desde já muito obrigado pela colaboração.

Boa tarde Marcos, Muito obrigado pela colaboração, vou analisar as suas alterações e estando tudo OK vou enviar para o repositório. Só para deixar claro para todos, os dois fragmentos de código que você postou se refere a sua aplicação, correto?

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Natan, Favor atualizar os fontes e faça novos testes. Note que fiz uma alteração no arquivo INI do provedor Betha.

Boa tarde Tailan, Essas tags (vBCSTRet e vICMSSTRet) são geradas quando o CST é 60 ou Rep60 ou CSOSN é 500. No caso de CST = 60 e CSOSN = 500 é aplicado a condição que você mencionou na sua postagem, mas no caso do Rep60 não existe a condição. Favor conversar com um bom contador para saber em qual situação realmente devemos gerar as referidas tags. Se elas devem ser geradas, por exemplo quando o CST for 60, ai acredito que vai ser necessário criar uma propriedade de configuração, pois pelo que vi esse decreto diz respeito a somente a SC, as demais UF continuam da forma que esta hoje.

Boa tarde Rodrigo, É para estar funcionando a versão 1.00 também. Após enviar na versão 1.00 e realizar a consulta o TXT que contem os dados para imprimir a guia não é salvo em disco?

Bom dia Renan Eu entendi o que você deseja fazer, mas o problema é o seguinte: FPIniParamsCarregado é uma variável interna do componente e não uma propriedade que inicialmente vale False e depois muda para True e a qualquer momento você pode novamente alterar o seu valor para False. Portanto o que você deseja fazer não é possível. A solução mais simples é: corrigido o arquivo INI, deve-se finalizar a execução da aplicação e executa-la novamente. Ou você transformar essa variável interna em uma propriedade de configuração.

Boa tarde Júlio, Primeiramente muito obrigado pela colaboração, já enviei para o repositório. Segundo, os seus fontes estão desatualizados. Terceiro, favor utilizar o tópico que aparece em primeiro lugar para enviar colaborações de inclusão de cidades ou troca de provedor.

Boa tarde Camilo, Essa mensagem de erro é porque no Schema que temos não esta previsto o serviço GerarNfseEnvio. Favor testar com o método Enviar em vez do método Gerar. Entre em contato com o provedor/prefeitura para saber se eles possui um novo Schema.

Boa tarde, Muito obrigado pelo retorno. Assim que estiver funcionando os dois ambientes vamos fechar o tópico.

Boa tarde Sérgio, Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada? Se sim, compilou a sua aplicação com a opção Build? Se sim, na pasta que contem o executável consta o arquivo INI ACBrCTeServicos? Se sim, apague ele, pois possa estar desatualizado.

Boa tarde Paulo, A impressão do QR-Code é obrigatória tanto no DACTE do CT-e quanto do CT-e OS. A questão é, você esta usando o Fortes Report ou o Fast Report?

Boa tarde, Porque você deseja alterar o nome do XML?

Bom dia, Para que você deseja uma tabela completa? Sendo que, se o DF-e for rejeitado é retornado o código e a descrição de rejeição (cStat, xMotivo). Portanto não vejo nenhuma necessidade dessa tabela. Basta você ver no manual quais são os cStat que não são rejeições, como por exemplo: cStat = 100 significa que o documento foi autorizado pela SEFAZ.

Bom dia Rodrigo, Já tentou configurar o componente para a versão 2.00 do GNRE? Lembre-se que nessa versão o webservice retorna através da consulta o XML com as informações da guia. E é este XML que devemos carregar para imprimir a guia.

Boa tarde Camilo, Tentou usar SSLLib = libWinCrypt ?