Italo Giurizzato Junior

Emerson, Será que não é o antivírus que esta alterando o conteúdo do arquivo antes do seu envio?

Bom dia Felipe, Que eu saiba somente que opera com combustível esta obrigado. Peça para o contador mostrar a lei que define a data da obrigatoriedade.

Bom dia Emerson, Depois do XML ter sido assinado, ele foi alterado e depois enviado?

Bom dia Emerson, Ficou faltando informar a data, por favor atualize os fontes e teste novamente. Atenção: essa alteração foi aplicada somente nos fontes do Trunk2.

Boa tarde Felipe, A principio quem tem que emitir o MDF-e são as transportadoras que realizam transporte de carga fracionada interestadual. Mas se um comercio ou industria alem de realizar a venda do produto também se encarrega de transportar as mercadorias vendidas até o seu cliente e cujo transporte for interestadual e a carga contida no caminhão for fracionada, a resposta é sim, tem que emitir o MDF-e. A transportadora vai relacionar no MDF-e todos os CT-e referentes a carga contida no caminhão. O comércio, industria vai relacionar no MDF-e todas as NF-e referentes a carga contida no caminhão. Acesso o Portal Nacional do MDF-e e baixe os manuais e notas técnicas e a cartilha para ficar mais por dentro do assunto. https://mdfe-portal.sefaz.rs.gov.br/

Boa tarde Jemison, Muito obrigado pela colaboração, assim que possível estaremos disponibilizando.

Ramalho, Eu que agradeço pelos testes. Gostaria muito de receber um retorno de todas as funcionalidades: Envio, Consulta, envio de evento, etc. Algo do Tipo: Envio - Ok Consulta - Ok Consulta Status - Ok (...) Tanto da NF-e quanto da NFC-e, preferencialmente de quem já esta utilizando os fontes do Trunk2. Esse retorno é muito importante para nós.

Ramalho, Como o componente pega a versão que consta no nome do schema, fiz uma alteração tanto no nome quanto na lista de URLs de Serviços. Por favor atualiza os fontes e teste novamente. Atenção: adicionei um schema chamado eventoEPEC_v1.00 caso você não esteja usando a pasta de schemas baixada junto com os fontes,favor copiar esse arquivo para a sua pasta particular de schemas.

Boa tarde Robson, Você esta atribuindo ve310 para a propriedade VersaoDF ?

Boa tarde Robson, Você esta tentando enviar NF-e ou NFC-e e para qual UF?

Boa tarde Ramalho, Eu gostaria que você gerasse o arquivo através do componente e não por fora, pois o meu objetivo é garantir que o componente esteja funcionando 100%. Se a sua aplicação gera o XML que depois é lido pelo componente não posso garantir que o XML gerado pela sua aplicação esteja 100%. Preciso que alguém teste para mim todas as etapas executadas pelo componente: Gerar o XML, Assinar, Validar, Enviar e Obtenção do Retorno. Outra coisa deixa com o valor True a propriedade Configuracoes.WebServices.Salvar para que seja salvo os arquivos de envio e de retorno completos, ou seja, com as TAGs de Envelope, esses arquivos tem a palavra soap no nome.

Bom dia, Favor atualizar os fontes e testar novamente.

Bom dia Emerson, Muito obrigado pela colaboração, já esta disponível. Na NF-e não foi preciso fazer essa alteração pois o valor padrão é para a NF-e.

Bom dia Emerson, Favor atualizar os fontes, foi implementado a opção de salvar o XML de retorno do Download e DistribuicaoDFe com base na emissão do documento. Basta atribuir o valor True a propriedade: EmissaoPathNFe

Pessoal, Primeiramente muito obrigado, já esta disponível, por favor atualizem os fontes e testem. Se possível, testem o EPEC da NF-e e NFC-e. A alteração que fiz visa gerar o XML de envio do EPEC de tal forma que ele fique em conformidade com os Schemas. No caso do EPEC da NF-e se eu não cometi nenhum erro de sintaxe nos fontes é para funcionar 100%, ou seja, é para ser validado pelo componente e aceito pela SEFAZ. Quanto ao EPEC da NFC-e é para ser validado pelo componente, mas vamos ver se será aceito pela SEFAZ. Fico no aguardo de um retorno dos resultados dos testes.

Bom dia a todos, EPEC da NF-e ==> Nota Técnica 2014/001 versão 1.10 página 7 O campo vST é obrigatório, mas vejam que esse campo é filho do campo P17 que é detEvento. Mas fomos obrigado a mudar, ou seja deixar os campos vNF, vICMS e vST como filhos do campo P26 que é dest. Porque essa alteração? No schema (e110140_v1.00.xsd) esta dessa forma e a validação no Web Service também. Portanto a estrutura apresentada na Nota Técnica não esta em conformidade com o schema e Web Service, no meu entendimento o correto seria o que esta na NT uma vez que os 3 campos sitados não são informações do destinatário. EPEC da NFC-e ==> Nota Técnica 2014/003 versão 1.02 página 7 O campo vST não existe, mas vejam que os campos vNF e vICMS são filhos do campo P17 que é detEvento. O componente esta gerando esses dois campos como filhos do campo P26 que é dest. Temos um problema agora, se usarmos o mesmo schema da NF-e para validar, ocorre erro de validação, acusando a falta do campo vST. Se usarmos o schema (eventoEPEC_v0.01) teremos que mudar a forma que o XML é gerado, ou seja os campos vNF e vICMS temos que colocar como filhos de detEvento, para que ocorra a validação. Fazer essa alteração no componente é simples e podemos fazer. Mas será que a SEFAZ vai validar o XML de EPEC da NFC-e desta forma? Se aceitar ótimo, problema resolvido. E se não aceitar? Bom neste caso a solução será alterar o schema e110140_v1.00.xsd de tal forma que o campo vST seja tratado pelo mesmo como opcional. Eu me comprometo a realizar as alterações, sejam no fonte ou no schema. Preciso de voluntários para realizar os testes. Quem se habilita e qual versão do ACBr vai utilizar (Trunk ou Trunk2) ?

Boa tarde Luiz, Por favor tente debugar, para sabermos exatamente onde esta ocorrendo a violação de acesso.

Boa tarde Emerson, Será preciso fazer uma checagem se deseja salvar na pasta mensal referente a emissão do documento e não na pasta mensal correspondente a data atual.

Bom dia Tiago, No meu entendimento quando o problema é a falta de acesso por parte do emitente, ou seja, a SEFAZ-Autorizadora esta operando normalmente, o emitente tem que enviar o evento EPEC, neste caso terá que se utilizar de uma conexão 3G por exemplo. E quando o problema for sanado as NFC-e deve ser enviadas para SEFAZ. Agora se o problema é na SEFAZ que esta parada, ai sim as notas devem ser represadas no SAT (Estado de São Paulo) e quando a SEFAZ voltar a operar normalmente o SAT envia as notas. Como não tenho nada desenvolvido com a NFC-e / SAT, acredito que se a nota foi enviada pelo SAT não se faz necessário enviar novamente como NFC-e.

Bom dia Korporasi, Conhece aquela frase: faça o que mando e não faça o que faço ? Pois bem segundo o manual da NF-e não devemos usar palavras com vogais acentuadas e cedilha no XML da NF-e, mas no retorno a SEFAZ usa. Desta forma se você tentar abrir o XML de retorno da SEFAZ através de um navegador terá problemas. Você pode abrir o XML usando um bloco de notas e alterar o cedilha por C e as vogais acentuas por não acentuadas, ou na sua aplicação escrever uma rotina que faça isso, depois de todo o processo concluído, a sua aplicação carrega o XML como uma string e faz a alteração e salva novamente.

Bom dia Rafael, Você tem certeza que ao enviar o evento EPEC esta configurando o componente para o modelo moNFCe? Pois se no momento de validar esta acusando a falta do vST significa que algo não esta configurado corretamente. Todos os fontes de todas as pastas estão atualizados? Pois fiz uma alteração visando corrigir esse problema, pois para a NFC-e é usado o schema eventoEPEC e não o envEPEC que é usado pela NF-e. Se esta tudo atualizado, você compilou a sua aplicação com a opção Build?

Bom dia Ally, A minha sugestão é desinstalar os componentes que você tem hoje, deletar a pasta que contem todos os fontes ACBr, criar uma nova e baixar os novos fontes do repositório Trunk2 em vez do Trunk. Os fontes que estão no Trunk vão ser congelados e não terão mais atualizações. Com os fontes do Trunk2 com certeza algumas alterações no seu código serão necessárias, mas nada de perder noites de sono. As alterações que tive que fazer na minha aplicação foram na rotina de configuração do componente, do resto não teve grandes mudanças. Como você esta migrando para a versão 3.10 da NF-e existem algumas alterações a serem feitas na rotina que alimenta o componente com os dados da venda, mas também nada de tão complicado. Se você tiver em mãos a nova estrutura do XML da NF-e versão 3.10 você vai descobrir o que é necessário acrescentar ou alterar para que funcione 100%.

Bom dia Claudio, Entendo o que você disse e concordo plenamente com você, uma vez que o XML, disponibilizado pelo emitente desde que assinado e protocolado pela SEFAZ é um documento com validade jurídica. Sendo assim podemos extrair dele todas as informações que necessitamos para cada etapa do processo. É por isso que sempre coloco o dedo na ferida. Todo Emitente de NF-e tem por obrigação legal disponibilizar o XML assinado e protocolado ao Destinatário assim que a SEFAZ retornar o protocolo de autorização. Estamos aqui falando da NF-e e não podemos esquecer do CT-e que também é preciso ser lançado pelo Tomador do Serviço, portanto o Emitente do CT-e também tem a mesma obrigação legal em disponibilizar o XML ao Tomador do Serviço. Hoje temos para a NF-e o serviço DistrubuicaoDFe disponibilizado pela SEFAZ que permite que o Destinatário baixe o XML completo da NF-e desde que realize a manifestação da mesma. No caso do CT-e ainda não temos este serviço, mas estou apostando que em breve teremos.

Duarte, Quanto ao Thread não sei lhe informar. O Daniel, André tem mais propriedade em responder a sua pergunta.

Bom dia Ramalho, Esse erro esta ocorrendo porque tanto o schema eventoEPEC_v0.01 quanto o tipoBasico_v3.10 possuem o tipo complexo: tcOrgaoIBGE. Se você esta com todos os fontes de todas as pastas atualizados, dentro da pasta ...\Exemplos\ACBrDFe\ACBrNFe\Schemas\ve310 você encontra todos os schemas utilizados tanto para a NF-e quanto para a NFC-e na versão 3.10 São esses esquemas que você deve utilizar.