Italo Giurizzato Junior

@Sergio Fuchs, Já esta no SVN.

Boa tarde @willian_delan, Já esta no SVN.

Boa tarde @Anderson Grolli, Já esta no SVN.

Boa tarde @Sergio Fuchs, Muito obrigado pela colaboração, já foi criado a TK-6301 para analise.

Bom dia @Rogério Ricardo Santos, Quero que você faça um teste de envio onde a tag Discriminacao não contenha um JSON. Seria interessante usar o programa exemplo do componente para esse teste.

Bom dia @NicolasSlox, Não vejo outra alternativa você entrar em contato com a prefeitura/provedor e expor o problema. Pode ser um bug no webservice do provedor que não esta aceitando essa informação no XML.

Bom dia @Anderson Grolli, Muito obrigado pela colaboração, já foi criado a TK-6296 para realizar a alteração.

Bom dia @willian_delan, Muito obrigado pela colaboração, já foi criado a TK-6289 para realizar a alteração.

Bom dia @Lucio Bittes, O novo componente ACBrNFSeX exige que o XML a ser lido tenha sido gerado pelo webservice e ter sido obtido através do mesmo. Se esses XML que você anexou foram baixados através do site das prefeituras as chances de não funcionar são grandes, pois o XML gerado e baixado via site nem sempre usa a mesma estrutura e a mesma nomenclatura das tag. Neropolis/GO se utiliza do provedor Sigep cujo webservice se baseia na versão 2 do layout da ABRASF. Se você abrir a uni ACBrNFSeXLerXml_ABRASFv2 vai notar o seguinte: NFSe.Numero := ObterConteudo(AuxNode.Childrens.FindAnyNs('Numero'), tcStr); NFSe.CodigoVerificacao := ObterConteudo(AuxNode.Childrens.FindAnyNs('CodigoVerificacao'), tcStr); Essas são as linhas responsáveis por ler o numero da nota e o código de verificação que se encontra no XML, presta muita atenção na grafia das tag: Numero e CodigoVerificacao. No XML que você anexou temos: <issweb:nfse> <issweb:numero>32</issweb:numero> <issweb:codigoValidacao>RHAK-I6K9</issweb:codigoValidacao> Notou que a grafia esta diferente? No XML esta: numero e o componente espera que seja: Numero. Essa diferença faz com que o componente não consiga ler a informação. Outra coisa, segundo o layout da versão 2 da ABRASF essas duas tags que eu mencionei estão dentro de um grupo chamado InfNfse e esse XML contem essas tags dentro de um grupo chamado nfse, totalmente diferente, logo o componente não vai conseguir ler mesmo. Entendeu porque o componente não faz a leitura do XML?

@Sandro Felipe Adad, Já esta no SVN.

Boa tarde @Anderson Grolli, Já esta no SVN.

@João Antônio, Já esta no SVN.

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.

Boa tarde @João Antônio, Muito obrigado pela colaboração, já foi criado a TK-6282 para a alteração.

Boa tarde @Marcelo Toller, Porque você deixou como padrão o modo de envio do lote como assíncrono? Quando o provedor disponibiliza os 3 modos de envio (Lote Assíncrono, Lote Síncrono e Unitário) damos como preferencia o modo de envio Lote Síncrono. Se você não deseja usar esse modo basta alterar o segundo parâmetro do método Emitir (exemplo abaixo). { O método Emitir possui os seguintes parâmetros: aNumLote (String) aModEnvio [meAutomatico, meLoteAssincrono, meLoteSincrono, meUnitario, meTeste] aImprimir (Boolean) Valor Padrão = True, portanto imprime o DANFSE } // meLoteAssincrono: Ajusta o Emitir para enviar um lote de Rps no modo Assincrono ACBrNFSeX1.Emitir(vNumLote, meLoteAssincrono);

Boa tarde @Sandro Felipe Adad, Muito obrigado pela colaboração, já foi criado a TK-6285 para analise.

@André Melim, Você pode fazer o seguinte: 1. Abra a unit RLZ.Provider e procure pela procedure: TACBrNFSeProviderRLZ203.Configuracao; 2. Inclua a linha: ConfigAssinar.CancelarNFSe := True; 3. Salve e feche o Delphi; 4. Reinstale o ACBr; 5. Compile novamente a aplicação e faça um novo teste.

Bom dia @Jeferson S Lima, Abra o arquivo ACBrNFSeXServicos.ini e leia as instruções que se encontram nas primeiras linhas do arquivo.

Bom dia @Rogério Ricardo Santos, Como assim não contem as duas assinaturas? Olha ai as duas tag Signature. A primeira é a assinatura do RPS, devemos assinar a tag InfDeclaracaoPrestacaoServico uma vez que é ela que contem o atributo Id cujo valor é usado na assinatura. A segunda é a assinatura do Lote, devemos assinar a tag LoteRps uma vez que é ela que contem o atributo Id. Pergunte para eles como deve ser o valor do atributo Id da tag LoteRps. Hoje esta sendo gerado com o valor "Lote_123" onde 123 é o numero do lote, pode ser que o webservice deles espera que o valor seja "ID_123".

Bom dia @Marcelo Toller, O que você alterou na unit Pronim.Provider ?

Bom dia @Anderson Grolli, Muito obrigado pela colaboração, já foi criado a TK-6281 para realizar a alteração.

Bom dia @André Melim, Analisando os arquivos que você disponibilizou noite o seguinte: 1. Para mim o pedido de cancelamento esta correto, verificar se há a necessidade de assinar o pedido de cancelamento, pois atualmente o componente não esta assinando. 2. O retorno do pedido de cancelamento esta da seguinte forma: Note que a tag <outputXML> esta vazia, ou seja, o webservice não gerou o XML de retorno do pedido de cancelamento, isso pode ser uma falha no webservice como também pode ser a falta de assinatura no pedido, mas neste caso deveria constar uma mensagem de erro acusando a falta da assinatura no pedido de cancelamento.

Olá Pessoal, Algumas units foram substituídas por outras com outros nomes mas com o mesmo conteúdo. Para quem emite CT-e/CT-e Simplificado/CT-e OS/GTV-e e por ventura faça uso em sua aplicação da unit pcteConsts deverá mudar o nome dela para ACBrCTe.Consts que se encontra na pasta: ...\Fontes\ACBrDFe\ACBrCTe\Base. Para quem emite MDF-e e por ventura faça uso em sua aplicação da unit pmdfeConsts deverá mudar o nome dela para ACBrMDFe.Consts que se encontra na pasta: ...\Fontes\ACBrDFe\ACBrMDFe\Base. Para quem emite NF-e/NFC-e e por ventura faça uso em sua aplicação da unit pcnNFeConsts deverá mudar o nome dela para ACBrNFe.Consts que se encontra na pasta: ...\Fontes\ACBrDFe\ACBrNFe\Base. Como dito as novas units permanecem com o mesmo conteúdo, mas agora com uma novidade. Exemplo: (...) const NAME_SPACE = 'xmlns="http://www.portalfiscal.inf.br/nfe"'; resourcestring DSC_AAMM = 'Ano e Mês'; DSC_ANOFAB = 'Ano de Fabricação'; DSC_ANOMOD = 'Ano do Modelo de Fabricação'; DSC_CEANTRIB = 'Código de Barra do Item Tributação'; (...) Antes todas as mensagens eram tratadas como const, agora são resourcestring. Para quem não sabe, Com resourcestring, o compilador coloca essas strings como um recurso stringtable no executável, permitindo que qualquer pessoa (digamos, sua equipe de tradução) as edite com um editor de recursos sem precisar recompilar o aplicativo ou ter acesso ao código-fonte. Observação: Façam as trocas listadas acima, pois em breve as units "antigas" vão ser removidas do SVN.

Bom dia @Marcelo Toller, Além no arquivo soap de retorno você também tem o arquivo de retorno sem ser o soap. Caso afirmativo poderia anexar? Pois nesse retorno que você anexou ele consta a nota. Outra coisa, no envio síncrono não temos o numero do protocolo.