Italo Giurizzato Junior

Cleiton, O problema é que o provedor não esta retornando essa informação. Fiz uma alteração para que o componente calcule com base nos demais valores retornados. Atualize os fontes, compile com a opção Build e teste novamente.

Cleiton, Se possível post como anexo o XML da NFS-e cujo valor liquido aparece zerado no DANFSE.

Boa tarde Graça, O XML do EPEC não contem todos os dados do XML da NF-e. Lembre-se que o EPEC é um evento e não a nota. Lançamos mão do EPEC normalmente quando o problema é com o emitente e não com a SEFAZ. Como o XML do evento EPEC é extremamente pequeno em relação ao XML da NF-e, podemos utilizar um modem 3G (por exemplo) para enviar o EPEC. E quando os problemas com o emitente forem sanados devemos enviar o XML da NF-e (cujo EPEC foi enviado) para a SEFAZ, mantendo o tpEmis =4 mais o dhCont e xJust.

Boa tarde a todos, Todas as Units referentes aos provedores possuem uma function chamada GetValidarLote, que no caso do DBSeller temos: function TProvedorDBSeller.GetValidarLote: Boolean; begin Result := True; end; Se alterarmos o valor de retorno de True para False o componente para esse provedor em questão não vai realizar a validação antes do envio. É isso que vocês desejam?

Boa tarde João, Tentou compilar com a opção Build?

Boa tarde Maiko, Favor atualizar os fontes, compile com a opção Build e teste novamente.

Maiko, Por favor post como anexo os arquivos que contem o -soap no final do nome, para que possamos avaliar o problema.

Boa tarde Diogo, Detalhe mais.

Boa tarde Cleiton, Seja mais especifico. Qual é o provedor e o Report que você esta utilizando para imprimir o DANFSE?

Boa tarde Graça, Você disse que: "Fiz a conciliação da nota enviando-a com tpEmiss=1. " Isso esta errado, pois segundo a Nota Técnica 2014/001 na página 4 diz: A emissão do EPEC poderá ser adotada por qualquer emissor que esteja impossibilitado de transmissão e/ou recepção das autorizações de uso de suas NF-e, adotando os seguintes passos: * Gerar a NF-e com “tpEmis = 4”, mantendo também a informação do motivo de entrada em contingência com data e hora do início da contingência, com número diferente de qualquer NF-e que tenha sido transmitida com outro “tpEmis”; (...) Adotar as seguintes providências, após a cessação dos problemas técnicos que impediam a transmissão da NF-e para UF de origem: * Transmitir as NF-e emitidas em Contingência Eletrônica para a SEFAZ de origem, observando o prazo limite de transmissão na legislação, bem como outros procedimentos constantes na legislação caso ocorra rejeição na autorização de uso; * A Chave de Acesso desta NF-e é a mesma Chave de Acesso do EPEC autorizado. Sendo assim ao enviar a NF-e para a SEFAZ-Autorizadora, devemos manter o tpEmis = 4, bem como o motivo e a data e hora do inicio da contingência. Se enviar a NF-e com o tpEmis = 1 não vai ocorrer a vinculação do evento EPEC com a NF-e. Espero ter ajudado.

Boa tarde Maiko, Uma dica muito importante. O componente possui uma propriedade chamada: Configuracoes.WebServices.Salvar cujo valor padrão é False, altere para True e tente novamente. Será salvo mais 2 arquivos com os seguintes nomes: <ID>-ped-inu-soap.xml e <ID>-inu-soap.xml Esses arquivos são salvos de forma completa, ou seja, exatamente com é enviado e como é retornado pela SEFAZ. O <ID>-inu-soap.xml deve conter o erro que esta ocorrendo. Por favor, post como anexo os arquivos nesse segundo teste.

Boa tarde Felipe, Por favor releia a postagem #4 eu deixo claro que: "Existe sim a possibilidade de enviar um lote com até 50 RPS, mas isso depende do provedor." Se você tem 20 RPS a serem enviados para o Web Services, se os mesmos forem enviados um a um, serão necessários 20 conexões de envio, 20 conexões de consulta a situação do lote (que neste caso tem apenas 1 RPS) e 20 conexões para obter o XML da NFS-e. Por outro lado se podemos enviar um lote com os 20 RPS, teremos, apenas UMA conexão de envio, UMA conexão de consulta a situação do lote (que neste caso tem os 20 RPS) e UMA conexão para obter os 20 XMLs das NFS-e. Você prefere realizar 60 conexões ou apenas 3?

Bom dia Isaac, No que diz respeito a Manifestação do Destinatário, você só vai se manifestar em relação a uma NF-e emitida contra o seu CNPJ, sendo assim todos os eventos referente a Manifestação do Destinatário sempre vão ser vinculados a NF-e, pelo simples fato que a mesma foi emitida.

Boa tarde, O componente ACBrNFe, já esta preparado para o novo WebService, estamos apenas aguardando a liberação do mesmo para iniciar os testes.

Boa tarde jwester, Favor atualizar todos os fontes de todas as pastas e testar novamente.

Boa tarde Savério, Basta comparar ele com o que esta no manual, pequenas alterações são aceitas, sem nenhum problema.

Como a SEFAZ se utiliza do CNPJ do emitente também na validação acredito que vai passar batido.

Boa tarde, Você utiliza o componente ou o ACBrNFeMonitor? Se for o componente, favor atualizar todos os fontes de todas as pastas e compilar a sua aplicação com a opção Build.

Boa tarde Renata, Não existe ainda a inutilização de numeração para o MDF-e. A SEFAZ não implementou um Web Services de Inutilização, portanto o componente não possui essa funcionalidade. Se algum dia a SEFAZ vier a implementar, com certeza iremos implementar no componente.

Boa tarde Luis, Tenho dois clientes, um que emite NF-e e outro que emite CT-e, ambos utilizam certificado A3 e nunca tive esse problema.

Boa tarde, Se tratando de transportadora e como o objetivo do MDF-e é facilitar a fiscalização no posto fiscal, o MDF-e deve conter a lista de CT-e emitidos pela transportadora, sendo assim, na chave dos CT-e temos o CNPJ do emitente, ou seja, o mesmo da transportadora, na chave do MDF-e temos o CNPJ do emitente, ou seja o mesmo da transportadora. Não sei se a SEFAZ vai autorizar um MDF-e que contenha em sua lista chaves de CT-e cujo CNPJ seja diferente do emitente do MDF-e. Uma vez que o seu cliente possui 2 empresas, portanto cada uma possui um CNPJ diferente. Segundo o seu exemplo: Empresa 01 , tem 3 CT-e e Empresa 02 mais 2 CT-e no mesmo caminhão. Supondo que o caminhão seja da Empresa 01: A empresa 01 vai emitir um MDF-e usando o certificado dela e relacionando somente os 3 CT-e e vai informar que o veiculo é próprio. A empresa 02 vai emitir um outro MDF-e usando o certificado dela e relacionando somente os 2 CT-e e vai informar que o veiculo é de terceiros.

Graça, Primeiramente muito obrigado pelas respostas. Vamos as conclusões: 1. Se o XML da NF-e foi enviado para SVC e o mesmo contem o protocolo de autorização significa que o envio esta tudo OK, é isso mesmo que tem que ocorrer. 2. Se ao imprimir o DANFE dessa NF-e em vez de aparecer o protocolo de autorização, é apresentado a chave de contingência, esta ai o problema. No meu entendimento apesar de estarmos enviando a NF-e para a SVC - SEFAZ-Virtual de Contingência, e não para a SEFAZ-Autorizadora, a SVC recepciona o XML completo da NF-e, processa e nos retorna o protocolo de autorização de uso. Alem disso a mesma se encarrega de disponibilizar essa nota para a SEFAZ-Autorizadora assim que a mesma voltar a funcionar normalmente. Sendo assim o DANFE deveria apresentar esse protocolo de autorização e não a chave de contingência para as 3 situações de emissão: Normal; SVC-AN SVC-RS Portanto deve-se fazer uma alteração no DANFE para resolver esse problema.

Bom dia Lucas, Reveja a sua rotina de Encerramento, você deve estar informado de forma incorreta a chave do MDF-e. Tenho uma aplicação que só serve para para Consultar um MDF-e pela chave, solicitar o Encerramento ou Cancelamento. E esta funcionando sem nenhum problema.

Bom dia Isaac, Procure sempre ter em mãos a Nota Técnica sobre o que você esta implementando no seu sistema. O componente segue o que esta na NT, se ao consultar temos como retorno da SEFAZ somente as informações A, B e C, são essas informações que o componente vai nos fornecer. Sim, na minha aplicação o campo Confirmacao armazena o tipo de manifestação do destinatário, ou seja, Confirmação da Operação, ....

Graça, Confirme por favor. Ao detectar que a SEFAZ-Autorizadora estava com problemas você realizou os seguintes passos: 1. Alimentou as seguintes propriedades com os valores: tpEmis = 6 dhCont = now (por exemplo) xJust = Problemas técnicos na SEFAZ 2. Gerou o XML, assinou, validou e enviou para a SEFAZ no caso o SVC 3. Imprimiu o DANFE em papel comum O XML gerado e assinado acima mencionado recebeu o protocolo de autorização da SVC? Se sim, ao Imprimir o DANFE o protocolo de autorização foi impresso? Qual versão do DANFE que você esta utilizando (Rave, Fast, Quick, ...)? Caso você utilize o comando: ACBrNFe.Enviar(<numlote>, <imprimir>, <sincrono>); Como se trata de uma NF-e o envio é assíncrono, portanto logo após o envio a SEFAZ ou SVC nos retorna o numero do recibo que é salvo no arquivo: <numrec>-rec.xml feito isso o componente se encarrega de realizar uma consulta com base no numero do recibo, o resultado dessa consulta é salvo no arquivo: <numprot>-pro-rec.xml Em seguida o componente se encarrega de atualizar o XML da NF-e acrescentando o conteúdo do <numprot>-pro-rec.xml deixando o XML da NF-e com validade jurídica, ou seja, assinado e protocolado. Essa atualização no XML da NF-e só ocorre caso a NF-e tenha sindo autorizada pela SEFAZ ou SVC. Caso você não utilize o comando Enviar acima, devemos incluir na nossa rotina o comando para realizar a consulta com base no numero do recibo: sRecibo := ACBrNFe.WebServices.Enviar.Recibo; ACBrNFe.WebServices.Retorno.Recibo := sRecibo; if ACBrNFe.WebServices.Retorno.Executar then begin (...) end; Preciso entender o seu processo para que possamos resolver o problema. No meu entendimento se tratando do SVC apesar de ser uma contingência, o XML é enviado para SEFAZ, logo não vejo motivo do DANFE possuir a segunda chave - Contingência que aparece no lugar do protocolo de autorização.