Italo Giurizzato Junior

Bom dia @douglasKrafti,
Não sei se é o seu caso, mas o componente estava gerando o mesmo identificador para os dois ambientes: homologação e produção.
Se você enviava uma nota de numero 10 para o ambiente de homologação e depois a nota de numero 10 para o ambiente de produção, o provedor recusava a nota informando que já existia uma nota com o mesmo identificador.
Foi feita uma alteração no componente visando contornar esse problema, alteração esta enviada para o SVN no dia 11/01/2024 conforme consta no change-log, veja:
11/01/2024 -- IPM.LerXml -- (...) -- IPM.GravarXml -- [*] Alteração no profeixo da tag <identificador> para quando o envio for para teste. Se produção usar "nfse_" se homologação usar "nfseh_". -- IPM.LerXml -- [*] Incluido a leitura da tag <data_fato> que é a data de competencia. Por: Diogo Loff Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e por fim recompile a aplicação.

Boa noite Jéter,
Acabei de enviar uma alteração na unit ACBrNFSeXWebserviceBase que visa essa questão do encoding diferente utilizado pelo provedor NFSeBrasil.
Por favor atualize os fontes e faça um novo teste com a alteração que fiz na unit mencionada.

Bom dia @xim.logan,
No programa exemplo do componente ACBrNFSeX temos 3 procedure para exemplificar a alimentação do componente com os dados do serviço prestado.
Como você notou tem uma procedure referente ao layout da ABRASF, devemos nos basear nessa procedure se o provedor segue a verão 1 ou 2 do layout da ABRASF.
A procedure referente ao layout próprio, devemos nos basear nessa procedure se o provedor não segue o layout da ABRASF.
Por fim, a procedure referente ao layout do Padrão Nacional nos apresenta como alimentar o componente se o prestador de serviço for MEI ou se a cidade em questão aderiu a emissão das notas de seus contribuintes segundo o Padrão Nacional.

Boa tarde Alexsandro,
Acredito ser um problema no Web Service, pois se fosse alguma informação errada era para ele acusar qual é a informação que esta errada.

Boa tarde @daniel_mirassol,
Veja o código do botão [Criar e enviar síncrono] do programa exemplo.

Bom dia @Michel Szakall,
Se a sua ideia é trocar no XML do CT-e o protocolo de autorização pelo de cancelamento, esquece.
No ajuste SINIEF numero 9 de 25/10/2007 que instituiu o CT-e, em nenhum Manual (desde a versão 1) em nenhuma Nota Técnica diz que essa troca pode ou deve ser feita e como fazer.
Muito pelo contrario segundo o ajuste SINIEF diz que o XML tem validade jurídica se o mesmo estiver assinado digitalmente e com o protocolo de autorização.
§ 1º Considera-se Conhecimento de Transporte Eletrônico - CT-e - o documento emitido e armazenado eletronicamente, de existência apenas digital, com o intuito de documentar operações e prestações, cuja validade jurídica é garantida por uma assinatura eletrônica qualificada e pela autorização de uso por parte da administração tributária da unidade federada do contribuinte, antes da ocorrência do fato gerador. O que você tem que enviar ao contador, ao tomador do serviço é o XML do CT-e autorizado e o XML do seu cancelamento.
O componente gera o XML *-procEventoCTe.xml, esse XML contem o pedido de cancelamento, esta assinado digitalmente e contem o protocolo da SEFAZ que atesta que o cancelamento foi homologado, ou seja, aceito.
O que o componente ACBrNFe faz de permitir a troca dos protocolos é uma aberração, repito, isso não existe, isso não esta documentado pelo Fisco.
Se o contador ou o tomador pedir, peça a ele um documento emitido pelo Fisco que diz que essa troca pode ser realizada.
O componente ACBrCTe permite que você carregue o XML assinado e protocolado e depois realize a sua consulta.
Se o CT-e em questão foi cancelado será retornado o evento de Cancelamento e o componente cria um novo XML chamado *-CTeDFe.XML que contem o XML do CT-e assinado e com o protocolo de autorização mais o evento de cancelamento também assinado e com o protocolo de homologação.
 

Bom dia Douglas,
Você tem fontes do ACBr com alterações locais?
Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit.
Atualize todos os fontes de todas as pastas.
Reinstale o ACBr com a opção de apagar arquivos antigos marcada.
Compile a aplicação com a opção Build.
Por fim repita os testes.
 

Bom dia @PHCASTANHO,
Isso aqui esta errado:
F_DM.ACBrCTe1.Conhecimentos.Add.CTe.infCTe.versao := 4.0; F_DM.ACBrCTe1.Conhecimentos.Add.CTe.Ide.cUF := 0125 ; // UFtoCUF(edtEmitUF.Text); F_DM.ACBrCTe1.Conhecimentos.Add.CTe.Ide.CFOP := 6932; (...)  
O correto é:
With F_DM.ACBrCTe1.Conhecimentos.Add.CTe do begin infCTe.versao := 4.0; Ide.cUF := 0125 ; // UFtoCUF(edtEmitUF.Text); Ide.CFOP := 6932; (...) end; Cada ADD executado o componente entende que você deseja adicionar mais um item (CT-e) a lista.
Outra coisa de onde você tirou o código 0125 ?
Todas as UF possuem um código IBGE formado por 2 dígitos.
Por favor estude o programa exemplo do componente, tenha em mãos os manuais do CT-e, caso contrario você não vai sair do lugar.

Paulo,
Já esta no SVN.

Boa tarde Fernanda,
Tente desta forma:
[3133600] Nome=Itapeva UF=MG Provedor=Fiorilli Versao=2.00 ProRecepcionar=http://nfe.sgpcloud.net:9134/IssWeb-ejb/IssWebWS/IssWebWS ProLinkURL=http://nfe.sgpcloud.net:9134/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso%  

Boa noite @[email protected],
Já esta no SVN.
Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Bom dia @Alexandre Felippeto Henzen,
Fica complicado em lhe dizer onde esta o problema.
O próprio provedor não ajuda, isso é mensagem de retorno: "Ocorreu um erro no processamento do arquivo" ?
Ok, ocorreu um erro, mas o que provocou o erro?
Você tem dois caminhos a seguir:
1. Entrar em contato com o prefeitura/provedor novamente e expor o problema, mostrar o XML enviado e o que você obteve de retorno, quem sabe eles possam lhe dizer o que esta de errado no XML de envio que provocou esse erro no processamento.
2. Fazer um teste de envio no ambiente de produção, enviar uma nota no valor de 1 real e depois via site realizar o cancelamento da mesma.
Para você ter uma ideia, o ambiente de produção da NFS-e Padrão Nacional esta bugado, cheguei a relatar os problemas para o pessoal da RFB.
A resposta que eu tive foi, tenta emitir em produção, pois o pessoal do SERPRO (responsável pela API da NFS-e Padrão Nacional) estão focados em resolver os problemas do ambiente de produção, neste momento eles não vão mexer no de homologação.

Bom dia @johni,
Normalmente a mensagem de dados não contem o encoding, que neste caso é o conteúdo da tag <xml>, mas esses provedores são todos malucos, os caras bebem gasolina.
Eu também acredito que o problema é do lado deles.

Bom dia Alex,
Como você utiliza o componente ACBrCTe vai ai algumas dicas:
Primeira
Você tem fontes do ACBr com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Segunda
Use o programa exemplo do componente para os testes conforme o nosso amigo Julionar já lhe passou. Terceira
O componente possui a propriede de configuração chamada VersaoDF, que tem que estar com o valor ve400 Ao alimentar o componente com os dados do CT-e não esqueça de também invormar o valor 4.0 ao campo versao: infCTe.versao := 4.0; Quarta
O envio do CTe da versão 4 tem que ser unitário, portanto não existe mais o envio em lote de até 50 CT-e. O modo de envio na versão 4 é síncrono, portanto já temos o resultado do processamento logo no retorno do envio, isso significa que não temos mais o numero do recibo e portanto não se faz necessáro realizar a consulta logo após o envio. Quinta
Estude o programa exemplo, pois houve algumas alterações no layout. Estude o código do botão [Criar e Enviar Sincrono]. Alex, você não acha que esta muito atrasado com os testes?
O ambiente de homologação foi liberado em abril de 2023 e o de produção em junho de 2023.
Quem fez o dever de casa já esta emitindo o CT-e na versão 4 a 7 meses.
O componente foi alterado para suportar a versão 4 em março de 2023 e essas alterações disponibilizadas no dia 30/03/2023 conforme consta no change log do componente.
30/03/2023 -- Diversos-- [*] Alteração visando a versão 4.00 do CT-e. por: Italo Giurizzato Junior Se você ainda tem uma esperança que o Fisco vai prorrogar, pode tirar o seu cavalinho da chuva, participei de uma reunião onde estava presente dois servidores da RFB e ambos deixaram muito bem claro: Não vai haver prorrogação.

Bom dia @Mcq Desenvolvimentos,
Diga a seu cliente que querer não é poder.
Vamos ao que interessa, o DAMDFE disponibilizado pelo Projeto ACBr segue o layout estabelecido pelo manual disponibilizado pelo Fisco.
E nesse manual temos o seguinte:

Como você pode ver não esta previsto a impressão das UF que fazem parte do percurso, somente a UF inicial (Carregamento) e a UF final (Descarregamento).
Se ele insiste, você pode sem problema algum informar as UF de percurso no campo de Observações.
Se você alterar o layout corre o risco de algum fiscal de fronteira entre os estados não gostar da alteração e resolver autuar o seu cliente.
Se ele quer porque quer essa alteração, faça ele assinar um documento que te exime de qualquer problema futuro.
Por fim, nós do Projeto ACBr não vamos fazer essa alteração, como já exposto acima fere o layout disponibilizado pelo Fisco.
 

Boa tarde @gerasoft,
Se o XML da NFS-e for o XML gerado pelo webservice do provedor, através do LoadFromFile(nomearquivo, False) você consegue sim ler os dados e com isso alimentar o seu sistema.

Bom dia Mateus,
Vamos ao Schema (EnviarLoteRpsSicronoEnvio.xsd) do provedor Tecnos:

Observe que dentro do elemento Rps temos o elemento tcDeclaracaoPrestacaoServico que dentro deste temos o elemento InfDeclaracaoPrestacaoServico e que dentro deste temos o elemento OutrasInformacoes.
Resumindo, ao enviar um Rps para o webservice do provedor Tecnos podemos informar o elemento (tag) OutrasInformacoes.
O XML da NFS-e é retornado ao consultar o lote ou consultar a NFS-e por faixa, sendo assim você também vai encontrar o elemento (tag) OutrasInformacoes definida dentro do elemento InfNfse nos schemas: ConsultarLoteRpsReposta.xsd e ConsultarNfseFaixaResposta.xsd
Agora vamos ao Schema (nfse.xsd) do provedor DataSmart:

Como você pode observar dentro do elemento completo tcInfDeclaracaoPrestacaoServico não contem o elemento OutrasInformacoes como ocorre com o provedor Tecnos, mas o elemento OutrasInformacoes esta presente no tipo complexo tcInfNfse conforme imagem anexada na sua primeira postagem.
Não sei se você notou, o elemento OutrasInformacoes presente no tipo complexo tcInfNfse do schema do provedor DataSmart, ele é opcional, portanto ele pode estar presente ou não no XML da NFS-e gerado pelo webservice do provedor.
Por ser uma tag gerada pelo webservice do provedor, compete a nós ao ler o XML da NFS-e, ler o conteúdo da tag OutrasInformacoes caso ela esteja presente no XML.
Se você abrir a unit DataSmart.LerXml vai notar o seguinte:
TNFSeR_DataSmart202 = class(TNFSeR_ABRASFv2) protected public end; Isso significa que esse provedor segue a versão 2 do layout da ABRASF e a classe responsável pela leitura do XML é TNFSeR_ABRASFv2.
Essa classe esta definida na unit ACBrNFSeXLerXml_ABRASFv2.
Se você procurar por OutrasInformacoes na unit mencionada acima, vai notar que a sua leitura é feita pelas procedures LerInfNfse e LerInfDeclaracaoPrestacaoServico, isso garante que ao ler o XML da NFS-e a tag vai ser lida e ao ler o XML do RPS ela também vai ser lida caso o provedor alterou o schema para contemplar essa tag também no XML do RPS.
Resumindo: o componente faz a sua parte.
Agora se o provedor não gera a tag no XML da NFS-e, não tem o que fazer do nosso lado.
Você vai ter que entrar em contato com o provedor e questionar sobre a ausência da tag no XML da NFS-e.

Boa tarde @Paulo R G Oliveira,
Acabei de fazer um teste usando o programa exemplo do componente ACBrNFSeX de cancelamento veja o resultado:
------------------------------ Versão OpenSSL OpenSSL 3.1.3 19 Sep 2023 03.01.00.030 C:\ACBr\trunk2\Exemplos\ACBrDFe\ACBrNFSeX\Delphi\libcrypto-3.dll C:\ACBr\trunk2\Exemplos\ACBrDFe\ACBrNFSeX\Delphi\libssl-3.dll ------------------------------ Requisição Ambiente : 1 Cidade : Muriae/MG Provedor : Ginfes Versão: 1.00 Data/Hora: 25/01/2024 14:07:44 Método Executado: Cancelar NFSe Parâmetros de Envio Numero da NFSe: 10 Série da NFSe : Parâmetros de Retorno Situação: Link : Sucesso : False Retorno do Pedido de Cancelamento: Situação : Data/Hora: 30/12/1899 Mensagem : Sucesso : Link : Erro(s): Código : E160 Mensagem: Arquivo enviado fora da estrutura do arquivo XML de entrada. Correção: Envie um arquivo dentro do schema do arquivo XML de entrada. --------- O erro E160 ocorre porque o CNPJ do prestador informado no pedido de cancelamento não consta com contribuinte da referida cidade, mas como você pode ver a mensagem não tem nada haver.
O importante é que não ocorreu o erro: "Erro ao Assinar: Não encontrei final do elemento: </ns3:Pedido>".
 
Lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX
O componente antigo: ACBrNFSe não está mais tendo manutenção.
Faça os testes usando o programa exemplo do novo componente.
Manual de Migração
https://www.projetoacbr.com.br/forum/topic/63017-manual-de-migração-para-o-novo-componente-de-emissão-de-nfs-e/
 

Bom dia @PrimeSoftware,
Acabei de realizar um teste usando o programa exemplo do componente ACBrNFSeX, veja o resultado:
------------------------------ Versão OpenSSL OpenSSL 3.1.3 19 Sep 2023 03.01.00.030 C:\ACBr\trunk2\Exemplos\ACBrDFe\ACBrNFSeX\Delphi\libcrypto-3.dll C:\ACBr\trunk2\Exemplos\ACBrDFe\ACBrNFSeX\Delphi\libssl-3.dll ------------------------------ Requisição Ambiente : 1 Cidade : Primavera do Leste/MT Provedor : AssessorPublico Versão: 1.00 Data/Hora: 22/01/2024 10:51:48 Método Executado: Enviar Lote Assíncrono Parâmetros de Envio Numero do Lote: 1 Parâmetros de Retorno Data de Envio : 30/12/1899 Numero do Prot: Numero da Nota: Link : Código Verif. : Sucesso : False Erro(s): Código : Mensagem: O Usuário Informado no Web Services é Diferente do Usuário Informado no Arquivo XML Correção: Como eu usei um CNPJ cujo prestador de serviço não é da referida cidade é de se esperar esse tipo de retorno.
Outra coisa, veja esse fragmento de código que se encontra na unit AssessorPublico.Provider:
function TACBrNFSeXWebserviceAssessorPublico.GetDadosUsuario: string; begin with TACBrNFSeX(FPDFeOwner).Configuracoes.Geral do begin Result := '<nfse:Usuario>' + Emitente.WSUser + '</nfse:Usuario>' + '<nfse:Senha>' + LowerCase(AsciiToHex(MD5(AnsiString(Emitente.WSSenha)))) + '</nfse:Senha>'; end; end; Como você pode ver o componente já resolve a questão da criptografia MD5.

Boa tarde @jailsinhus,
Na propriedade de configuração VersaoDF só consta as versões 1.00 e 3.00, correto?
De onde você tirou essa ideia de versão 4.00 do MDF-e?
Não existe nenhum manual ou nota técnica informando que a versão do MDF-e vai mudar para 4.00
Depois de alguns meses a SEFAZ aceitando tanto a versão 3.00 quanto a 4.00 do CT-e, chega ao fim a versão 3.00 do CT-e na data de 31/01/2024.
O único documento que mudou de versão foi o CT-e, os demais continuam na mesma versão.

Bom dia @econdotta,
Esse IF que você comentou antes não tinha a condição: StringIsXML(FPRetorno).
Mesmo com ela ocorre o erro?

Boa tarde Diogo,
Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e inicie os testes de preferencia com o programa exemplo.

Boa tarde Felipe,
Já implementei o provedor e enviei para o SVN.
Essa implementação só foi feita no novo componente: ACBrNFSeX.
Atualize todos os fontes de todas as pastas e reinstale o ACBr.
Abra o arquivo ACBrNFSeXServicos.ini e veja o que eu escrevi na seção que se refere a Uberlândia/MG
Caso deseje realizar testes, no inicio desse arquivo INI existe uma instrução de como proceder.

Bom dia @m5sistemas,
Quanto a primeira postagem, caso não queira baixar todos os documentos que com certeza vai levar um tempo considerável, uma vez que o serviço de DistribuicaoDFe por Ultimo NSU retorna um lote de até 50 documentos.
Lembrando que esses Documentos podem ser XML de NF-e e também podem ser XML de Eventos, eventos estes indicando que a nota foi cancelada, eventos de registro de passagem do caminhão por um local como fronteira entre Estados ou Pedágio ou Fiscalização Eletrônica.
Se você dividir 31690 por 50 vai ter uma ideia de quantidade de vezes que deverá executar o DistribuicaoDFe para baixar tudo e considere um tempo de uns 3 minutos entre uma execução e outra, você vai ter uma ideia do tempo que vai levar.
Eu em particularmente não vejo problema em baixar os 100 últimos por exemplo.
 
Quanto a sua segunda postagem, lembre-se que se a empresa ficar 60 dias ou mais sem usar o serviço de DistribuicaoDFe, ao usar vai ser retornado essa mensagem mesmo tendo documentos a serem baixados.
A recomendação da SEFAZ é que aguarde 1 hora e tente novamente.
Dica importante:
Armazene no Banco de Dados a data e hora e o status da ultima execução do DistribuicaoDFe, desta forma você consegue calcular o tempo já decorrido da ultima execução em relação a nova solicitação de execução.
Com isso você pode impedir que o usuário execute novamente antes do prazo estabelecido.
Você pode estabelecer esses prazos.
Exemplo:
Se retornar que não tem mais documentos, você define um prazo de 65 ou 70 minutos, uma margem de segurança de 5 a 10 minutos a mais do exigido pela SEFAZ.
Se retornar os documentos e o ultNSU é menor que maxNSU, você define um prazo de 3 ou 5 minutos.
Se retornar os documentos e o ultNSU é igual a maxNSU, você define um prazo de 65 ou 70 minutos.
Com essas regras para a próxima execução o seu cliente nunca vai ser barrado por consumo indevido.
O status que eu me refiro na dica é:
1 - aguardar tempo curto (3 ou 5 minutos)
2 - aguardar tempo longo (65 ou 70 minutos)
Espero ter ajudado.

Bom dia Kleber,
O programa exemplo não é um emissor de CT-e.
Ele tem por finalidade lhe mostrar como configurar o componente, como alimentar o componente e uma codificação bem simples de como usar cada método implementado no componente.
O programa exemplo não se utiliza de um banco de dados, é por isso que a configuração do mesmo é salva em disco em um arquivo INI e os dados fictícios passados para o componente estão presentes no código em vez de ler de uma tabela do banco de dados.
Por ser dados fictícios é de se esperar que o CT-e gerado e enviado para a SEFAZ seja rejeitar.
Uma coisa posso lhe garantir o componente funciona, basta configurar ele corretamente e passar os dados corretos.
Dica, ao testar em homologação só informe a chave de uma NF-e se esta tenha sido também emitida em homologação, se você não tiver uma, em vez de informar os dados da NF-e (chave) informe os dados de um outro tipo de documento (infOutro) como por exemplo uma carta remessa de mercadoria.
Vide o Manual que contem o layout do CT-e.