Ir para conteúdo
  • Cadastre-se

Italo Giurizzato Junior

Consultores
  • Total de ítens

    37.488
  • Registro em

  • Última visita

  • Days Won

    1.056

Tudo que Italo Giurizzato Junior postou

  1. Boa noite Flavio, A rotina que assina o RPS é a mesma que assina o Lote, consequentemente o certificado digital utilizado é o mesmo nas duas assinaturas. Amanhã vou analisar o que possa esta ocorrendo e vou enviar uma possível correção para o repositório.
  2. Boa tarde Diane, Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada. Note que o arquivo INI do provedor contem algumas alterações comparado com o que você anexou. Atualiza tudo e faça novos testes.
  3. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
  4. Alexsandro, Eles podem ter alterado alguma coisa no webservice para essa cidade que esta provocando esse erro. Tenta entrar em contato com o provedor e solicite um XML completo, ou seja, com a tag <Envelope> para que possamos comparar com o que o componente esta gerando. Desta forma da para descobrir o que esta errado.
  5. Boa tarde a todos, A implementação do evento no componente já esta sendo feita, acredito que até o final desta semana eu disponibilizo para vocês possam realizar os testes.
  6. Boa tarde Igor, Achei melhor criar uma propriedade chamada TipoUnidade onde você pode atribuir um dos valores: tuHora ou tuQtde. Pois da forma que estava o componente gerava a tag com um valor fixo. Agora é possível escolher o tipo de unidade que se deseja. Favor atualizar os fontes e faça novos testes. Detalhe, é importante acrescentar a linha: TipoUnidade := tuQtde; ou TipoUnidade := tuHora; na sua rotina que alimenta o componente com os dados do serviço.
  7. Boa tarde André, O valor de DM.qryManifestociot.AsString não é uma string vazia?
  8. Alexsandro, Fiz um teste e também tive o mesmo erro.
  9. Boa tarde BigWings, Se não me falha a memória um outro membro do fórum fez uma correção no EL.
  10. Boa tarde Nickolas, Esta ocorrendo uma confusão. Ao enviar o XML do CT-e para ser averbado este deve ser colocando dentro do CDATA, a averbação ocorreu com sucesso, pois o CT-e só a partir de 26/08/2019 será obrigado a ter em seu XML a string do QR-Code em ambiente de Produção. Para quem deseja testar em homologação a data prevista é hoje. Implantada versão 3.00a e Comprovante de Entrega em HMLE na SVRS Foi implantada em homologação na SVRS a versão 3.00a do CT-e e CT-e OS na data de hoje (22/07). A versão contempla alterações nas regras de validação de chave de acesso relacionadas, introdução do QR Code no schema XML e a criação dos eventos de comprovante de entrega e cancelamento do comprovante de entrega do CT-e.
  11. Boa tarde Emerson, Na estrutura de pastas do Branches, consta a pasta que contem o programa exemplo, os fontes do componente e do Pacote de Instalação. É necessário pegar essas pastas do ACBrCiot que esta no Branches e copiar para a estrutura do Trunk2. Feito isso através do Dephi abrir o pacote de instalação, compilar e instalar. Por fim abrir o programa exemplo e iniciar os testes.
  12. Boa tarde Giovanne, Você chegou a verificar com qual valor a variável FPVersaoServico estava passando para o parâmetro versaoDados?
  13. Boa tarde Marcio, Muito obrigado pela colaboração, já enviei para o repositório.
  14. Oliveira, Basta abrir o arquivo Cidades.ini e procurar pelo provedor que atende essa cidade e acrescentar ela da mesma forma que foi incluída para outras cidades do mesmo provedor. Talvez seja necessário abrir o arquivo INI do respectivo provedor e acrescentar as URLs de produção e de homologação para a respectiva cidade. Resumindo veja como foi feito para as demais cidades que utilizam o mesmo provedor e faça igual. Se tudo der certo favor anexar os arquivos alterados para que possamos enviar para o repositório.
  15. Boa tarde Nebrio, O que tem na classe WebServices é uma propriedade chamada aMsg que contem uma mensagem de retorno que pode ser de erro ou não. Logo não tem nada haver com mensagem de cabeçalho ao enviar. O cabeçalho quando este deve ser gerado ele é colocado dentro do grupo Header que faz parte da estrutura do <Envelope>.
  16. Boa tarde Oliveira, A cidade em questão é Serra Azul/SP ou Caieiras/SP ?
  17. Boa tarde Alexsandro, Favor atualizar os fontes, note que fiz uma alteração no arquivo Cidades.ini Utilize o programa exemplo do componente para realizar os testes.
  18. Bom dia Nickolas, Tanto o MDF-e quanto o CT-e (a partir de hoje em homologação e 26/08/2019 em produção) devemos informar a string do QR-Code na tag qrCodMDFe (para o MDF-e) e qrCodCTe (para o CT-e). Nessa string temos o caractere "&", sendo assim se faz necessário o uso do CDATA, para que a validação do XML ocorra sem nenhum problema. A remoção do CDATA do XML apesar de não tornar o XML invalido, uma vez que este é assinado antes da inclusão da tag qrCodMDFe / qrCodCTe, não faz sentido. A ATM por sua vez tem que fazer os ajustes necessários para que o XML do CT-e ou MDF-e sejam aceitos conforme o manual, ou seja, com o CDATA.
  19. Bom dia Asterix, A sua alteração esta correta, aproveitei fiz a mesma correção no CT-e e enviei tudo para o repositório.
  20. Bom dia Allan, Você poderia anexar um XML onde esse problema ocorre?
  21. Ricardo, Acho que você não entendeu o problema no nosso amigo Nickolas. No XML a tag <qrCodMDFe> o seu conteúdo esta entre: <![CDATA[ .... ]]> O motivo de ter o CDATA é por causa do caractere "&" que aparece antes do campo tpAmb. O CDATA tem a função de indicar que o texto dentro dele é um texto comum e não pode ser interpretado como parte da marcação do XML. E ao enviar o XML do MDF-e para a seguradora fazer a averbação o recusa. Para removermos o CDATA do XML do MDF-e a SEFAZ teria que trocar o caractere "&" por "|" como fez na NF-e. Enquanto isso não ocorre, a seguradora vai ter que ajustar o seu sistema para aceitar o XML do MDF-e com o CDATA.
  22. Boa tarde Ricardo, Favor anexar o XML que foi gerado e autorizado pela SEFAZ.
  23. Sergio, Na unit ACBrNFSeNotasFiscais temos uma procedure chamada: AssinaturaAdicional. É ela que é responsável por gerar o conteúdo da tag Assinatura que aparece no XML do RPS. Vai ser necessário debugar essa procedure para saber se algum valor esta sendo passado de forma errada.
  24. Boa tarde Fátima, Se o tomador do serviço é do exterior não tem como informa-lo no grupo de informações do contratante, pois nesse grupo só podemos informar o CNPJ ou CPF do mesmo.
  25. Boa tarde Nickolas, Faça o seguinte teste: Gere o XML do MDF-e sem o ![CDATA], assina, valida e envia para a SEFAZ. Depois nos conta se a SEFAZ autorizou ou não o MDF-e.
×
×
  • 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.

The popup will be closed in 10 segundos...