Italo Giurizzato Junior

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.

Bom dia Robinho, Sim, o Manual da versão 3.00 do CT-e e os Schema já baixei. O que preciso agora é o Manual do DACTE referente a versão 3.00 que é uma publicação a parte. No caso do CT-e temos dois Manuais, um traz a estrutura do XML e todos os métodos o outro traz o layout do DACTE.

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 Robinho, Você tem alguma informação sobre o Manual do DACTE para a versão 3.00 ?

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).

Amilton, Ao instalar os componentes você selecionou a opção para copiar e instalar as DLLs. Se sim, tem um certificado instalado? Se sim, o componente esta configurado corretamente, ou seja, foi informado o numero de série do certificado?

Boa tarde Phulano, Você não respondeu se utiliza o componente ou o Monitor. Se você utiliza o componente, com certeza a sua aplicação possui uma rotina que lê os dados pertinentes a venda e alimenta o componente, correto? Pois bem, logo no inicio dessa rotina existe uma linha algo do tipo: with ACBrNFe.NotasFiscais.Add.NFe do begin (...) Se você primeiramente armazenar os dados da venda no banco de dados e depois quando o seu cliente desejar emitir as notas, a rotina que alimenta o componente deverá ser executada exatamente o numero de vezes de notas a serem emitidas e a cada execução deve pegar no banco de dados as informações da respectiva nota. Desta forma o componente será alimentado N vezes. Ao executar o método Enviar a mágica acontece, o XML de cada uma delas será gerado, bem como a assinatura e a validação de cada uma delas. Estando todas OK, o lote será gera e enviado para SEFAZ, caso todas sejam autorizadas o protocolo de autorização de cada uma delas será adicionado ao XML que esta assinado e o DANFE de todas serão impressos. Quanto ao limite de notas é 50 e o lote não pode ter um tamanho maior que 500 Kbytes. Se as notas costumam ter uma quantidade grande de itens com certeza o lote deverá conter uma quantidade pequena de notas, caso contrario vai ultrapassar o tamanho máximo de 500 Kbytes. Tanto a quantidade quanto o tamanho você encontra na página 29 da versão 6 do Manual da NF-e. No final desta página temos a estrutura do envio da NF-e ou seja o lote, note que o último item dessa tabela (AP04) se refere ao XML da NF-e e na coluna de observação deixa claro que a quantidade máxima é de 50 notas. E no paragrafo abaixo diz que em média uma nota tem 10 Kbytes, fazendo as contas resulta em 500 Kbytes. Na pagina 32 temos uma tabela de regras de validação e a primeira regra diz que se o tamanho do XML de dados for superior a 500 Kbytes vai ocorrer uma rejeição. O XML de dados entenda como sendo o Lote que esta sendo enviado.

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.