Italo Giurizzato Junior

Boa tarde, Muito obrigado, vamos analisar e tentar encontrar uma solução para o problema. Uma das coisas que notei em relação a assinatura é que no componente temos: <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> Já no exemplo deles temos somente uma transformação: <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> Será que não é isso que esta fazendo com que a assinatura realizada pelo componente se torna invalida para eles.

Boa tarde Marcel, Quanto ao componente ACBrMDFe já esta quase pronto para ficar em conformidade com a Nota Técnica 2020/001. Acredito que até o final da semana que vem já vai estar pronto. Mas só vamos poder iniciar os testes a partir de 09/03/2020. Caso alguém queira colaborar em tentar descobrir o que esta ocorrendo com o ACBrCIOT ficarei grato.

Bom dia a todos, Desculpa ser repetitivo, mas vou postar aqui um trecho da Nota Técnica 2020/001 do MDF-e. Publicação dessa NT, que estrutura o MDF-e de forma a possibilitar, entre outros benefícios: Geração automática do CIOT, pelo Sistema MDF-e, tanto para as modalidades TAC-Independente como TAC-Agregado; Automação do processo de fiscalização do Piso Mínimo do Frete (Tabela do Frete), nos termos da Resolução ANTT nº 5.849 de 16 de julho de 2019. Geração de informações para facilitar a negociação de direitos de recebimentos de fretes, por parte do TAC, junto a instituição financeira onde possui conta corrente, sem a interferência de atravessadores. Datas: Ambiente de Homologação: 09/03/2020 Ambiente de Produção: 06/04/2020 Pergunto a vocês, isso não vai de encontro com o que a ANTT deseja?

Bom dia Werner, Já temos um tópico discutindo sobre o componente ACBrCIOT. Vamos manter apenas um, portanto vou fechar esse. Obrigado pela compreensão.

Bom dia Marcos, Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr e por fim faça novos testes.

Boa tarde Marcel, E como que fica com relação as mudanças que vão ocorrer no MDF-e? Sendo que uma delas é poder gerar o CIOT via MDF-e.

Olá Pessoal, Encontra-se disponível em nossa biblioteca a nova versão da NT 2017/002. Resumo: Esta edição insere novos registros e indicadores na Tabela CFOP publicada no Portal da NF-e. A Tabela CFOP, disponibilizada no Portal Nacional da NF-e, fica atualizada com novos registros para o atendimento das cláusulas previstas no Ajuste SINIEF 27/19, sendo que o mesmo Ajuste também altera CFOP existentes. Ajuste SINIEF 27/19 – Alteração e Inclusões de CFOP com as respectivas Notas Explicativas CFOP alterado 5.929 – Lançamento efetuado em decorrência de emissão de documento fiscal relativo a operação ou prestação também acobertada por documento fiscal do varejo. Classificam-se neste código os registros relativos aos documentos fiscais emitidos em operações ou prestações que também tenham sido acobertadas por documento fiscal do varejo. CFOP incluídos 1.657 - Retorno de remessa de combustível ou lubrificante para venda fora do estabelecimento. Classificam-se neste código as entradas em retorno de combustível ou lubrificante remetidos para venda fora do estabelecimento, inclusive por meio de veículos, e não comercializados. 2.657 - Retorno de remessa de combustível ou lubrificante para venda fora do estabelecimento. Classificam-se neste código as entradas em retorno de combustível ou lubrificante remetidos para venda fora do estabelecimento, inclusive por meio de veículos, e não comercializados. Datas de liberação: Ambiente de Homologação: 15/01/2020 Ambiente de Produção: 03/02/2020

Secaio, Lembre-se que o componente gera e envia o XML do RPS, já o webservice do provedor gera e retorna o XML da NFS-e. Vou dar uma olhada nos schemas.

Bom dia Bruno, Muito obrigado pela colaboração, já enviei para o repositório. Observação, os seus fontes estão desatualizados.

Bom dia José, Chegou a fazer testes usando o programa exemplo?

Bom dia Secaio, O ACBr gera essas TAGs? Até onde seu o provedor Tecnos segue a versão 2 do layout da ABRASF e a unit referente a essa versão não gera essas TAGs.

Bom dia Luiz, O que você esta utilizando (Fortes ou Fast Report) ?

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

Bom dia Henrique, Primeiramente, por favor não poste conteúdo de arquivos (por exemplo XML) como parte da postagem, procure sempre anexar. Segundo, o seu XML não me parece ter sido gerado pelo componente ACBrNFSe. Você esta gerando o XML através da sua aplicação e depois esta usando o componente para assinar e enviar?

Bom dia Luiz, Todos os provedores que seguem a versão 2 do layout da ABRASF não tem o método Consultar Situação do Lote implementado, uma vez que nessa versão não existe esse serviço. Sendo assim o método a ser utilizado é Consultar Lote RPS: ACBrNFSe1.ConsultarLoteRps(NumeroLote, NumeroProtocolo);

Bom dia Leandro, Já enviei para o repositório.

Bom dia Lutzem, Já enviei para o repositório.

Bom dia Lutzem, Já enviei para o repositório.

Bom dia Daniel, Sim, usando o programa exemplo do componente ACBreSocial ao solicitar o Download seja pelo ID ou pelo numero do Recibo, o erro 500 ocorre caso o componente esteja configurado para o ambiente de produção. Já em ambiente de homologação o webservice demora para responder mas não ocorre o erro 500 e sim uma rejeição (em anexo). 20200114100340-dow-soap.xml

Bom dia Rodrigo, Favor anexar o XML que esta sendo rejeitado.

Bom dia Camilo, O método GerarXMLs que eu me refiro se encontra na unit ACBreSocialEventos. Veja: procedure TEventos.GerarXMLs; begin Gerar; Assinar; Validar; end; Cada unit de evento possui o seu GerarXML que agora apenas gera o XML. Já o GerarXMLs que se encontra na unit ACBreSocialEventos como você pode ver chama os 3 métodos novos, ou seja, gera, assina e valida.

Nelson, Me enganei, o namespace não foi alterado. É que existe o namespace da tag <eSocial> e o da tag <Envelope>. Notei que tanto o download pelo ID ou pelo numero do Recibo no ambiente de produção ocorre o erro 500, já no ambiente de homologação esse erro não ocorre. As URLs utilizadas pelo componente estão corretas, os namespace estão corretos e os SoapAction também. O XML de pedido de Download após ser gerado e assinado é validado, portanto esta em conformidade com os schemas. Realmente não sei o que pode esta ocorrendo.

Nelson, O que tudo indica é que houve uma alteração do namespace no webservice. O namespace que consta no XML esta diferente do wsdl. Vou fazer as alterações e enviar para o repositório.

Bom dia Nelson, É salvo o XML de pedido de Download (*-ped-dow.xml)? Se sim, favor anexar.