Ir para conteúdo
  • Cadastre-se

Italo Giurizzato Junior

Consultores
  • Total de ítens

    37.961
  • Registro em

  • Última visita

  • Days Won

    1.073

Tudo que Italo Giurizzato Junior postou

  1. Boa tarde ncc, Segundo a versão 2.00a do Manual do CT-e página 133 campo 242 ICMSOutraUF diz: ICMS devido à UF de origem da prestação, quando diferente da UF do emitente. Dai o retorno de cstICMSOutraUF.
  2. Jefferson, Esquece o Trunk, no Trunk2 o padrão é para não consultar. Volto a te perguntar o componente esta configurado para consultar após o envio.
  3. Boa tarde Elton, Qual provedor?
  4. Boa tarde Jefferson, O componente esta configurado para consultar após o envio?
  5. Dercide, Anexe o XML de envio gerado ao usar o método Gerar.
  6. Boa tarde Dercide, Acabo de realizar um teste de envio de um RPS usando o método Enviar para o provedor WebISS e esse erro não ocorreu. Você tem certeza que os fontes estão atualizados? Compilou a aplicação com a opção Build? Esta usando o programa exemplo ou outra aplicação?
  7. Boa tarde João, Primeiramente consta na legislação que o emitente da NF-e tem que disponibilizar o XML da NF-e para o destinatário e para a transportadora quando esta for a responsável pelo transporte da mercadoria. A forma mais simples é enviar um e-mail para a transportadora contendo o XML. Desta forma na sua aplicação basta você utilizar os dois componentes ACBrNFe e ACBrCTe. Com o ACBrNFe você vai conseguir ler o XML da NF-e para ler não só a chave como também todos os dados necessários para a emissão do CT-e. A minha aplicação funciona dessa forma, tenho duas opções, sendo que a primeira o funcionário tem que digitar tudo, já a segundo solicitar a importação do XML da NF-e. A rotina de importação se encarrega de fazer tudo, inclusive cadastrar o remetente e o destinatário se necessário sem falar no calculo automático do frete. Outra forma da transportadora obter o XML da NF-e é pedir para o emitente da mesma sempre informar o seu CNPJ no grupo <transporta> Grupo Transportador da NF-e. Se o emitente fizer isso, a sua aplicação poderá se utilizar do método DistribuicaoDFe que existe no componente ACBNFe. Ele retornará o XML completo da NF-e, não havendo a necessidade do emitente da NF-e enviar o XML por e-mail para a transportadora, basta informar o CNPJ da mesma no grupo mencionando acima. Bom, tendo o XML obtido pelo método DistribuicaoDFe ou por e-mail as coisas ficam fácil como demostrado acima. João a ferramente esta ai a sua disposição, arregaça as mangas e bom trabalho.
  8. Boa tarde Souza, Como lhe disse Fortaleza se utiliza do Ginfes mas com algumas diferenças. Se você abrir a unit ACBrNFSeConfiguracoes, vai descobrir que se o nome do provedor for ISSFortaleza ele troca por Ginfes. Os Schemas devemos utilizar da pasta Ginfes. Se você estiver testando com a sua aplicação, incluiu as linhas de configuração do emitente (vide programa exemplo) ?
  9. Boa tarde, O problema ocorreu depois de uma nova compilação devido a uma atualização dos componentes? Ou nada foi alterado?
  10. Boa tarde Joel, Desfaça a sua alteração e atualize todos os fontes. Note que fiz uma alteração no arquivo INI do provedor.
  11. Boa tarde Danilo, Muito obrigado pelo retorno, já fiz a alteração no arquivo INI e disponibilizei no repositório.
  12. Boa tarde Silvio, Você esta usando o componente ACBrNFSe? Lhe pergunto isso, pois até o momento o componente não atende a cidade de Guarapuava.
  13. Boa tarde Agnaldo, Muito obrigado pela colaboração, já esta disponível.
  14. Boa tarde Marcos, Você não configurou as propriedades do Emitente. Vide o programa exemplo.
  15. Boa tarde Luiz, Você esta configurando e alimentando o componente corretamente? Pois segundo a versão 2.00a do Manual do CT-e - página 36 temos uma tabela de regras e a regra G010 diz que se a forma de emissão do CT-e for diferente de 5 (FS-DA): dhCont e xJust não devem ser informados. Na minha aplicação tenho: Configuração do componente: case rgTipoEmissao.ItemIndex of 0: DMDFe.CTe.Configuracoes.Geral.FormaEmissao := teNormal; 1: DMDFe.CTe.Configuracoes.Geral.FormaEmissao := teFSDA; // Contingencia FSDA 2: if DMDFe.CTe.Configuracoes.WebServices.UFCodigo in [14, 16, 26, 35, 50, 51] then DMDFe.CTe.Configuracoes.Geral.FormaEmissao := teSVCRS else DMDFe.CTe.Configuracoes.Geral.FormaEmissao := teSVCSP; end; Alimentação do componente: case rgTipoEmissao.ItemIndex of 0: Ide.tpEmis := teNormal; 1: Ide.tpEmis := teFSDA; // Contingencia FSDA 2: if DMDFe.CTe.Configuracoes.WebServices.UFCodigo in [14, 16, 26, 35, 50, 51] then Ide.tpEmis := teSVCRS else Ide.tpEmis := teSVCSP; end;
  16. Paulo, Favor configurar o componente para salvar os arquivos Soap. O retorno do status de homologação esta em branco.
  17. Bom dia Wilson, Faça uma cópia da sua implementação e atualize os fontes fiz uma alteração agora pouco visando resolver esse problema. Caso detecte mais algum problema favor altera-la com base no que foi enviado agora para o repositório.
  18. Joel, Favor atualizar os fontes e testar novamente.
  19. Felipe, Esta difícil interpretar corretamente essa mensagem de erro. Em um primeiro momento podemos concluir que esta sendo feita uma referencia a um objeto que não existe, se é isso, então qual é esse objeto? Como lhe disse não encontrei nada de errado na grafia das TAGs bem como a sua ordem. Como a mensagem de erro não é clara sugiro que entre em contato com o pessoal da Tecnos quem sabe eles dizem o que esta errado.
  20. Bom dia, Esse problema esta ocorrendo somente com essa nota ou com todas? Se no XML os valores estão aparecendo zerados é porque eles não foram informados, ou seja, o componente não esta sendo alimentado de forma correta.
  21. Eu tive um professor que dizia: quanto mais você escreve, mas você erra. Em uma aplicação quanto mais informações o usuário tem que digitar mais ele vai errar. É por isso que eu procuro nas minhas aplicações parametrizar o máximo possível, ou seja, colocar em tabelas de configuração no banco de dados. No caso da alíquota, se o usuário tem que digitar toda vez que for emitir uma nota, com certeza uma hora ele vai errar. Por outro lado se essa informação esta parametrizada, ela não precisa ser digitada evitando assim o erro. O que você esquece é que o seu problema é pontual, onde a sua aplicação vai usar somente esse provedor ou mais algum outro. Eu por outro lado estou escrevendo um componente que tem que satisfazer mais de 50 provedores. Como lhe disse dos 58 provedores (para ser exato até o momento) somente o Governa exige mais essas duas informações na consulta. Se eu for começar a colocar essas diferenças como parâmetros nos métodos vai chegar uma hora que vamos ter dezenas de parâmetros. O componente ainda não esta 100% para todos os provedores e com a migração para o Trunk2 estou analisando todos os fontes para tentar reduzir o máximo possível de IF Provedor. Quero um código o mais limpo possível.
  22. Felipe, Comparando o XML enviado com o schema e mais o WSDL do web service conclui: 1. não encontrei nenhum nome de TAG ou Grupo diferente do que esta estabelecido, inclusive aparecem na ordem definida. 2. no WSDL existe o grupo <cabecalho> tanto no método do envio quando da consulta, mas eles não são gerados pelo componente e esse grupo no WSDL consta como opcional. 3. achei estranho o web service retornar após o envio o numero de protocolo contendo 23 dígitos, sendo que no schema ConsultarLoteRpsEnvio.XSD que contem a estrutura do XML para realizar a consulta ao lote consta que a TAG Protocolo é do tipo Integer. E o que esta sendo informado é exatamente o retorno do envio, ou seja, o protocolo com 23 dígitos que com certeza poderia ocorrer erro no Web Service. No seu envio, foi informado o numero de lote = 88, pelo que notei o numero do protocolo nada mais é do que o CNPJ + numero do lote formatado com 9 dígitos totalizando os 23 dígitos. Tente consultar novamente mas passando os seguintes valores: ====> sintaxe: function ConsultarLoteRps(ANumLote, AProtocolo: string): Boolean; OK := ACBrNFSe.ConsultarLoteRps('88', '88');
  23. Bom dia Dercide, Favor atualizar novamente todos os fontes e realize novos testes.
  24. Bom dia a todos, Graça, não, essa mensagem de erro é do componente e não um retorno do Web Services ou uma tentativa de conexão com ele. Quando comecei a migrar a minha aplicação para usar os componentes do Trunk2 passei por uma situação desse tipo. O problema era a versão errada definida na propriedade VersaoDF. Hoje tenho os componentes ACBrNFe, ACBrNFeDANFE e ACBrMail bem como a rotina de configuração deles em um Data Module, desta forma eu tenho a garantia que feita a configuração ela será valida para tudo o que preciso.
×
×
  • 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.