Italo Giurizzato Junior

Boa tarde Gleiko, Já esta no SVN.

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

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

Felipe, Você utiliza o Fortes ou o Fast Report? Você poderia anexar o XML da NFS-e para que possamos analisar?

Ronaldo, Porque você não utiliza a DLL: ACBrLibNFSe ?

Tópico fechado por falta de retorno do usuário

Boa tarde Felipe, Lista de checagem: Você tem fontes 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.

Boa tarde Antonio, No novo componente ACBrNFSeX não é usado os arquivos Cidades.ini e os INI dos provedores. No componente novo temos o arquivo ACBrNFSeXServicos.ini que contem as cidades atendidas pelo componente. Para cada provedor temos 3 units, exemplo: SimplISS.Provider , SimplISS.GravarXml e SimplISS.LerXml. Para saber se é necessário o uso do certificado digital, basta abrir a unit Provider do provedor em questão. Veja a imagem que o Diego anexou, nela esta claro que para a verão 2.03 do provedor SimplISS devemos assinar o XML do RPS, assinar o Lote de RPS ( quando o RPS é enviado em Lote ) e assinar o RPS quando este é enviado de forma unitária ( serviço GerarNfse ).

Boa tarde, O componente gera e envia o XML do RPS. Quem gera o XML da NFS-e é o WebService do provedor, caso o RPS que foi enviado esta com todas as informações corretas. A principio em um envio Síncrono já teríamos como retorno o XML da NFS-e ou a lista de erros. Se nenhum dos 2 esta sendo retornado vai ser necessário consultar a nota pelo RPS. Você poderia anexar o XML (soap) de retorno desse envio para que possamos analisar?

Boa tarde Felipe, Já inclui na minha lista de tarefas para analise. TK-4315

Boa tarde Ronaldo, Você trabalha com qual linguagem?

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

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

Boa tarde Felipe, Lista de checagem: Você tem fontes 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.

Boa tarde, Você esta usando o componente antigo ACBrNFSe? Se sim, 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/

Boa tarde Jovito, Fiz uma alteração no componente que acredito vai resolver o problema. Vamos aguardar agora uma nova compilação da Lib.

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.