Italo Giurizzato Junior

Bom dia, Fiz algumas alterações mas sem nenhum sucesso. Você sabe me dizer se com o componente antigo funcionava o cancelamento?

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

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

Douglas, Neste caso te aconselho a entrar em contato com o provedor e expor o problema.

Leonard, No caso de Boituva você tem a nova URL?

Boa tarde William, Vai ser necessário debugar para saber a linha exata que esta gerando o erro: Argument out of range. Pois não encontrei nada no XML de retorno que pudesse estar provocando esse erro. Por favor faça um novo teste e coloque um ponto de parada na primeira linha da procedure: TratarRetornoConsultaNFSeporRps que esta na unit ACBrNFSeXProviderABRASFv2

Boa tarde Alexandre, Debuga usando o programa exemplo do componente. Vai ser necessário debugar os fontes do componente, pois a atribuição do nome do XML a propriedade NomeArq ocorre no componente.

Boa tarde Leonard, Você sabe me dizer se essa alteração é para todas as cidades atendidas pelo provedor? Pois no novo componente ACBrNFSeX algumas cidades atendidas pelo provedor já estão com a nova URL.

Boa tarde Douglas, Se você esta tentando enviar para o ambiente de homologação, favor fazer um teste enviando para o de produção. Infelizmente muitos provedores não dão muita atenção para o ambiente de homologação ou as vezes nem implementam. Pela mensagem de erro, esta ocorrendo algum problema com o webservice do provedor.

Boa tarde Valter, Fiz uma alteração que acredito venha resolver esse problema desse provedor e de outros que existem a presença da tag mesmo quando o valor inicial e final são iguais. Favor atualizar os fontes e faça novos testes.

Boa tarde, O XML de pedido de cancelamento é validado pelos schemas disponibilizados pelo provedor, logo não existe nada no XML que esteja faltando ou sobrando a ponto do webservice recusar e informar que o XML esta fora da estrutura esperada. Por favor, entre em contato com o provedor e solicite um XML de pedido de cancelamento de exemplo.

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

Bom dia, Faça o seguinte, na unit ISSNet.Provider, procedure Configuracao altere a linha: ConfigGeral.Identificador := ''; para: ConfigGeral.Identificador := 'id'; E refaça todos os testes: de envio, consulta e cancelamento.

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

Boa tarde, Acredito ter descoberto o problema. Veja como o provedor gerou a data de competência. Favor atualizar os fontes e faça novos testes.

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.