Olá a todos,
Amigos, a situação é a seguinte:
Por falta de tempo, um colega programador pediu-me para desenvolver um aplicativo para impressão de CUPOM FISCAL na impressora DARUMA. Até aí blz...
O problema é que o meu aplicativo atuará somente no que diz respeito ao CUPOM FISCAL, ou seja, Emissão de Cupom, Cancelamento, Leitura X, Redução Z... etc... etc... e o programa dele fará toda a RETAGUARDA (controle de estoque, vendas, cts a receber... etc... etc...)
Pergunto:
1-) Dá pra funcionar assim, um programa sendo o FRENTE DE CAIXA e outro a RETAGUARDA?
2-) Dessa maneira, não terá problema por parte do fisco?
É urgenteeeee!
Aguardo...
Janio
Aplicativo Fiscal x Retaguarda (Urgente)
Moderador: Moderadores
Aplicativo Fiscal x Retaguarda (Urgente)
fui...
e-mail:janioaguiar@yahoo.com.br
msn: janio_aguiar@hotmail.com
xHarbour1.2.1/Harbour3.2 + wvg + hwgui + Mediator + MySql
e-mail:janioaguiar@yahoo.com.br
msn: janio_aguiar@hotmail.com
xHarbour1.2.1/Harbour3.2 + wvg + hwgui + Mediator + MySql
- rochinha
- Administrador

- Mensagens: 4664
- Registrado em: 18 Ago 2003 20:43
- Localização: São Paulo - Brasil
- Contato:
Amiguinho
E bem simples:
Este e o funcionamento basico de programa de frente de caixa. que fazem todo o trabalho de leitura de estoque e impressao, e o movimento sera visualizado na retaguarda como venda normal.
O fisco nao fara nada relativo a este metodo de trabalho, mas o seu programa de venda no balcao devera fazer todo o trabalho fiscal sozinho levando em consideracao a legislacao do estado em que o seu ECF ira trabalhar.
Suponha que voce fez um modulo de frente de caixa que funcione com varias impressoras e possui funcao TEF e gera os arquivos com dados de vendas e financeiro que pudesse ser manipulado por qualquer outro sistema de retaguarda.
O sistema de retaguarda apenas leria tais informacoes e atualizaria o estoque e financeiro.
O seu PDV daria conta da venda e das impressoras e todo o trabalho fiscal ficaria no PDV, inclusive a responsabilidade.
@bracos :?)
E bem simples:
Este e o funcionamento basico de programa de frente de caixa. que fazem todo o trabalho de leitura de estoque e impressao, e o movimento sera visualizado na retaguarda como venda normal.
O fisco nao fara nada relativo a este metodo de trabalho, mas o seu programa de venda no balcao devera fazer todo o trabalho fiscal sozinho levando em consideracao a legislacao do estado em que o seu ECF ira trabalhar.
Suponha que voce fez um modulo de frente de caixa que funcione com varias impressoras e possui funcao TEF e gera os arquivos com dados de vendas e financeiro que pudesse ser manipulado por qualquer outro sistema de retaguarda.
O sistema de retaguarda apenas leria tais informacoes e atualizaria o estoque e financeiro.
O seu PDV daria conta da venda e das impressoras e todo o trabalho fiscal ficaria no PDV, inclusive a responsabilidade.
@bracos :?)
depende
olha não sei quanto ao seu estado pois no meu SC e com os fiscais que temos por aqui eles não permitem em hipotese alguma que se tenha frete de caixa e retaguarda separados digo:
Se o sistema de frente de caixa for um .exe e o retaguarda for outro .exe o que é normal tudo bem desde que o frente de caixa faz toda a movimentacao de vendas na mesma base "unica" do retarguarda.
Este negocio de importar e exportar para outros sistema eles não permitem de jeito nenhum.
Melhor mesmo é conversar com um fiscal do seu estado, para verificar como eles estão precedendo em campo.
Se o sistema de frente de caixa for um .exe e o retaguarda for outro .exe o que é normal tudo bem desde que o frente de caixa faz toda a movimentacao de vendas na mesma base "unica" do retarguarda.
Este negocio de importar e exportar para outros sistema eles não permitem de jeito nenhum.
Melhor mesmo é conversar com um fiscal do seu estado, para verificar como eles estão precedendo em campo.
-
gransoft
- Usuário Nível 3

- Mensagens: 321
- Registrado em: 06 Jul 2004 17:48
- Localização: UBERLÂNDIA-MG
- Contato:
Frente de Caixa x Retaguarda
ARAGUARI-MG, 22 de junho de 2005.
Prezados Srs,
Via de regra, um Aplicativo Fiscal para ECF, com ou sem o TEF, deverá ser Homologado/Credenciado pelas Secretarias da Fazenda Estaduais.
Ocorre que a cada atualização/alteração do Aplicativo, deverá ser efetuado todo o processo. Isso é desgastante, e com TEF, muito caro.
O viável é planejarmos um Frente de Caixa em executável único, com funções triviais para Pedido/Cupom Fiscal, Relatórios X,Z, Mapa de Memória Fiscal e outros que são exigidos. E também disponibilizarmos o necessário para Consultas ao Estoque antes/após emissão do CF, para que o FISCO possa comprovar "in-loco" a atualização das Mercadorias, Clientes, Tabelas de CT, CST, CFOP e outras.
O executável único e respectivos fontes é para simplificar documentação pelo MD-5, exigida pela SEFAZ-MG.
Item 3 - Autenticação de Arquivos:
http://www.sef.mg.gov.br/servicos/ecf/i ... u_apli.htm
Assim sendo, o Retaguarda, em outro executável, NA MESMA BASE DE DADOS - EVIDENTEMENTE, com seus "trocentos" módulos, relatórios, SINTEGRA, SAPI(MG) e perfumarias, ficaria totalmente LIVRE( * ) para atualizações rotineiras e necessárias a um bom Aplicativo Fiscal PED, devidamente documentado e controlado a nível de "Versões".
( * ) Ou quase...
http://www.sef.mg.gov.br/slt/ricms/anex ... htm#parte2
Atenciosamente,
Janis Peters Grants.
Skype: gransoft
http://www.gransoft.com.br
gransoft@zipmail.com.br
Prezados Srs,
Via de regra, um Aplicativo Fiscal para ECF, com ou sem o TEF, deverá ser Homologado/Credenciado pelas Secretarias da Fazenda Estaduais.
Ocorre que a cada atualização/alteração do Aplicativo, deverá ser efetuado todo o processo. Isso é desgastante, e com TEF, muito caro.
O viável é planejarmos um Frente de Caixa em executável único, com funções triviais para Pedido/Cupom Fiscal, Relatórios X,Z, Mapa de Memória Fiscal e outros que são exigidos. E também disponibilizarmos o necessário para Consultas ao Estoque antes/após emissão do CF, para que o FISCO possa comprovar "in-loco" a atualização das Mercadorias, Clientes, Tabelas de CT, CST, CFOP e outras.
O executável único e respectivos fontes é para simplificar documentação pelo MD-5, exigida pela SEFAZ-MG.
Item 3 - Autenticação de Arquivos:
http://www.sef.mg.gov.br/servicos/ecf/i ... u_apli.htm
Assim sendo, o Retaguarda, em outro executável, NA MESMA BASE DE DADOS - EVIDENTEMENTE, com seus "trocentos" módulos, relatórios, SINTEGRA, SAPI(MG) e perfumarias, ficaria totalmente LIVRE( * ) para atualizações rotineiras e necessárias a um bom Aplicativo Fiscal PED, devidamente documentado e controlado a nível de "Versões".
( * ) Ou quase...
http://www.sef.mg.gov.br/slt/ricms/anex ... htm#parte2
Atenciosamente,
Janis Peters Grants.
Skype: gransoft
http://www.gransoft.com.br
gransoft@zipmail.com.br
- rochinha
- Administrador

- Mensagens: 4664
- Registrado em: 18 Ago 2003 20:43
- Localização: São Paulo - Brasil
- Contato:
Amiguinhos
Apos estas explicacoes fica bem frisado que se o retaguarda contiver modulo de ECF/TEF e for homologado e por qualquer motivo tenha sido feita uma alteracao, revisao ou qualquer modificacao no mesmo, cai por terra todo o processo de homologacao.
O ECF/TEF passa a ser somente mais um programa que agregamos ao uso de nossos usuarios sem vinculo nenhum com qualquer programa, sendo totalmente independente assim como outlook, explorer, access, word, etc.
Inclusive podendo ser vendido a parte para outras empresas de software.
:xau @bracos :?)
Apos estas explicacoes fica bem frisado que se o retaguarda contiver modulo de ECF/TEF e for homologado e por qualquer motivo tenha sido feita uma alteracao, revisao ou qualquer modificacao no mesmo, cai por terra todo o processo de homologacao.
O ECF/TEF passa a ser somente mais um programa que agregamos ao uso de nossos usuarios sem vinculo nenhum com qualquer programa, sendo totalmente independente assim como outlook, explorer, access, word, etc.
Inclusive podendo ser vendido a parte para outras empresas de software.
:xau @bracos :?)
Re: Frente de Caixa x Retaguarda
Amigos,
A verdade verdadeira, é que esse negócio de Legislação é de deixar qualquer um maluco!
Cada Estado faz à sua maneira, muda muito de um para o outro... e fica até difícil agente esplanar nossas dúvidas.
Neste caso específico que coloquei neste post, pretendo fazer o sistema ESTRITAMENTE para o uso de EMISSÃO DE CUPOM FISCAL e, logicamente, tudo com relação a ECF (Cancelamento de cupom, Emissão de Redução Z, Leitura X, Leitura da Memoria Fiscal). Nada de Controle de estoque. Nem banco de dados terei. Apenas um simples cadastro de produtos. só.
A minha dúvida é justamente essa: Posso fazer o sistema assim? Qual é a obrigatoriedade de um aplicativo fiscal ter, paralalamente, um controle de estoque por trás, para que o fiscal possa comprovar "in-loco" a atualização das Mercadorias?
Lógico, que todas essas perguntas tem que ser respondidas genericamente, pois muda de Estado pra Estado.
É isso,
Um abraço,
Janio
A verdade verdadeira, é que esse negócio de Legislação é de deixar qualquer um maluco!
Cada Estado faz à sua maneira, muda muito de um para o outro... e fica até difícil agente esplanar nossas dúvidas.
No meu Estado (Ceará), por exemplo, não tem esse negócio de homologação de Aplicativo Fiscal sem o TEF. Aqui o fiscal visita o cliente, emite alguns cupons, cancela outros, emite alguns relatórios fiscais e pronto! Ele sela a impressora e a partir daí o sistema tá "homologado" sem que seja emitido nenhum documento afirmando que o nosso sistema está dentro de todas as especificações exigidas pela Fazenda.gransoft escreveu:Via de regra, um Aplicativo Fiscal para ECF, com ou sem o TEF, deverá ser Homologado/Credenciado pelas Secretarias da Fazenda Estaduais.
Neste caso específico que coloquei neste post, pretendo fazer o sistema ESTRITAMENTE para o uso de EMISSÃO DE CUPOM FISCAL e, logicamente, tudo com relação a ECF (Cancelamento de cupom, Emissão de Redução Z, Leitura X, Leitura da Memoria Fiscal). Nada de Controle de estoque. Nem banco de dados terei. Apenas um simples cadastro de produtos. só.
A minha dúvida é justamente essa: Posso fazer o sistema assim? Qual é a obrigatoriedade de um aplicativo fiscal ter, paralalamente, um controle de estoque por trás, para que o fiscal possa comprovar "in-loco" a atualização das Mercadorias?
Lógico, que todas essas perguntas tem que ser respondidas genericamente, pois muda de Estado pra Estado.
É isso,
Um abraço,
Janio
Editado pela última vez por janio em 22 Jun 2005 17:51, em um total de 1 vez.
fui...
e-mail:janioaguiar@yahoo.com.br
msn: janio_aguiar@hotmail.com
xHarbour1.2.1/Harbour3.2 + wvg + hwgui + Mediator + MySql
e-mail:janioaguiar@yahoo.com.br
msn: janio_aguiar@hotmail.com
xHarbour1.2.1/Harbour3.2 + wvg + hwgui + Mediator + MySql
- rochinha
- Administrador

- Mensagens: 4664
- Registrado em: 18 Ago 2003 20:43
- Localização: São Paulo - Brasil
- Contato:
Amiguinho
A fiscalizacao uso a maxima da contabilidade: entrou... saiu... e se saiu e porque entrou.
Isto não se aplica diretamente sobre a quantidade mas sim sobre os impostos que entram e saem.
Se entrou 10, saiu cinco, seu aplicativo fiscal devera apresentar estas cinco saidas. Pois se a fiscalizacao pegar pesado em relacao as notas de entrada e saida, sera calculado os impostos referentes a quantidade de itens que entrou em relacao a quantidade de itens que saiu, etc.
Seu aplicativo também devera controlar as baixas do estoque.
Se voce optar por criar um sistema generico que possa ate ser usado por outras empresas o seu estoque devera conter apenas codigo, descricao, valor e imposto(icms).
A saida gerada de cada cupom deverá ficar em um arquivo que posteriormente sera analisado por uma rotina de fechamento e entao o estoque principal sera atualizado. Este seria o metodo de trabalho off-line, ou seja, monta cada registro referente aos produtos(estoque), monta cada registro referente ao cupom(para o financeiro) mas efetiva a impressao do cupom no ato.
Este método de movimento de estoque num dado momento é mais seguro do que o método de baixa on-line que pode porventura perder vinculo ao baixar e furar o estoque.
Seu aplicativo devera prover os dois metodos.
@braços :?)
A fiscalizacao uso a maxima da contabilidade: entrou... saiu... e se saiu e porque entrou.
Isto não se aplica diretamente sobre a quantidade mas sim sobre os impostos que entram e saem.
Se entrou 10, saiu cinco, seu aplicativo fiscal devera apresentar estas cinco saidas. Pois se a fiscalizacao pegar pesado em relacao as notas de entrada e saida, sera calculado os impostos referentes a quantidade de itens que entrou em relacao a quantidade de itens que saiu, etc.
Seu aplicativo também devera controlar as baixas do estoque.
Se voce optar por criar um sistema generico que possa ate ser usado por outras empresas o seu estoque devera conter apenas codigo, descricao, valor e imposto(icms).
A saida gerada de cada cupom deverá ficar em um arquivo que posteriormente sera analisado por uma rotina de fechamento e entao o estoque principal sera atualizado. Este seria o metodo de trabalho off-line, ou seja, monta cada registro referente aos produtos(estoque), monta cada registro referente ao cupom(para o financeiro) mas efetiva a impressao do cupom no ato.
Este método de movimento de estoque num dado momento é mais seguro do que o método de baixa on-line que pode porventura perder vinculo ao baixar e furar o estoque.
Seu aplicativo devera prover os dois metodos.
@braços :?)

