Cleber Ferreira

as instruções passadas por este tópico embaixo parecem ser mais contundentes. Pra complicar, já recebi relatos de que outra ECF desse mesmo cliente está dando esse mesmo erro. E essa outra ECF é uma Daruma.

Tentei olhar agora, mas já te adianto que os links estão abrindo a mesma página

Bom dia Regys, eu diminui o buffer da serial virtual e infelizmente não obtive sucesso. Depois que alterei os buffers (17:30 da tarde) 2 cupons tiveram o mesmo problema até o fechamento do caixa (20:40 da noite). E isso ta complicado pois, por causa desse erro o evento OnDepoisFechaCupom não está sendo executado e com isso os totais atualizados do cupom fiscal não estão sendo atualizados no banco de dados. É no evento OnDepoisFechaCupom que faço essa ultima atualização no banco de dados. PS: eu encontrei a dica de diminuição dos buffers em outro tópico com o mesmo assunto, porém a busca do fórum está retornando tópicos sem nada a ver com o tema. Pra vocês terem uma ideia, consegui achar o tópico pelo doctor Google.

Boa tarde! Será que alguém poderia esclarecer pra mim que erro é esse que a ecf retorna? Ta acontecendo com uma certa frequencia e ainda não consegui localizar a causa. Isolei uma parte do log onde o erro para análise: -- 16:34:14:919 FechaCupom( MD-5:C48E973617DAA1C03B736537302A20F6[CR][LF]MINAS LEGAL: 65213886000105 23072015 390[CR][LF]Trib aprox R$:0,48 Federal e 0,81 Estadual[CR][LF]Fonte:IBPT[LF]Vendedor: CLEIDE Operador: CLEIDE ) TX -> [STX][177][NUL][FS]"MD-5:C48E973617DAA1C03B736537302A20F6[CR][LF]MINAS LEGAL: 65213886000105 23072015 390[CR][LF]Trib aprox R$:0,48 Federal e 0,81 Estadual[CR][LF]Fonte:IBPT[LF]Vendedor: CLEIDE Operador: CLEIDE[LF][186], 16:34:15:262 RX <- ACK = 6 Falha: 0 16:34:15:262 VerificaFimImpressao: Pedindo o Status (19) 16:34:15:574 VerificaFimImpressao: ACK = 6, OK... Aguardando ST1 e ST2 16:34:15:949 VerificaFimImpressao: ACK = 6 - Falhas = 0 - Erro: ESynaSerError Communication error 9997: Timeout during operation 16:34:16:151 VerificaFimImpressao: Pedindo o Status (19) 16:34:16:588 VerificaFimImpressao: ACK = 0 - Falhas = 0 - Erro: ESynaSerError Communication error 9997: Timeout during operation 16:34:16:791 VerificaFimImpressao: Pedindo o Status (19) 16:34:16:916 VerificaFimImpressao: ACK = 0 - Falhas = 0 - Erro: EACBrECFErro ACK <> 6 16:34:17:119 VerificaFimImpressao: Pedindo o Status (19) 16:34:17:243 VerificaFimImpressao: ACK = 0 - Falhas = 0 - Erro: EACBrECFErro ACK <> 6 16:34:17:446 VerificaFimImpressao: Pedindo o Status (19) 16:34:17:602 VerificaFimImpressao: ACK = 0 - Falhas = 0 - Erro: EACBrECFErro ACK <> 6 16:34:17:805 VerificaFimImpressao: Pedindo o Status (19) 16:34:18:242 VerificaFimImpressao: ACK = 0 - Falhas = 0 - Erro: ESynaSerError Communication error 9997: Timeout during operation 16:34:18:445 VerificaFimImpressao: Pedindo o Status (19) 16:34:18:569 VerificaFimImpressao: ACK = 6, OK... Aguardando ST1 e ST2 16:34:18:679 RX <- [NUL][NUL][NUL][NUL] -- 16:34:18:679 GrandeTotal TX -> [STX][ENQ][NUL][FS]#[ETX]B[NUL] 16:34:18:803 RX <- ACK = 0 Falha: 0 TX -> [STX][ENQ][NUL][FS]#[ETX]B[NUL] 16:34:19:037 RX <- ACK = 0 Falha: 1 TX -> [STX][ENQ][NUL][FS]#[ETX]B[NUL] 16:34:19:271 RX <- ACK = 0 Falha: 2 16:34:19:271 RX <- ----------------- ERRO ----------------- Impressora Bematech não responde (ACK = 0) ---------------------------------------- O ambiente é o seguinte: -Windows 7 x64 - ECF Bematech MP4000 - Comunicação USB com instalação do emulador de portas da bematech x64

link do trunk: https://drive.google.com/file/d/0B0gye_CxbqUIdUlJY0QyNWFoRDQ/view?usp=sharing já falei logo acima amigo

Segue link do trunk2: https://drive.google.com/file/d/0B0gye_CxbqUIZlpoa1NkdHhTUmc/view?usp=sharing

Eu sempre guardo uma copia intacta dos fontes aqui comigo caso ocorra essas eventualidades. Creio que todos podem agir também dessa forma. Vou tentar disponibilizar agora no google drive e compartilhar o link o trunk data de 13/07/2015 e o trunk2 é de 14/07/2015 daqui a pouco posto os links

A que temos é FBIII. pode ser esse o motivo então

Temos uma ECF da Epson aqui no escritório e é muito boa. Uma das melhores de se trabalhar na minha opiniao. Aqui leva em torno de 3 a 4 segundos pra retornar os dados da redução e gravar na base de dados. Só demora um pouco durante a impressão do qrcode, mas isso é irrelevante.

Só citei isso Ítalo pois muitas vezes aqui no fórum li até mesmo dos administradores não incentivando certos tipos de práticas, pensando justamente na dor de cabeça que pode dar lá na frente. Mas isso é escolha de cada um. Se todo mundo seguisse a Lei em suas entrelinhas, o Brasil não seria Brasil.

Era esperado isso mesmo. No papel você não pode ser software house pois MEI não abrange esse CNAE. Você vai ter que encontrar uma alternativa pra isso.

Já tentou conversar diretamente com a SEFAZ de SP? O que eles disseram a respeito?

Me perguntei isso agora também. Outro dia estava fazendo um curso EaD do SEBRAE sobre MEI e dei uma olhada na lista de atividades e não tem desenvolvimento de software lá. O que vi foi atividades referentes a manutenção.

Ja foi falado isso aqui no forum diversas vezes. É ilegal fazer esse tipo de operação, estando o contribuinte sujeito a penalidades. O que a legislação da NF-e diz é que TODO xml deve ser enviado ao destinatário (cliente) para que seja escriturado por ele. Vale a dica aí, cuidado. Só complementando que informações baixadas de sites ou afins não são consideradas válidas. Sendo assim, valem apenas os xml assinados digitalmente pelo emissor e enviados ao cliente.

Bom dia! Destaca-se que empresas do simples nacional não fazem esse tipo de calculo, ou pelo menos, 99,99999% delas. Quando há a redução usa-se cst20 (indicado para a situação que voce esplanou), 70 (quando tiver ST no meio) ou o 90 (casos esporádicos). Não mais, o seu calculo na minha opinião, está correto. Basta agora abastecer as tags correspondentes na geração do xml.

Boa noite! Em alguns Estados é permitido apenas que vc lance a nf serie D no sistema PED, sendo dispensado a emissão da mesma na ECF. Outros estados (MG por exemplo) exigem que, quando a ecf voltar a funcionar, emita o cupom fiscal referente à NF e armazene esses dados. Até aí tudo bem. Quanto a sua dúvida sobre duplicação do imposto, é bem chata essa questão. Na legislação do SPED, especificamente no bloco C350 diz o seguinte: "Este registro deve ser apresentado pelos contribuintes que utilizam notas fiscais de venda ao consumidor, não emitidas por ECF...". Já na legislação do Sintegra, o item 17.1.1 diz o seguinte: "17.1.1 - Registro composto apenas pelos emitentes dos documentos fiscais em questão, quando não emitidos por equipamento Emissor de Cupom Fiscal;" Com isso dá-se a entender que NF's transformadas em cupom fiscal em momento posterior não devem ser declaradas nesses blocos. Contudo, há de se levar em consideração que cada homologador pode interpretar de forma diferente essa questão. Alguns pedem para utilizar CFOP específico, outros pedem para não declarar mesmo. Recomendo apresentar isso a ele e ver o que tem a dizer e, claro, consultar também um contador. Várias opiniões são bem-vindas. Espero que tenha te ajudado.

No site da propria SEFAZ na parte de ECF tem toda a explicação sobre tais mudanças e ainda um passo a passo de como realizar o devido cadastro. Não tem como não entender depois dar uma boa lida lá

Dei uma verificada e já está configurado para 3.

E se eu digitar a mesma tag manualmente, o ACBrTEFD substitui caso ele já tenha escrito no arquivo essa mesma tag?

Pelo que sei, não há validade.

O componente ao imprimir o comprovante ele verifica somente as linhas 029-xxx? Pergunto isso, pois vou preferir não imprimir diferenciados e nem reduzidos. Aí o homologador nesse caso disse que verifica somente os campos 029-xxx.

Não seria o caso de se criar uma propriedade "SuportaComprovanteReduzido" e "SuportaViaExclusiva" no componente? Lembrando que se essas opções estiverem habilitadas/desabilitadas, o componente teria que tratar qual tipo de comprovante seria impresso.

No manual diz o seguinte: Para que o Pay&Go possa formatar adequadamente os comprovantes para a Automação Comercial, esta deve informar no campo 706-000: - Se é apta a imprimir as vias diferenciadas (ao invés de duplicar a via única); - Se é apta a imprimir o cupom reduzido. Mais pra frente no manual, localizei essas informações de preenchimento do campo 706-000: Soma dos seguintes valores, identificando as funcionalidades suportadas pela Automação Comercial: 1: funcionalidade de troco (ver campo 708-000) 2: funcionalidade de desconto (ver campo 709-000) 4: valor fixo, sempre incluir 8: vias diferenciadas do comprovante para Cliente/Estabelecimento (campos 712-000 a 715-000) 16: cupom reduzido (campos 710-000 e 711-000) Caso este campo não seja informado pela Automação Comercial (versões anteriores), considera-se que nenhuma das funcionalidades é suportada. Importante: na certificação da CIELO, é exigido que a Automação Comercial implemente a funcionalidade de desconto.

Nesse caso Daniel, o que pode ser feito? Você tem alguma dica?

Bom dia! Em conversa hoje pela manha com o homologador da NTK, foi me dado uma orientação sobre a impressão da via reduzida. Ele me disse que a via reduzida só deve ser impressa nas observações do cupom. Tudo bem, ele está certo nesse ponto. Até pensei em imprimir a via reduzida no final do cupom, mas como existem outras informações a serem impressas (md5, minas legal, impostos, etc, etc...), vi que não era viável, sendo assim, optei por imprimir somente o CCD em 2 vias. Perante isso, busquei aqui no componente ACBrTEFD alguma propriedade (no object inspector) onde eu possa tratar para desabilitar a impressão de via reduzida, porém não encontrei. Alguém sabe se há uma maneira de contornar isso? Vai até uma dica: seria interessante adicionar uma propriedade para tratar essa questão no componente? Grato pela atenção...