Italo Giurizzato Junior

Bom dia Gabriel, Não é possível uma unica aplicação possuir um componente do trunk e outro do trunk2. O componente ACBrNFSe já foi migrado para o Trunk2, mas existem alguns problemas para serem resolvidos. Por exemplo: Criar os arquivos INI para cada provedor, resolver uma questão pendente que é quando o lote é assinado e os RPS também (o componente hoje só consegue assinar o lote se o RPS não for assinado), realizar testes e fazer as devidas correções nos métodos: Gerar, EnviarSincrono e SubstituirNFSe. Se o provedor que você necessita para emitir as NFS-e não requer que tanto o lote quanto o RPS sejam assinados e o método de envio é o Enviar, basta então verificar se o arquivo INI dele já esta disponível ou não, se não esta ou você aguarde ou baseado nos que já existem tente fazer e realize os testes, se tudo der certo não esqueça de disponibilizar o INI do provedor.

Bom dia a todos, Gilson, a coisa é mais simples o que parece, vamos aos passos: 1. A nota é enviada a SEFAZ; 2. Se não ocorrer nenhuma falha de conexão com a internet temos o retorno da SEFAZ; 2.1. Temos que analisar o cStat para saber se a nota foi autorizada, denegada ou rejeitada; 2.2. Se foi autorizada o XML é atualizado com o protocolo de autorização e o DANFE é impresso. 2.3. Se foi denegada o XML é atualizado com o protocolo de denegação e a venda não é realizada. 2.4. Se foi rejeitada é preciso efetuar a correção do dado errado, gerar, assinar e enviar novamente o XML (voltar ao passo 1); 3. Se ocorreu falha de conexão devemos carregar o componente com o XML assinado e realizar uma consulta; 3.1 Se nessa consulta não ocorrer nenhum erro de conexão temos que analisar o cStat, analise semelhante aos passos 2.2, 2.3 e 2.4 3.2 Caso a nota seja rejeitada por não constar na base de dados da SEFAZ, devemos efetuar o envio novamente, neste caso fica claro que o erro de conexão ocorreu logo no envio e não no retorno. Seguindo esses passos, você nunca vai ter problemas de notas em duplicidades. Quando lançamos mão a contingência? Quando o problema de conexão vai demorar para ser sanado. Outra coisa, temos que saber onde esta a origem do problema (SEFAZ ou contribuinte)? Dependendo de onde é o problema o tipo de contingência a ser executado é diferente. Se o problema é com a SEFAZ devemos alterar o tipo de emissão para offline (no caso da NFC-e), informar a data e hora de contingência mais a justificativa, gerar e assinar novamente o XML e simplesmente imprimir o DANFE. Quando os problemas forem sanados devemos enviar esse último XML para a SEFAZ. Agora se o problema é com o contribuinte, se este possuir uma conexão 3G (por exemplo) deve-se também alterar o tipo de emissão para EPEC, informar a data e hora de contingência mais a justificativa, gerar e assinar novamente o XML, imprimir o DANFE e por fim enviar via 3G o evento EPEC. Quando os problemas forem sanados devemos enviar esse último XML para SEFAZ.

Bom dia, Eu em particular não concordo muito com essa propriedade. Suponha que a sua aplicação salva os XMLs somente em disco, neste caso o XML será gerado, assinado e validado para que seja enviado para a SEFAZ. Caso ocorra algum erro no retorno, é possível carregar o componente novamente com o XML que já esta assinado e efetuar uma consulta, caso o mesmo foi recebido e processado pela SEFAZ com sucesso, teremos como resposta o protocolo de autorização e o componente por sua vez vai inclui-lo ao XML. Se o XML inicialmente gerado, assinado e validado não for salvo em disco em função da propriedade SalvarApenasMDFeProcessados, você não o terá para realizar essa consulta. Nas minhas aplicações o XML só gerado no momento do envio, sendo assim se existe um XML assinado mas sem o protocolo de autorização significa que ocorreu algum problema no envio do mesmo. Realizando a consulta mencionada acima se a SEFAZ retornar o protocolo significa que o problema foi no retorno, mas se voltar uma mensagem informando que o documento não existe na base de dados da SEFAZ, isso significa que o problema ocorreu logo no envio, sendo assim devemos envia-lo novamente.

Bom dia Mailson, Até onde sei é a NT 2015/002 inteira que será prorrogada para o ano que vem no que diz respeito ao ambiente de produção. Por outro lado as datas da NT 2015/003 ainda continuam valendo.

Bom dia DATAC, Pelo que andei lendo no fórum no caso do RS existe um CSC especifico para cada ambiente, sendo assim não se pode usar o de produção para realizar testes e também não é valido do que o Juniorsk8 postou para o RS.

Bom dia a todos, Jones, no seu primeiro post você diz que não pode migrar para o Trunk2 pelo simples fato de que necessita do ACBrGNRE e ACBrNFSe. Pois bem, eu lhe informei que os fontes do ACBrNFSe disponíveis no Trunk2 compila e instala, mas ele esta funcional para o provedor Ginfes, para os demais provedores serão necessários mais ajustes e criação dos arquivos INI de configurações. Lhe convidei a fazer as devidas alterações no fonte do ACBrGNRE que esta disponível no Trunk2 para que o mesmo possa ser compilado e instalado. Agora você disponibiliza os fontes do ACBrGNRE dizendo que é um quebra galho. Essas alterações que você fez foi baseado em que? Como você sabe que essas alterações será possível compilar e instalar na nova estrutura? No meu entendimento você tem que baixar os fontes do Trunk2 em uma maquina isolada, instalar (usando o ACBrInstall_Trunk2) todos os componente exceto o ACBrGNRE. Depois usando o pacote de instalação do mesmo tentar compilar e instalar. A medida que for surgindo os erros, deve-se resolve-los até que a compilação e instalação seja bem sucedida. O próximo passo é testa-lo de preferencia usando o programa exemplo. Finalizado os testes e funcionando como deve ser, ai sim você disponibiliza de forma zipada, os fontes do componente, o pacote de instalação e o programa exemplo caso este tenha sido alterado para funcionar.

Boa tarde Gilson, Como assim se retornar que a nota enviada já existe na SEFAZ você altera o tipo de emissão e envia novamente? Não entendi nada o que você esta fazendo. Outra coisa você só remove a assinado executando um Clear e alimentando o componente novamente do zero.

Boa tarde Carlos, Com certeza os seus schemas não estão atualizados.

Boa tarde, Favor atualizar os fontes e testar novamente.

Boa tarde Thiago, Primeiramente, se atente ao seguinte: Quem pode emitir o MDF-e? Transportadoras, neste caso deve relacionar os CT-e que ela emitiu. Empresas que realizam o transporte da própria mercadoria vendida. Por exemplo você tem uma loja de moveis e possui um caminhão. A sua sua loja vai emitir a NF-e referente a venda e caso o destinatário seja de uma cidade em outro estado, será necessário emitir o MDF-e. Vale lembrar também que a emissão do MDF-e é para transporte interestadual e carga fracionada, ou seja, serão realizadas diversas entregas para destinatários diversos. Sendo assim o emitente do MDF-e é o mesmo da NF-e. O XML que você postou traz como emitente uma empresa (vide a TAG CNPJ do emitente - final é /0001-12) e outra como emitente das NF-e (vide CNPJ contido na chave das NF-e - final é /0001-76) Esse CNPJ que aparece no emitente tem que ser o mesmo que aparece nas chaves das NF-e. Com certeza esse CNPJ com final /0001-12 não esta habilitado junto a SEFAZ a emitir NF-e.

Bom dia Werner, Para se obter o XML assinado e protocolado de forma legal existem 3 formas: 1. O emitente da nota deve enviar por e-mail o XML conforme consta na legislação, se ele não faz isso você esta recebendo a mercadoria sem nota, pois o DANFE para o Fisco não tem validade jurídica a não ser que o destinatário seja pessoa física. 2. Pelo site da SEFAZ; 3. Usando o método DistribuicaoDFe; Vamos então a esse método: 1. Na pasta Doctos\Manuais você encontra o PDF: Manual ACBrNFe versão 1.04 caso você já esteja usando os fontes do Trunk2 com certeza alguns métodos estão diferentes, mas o DistribuicaoDFe não mudou nada e na página 15 você encontra uma breve explicação bem como o significado de cada parâmetro dele. 2. No Portal Nacional da NF-e em Notas Técnicas você encontra a NT 2014/002 versão 1.01 que trata sobre o Distribuição DFe são apenas 13 páginas, considero a sua leitura muito importante. 3. A sua utilização é bem simples mas para poder obter o tão desejado XML assinado e protocolado é necessários alguns passos a mais. Devemos inicialmente executar o método DistribuicaoDFe para obter os resumos das NF-e, em seguida devemos realizar a manifestação do destinatário em cada uma delas (lembrando que a manifestação é um evento, vide NT 2012/002 versão 1.02) ao executar pela segunda vez o DistribuicaoDFe, dependendo do tipo de manifestação teremos como resposta o XML completo da NF-e. Não é preguiça ou não querer explicar o que é e como faz, eu sempre peço para que as pessoas leem os manuais e notas técnicas, pois estarão lendo um documento que foi publicado pelo ENCAT e disponibilizado no Portal Nacional da NF-e da SEFAZ, pressupõe que as informações contidas sejam corretas. Ocorrem alguns erros sim, ninguém é perfeito. Estamos aqui para esclarecer algumas duvidas.

Bom dia, Já postei em um outro tópico que as chances de prorrogar o inicio em ambiente de produção são muitas, acredito que somente para o ano que vem vai ser necessário, visto que algumas SEFAZ não implementaram ainda em ambiente de homologação.

Bom dia, Cuidado para não confundir o certificado digital em formato de Token com o CSC - Código de Segurança do Contribuinte que antes também era chamado de Token. O idCSC e CSC são obrigatórios para gerar a URL do QR-Code usado na NFC-e.

Bom dia a todos, Me parece que a obrigatoriedade de incluir o QR-Code no XML em ambiente de produção vai ser prorrogado para o ano que vem, visto que algumas SEFAZ nem sequer ainda implementaram essa obrigatoriedade no ambiente de homologação.

Bom dia Claudio, No caso do Open SSL há necessidade de que a unidade tenha no minimo 3 caracteres.

Você pode zipar somente os fontes que foram necessários alguma alteração e postar aqui mesmo em anexo. Caso seja necessário também alteração no pacote de instalação separe em um outro Zip.

Bom dia Luiz, Se isso ocorreu significa que a unit pcnNFeR foi alterada por você e consequentemente não foi atualizada. Sugiro que renomei caso você tenha feito alguma alteração e baixe ela novamente.

Bom dia Jones Almeida, Que tal contribuir com o projeto e fazer as alterações necessária no GNRE? Para que o mesmo fique funcional com o Trunk2. Eu não uso o ACBrNFSe, mas estou fazendo as devidas alterações para que o mesmo funcione no Trunk2.

Bom dia Gilvan, Esse problema já foi comentado em outra postagem. O problema é a URL da SEFAZ-PB que inventaram de acrescentar um parâmetro a mais. A SEFAZ já esta ciente do problema e esta estudando uma solução para o mesmo.

Bom dia Mauro, Pelo que eu entendi você esta usando o programa gratuito da SEFAZ para poder emitir o MDF-e, correto? Pois bem, aqui nós não usamos esse programa, nós desenvolvemos componentes e programas para emitir MDF-e. Existe um site especifico do MDF-e onde você encontra uma cartilha, não é o manual desse programa mas acredito que vai lhe ajudar bastante a entender como deve proceder. https://mdfe-portal.sefaz.rs.gov.br/

Programa exemplo do ACBrNFSe - Trunk2 Visulizar Arquivo Na pasta onde for descompactado o executável, deve-se colocar junto os arquivos INI que são baixados junto com os fontes do repositório Trunk2. Autor Italo Jurisato Junior Enviado 09-10-2015 Categoria Utilitários ACBr

Boa tarde, Os últimos 9 dígitos são 8 do cCT e 1 do Digito Verificador. Se esta diferente é porque você optou por fazer com que o componente gere automaticamente de forma aleatória o cCT (código aleatório do Conhecimento de Transporte). A SEFAZ aconselha que o cCT seja aleatório. Você pode contornar esse problema fazendo o seguinte: 1. Quando for salvar no banco de dados as informações pertinentes ao conhecimento gere um numero aleatório com no máximo 8 dígitos e que seja maior que zero. Salve esse numero com as demais informações no banco de dados. 2. Quando for alimentar o componente com os dados atribua o numero gerado a propriedade cCT. 3. Caso você utilize o LoadFromFile para carregar o conteúdo de um XML do CT-e, lembre-se de atribuir o valor False como segundo parâmetro, isso faz com que o componente não gere novamente o XML. Espero ter ajudado.

Boa tarde Rogério, Antes de executar o método Consultar você esta carregando o XML da NF-e? Se sim, você poderia postar em anexo o arquivo: *-sit.xml ?

Boa tarde Marcio, Se esta falhando na validação da TAG qrCode o problema é que você não configurou as propriedades CSC e idCSC do componente.

Boa tarde Pedro, Por favor leia a Nota Técnica 2014/001 v1.10 que trata sobre o Evento EPEC. É ele que substitui o DPEC.