Re: [Openerp-brazil-team] [Fwd: Re: POS, Windows e etc.]
99 views
Skip to first unread message
Guilherme Santos
Dec 28, 2010, 9:47:57 PM12/28/10
to Cloves Almeida, OpenERPBrasil Groups, openerp-b...@lists.launchpad.net
Olá pessoal!
Revivendo essa discussão, gostaria de compartilhar alguns "problemas" referentes ao PAF-ECF que estão me fazendo quebrar a cabeça.
Imaginemos por exemplo uma empresa que:
Venda produtos para outros estados, através de Televendas, E-commerce, etc. O faturamento será feito através de NF-e;
Venda produtos na sua loja física. A venda é feita diretamente no POS e emitido Cupom Fiscal;
Presta serviços de conserto de equipamentos: Faturamento será feito através de NF-e/NFS-e para equipamentos com entrega ou através de Cupom Fiscal quando o cliente retira o equipamento diretamente na loja.
Até aí tudo bem, porém o PAF-ECF exige que se o sistema ERP execute alguma função que exista requisito estabelecido, será necessário análise/homologação do sistema ERP também!
O PAF-ECF trata Ordens de Serviços como Documento Auxiliar de Venda (DAV), assim como trata Pedidos e Orçamentos, ou seja, seria necessário a homologação do OpenERP também, já que ele controlaria as Ordens de Serviços(DAV-OS)!
O "problema" é:
Como homologar um sistema opensource? (Usuário final teria acesso a todo código fonte para modificar o que quiser e achar maneiras para sonegação de impostos)
Como homologar um sistema que é atualizado diariamente? (É necessário realizar nova homologação caso o sistema seja modificado após ser homologado)
Como homologar um sistema modular? (Onde o usuario final pode criar simplesmente um novo modulo)
Ou seja, a empresa não poderia controlar suas ordens de serviços pelo OpenERP!
Seguem algumas perguntas e respostas retiradas do Roteiro de Homologação do PAF-ECF:
Pergunta: 08 Quando o aplicativo fiscal analisado funciona com mais de um software de Retaguarda(ERP) ou,
quando o cliente da Empresa Desenvolvedora possui um software Retaguarda de outra
Empresa Desenvolvedora, devemos listar no Laudo de Analise todos os softwares de
Retaguarda com os seus respectivos códigos MD5? Se sim, teremos que chamar a outra
empresa Desenvolvedora para obter também o código MD5 do software de Retaguarda?
Resposta: O Software de Gestão ou Retaguarda somente necessita ser analisado quando execute
alguma função para a qual exista requisito estabelecido. Se tais funções forem todas executadas pelo
PAF-ECF não há necessidade de analisar o Software de Gestão ou Retaguarda. Entretanto, se o PAF-
ECF deixar de executar alguma função e a mesma for executada por diversos Softwares de Gestão e
Retaguarda, estes deverão ser analisados e identificados no Laudo de Análise com o seu código MD-5.
Quanto à apresentação dos Softwares de Gestão ou Retaguarda, sugerimos observar o disposto no item
VII das Orientações Gerais deste Roteiro de Analise.
Pergunta: 22 Na lei do PAF tem uma informação de que é possível reservar a quantidade em estoque
quando fizer um registro de pré-venda. A pré-venda deve ser realizada somente pelo
aplicativo PAF ou pode ser gerada em outro programa? Imagine uma loja de materiais de
construção que possui 1 computador de caixa PAF e 3 computadores no balcão para
atendimento que não possui ECF (Não pode ser o PAF) porém estes softwares que rodam no
micro do balcão devem ter a possibilidade de gerar registros de pré-venda para ser finalizado
e impresso o cupom fiscal pelo PAF no caixa e ambos os sistemas compartilham a mesma
base de dados para que o aplicativo do balcão possa reservar a quantidade em estoque. É
possível esta operação?
Resposta: A função para Registro de Pré-venda ou emissão de DAV pode ser executada pelo Sistema
de Gestão ou Retaguarda. Entretanto, neste caso o referido sistema também deverá ser submetido a
análise (veja resposta da pergunta 08). A operação exemplificada na pergunta é possível, desde que
seja realizada pelo próprio PAF-ECF ou por Sistema de Gestão ou Retaguarda integrado ao PAF-ECF.
Pergunta: 31 Sobre a análise funcional de PAF-ECF que possa funcionar com vários sistemas de
retaguarda:
a) Na análise do PAF-ECF será necessária a análise de todas as retaguardas?
b) Pode ser emitido um laudo de um PAF-ECF e várias retaguardas ou precisará de um novo
laudo para cada retaguarda?
c) E no caso de uma nova retaguarda suportada pelo PAF-ECF, mas que não constou no
laudo?
d) Sendo analisado um PAF-ECF com a apresentação de apenas uma retaguarda poderá
ser comercializado com outra retaguarda que não conste no laudo técnico?
Resposta: Preliminarmente deve-se esclarecer que o Software de Gestão ou Retaguarda somente
necessita ser analisado quando execute alguma função para a qual exista requisito estabelecido. Isto
posto vamos às respostas:
a) Sim.
b) Sim, pode ser emitido um laudo de PAF-ECF relacionando vários Sistemas de Gestão ou
Retaguarda.
c) Deve ser realizada nova análise com emissão de novo laudo para inclusão do novo Sistema de
Gestão ou Retaguarda.
d) Não. (veja respostas acima)
Não sei se estou entendendo errado, mas essas exigencias do PAF-ECF acabam com "filosofia" de sistemas Livres.
Opinem!
Abraços,
Guilherme Santos
Revivendo essa discussão, gostaria de compartilhar alguns "problemas" referentes ao PAF-ECF que estão me fazendo quebrar a cabeça.
Imaginemos por exemplo uma empresa que:
Venda produtos para outros estados, através de Televendas, E-commerce, etc. O faturamento será feito através de NF-e;
Venda produtos na sua loja física. A venda é feita diretamente no POS e emitido Cupom Fiscal;
Presta serviços de conserto de equipamentos: Faturamento será feito através de NF-e/NFS-e para equipamentos com entrega ou através de Cupom Fiscal quando o cliente retira o equipamento diretamente na loja.
Até aí tudo bem, porém o PAF-ECF exige que se o sistema ERP execute alguma função que exista requisito estabelecido, será necessário análise/homologação do sistema ERP também!
O PAF-ECF trata Ordens de Serviços como Documento Auxiliar de Venda (DAV), assim como trata Pedidos e Orçamentos, ou seja, seria necessário a homologação do OpenERP também, já que ele controlaria as Ordens de Serviços(DAV-OS)!
O "problema" é:
Como homologar um sistema opensource? (Usuário final teria acesso a todo código fonte para modificar o que quiser e achar maneiras para sonegação de impostos)
Como homologar um sistema que é atualizado diariamente? (É necessário realizar nova homologação caso o sistema seja modificado após ser homologado)
Como homologar um sistema modular? (Onde o usuario final pode criar simplesmente um novo modulo)
Ou seja, a empresa não poderia controlar suas ordens de serviços pelo OpenERP!
Seguem algumas perguntas e respostas retiradas do Roteiro de Homologação do PAF-ECF:
Pergunta: 08 Quando o aplicativo fiscal analisado funciona com mais de um software de Retaguarda(ERP) ou,
quando o cliente da Empresa Desenvolvedora possui um software Retaguarda de outra
Empresa Desenvolvedora, devemos listar no Laudo de Analise todos os softwares de
Retaguarda com os seus respectivos códigos MD5? Se sim, teremos que chamar a outra
empresa Desenvolvedora para obter também o código MD5 do software de Retaguarda?
Resposta: O Software de Gestão ou Retaguarda somente necessita ser analisado quando execute
alguma função para a qual exista requisito estabelecido. Se tais funções forem todas executadas pelo
PAF-ECF não há necessidade de analisar o Software de Gestão ou Retaguarda. Entretanto, se o PAF-
ECF deixar de executar alguma função e a mesma for executada por diversos Softwares de Gestão e
Retaguarda, estes deverão ser analisados e identificados no Laudo de Análise com o seu código MD-5.
Quanto à apresentação dos Softwares de Gestão ou Retaguarda, sugerimos observar o disposto no item
VII das Orientações Gerais deste Roteiro de Analise.
Pergunta: 22 Na lei do PAF tem uma informação de que é possível reservar a quantidade em estoque
quando fizer um registro de pré-venda. A pré-venda deve ser realizada somente pelo
aplicativo PAF ou pode ser gerada em outro programa? Imagine uma loja de materiais de
construção que possui 1 computador de caixa PAF e 3 computadores no balcão para
atendimento que não possui ECF (Não pode ser o PAF) porém estes softwares que rodam no
micro do balcão devem ter a possibilidade de gerar registros de pré-venda para ser finalizado
e impresso o cupom fiscal pelo PAF no caixa e ambos os sistemas compartilham a mesma
base de dados para que o aplicativo do balcão possa reservar a quantidade em estoque. É
possível esta operação?
Resposta: A função para Registro de Pré-venda ou emissão de DAV pode ser executada pelo Sistema
de Gestão ou Retaguarda. Entretanto, neste caso o referido sistema também deverá ser submetido a
análise (veja resposta da pergunta 08). A operação exemplificada na pergunta é possível, desde que
seja realizada pelo próprio PAF-ECF ou por Sistema de Gestão ou Retaguarda integrado ao PAF-ECF.
Pergunta: 31 Sobre a análise funcional de PAF-ECF que possa funcionar com vários sistemas de
retaguarda:
a) Na análise do PAF-ECF será necessária a análise de todas as retaguardas?
b) Pode ser emitido um laudo de um PAF-ECF e várias retaguardas ou precisará de um novo
laudo para cada retaguarda?
c) E no caso de uma nova retaguarda suportada pelo PAF-ECF, mas que não constou no
laudo?
d) Sendo analisado um PAF-ECF com a apresentação de apenas uma retaguarda poderá
ser comercializado com outra retaguarda que não conste no laudo técnico?
Resposta: Preliminarmente deve-se esclarecer que o Software de Gestão ou Retaguarda somente
necessita ser analisado quando execute alguma função para a qual exista requisito estabelecido. Isto
posto vamos às respostas:
a) Sim.
b) Sim, pode ser emitido um laudo de PAF-ECF relacionando vários Sistemas de Gestão ou
Retaguarda.
c) Deve ser realizada nova análise com emissão de novo laudo para inclusão do novo Sistema de
Gestão ou Retaguarda.
d) Não. (veja respostas acima)
Não sei se estou entendendo errado, mas essas exigencias do PAF-ECF acabam com "filosofia" de sistemas Livres.
Opinem!
Abraços,
Guilherme Santos
De: Cloves Almeida <cjal...@gvmail.br>
Para: Raphaël Valyi <rva...@gmail.com>
Cc: OpenErp Brasil <openerp-b...@lists.launchpad.net>
Enviadas: Quinta-feira, 25 de Março de 2010 11:57:06
Assunto: Re: [Openerp-brazil-team] [Fwd: Re: POS, Windows e etc.]
Assim como ERP, as soluções de POS costumam ser agrupadas por segmento - não existe um POS que atende a todos e as necessidades de um supermercado, por exemplo, são bem diferentes de um restaurante, ou de um varejista de eletrônicos. E a legislação fiscal e os periféricos adicionam uma carga gigante de complexidade no trabalho. O OpenbravoPOS com muito esforço pode atender bem alguns segmentos, mas não acho que valha a pena criar um projeto específico de integração nos moldes do que foi feito com o Magento.
Outro ponto que POS é um sistema relativamente barato e há dúzias de empresas com sistemas prontos e funcionando em todo o país. Por isso que minha idéia é criar interfaces XML que simplifiquem o processo de integração. Isso permite que a empresa use o OpenERP com qualquer PDV, bastando que ele gere/processe os arquivos XML. Uma integração específica via Kettle, mesmo sendo mais simples inicialmente, exigiria mais esforço por parte do desenvolvedor do POS.
Do ponto de vista do integrador, fica possível fazer uma implantação menos traumática. Enquanto ao trocar o ERP você precisa treinar normalmente só o pessoal da matriz, trocando o POS em qualquer empresa de varejo você impacta um exército de vendedores e caixas, distribuídos geograficamente. Para quem tem interesse em vender uma solução de ERP para empresas de varejo, dar a opção de poder manter o POS atual é um grande bônus.
Resumindo, independente de haver ou não POS open-source adequados, uma plataforma de integração baseada em troca de arquivos XML (nos moldes da NFe, mas simplificado) é mais interessante, dado a variedade das soluções POS existentes e a complexidade de desenvolver uma alternativa open-source.
CJ
Raphaël Valyi escreveu:
> Ola,
>
> Cloves, muito interessante seu trabalho.
> Porem, voce poderia me confirmar o que voce acha do OpenbravoPOS se ele pode ou nao atender as necessidades legais no Brasil?
> Lembro que graça a nosso trabalho de integraço com Kettle (TerminatOOOR http://github.com/rvalyi/terminatooor ), ficaria facil integrar entao OpenERP com OpenbravoPOS (8 dias para nos eu diria), mas entao eu gostaria saber se alguem acha que vale a pena ou sera que o mundo do POS é dfinitivamente condemnado a se entregar para as soluçoes proprietarias no Brasil?
> Vi que a OpenVIP se orgulha de ter feito um projeto com OpenbravoPOS em Sao Paulo, mas no caso foi num bar, quer dizer talvez a problematica nos bares/restaurantes ainda é outra. Bom, a pergunta é: seria interessante ou nao fazer esse trabalho de integraçao com OpenbravoPOS (no caso eu ia derivar a transformaçao Kettle da propria Openbravo para usar la com nosso plugin TerminatOOOR e talvez algums modulos tipo base_external_referentials ou base_sale_multichannels).
>
> Obrigado.
>
> Raphaël Valyi
> http://www.akretion.com.br <http://www.akretion.com.br> - primeiro integrador OpenERP parceiro da Tiny no Brasil
>
>
>
> 2010/3/24 Cloves Almeida <cjal...@gvmail.br <mailto:cjal...@gvmail.br>>
>
> Lincoln e outros.
>
> Eu comecei a trabalhar com integração a POS no OpenERP, mas a
> solução existente tinha muitos problemas e decidimos alterar. Hoje
> usamos uma solução de uma empresa local daqui de Goiânia (AugePDV)
> que atende TEF/ECF/PAF/etc. Contudo ele não está integrado ao OpenERP.
>
> A integração funcionaria assim: a cada operação, um dos pontos
> (PDV ou OpenERP) gera um arquivo XML com a operação e manda para
> as partes interessadas. Cada ponto teria um INBOX e um OUTBOX. Uma
> rotina ou sistema faria o roteamento das mensgens do OUTBOX de um
> para o INBOX de outro.
>
> A implementação envolve então:
>
> 1) Mecanismos para fazer o "gancho" nas operações (cadastro de
> cliente, venda, contagem de estoque, cadastro de produto, etc.) no
> OpenERP e no PDV.
> 2) Definição de um esquema XML para as operações.
> 3) Mecanismo no OpenERP para transformar os objetos no XML
> (serialização).
> 4) Mecanismo para processar o XML nos objetos (de-serialização).
> 5) Regras de negócio ao processar o XML (na venda, por exemplo,
> gerar o "sales.order", baixar o estoque, lançamentos contábeis, etc.).
> 6) Infra-estrutura para armazenamento e roteamento das mensagens
> (usando o ActiveMQ por exemplo).
>
> A vantagem dessa arquitetura é que poderíamos acoplar praticamente
> qualquer PDV ao OpenERP. O gancho no PDV poderia ser feito via
> TRIGGERS no BD e nem precisaria mexer no código do PDV.
>
> Infelizmente, eu tive que parar o desenvolvimento por conta da
> implantação do novo PDV. Em algumas semanas, porém, pretendo fazer
> integração dos sistemas aqui com a parte contábil do OpenERP
> usando essa estratégia. Para tanto, em vez de um único módulo,
> pretendo criar um módulo genérico de integração e para isso vou
> precisar desenvolver as partes 1,3, 4 e 6. Já meio caminho andado
> para o PDV.
>
> CJ
>
> Lincoln Wallace Procopio escreveu:
>
> Ola a todos, estou a comecar o estudo da ferramenta OpenERP, e as
> coisas esta ficando mais claras para mim.
>
> Tabalho na area de desenvolvimento a 22 anos, comecei com
> Basic no MSX
> Expert, migrei para Dbase II Plus para MSX Expert (Sim existe
> o Dbsase
> para MSX :D), e posteriormente para Clipper no ambiente PC,
> atualmente
> desenvolvo em Visual Basic, Xharbour e FiveWin, e nao estou
> querendo
> reescrever a roda, com bastante experiencia com SQL junto ao
> banco de
> dados Mysql.
>
> Estou comecando uma parceria forte em um escritorio contabil
> grande da
> minha regiao, onde temos varios clientes que iriam de encontro
> com o
> OpenERP, ja que tenho 10 meses para realizar algumas adequacoes
> funcionais, fiscal e contabil na ferramenta, mas para isso
> preciso de
> maiores informacoes a respeito do andamento do projeto, porque
> sei que
> alguns tem e terao as mesmas necessidades que tenho (NFe, Sped,
> Sintegra, POS e etc).
>
> Entao tenho algumas perguntas:
>
> 1) Como poderia ajudar no projeto, usando o Ambiente Windows como
> ambiente de desenvolvimento/testes.
> 2) Como estao o projeto aprofundadamente falando no que diz
> respeito a
> NFe, Sped e Sintegra.
> 3) Sei que o amigo Cloves esta trabalhando forte com POS, qual
> ferramenta ele esta a utilizar para vendas no varejo, e se essa
> ferramenta ja esta adequada para Tef/Ecf.
> 4) Como funciona a parte de customizacao do OpenERP, o que da para
> solucionar sem alterar profundamente o projeto.
> 5) Sei do problema dos calculos tributarios que ja estao a ser
> solucionado, previsao para termino do projeto?!
> 6) Como preparar um ambiente de teste junto ao Windows XP!?
>
> Desculpe das perguntas triviais que estou a fazer mas preciso de
> maiores esclarecimentos para poder quem sabe em um futuro ajudar a
> comunidade mais ativamente e poder desbravar o OpenERP de um
> modo m
> ais profissional.
>
>
> Um forte abraco a todos e aguardo anciosamente uma respostas.
>
>
> Lincoln Wallace Procopio
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-brazil-team
> <https://launchpad.net/%7Eopenerp-brazil-team>
> Post to : openerp-b...@lists.launchpad.net
> <mailto:openerp-b...@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~openerp-brazil-team
> <https://launchpad.net/%7Eopenerp-brazil-team>
> More help : https://help.launchpad.net/ListHelp
>
>
_______________________________________________
Mailing list: https://launchpad.net/~openerp-brazil-team
Post to : openerp-b...@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openerp-brazil-team
More help : https://help.launchpad.net/ListHelp
Para: Raphaël Valyi <rva...@gmail.com>
Cc: OpenErp Brasil <openerp-b...@lists.launchpad.net>
Enviadas: Quinta-feira, 25 de Março de 2010 11:57:06
Assunto: Re: [Openerp-brazil-team] [Fwd: Re: POS, Windows e etc.]
Assim como ERP, as soluções de POS costumam ser agrupadas por segmento - não existe um POS que atende a todos e as necessidades de um supermercado, por exemplo, são bem diferentes de um restaurante, ou de um varejista de eletrônicos. E a legislação fiscal e os periféricos adicionam uma carga gigante de complexidade no trabalho. O OpenbravoPOS com muito esforço pode atender bem alguns segmentos, mas não acho que valha a pena criar um projeto específico de integração nos moldes do que foi feito com o Magento.
Outro ponto que POS é um sistema relativamente barato e há dúzias de empresas com sistemas prontos e funcionando em todo o país. Por isso que minha idéia é criar interfaces XML que simplifiquem o processo de integração. Isso permite que a empresa use o OpenERP com qualquer PDV, bastando que ele gere/processe os arquivos XML. Uma integração específica via Kettle, mesmo sendo mais simples inicialmente, exigiria mais esforço por parte do desenvolvedor do POS.
Do ponto de vista do integrador, fica possível fazer uma implantação menos traumática. Enquanto ao trocar o ERP você precisa treinar normalmente só o pessoal da matriz, trocando o POS em qualquer empresa de varejo você impacta um exército de vendedores e caixas, distribuídos geograficamente. Para quem tem interesse em vender uma solução de ERP para empresas de varejo, dar a opção de poder manter o POS atual é um grande bônus.
Resumindo, independente de haver ou não POS open-source adequados, uma plataforma de integração baseada em troca de arquivos XML (nos moldes da NFe, mas simplificado) é mais interessante, dado a variedade das soluções POS existentes e a complexidade de desenvolver uma alternativa open-source.
CJ
Raphaël Valyi escreveu:
> Ola,
>
> Cloves, muito interessante seu trabalho.
> Porem, voce poderia me confirmar o que voce acha do OpenbravoPOS se ele pode ou nao atender as necessidades legais no Brasil?
> Lembro que graça a nosso trabalho de integraço com Kettle (TerminatOOOR http://github.com/rvalyi/terminatooor ), ficaria facil integrar entao OpenERP com OpenbravoPOS (8 dias para nos eu diria), mas entao eu gostaria saber se alguem acha que vale a pena ou sera que o mundo do POS é dfinitivamente condemnado a se entregar para as soluçoes proprietarias no Brasil?
> Vi que a OpenVIP se orgulha de ter feito um projeto com OpenbravoPOS em Sao Paulo, mas no caso foi num bar, quer dizer talvez a problematica nos bares/restaurantes ainda é outra. Bom, a pergunta é: seria interessante ou nao fazer esse trabalho de integraçao com OpenbravoPOS (no caso eu ia derivar a transformaçao Kettle da propria Openbravo para usar la com nosso plugin TerminatOOOR e talvez algums modulos tipo base_external_referentials ou base_sale_multichannels).
>
> Obrigado.
>
> Raphaël Valyi
> http://www.akretion.com.br <http://www.akretion.com.br> - primeiro integrador OpenERP parceiro da Tiny no Brasil
>
>
>
> 2010/3/24 Cloves Almeida <cjal...@gvmail.br <mailto:cjal...@gvmail.br>>
>
> Lincoln e outros.
>
> Eu comecei a trabalhar com integração a POS no OpenERP, mas a
> solução existente tinha muitos problemas e decidimos alterar. Hoje
> usamos uma solução de uma empresa local daqui de Goiânia (AugePDV)
> que atende TEF/ECF/PAF/etc. Contudo ele não está integrado ao OpenERP.
>
> A integração funcionaria assim: a cada operação, um dos pontos
> (PDV ou OpenERP) gera um arquivo XML com a operação e manda para
> as partes interessadas. Cada ponto teria um INBOX e um OUTBOX. Uma
> rotina ou sistema faria o roteamento das mensgens do OUTBOX de um
> para o INBOX de outro.
>
> A implementação envolve então:
>
> 1) Mecanismos para fazer o "gancho" nas operações (cadastro de
> cliente, venda, contagem de estoque, cadastro de produto, etc.) no
> OpenERP e no PDV.
> 2) Definição de um esquema XML para as operações.
> 3) Mecanismo no OpenERP para transformar os objetos no XML
> (serialização).
> 4) Mecanismo para processar o XML nos objetos (de-serialização).
> 5) Regras de negócio ao processar o XML (na venda, por exemplo,
> gerar o "sales.order", baixar o estoque, lançamentos contábeis, etc.).
> 6) Infra-estrutura para armazenamento e roteamento das mensagens
> (usando o ActiveMQ por exemplo).
>
> A vantagem dessa arquitetura é que poderíamos acoplar praticamente
> qualquer PDV ao OpenERP. O gancho no PDV poderia ser feito via
> TRIGGERS no BD e nem precisaria mexer no código do PDV.
>
> Infelizmente, eu tive que parar o desenvolvimento por conta da
> implantação do novo PDV. Em algumas semanas, porém, pretendo fazer
> integração dos sistemas aqui com a parte contábil do OpenERP
> usando essa estratégia. Para tanto, em vez de um único módulo,
> pretendo criar um módulo genérico de integração e para isso vou
> precisar desenvolver as partes 1,3, 4 e 6. Já meio caminho andado
> para o PDV.
>
> CJ
>
> Lincoln Wallace Procopio escreveu:
>
> Ola a todos, estou a comecar o estudo da ferramenta OpenERP, e as
> coisas esta ficando mais claras para mim.
>
> Tabalho na area de desenvolvimento a 22 anos, comecei com
> Basic no MSX
> Expert, migrei para Dbase II Plus para MSX Expert (Sim existe
> o Dbsase
> para MSX :D), e posteriormente para Clipper no ambiente PC,
> atualmente
> desenvolvo em Visual Basic, Xharbour e FiveWin, e nao estou
> querendo
> reescrever a roda, com bastante experiencia com SQL junto ao
> banco de
> dados Mysql.
>
> Estou comecando uma parceria forte em um escritorio contabil
> grande da
> minha regiao, onde temos varios clientes que iriam de encontro
> com o
> OpenERP, ja que tenho 10 meses para realizar algumas adequacoes
> funcionais, fiscal e contabil na ferramenta, mas para isso
> preciso de
> maiores informacoes a respeito do andamento do projeto, porque
> sei que
> alguns tem e terao as mesmas necessidades que tenho (NFe, Sped,
> Sintegra, POS e etc).
>
> Entao tenho algumas perguntas:
>
> 1) Como poderia ajudar no projeto, usando o Ambiente Windows como
> ambiente de desenvolvimento/testes.
> 2) Como estao o projeto aprofundadamente falando no que diz
> respeito a
> NFe, Sped e Sintegra.
> 3) Sei que o amigo Cloves esta trabalhando forte com POS, qual
> ferramenta ele esta a utilizar para vendas no varejo, e se essa
> ferramenta ja esta adequada para Tef/Ecf.
> 4) Como funciona a parte de customizacao do OpenERP, o que da para
> solucionar sem alterar profundamente o projeto.
> 5) Sei do problema dos calculos tributarios que ja estao a ser
> solucionado, previsao para termino do projeto?!
> 6) Como preparar um ambiente de teste junto ao Windows XP!?
>
> Desculpe das perguntas triviais que estou a fazer mas preciso de
> maiores esclarecimentos para poder quem sabe em um futuro ajudar a
> comunidade mais ativamente e poder desbravar o OpenERP de um
> modo m
> ais profissional.
>
>
> Um forte abraco a todos e aguardo anciosamente uma respostas.
>
>
> Lincoln Wallace Procopio
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-brazil-team
> <https://launchpad.net/%7Eopenerp-brazil-team>
> Post to : openerp-b...@lists.launchpad.net
> <mailto:openerp-b...@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~openerp-brazil-team
> <https://launchpad.net/%7Eopenerp-brazil-team>
> More help : https://help.launchpad.net/ListHelp
>
>
_______________________________________________
Mailing list: https://launchpad.net/~openerp-brazil-team
Post to : openerp-b...@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openerp-brazil-team
More help : https://help.launchpad.net/ListHelp
Guilherme Santos
Dec 30, 2010, 10:57:58 AM12/30/10
to Luiz Franca, openerp-b...@lists.launchpad.net, openerp...@googlegroups.com
Boa tarde Luiz,
O que eu tinha em mente, e acredito que todos aqui também, era de apenas integrar um sistema POS homologado com o OpenERP. Porém, a lei do PAF-ECF deixa bem claro, que se o "retaguarda" cria documentos previstos no roteiro de análise, também será necessário homologação.
Vamos pegar como exemplo o módulo de vendas do OpenERP, ele inicia como uma cotação(orçamento), que é considerado um DAV pela lei do PAF-ECF. Já seria motivo para ter que homologar o OpenERP, correto?
Mas aí vem o grande "problema", o ERP é Opensource (nem longe um sistema Opensource deveria ser um problema!).
Será que não poderemos usar o OpenERP em empresas varejistas, obrigadas a emissão de Cupom Fiscal/PAF-ECF?
Problema complicado para se resolver no fim de ano, não? hehehe
Abraços,
Guilherme Santos
O que eu tinha em mente, e acredito que todos aqui também, era de apenas integrar um sistema POS homologado com o OpenERP. Porém, a lei do PAF-ECF deixa bem claro, que se o "retaguarda" cria documentos previstos no roteiro de análise, também será necessário homologação.
Vamos pegar como exemplo o módulo de vendas do OpenERP, ele inicia como uma cotação(orçamento), que é considerado um DAV pela lei do PAF-ECF. Já seria motivo para ter que homologar o OpenERP, correto?
Mas aí vem o grande "problema", o ERP é Opensource (nem longe um sistema Opensource deveria ser um problema!).
Será que não poderemos usar o OpenERP em empresas varejistas, obrigadas a emissão de Cupom Fiscal/PAF-ECF?
Problema complicado para se resolver no fim de ano, não? hehehe
Abraços,
Guilherme Santos
De: Luiz Franca <lu...@sigsolucoes.net.br>
Para: Guilherme Santos <guisa...@yahoo.com.br>
Cc: Cloves Almeida <cjal...@gvmail.br>; "openerp-b...@lists.launchpad.net" <openerp-b...@lists.launchpad.net>; OpenERPBrasil Groups <openerp...@googlegroups.com>
Enviadas: Quarta-feira, 29 de Dezembro de 2010 8:52:57
Assunto: Re: [Openerp-brazil-team] [Fwd: Re: POS, Windows e etc.]
Para: Guilherme Santos <guisa...@yahoo.com.br>
Cc: Cloves Almeida <cjal...@gvmail.br>; "openerp-b...@lists.launchpad.net" <openerp-b...@lists.launchpad.net>; OpenERPBrasil Groups <openerp...@googlegroups.com>
Enviadas: Quarta-feira, 29 de Dezembro de 2010 8:52:57
Assunto: Re: [Openerp-brazil-team] [Fwd: Re: POS, Windows e etc.]
Bom dia Guilherme,
Realmente a situação é bastante complicada, não tenho as respostas da forma como voce deseja, mas vou tentar contribuir.
A legislação Brasileira, está tentando se garantir contra a sonegação e a obtenção de informações sofre as operações fiscais, e para isto está criando obrigações e responsabilidades tanto para o contribuinte quanto para a software house. Na prática, algumas delas são muito difíceis, e outras até quase impossíveis.
Quanto ao PAF-ECF, o que a legislação diz é muito claro, se sua aplicação de retaguarda realiza funções previstas para o PAF-ECF, voce tem que homologar também a aplicação do retaguarda. A simples importação de cadastros e a exportação de cupons, não obriga a homologação do retaguarda, mas se voce fizer davs ou pre-vendas no retaguarda e importar para o PAF-ECF, tem que homologar o retaguarda, alem disto, se voce transferir para o retaguarda a geração dos arquivos previstos na legislação, como sintegra e etc, voce tambem precisa homologar o retaguarda.
Caso seu frente gere estes arquivos e voce os exporte para o retaguarda, por apenas este motivo, não precisa homologar o retaguarda.
Uma vez homologado, PAF-ECF e/ou retaguarda, durante um ano após a homologação, voce pode fazer alterações em sua aplicação e simplesmente informar a SEF que voce tem nova versão, sem necessidade de re-homologação. Claro, cada vez que voce informar, tem que pagar uma "taxinha".
Agora o grande problema está no fato de ser software livre. Há requisitos no PAF-ECF que voce tem que garantir a integridade dos dados não apenas quanto igualdade entre ECF e base de dados, mas tambem quanto a adulteração por parte do contribuinte. Como fazer isto se os fontes estão no contribuinte? Neste caso, implicitamente, estamos impedidos de usar o software livre para PAF-ECF. Para o retaguarda não há tal impedimento, a não ser que seu PAF-ECF não atenda 100% da legislação.
Sei que minha informação resolveu pouco, mas tá ai!
Um grande abraço
Luiz Fernando M.França
Reply all
Reply to author
Forward
0 new messages