Italo Giurizzato Junior

Bom dia Lukas, Primeiramente desculpa pela demora na analise da sua contribuição. Aparentemente esta tudo correto, já se encontra no repositório. Muito obrigado pela contribuição.

Bom dia David, Se tratando de MDF-e não importa de qual UF seja o Emitente, todos os MDF-e vão para a SVRS - SEFAZ-Virtual do Rio Grande do Sul. Sendo assim, você tem que entrar em contato com a SEFAZ-RS e não com a SEFAZ-SP.

Bom dia Thiago, Desculpa eu não entendi. Você chegou a fazer as alterações? Se sim, poderia anexar a unit alterada para que possamos analisar e caso esteja tudo OK enviaremos para o repositório. Desde já muito obrigado pela colaboração.

Bom dia Ana Paula, Onde você conseguiu essa NT? Pois no Portal do MDF-e não consta ela.

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

Bom dia Túlio, Muito obrigado pela colaboração, já enviei para o repositório.

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

Bom dia a todos, É sabido que a SEFAZ-MG tem pata de elefante, onde põe a mão ferra tudo. Favor entrar em contato com a SEFAZ e expor o problema. Verifique também se não há necessidade de atualizar a cadeia de certificados da SEFAZ.

Bom dia Robinho, O que tudo indica não esta correta. Não abre no navegador. Favor entrar em contato com os responsáveis pelo webservice e solicite as novas URLs.

Bom dia César, Primeiramente desculpa pela demora na analise na sua contribuição. Muito obrigado, já se encontra no repositório.

Bom dia Gustavo, Primeiramente peço desculpa pela demora na analise da sua contribuição. Muito obrigado, já analisamos e enviamos para o repositório.

Bom dia, Primeiramente peço desculpa pela demora na analise da sua contribuição. Segundo, não se fez necessário nenhuma alteração no arquivo DFM somente no PAS da unit?

Bom dia a todos, Gostaria de agradecer a todos que colaboraram com a implementação e com os testes. Postei uma noticia sobre o novo layout de impressão. Douglas, vou fechar esse tópico, assim que você fizer as correções com relação aos labels favor criar um novo tópico.

Olá Pessoal, Já se encontra em nossa biblioteca a NT 2020/001 da NF-e segue abaixo um resumo sobre ela. Resumo: Este documento substituirá as Notas Técnicas(NT) 2012.002 e 2013.001 e tem por objetivo unificar as informações referentes à manifestação do destinatário na Nota Fiscal eletrônica (NF-e) modelo 55 e estender o serviço para ser usado também por Pessoa Física (CPF). A manifestação está prevista na cláusula décima-quinta-A do Ajuste SINIEF 7/2005, a qual permite que o destinatário da Nota Fiscal eletrônica confirme a sua participação na operação acobertada pela Nota Fiscal eletrônica emitida para o seu CNPJ/CPF, através dos eventos tratados a seguir. 3 - Prazos para realização dos eventos de manifestação do destinatário Evento Prazo legal(Ajuste SINIEF 44/20) Ciência da Emissão 10 dias contados a partir da data de autorização da NF-e Confirmação da Operação 180 dias contados a partir da data de autorização da NF-e Desconhecimento da Operação 180 dias contados a partir da data de autorização da NF-e Operação Não Realizada 180 dias contados a partir da data de autorização da NF-e 4 -Obrigados a realização da manifestação do destinatário A cláusula décima-quinta-B do Ajuste SINIEF 7/2005 prevê a obrigatoriedade do registro pelo destinatário da NF-e dos eventos de confirmação da operação, operação não realizada e desconhecimento da operação nos prazos especificados naquele Ajuste. Também está obrigado a realizar a manifestação, de acordo com o Anexo II do Ajuste SINIEF 7/2005, o destinatário de toda NF-e que: I – seja exigido o preenchimento do Grupo Detalhamento específico de Combustíveis, como nos casos de mercadoria destinada a: a) estabelecimentos distribuidores de combustíveis, a partir de 1º de março de 2013; b) postos de combustíveis e transportadores revendedores retalhistas, a partir de 1º de julho de 2013; II - acoberte operações com álcool para fins não-combustíveis, transportado a granel, a partir de 1º de julho de 2014; III – acoberte, nos casos em que o destinatário for um estabelecimento distribuidor ou atacadista, a partir de 1º de agosto de 2015, a circulação de: a) cigarros; b) bebidas alcoólicas, inclusive cervejas e chopes; c) refrigerantes e água mineral. Obs: a NT 2012/003 (item 03.1), publicada em agosto/2012, define quais são os CFOP que obrigam a informação do Grupo de Combustível na NF-e. Os CFOP citados estão relacionados com as operações que envolvem “Combustível derivado ou não de Petróleo e Lubrificantes”. • Como as operações com lubrificantes são exceção à obrigatoriedade de manifestação do destinatário, consta no Anexo II a tabela de Códigos de Produto da ANP relativa a lubrificantes e que não estão obrigados à Manifestação do Destinatário Conclusão: Não existe nenhuma implementação a ser feita no componente, simplesmente agora a pessoa física que possui um e-CPF (Certificado Digital) poderá realizar a Manifestação do Destinatário, ou seja, enviar para a SEFAZ um dos 4 tipos de eventos que engloba a Manifestação do Destinatário. O componente já esta apto a gerar o XML do respectivo evento com o CPF do destinatário em vez do CNPJ.

Boa noite Walmi, O arquivo INI que você utilizou para comparar com o manual foi obtido de onde? Pois o arquivo INI do evento S1200 que se encontra na pasta: ...\Exemplos\ACBrDFe\ACBreSocial\ArqINI esta totalmente diferente do que você utilizou para fazer a comparação.

Olá pessoal, Alguém já imaginou ou tem a necessidade de imprimir o boleto em uma impressora térmica? Pois bem, o @guilhermekm teve a necessidade, arregaçou as mangas e implementou um novo layout chamado lTermica80mm. Guilherme, muito obrigado pela colaboração, já esta disponível no repositório. Quero também agradecer ao @Doug Dela Bite pelos ajustes feitos na implementação do Guilherme, muito obrigado Douglas. Abaixo o Preview e a impressão do boleto feita em uma Epson TM-T20X. Esse layout esta disponível apenas para o Fortes Report, portanto convido aos mestres em Fast Report a fazerem o mesmo que o Guilherme e Douglas. Estou aguardando o layout para o Fast! Compatibilizei o LFM do Lazarus com o DFM do Delphi, sendo assim é para funcionar sem nenhum problema no Lazarus / Fortes Report. Veja aqui o tópico original:

Bom dia Valmir, O que esta divergente? Esta faltando alguma coisa no arquivo TXT de exemplo ou as seções estão fora de ordem comparado com o layout que se encontra no manual?

Bom dia a todos, Com os fontes disponibilizados pelo Guilherme a impressão do boleto ocorreu sem nenhum problema em uma impressora Epson TM-T20X. A impressão ficou um pouco falha, acredito que deva ser o papel que estou usando que é de má qualidade. Hoje em dia, são poucos que vão até ao banco pagar um boleto e quando vão realiza o pagamento nas maquinas de autoatendimento. Sendo assim hoje o que realmente o que interessa para efetuar o pagamento do boleto é o seu código de barras ou a linha digitavel e é claro o boleto estar registrado. Portanto se o boleto foi impresso em papel A4 ou Carta ou Bobina, pouco interessa. A única questão de imprimir o boleto em uma impressora térmica é o clareamento da imagem, na empresa que eu trabalhava o pessoal tinha o costume de tirar um fotocopia de todos os documentos impressos em impressora térmica. Gostaria de saber se mais alguém consegui ou esta com problemas de imprimir o boleto na impressora térmica usando o programa exemplo do componente ACBrBoleto.

Boa noite Marcio, Eu recomendo você entrar em contato com a agencia da Caixa do seu cliente, pois se não me falha a memória cada agencia trabalha de uma forma diferente. Algumas disponibilizam aos seus clientes uma aplicativo próprio, outras é utilizado um aplicativo de um parceiro da Caixa. Se tratando de Boletos, a Caixa já possui um webservice onde a sua aplicação gera um XML com os dados do boleto e o envia para que o mesmo seja registrado. A equipe ACBr esta trabalhando para disponibilizar uma nova versão do componente ACBrBoleto que vai contemplar essa modalidade de envio.

Bom dia Luiz, Não precisa de nenhuma configuração especial. 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?

Bom dia Josué, Em uma rápida olhada no Manual, notei que esse provedor não segue o layout da ABRASF, ou seja, possui um layout próprio. Sendo assim se faz necessário criar uma unit para gerar o XML desse provedor segundo o seu layout. Depois será necessário fazer farias alterações nas demais unit para que o componente reconheça esse novo provedor bem como a leitura dos retornos e a geração dos XMLs de Consulta e Cancelamento. E para finalizar criar um arquivo INI para o provedor que vai conter as configurações e a definição dos Envelopes de cada serviço e por fim a inclusão da respectiva cidade no arquivo Cidades.ini Outra coisa o código IGBE que você postou acredito que esteja errado, pois normalmente esse código possui 7 dígitos. O correto é: 2924009 Se desejar contribuir com o projeto fique a vontade em fazer a implementação.

Bom dia ALA, Primeiramente a Inutilização não é um evento, logo não devemos salvar junto com os XML de eventos. Os XML de inutilização de números são salvos na pasta ..\Inu já os eventos são separados por tipos, dentro da pasta ...\Evento temos uma pasta para cada tipo de evento, no caso de cancelamento temos ...\Evento\Cancelamento e dentro desta temos os XML de cancelamento. Em vez de deixar a cargo do usuário pegar os XML de uma determinada pasta e enviar para o contador, porque você não implementa uma opção na sua aplicação que faça isso?

Bom dia Magnu, O cancelamento é um evento sendo assim é gerado 3 XML, sendo que o primeiro é *-ped-eve.xml (pedido de evento), *-eve.xml (retorno da SEFAZ), *-procEventoBPe.xml (Evento processado). Esse ultimo é o que devemos guardar e enviar aos interessados, pois ele contem o pedido (no seu caso o pedido de cancelamento) assinado digitalmente e o retorno da SEFAZ que contem o protocolo e o status que acusa que o evento foi aceito e vinculado ao documento. Agora me diga uma coisa, esses arquivos não estão sendo salvos ou estão sendo salvos mas não esta obedecendo a configuração? Se não esta salvando é porque você não ativou a opção que faz com que os arquivos referente aos eventos sejam salvos. A pasta onde os eventos de cancelamentos são salvos é: ...\Evento\Cancelamento Para finalizar o XML do BPe que foi inicialmente enviado e que contem o protocolo de autorização, este não vai sofrer alteração ao realizar o seu cancelamento. Lembre-se, no caso cancelamento temos 2 XML, o XML do BP-e que deve estar assinado e com o protocolo de autorizado (isso faz com que esse arquivos tenha valor jurídico conforme consta na legislação) e o XML *-procEventoBPe.xml (referente ao cancelamento) que para ter validade jurídica, também tem que conter o pedido de cancelamento, estar assinado e conter o protocolo que homologa o cancelamento. Na legislação, no Manual e em nenhuma Nota Técnica diz que ao realizar o cancelamento de um Documento Fiscal Eletrônico devemos substituir o protocolo de autorização pelo de cancelamento.

03/01/2020 Liberado ambiente de produção da SVRS O ambiente autorizador da Sefaz Virtual está disponível para emissão em produção da NF3e. As empresas interessadas deverão contatar a Unidade Federada de sua circunscrição para verificar condições para habilitação à emissão deste documento eletrônico.

Bom dia Leonardo, Respondendo as suas perguntas: 1. Não, você só consegue consultar uma nota via site ou através do método Consultar se tiver a chave completa da nota. 2. A chave possui um campo chamado Código da Nota que por orientação da SEFAZ deve ser um código aleatório composto por 8 dígitos. Aconselho utilizar a função GerarCodigoDFe para gerar esse código (leia o artigo: Código Inválido Chave Não Gerada) Esse código deve ser salvo no banco de dados juntamente com os demais dados da nota e quando for alimentar o componente para gerar o XML, você deve ler esse código e atribuir ele ao campo cNF. 3. Se você seguir o conselho acima, jamais você vai ter rejeição de duplicidade com diferença de chave. Para eliminar de vez com o problema de duplicidade, além de seguir o conselho acima, se ocorrer algum erro ao enviar a nota jamais tente enviar novamente e sim realizar uma consulta com a nota carregada. Pois você não sabe se o erro ocorreu no envio ou no retorno do protocolo. Se ao consultar a SEFAZ retornar a mensagem informando que a nota não consta na base de dados, ai sim temos a certeza que o erro ocorreu no envio, logo podemos enviar novamente. Por outro lado se o erro ocorreu no retorno, realizando essa consulta a SEFAZ vai retornar o protocolo de autorização ou a rejeição caso a nota tenha alguma informação errada. Se a nota for rejeitada, o usuário deve providenciar as devidas correções e enviar novamente.