Alexsander

Juliomar, a emissão da NF-e já é uma homologação e tanto. Fazer um software que emite NF-e direitinho, manter atualizado com as últimas NT, etc requer um nível de esforço que automaticamente exclui os "pés-de-chinelo".

Sei que isso é coisa pra perguntar pro contador, mas lá vai: teoricamente, se a empresa vender tudo com o mesmo PIS/COFINS (praticamente uma conta sobre o faturamento), as informações nos registros C460 e C470 do SPED Fiscal são suficientes, não?

Obrigado!

Só para constar, testei o Validador (programa em Java) no Windows e funcionou. No meu Ubuntu 12.04 64-bit tive que fazer "downgrade" pois tinha um Java 1.7, instalei um JRE 1.6.0 release 35.

Fiz mais um teste, coloquei registros C100 e C170 fictícios, o validador 2.0.28 pulou os mesmos 56 bytes, caindo no meio da chave da NF-e, mostrando a mesma mensagem de erro.

Só para encerrar, acabei optando por criar uma "stored procedure": SELECT * FROM sp_gera_sped(tipo,cnpj,dataini,datafim,params); Onde tipo é uma das strings: "FISCAL" ou "PIS/COFINS". A procedure usa N views chamadas vw_sped_registro_NNNN que buscam os dados e colocam em colunas com os mesmos nomes dos registros, facilitando o desenvolvimento.

Isso é possível? O arquivo ficou assim (a partir da linha 8364): |0990|8364| |C001|0| |C400|2D|DARUMA|DR0609BR000000195551|12| |C405|28062012|4|597|107740|2172399,83|4912,58| Mas o validador diz o seguinte: Mensagem: Estrutura da linha inválida. Linha: 8365 Campo: "Não se Aplica" Valor calculado: C001 Conteúdo do campo: "Não se Aplica" Registro: "Não se Aplica" Conteúdo do registro: |4|597|107740|2172399,83|4912,58| Vejam que parece que ele "engoliu" alguns caracteres, pois ele não acha o C001, pula a linha do C400 e corta um pedaço da linha do C405. Já conferi num editor hexadecimal, não há bytes espúrios. Não estou informando os registros abaixo de C400, segundo a documentação são opcionais, será que é esse o problema?

Em teoria se o ACBrNFeMonitor imprimir a DANFE simplificada (conforme NT correspondente), dá pra ter uma impressora térmica separada só pra isso. Bastaria emitir a NFe e mandar imprimir a DANFE simplificada.

Vou analisar aqui, talvez acabe criando algo novo.

Mas poderia haver um parâmetro, por exemplo: a chamada "GeraRegistro0200(tpPisCofins)" acrescentaria o campo 12 "ALIQ_ICMS", que é a única diferença entre os dois atualmente. Quando são totalmente diferentes a procedure poderia ser apenas um "wrapper" para as procedures específicas -- que seriam poucas.

Que possa ser usado tanto no Fiscal quanto no Pis/Cofins. Por exemplo, o Fiscal usa um C400 que é idêntico ao C400 do Pis/Cofins, ambos têm um C405 que também é idêntico, mas o Fiscal tem um C410 que não existe no Pis/Cofins. Por outro lado o Pis/Cofins tem os registros C481 até C489 que não estão no Fiscal e os registros C490, C495, etc são diferentes nos dois layouts.

Pelo que vi, vários blocos são idênticos para os 2 tipos de SPED. Há alguma maneira de compartilhar código entre os dois pra não ter que repetir? Como vocês estão fazendo?

Quando sai esta NT 2012/004 ?

O CodeTyphon usa um pacote com nome "pl_synapse", certamente um "freeze" do dia em que eles montaram o pacote. Ou talvez esta versão tenha alguma customização, não cheguei a investigar. De qualquer forma, tanto o ACBr quanto o CT acessam o pacote pelo nome, então surge o conflito porque o FPC acha todas as units duplicadas.

*Meu Deus, eu escrevi "abriu" quando queria dizer abril. Fiquei até envergonhado.

Alguém já instalou o CodeTyphon (pacote com Lazarus + FPC + vários componentes) com ACBr? Para poder instalar o ACBr tive que excluir o Synapse que vem junto com o CT -- que era mais novo que o do ACBr. Isso quebrou vários outros pacotes, no final tive que remover vários componentes -- que até nem uso, mas poderia ao menos experimentar. Eu pergunto: porque o Synapse está dentro do ACBr? Já testaram com uma versão mais recente (ou mesmo do SVN)? Em abriu saiu o release 40: http://www.ararat.cz/synapse/doku.php/download

Obrigado!

Além disso, o ACBr não compila com o FPC 2.7.x do trunk, pois Unix.Shell (deprecated) foi removido: http://wiki.freepascal.org/Executing_Ex ... _and_shell O erro ocorre no arquivo Fontes/ACBrComum/ACBrUtil.pas, linha 1757. A sugestão do Wiki é usar "fpsystem" ao invés de Shell, como já foi feito na unit Synaser.

Segue PATCH gerado com "svn diff ACBrECFBematech.pas". Apenas acrescentei dois {$IFNDEF LINUX} nas chamadas de LoadDLLFunctions e AbrePortaSerialDLL. Não deve funcionar no Linux (que não usa DLL) mas pelo menos compila. PS: Como dá pra ver, o arquivo também não está com encoding UTF-8. Index: ACBrECFBematech.pas =================================================================== --- ACBrECFBematech.pas (revisão 3869) +++ ACBrECFBematech.pas (cópia de trabalho) @@ -3723,7 +3723,9 @@ FileMFD: AnsiString; DataArquivo: TDateTime; begin + {$IFNDEF LINUX} LoadDLLFunctions; + {$ENDIF} NumUsu := AnsiString(UsuarioAtual); @@ -3739,7 +3741,9 @@ // gerar arquivos de um arquivo MFD, ent�o baixamos a MFD para o periodo // e rodamos um loop com a data gerando o arquivo para cada dia dentro // do per�odo + {$IFNDEF LINUX} AbrePortaSerialDLL( fpDevice.Porta, FilePath ) ; + {$ENDIF} // fazer primeiro o download da MFD para o per�odo Resp := xBematech_FI_DownloadMFD( FileMFD, '1', DiaIni, DiaFim, NumUsu ); bematech.txt

Há previsão de entrar no SVN? Montei um ambiente novo, puxei do SVN e veio a versão com erro.

Na verdade nosso ERP tinha um módulo PDV que foi descontinuado em favor da integração com soluções PDV de terceiros. Agora, com o projeto da NF-e ao Consumidor no horizonte, volta a ser interessante ter um módulo PDV que não requeira uma impressora fiscal. Vi que o D-TEF da Direção seria uma opção, mas mandei email pra eles e não tive retorno ainda.

Como foram os testes?

Tenho 3 perguntas: 1) As impressoras ECF imprimem a DANFE reduzida? Sem isso o custo seria alto para os lojistas. 2) Como vai funcionar a venda ao CONSUMIDOR? Não dá pra exigir CPF de todo mundo. 3) Como vender quando cair a Internet? As formas de contigência atuais são insuficientes. Ola amigo estou participando do projeto piloto aqui no amazonas. Respodendo as suas perguntas. 1 - Nâo será preciso ECF pode ser utilizado impressoras terminais nao fiscal ou impressoras laser por exemplo. 2 - Existem os campos de CFP mais o mais o mesmo nao sera obrigatorio. 3 - Sim existe contigencia. abraços Continuando: 1 - Eu sei que não precisa ECF e sei que as impressoras térmicas não-fiscais custam um terço das fiscais. Mas o que os lojistas farão com seu imenso parque instalado de ECF, jogar tudo fora? Haverá resistência por parte dos lojistas se todo mundo tiver que trocar de equipamento. 2 - Há alguma previsão para a NT que introduzirá a não-obrigatoriedade de CPF/CNPJ na NF-e? Como as empresas do projeto-piloto estão procedendo neste meio tempo, usando um CPF fixo definido pela SEFAZ? Quando esta NT sair, qualquer comerciante poderá fazer seu próprio piloto. 3 - Que tipo de contingência? Algum dos existentes (ex: SCAN, que requer internet) ou um tipo novo? Tem que ser algo que possa armazenar localmente a NF-e sem depender de conexão internet, pois a lógica é a mesma do ECF: a SEFAZ não quer dar uma "desculpa" pro lojista vender sem emitir cupom alegando falha de comunicação por culpa de terceiros (empresa de telefonia/banda larga por exemplo).

Arquivo: Fontes/ACBrSerial/ACBrECFBematech.pas Procedure: PafMF_GerarCAT52() Não compila no Linux; acrescentei dois {$IFNDEF LINUX} apenas para compilar. As chamadas que deram erro: LoadDLLFunctions e AbrePortaSerialDLL. Para funcionar no Linux seria preciso mais do que estes IFDEF, evidentemente.

Eu fiz um algoritmo que tenta localizar de várias maneiras (ex: campo "referência" do cadastro) e no final cai nesta alternativa de fazer o mapeamento manual e salvar para as próximas notas.