JSantos

Galera! Tenho visto vários posts sobre impressão do cupom usando o Fortes. Vejo a princípio as seguintes desvantagens: 1- Impressão em modo gráfico para o cupom inteiro (mesmo os textos são impressos em modo gráfico). A impressão gráfica naturalmente é mais lenta; 2- Dificuldade nos ajustes de dimensão da página, já que se trata de uma impressão em bobina com número de itens variáveis. A vantagem que consigo ver até agora seria na possibilidade de impressão dos códigos de barras mesmo em impressoras que não tenham este recurso nativo (desde que a impressora possua driver para impressão gráfica). Estou na linha de usar o EscPos. Para a impressão de cupons é de longe a alternativa mais indicada, principalmente na questão de velocidade. Falando em velocidade, se for uma impressora serial então nem se fale. Precisamos com o tempo compatibilizar o ACBr com os modelos de impressoras mais usais no mercado. Hoje já tem suporte para Epson, Bematech e Daruma; cobrindo uma boa parcela.

Olá rick, O contribuinte poderá manter em funcionamento sim seus ECFs. Isso só será permitido até que eles completem 5 anos desde a primeira lacração.

SEFAZ SP reconheceu os erros e habilitou a contingência.

Legal João! Vou baixar na sequência. Daniel, você pretende incorporar este ótimo trabalho que o João tem feito no componente? Como pensa em fazer?

Como se trata de impressão direta, acho melhor não usar acentuação. Assim reduzimos a necessidade de configuração adicional da impressora no cliente.

João! Muito bom seu trabalho! Testei aqui com a Daruma DR700 e ficou perfeito! Parabéns! Vamos aguardar o Daniel atualizar o repositório. Só uma pergunta/sugestão: Não seria interessante montar os extratos sem usar acentuação? (para diminuir configurações de página de código, etc. etc. com as impressoras) []s José Santos

Seguindo a sugestão do nosso colega Cristiano Abbud (boa ideia Cristiano!), falei hj com a AFRAC. Conversei com uma pessoa da área de associação e perguntei como estava o posicionamento deles com relação ao SAT e principalmente esta questão dos desenvolvedores autônomos ficarem de fora. Segundo a pessoa, eles ainda não tinham tido nenhuma solicitação do tipo até agora e, depois de falar a ala que estávamos discutindo isto num fórum e que o nome da Afrac havia surgido, pediu-me que encaminhasse um e-mail com esta solicitação para que ela "escalasse" o assunto em sua diretoria. Bom, já vou fazer o meu email e, se mais alguém tiver interesse, pode mandar para [email protected] Penso que se fizermos chegar um bom número de e-mails, ao menos conseguiremos chamar a atenção! Agora vejam só: segundo a pessoa, a Afrac está tentando pleitear junto ao governo estadual, a possibilidade de convívio entre as tecnologias fiscais (ECF e SAT) deixando a cargo do contribuinte a escolha sobre qual tecnologia adotar. Abraço!

Pessoal, Importante surgir esta discussão principalmente porque achei muito quieta a classe de desenvolvedores autônomos frente às novas exigências que estão por vir. Não sei se só por uma passividade ou então por falta de expressão mesmo. Gostaria de consultar os amigos sobre a existência de algum organismo que possa representar os desenvolvedores autônomos, que tenha representatividade e possa pleitear o direito de desenvolvimento do SAT.

Pessoal, Segundo as normas do SAT, somente pessoas jurídicas poderão se credenciar para o desenvolvimento de aplicações. Através do serviço de atendimento da SEFAZ fiz um questionamento e recebi a resposta abaixo: Boa tarde, Caso não concorde com ela, a sua classe pode enviar um ofício para a Secretaria da Fazenda pleiteando modificar essa regra. Agradecemos seu contato no "Fale Conosco" da Secretaria da Fazenda. Sua opinião é muito importante para nós. Por gentileza, clique no link abaixo e opine sobre este e-mail: Pesquisa de Satisfação Atenciosamente, Secretaria da Fazenda do Estado de São Paulo Mensagem Original: Desenvolvedor autônomo pessoa física Sou desenvolvedor de sistemas e automação comercial na qualidade de autônomo. Vi que o projeto SAT não prevê que desenvolvedores de sistemas autônomos possam se credenciar para o desenvolvimento. Vocês pretendem mesmo excluir a nossa classe deste projeto? Gostaria de saber entre nossos colegas, se ainda existem programadores autônomos assim como eu e se nós podemos fazer alguma coisa a respeito? José Santos

Segue posicionamento da Secretaria da Fazenda para o problema encontrado: Resposta da Mensagem 5859970 Prezado contribuinte Já verificamos o erro e devemos atualizar a aplicação o mais breve possível. Nossa recomendação é informar os dados em informações adicionais, enquanto o problema não é resolvido. Agradecemos seu contato no "Fale Conosco" da Secretaria da Fazenda. Sua opinião é muito importante para nós. Por gentileza, clique no link abaixo e opine sobre este e-mail: Pesquisa de Satisfação Atenciosamente, Secretaria da Fazenda do Estado de São Paulo Mensagem Original: Rejeição de NFe Prezados Senhores, Desde 01/06/2013 não estamos conseguindo autorizar NFe de entrada com compra de produtor rural de outro estado. Somente NFe de entrada para produtores rurais do estado de SP estão sendo autorizadas. O erro recebido é: Rejeição: NF Referenciada De Produtor Com IE Inexistente. O mesmo acontece em nosso ERP e no emissor gratuito de NFe. Consultando o cadastro do produtor rural pelo site do SINTEGRA podemos verificar que a inscrição estadual está correta. Antes do dia 01/06, conseguíamos autorizar NFes com estes produtores sem problema. Parece-nos que a SEFAZ SP está checando somente a base de dados de SP e não dos outros estados. Em virtude disso, não estamos conseguindo autorizar tais NFes. NÃO RESPONDA ESTE E-MAIL Para fazer uma nova pergunta, clique aqui.

Boa tarde, Douglas. Infelizmente aqui nenhum progresso. Já entramos em contato com a SEFAZ SP. Estamos pedindo a nossos clientes que registrem o mesmo tipo de reclamação na SEFAZ. Os clientes já estão pensando em não preencher os campos de NF referenciadas e mandar tudo nas informações complementares. Se não tiver solução melhor, eles vão acabar fazendo isto mesmo. Se tiver alguma novidade posto aqui.

Pessoal, Desde o dia 01/06/2013, data das novas implementações na SEFAZ, passamos a enfrentar um novo problema aqui em SP. Tenho alguns clientes que compram produtos de produtores rurais e são obrigados a emitir NF-e de entrada para estas compras. Desde o dia 01/06 a SEFAZ SP começou a rejeitar NFes de entrada para produtores rurais de outro estado, aceitando somente as NFes emitidas nos casos de produtores rurais de SP. Nos casos de rejeição a mensagem tem sido: Rejeição: "NF referenciada de produtor com IE inexistente" Minha pergunta: Será possível que a SEFAZ foi tão ingênua ao ponto de verificar se a IE existe ao não, confrontando-a somente com a base de dados de SP? Veja o trecho um NF-e referencia de um produtor de SP aceita pela SEFAZ SP: <NFref> <refNFP> <cUF>35</cUF> <AAMM>1306</AAMM> <CNPJ>08368374000176</CNPJ> <IE>665059715112</IE> <mod>04</mod> <serie>0</serie> <nNF>369</nNF> </refNFP> </NFref> Veja o trecho um NF-e referencia de um produtor de outra UF rejeitada pela SEFAZ SP: <NFref> <refNFP> <cUF>31</cUF> <AAMM>1305</AAMM> <CPF>74891790687</CPF> <IE>0014435710200</IE> <mod>04</mod> <serie>0</serie> <nNF>121</nNF> </refNFP> </NFref> O mais importante é que a Inscrição Estadual do produtor (cuja NFe foi rejeitada) é válida. Consultando pelo SINTEGRA estão lá todos os dados. Alguém pode dar uma luz? José Santos VMX Technologies

Pessoal, Desculpem-me pelo uso do "Atenção". Na verdade, como estes códigos de status já estão em produção e podem causar uma série de problemas com os diversos sistemas que utilizam o componente, inclusive com consequências legais (não identificar uma NFe cancelada com código 151, por exemplo), julguei urgente a atualização. Mas fiquem tranquilos, pegarei mais leve!!!

Jéter, Se você observar os fontes, verá que existem tratamentos internos do componente. Verifique em ACBrNFeWebServices.pas, por exemplo. Você tem certeza que o componente não precisará tratar estes novos códigos de status e retornos?

Confirme se você está em ambiente de produção ou homologação. Aqui, se estiver em homologação a tarja de cancelada não aparece, mas em produção aparece.

Pessoal do desenvolvimento, Vocês sabem dizer se os Status e retornos de eventos abaixo já estão sendo tratados no ACBrNFe ? 150 - Autorizado o uso da NF-e, autorização concedida fora de prazo. 151 - Cancelamento de NF-e homologado fora de prazo. 155 - Cancelamento homologado fora de prazo. Dando uma olhada nos fontes, não encontrei referência a estes códigos.

Resolvi o problema aqui acrescentando os WSs no arquivo ACBrNFeUtil.pas. Linha acrescentada: LayNFeCCe,LayNFeEvento : Result := DFeUtil.SeSenao(AAmbiente=1, 'https://www.scan.fazenda.gov.br/RecepcaoEvento/RecepcaoEvento.asmx', 'https://hom.nfe.fazenda.gov.br/SCAN/RecepcaoEvento/RecepcaoEvento.asmx'); Seria ótimo o pessoal atualizar no repositório!!!

Bom pelo portal da NFe diz estar disponível. Veja em: http://www.nfe.fazenda.gov.br/portal/webServices.aspx O WS para tratamento de eventos é: https://www.scan.fazenda.gov.br/Recepca ... vento.asmx Mas no ACBr, pelo que pude ver não está implementado. Veja em: ACBrNFeUtil.pas Desenvolvedores, uma ajudinha aí, por favor! rsrsrs

Pessoal, Fazendo uns testes aqui com cancelamento por eventos surgiu um erro na tentativa de cancelamento de uma NFe emitida no ambiente de homologação SCAN. Rastreando, o erro é gerado no arquivo ACBrNFeWebServices.pas na linha: 3501: FEventoRetorno.Free; ERRO: Access violation at address 006A5B9A in module 'ACBrNFeMonitor.exe'. Read of address 0000001C

Seguinte galera, problema resolvido. Instalado driver para eToken Aladdin Certisign para Windows Vista / Seven. Embora eles digam em seu suporte que não possuem drivers para Windows Server 2008 R2, os drivers para para Windows Vista e Seven funcionam. Na ocasião baixei no link abaixo: http://www.downloadcertisign.com.br/sit ... P2-x64.msi Testado com Windows Server 2008 R2 Standard e Foundation. Mensagem de "Erro no suporte a canais seguros" Antes de testar com o driver para Vista/Seven, encontrei algumas alternativas na internet em outros sites que diziam ser compatíveis. Mas sempre me deparava com a mensagem de erro acima. Vi que outros usuários do fórum já encontraram este problema. No meu caso foi resolvido instalando o driver compatível. Obrigado Cleber pela ajuda! Abraço!

Pessoal, Alguém conseguiu colocar em funcionamento um certificado digital A3 eToken pro Aladdin da Certisign no Windows Server 2008 R2. Na página de download da Certisign não há opção de driver para Windows Server. Entrei em contato com a Certisign e eles disseram não dar suporte para o Windows Server (parece brincadeira!). Alguém já possou por isso e tem algum driver ou link para instalação e funcionamento do token? Abraço!

Zottis, Você já baixou a unit e adicionou ao projeto? Qual é exatamente sua dificuldade? Seguindo o exemplo do tópico deve funcionar. Você vai precisar ao menos um arquivo XML de uma NFe e um arquivo XML de uma CCe. Tente montar um exemplo e poste aqui se tiver alguma dificuldade. Abraço!

ArbSis, Da minha parte já está doado. Só fiz este alerta para que os usuários do projeto não fizessem qualquer cobrança de funcionamento com o pessoal do ACBr.

Pessoal, Há pouco mais de um mês, postei no fórum um tópico para discussão de um modelo de impressão para a CCe. viewtopic.php?f=6&t=6253&p=32978&hilit=modelo+CCe Acabei implementando uma solução para impressão da CCe de acordo com o modelo que proposto e, como tenho recebido alguns e-mails de amigos do fórum me perguntando sobre a solução, decidi empacotar a solução em uma classe e disponibilizar aqui para download. O uso da classe em Delphi funciona assim: var CCeImp1: TCCeImp; begin CCeImp1 := TCCeImp.Create(nil); CCeImp1.defineSaida(tps_PDF,'35120650983733000161550010000002171045708017-ProcEventoNFe.pdf'); // tps_PDF ou tps_Print CCeImp1.defineLayOut(fp_Portrait); // implementado impressão retrato CCeImp1.defineXMLNFe('F:\NFE\35120650983733000161550010000002171045708017-nfe.xml'); // XML da NFe corrigida CCeImp1.defineXMLCCe('F:\NFE\35120650983733000161550010000002171045708017-ProcEventoNFe.xml'); // XML da CCe CCeImp1.defineSoftHouse('MinhaSoftwareHouse'); try CCeImp1.Execute; except // Tratamento end; CCeImp1.Free; end; O fonte está aí para download. Assim, aqueles que estão precisando de uma solução e ainda não implementaram, podem contar com esta ajuda. Só lembrando que: 1- Este código fonte não tem vínculo algum com o desenvolvimento do ACBr; 2- Não existe determinação governamental para impressão da CCe e nada impede que amanhã surja alguma em formato totalmente diferente deste proposto aqui. Acredito que se um modelo for determinado em lei, o pessoal do ACBr com certeza implementará a solução. 3- O uso desta solução é por conta e risco de cada um. Bom pessoal é isso. Se alguém achar que ajudou e quiser dar uma contribuição pode me mandar um e-mail. Não vou mentir não, tô precisando! Abraços a todos! VMXCCePrint.pas

Pessoal, verifiquem aí? ACBrNFeMonitor 0.7.1c, atualizado. Fiz algumas consultas de NFe sem incluir os novos schemas de consulta e o ACBrNFeMonitor não retornou nenhum problema. Fez as consultas normalmente. Achei estranho e decidi fazer alguns testes: 1- Retirei da pasta schemas os arquivos: consSitNFe_v2.00.xsd, leiauteConsSitNFe_v2.00.xsd, retConsSitNFe_v2.00.xsd, consSitNFe_v2.01.xsd, leiauteConsSitNFe_v2.01.xsd, retConsSitNFe_v2.01.xsd Resultado: O ACBrNFeMonitor continuou funcionando normalmente para a consulta de situação de NFe. 2- Alterei os arquivos leiauteConsSitNFe_v2.00.xsd e leiauteConsSitNFe_v2.01.xsd de modo que o preenchimento da tag fosse obrigatório com o conteúdo "CONSULTAW" e não "CONSULTAR" Resultado: O ACBrNFeMonitor continuou funcionando normalmente para a consulta de situação de NFe. Pergunta: estes schemas não estão sendo usados pelo ACBrNFe ou está ocorrendo alguma outra coisa??? Teste aí, por favor!!!