Italo Giurizzato Junior

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.

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

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

Bom dia Everto, Muito obrigado pela colaboração, assim que possível vamos analisar e caso esteja tudo OK vamos enviar para o repositório.

Bom dia Everto, Será que não é o objeto referente ao código de barras que esta sobrepondo o objeto do QR-Code?

Bom dia Maílson, Muito obrigado, já inclui e vou enviar novamente para o repositório.

Bom dia Mendonça, Analisando o fragmento do seu XML que se encontra na sua primeira postagem, me diz uma coisa: Existe a tag vIMCSDeson? O correto não seria vICMSDeson ? Esse XML esta sendo gerado pela sua aplicação, correto?

Bom dia Maílson, Primeiramente desculpe pela demora em analisar a colaboração. Muito obrigado pela colaboração, já foi enviada para o repositório. Favor atualizar os fontes e faça novos testes.

Bom dia Filipe, Primeiramente desculpe pela demora em analisar a sua colaboração. Muito obrigado pela colaboração, já foi enviada para o repositório.

Bom dia Rafael, Se você deseja imprimir somente as autorizadas tem dois caminhos: executar o método Enviar(nLote, True) ou após o envio você limpa a lista de notas e carrega os XML das notas que foram autorizadas e execute o método Imprimir. Acredito que a solução mais simples é executar o método Enviar conforme mostrado acima. Com relação ao Preview que é gerado um para cada nota quando se utiliza o Enviar a resposta esta na própria rotina do Enviar, veja abaixo: NotasFiscais.Assinar; NotasFiscais.Validar; Result := WebServices.Envia(ALote, Sincrono, Zipado); if DANFE <> nil then begin for i := 0 to NotasFiscais.Count - 1 do begin if NotasFiscais.Items[i].Confirmada and Imprimir then NotasFiscais.Items[i].Imprimir; end; end; Note que após obter o retorno do envio a rotina verifica se existe um componente de DANFE linkado ao componente ACBrNFe, caso afirmativo é executado um loop onde o método Imprimir só é executado se a nota esta confirmada (Autorizada) e se o parâmetro Imprimir esta com o valor True. Isso explica ele gerar um Preview para cada nota. Agora se você quer somente um Preview para todas as notas que foram enviadas no lote e que foram autorizadas, acredito que a solução seja mesmo, após o envio, limpar a lista de notas do componente, carregar o XML das notas autorizadas e executar o método Imprimir.

Boa tarde Execom, Dependendo a informação que é colocada no XML pode ocorrer erro de validação. Neste caso o XML nem sequer foi enviado para a SEFAZ, sendo assim se faz necessário corrigir a informação que esta errada, gerar novamente o XML, assinar e validar. Se tudo der certo o passo seguinte é enviar. Agora se o XML foi gerado, assinado, validado, enviado e após o seu envio a SEFAZ retornou uma mensagem de Rejeição, é preciso fazer as devidas correções, gerar novamente o XML, assinar, validar e enviar. Vamos a um exemplo, informar um CFOP com 5 dígitos, isso gera um erro de validação. Informar o CFOP igual a 5050, com certeza a nota vai ser rejeitada, pois não existe esse CFOP. Notou a diferença entre erro de validação e rejeição?

Boa tarde Wesley, Tente da seguinte forma: XMLdoEventoAutorizado := ACBrNFe1.WebServices.EnvEvento.EventoRetorno.XML; Onde XMLdoEventoAutorizado é uma variável string.

Boa tarde Railson, 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 Marcel, Eu configuro o componente na minha aplicação da seguinte forma: // Configurações -> Arquivos with ACBrMDFe.Configuracoes.Arquivos do begin AdicionarLiteral := True; EmissaoPathMDFe := True; SepararPorMes := True; SepararPorModelo := False; SepararPorCNPJ := False; Salvar := True; PathMDFe := Trim(DM_CTA.ParamDFePathSalvar.AsString); // Lê o conteudo do campo PathSalvar da tabela ParamDFe PathEvento := Trim(DM_CTA.ParamDFePathSalvar.AsString); // idem PathSchemas := Trim(DM_CTA.ParamDFePathSchema.AsString); // Lê o conteudo do campo PathSchema da tabela ParamDFe PathMensal := GetPathMDFe(0); // PathMensal é uma variável do tipo String. PathSalvar := PathMensal; end; O conteúdo de PathSalvar no meu caso é C:\Erp\XML e o conteúdo de PathSchema é C:\Erp\Schema\MDFe

Olá pessoal, Aproveitando os últimos minutos do segundo tempo, temos novidades para o inicio do ano que vem. Novidades da versão 1.40 da NT 2019/001 * Modifica a RV N12-94 para deixar mais específica a rejeição, criando assim a RV N12-98 com sua respectiva rejeição; A regra vai ser ativada a partir de 11/05/2020 10/08/2020 em produção, verificando a existência e a vigência do cBenef. Assim, a RV N12-94, a partir dessa data, passará a verificar apenas se o cBenef é compatível com o CST. Essa nova regra permite que determinada UF possa validar apenas a existência do cBenef, caso não opte por validar a compatibilidade com o CST. A criação da RV N12-98 não traz impacto para os sistemas emissores que já estão preparados para a validação da RV N12-94, salvo o possível tratamento da mensagem da rejeição. Rejeição 946: Informado código de beneficio fiscal incorreto ou inexistente na UF. * Adiciona as exceções e modelos para as RV N12-85, N12-86, N12-90, N12-94, N12-97 e N12-98; Criação de Exceções para as Regras de Validação N12-85 (Se informado CST e não informado código de benefício fiscal), N12-86 (Se informado CST e informado código de benefício fiscal), N12-90 (Se CST de ICMS = (20, 30, 40, 41, 50, 70 ou 90)), N12-94 (Se informado CST e informado código de benefício fiscal), N12-97 (Não informados campos de valores do CST 51 (Diferimento)) e N12-98 (Se informado código de benefício fiscal) Trata-se de exceções que já haviam sido criadas e implementadas, tendo sido comunicadas por meio de aviso disponibilizado no Portal Nacional da NF-e. As Rejeições das Regras de Validação N12-85, N12-86, N12-90, N12-94 e N12-97 encontram-se no artigo referente a NT2019/001 versão 1.30 * Informa as Exceções e Datas aplicáveis as UF que ativaram as RV N12-85, N12-86, N12-90, N12-94 e N12-97; e que ativarão a N12-98; Quadro com datas de ativação das RV, respectivas exceções e possíveis modelos para UF que ativaram/estão ativando tais RV. Quadro já disponibilizado no Portal da NF-e. A única diferença é a indicação das opções de modelos (55; 65; ou 55/65). Tal quadro demonstra quais UF estão ativando as RV, bem como as exceções aplicadas e os modelos que de DF-e (55 e 65) em que se aplicam a tais RV. A tabela a seguir substitui a do item anterior (1.8), pois adiciona exceções e modelo aplicável. Na tabela a seguir encontram-se as Unidades da Federação que implementarão as Regras de Validação N12-85, N12-86, N12-90, N12-94, N12-97 e N12-98, previstas nesta Nota Técnica. Na legenda são encontradas as datas de aplicação, as exceções e os modelos aplicáveis (55/65), a critério da UF. Regra de validação - Aplicação e Exceções +----------------------------------------------------------------------------------------------------------+ | UF | N12-85 | N12-86 | N12-90 | N12-94 | N12-97 | N12-98 | +----------------------------------------------------------------------------------------------------------+ | PR | (D1), (55/65) | (D1), (55/65) | (D*) | (D2), (55/65) | (D1), (55/65) | (D3), (55/65) | +----------------------------------------------------------------------------------------------------------+ | RJ | (D2), (55/65) | (D2), (55/65) | (D2), (55/65) | (D2), (55/65) | (D2), (55/65) | (D3), (55/65) | | | (E2, E3) | (E2, E3) | (E2, E3) | (E2, E3) | (E2, E3) | (E2, E3) | +----------------------------------------------------------------------------------------------------------+ | RS | (D2), (55/65) | (D2), (55/65) | (D*) | (D*) | (D*) | (D3), (55/65) | | | (E3,E4) |(E3,E4) | | | | (E3,E4) | +----------------------------------------------------------------------------------------------------------+ |Demais UF | (D*) |(D*) | (D*) | (D*) | (D*) | (D*) | +----------------------------------------------------------------------------------------------------------+ Datas para aplicação das Regras de validação (D), com respectivo Modelo de DF-e: (D*) - Regra de validação não será aplicada; (D1) - Aplicação a partir de 02/09/2019; (D2) - Aplicação a partir de 01/10/2019; (D3) - Aplicação a partir de 11/05/2020 10/08/2020 em Produção (Homologação: 16/03/2020) Aplicação aos Modelos de DF-e: (55); (65); ou (55/65) Exceções constantes nas Regras de Validação, a critério da UF: (E1) - Exceção 1: a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a Devolução de Mercadoria e Identificador de local de destino da operação (tag: idDest) igual a Operação interestadual ou com o Exterior. (E2) - Exceção 2: a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a Devolução de Mercadoria; (E3) - Exceção 3: a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a NF-e de ajuste; (E4) - Exceção 4: a RV não se aplica quando Tipo de Operação (tag: tpNF) igual a Entrada. Observação: A Exceção 1, constante nas respectivas Regras de Validação, aplica-se a todas as UF. Assim, não necessita estar no quadro acima. As datas aqui definidas, juntamente com todas as demais informações a respeito das regras de validação opcionais por UF, podem ser consultadas em tabela publicada no Portal Nacional da NFC-e, na área “Regras de Validação” da aba “Desenvolvedor”. Para contribuintes estabelecidos no Estado do Rio Grande do Sul, as Regras de Validação N12-85 e N12-86 permitirão informar qualquer CST até 31/03/2020 no ambiente de autorização em produção, conforme tabela disponibilizada no Portal da NF-e. Em homologação, o contribuinte já pode testar a validação dessa Regras. A RV N12-94 será desativada para o Rio Grande do Sul a partir da publicação desta NT.  A RV N12-98 será ativada conforme as datas de homologação e produção previstas nesta NT. * Retira o modelo 65 da validação da RV B03-10 Datas de efetivação das modificações: Ambiente de Homologação: 16/03/2020 Ambiente de Produção: 11/05/2020 (10/08/2020) Como se tratam de regras de validação nos WebServices das SEFAZ-Autorizadoras, não se faz necessário nenhuma alteração nos fontes dos componentes e nem na aplicação. Para baixar a NT na integra favor acessar a nossa biblioteca.

Lucas, Estranho, não tive problemas nos meus testes.

Bom dia Natan, Já enviei a sua alteração para o repositório, muito obrigado pela colaboração.