PRODUTOS NO PDV
Ola pessoal
Com a obrigatoriedade do PAF a partir de 2014 aqui no paraná, estou implementando o PDV como manda o roteiro de homologação do PAF. Bom ate ai tudo bem, o PDV ja esta 80% de acordo com as normas, mas... uma as obrigações é o PDV trabalhar off-line, eu ja desenvolvi isso e utilizei arquivos TXT para troca de informações e esta rodando perfeitamente no cliente, so que quando o usuario na retaguarda gera o arquivo dos produtos e manda para o PDV, o mesmo fica +/- 7 minutos processando, visto que o cliente tem mais de 30.000 produtos cadastrados em sua base.
Entao gostaria de saber como que voces estao tratando isso, ou ainda algum exemplo/dica que seja mais rapido para a importação dos produtos no PDV.
Boa noite a todos.
Com a obrigatoriedade do PAF a partir de 2014 aqui no paraná, estou implementando o PDV como manda o roteiro de homologação do PAF. Bom ate ai tudo bem, o PDV ja esta 80% de acordo com as normas, mas... uma as obrigações é o PDV trabalhar off-line, eu ja desenvolvi isso e utilizei arquivos TXT para troca de informações e esta rodando perfeitamente no cliente, so que quando o usuario na retaguarda gera o arquivo dos produtos e manda para o PDV, o mesmo fica +/- 7 minutos processando, visto que o cliente tem mais de 30.000 produtos cadastrados em sua base.
Entao gostaria de saber como que voces estao tratando isso, ou ainda algum exemplo/dica que seja mais rapido para a importação dos produtos no PDV.
Boa noite a todos.
Apesar do comentário, um bom tempo para 30 mil produtos em arquivo-texto.
Uma sugestão é utilizar base de dados diretamente ao invés de arquivos texto, e efetuar o download do arquivo de base de dados atualizado para as estações (PDV), conforme elas sejam inicializadas.
Com isso, você [Ô]pula[Ô] toda a parte de conversões.
Utilizar um SQL Server CE 4.0 é uma boa alternativa, não tem custo e não requer servidor.
Uma sugestão é utilizar base de dados diretamente ao invés de arquivos texto, e efetuar o download do arquivo de base de dados atualizado para as estações (PDV), conforme elas sejam inicializadas.
Com isso, você [Ô]pula[Ô] toda a parte de conversões.
Utilizar um SQL Server CE 4.0 é uma boa alternativa, não tem custo e não requer servidor.
ok, professor
eu ja tinha pensado nisso, trocar o arquivo direto, mais eu uso firebird, e o firebird nao tem esse recurso.
eu ate pensei nisso de no momento da inicialização, so que se alterar um preço durante o dia, vai ter que passar as alterações do mesmo jeito.
agora surgiu outra duvida o SQL server CE ele cria arquivos individuais para cada tabela? pois se criar vale a pena a migração!
eu ja tinha pensado nisso, trocar o arquivo direto, mais eu uso firebird, e o firebird nao tem esse recurso.
eu ate pensei nisso de no momento da inicialização, so que se alterar um preço durante o dia, vai ter que passar as alterações do mesmo jeito.
agora surgiu outra duvida o SQL server CE ele cria arquivos individuais para cada tabela? pois se criar vale a pena a migração!
Marcelo, não sei qual é a regra de negócio do seu sistema e nem mesmo a estrutura do seu banco de dados.
Mas pense na seguinte possibilidade.
Naturalmente as alterações efetuadas no retaguarda não irão afetar todos os 30.000 itens Correto. E sendo assim o correto seria enviar apenas os itens alterados, de forma que acredito , reduzir MUITO o tempo para essa atualização no PDV.
Mas pense na seguinte possibilidade.
Naturalmente as alterações efetuadas no retaguarda não irão afetar todos os 30.000 itens Correto. E sendo assim o correto seria enviar apenas os itens alterados, de forma que acredito , reduzir MUITO o tempo para essa atualização no PDV.
ok Foxman, eu ja uso isso em meu sistema, mas vamos analisar a seguinte situação (e pode ter certeza que isso acontece) o cliente tem 5 pdvs na loja, sendo que durante a semana ele utiliza apenas 3 em virtude do movimento, ja no fim de semana ele abre os 5 pdvs para suprir demanda de venda, mas durante a semana ocorreram várias alterações de preços, os quais aqueles 2 que ficaram desligados não receberam, ai que entra a nacessidade de gerar todos os itens, e o cliente nem pensa se deve gerar para apenas os 2... ele manda pra todos, ficando um tempao a loja parada.
Citação::
ok Foxman, eu ja uso isso em meu sistema, mas vamos analisar a seguinte situação (e pode ter certeza que isso acontece) o cliente tem 5 pdvs na loja, sendo que durante a semana ele utiliza apenas 3 em virtude do movimento, ja no fim de semana ele abre os 5 pdvs para suprir demanda de venda, mas durante a semana ocorreram várias alterações de preços, os quais aqueles 2 que ficaram desligados não receberam, ai que entra a nacessidade de gerar todos os itens, e o cliente nem pensa se deve gerar para apenas os 2... ele manda pra todos, ficando um tempao a loja parada.
Ok, isso realmente ocorre, no meu caso solicito aos meus clientes que permaeçam com os caixas ligados(assim como nos supermercados).
Mas caso o cliente queira deixar realmente os caixas desligados, a sugestão então é fazer carga de arquivos a partir dos caixas, e não a partir do retaguarda. Por dois motivos :
Não sobrecarrega a rede e nem o servidor.
Pode-se fazer a carga PDV por PDV preferencialmente quando o mesmo estiver ocioso.
Aqui em minha região o Supermercado(Savenagno) onde costumo fazer compras utiliza-se desse recurso. Digo porque volta e meia vejo os gerentes de frente de caixa solicitar ao caixa para FAZER CARGA, e nesse momento o caixa pressiona alguma tecla o pdv abre uma tela e faz a carga de arquivos.
Legal essa opção do caixa pegar a carga é legal, nao tinha pensado nisso.
Mais outra duvida, hoje uso banco de dados firebird (um arquivo .fdb com todas as tabelas dentro), fora o dbf e paradox, existe algum outro banco de dados que armazene as tabelas em arquivos separados? Caso exista, vale a pena a migração para esse banco, pois assim eu posso copiar o arquivo da tabela, sem prescisar alterar registro a registro?
Mais outra duvida, hoje uso banco de dados firebird (um arquivo .fdb com todas as tabelas dentro), fora o dbf e paradox, existe algum outro banco de dados que armazene as tabelas em arquivos separados? Caso exista, vale a pena a migração para esse banco, pois assim eu posso copiar o arquivo da tabela, sem prescisar alterar registro a registro?
O SQL Server CE é composto por um único arquivo, com extensão [Ô].sdf[Ô], e um arquivo temporário de log é criado durante os acessos, com extensão [Ô].ldf[Ô].
Eu citei o SQL Server CE por ser uma base de dados bem interessante, pequena e flexÃvel. Como você disse que os dados á serem atualizados estão em arquivos-texto, imaginei que o módulo que usa esses textos poderia ter o SQL Server CE como administrador de dados, e nesse caso, apenas os dados relacionados aos produtos e valores atualizados, sendo que toda a parte relacionada ás transações comerciais viria [Ô]zerada[Ô]. O arquivo centralizado do SQL Server CE seria razoavelmente pequeno, o suficiente para que cada estação fizesse o download atualizado (carga) quando ligado, em rede interna, e esse download seria relativamente rápido, se comparado á importar dados de arquivos-texto. Eu pessoalmente, se tivesse de lidar com o problema, faria assim. E ainda tem o fechamento dos terminais, onde os dados fariam o caminho contrário, das estações ao servidor. Um arquivo SQL Server CE, enviado á uma pasta especÃfica do central, com uma nomenclatura própria indicando terminal, data, hora e status, viabilizaria uma troca de caixa entre turnos mais [Ô]pacÃfica[Ô]. No [Ô]retaguarda[Ô], sim, uma rotina avaliando essa pasta e seu conteúdo, fariam a atualização dos dados de movimentação do servidor, sempre que um arquivo fosse transferido integralmente.
Mas depois, lendo as respostas subsequentes, pode não ser tão simples quanto imaginei. Uma vez que todas as suas rotinas já foram criadas para usar o Firebird, alterar as coisas agora pode ser complexo e demorado (codificação para os updates, para validar os arquivos e a comunicação com o servidor etc.). é sempre complicado, e até perigoso, [Ô]trocar pneu com o carro andando[Ô].
Mas voltando á sua última pergunta, á exemplo do FoxPro, Paradox e dBase, em arquivos separados, os relacionamentos perdem fiabilidade, pois nenhuma regra de servidor é [Ô]checada[Ô] nas operações CRUD. Além disso, vários arquivos implicam em manter vários ponteiros (handles) [Ô]pendurados[Ô], o que torna o modelo menos estável e mais lento. O modelo [Ô]file per table[Ô], portanto, já foi padrão, mas por conta da segurança, vem se tornando obsoleto.
O Firebird pode utilizar tanto um modelo (file per table) quanto outro (single file), e dá conta do recado, muito bem aliás, por administrar todos os arquivos de forma integrada, ou seja, á partir de um Server central.
O InnoDb também confere fiabilidade á opção de [Ô]file per table[Ô] no MySQL, e a lista não para por aÃ.
E nessa linha, sempre existe o XML, se é o caso de usar arquivos separados para cada tabela. A vantagem de um XML é que você só precisa dos DataTables nativos para lidar com eles. Mas há desvantagens, e não são poucas.
Mas realmente é necessário usar arquivos separados ? Digo, se você precisa copiar uma tabela, não se trata apenas de fazer uma consulta, tipo [Ô]SELECT * FROM [TABELA][Ô] e salvar com algum formato interessante, até em XML, por exemplo ?
Eu citei o SQL Server CE por ser uma base de dados bem interessante, pequena e flexÃvel. Como você disse que os dados á serem atualizados estão em arquivos-texto, imaginei que o módulo que usa esses textos poderia ter o SQL Server CE como administrador de dados, e nesse caso, apenas os dados relacionados aos produtos e valores atualizados, sendo que toda a parte relacionada ás transações comerciais viria [Ô]zerada[Ô]. O arquivo centralizado do SQL Server CE seria razoavelmente pequeno, o suficiente para que cada estação fizesse o download atualizado (carga) quando ligado, em rede interna, e esse download seria relativamente rápido, se comparado á importar dados de arquivos-texto. Eu pessoalmente, se tivesse de lidar com o problema, faria assim. E ainda tem o fechamento dos terminais, onde os dados fariam o caminho contrário, das estações ao servidor. Um arquivo SQL Server CE, enviado á uma pasta especÃfica do central, com uma nomenclatura própria indicando terminal, data, hora e status, viabilizaria uma troca de caixa entre turnos mais [Ô]pacÃfica[Ô]. No [Ô]retaguarda[Ô], sim, uma rotina avaliando essa pasta e seu conteúdo, fariam a atualização dos dados de movimentação do servidor, sempre que um arquivo fosse transferido integralmente.
Mas depois, lendo as respostas subsequentes, pode não ser tão simples quanto imaginei. Uma vez que todas as suas rotinas já foram criadas para usar o Firebird, alterar as coisas agora pode ser complexo e demorado (codificação para os updates, para validar os arquivos e a comunicação com o servidor etc.). é sempre complicado, e até perigoso, [Ô]trocar pneu com o carro andando[Ô].
Mas voltando á sua última pergunta, á exemplo do FoxPro, Paradox e dBase, em arquivos separados, os relacionamentos perdem fiabilidade, pois nenhuma regra de servidor é [Ô]checada[Ô] nas operações CRUD. Além disso, vários arquivos implicam em manter vários ponteiros (handles) [Ô]pendurados[Ô], o que torna o modelo menos estável e mais lento. O modelo [Ô]file per table[Ô], portanto, já foi padrão, mas por conta da segurança, vem se tornando obsoleto.
O Firebird pode utilizar tanto um modelo (file per table) quanto outro (single file), e dá conta do recado, muito bem aliás, por administrar todos os arquivos de forma integrada, ou seja, á partir de um Server central.
O InnoDb também confere fiabilidade á opção de [Ô]file per table[Ô] no MySQL, e a lista não para por aÃ.
E nessa linha, sempre existe o XML, se é o caso de usar arquivos separados para cada tabela. A vantagem de um XML é que você só precisa dos DataTables nativos para lidar com eles. Mas há desvantagens, e não são poucas.
Mas realmente é necessário usar arquivos separados ? Digo, se você precisa copiar uma tabela, não se trata apenas de fazer uma consulta, tipo [Ô]SELECT * FROM [TABELA][Ô] e salvar com algum formato interessante, até em XML, por exemplo ?
Tópico encerrado , respostas não são mais permitidas