Italo Giurizzato Junior

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.

Boa tarde Werner, Foi feita uma correção, favor baixar e testar novamente .

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 Werner, Vamos separar as coisas: Componente de aplicação. A sua aplicação ou o programa Demo podem estar OK, mas o componente pode estar com algum erro. É por isso que sugeri colocar o break point e debugar o que o EnviarEmail faz para tentar encontrar onde esta a linha que gera o erro. Por outro lado fiz uma comparação entre a rotina do ACBrCTe com a mesma do ACBrNFe, tinha algumas diferenças, agora elas estão iguais. Favor atualizar os fontes e testar novamente.

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, O que foi gerado e autorizado pela SEFAZ você não tem que se preocupar. Lembre-se que o método Assinar executa internamente o Gerar, logo não há necessidade de executar o gerar, pois estaria executando duas vezes. O Validar checa se o XML esta assinado se não estiver o executa, logo se desejar pode executar o Validar diretamente. O Enviar por sua vez executa o Assinar e o Validar internamente, sendo assim podemos simplesmente executar o Enviar. Entenda o seguinte, se o XML já foi gerado e assinado para o envio normal, caso haja necessidade de mudar para Offline (no caso da NFC-e) devemos reconfigurar o componente bem como mudar as 3 propriedades que você apresentou nas postagens anteriores. Como o tipo de emissão faz parte da chave de acesso e os 3 campos (tpEmis, xJust e dhCont) fazem parte do XML consequentemente os seus conteúdos são levados em consideração no calculo do DigestValue incluído na assinatura. Outra coisa, em uma emissão normal os campos xJust e dhCont não existem no XML. Por outro lado em uma emissão Offline eles existem. Perante tudo o que foi dito conclui-se que devemos gerar novamente o XML para que os campos xJust e dhCont bem como o novo valor de tpEmis estejam presentes no XML e consequentemente devemos realizar uma nova assinatura para esta esta fique condizente com o novo conteúdo.

Boa tarde Carlos, Tente desta forma: sID := ACBrNFe.EventoNFe.Evento.Items[X].InfEvento.id; Onde X varia de zero até a quantidade de eventos carregados, a principio é apenas um sendo assim o valor de X = zero.

Boa tarde Werner, Como lhe disse não basta saber que o erro ocorre no método EnviarEmail, é preciso debugar tudo o que o método executa para descobrir onde esta provocando o erro. Coloque um break point na linha que é executado o método EnviarEmail, depois vai pressionando a tecla F7 para debugar o método.

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/

Bom dia Rolemar, Como não utilizo o ACBrMonitor Plus, por favor aguarde alguém que tenha um conhecimento maior para te ajudar.

Bom dia Werner, Será necessário um debug mais minucioso para descobrir exatamente onde ocorre o erro.

Bom dia Antonio, Quando uma NF-e é emitida, conforme a legislação devemos disponibilizar ao destinatário o XML da mesma. O ACBrNFe dispõe do método EnviarEmail para que possamos não só enviar o XML como também se assim você desejar o PDF do DANFE. Caso ocorra o cancelamento da mesma, você deve utilizar o método EnviarEmailEvento, este envia o XML (*-procEventoNFe) e se desejar o PDF referente ao evento de cancelamento. Como o XML da NF-e não é e segundo a legislação não deve ser alterado após um cancelamento, não se faz necessário o envio do XML da NF-e novamente junto com o XML de cancelamento. Por questão de organização os XML referentes aos eventos são salvos em uma pasta separada da pasta das notas.

Bom dia a todos, Hinaldo, se você desejar continuar com os fontes do repositório Trunk, fique ciente que a partir de agora a equipe ACBr não vai dar mais manutenção a eles, logo você terá que estudar os fontes e implementar você mesmo todas as alterações necessárias para atender não só essas 2 NT como todas as que virão daqui para frente. Se você não quer ter todo esse trabalho, sugiro que migre para o Trunk2.