Italo Giurizzato Junior

Valter, Se pela consulta por Rps deu certo, então a consulta da nota por faixa que deve estar com algum problema.

Bom dia Douglas, Me parece que ocorreu um erro, veja o arquivo temp2.xml <S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope" xmlns=""> <faultcode>S:Server</faultcode> <faultstring>Cannot rollback transaction in current status [COMMITTED]</faultstring> </S:Fault> O programa exemplo esta configurado para salvar os arquivos de envio e de retorno? Se não esta, favor configurar para que os mesmos sejam salvos em disco.

Bom dia Felipe, Tem provedor que só retorna um link mesmo. O jeito vai ser usar esse link para poder baixar o PDF do DANFSE e imprimir.

Bom dia Valter, E a nota de numero 245 foi cancelada com sucesso? Se sim, vai ser necessário entrar em contato com o provedor para saber o motivo desse retorno ao consultar a nota cancelada.

Bom dia Olímpio, Já esta no SVN a sua contribuição. Notei que você ainda esta usando o componente antigo: ACBrNFSe. Lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente ACBrNFSe não vai mais ter manutenção. Manual de Migração

Boa tarde André, Note que a rejeição diz que o campo xNome do grupo toma que foi informado na carta de correção não existe. O campo xNome existe, o que não existe é o grupo toma. Você esta fazendo uma carta de correção para o CT-e (modelo 57). Nesse modelo de documento o grupo que contem os dados do tomador quando se tratar de outros se chama: toma4 Outra coisa, notei que você esta informando o campo: nroItemAlterado, não se faz necessário pois todos os campos alterados aparecem uma única vez. O campo nroItemAlterado só é necessário quando estamos alterando uma informação que se encontra em uma lista, ai devemos informar se ele é o item de numero 01, 02, ... dessa lista. Isso esta errado: <infCorrecao> <grupoAlterado>toma</grupoAlterado> <campoAlterado>fone</campoAlterado> <valorAlterado>81991447846</valorAlterado> <nroItemAlterado>07</nroItemAlterado> </infCorrecao> <infCorrecao> <grupoAlterado>toma</grupoAlterado> <campoAlterado>xNome</campoAlterado> <valorAlterado>TEMARCO OPERACOES PORTUARIAS S/A</valorAlterado> <nroItemAlterado>08</nroItemAlterado> </infCorrecao> Correto: <infCorrecao> <grupoAlterado>toma4</grupoAlterado> <campoAlterado>fone</campoAlterado> <valorAlterado>81991447846</valorAlterado> </infCorrecao> <infCorrecao> <grupoAlterado>toma4</grupoAlterado> <campoAlterado>xNome</campoAlterado> <valorAlterado>TEMARCO OPERACOES PORTUARIAS S/A</valorAlterado> </infCorrecao> Note que troquei o toma por toma4 e removi a tag: nroItemAlterado Espero ter ajudado.

Boa tarde Joas, Faça o seguinte teste: Abra o arquivo ACBrNFSeXServicos.ini e procure pela cidade "Colombo" Inclua a linha referente ao campo Params2: [4105805] Nome=Colombo UF=PR Provedor=IPM Params2=AssinarRps Fecha o arquivo salvando-o, depois execute o BAT: Compila_RES. Por fim compila/executa o programa exemplo e faça novos testes.

Boa tarde Valter, No novo componente: ACBrNFSeX não se faz necessário carregar o XML da NFS-e para solicitar o seu cancelamento. A maioria dos provedores que seguem o layout do ABRASF, é possível sim obter o XML da NFS-e completo, ou seja, com o grupo referente ao cancelamento da mesma. Para isso basta executar o método ConsultarNFSe (versão 1 do layout da ABRASF) ou ConsultarNFSePorFaixa (versão 2). O novo componente também tem uma opção de configuração chamada: ConsultaAposCancelar. Se essa propriedade estiver com o valor True o componente se encarrega de realizar a consulta, utilizando o método mais apropriado dependendo do provedor.

Boa tarde Junior, Ambos os XMLs foram gerados pelo mesmo componente: ACBrNFSeX, correto? Verifiquei a assinatura de ambos os XMLs e estão tudo OK segundo o site da Receita: Receita Federal do Brasil - Validador de Assinaturas (fazenda.gov.br)

Boa tarde Eliandro, Acredito que seja necessário fazer uma alteração na unit ACBrNFSeXConfiguracoes, mais precisamente na linha: property Provedor: TnfseProvedor read FProvedor; property Versao: TVersaoNFSe read FVersao; Mudar para: property Provedor: TnfseProvedor read FProvedor write FProvedor; property Versao: TVersaoNFSe read FVersao write FVersao; Desta forma essas propriedades de configuração deixam de ser somente leitura. Com isso, vai ser possível fazer o seguinte: ACBrNFSeX1.Configuracoes.Geral.Provedor := proBetha; // ve100, ve101, ve103, ve200, ve201, ve202, ve203, ve204 ACBrNFSeX1.Configuracoes.Geral.Versao := ve100; // versão do layout do XML usado pelo provedor que no caso do Betha pode ser ve100 ou ve202 ACBrNFSeX1.NotasFiscais.Clear; ACBrNFSeX1.NotasFiscais.LoadFromFile(xNomeXml, False); ACBrNFSeX1.NotasFiscais.Imprimir;

André, Mas o XML da nota não foi retornado e salvo? Verifica se as opções para salvar os XMLs das notas na aba Arquivos do programa exemplo estão marcadas. Procure sempre fazer os testes usando o programa exemplo.

Boa tarde, Eu conheço esse e-mail, trata-se de um texto padrão que eles enviam para todos. O ACBr gera o XML do Rps em conformidade com que esta escrito. Note que eles indicam um site da receita para validar a assinatura, pois bem se pegarmos o XML gerado pelo ACBr e jogar nesse validador da receita vai acusar que ela é valida, mas o webservice deles acusa que a assinatura é invalida. Eles não admitem que o webservice de homologação esta bichado ou não são capazes de apontar exatamente onde esta o erro para que possamos fazer as devidas correções.

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

Boa tarde Douglas, Me parece que você esta com os seus fontes desatualizados, inclusive o programa exemplo. Favor atualizar todos os fontes de todas as pastas. Reinstale o ACBr e refaça os testes.

Junior, Favor anexar os XMLs gerado pelo programa exemplo cujo processamento resultou em sucesso e os gerados pela sua aplicação. Detalhe, preciso do XML de envio e não do Rps.

Boa tarde André, Agora ficou complicado, o webservice rejeita o Rps por estar em desacordo, ao validar o que foi enviado para o webservice usando um validador disponibilizado pelo próprio provedor acusa que ele é valido. Não vejo outra saída a não ser entrar em contato com o problema e relatar o problema, quem sabe eles conseguem identificar onde estamos errando ao gerar o XML.

Boa tarde Junior, Ficou confuso, o que foi gerado pelo programa exemplo do componente o Rps foi processado com sucesso, já o que foi gerado usando o componente através da sua aplicação deu erro de assinatura?

Boa tarde Maiquel, Favor atualizar os fontes e faça novos testes.

Boa tarde Diego, Já esta no SVN, favor atualizar os fontes e faça novos testes.

Boa tarde Edmar, Já esta no SVN. Favor atualizar os fontes e faça novos testes.

Bom dia Eliandro, Favor atualizar os fontes e faça novos testes.

Bom dia Edmar, Já esta no SVN a sua contribuição com um pequeno ajuste realizado por mim.

Bom dia Junior, O XML que você diz que foi gerado pelo programa exemplo e foi autenticado é de uma NFS-e que na verdade foi gerado e retornado pelo webservice do provedor. Já o segundo é o XML do Rps que é gerado pelo componente. O Rps que foi processado com sucesso, portanto resultou na nota de numero 4382 se refere ao Rps de numero 2 serie 85. Já o segundo Rps que você diz que não foi processado com sucesso é o Rps de numero 204 serie 2. O que foi processado com sucesso foi enviado para o ambiente de homologação ou de produção? Já o que não foi processado com sucesso foi enviado para qual ambiente?

Boa tarde Douglas, No programa exemplo, você clicou no botão [Emitir Nota (Novo)] ?

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