Italo Giurizzato Junior

Boa noite Monteiro, Tudo me leva a crer que esse certificado é incompatível com o ACBr e ou DLLs usadas pelo mesmo.

Boa tarde Santos, Tente alterar as configurações do IE no que diz respeito a revogação de certificados. As SEFAZ me parecem que estão alterando os seus certificados.

Ramanho, Muito obrigado pelo retorno.

Boa tarde Luiz, Primeiramente esse tópico se refere ao CT-e e não a NF-e. Segundo a última postagem é de janeiro de 2011.

Boa tarde a todos, Vou escrever uma besteira, será que ocorreu alguma atualização do antivírus e este matou o Capicom? Pois ao mudar de libCapicom para libOpenSSL você deixa de usar a DLL Capicom.

Ramalho, Favor atualizar os fontes e realizar novos testes.

Boa tarde Ramalho, Pelo contrario, o campo assinatura que a mensagem se refere não esta sendo gerado com a letra "E". Vou checar a rotina que gera esse campo.

Talita, A SEFAZ-SP com certeza deve ter feito alguma alteração devido a nova versão e fizeram alguma "kaka". As outras funcionalidades estão funcionando, ou seja, o envio e consulta, o problema só ocorre com o envio de evento no caso o cancelamento?

Bom dia Rogério, Experimenta desmarcar as opções "Revogação de certificados" nas configurações do Internet Explorer.

Bom dia Talita, Qual é a UF do Emitente?

Thiago, Detectado problema na SEFAZ-Autorizadora, você deve alterar o tpEmis, gerar e assinar novamente o XML e enviar para a SVC. Só devemos informar o dhCont e xJust se o tpEmis=5. Alem de alterar o tpEmis é preciso alterar a configuração do componente também veja um exemplo: // (AC,AL,AP,AM,BA,CE,DF,ES,GO,MA,MT,MS,MG,PA,PB,PR,PE,PI,RJ,RN,RS,RO,RR,SC,SP,SE,TO); // (12,27,16,13,29,23,53,32,52,21,51,50,31,15,25,41,26,22,33,24,43,11,14,42,35,28,17); case rgTipoEmissao.ItemIndex of 0: ACBrCTe.Configuracoes.Geral.FormaEmissao := teNormal; 1: if ACBrCTe.Configuracoes.WebServices.UFCodigo in [14, 16, 26, 35, 50, 51] then ACBrCTe.Configuracoes.Geral.FormaEmissao := teSVCRS else ACBrCTe.Configuracoes.Geral.FormaEmissao := teSVCSP; end;

Bom dia Santos, Uma coisa é a Internet do seu cliente, outra coisa é a conexão da SEFAZ com a internet. Acrescente na sua aplicação um campo de configuração onde o próprio usuário ou você possa acessar a maquina do cliente e alterar o tempo. Esse tempo é usado para configurar a propriedade Timeout.

Bom dia Thiago, Em vem de emitir em contingência (tpEmis=5) porque você não emite em contingência tpEmis=7 ou tpEmis=8 (depende da UF do emitente). Detectado que a SEFAZ-Autorizadora esta fora do "ar" a mesma libera a emissão através do SVC - SEFAZ Virtual de Contingência. Desta forma você já obtêm o protocolo de autorização e imprimi o DACTE com o protocolo de autorização, sem perda de tempo. Assim que a SEFAZ-Autorizadora voltar a funcionar, você volta a emitir através da mesma. Todos os CT-e emitidos através da SVC você não precisa se preocupar, pois a SVC se encarrega de enviar para a SEFAZ-Autorizadora todos eles. Agora se o problema é no Emitente, existe uma outra saída, o envio do EPEC (evento) através de uma conexão 3G por exemplo. Quando o problema for sanada ai sim você envia o CT-e para a SEFAZ-Autorizadora.

Boa noite Luis, Muito obrigado pelo retorno. Ainda estou fazer ajustes espero finalizar até o final desta semana.

Boa noite, Muito obrigado pela colaboração, já esta no repositório.

Boa noite André, Notei que o seu fonte esta desatualizado, por favor atualize primeiro todos os seus fontes e depois faça novos testes e se for a questão aplique a sua alteração.

Boa noite Ramalho, Será que esse "E" 60920E NS000 tem haver com o valor da propriedade Tributação?

João, Favor atualizar os fontes e para testar use o programa exemplo, botão [Gerar Lote Rps].

Boa noite João, Não me parece correto, vou analisar.

Boa noite Guto, O arquivo mdfe.xml contem o XML do MDF-e assinado mas não contem o protocolo de autorização. Por outro lado o prot.xml contem somente o protocolo de autorização. Desculpe, mas você guardar esses dois arquivos não servem para nada. O que você precisa guardar é o XML completo, ou seja o XML do MDF-e assinado e protocolado. O componente ACBrMDFe gera esse arquivo e salva em disco, caso esteja configurado para salvar e também o disponibiliza para salvar no banco de dados na propriedade XMLOriginal. Para ler essa propriedade faça o seguinte: sXML := ACBrMDFe1.Manifestos.Items[ 0 ].XMLOriginal; Lembrando que a linha acima tem que ser executado depois do envio. A estrutura do arquivo obtido acima tem a estrutura apresentada na página 87 do Manual versão 1.00a do MDF-e (item 12.2).

Ramalho, Fiz uma alteração no componente, dentro da estrutura DadosServicos inclui as propriedades Operacao e Tributacao. Operacao poderá receber um dos seguintes valores: [toSemDeducao, toComDeducaoMateriais, toImuneIsenta, toDevolucaoSimplesRemessa, toIntermediacao] Tributacao poderá receber um dos seguintes valores: [ttIsentaISS, ttNaoIncidencianoMunic, ttImune, ttExigibilidadeSusp, ttNaoTributavel, ttTributavel, ttTributavelFixo, ttTributavelSN, ttMEI] Inclua na rotina que alimenta o componente essas duas propriedades.

Boa tarde Guilherme, Nota Técnica 2015/001 versão 1.01 - Regras de Validação e Schemas - página 4 item 8: Tag forPag (Forma de Pagamento) passa a ser opcional no schema e deverá ser retirada em versões futuras, recomendamos portanto que deixe de ser preenchida; Essa NT é de abril/2015 como você pode ver a retirada dessa TAG foi anunciada a mais de um ano.

Boa tarde, Quanto a emitir a NFC-e em vez da NFS-e no que diz a notas com datas retroativas não sei lhe responder.

Boa tarde Ramalho, Você poderia disponibilizar esse Manual, pois analisando o fonte encontrei onde a TAG <Tributacao> recebe o valor, mas não encontrei entre as possibilidades uma que atribui o valor "E".

Bom dia, Acredito que sim. Outra coisa, no caso de Manaus, favor verificar no que diz respeito a NFS-e, pois me parece que alguns contribuintes deverão emitir as suas Notas Fiscais de Serviço usando a NFC-e e não a NFS-e.