Jump to content

2 Dia do ACBr

Confira o nosso time de palestrantes
Quero conhecer o Evento

Nova Loja Oficial
loja.projetoacbr.com.br
Ajude o projeto a crescer, com estilo

Comprar

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

All Activity

This stream auto-updates     

  1. Past hour
  2. 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.
  3. Ví isso agora debugando @BigWings no layout antigo mostrava KG ou TON, nesse novo o certo é converter mesmo? Outra coisa aparece assim Modal xxxxxxxxxxx de Carga
  4. O XML contém o peso total em toneladas, ele é convertido para KG na impressão do DAMDFE.
  5. segue 41190722917635000190580010000000251996386300-mdfe.xml
  6. Boa tarde. Estamos tentando associar uma nova assinatura num SAT RB 2000, da Bematech, e recebemos a mensagem de "erro na leitura da porta de comunicação com SAT". Esse SAT já estava em operação. Precisamos trocar a assinatura porque a software house tem um novo certificado digital. Instalamos e vinculamos um novo SAT e funcionou perfeitamente, mas esse que já estava em funcionamento começou a apresentar a mensagem de "assinatura inválida" quando tentamos emitir o cupom fiscal. Por isso precisamos associar a nova assinatura, mas não estamos conseguindo por conta do erro na leitura da porta de comunicação com o SAT. Já tentamos de tudo, mas nada deu certo. Alguém sabe como resolver esse problema? Obrigado.
  7. Baixei o DAMDfe, em anexo e vi que a máscara do PESO TOTAL está errada. Eu mandei 70 KG e na impressão ficou 70.000,00 no XML está 70.0000
  8. Boa tarde Ricardo, Favor anexar o XML que foi gerado e autorizado pela SEFAZ.
  9. 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.
  10. 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.
  11. Today
  12. 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.
  13. Boa tarde Emerson, Você tem que pegar a URL de configuração do trunk2 que foi informada no Tortoise e mudar de trunk2 para branches. A URL para baixar os fontes do Trunk2 é: svn://svn.code.sf.net/p/acbr/code/trunk2 A URL para baixar os fontes do Branches é: svn://svn.code.sf.net/p/acbr/code/branches
  14. Boa Tarde! Não é minha aplicação eu não alimento esse campo. parece ser alguma coisa ligada a esse rps pois os outros passaram no dia 15/07 ela enviou mais de 100 rps para prefeitura e todos derão ok. não tem um jeito de transformar a linha da assinatura em uma string de novo para conferir?
  15. tão simples usar o pesquisar do fórum for i := 1 to xxx do // onde xxx pode variar de 001 até 999 begin with rodo.infANTT.infCIOT.New do begin CNPJCPF := sCNPJCPF[ i ]; // CNPJ ou CPF do responsável pela geração do CIOT CIOT := sCIOT[ i ]; // Código Identificador da Operação de Transporte end; end;
  16. não é isso... pois vc pode ter n seguros o problema é que, é necessário informar dentro da <seg> <nApol></nApol> <nAver></nAver> nas 3, ele só informa 1 delas...
  17. Boa tarde Giovanne, Você esta fazendo confusão, o campo ISUF não tem nada haver com código da UF, esse campos se refere a Inscrição SUFRAMA conforme é apresentado na mensagem de erro de validação. Favor deixar esse campo vazio, ou seja, não alimentar nada, a não ser que o destinatário possui uma Inscrição no SUFRAMA, ai sim você informa o numero dessa Inscrição.
  18. Boa tarde Sergio, É a sua aplicação que esta gerando o conteúdo do campo: NFSe.Assinatura ? Se sim, anexa em um TXT a rotina que gera o conteúdo.
  19. Seu xml tem 3 grupos <seg> com informações diferentes, pode ser que isso seja a causa do problema.
  20. Certamente é problema na ATM. Eles não podem recusar nem pedir pra alterar um XML autorizado.
  21. Está rodando com cryCapicom nesse cliente, em todos os outros cryWinCrypt. Esse é o problema que está acontecendo.
  22. Olá pessoal, Para quem utiliza o componente ACBrCTe e necessita emitir um CT-e de Substituição deve alimentar os seguintes campos: Vamos a estrutura completa: with infCTeNorm.infCteSub do begin chCte := chaveCTeOriginal; indAlteraToma := tiNao ou tiSim; // Se atribuir tiSim significa que foi alterado o tomador // Para tomador contribuinte do ICMS tomaICMS.refNFe := chaveNFe; // NF-e de anulação emitenta pelo tomador // ou informações da Nota Fiscal comum de papel emitida pelo tomador tomaICMS.refNF.CNPJCPF := sCNPJCPF; tomaICMS.refNF.modelo := sModelo; tomaICMS.refNF.serie := iSerie; tomaICMS.refNF.subserie := iSubSerie; tomaICMS.refNF.nro := iNumero; tomaICMS.refNF.valor := vValor; tomaICMS.refNF.dEmi := DataEmissao; // ou a chave do CT-e emitido pelo tomador quanto este for uma transportadora tomaICMS.refCte := ChaveCTeTomador; // caso tenha sido emitido o CT-e de Anulação informar a chave do mesmo no campo abaixo refCteAnu := ChaveCTeAnulacao; end; Exemplo 1: Caso tenha sido emitido um CT-e de Anulação with infCTeNorm.infCteSub do begin chCte := chaveCTeOriginal; indAlteraToma := tiNao ou tiSim; // Se atribuir tiSim significa que foi alterado o tomador // CT-e de Anulação informar a chave do mesmo no campo abaixo refCteAnu := ChaveCTeAnulacao; end; Exemplo 2: Caso o tomador tenha emitido uma NF-e de Anulação with infCTeNorm.infCteSub do begin chCte := chaveCTeOriginal; indAlteraToma := tiNao ou tiSim; // Se atribuir tiSim significa que foi alterado o tomador // Para tomador contribuinte do ICMS tomaICMS.refNFe := chaveNFe; // NF-e de anulação emitenta pelo tomador end; Exemplo 3: Caso o tomador tenha emitido uma Nota Fiscal comum de papel with infCTeNorm.infCteSub do begin chCte := chaveCTeOriginal; indAlteraToma := tiNao ou tiSim; // Se atribuir tiSim significa que foi alterado o tomador // Informações da Nota Fiscal comum de papel emitida pelo tomador tomaICMS.refNF.CNPJCPF := sCNPJCPF; tomaICMS.refNF.modelo := sModelo; tomaICMS.refNF.serie := iSerie; tomaICMS.refNF.subserie := iSubSerie; tomaICMS.refNF.nro := iNumero; tomaICMS.refNF.valor := vValor; tomaICMS.refNF.dEmi := DataEmissao; end; Exemplo 4: Caso o tomador seja uma transportadora e tenha emitido um CT-e with infCTeNorm.infCteSub do begin chCte := chaveCTeOriginal; indAlteraToma := tiNao ou tiSim; // Se atribuir tiSim significa que foi alterado o tomador // chave do CT-e emitido pelo tomador quanto este for uma transportadora tomaICMS.refCte := ChaveCTeTomador; end;
  23. Nesse caso de alguma forma nesse cliente a configuração está diferente de cryWinCrypt ou cryCapicom. Sem ter como replicar o problema não tem como ajudar.
  1. Load more activity
×
×
  • Create New...