Italo Giurizzato Junior

Boa tarde Rafael, O método ObterDANFSE não retorna um XML e sim um PDF, verifique na aba Log o que esta escrito.

Boa tarde Antonio, Eu sempre me baseio nos schemas. Segundo os schemas temos: <!--TIPO COMPLEXO PARA INFORMAÇÕES DO LOCAL DA PRESTAÇÃO DO SERVIÇO--> <xs:complexType name="TCLocPrest"> <xs:sequence> <xs:element name="cLocPrestacao" type="TSCodMunIBGE" minOccurs="0"> <xs:annotation> <xs:documentation>Código do município onde o serviço foi prestado (tabela do IBGE)</xs:documentation> </xs:annotation> </xs:element> <xs:element name="cPaisPrestacao" type="TSCodPaisISO" minOccurs="0"> <xs:annotation> <xs:documentation>Código do país onde o serviço foi prestado (Tabela de Países ISO)</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> Como você pode notar tanto a tag cLocPrestacao quanto cPaisPrestacao são opcionais (numero mínimo de ocorrências é zero). Se o local da prestação do serviço for um município brasileiro devemos informar o código IBGE do mesmo, por outro lado se o local for fora do Brasil devemos informar a sigla na tag cPaisPrestacao. O que diz o Manual: Como você pode ver não existe nenhuma indicação que devemos informar 9999999 em cLocPrestacao se for exterior e a sigla e por outro lado se não for exterior não devemos informar BR em cPaisPrestacao. O que eu entendi referente a tabela que contem as siglas dos países, mais precisamente a ultima linha que contem o ZZ: ZZ = Município não possui a informação no sistema próprio. Ao cadastrar o tomador não foi informado o pais do mesmo, neste caso devemos informar ZZ em cPaisPrestacao. Observação importante: O Anexo IV - LeiautesRN_ADN-SNNFSe_V1.00.02 tem haver com o compartilhamento de dados entre os municípios e a ADN, quando o município aderiu somente o compartilhamento. Veja: Já o Anexo I - LeiautesRN_DPS_NFSe-SNNFSe_v1.00.02 tem o layout do DPS que é gerado e enviado pelo contribuinte para o ADN - Ambiente de Dados Nacional. Como você pode ver é muito fácil se perder com a documentação disponibilizada da NFS-e Padrão Nacional.

Boa tarde Denis, Você poderia anexar esse outro XML que contem a tag CompNfse para que eu possa analisar o problema?

Boa tarde Elison, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Antonio, Existe esse ZZ pois ele consta na tabela (Anexo A) disponibilizado no Portal Nacional da NFS-e. Veja: Mas realmente precisamos analisar mais afundo essa questão.

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

Bom dia Denis, Esse XML foi baixado do Portal da Prefeitura ou foi retornado pelo WebService? Por padrão todos os XML de NFS-e segundo o layout da ABRASF devem começar pela tag CompNfse e esse XML esta começando pela tag Nfse. Veja:

Bom dia Silva, Pode ser um bug no webservice deles, ou apesar de existir o serviço no webservice ele esta desativado a pedido da prefeitura que deseja que o envio seja feito de forma unitária.

Bom dia Rafael, O Padrão Nacional não traz algumas informações em seu XML, a titulo de exemplo é o código de verificação. O que foi feito, o componente esta usando a chave da NFS-e como sendo o código de verificação e ao imprimir a mesma não cabe no espaço reservado para o código de verificação. No meu entendimento em vez de imprimir o DANFSE pelo componente após o envio do DPS para a API do padrão nacional, eu faria o seguinte: Emitir(nLote, meAutomatico, False); // o False é para não imprimir o DANFSE automaticamente. If retornou o XML da nota then ObterDANFSE(chaveNota); Depois basta abrir o PDF para visualisar e imprimir

Bom dia Felipe, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Bom dia Elison, Já esta no SVN. Quanto a esse erro, comigo não ocorreu. Verifique a configuração na aba Certificados e WebServices no diz respeito as propriedade de configuração: SSLLib, CryptLib, HttpLib, XmlSignLib e SSLType.

Bom dia Marcos, Já esta no SVN.

Bom dia Danio, Já esta no SVN. Quanto a esse erro retornado, acredito que seja necessário realizar um cadastro junto a prefeitura/provedor para que o prestador de serviço possa emitir a sua nota via webservice.

Bom dia Antonio, O XML retornado pelo ConsultarNFSePorChave é o da NFS-e e infelizmente não existe nenhuma tag que indica que a nota se encontra cancelada. Como as NFS-e do Padrão Nacional são canceladas por um evento, vai ser necessário você executar o método ConsultarEvento. Onde temos que informar a chave da NFS-e e opcionalmente o tipo de evento e se este possa conter mais de uma ocorrência devemos informar também o numero sequencial do evento. Estude o código do botão [Consultar Evento por Chave] e na unit PadraoNacional.Provider, mais precisamente a procedure TratarRetornoConsultarEvento, para saber quais tag são lidas do retorno. Nesse retorno você vai ter a data/hora do processamento do evento.

Bom dia Souza, Se o PDF baixado pelo ObterDANFSE esta ficando em branco é porque você esta com os seus fontes desatualizados. Tive esse mesmo problema e encontrei onde esta o bug e fiz apliquei uma possível solução. Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Bom dia Bill, Notei que esse XML, somente o grupo infNFSe esta assinado, o grupo infDPS não esta. O componente ACBrNFSeX assina o DPS antes de ser enviado, logo o XML da NFS-e retornado pela API contem 2 assinaturas, a do DPS feita pelo componente e a da NFS-e feita pela API. Você esta com todos os fontes de todas as pastas atualizados, pois detectei um erro no componente que estava corrompendo o PDF baixado da API.

Bom dia Antonio, Assim que eu tiver um retorno do pessoal da RFB/SERPRO lhe informo aqui.

Bom dia Antonio, Se foi eu lhe peço desculpas. Mas temos que analisar todos os fontes com alterações enviados por vocês, pois tivemos casos de aceitar colaboração e esta acabou gerando um efeito colateral com outros provedores. Outra coisa ao enviar alguma contribuição, envie somente a unit alterada e procure sempre fazer a alteração com os fontes atualizados. Você concorda que a função SiglaISO2ToCodIBGEPais retorna -1 caso não encontre a tag cPaisPrestacao não exista no XML. Desta forma ao tentar gerar novamente o XML, vai acabar gerando a tag com o valor ZZ. Se alterarmos a função para retornar o valor zero em vez de -1, não vamos precisar do IF que você incluir na unit que faz a leitura do XML. Desta forma resolvemos esse problema e se amanhã aparecer outro provedor que se utilize da mesma função não teremos que lembrar de colocar o IF, pois não teremos o mesmo problema que você esta enfrentando. Mais uma vez muito obrigado pelos testes, analise e apontar uma solução para o problema. Toda colaboração é sempre bem vinda, pois todos nós saímos ganhando. Você encontrou um erro, outros podem encontrar outros erros, se todos vão nos passando esses erros e uma possível solução, repito todos saem ganhando, pois o componente se torna a cada dia mais robusto.

Bom dia Rodrigues, Esse XML contem quebra de linha em cada tag que compõe o XML e ele esta identado.

Bom dia Lindomar, Pelo que me recordo o campo dPrev tem que ser um campo cujo tipo seja numérico de ponto flutuante. Devemos informar o valor zero quando não queremos informar uma determinada data.

Bom dia Lindomar, Como não sou eu que cuido da Lib, vou passar esse caso para o pessoal, eles vão retornar aqui mesmo neste tópico com uma resposta mais assertiva.

Felipe, Muito obrigado pela informação, já inclui na minha lista de tarefas. TK-4416

Boa tarde Lindomar, O ACBr se utiliza do caractere ";" para indicar uma quebra de linha, uma vez que o \r\n (posso estar escrevendo besteira) no XML vai se tornar um #13#10 e esses caracteres vão ser removidos automaticamente antes do XML ser assinado.

Boa tarde Antonio, Não seria o caso de mudar a função abaixo? function SiglaISO2ToCodIBGEPais(const t: string): Integer; var i: Integer; begin Result := -1; <==== mudar aqui para zero for i := Low(SiglaISO2Pais) to High(SiglaISO2Pais) do begin if SiglaISO2Pais[i] = t then begin Result := CodigoIBGEPais[i]; exit; end; end; end;

Boa tarde Antonio, Já passei para o pessoal da RFB e do SERPRO o problema de discordância entre o Manual e o Schema. Eles tem que dar um jeito nisso, pois Porto Alegre em outubro quem é autônomo vai ser obrigado a emitir pelo padrão nacional e em novembro as empresas ME EPP. Imagina todo esse povo enviando notas com informações erradas.