Italo Giurizzato Junior

Boa tarde Leão, Não sei qual é o software que você esta usando para visualizar o XML, mas não existe nenhum linha em branco em lugar nenhum desse XML. Ele só não esta assinado e protocolado e contem o valor 1 informado de forma errada a TAG qMDFe conforme eu já relatei em uma outra postagem sua.

Bom dia Leão, É bem provável que o seu MDF-e esteja sendo rejeitado pelo simples fato de você estar atribuindo o valor UM ao campo qMDFe. O campo qMDFe que fica no grupo <tot> não significa a quantidade de MDF-e que você esta emitindo e sim a quantidade de MDF-e que foi relacionado nesse MDF-e que você gerou. Um MDF-e pode conter uma lista de CT-e no caso de uma transportadora, ou uma lista de NF-e no caso de transporte próprio ou uma lista de MDF-e quando se tratar de transporte Multimodal. Quando o MDF-e possui uma lista de CT-e devemos informar em qCTe a quantidade de CT-e que constam nessa lista. Quando o MDF-e possui uma lista de NF-e devemos informar em qNFe a quantidade de NF-e que constam nessa lista. Quando o MDF-e possui uma lista de MDF-e devemos informar em qMDFe a quantidade de MDF-e que constam nessa lista. Sendo assim somente um desses campos terá um valor maior do que zero os demais são sempre zero. Logo o XML que você postou esta errado, pois aparece: <qNFe>3</qNFe> <qMDFe>1</qMDFe> Sendo que deve aparecer somente: <qNFe>3</qNFe> Faça as devidas correções e teste novamente.

Bom dia Leão, Qual linha em branco?

Bom dia Matthias, Obrigado pelos arquivos, vou analisar e assim que possível disponibilizar as correções necessárias. ***** Favor atualizar os fontes e testar novamente.

Rafael, O Firewall da empresa esta impedindo que eu faça o download do 4shared. Envie os arquivos por e-mail.

Boa tarde Cantu, Na verdade você esta utilizando o método DistribuicaoDFe e não o Download, correto? Você esta passando como terceiro parâmetro o último NSU retornado pela última execução do método? Esta passando uma string vazia como quarto parâmetro? Já tentou realizar o teste em ambiente de produção?

Boa tarde Fabio, Mas esse XML original foi gerado por quem?

Boa tarde Igor, Qual XML foi excluído? No EPEC você tem que informar como Data/Hora de emissão a mesma Data/Hora informada em dhEmi que esta no XML da NF-e?

Bom dia Rômulo, Seguindo as orientações do Daniel, por favor atualize todos os fontes de todas as pastas e refaça os testes.

Bom dia Sandro, Esse XML que você anexou não possui o protocolo de autorização, ele esta apenas assinado. Você deve carrega-lo com o método LoadFromFile e depois executar o Consultar, desta forma o XML será atualizado, ou seja, vai receber o protocolo de autorização, caso o mesmo tenha sido autorizado pela SEFAZ.

Bom dia Pedro, Você pode sim utilizar a mesma série e consequentemente a mesma sequencia de numeração sem nenhum problema, visto que a NF-e é um modelo de documento fiscal e a NFC-e é outro modelo. Uma mesma Empresa pode dependendo da situação emitir a NF-e ou a NFC-e, consequentemente em algum momento será emitido a NF-e serie 1 numero 1500 e em outro a NFC-e serie 1 numero 1500. Repito isso não tem problema nenhum pois são modelos de documentos fiscais diferentes. Modelo da NF-e é 55 e da NFC-e é 65.

Bom dia Rafael, O componente possui 3 propriedades que determina se os XMLs serão salvos em disco ou não. Configuracoes.Geral.Salvar := [True|False] => defini se os XMLs de envio/retorno serão salvos em disco ou não. Configuracoes.WebServices.Salvar := [True|False] => defini se os XMLs de envio/retorno (completos com as TAGs de envelope) serão salvos em disco ou não. Configuracoes.Arquivos.Salvar := [True|False] => defini se os XMLs de validade jurídica serão salvos em disco ou não.

Bom dia Leão, Os espaços em brancos que encontrei no seu XML são normais e estão previstos, não encontrou nenhum que invalidasse o seu XML.

Bom dia Fabio, O método consultar é para quando você já tem o XML assinado e só necessita do protocolo de autorização. Se o emitente perdeu o XML existem 2 soluções: 1. Se o XML em questão foi enviado por e-mail para o destinatário, basta entrar em contato com o mesmo e pedir que lhe envie por e-mail, simples assim. 2. Gerar e assinar o XML com os mesmos dados da primeira vez, tomando o cuidado da chave ser exatamente igual, depois executar o método consultar para obter o protocolo de autorização.

Bom dia Robinho, Qual problema?

Boa tarde Fabio, O Consultar não gera XML do CT-e ele apenas realiza uma consulta. O que ele faz é se você carregar o componente com o CT-e, após a consulta o mesmo será atualizado. Por exemplo, o XML do CT-e esta assinado mas não contem o protocolo de autorização. Você carrega o XML com o LoadFromFile e depois executa o Consultar. O XML do CT-e será atualizado, ou seja, vai ficar assinado e com o protocolo de autorização (caso a SEFAZ tenha autorizado).

Boa tarde Murilo, A mensagem de erro é clara: '' violates pattern constraint of '[!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1}'.The element '{http://www.portalfiscal.inf.br/nfe}cExportador' with value '' failed to parse. Diz que o elemento cExportador contem uma string vazia, sendo assim você deve alimentar esse campo na sua rotina que alimenta o componente com os dados da nota. Te aconselho ter em mãos a estrutura completa do XML para saber quais são os campos obrigatórios e opcionais na hora de alimentar o componente. Você encontra a estrutura completa e atualizada do XML da NF-e na Nota Técnica 2013/005 versão 1.22

Boa tarde Rafael, Post como anexo o XML de envio do evento sem esse arquivo não tem como lhe ajudar.

Boa tarde, O problema é que esse provedor não segue o padrão ABRASF e isso dificulta muito a implementação. A migração do ACBrNFSe para o Trunk2 esta mais demorada por causa desse tipo de documento não seguir os mesmos moldes da NF-e, CT-e entre outros. Na NF-e você gera e assina o XML da NF-e e ao enviar o mesmo para o Web Service da SEFAZ esta analisa e se tudo estiver correto retorna simplesmente o protocolo de autorização. No caso da NFS-e não é assim que funciona, você gera e assina o XML do RPS, envia ele para o Web Service do provedor e este extrai os dados do RPS e gera e retorna o XML da NFS-e. Agora você soma a isso os provedores que usam o padrão ABRASF versão 1.00, os que usam a versão 2.00 e os que usam a versão 2.01 e sem contar com aqueles que alem de usar uma determinada versão do padrão resolveram acrescentar ou inverter alguma TAG de posição. Depois aparecem empresas (provedores) que não seguem o padrão, mas como atendem as necessidades da prefeitura, acabam sendo contratas, alias para muitos funcionários de prefeituras, Web Service deve ser algum restaurante novo onde você mesmo pega a comida. No primeiro momento o nosso objetivo é fazer com que o ACBrNFSe funcione no Trunk2 para os provedores que seguem o padrão ABRASF, depois vamos partir para aqueles que não seguem. Tem que ser assim não tem outro jeito.

Bom dia Rômulo, Muito obrigado pela colaboração, já esta disponível no Trunk2.

Isaac, Você utiliza os fonte do Trunk ou Trunk2? Se for o Trunk abra a uni ACBrNFeUtil e se for o Trunk2 abra o arquivo INI: ACBrNFeServicos.

Bom dia Isaac, Por favor pesquise antes de postar, sobre as novas URLs da SEFAZ-RS e da SEFAZ-Virtual do Rio Grande do Sul já foi dito aqui por dezenas de vezes que já foram atualizadas nos componentes por mim no dia 01/05/2015, sendo assim se os seus fontes estão 100% atualizados não há motivo de se preocupar.

Bom dia Sandro, Arquivo tipo Compartilhamento, são os que devemos compartilhar com os destinatários e transportadoras, se tratando de NF-e temos: *-nfe.xml (nota fiscal eletrônica propriamente dita), esse XML tem que estar assinado e protocolado. *-procEventoNFe.xml (processamento do Evento de NF-e), esse XML contem a solicitação do evento e o retorno da SEFAZ acusando que o evento foi ou não vinculado a NF-e bem como o protocolo da SEFAZ. Temos ainda o *-procInutNFe.xml (processamento da Inutilização de numeração), esse XML contem a solicitação de inutilização de numeração e o retorno da SEFAZ acusando que foi autorizado a inutilização. Esse arquivo no meu entendimento só devemos enviar para o escritório de contabilidade. Você poderia postar em anexo o XML que aparece esse erro de: Arquivo XML não é do tipo Compartilhamento para que possamos analisar?

Bom dia Daniel, O problema em si não é a rotina do nosso amigo Cleonir e sim o XML de consulta gerado pelo componente e enviado para SEFAZ. Esse XML possui a TAG <xServ> onde consta a descrição do serviço a ser executado pelo Web Service, que por sinal até hoje não sei o motivo dessa TAG, uma vez que a TAG principal do XML é <consMDFeNaoEnc> e por ela acredito que o Web Service seja capaz de identificar o que desejamos. Mas tudo bem, na Nota Técnica 2015/001 página 5 temos a estrutura dessa consulta, nota-se que o conteúdo da TAG <xServ> é: CONSULTAR NÃO ENCERRADOS. Veja que a palavra: não, tem a vogal acentuada. Esse é o primeiro caso, e é ai onde mora o problema, se não acentuar o XML será rejeitado pois no schema o conteúdo dessa TAG esta definida da seguinte forma: <xs:element name="xServ" type="TServ" fixed="CONSULTAR NÃO ENCERRADOS"> Sendo assim temos que gerar o XML dessa consulta em UTF8 de tal forma que o conteúdo da referida TAG esteja de acordo com o schema.

Bom dia, Como você faz referencia a NF-e e NFC-e, acredito que você postou em lugar errado, pois aqui estamos tratando da NT 2015/003 do CT-e e não da NT de mesmo numero da NF-e. Mas como essas duas NT tratam do mesmo assunto vamos abrir a NT na página 6: Temos as regras sobre o grupo <ICMSUFDest>, delas podemos concluir varias coisas: 1. pela regra NA01-10 a nota cujo modelo é 65 (NFC-e) será rejeitada se for informado o grupo <ICMSUFDest>, podemos então concluir que só vamos gerar esse grupo para a NF-e. 2. pela regra NA01-20 o grupo <ICMSUFDest> deve ser informado quando <idDest>=2 (Operação Interestadual) e <indFinal>=1 (Consumidor Final) e <indIEDest>=9 (não contribuinte do ICMS). Podemos concluir que o grupo <ICMSUFDest> deverá ser gerado quando vendermos para uma pessoa física situada em outro Estado, portanto ela não é contribuinte do ICMS e é um consumidor final. Espero ter ajudado.