Ir para conteúdo
  • Cadastre-se

Italo Giurizzato Junior

Consultores
  • Total de ítens

    37.596
  • Registro em

  • Última visita

  • Days Won

    1.060

Tudo que Italo Giurizzato Junior postou

  1. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
  2. Boa tarde @João Guilherme Marques, Exatamente, eu fiz as perguntas só para provocar. Não mudou absolutamente nada a não ser o layout do pedido de cancelamento que já foi feito o ajuste em 13/07/2023. Resumindo, não se preocupe com essa informação.
  3. @brajan, Você tem o XML de retorno que contem essa informação? Se sim, poderia anexar?
  4. Boa tarde @brajan, No XML de retorno do envio do RPS o numero do protocolo retornado é 175040?
  5. Boa tarde Carlos, Se você utiliza o componente ACBrNFSeX ou o ACBrLibNFSe ou o ACBrMonitor não precisa se preocupar com nada. Na verdade não mudou nada. Todos que tentaram alterar o componente seguindo as orientações passadas pelo provedor deram com os burros n'agua. Por via das duvidas entre em contato com eles e questione sobre a nova versão e sobre as novas URLs de homologação e de produção do webservice. Eles vão responder que não ocorreu alteração nas URLs do webservice. O que mudou na verdade é o Portal feito pelo provedor que agora esta de cara nova.
  6. Boa tarde @ddsilva, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-5446
  7. Boa tarde @jefferson01, O componente ACBrNFSeX possui uma propriedade de configuração chamada: ConsultaLoteAposEnvio. Se ela tiver com o valor True todo o processo vai ser realizado automaticamente.
  8. Boa tarde @carlessoflu, Checando todos os fontes que compõe o componente ACBrNFSeX, nenhum deles tem em seu código o e-mail: [email protected] Nem no programa exemplo. Sendo assim chego a conclusão que esse e-mail esta em alguma unit da sua aplicação ou esta sendo lido do banco de dados.
  9. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
  10. Boa tarde João, A rejeição Falha no Schema XML é um retorno da SEFAZ, sendo assim o XML que foi gerado, assinado e validado esta OK, o problema é a SEFAZ que não esta aceitando o XML. Ela detectou algo nele e não possui uma mensagem de rejeição especifica, logo retorna essa mensagem genérica. Isso costuma ocorrer quando enviamos para a SEFAZ um XML com uma tag nova e o ambiente de homologação ou de produção não esta preparado para processar essa nova tag.
  11. Boa tarde @Adriano Wolff, Não ficou claro para mim como você esta executando o método Emitir. Segundo o programa exemplo temos: { O método Emitir possui os seguintes parâmetros: aNumLote (String) aModEnvio [meAutomatico, meLoteAssincrono, meLoteSincrono, meUnitario, meTeste] aImprimir (Boolean) Valor Padrão = True, portanto imprime o DANFSE } // como não foi informado o segundo parâmetro o método assume o valor // meAutomatico, isso faz com que ele se ajusta ao provedor selecionado ACBrNFSeX1.Emitir(vNumLote); O provedor SystemPro segue a versão 2.01 do Layout da ABRASF. Na unit ACBrNFSeXProviderABRASFv2 define que o modo de envio padrão para o provedores que seguem a versão 2.xx do layout da ABRASF é meLoteSincrono. Sendo assim ao usar o método Emitir somente com o primeiro parâmetro (Numero do Lote) o segundo parâmetro que defini o modo de envio é assumido como sendo meAutomatico, neste caso é usado o modo de envio da configuração apresentado acima. Veja na unit ACBrNFSeXProviderBase: procedure TACBrNFSeXProvider.Emite; var AService: TACBrNFSeXWebservice; AErro: TNFSeEventoCollectionItem; begin EmiteResponse.Erros.Clear; EmiteResponse.Alertas.Clear; EmiteResponse.Resumos.Clear; TACBrNFSeX(FAOwner).SetStatus(stNFSeRecepcao); if EmiteResponse.ModoEnvio = meAutomatico then EmiteResponse.ModoEnvio := ConfigGeral.ModoEnvio; (...)
  12. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
  13. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
  14. Boa tarde @LeonardoRocha, Fiz uma alteração no componente visando a não impressão da informação "Opção Simples Nacional" quando o provedor não possui essa informação no XML da nota. Como você utiliza o ACBrLibNFSe favor aguardar uma nova versão do mesmo.
  15. Bom dia @brajan, Você poderia anexar o XML soap da Consulta ao Lote bem como o seu retorno?
  16. Bom dia Bruno, O provedor ISSNet possui duas versões, em qual delas você fez essa alteração? Foi testado com qual cidade? Qual cidade você usou para testar a alteração feita no MetropolisWeb ?
  17. Bom dia @Desenvolvimento total S, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.
  18. Bom dia @Adriano Wolff, Checando os fontes do componente, mais precisamente a unit ACBrNFSeXProviderABRASFv2 responsável pela leitura do XML retornado ao executar o método Emitir (procedure TratarRetornoEmitir). Consta sim a leitura da tag CodigoVerificacao e essa informação é armazenada tanto em Response.CodigoVerificacao quanto em AResumo.CodigoVerificacao Você pode ler essa informação da seguinte forma: ACBrNFSeX1.WebService.Emite.CodigoVerificacao ou ACBrNFSeX1.WebService.Emite.Resumos[ x ].CodigoVerificacao (onde x varia de 0 até Resumos.Count -1 Vide o programa exemplo, procedure ChecarResposta.
  19. Bom dia @Heber Germano Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.
  20. Bom dia @CONCEPT AUTOMACAO, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.
  21. Bom dia @bfbraz, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça os testes.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.