Jump to content

geovanesilveira

Membros
  • Content Count

    12
  • Joined

  • Last visited

Community Reputation

2 Neutral

About geovanesilveira

  • Rank
    Novato

Profile Information

  • Sexo
    Masculino
  • Localização
    Brasil, SC, Criciuma

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Foi um dos primeiros teste que fiz, e percebi que não poderia ser desse jeito. A não ser que eles fizessem a leitura de nodes de um modo diferente que possibilitasse esse "hack", mas não acredito que isso seria posto em pratica. Realmente, no momento em que estava fazendo isso nem me passou pela cabeça que isso seria bloqueado pelo schemas. (e tinha esquecido sobre esse site validador)
  2. Seguinte, a Votorantim requer que na tag <infAdProd> seja adicionado uma tag filha, chamada <codMaterialCliente> Conforme manual (começa na página 71) Hoje, a tag <infAdProd> é uma string, não possibilitando fazer a situação citada. Gostaria de saber se é possível adicionar um node em tempo de execução? Ou, se seria mais correto, já criar propriedades e rotinas para atender esse tipo de ocorrência.
  3. Boa noite, acabou de acontecer com um cliente meu o seguinte: Meu cliente fez a venda nº 500. Por algum motivo, o sistema não conseguiu enviar a mesma e o cliente também não percebeu. Seguindo o ritmo dele, outras 5 vendas (nºs: 501~505) foram efetuadas e todas enviaram. Após um tempo, o cliente notou que havia esta nota (nº 500) pendente e enviou a mesma. Depois que foi feito isso, o SAT parece que voltou no tempo, e todas a notas que eu tento fazer apartir de agora, elas saem como se fossem a próxima venda que tinha sido feito na sequencia ANTES de ele tentar ter enviado essa pendente. Simplificando: Após de ter enviado as notas 501~505 ele voltou para enviar a 500. Depois disso as novas notas saem como se fosse as antigas. 506 é emitida como se fosse a nota 501. 507 igual a 502. E assim por diante. O cliente não consegue mais tirar nenhuma nota, pois todas elas saem como se fosse a nota anterior. Alguém já passou ou sabe como resolver esse problema?
  4. Desculpe a demora, mas é exatamente como o Fernando falou. Após pesquisar mais não consegui de maneira nenhuma automatizar isso, no fim, abri o site (com o panel da solicitação ja aberto) e com as informações ja preenchida, dai precisa apenas informar o captcha e clicar em preencher. Caso alguem descobrir algo e querer compartilhar mesmo assim, esteja livre para faze-lo.
  5. Após dar uma olhada no fonte do ACBRGNRe, notei que não existe a opção de solicitar o uso do webservice. A imagem abaixo mostra o que eu quis dizer. Depois de ler os manuais da GNRe e o código fonte da página (que, dessa vez, não me ajudou em nada), não achei em nenhum lugar algo que indique como automatizar essa opção. Seria esse o motivo de não ter essa opção no GNRe? Ou há uma maneira, porém, não foi implementada? Essa seria uma das coisas que iria implementar no sistema, porém não estou conseguindo montar a URL, caso alguem tenha alguma ideia, favor, compartilhar.
  6. A modificação e o exemplo abaixo servem apenas para quem tem como provedor a Betha. Após atualizar os fontes do ACBr, há um código em TNFSeWebService.InicializarGerarDadosMsg (unit ACBrNFSeWebServices) que cria um exception caso a Inscrição Municipal esteja vazia: if IM = '' then GerarException(ACBrStr('A I.M. não informada em: Configuracoes.Geral.Emitente.InscMun')); Porém quem usa o provedor Betha, em ambiente de HOMOLOGAÇÃO, não se deve informar a IM. Abaixo segue a linha corrigida e o anexo da unit: if (IM = '') and ((Provedor <> proBetha) or (FPConfiguracoes.WebServices.Ambiente = taProducao)) then GerarException(ACBrStr('A I.M. não informada em: Configuracoes.Geral.Emitente.InscMun')); ACBrNFSeWebServices.pas
  7. 3Soft, sim, mas por questões de facilitação, traze-la na mensagem não deveria ser um problema, não?
  8. 3Soft, entendi a diferença entre elas, porém no segundo caso, 204, a mensagem não traz a chave, apena o número de recibo do lote, ao qual propus a alteração para fazer trazer, mas ja que a mensagem vem do XML, o único jeito seria fazer um condição só pra ela (o que não é legal): for I := 0 to FConhecimentos.Count - 1 do begin if not FConhecimentos.Items[I].Confirmado then begin FPMsg := FPMsg + IntToStr(FConhecimentos.Items[I].CTe.Ide.nCT) +'->'+ FConhecimentos.Items[I].Msg; if (FcStat = 204) then FPMsg := FPMsg +' [chCTE: '+ FConhecimentos.Items[I].NumID +']'; FPMsg := FPMsg + LineBreak; end; end;
  9. Italo, após dar uma pesquisada, vi que cometi um erro. A mensagem do status 539 está vindo do jeito como eu havia descrito acima: Rejeicao: Duplicidade de CT-e, com diferença na Chave de Acesso [chCTe: 99999999999999999999999999999999999999999999][nRec:999999999999999] E a mensagem da qual eu estava falando, era na verdade a 204: Rejeição: Duplicidade de CT-e [nRec:999999999999999] E quanto ao xMotivo não trazer a chave na mensagem 204, sendo que vem do XML de retorno, o único jeito seria falar com a fazenda?
  10. Quando tento enviar uma numeração de conhecimento, que por ventura, já foi processada, recebo a seguinte mensagem: Project cte.exe raised exception class EACBrDFeException with message 'Conhecimento(s) não confirmados: 7000->Rejeição: Duplicidade de CT-e [nRec:423000006816472] Até ai tudo certo, afinal ocorreu a exceção como esperado. Porém o número de recibo do lote (nRec) que vem junto da imagem não me serve muito, já que a consulta de CTe é feita pela chave. Então procurei pelo local aonde da o raise na exceção e encontrei na unit ACBrCTeWebServices, localizada na rotina TCTeRetRecepcao.TratarRespostaFinal: //Montando a mensagem de retorno para os Conhecimentos nao confirmados for I := to FConhecimentos.Count - 1 do begin if not FConhecimentos.Items[I].Confirmado then FPMsg := FPMsg + IntToStr(FConhecimentos.Items[I].CTe.Ide.nCT) + '->' + FConhecimentos.Items[I].Msg + LineBreak; end; Procurei o local aonde é montade o FConhecimentos.Items.Msg mas não encontrei, então para mostrar a chave fiz o seguinte: //Montando a mensagem de retorno para os Conhecimentos nao confirmados for I := to FConhecimentos.Count - 1 do begin if not FConhecimentos.Items[I].Confirmado then FPMsg := FPMsg + IntToStr(FConhecimentos.Items[I].CTe.Ide.nCT) + '->' + FConhecimentos.Items[I].Msg +' [Chave: '+ FConhecimentos.Items[I].NumID +']'+ LineBreak; end; Apesar de ainda achar que o certo seria arrumar a propriedade .Msg essa solução já me serve. Creio que trazer a chave é melhor do que não traze-la, já que com ela consigo consulta-la na fazenda sem precisar de debug ou códigos adicionais afins.
  11. Italo, fiz os testes aqui e funcionou tudo certinho, grato.
  12. Ao tentar fazer a leitura de um XML, conforme a imagem do mesmo em anexo, verifiquei que a tag, indicada na imagem, não esta sendo verificada no fonte, ou melhor, ela esta sendo mas falta outra condição. Na unit pnfsNFSeR, encontra-se duas funções que se chamam: LerNFSe_ABRASF_V1 e LerNFSe_ABRASF_V2. A função LerNFSe_ABRASF_V2 contêm a seguinte condição para carregar as informações do tomador: if (Leitor.rExtrai(3, 'Tomador') <> '') or (Leitor.rExtrai(3, 'TomadorServico') <> '') or (Leitor.rExtrai(2, 'Tomador') <> '') or (Leitor.rExtrai(2, 'TomadorServico') <> '') then Porém, na função LerNFSe_ABRASF_V1 o mesmo local que carrega as informações do tomador está assim: if Leitor.rExtrai(3, 'TomadorServico') <> '' then E conforme a imagem do XML que anexei, a tag esta vindo como <Tomador> e esta sendo executado pela função LerNFSe_ABRASF_V1, e consequentemente não carrega as informações. A solução que encontrei foi fazer do mesmo jeito que a LerNFSe_ABRASF_V2 if (Leitor.rExtrai(3, 'Tomador') <> '') or (Leitor.rExtrai(3, 'TomadorServico') <> '') then Desse jeito, as informações as informações são carregadas normalmente. OBS.: A versão que usei de exemplo acima não é a ultima, porém, antes de fazer esse post, fiz essa verificação também na ultima versão e encontrei o mesmo problema.
×
×
  • Create New...