Italo Giurizzato Junior

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.

Bom dia jwester, Muito obrigado, vou analisar os schemas. Não me recordo se tem mais alguém que utiliza o componente ACBrNFSe para emitir NFS-e em Recife.

Bom dia Graça, Desculpe, esqueci de pedir também o *-pro-rec.xml que é o arquivo que contem o retorno da consulta com base no numero do recibo. Caso você tenha por favor, anexe.

Bom dia Rafael Moroni, Segundo o Manual versão 2.00a do CTe temos: Página 125 - campo: xObs - Observações Gerais é opcional e comporta um texto de até 2000 caracteres. O campo acima se refere a estrutura do XML de um CT-e. Página 85 - campo: valorAlterado - Valor correspondente a alteração é obrigatório e comporta um texto de até 500 caracteres. O campo acima se refere a estrutura do XML referente ao evento de Carta de Correção. Tanto procede que consta no Manual.

Bom dia, Por favor atualize os fontes e teste novamente. Outra coisa verifique se o certificado não esta vencido e verifique também as opções avançadas do Internet Explorer, tem umas 3 opções que trata de revogação de certificados, deve-se deixar desmarcado essas opções.

Graça, Precisamos revisar algumas rotinas, pois o SVC apesar de ser uma contingência, mas esta é diferente da FS-DA onde não ocorre o envio do XML. No caso do SVC, o envio da nota ocorre e é para retornar sim o protocolo de autorização, consequentemente o XML deveria ter essa informação. No caso do FS-DA não ocorre o envio e devemos imprimir o DANFE em papel moeda e depois enviar o XML para SEFAZ para que esta o protocole. Já no SVC, enviamos o XML e já obtemos o protocolo, portanto podemos imprimir o DANFE em papel comum, reduzindo assim custos. Verifique se após o envio para o SVC é salvo o arquivo *-sit.xml, neste arquivo tem que constar o protocolo de autorização. Caso afirmativo e se for possível anexe ele, por favor.

Boa tarde Eric, Que eu me lembre o componente ACBrNFSe não se utiliza da DLL: wininet.dll

Boa tarde Isaac, O DM_VEN é sim um Data Module. Como o meu ERP é multi empresa o xCodEmpresa é o código da Empresa que esta usando o ERP e não o código da empresa que emitiu a nota.

Boa tarde, O Encerramento é um evento e o componente só salva o XML de evento no momento do seu envio.

Boa tarde ncc, Muito obrigado pelo retorno.