Italo Giurizzato Junior

Boa tarde Maiquel, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. Lhe peço que inicie os testes com o novo componente.

Boa tarde, Já lhe respondi essa questão em outra postagem sua. Vou fechar essa e vamos continuar na outra.

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

Boa tarde Joselito, Já inclui na minha lista de tarefas, vou analisar o problema.

Boa tarde, Pela mensagem de erro, se faz necessário verificar junto a prefeitura qual é a tributação correta para o contribuinte em questão.

Henrique, Muito obrigado, já inclui na minha lista de tarefas.

O grande problema é que o provedor Ginfes segue a versão 1 do layout da ABRASF. Todos os provedores que seguem a versão 1 só tem um serviço para recepcionar o XML. É o serviço: EnviarLoteRpsEnvio. O provedor 4R segue a versão 2 do layout da ABRASF. A principio nessa versão os provedores deveriam disponibilizar os serviços: EnviarLoteRpsEnvio, EnviarLoteRpsSincronoEnvio e o GerarNfse. Só que o provedor 4R disponibilizou somente o EnviarLoteRpsSincronoEnvio. Isso explica a mensagem que você anexou. O novo componente não tem mais os métodos: Enviar, EnviarSincrono e Gerar que consome os serviços listados acima. Ele tem o método chamado Emitir. Esse novo método é capaz de abstrair qual é o serviço que o provedor disponibilizou e desta forma consegue enviar o Rps para o webservice. É por isso que estamos orientado o pessoal a migrar para o novo componente.

Thiago, O provedor Digifred segue a versão 2 do layout da ABRASF e pelos meus testes ele implementou os 3 serviços para recepcionar o Rps. No programa exemplo qual botão você esta usando para Emitir o Rps?

Boa tarde, Se possível anexe o XML da NFS-e para que possamos analisar o problema.

Boa tarde Thiago, Você não informou se você esta querendo essas informações após o envio, consulta ou cancelamento.

Boa tarde Henrique, Favor configurar o componente ACBrNFSe (antigo) para salvar os arquivos soap. Faça um envio e anexa aqui. Depois repita o processo só que usando o novo componente: ACBrNFSeX. Desta forma poderemos comparar o XML do cabeçalho gerado pelo componente antigo e o gerado pelo novo.

Boa tarde, Então faça um teste usando o programa exemplo do componente ACBrNFSe e nos mostre a mensagem exata do erro e como reproduzir. Como você incluiu a cidade, favor anexar os arquivos INI que você alterou para incluir ela.

Boa tarde, No envio é levado em consideração o numero do Rps, pois é este que é enviado. No momento do envio o componente esta carregado com os dados do Rps, ao tratar o retorno ele procura pelo Rps, uma vez que dependendo do provedor e serviço podemos enviar um lote de até 50 Rps. Após o envio no caso do provedor SP, podemos realizar a consulta a NFS-e por Rps informando o Rps. No programa exemplo temos a procedure chamada ChecarResposta: if Response is TNFSeEmiteResponse then begin memoLog.Lines.Add('Modo de Envio : ' + ModoEnvioToStr(TNFSeEmiteResponse(Response).ModoEnvio)); memoLog.Lines.Add('Numero do Lote: ' + TNFSeEmiteResponse(Response).Lote); memoLog.Lines.Add('Data de Envio : ' + DateToStr(TNFSeEmiteResponse(Response).Data)); memoLog.Lines.Add('Numero do Prot: ' + TNFSeEmiteResponse(Response).Protocolo); memoLog.Lines.Add('Sucesso : ' + BoolToStr(Response.Sucesso, True)); end; O fragmento de código acima se refere ao retorno do Emitir. Para obter o numero da NFS-e e o código de verificação que temos no retorno do envio, basta fazer o seguinte: Basta ler os campos: NumeroNFSe := Response.InfRetorno.ChaveNFeRPS.Numero; CodVer := Response.infRetorno.ChaveNFeRPS.CodigoVerificacao;

Boa tarde Danny, Já esta no SVN.

Olá pessoal, Fizemos mais alguns ajustes, só que agora no DANFSE feito em Fortes Report. O que mudou? O componente ACBrNFSeXDANFSeRL tinha algumas propriedades de configuração que não deixava bem claro do que se tratava. Detectamos que algumas fazia referencia ao Prestador e outras ao Tomador. Foi criado uma propriedade de configuração chamada Prestador e outra Tomador e dentro dessas propriedades foi colocado as propriedades que as pertence. As propriedades: PrestLogo, RazaoSocial, Endereco, Complemento, Fone, Municipio, InscMunicipal, EMail_Prestador, CNPJ_Prestador e UF foram removidas e elas agora estão na propriedade Prestador com os seguintes nomes: RazaoSocial, NomeFantasia, InscricaoMunicipal, CNPJ, Endereco, Complemento, Municipio, UF, EMail, Fone e Logo. As propriedades: T_InscEstadual, T_InscMunicipal, T_Fone, T_Endereco, T_Complemento e T_Email foram removidas e elas agora estão na propriedade Tomador com os seguintes nomes: InscricaoEstadual, InscricaoMunicipal, Fone, Endereco, Complemento e Email. Favor atualizar todos os fontes de todas as pastas e reinstale a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada.

Boa tarde Leandro, Segundo o site: http://nfce.encat.org/consulte-sua-nota-qr-code-versao-2-0/ que o Fabricio nos passou (primeira postagem desse tópico) consta uma tabela com todas as UF. Sendo que uma boa parte delas (isso inclui Goiás) a URL é a mesma para ambos os ambientes no que se refere a versão 2 do QR-Code. Sendo assim não posso aceitar essa sua alteração.

Bom dia Cristiano, Chegou a ler o artigo abaixo?

Bom dia Cristiano, Se você já tem uma postagem relatando o seu problema, não resolve nada postar outro e ainda por cima não colocar o link do outro. Vou fechar esse. Aguarde no outro se mais alguém lhe passe mais informações.

João, Já esta no SVN. Atenção essa alteração foi feita somente no novo componente de emissão de NFS-e: ACBrNFSeX. 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 Eloi, Já esta no SVN.

Boa tarde, Esse erro diz que o Rps que você enviou já foi convertido em NFSe, logo não pode enviar ele novamente, é preciso incrementar a numeração do Rps. Verifica se no site da prefeitura não tem como descobrir quais Rps já foram enviados e foram convertidos em NFSe.

Marcelo, Pelo o que eu entendi, a nota que você emitiu foi utilizando o site da prefeitura e não uma aplicação, correto? A maioria dos provedores disponibilizam dois meios para que o contribuinte possa emitir a sua nota de serviço, são eles: Via Site ou Via WebService. Os componentes ACBrNFSe e ACBrNFSeX se utilizam dos WebServices disponibilizados pelos provedores. Alguns provedores permitem emitir notas de forma diferente em relação ao webservice. O que eu preciso saber é: O provedor que atende a sua cidade permite emitir uma nota de serviço via webservice informando mais de um serviço, ou seja, o XML do Rps pode conter mais de uma ocorrência do grupo <tcDadoServico> ?

Boa tarde João, Muito obrigado pela colaboração, já inclui na minha lista de tarefas.

Boa tarde Marcelo, A emissão dessa nota ocorreu via site ou via aplicativo disponibilizado pela prefeitura? O que me chama a atenção é os schemas, veja: Definição do grupo <IdentificacaoRps> <xsd:element name="IdentificacaoRps"> Definição do grupo <RpsSubstituido> <xsd:element name="RpsSubstituido" minOccurs="0" maxOccurs="1"> Definição do grupo <tcDadosServico> <xsd:element name="tcDadosServico"> Note que na definição do grupo <RpsSubstituido> esta claro que a quantidade mínima de ocorrências é zero, isso significa que é opcional e a máxima é 1, ou seja, esse grupo só pode ocorrer apenas uma vez no XML do Rps. Já os outros 2 grupos que mencionei a titulo de exemplo, não consta a especificação de quantidade mínima e máxima de ocorrências, isso me leva a crer que os valores sejam 1 para ambos, ou seja, o grupo é obrigatório e só pode constar uma única vez no XML. O XML que você anexou apresenta duas ocorrências do grupo <tcDadosServico> no XML. Se realmente é possível gerar um XML de Rps com mais de uma ocorrência do grupo <tcDadosServico>, os schemas atuais que temos estão desatualizados, pois com eles a validação vai falhar caso o XML tenha mais do que uma ocorrência. Podemos até alterar o Schemas, mas para isso precisamos saber qual é a quantidade máxima de ocorrências desse grupo.

Boa tarde, Lhe convido a conhecer o novo componente de emissão de NFS-e: ACBrNFSeX. Manual de Migração No caso do novo componente a cidade deve ser incluída no arquivo ACBrNFSeXServicos.ini Esse arquivo se encontra na pasta: ...\Fontes\ACBrDFe\ACBrNFSeX No novo componente o provedor 4R passou a se chamar Sistemas4R. Veja como foi incluída outras cidade para o mesmo provedor, o que você precisa saber são as URLs de homologação e de produção.