Italo Giurizzato Junior

Boa tarde rlmariz, Essa data/hora que esta no XML retornado pela consulta esta errada. Favor entrar em contato com o provedor e expor o problema.

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 rlmariz, Esse XML é o retorno do webservice referente a consulta. É para ter salvo em disco dentro da pasta Notas o XML da nota retornado por essa consulta. Nesse XML consta o grupo NfseCancelamento, dentro desse grupo tem o pedido de cancelamento, mas a data/hora do cancelamento consta: 0001-01-01T00:00:00 Te aconselho a entrar em contato com o problema e questionar sobre o porque dessa data/hora. O que isso significa, a nota foi ou não cancelada? Se foi não deveria constar a data/hora do cancelamento?

Boa tarde Jovito, Precisamos do XML (soap) de retorno do envio e da consulta para que possamos analisar e fazer os ajustes necessários.

Boa tarde a todos, Conforme consta na página 6 do Manual CTe Anexo I Leiaute e Regras de Validação v4.00 o conteúdo da tag xNome do Remetente, Expedidor, Recebedor e Destinatário em ambiente de homologação tem que ser: “CTE EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL" conforme as regras de validação: G002, G003, G004 e G005. Notem que a sigla CTE não contem hífen. Por outro lado na página 71 do Manual CTe Visão Geral v3.00a a sigla CTE tem o hífen, ou seja, o conteúdo tem que ser: “CT-E EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL” conforme as regras de validação: G002, G003, G004 e G005. Resumindo: Segundo as regras de validação mencionadas acima, para a versão 3.00 tem que ser "CT-E" e para a versão 4.00 tem que ser "CTE". Pelo menos é o que consta nas regras de validação de cada manual. As SEFAZ Autorizadoras tem que entrar em um acordo, ou segue a risca o que esta nos manuais ou o ENCATE publica uma Nota Técnica retificando o manual da versão 4. Mas de toda forma todos tem que usar as mesmas regras de validação. Quem tem clientes que a UF x é uma uma forma e na UF y é de outra para a mesma versão, aconselho a entrar em contato com a SEFAZ que esta em desacordo com o manual e pedir explicação. Quanto mais desenvolvedor entrar em contato com as SEFAZ-Autorizadoras questionando a falta de padrão, quem sabe eles resolvem corrigir essa kaka.

Bom dia Rogerio, Vamos lá: 1. uma coisa é a mensagem Dados Fatura que é impresso, isso é de menos, você pode alterar o fonte do componente para aparecer a mensagem que você bem entender. 2. outra coisa é o numero da parcela que esta aparecendo no DANFE: 2342-1 em vez de 001. Neste caso se faz necessário analisar o XML dessa nota, pois como dito acima a tag nDup, que antes erada chamada de numero da Duplicata agora é chamada de numero da parcela, apesar de ter um tamanho máximo de 60 caracteres tanto no manual quanto nos schemas existe uma observação quanto ao seu preenchimento (vide imagem abaixo). Você vai conseguir alimentar o componente com o conteúdo 2342-1, vai conseguir gerar o XML, assinar e validar, mas ao enviar a nota para a SEFAZ a mesma vai ser rejeitada pela regra abaixo: Se o XML dessa nota o conteúdo da tag nDup é 2342-1, isso significa que o XML foi alterado após o seu envio para a SEFAZ e consequentemente ele não tem validade jurídica. Agora se o conteúdo da tag nDup é 001, mas esta imprimindo 2342-1, isso significa que esse desenvolvedor mudou a impressão do DANFE. Eu imagino que esse 2342 deva ser o numero da Fatura logo ele tem que ser o conteúdo da tag nFat, como dito acima podemos comprovar analisando o XML dessa nota. O que diz o manual sobre o DANFE: Onde se lê Duplicatas, leia-se Faturas. Onde se lê arquivo da NF-e, leia-se XML da NF-e. O ACBr preza pelo o que esta escrito no item 3.1 do Manual do DANFE, veja: Você quer ter argumentos para conversar com o seu cliente, peça o XML dessa nota e o analise. Depois de posse dos manuais você vai poder chegar para ele e dizer se o DANFE da nota que ele recebeu esta correto ou não, se o XML da nota tem validade jurídica ou não e por fim se é possível fazer a modificação que ele quer ou não.

Bom dia Rogerio, Já esta no SVN.

Bom dia Luciano, Já esta no SVN.

Boa tarde @Quality Automação, Até onde sei Goiânia segue a versão 2 do layout da ABRASF e sendo assim o código da cidade conforme o schema tem que ser o código IBGE. Me parece que o XML da NFS-e gerada pelo webservice que é gerado com esse código próprio. É por isso que só existe o tratamento para a leitura e não para a geração do XML.

Boa tarde Diego, Acabei de fazer um teste usando o programa exemplo, veja o resultado: Requisição Ambiente: 1 Cidade : Joinville/SC Provedor: ISSJoinville Versão: 2.04 Método Executado: Enviar Lote Parâmetros de Envio Numero do Lote: 1 Parâmetros de Retorno Data de Envio : 09/08/2023 Numero do Prot: Numero da Nota: Link : Código Verif. : Sucesso : False Erro(s): Código : E73 Mensagem: O CNPJ do PRESTADOR 999999 não está cadastrado no sistema NF-em ou não possui permissão de emitir NF-em. | CNPJ não encontrado na base de dados. Correção: Confira o numero do CNPJ informado. Caso esteja correto, o prestador não está inscrito no município. Como você pode ver não ocorreu esse erro, tudo me leva a crer que você não esta configurando o componente corretamente no que se refere as propriedades: SSLLib, CryptLib, HttpLib, XmlSignLib e SSLType.

Boa tarde Rogerio, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-4301

Boa tarde Alexandre, Se o envio ocorreu mas não foi retornado nada, com certeza ocorreu o erro de internet no retorno. Quando isso ocorre ficamos sem o numero do protocolo. Neste caso devemos executar o método ConsultarNFSePorRps para obter o XML da nota caso o Rps tenha sido processado com sucesso ou a lista de erros caso ocorreu falha no processamento.

Alexandre, No que se refere a salvar o XML em disco temos 3 configurações para isso: Configuracoes.Arquivos.Salvar := True Salva os XML do Rps e da NFS-e em disco. Configuracoes.Geral.Salvar := True Salva os XML de envio e de retorno em disco. Configuracoes.WebServices.Salvar := True Salva os XML (soap) de envio e de retorno em disco.

Bom dia Luciano, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-4300

Bom dia Edvilson, Já esta no SVN.

Bom dia Alexandre, Com relação ao tratamento de um retorno vazio é feito sim, veja: Como o Diego lhe disse o provedor ISSCuritiba segue a versão 1 do layout da ABRASF. Sendo assim o tratamento de retorno dos métodos da versão 1 do layout da ABRASF se encontra na unit ACBrNFSeXProviderABRASFv1. No inicio do TratarRetornoEmitir temos: procedure TACBrNFSeProviderABRASFv1.TratarRetornoEmitir(Response: TNFSeEmiteResponse); var Document: TACBrXmlDocument; AErro: TNFSeEventoCollectionItem; ANode: TACBrXmlNode; begin Document := TACBrXmlDocument.Create; try try if Response.ArquivoRetorno = '' then begin AErro := Response.Erros.New; AErro.Codigo := Cod201; AErro.Descricao := ACBrStr(Desc201); Exit end; Document.LoadFromXml(Response.ArquivoRetorno); (...)

Bom dia Rogério, A tag indPag que identifica se o pagamento é a vista ou a prazo não existe mais dentro do grupo ide. Isso explica o IF checando a versão da NF-e. A sua proposta não vai mudar, pois o segundo IF sempre vai ser vazio, a não ser que você alimente o campo indPag. Mas lembre-se que o campo indPag ainda permanece por questão de compatibilidade com a versão anterior a 4. Na versão 4 a tag indPag se encontra dentro do grupo detPag que se encontra dentro do grupo pag. Com relação ao Numero da Parcela (tag nDup), segundo o manual que contem o layout da NF-e (final da página 61) temos a seguinte observação: Obrigatória informação do número de parcelas com 3 algarismos, sequenciais e consecutivos. Ex.: “001”,”002”,”003”,... Observação: este padrão de preenchimento será Obrigatório somente a partir de 03/09/2018. Como já estamos em 2023, o numero da parcela tem que ser com 3 algarismos sequenciais e consecutivos.

Boa tarde Rogerio, Favor entrar em contato com a prefeitura/provedor e solicitar a URL de produção. Sem essa informação não consigo fazer o favor de atualizar o arquivo ACBrNFSeXServicos.ini

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

Boa tarde Alexandre, Necessito dos XML (soap) de retorno dos métodos executados para analise. Outra coisa, qual é o valor configurado para Timeout? Um valor baixo como 5000 pode ocorrer erro de internet, sugiro colocar 40000.

Boa tarde Alexandre, Esse XML do RPS foi gerado pelo componente novo (ACBrNFSeX) ou pelo componente antigo (ACBrNFSe) ? Se foi com o antigo: 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 No caso desse RPS em questão, você pode consultar a NFS-e por Rps que você vai ter como resposta o XML da NFS-e.

Bom dia Edvilson, E a URL de homologação? Testando a URL atual ela não esta funcionando. Ela também mudou? Ou não vão disponibilizar o ambiente de homologação? Já inclui na minha lista de tarefas para atualiza a URL. TK-4297

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Bom dia Paulo, Já esta no SVN.