Alexsander

Linha 709: procedure TACBrECFBematech.Desativar; begin if fsEnviaPorDLL and Ativo then try FechaPortaSerialDLL(False); // <----- CAUSA ERRO NO LINUX except {Exceção muda pois Porta pode já estar fechada} end ; inherited Desativar ; end; Ambiente: FPC 2.6.0 release + Lazarus release 1.0.2 + ACBr do SVN

Em ACBrSerial.

+1

Com o Lazarus, cujo link o Daniel passou acima, é FREE.

Aqui o trecho que tranquiliza os que estavam preocupados com a possível demora do processo:

Aqui também estou orientando pra fazer downgrade.

Fizemos alguns testes, sem expandir o logo fechamos em 400 x 400 (ou 200 x 200) com RAVE e 260 x 200 com RAVECB. Com o logo expandido, no RAVECB (não testamos no RAVE) definimos o melhor tamanho em 678 x 228 (dobro de 339 x 114).

As duas deviam avisar em seus sites sobre esta situação: http://www.atipinformatica.com.br http://www.elpro.com.br

Atualizei hoje o SVN e deu erro, no Linux (Lazarus), no seguinte arquivo: Fontes/ACBrComum/ACBrConsts.pas Falta um {$IFDEF Windows} no uses para excluir a unit Windows no Linux.

Pois é, quem é o verdadeiro dono? Tem vários fontes perambulando pela Internet, onde estão os autores?

Parece que a exigência mínima será um XML resumo a cada 12 horas, sendo este prazo definido por UF. Sendo assim, o comerciante poderá operar offline nos caixas, com um programa em retaguarda enviando os resumos e os XML em lotes grandes. Na pior das hipóteses o envio poderá ser feito de madrugada.

Uso o NFeMonitor. Até hoje não achei uma informação definitiva sobre o tamanho do logotipo na DANFE, tanto no modo "expandir logo" quanto no modo normal. Tenho visto números como 200 x 200, 106 x 94, 339 x 114... alguém sabe ao certo? Eu procuro algo assim: logo reduzido = A x B, logo expandido = C x D.

Pelo que tenho lido haverá um modo off-line que permitirá o envio com atraso, tornando o tempo no mínimo igual ao do ECF. Se você optar pela DANFE ecológica, que omite os itens, o tempo será MENOR que o do ECF.

Considerando que um dos modos de contingência da NFC-e prevê o envio dos XML a posteriori, desde que se envie um RESUMO a cada 12 horas, e considerando que há uma DANFE Ecológica que tem apenas o QR Code com os totais (não importa quantos itens), acho que vai ficar até melhor.

Mais uma oportunidade para a NFC-e...

Outra dica: usar números aleatórios na tag cNF, conforme sugere o manual. Assim, se por algum motivo gerar novamente o XML, pelo menos não sobrescreve.

Se a impressão for via ACBrETQ, posso ajudar neste componente. No Lazarus existe o http://wiki.lazarus.freepascal.org/LazBarcodes

Alguns registros são 100% idênticos entre os dois SPED; outros são quase iguais. Num post anterior eu dei o exemplo do registro 0200: a diferença é UM campo. Poderia haver uma classe com os campos básicos e outra com os campos extras, assim não haveria duplicação de código. Se no futuro criarem mais campos novos, bastaria acrescentar nas classes derivadas. A resposta do EMBarbosa foi: Eu dei a sugestão, apenas isso. Se ela é ruim, ou se é boa mas não há horas-homem para fazer, tudo bem, a decisão é dos mantenedores. Sei como funciona software livre, sei que tem pouca gente ajudando neste componente em especial, mas também sei que cada um ajuda no que usa. Já mandei contribuições tanto para o ACBr quanto para o Lazarus, mas não fico ofendido se alguém reclamar da TACBrETQ ou da TStringGrid... De qualquer forma eu precisava de algo que pudesse ser rodado via linha de comando (SSH para um servidor Linux), então fiz a minha procedure. Também não preciso de TODOS os registros, então só fiz o que precisava, quando tiver um cliente que venda armas de fogo ou preste serviço de energia elétrica, completo a implementação. Um abraço a todos e mais uma vez parabéns!

Leia meus posts anteriores, eu disse que fiz uma Stored Procedure para gerar o TXT, não uma VIEW. Pra minha necessidade, que inclui poder rodar a dita procedure num console via SSH, ficou melhor assim. Cuidado com a soberba, não ofenda os outros sem pesquisar antes [1]. Saber aceitar críticas e sugestões é uma virtude importante. Tem contribuições minhas no ACBr, eu continuo usando-o, apenas optei por não usar no SPED. Acho um excelente projeto e recomendo, estão todos de parabéns. [1] http://www.linkedin.com/in/alexsander

Não entendi. Como um componente para gerar o arquivo SPED poderia ser mais prático e não precisar preencher os campos? Muitas informações são repetidas. Por exemplo, o Bloco C pode ser quase todo preenchido com informações de 4 tabelas (Reduções Z, Tributo da Redução Z, Cupom, Item do Cupom). Se houvesse 4 classes com estas informações, daria pra preencher apenas 4 objetos e gerar quase todo o bloco. Isso sem contar as repetições entre PIS/COFINS e Fiscal mencionadas anteriormente.

O DANFE em Fortes feito pelo Jean já está incorporado? http://jeansistemas.net/acbr_danfe_fortes.zip

Confesso que achei os componentes SPED pouco práticos, pois é preciso preencher os campos um por um, fica uma tarefa repetitiva. Com as VIEWS ficou bem mais fácil, eu busco os dados na VIEW e formato os campos na procedure. CREATE VIEW vw_sped_registro_c420 AS SELECT cod_trib_fk||case when cod_trib_fk <> 'T' then '1' else '' end|| case when aliquota = 0 then '' else to_char(aliquota*100,'FM0000') end as cod_tot_par, valor as vlr_acum_tot, case when cod_trib_fk = 'T' then '1' else '' end as nr_tot, data_proc_fk, cod_empresa_fk, num_pdv_fk FROM cf_reducao_trib WHERE valor > 0; (...) -- REGISTRO C420 FOR reg_C420 IN SELECT * FROM vw_sped_registro_c420 r WHERE cod_empresa_fk = reg_C405.emp AND data_proc_fk = reg_C405.dt_doc AND num_pdv_fk = reg_C405.pdv ORDER BY cod_tot_par LOOP linha := delim||'C420'||delim||reg_C420.cod_tot_par||delim|| to_char(reg_C420.vlr_acum_tot,'FM9999999990D00')||delim|| reg_C420.nr_tot||delim||delim; RETURN NEXT linha; (...)

Do link acima: Vários destes impostos (ex: IPI, II, PIS, COFINS) já estão na NF-e, se a NFC-e já estivesse em vigor seria relativamente simples imprimir na "DANFCE" (DANFE da NFC-e). Nos ECF dará mais trabalho, pois além de haver pouca flexibilidade no que sai impresso, a maioria dos softwares de PDV trabalha apenas com os impostos relevantes ao cupom fiscal.

Na imensa maioria dos países do mundo não há nem webservice nem hardware especializado. Os softwares de sonegação são conhecidos como "zappers", que deletam ou alteram lançamentos (geralmente em dinheiro) nos bancos de dados dos computadores, numa espécie de "Caixa 2". Os governos têm, no entanto, várias formas de detectar fraudes: oscilações no faturamento oficial, discrepância entre compras e vendas, modo de vida acima da renda, etc. E quando querem confirmar, basta o fiscal fotografar o recibo, pagar em dinheiro e depois voltar para auditar o estabelecimento: se o registro interno for diferente do que está na foto, está provada a evasão fiscal. A diferença é que no Brasil se ataca o sintoma, não o problema. Vejam o caso dos celulares nos presídios: ao invés de simplesmente PROIBIR a entrada de celulares, o governo tenta instalar bloqueadores de sinal. Da mesma forma, ao invés de PUNIR os sonegadores, o governo inventa ECF com lacre, memória fiscal, redução Z, etc aumentando os custos para os comerciantes.