Fim do Emissor Gratuito

[Darc]

Bom dia.

Com o descontinuação do emissor gratuito de nfe, estou com um grande problema. Meus sistemas são todos desenvolvidos em clipper, gero o arquivo txt e importo para o emissor gratuito. Que saída tenho agora? Alguém tem alguma sugestão?

Desde de já agradeço.
Darc

[Jairo Maia]

Olá Darc,

Leia este tópico, acho que pode ajudar: Fim do emissor gratuito

[Darc]

Bom dia, Jairo.

Já estou lendo, inclusive estou tentando acessar a página no Projeto ACBr, mas a mesma não esta respondendo.

[JoséQuintas]

De TXT pra XML é relativamente fácil.
Na prática, o único problema com o DOS é que ele gera um control-Z como final de arquivo sempre, mas pode ser contornado usando as funções fOpen(), fClose(), etc, ou até um programa externo.
XML não é um bicho de 7 cabeças, e se gera TXT já tem a parte mais difícil pronta.
Usando XML já libera qualquer solução existente.

Componentes grátis tem o ACBR e o UNINFE/UNIDANFE.
Destes aqui uso só o Unidanfe pra gerar PDFs (que pode ser usado pra imprimir NFE, CTE, MDFE, carta de correção, etc).

Aproveita estes meses que tem o emissor pra ajudar em testes, e comece a pensar no XML, pra ter opções ilimitadas.
No final acaba sendo mais fácil trabalhar com o XML do que com o TXT, pra resolver problemas e até pra acrescentar "novidades".
Lembre-se que como não vai existir TXT oficial depois, cada solução pode inventar um padrão diferente.

Quanto à comunicação entre o aplicativo e ACBR/UNINFE, é na base de MemoRead() e MemoWrit(), relativamente simples.

É só não ter pressa, porque às vezes uma única letra já causa problema, e se tiver pressa, não vai "enxergar" essa letra.

É fazer uma coisa de cada vez, entender o que está fazendo, testar, e só depois ir pra próxima etapa.
Assim, uma etapa vai sendo mais rápida que a outra, porque já vai saber o que pode acontecer.
Se tentar tudo correndo, tudo de uma vez, pode ter vários "mesmos problemas" pra resolver, e não vai ter tempo de entender.

Não é obrigatório, e não depende disso, mas se achar que pode usar o Harbour pro seu aplicativo pode ajudar.
Senão tudo bem.
Em último caso pode até usar o Harbour pra ajudar a remover o Ctrl-Z do TXT ou XML.
Nada complicado, só isto:

Código: Selecionar todos

PARAMETERS cNomeDoArquivo
hb_MemoWrit( MemoRead( cNomeDoArquivo ) )

Só vai ler o arquivo DOS que tem control-Z, e gravar sem control-Z.
E no Clipper:

Código: Selecionar todos

RUN ( "programa.exe arquivo.txt" )

Fique tranquilo, faça tranquilo, que dá tudo certo.
Só não deixe pra última hora.
É simples, mas é trabalhoso.

É igual construir uma parede de tijolos.
Gaste bastante tempo nos primeiros tijolos.
O que aprender nesses primeiros tijolos, vai te ajudar e facilitar em todos os outros.
Nos últimos tijolos, vai ter fazendo rápido e de olhos fechados..... rs

[Jairo Maia]

Olá José,

Aproveita estes meses que tem o emissor pra ajudar em testes, e comece a pensar no XML, pra ter opções ilimitadas.
No final acaba sendo mais fácil trabalhar com o XML do que com o TXT, pra resolver problemas e até pra acrescentar "novidades".
Lembre-se que como não vai existir TXT oficial depois, cada solução pode inventar um padrão diferente.

Com certeza José. Concordo também. Porém, na verdade, trabalho e indico o ACBrMonitor, porque achei bem mais fácil adaptar o sistema para gerar um arquivo TXT no formato do ACBr. Ao enviar esse arquivo TXT ao ACBr, ele cria o XML e envia o XML para gerar a nota. Tem a opção de enviar também o TXT no formato da SEFAZ, mas nunca usei, sempre uso a opção para gerar o XML e enviar. Esse XML de envio fica disponível ao usuário também.

Resumindo: A comunicação em TXT é apenas entre a aplicação e o ACBr que por sua vez envia o XML criado com base no TXT no padrão ACBr.

[JoséQuintas]

Provavelmente também aceita em formato XML, que é padrão geral.

Acontece em alguns conversores que acaba dando erro no XML, e aí a pessoa não sabe resolver pelo TXT.
Nesse caso vai depender de quem use txt, ou de correção/ajuste no conversor.

Se for deixar pra depois... vai sempre deixar pra depois... rs

[rubens]

Bom dia...

O acbr aceita o arquivo no formato xml também... é só configurar no monitor que vai comunicar xml.
Hoje os comandos do txt do acbr estão praticamente os mesmos do xml, então essa conversão não vai ser difícl e nem muito complicada.
A Questão é que na geração do txt é mais fácil e amigável do que gerar o xml manual. Para quem já trabalha com xml é mais fácil, mas para quem vai começar do zero o txt fica mais de entender..
Bom vai depender de cada um. O que achar mais fácil.

MAs o que precisamos mesmo é criar uma força tarefa para por o hbnfe para funcionar mesmo né... ?!?!?!?!?

Rubens

[JoséQuintas]

MAs o que precisamos mesmo é criar uma força tarefa para por o hbnfe para funcionar mesmo né... ?!?!?!?!?

Então comece dizendo o que não funciona.

[rubens]

Calma mestre...
Nâo entendeu o meu comentário... Nâo falei que não funciona... Eu pelo menos não estou com ele em funcionamento. Foi simplesmente um comentário... repetindo o que outro colega comentou em outro post. O que eu quis dizer é que temos que colocar ele para funcionar, colocar ele em produção e não que está com algum defeito.
Se vários programadores, inclusive eu, começar a usá-lo com certeza vai virar uma ferramenta funcional logo logo em nossos sistemas.
Pelo menos para mim a cada comando novo e ferramenta nova descoberta do mundo harbour incentiva mais ainda a continuar no mundo harbour.
Seria um avanço enorme começarmos a trabalhar diretamente com funções nativas do harbour mesmo para o gerenciamento das nfe.
O Problema é tempo né...

Rubens

[depaula.jau]

Olá, José Quintas

Será que você pode me responder uma questão, quanto ao uso de suas rotinas "sefazclass-master.zip", as questões são:

Em meu sistema eu crio o arquivo xml como se estivesse criando um arquivo txt mais ou menos assim:

oXml :='<?xml version="1.0" encoding="UTF-8" standalone="no" ?>'
oXml +='<nfeProc versao="3.10" xmlns="http://www.portalfiscal.inf.br/nfe">'
oXml +='<NFe xmlns="http://www.portalfiscal.inf.br/nfe">'
oXml +='<infNFe Id="'+cId+'" versao="3.10">'

oXml +='<ide>' // Inicio da TAG (ide)
oXml +='<cUF>'+Left(CepToIBGE(Limpa_Campo(mCep)),2)+'</cUF>' // UF do Destinatário
...e por ai vai

Após eu uso o Acbr para Assinar, Validar, e Enviar o que é bem simples, pois passo via parâmetro o arquivo xml que eu crie para as funções que vc deve conhecer.

Gostaria de saber se posso fazer isso com suas rotinas compartilhada ? Nem preciso de impressões e PDFs .. pois isso eu sei e posso criar, seria mais esses processos mesmo.

Atualmente estou usando o AcbrMonitorPlus para isso, ele é muito bom mas esta carregado com outros implementos alem do que nem sempre me trás o retorno causando um transtorno na hora de ler o arquivo SAINFE.TXT.

Acho que terei mais segurando lendo o Soap diretamente.

Por hora José, muito Obrigado!

Abraços

[JoséQuintas]

Só pesquisar pelo nome mais adequado ao que está querendo, que seria este:

Código: Selecionar todos

oSefaz := SefazClass():New()
cRetorno := oSefaz:NfeLoteEnvia( cXml, cLote, cUf, cCertificado, cAmbiente )

Enviou o XML, recebeu a resposta.
Dependendo da resposta, é salvar a NFE autorizada.

Não conheço o ACBR.

[depaula.jau]

José!

Então seria Essa a sequencia:

1 - Criar arquivo XML
Retorno Ok

2 - AssinaXml( @cXml, cCertificado )
Retorno OK

3 - NFeGeraAutorizado( cXmlAssinado, cXmlProtocolo )
Retorno OK

4 - NFeLoteEnvia( cXml, cLote, cUF, cCertificado, cAmbiente )
Retorno OK (cStat = 107)

[JoséQuintas]

Primeiro esqueça um pouco o vício do ACBR, em considerar tudo arquivo.

A função NfeLoteEnvia() vai receber uma string, assinar essa string, transmitir essa string, e receber uma string de retorno.

Não existe arquivo temporário de tipo nenhum, não existe pasta de envio/retorno, etc. NADA, porque não existe arquivo.

Esse é o padrão da Fazenda, usado por qualquer aplicativo.

O ACBR usa arquivos, porque é a forma que encontraram do seu aplicativo conversar com o ACBR.

Lógico:
A nota fiscal autorizada é composta do XML enviado + XML de protocolo recebido.
Com certeza podem ocorrer falhas de envio/retorno/XML mau formado, etc.
Por esse motivo, convém gravar essas strings em arquivo, pra eventual conferência/acompanhamento/etc.

É só gravar, igual grava qualquer arquivo.

Código: Selecionar todos

hb_MeMoWrit( "arquivo.xml", cTexto )

ou no xHarbour

Código: Selecionar todos

MemoWrit( "arquivo.xml", cTexto, .T. )

Lembrando que o MemoWrit() compatível com o Clipper salva com control-Z no final, e isso não é válido, por isso as opções acima.

[JoséQuintas]

Não reparei antes, estamos no tópico Clipper....

Se o aplicativo é Clipper, cai na necessidade de arquivos pra comunicação, e acaba voltando a algo parecido com ACBR.
Acaba perdendo toda vantagem que teria sobre o ACBR.

[depaula.jau]

Não! Desculpe não haver mencionado antes (Minigui Extend + Harbour + Mysql)

Ontem a noite analisando com calma e esquecendo o Acbr, as coisas ficaram claras ... já comecei a visualizar o processo

Muito obrigado.

PS: Você dará sequencia nesse projeto quando houver mudanças de versão (3.10) exemplo, porque notei que quando isso acontece , troca-se endereços de serviços

PS2: Estava testando sua classe de STATUS : cXmlRetorno := oSefaz:NfeStatus('SP','6AF73517F897C36A747D9E9583818A29', '1')

O Retorno é : "ERRO: na comunicação SOAP"

DLLs copiadas e registradas observando se Windows32 ou 64.

Você teria alguma dica para que eu possa verificar ?

Abraços;

Marcelo de Paula