PC Toledo

Olá Marcelo,

MSDN escreveu:o projeto da NFC-e foi criado para funcionar 100% sem o SAT

Depende do estado. Em SP você pode até emitir NFC-e, mas é obrigatório ter um SAT vinculado para o CNPJ emitente para o caso de contingência. Assim, aqui trabalhar com NFC-e não tem nenhum sentido, se trabalha direto com o SAT.

MSDN escreveu:ele [SAT] é uma maneira de pura e simplesmente arrecadar e não deixar na mão as empresas que vendiam e lacravam as ECFs ou realmente é algo útil ?

No início eu fazia coro com essa ideia (de lucro aos fabricantes), mas depois a medida que ele foi sendo implantado nos clientes, realmente foi uma boa sacada. É rápido, pode ser compartilhado por vários caixas e não depende do bom humor de internet. Na minha opinião é muito útil.

Jairo,

Com relação ao SAT, o que vc afirmou é isso mesmo, o SAT é muito útil, até pq uma operação de NFC-e na maior cidade do Brasil, contando que toda a infra funcione 100%, é praticamente um milagre, infelizmente.
Nesse link informações sobre o SAT, para quem como eu, ainda tinha algumas dúvidas :
https://portal.fazenda.sp.gov.br/servic ... Sobre.aspx
Como diria o Jack, vamos por parte, primeiro NFC-e OK, depois SAT, como pretendo vender meu software em todo país, o caminho é esse.

Abraços

Conforme estabelecido pela NT 2016.002 versão 1.31, o ambiente de produção da NF-e 4.0 começará a vigorar hoje, no dia 6 de novembro de 2017 , permitindo a emissão e autorização de XMLs no novo layout.

Neste site pode-se encontrar muita informação sobre códigos de erro/rejeição, e tantas outras dúvidas que aparecem no desenvolvimento, quando estamos enviando em ambiente de homologação as notas :
https://www.oobj.com.br/bc/category/leg ... /nfc-e/65/
Carreguei no GIT um arquivo zipado contendo 9 arquivos PNG que mostram como era o XML na versão 3.10 e como ficou para a versão 4.0, retirei a informação do site da empresa TecnoSpeed http://tsdn.tecnospeed.com.br/
endereço com as imagens : https://github.com/hbnfce/home/blob/mas ... ra_400.rar
Logo espero estar postando os fontes (PRG) com a montagem do XML e na sequência com a classe do Quintas.
Lembrando que tudo o que estou fazendo já é para a versão 4.0, pois não vale a pena gastar tempo na 3.10.

Abraços

O projeto hbnfe parou na nota 2.00, e no CTE 1.04, e depois foram fazendo por fora.
A intenção dele era ser compatível com ACBR, funcionando igual.
O problema é que ficar criando arquivos e pastas requer muito mais fonte e complicação, porque cada um vai fazer de um jeito, ou até nem mesmo usar arquivo.
Ia dar muito trabalho continuar mantendo compatível com ACBR, e cada usuário ia acabar tendo fontes diferentes pra criar rotinas próprias pra essa parte.

Toda comunicação com a Fazenda eu já tinha feito aqui, só faltava a assinatura digital.
A hbnfe me mostrou o "mistério" de como assinar o XML.

Depois contribuíram com PDF de nota, CTE e MDFE, e por último de NFCe.
Esta parte veio baseada na hbnfe.

Como dá pra ver pelo sefazclass.ch, o projeto em si é simples, o que complica é que não existe um padrão.
Prometeram padronizar com a NFE 4.0, mas infelizmente não padronizaram do jeito que prometeram.

A NFCE, de um modo geral, usa a mesma coisa da NFE, mesmos webservices.
Um usuário do nordeste queria testar a NFCE, e acrescentei NFCE.
Ele passou a usar oficialmente há algum tempo.

O modo de funcionamento é o mesmo desde quando começou tudo.
O que acontece é justamente as diferenças entre uma UF e outra, que procurei colocar nos arrays que estão em sefazclass.ch
Se precisar de ajuste, de um modo geral é acrescentar/modificar o conteúdo dos arrays.

E algum detalhe a mais quando modifica de versão 3.10 pra 4.00 por exemplo.

Aliás...
Não sei se NFE e NFCE vão continuar andando juntas, porque depende das UFs trocarem de 3.10 pra 4.00, enão sei se vão trocar tudo de uma vez.
Por isso deixando pra depois, porque vai chegar um momento em que todas as UFs vão estar prontas pra 4.00, e não vai precisar controle extra pra isso.

Tem essa também.... rs

Aproveitando....

Talvez a alteração maior não seja no XML, mas sim no aplicativo, pra ter as informações necessárias...

Pois é Quintas, é tanta coisa que a gente fica perdido, e foi justamente isso, estar "perdido" que me fez criar esse tópico e o espaço no GIT, sei que sou o enésimo a fazer algo parecido, mas lembrando de tudo o que vc já fez, e que falou agora, uma coisa fica clara, um depende do outro quando o assunto é crescer e evoluir, cada um tem os seus sistemas e tem coisas que não deixa público, por motivos óbvios claro, mas essa questão fiscal, que a cada dia vem se tornando uma realidade gigantesca na vida de nós programadores, pode deixar de ser um problema e virar uma solução, e digo isso pq foi justamente esse pensamento que me levou a fazer (quase terminando...) um sistema para restaurantes, bares, pizzarias, etc, ao invés de fazer outro que não tivesse a parte fiscal envolvida, pois o governo, da forma irreversível como está implementando exigências fiscais em formato digital, acabou criando uma forma de nós programadores fidelizarmos clientes, tanto cobrando mensalidade, como consultoria, pois no caso da NFC-e, quando vc vende um sistema, o mesmo é cadastrado na receita junto ao seu cliente, criando um vínculo.
Eu tenho certeza que dominar essa parte fiscal, é o melhor caminho para nós, programadores xBase, continuarmos no mercado, até mesmo pq tudo isso nos força a estudar, aprender coisas novas, eu mesmo evolui muito em pouco tempo, desde que me foquei na NFC-e.
A questão das obrigatoriedades fiscais, criou e está criando um mercado novo, onde várias empresas oferecem diversos tipos de serviço interligados, como backup de XML, consultoria contábil e jurídica, componentes para integração entre softwares, e por ai vai.
Por enquanto meu propósito é fazer o feijão com arroz, e compartilhar com todos, mas depois que estiver funcionando perfeitamente, o próximo passo é fazer o que o Quintas já mencionou, evoluir, pois como ele mesmo já disse, e eu, estudando confirmei, a coisa toda é bem simples, os detalhes é que complicam, mas tenho certeza que com muitas cabeças pensando, chegaremos a um nível invejável em relação as exigências fiscais (NF-e, NFC-e, CT-e, MDF-e, NFS-e, etc).
Fugindo um pouco do assunto, como estou fazendo um sistema para atendimento ao público, uma exigência desse segmento é o atendimento mobile, com tablets ou smartphones, e tão logo eu finalize meu sistema, partirei para esse desenvolvimento, e gostaria de sugerir ao Toledo a criação de uma seção no fórum voltada especificamente para MOBILE, creio que muita gente iria ter assunto pra trocar ideias.

Abraços

Ontem iniciei a criação do módulo NFC-e usando a classe do Quintas, e ocorreu o seguinte erro :
" Erro Assinatura : Template de assinatura não encontrado "
O fonte usado é esse : Vou tentando aqui identificar o erro, se alguém já passou por isso, favor informar.

Abraços

Deve ser a velha diferença entre Harbour/Xarbour.

A diferença é que no Harbour FUNCIONA.

No XHarbour, precisa descobrir o que o Harbour ou as LIBs inventaram, que varia conforme a LIB.

Aqui tem até uma coisa esquisita:

A rotina que está na SefazClass funciona, desde que não altere de OleAutoX() pra outro nome.

De forma simples e direta: não sei quer M**** a compilação com XHarbour faz.
Se funciona com um nome, deveria funcionar ao alterar o nome.
XHarbour, minigui, fivewin.... o comportamento não é igual no Harbour que sempre funciona do mesmo jeito.
Lógico... isso quando não se usa a lib de compatibilidade XHarbour que as LIBs SEMPRE USAM, e outras alterações das LIBs.

Solução pra tudo isso:

TODO MUNDO USAR HBMK2 SEJA HARBOUR OU XHARBOUR, OU SEJA QUALQUER LIB.

Porque?

Porque todo mundo vai compilar igual, e vai ter o mesmo resultado.
Se cada LIB altera a ordem de compilação do jeito que quiser, o resultado não vai ser o mesmo.
E isso se não considerar que pode ser problema do velho BCC.

Como saber?
Não faço a menor idéia.
Uso Harbour 3.4, somente fontes do Harbour 3.4, gero o Harbour e uso.
SE ALGUM DIA eu usar alguma lib gráfica, vou continuar usando do jeito Harbour, não do jeito inventado pela LIB.

LIBs e Harbour:
Se as LIBs soubessem usar Harbour, usariam HBP e não arquivos BATs, então significa que elas NÃO sabem trabalhar com Harbour.
Agora XHarbour.... não adianta inventar formas de compilar, é usar o HBMK2 do Harbour que está pronto, ou criar um próprio que funcione.

Lembrando:
Harbour e XHarbour começaram juntos, a compilação dos dois é igual.
A única coisa que mudou foi a forma de organizar as LIBs, e também que as LIBs não tiveram mais atualizações.
Só olhar a GTWVG do XHarbour, ela tá pelada.... começou igual ao Harbour e parou no tempo, não tem nada de GUI.
E TODA GUI da GTWVG poderia ser usada pra minigui e outras, com melhor resultado do que é agora.

Pelo que vc disse já meu deu uma pista, apesar que uso somente Harbour, na versão 3.2 que acompanha a distribuição da MiniGUI Extended.
Vou fazer testes, logo reporto aqui os resultados.
Obrigado Quintas.

Retirei do HBP o arquivo xhb.hbc, e de cara já está aparecendo o que Quintas falou.
Ainda não testei sem pra ver se dá certo mesmo, mas a princípio, tem tudo para estar aqui o erro.
A gente vai criando hábitos (ruins as vezes), e vai deixando chamadas a arquivos dentro HBP e códigos no fonte, que por muitas vezes mais atrapalham do que ajudam.
Vamos em frente...

Aproveitando....

No Harbour 3.4 já está indicado que deve ser removída a XHB.HBC.

Segundo o Viktor: essa XHB foi uma péssima idéia... inclusive dele mesmo....

Como no meu sistema estava dando uns erros, resolvi fazer a rotina em separado, e continua com o mesmo erro.
" Erro Assinatura : Template de assinatura não encontrado "
Para criar o teste, usei :

1- Harbour 3.2 baixado de https://github.com/harbour/core que já vem com a pasta contrib e o mingw (baixei os binários)
2- Não utilizei nenhuma lib gráfica, texto puro

Alguém tem mais alguma sugestão ?

OBS : Estou usando Windows 10 64 bits, e na pasta c:\windows\syswow64\ estão os arquivos capicom.dll e msxml5.dll devidamente registrados, além claro de estar com um certificado A1 instalado na máquina, inclusive a classe reconhece o certificado e pega o nome.

Se é Harbour 3.2.... se capicom e msxml5 estão na pasta syswow64 e devidamente registrados pelo regsvr32 dentro da pasta syswow64, então faça um teste rodando o programa em modo compatibilidade XP.

Uma coisa que o Viktor mencionou, mas não deram atenção, é que o Harbour 3.2 NÃO É COMPATÍVEL COM WINDOWS 10, não basta alterar o manifest.
Isso se estiver usando em Harbour 32 bits... syswow64 é para os programas em 32 bits....

Se registrou errado, primeiro é des-registrar do lugar errado, e depois registrar no lugar certo.

Só lembrando: tem duas versões de regsvr32 dentro do Windows 64 bits: uma dentro de system32 que é a default, e outra dentro de syswow64 que é pra ficar visível em programas 32 bits.

Cada hora que passa fica mais tenebroso....rssss
Essa que vc falou agora de que Harbour 3.2 não é compatível com Windows 10, é de f.....
Tomara que isso não proceda, até pq eu sempre usei o Harbour 3.2 e sempre funcionou no Windows 10 32 e 64, menos a questão da nfce, claro !
Com relação as DLLs, tirei e registrei novamente, capicom.dll e msxml5.dll, que vc fornece junto com a classe, abri o PowerShell do Windows 10, fui em c:\windows\syswow64 e digitei no prompt :
regsvr32 c:\windows\syswow64\capicom.dll
regsvr32 c:\windows\syswow64\msxml5.dll
e nada, continua o mesmo erro !
lembrando que estou fazendo os testes em separado, sem nenhuma lib gráfica, só Harbour 3.2 puro e MingW.
Continuo na luta, mas é o tipo de erro que não é fácil identificar o motivo, vendo nos fontes da classe fica fácil chegar a essa conclusão !