Ir para conteúdo
  • Cadastre-se

Italo Giurizzato Junior

Consultores
  • Total de ítens

    39.767
  • Registro em

  • Última visita

  • Days Won

    1.155

Tudo que Italo Giurizzato Junior postou

  1. Boa noite, A mensagem é clara: Nenhum valor informado no campo NroRegEstadual, esse campo é composto por 25 dígitos.
  2. Boa noite Robinho, Você esta carregando o XML do MDF-e antes de executar a consulta? Se sim, ai esta o problema. Ao carregar o XML o componente se reconfigura baseado na versão do MDF-e carregado que neste caso é 1.00
  3. Rodrigo, Se a empresa é uma transportadora e emite CT-e você não pode dizer que o emitente é transportador de carga própria, pelo simples fato de que a carga não é do emitente e sim de um terceiro (remente). Não tem jeito, essa transportadora vai ter que fazer o seguro da carga que ele vai transportar.
  4. Boa noite José, Se tratando do MDF-e todos os os envios vão para a SEFAZ-RS, não importa a UF do Emitente.
  5. Boa tarde Rodrigo, Você alimentou o componente de forma errada, esta dizendo que o tipo de emitente é um Transportador de carga própria e não um Prestador de serviço de transporte. Sendo assim ele espera a ADD de chNFe e não chCTe. Veja a tag: <tpEmit>2</tpEmit> o correto seria 1 e não 2. Jamais atribua o mesmo valor de nMDF a cMDF por 2 motivos: 1. o tamanho do campo cMDF é de 8 dígitos e de nMDF é 9, logo não cabe um numero de 9 dígitos onde só é aceito 8. 2. quando cMDF é igual a nMDF o documento se torna vulnerável. Essa dica é valida também para a NF-e / NFC-e e CT-e.
  6. Boa tarde Pedro, Só uma correção. As novas versões são: NF-e / NFC-e versão 4.00 CT-e versão 3.00 MDF-e versão 3.00 e não 2.00
  7. Boa tarde, Você tem XSD do CT-e junto com os do MDF-e? Se sim, nunca misture XSD de tipo de documento com outro, terá problemas.
  8. Boa tarde Pedro, Favor anexar o XML do MDF-e rejeitado para que possamos analisar.
  9. Boa tarde, Com essa alteração o grupo <infTribFed> sempre será gerado, desta forma fica em desacordo com o manual.
  10. Boa tarde Graça, Note que no caso do CT-e e NF-e devemos averbar, já o MDF-e devemos declarar. No manual, consta o web services para realizar a declaração do MDF-e e através do mesmo web services podemos enviar os eventos de cancelamento, encerramento e inclusão de condutor. No meu entendimento devemos sim declarar o MDF-e depois de averbar todos os CT-e/NF-e contidos no MDF-e. Quanto ao DAMDFE não encontrei nada.
  11. Boa tarde Flavia, Favor anexar os XML de envio e de retorno do evento de encerramento.
  12. Boa tarde Cleonir, Então o problema não é pegar o retorno do envio e sim erro de validação. O conteúdo do campo NroRegEstadual tem que ter obrigatoriamente 25 dígitos, preencher com zeros a esquerda se necessário.
  13. Graça, Por favor mais uma vez, atualize e faça novo teste.
  14. Bom dia a todos, Para que utiliza o componente ACBrMDFe é preciso atribuir o valor ve300 a propriedade VersaoDF. Para que utiliza o ACBrMonitor, não sei informar se os ajustes para a versão 3.00 já foram todos implementados. Uma coisa é certa, o fim da versão 1.00 estava marcada para junho/2017, foi prorrogado para outubro/2017 e pelo jeito, não tomaram conhecimento da mudança.
  15. Graça, Favor atualizar os fontes e fazer novo teste.
  16. Bom dia Cleonir Configure o componente para salvar os arquivos Soap, faça um novo teste provocando a rejeição e anexe o arquivo soap de retorno.
  17. Bom dia Graça, Favor anexar os arquivos Soap de envio e de retorno para que eu possa analisar.
  18. Bom dia Dionatan, Porque você marcou que o CT-e é um CT-e Globalizado? Se o CT-e não for Globalizado devemos atribuir o valor tiNao da seguinte forma: ide.indGlobalizado := tiNao;
  19. Boa tarde Thiago, No CT-e temos o Grupo <ICMS45> mas o campo CST tem que ser preenchido com os valores: 40 ou 41 ou 51. No CT-e não existe o CST 45, portanto a sua alteração não confere. Manual do CT-e versão 3.00 páginas: 165 ( CT-e ) e 184 ( CT-e OS ).
  20. Bom dia a todos, O <nAVer> tem que ter de 1 a 40 caracteres, sendo assim pode ter apenas 1 mas acredito que deve ser diferente de zero.
  21. Boa tarde Anselmo, Você esta sabendo que a SEFAZ a partir de outubro/2017 não vai mais aceitar a versão 1.00 somente a versão 3.00 do MDF-e? E que a partir de dezembro/2017 não vai mais aceitar a versão 2.00 somente a versão 3.00 do CT-e. E que a partir de abril/2018 não vai mais aceitar a versão 3.10 somente a versão 4.00 da NF-e / NFC-e. Porque você quer atualizar somente o MDF-e? Atualize toda a suite do ACBr, se deseja manter até novembro/2017 a versão 2.00 do CT-e basta configurar o componente para emitir nessa versão, idem você faz a mesma coisa com a NF-e / NFC-e mantendo configurado para a versão 3.10 até março/2017
  22. Bom dia a todos, Acabo de migrar o componente ACBrANe para o Trunk2, vou manter uma cópia do mesmo por uma semana no Branches. Foi migrado os fontes do componente bem como o pacote de instalação para o Delphi e o programa exemplo. O que precisa ainda ser feito: 1. Pacote de instalação para o Lazarus. 2. Criar um ícone para o componente. 3. Acrescenta-lo ao ACBrInstall_trunk2 Não seria interessante criar um "report" para imprimir o resultado da solicitação de averbação? Se sim, é importante termos em Fast e Fortes Report. Quem puder colaborar com o que falta a ser feito fico muito agradecido.
  23. Boa noite Cleonir Este outro também fica vazio? ACBrCTe.WebServices.Enviar.RetornoWS.
  24. Boa tarde ALA, Nota Técnica 2017/002 -página 2 temos a data final da versão 1.00 É melhor correr: 02/10/2017
  25. Boa tarde Hugo, Mas no seu XML contem 3 <veic>. Esta gerando duas páginas?
×
×
  • 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.