Olá Colegas !

Apesar de alguma experiência, até então só utilizada em ERP e CRM, estou iniciando um novo desafio: Automação Comercial. Felizmente para mim, diversos clientes de ERP estão me "cobrando" a solução completa e tenho certeza que tenho algumas barreiras a vencer como, por exemplo, PDV e TEF.

Bem, direto ao assunto: O PDV Off-line.

Meu ERP trabalha com algumas soluções de PDV apenas importando e exportando arquivos texto para os "Gestores de Frente". Pois bem, observei algumas técnicas utilizadas pelos desenvolvedores do frente e, particularmente, achei interessante esta solução:

• ERP exporta texto para Produtos, Convenios, Clientes, CCF, etc...
• Gestor do Frente importa texto gerado pelo ERP para o seu banco de dados.
• Gestor do Frente gera texto de cada entidade importada do ERP para cada PDV.
• A cada abertura de CF ou consulta de preço, o PDV importa para seu banco de dados local o texto gerado pelo Gestor do Frente.
• Cada CF emitido pelo PDV é salvo em formato texto em seu disco, em diretório correspondente à data do dia. Além disso, o mesmo CF é salvo em um servidor de arquivos, também em um diretorio correspondente a data do dia.
• A cada reinício do software de PDV, os bancos de dados do Gestor do Frente, são copiados para seu disco local. Os bancos do PDV e do Gestor são idênticos.
• Ao finalizar o movimento do dia, a redução Z é salva no diretório do dia e um arquivo texto contendo todos os CFs emitidos naquele dia é gerado. Tanto o arquivo da redução quanto o de CFs do dia também são salvos no diretório do dia do servidor de arquivos.
• No dia seguinte (ou após fechamento da loja) o ERP importa do servidor de arquivos os CFs e as reduções de todos os PDVs fazendo todas as operações necessárias relacionadas a vendas, estoque, fiscal e contas à receber.

Esta solução tem algumas falhas que já observei e que irei contorná-las como, por exemplo, se o servidor de arquivos ficar off-line ou a rede indisponível por alguns minutos, os arquivos texto gerados pelos PDVs não são salvos no servidor. Pretendo criar um mecanismo que assegure que o diretorio do dia no disco local do PDV e o diretorio do dia no servidor de arquivos estejam sempre sincronizados, mesmo após falhas de hardware.

Falando em PDV Off-line e movimento de estoque/vendas também off-line, gostaria de contar com a opinião dos colegas em relação à esta solução.

Um abraço.

Ola Vinicius, seja bem vindo ao ForumWeb...

Também estou trabalhando em um PDV com caracteristicas semelhantes...

No ramo de Supermercados é muito importante a possibilidade de trabalhar Off-line, e a maioria dos programas Frente de Caixas assim o faz, porém notei que geralmente a exportação para o retaguarda é feita apenas no fim do dia... o que pode ser um incômodo para alguns administradores

Pensando nisso fiz uma solução hibrida que se comunica com o BD sempre que possível, mas mantendo uma copia atualizada das tabelas necessárias no HD local para o caso de queda da comunicação...

Notei ainda que normalmente a comunicação entre os programas é feita diretamente entre Retaguarda e Frente de caixa, o que complica um pouco, pois a retaguarda precisa sair "procurando" por todos os PDVs pela rede, para "pegar" os arquivos de Vendas e atualizando as tabelas de preços, clientes, etc... Pensando nisso, fiz um programa intermediário que chamei de Monitor, ele que fala com os Frente de Caixas, e cria apenas 1 arquivos com todas as vendas de todos os PDVs para a retaguarda

Estou fazendo uso intensivo dos recursos do ClientDataSet, que permite facilmente "chavear" entre a base on-line ou arquivo local e deixo essa tarefa para o proprio Delphi... Exemplo:

Na tabela de Operadores... Se o PDV estiver conectado ao BD, uso o SQL para trazer todos operadores da Loja além de Todos da empresa com Nivel de Admin

depois que o arquivo foi aberto com sucesso (AfterOpen) e antes de ser fechado (BeforeClose) salvo copia dele no HD (GravaArqOperador)

Essa tabela é read-only no PDV e os operadores devem ser cadastrados no programa Monitor

Para as tabelas de Vendas usei outra abordagem... Os dados sempre são gravados localmente (não há ligação com um DataSetProvider) e no final de cada venda verifico se o BD está disponivel dando um "ping" na porta do Servidor (mais rápido)... Se estiver, uso comandos SQL para gravar as vendas pendentes no BD e depois zero o arquivo de vendas local..


Para tabelas grandes como o Cadastro de Produtos e Clientes... Uso uma tabela Local (sem ligação com o BD) e o programa Monitor cria arquivos de atualização (apenas com os itens alterados/incluidos).... Nessa operação de atualização ainda há a possibilidade de enviar fotos de produtos novos, novas Skins, e atualizar o EXE do PDV... A rotina de atualização do Monitor compacta tudo em um .ZIP e grava esse ZIP no BD (campo Blob)... Depois sinaliza em um Flag na tabela de Terminais quais Terminais devem "baixar" esse ZIP... esse Flag é verificado pelos PDVs sempre que eles estão livres (não estão em venda)

Olá Daniel ! Obrigado pelas boas vindas e por compartilhar suas idéias comigo
Na verdade, sou membro antigo do FW (2003), porém pouco participativo por falta de tempo...



Exatamente o ramo aonde estou iniciando o trabalho com automação, tenho alguns clientes de ERP nesta área. Devido ao fato de serem soluções de desenvolvedores diferentes, estes clientes estão habituados a só obterem números totalizados das vendas no final do dia ou mesmo no dia seguinte. Porém, na solução de PDV irei criar formas de que os números possam ser consultados no decorrer do dia, mas independente do ERP.

Por isso vou criar um intermediário, como você o fez, e vou chamá-lo de "Gestor de frente". É esse "cara" que importará preços, clientes, CCF e etc do ERP e enviará as alterações para os PDVs. E será também ele o responsável por consultas e relatórios de vendas durante o dia. Mas *devo* manter esta comunicão ERP -> Gestor de Frente no formato de arquivos texto. O que será diferente é a comunicação entre Gestor de Frente e PDVs, esta poderá ser mais "elegante" como a sua, por fazerem parte da mesma solução.

Mas por que comunicação via "texto"? Porque mesmo criando a solução de PDV, poderei manter minha solução de ERP em outros clientes sem alterações e também vender minha solução de PDV para clientes que utilizam outro ERP ou mesmo aqueles clientes que não tenham ERP e não queiram investir em um no momento. Numa visão rápida não é uma solução muito elegante, mas é uma estratégia de mercado. Na verdade, meu Gestor de Frente, será um mini-ERP. Clientes que não queiram utilizar meu ERP e não possuam outro, poderão realizar controles básicos da loja, no tocante à produtos, clientes e vendas no próprio Gestor de Frente.

Atualmente, quando existem alterações de preços ou início de promoções, etc, meu ERP exporta estas alterações para um servidor de arquivos. Esta exportação pode ser automática ou não, isto é parametrizado e quem decide é o cliente. Porém, após feita a exportação, nas soluções de PDV que conheço é necessário um comando de importação no Gestor de Frente. Esse comando traz para seu banco de dados as alterações e as envia para o PDV simultaneamente.

O que eu vou fazer de diferente? O meu Gestor não vai exigir comando para importação do ERP/envio para os PDVs. Isto será automatizado porque ele irá monitorar o diretório designado no servidor de arquivos para onde o ERP exporta. Com isso se o cliente optar por exportação de alterações automáticas no ERP e estiver utilizando minha solução de PDV a comunicação será "quase" transparente.

Neste primeiro momento, estou tendendo a este modelo porque, como todo primeiro projeto na área, minha solução de PDV estará sujeita a muitas falhas.

Além disso, não sei se ocorre com você, mas é muito comum produtos serem inseridos na área de venda antes de terem suas N.Fs de entrada imputadas no ERP ou mesmo NFs imputadas de forma incorreta.
Meu ERP trata de forma muito séria e eu diria até bastante "chata", a questão custo. Se as vendas do PDV forem processadas imediatamente, sem atualização de custo do produto no ERP os relatórios de análise de lucratividade do dia ficam "furados"...

Com a importação após o fechamento da loja, estas falhas podem ser detectadas mais facilmente e, se necessário, a importação pode ser desfeita, os erros que levaram a apuração incorreta de custo e PMZ (Preço Margem Zero), corrigidos e as vendas re-importadas.

Será esta metodologia antiquada demais? Honestamente, não sei... É segura, com certeza.... Estou habituado a trabalhar desta forma e é sempre bom novas idéias para "clarear" a mente.

Em tempo, qual banco de dados local você usa? Estou numa dúvida "cruel" entre FB e Access, mas estou tendendo ao Access por ter acesso simplificado via ADO+JET, não requerer muitos recursos da máquina e, além disso, menos suceptível a corrupção por causa dos "dedinhos nervosos", loucos por um reset, dos operadores de PDV. Além disso, todas as boas soluções de PDV que conheço, utilizam o Access como banco local... não deve ser a toa.

[]'s

Vou trabalhar da mesma forma.... Vc já definiu o formato dos arquivos TXT para troca de informações entre o Gestor e o ERP ? Sabe se existe algum "formato padronizado" para esse tipo de intercambio.... Eu mesmo defini o meu formato, mas seria interessante seguir um padrão de mercado (caso exista algum)..


Sem dúvida é muito interessante... sem falar no fato que outras aplicações de Retaguarda (de outras SW.Houses) poderiam se integrar ao seu Gestor e PDV.. (se for o caso)...

Assim como o seu gestor, o meu programa Monitor tb pode trabalhar independente do ERP, nesse caso os produtos / clientes são cadastrados diretamente nele...


Mais uma vez pensamos da mesma forma... O meu programa Monitor tem parâmetros para monitorar um diretorio, e assim que os arquivos TXT chegam, ele processa-os, e pode (se assim foi configurado) já enviar as alterações para os PDVs... Aqui cabe uma preocupação extra: No momento da "carga" dos PDVs, pode haver equipamentos desligados ou fora da rede... Nesse caso é necessário um tratamento para processar arquivos de carga antigos ou não recebidos

Com o envio das vendas do Monitor para o ERP, o mesmo ocorre... Existe um parametro com o intervalo de tempo em que ele deve gerar o TXT, além de uma linha de comando que deve ser "disparada" após a criação do TXT com as vendas... Essa linha de comando pode ser um programa (tipo Console) escrito pela SW. do ERP que abrirá o TXT e incorporar os dados do TXT no ERP...


Concordo... não havia pensado nesse problema... meu Retaguarda tb registra no arquivo de Vendas o Custo Médio do produto na ocasião em que ocorreu a venda, para a apuração do Lucro..


Estou usando os arquivos binários do ClientDataSet (.CDS), o que a Borland chama de MyBase, são bastante rápidos (pois ficam na memória da máquina)... Fiz alguns testes de velocidade com uma base de dados de 10.000 produtos e foi muito bom... tb testei desligamentos e travamentos e parece que ele se comportou bem... Como estou focando o Linux procurei algo que pudesse rodar no Pinguim e tb no Windows... Se o Mybase começar a "dar pra trás" vou usar DBFs com o componente TDBF.... DBFs são muito robustos, e fáceis de trabalhar... e com o TDBF não preciso instalar o BDE, nem nenhuma DLL

Meu ERP já exporta para 3 soluções de PDV e, entre eles, não observei padrão, apenas semelhanças... Eu ainda não defini o formato, mas deve ser próximo dos que ele já exporta e, provavelmente, bastante parecido com o seu. Creio que não há como fugir do "básico".


A idéia é exatamente essa. Como meu ERP já trabalha com outros PDVs, outros ERPs poderão trabalhar com meu PDV.


Eu já projetei uma abordagem diferente para as cargas do PDV. Não será o Gestor a enviar a carga e sim o PDV a buscá-la. Quando o gestor importar o TXT do ERP, ele irá gerar no servidor de arquivos um arquivo TXT para cada PDV cadastrado no Gestor.
Exemplo:
- PDVs cadastrados no gestor 01, 02, 03 e 04.
- Gestor importa TXT de produtos do ERP e gera no servidor de arquivos "produto.01", "produto.02", "produto.03" e "produto.04". Estes arquivos serão criados se não existirem ou "appendados" se já existirem.
- PDV monitora (ou em tempo configurável ou a cada abertura de cupom - ainda não decidi) o diretório do servidor de arquivos e, se houver carga para ele a irá buscar.
Com isso, se um PDV sair da rede, assim que ele voltar ele mesmo se atualizará. Além disso, vou projetar a base de dados do PDV e do Gestor exatamente idênticas. Então, se o PDV for reiniciado, ele irá desconsiderar a carga parcial e irá buscar o banco de dados inteiro do gestor para ele. Por isso eu estou pensando em usar o Access. O inconveniente (segurança) é ter que manter o banco de dados do Gestor em um diretório acessível da rede. O conveniente é que, qualquer problema no BD do Gestor, serão tantos BDs de backup quando forem o número de PDVs


Não havia pensado no MyBase... Como será o seu comportamento com cerca de 30 mil registros?
No meu modelo de exportação do ERP para o Gestor e no que eu projetei para o PDV, um produto poderá ter vários códigos.
Exs:
- Mais de um EAN para um mesmo produto.
- EAN de fardos/caixas, como por exemplo, cerveja em lata. Neste caso meu ERP associa o EAN do fardo da cerveja em lata à 12 unidades do produto.
- Código interno também poderá ser utilizado no PDV mesmo com produtos que tenham EAN e sempre serão usados em casos de produtos pesáveis.

Estou achando esta discussão extremamente proveitosa.

Fiz o meu formato TXT meio as escuras, e tenho medo de estar muito diferente do usado pelos programas atuais... Haveria a possibilidade de vc me passar um link ou e-mail com alguns formatos de arquivos existentes ? Isso é, caso essa informação seja de acesso público...


Como vc pretende fazer para o PDV baixar o arquivo gerado no Gestor ? Será um acesso a uma pasta compartilhada em rede local ? inicialmente eu havia imaginado dessa maneira, mas mudei de ideia pois isso pode compremeter a segurança do Servidor e tb estou imaginando um Gestor de PDVs multi-lojas, então, em alguns casos o servidor não estará em uma rede Local. Por isso copio o arquivo gerado para um campo Blob do BD (FireBird), que é "baixado" pelo PDV....

Outro "problema" são as fotos... preferi manter as fotos em arquivos externos, em um sub-diretório "fotos"... o nome do arquivo é composto de CODEAN.jpg... usando um FileExists, verifico se a foto está disponivel e a carrego no Image.

Interessante a técnica de fazer um "append" no arquivo de carga... Eu usei um sistema de "fila" onde os arquivos de atualização pendentes devem todos ser processados...


Nunca usei o Acess como BD, mas já vi bons programas usando ele... Não gosto muito da ideia de depender de algum engine como o JET ou BDE... Acho que dificulta a instalação, sem falar na questão multi-plataforma... Parece que o MyBase vai dar conta do recado..

Acho que um dos primeiros segmentos a adotar o Linux como desktop será o de Supermercados, pois a maioria deles está com Windows ilegal, e comprar linceças para 10, 20, 50 terminais pode onerar muito o projeto de informatização... O Carrefour já usa um PDV em Linux... curiosamente, no mês passado, atendi um possível cliente que possui alguns mini-mercados, e só estava aceitando ver demonstração de programas PDV em Linux...


Muito interessante a ideia... não havia pensado nisso... meu cadastro permite apenas um código de barras. Também tenho suporte a produtos IN-STORE ou "pesáveis"... nesse caso é usado um código interno.


Sem duvida... muito bom trocar ideias...

Sim, imaginei um diretório compartilhado na rede ou por FTP (ainda não viabilizei esta segunda opção).
Veja bem: Pensando em soluções completamente independentes, você precisará ter um diretório para aonde o ERP irá exportar a fim de que o Gestor de PDV importe, correto? Este diretório precisará estar acessível pelo Gestor, então, poderia também estar acessível pelos próprios PDVs. O mesmo diretório utilizado pelo Gestor para importar do ERP, seria o mesmo para onde ele geraria a carga para os PDVs. Uma solução sem necessidade de acesso à LAN, apenas a um serviço como é o caso do Firebird ou por FTP é mais elegante, com certeza, mas bem mais complexa de ser implementada... eu acho...


Eu não vou trabalhar com fotos. Ao menos neste primeiro momento. Apesar da maioria dos softwares conterem o recuro, nunca vi ninguém usar.


Ainda não tenho muita certeza da viabilidade deste "append". É preciso imaginar que um caixa possa estar puxando sua carga ao mesmo tempo que o Gestor estaria lhe enviando outra. Será necessário bloquear o arquivo para um deles caso o outro o esteja utilizando e isto pode ser ruim. Uma fila de arquivos como você o fez, seria mais interessante para isso.


Como eu lhe disse, realmente não estou decidido pelo Acess como base local. É apenas um tendência... Se eu não optar pelo Firebird (Embedded) como banco local, não gostaria de requerer um "cliente" a mais, entende? Se eu fizer como você e optar pelo meu banco local com o Access, eu teria que que ter também o cliente do FB e o driver dbExpress instalados. É isso que eu gostaria de evitar.
Estou fazendo testes pesados no FB Embedded para ver se ele "segura a peteca".


Pois é... o Pinguim. Já o utilizo amplamente como servidor e gosto muito. Mas não vou pensar nele agora como Desktop. Neste primeiro momento, criar minha primeira solução de PDV para Win32 já estará ótmo. Após isso posso fazer o "bolo crescer".
Se eu "viajar" demais acabo não cumprindo minhas metas de prazo. O que aliás, acontece com todos nós programadores
Prova da viagem é que eu estava decido a suportar somente Bematech e Sweda, agora já quero suportar também a Daruma. Se eu me deixar levar, vou passar o ano todo só trabalhando na classe de suporte à ECFs

O mecanismo de filas tb pode apresentar problemas se o terminal ficar muito tempo fora do ar... nesse caso uma "carga completa" seria mais fácil do que processar todos os arquivos da Fila... Uma outra opção é gerar um arquivo diferenciado para cada Terminal, baseado em algum campo de Data_Ultima_Atualização


Como vim do Clipper, gosto muito de DBFs... a simplicidade da estrutura do arquivo é o segredo da sua robustez... o problema são os indices (CDX, NTX, IDX) que são facilmente corrompidos em queda de energia/travamentos... mas acho que seria rápido criar os indices sempre que a aplicação iniciar... Usar DBFs com o BDE era um tormento, mas agora com o componente TDBF ficou muito fácil... Acho que seria interessante evitar soluções que o prendam apenas a plataforma Windows (Access) e impossibilitem uma migração no futuro...

Gostaria de saber como FB embedded sai nos seus testes... nunca o utilizei, mas acho a ideia muito interessante...


Acho que o ACBr pode ajudar nessa tarefa... atualmente há suporte para mais de 10 ECFs diferentes... Iniciei o ACBr porque estava com a ideia fixa em Linux e poucos fabricantes tem soluções de alto-nivel para Linux semelhantes as DLLs... a consequencia é que o meu PDV está mais de 1 ano atrasado do seu lançamento previsto...

Pessoal


Como vcs tratam a questão de contas a receber/convenios com o pdv off line?


Hj minha solução é mista, partes off outras on-line.


Tenho usuário q controlam diversas lojas em um unico CPD, e os clientes podem comprar em qquer loja q a checagem de limite de crédito, compras em atraso, convenio e cheques sem fundo são feitas on-line.


ainda não vi a luz no fim do tunel pra poder deixar isto 100% off line



Ederson Selvati

Ederson,

Acho que tem que ser assim, mesmo... Crédito é algum muito dinâmico e deve ser consultado on-line... Eu mantenho na tabela de Clientes o Crédito atual do cliente, e atualizo esse campo sempre que ele é consultado on-line.

Uma ideia é permitir a aprovação de crédito off-line mediante uma senha de gerente ou supervisor, caso o valor da compra chegue muito perto do Limite...

Também vim do Clipper (às vezes da saudade... ainda tenho 6 clientes rodando aplicações minhas escritas em clipper), mas nunca usei DBF com o Delphi, graças a Deus também nunca usei Paradox.
Vou testar o TDBF também como base local. Estarei lhe reportando em breve sobre o FB Embedded. Até o final desta semana, creio que terei uma posição definitiva sobre o que irei utilizar localmente.

Sobre a dúvida do Eselvati, ainda não projetei isso, mas penso que crédito, deve ser sempre on-line, assim como o Daniel pensa.
Infelizmente, ainda não posso opinar muito sobre isso pois ainda não pensei sobre o assunto.

Bom dia ...estava lendo este tópico e achei bem interessante , ja trabalhei com pdv neste formato, e particularmente analisando outros na minha opinião acredito que desta forma fica muito melhor de se trabalhar , hj a loja na qual trabalhava com software desta forma tb migrou seus pontos de venda para linux e estão muito satisfeitos, acredito que esta não é mais uma tendencia mas uma realidade por isso os aplicativos para multi-plataformas terão um grande espaço no mercado..La as atualizações eram geradas no aplicativo que no caso chamavam de retaguarda , e eram enviadas para o servidor onde todos os pdvs no momento em que eram ligados efetuavam a busca desta atualização , e caso algum destes não tivessem sido atualizados tinham uma forma de aviso para que o operador , possa saber que seu caixa não estava com seus dados atualizados. Onde cada pdv tinha uma mini banco local que se comunicava durante o dia com o servidor , enviando todas as suas transaçãoes...entre outros detalhes...
Mas era muito bacana tinham poucos problemas .

Colegas,

Demorou um pouco mais que o previsto para eu ter uma posição definitiva porque encontrei algumas dificuldades do FB Embeded com o dbExpress.
Ele fica um pouco instável, algumas vezes, fechando "do nada" a aplicação após algumas conexões e desconexões.
Para contornar isso, deve-se usar um "macete" para que também não ocorra erro de carregamento da "fbembed.dll" pelo SQLConnection:
No OnCreate do TDataModule chamar "LoadLibrary" na DLL e no OnDestroy chamar "FreeLibrary", como segue:


Não gostei desta instabilidade com o dbExpress e resolvi conferir com mais testes. Resultado: totalmente estável com IBX. Só por desencargo de consciência testei até com ADO. Acho que a instabilidade é só com o dbExpress (uso driver da Borland para IB).

Vou usar o FB Embeded com IBX como banco local. A performance é, naturalmente, excepcional. Se algo me fizer mudar de idéia durante o desenvolvimento, estarei comunicando a vocês.

Vinicius,

Vc experimentou usar o driver para a dbExpress da UIB... Parece que com o FB 1.5 o driver do Interbase desenvolvido pela Borland ficou um pouco incompatível....

Os Componentes UIB tb são um bom substituto para a IBX, pois acho que atualmente o desenvolvimento deles está mais intenso que a IBX... O UIB foi incorporado ao projeto Jedi...

Compilar o driver dbExpress da UIB nã é muito simples, pois é necessário vários componentes adicionais para conseguir compilar os packages da UIB... Se vc quizer tenho os drivers dbExpress compilados com a versão 2.0, para Delphi (.DLL) e para Kylix (.SO)

Olá Daniel !

Especificamente com o Embeded não testei o driver da UIB, mas já o testei e tentei utilizá-lo em projetos normais e não deu certo... Eu o estava acompanhando desde a versão 1.2, baixei e compilei os drivers 2.0, mas mesmo assim não tive boas experiências.

Para mim ele está instável e são frequentes as quedas de conexão ou erros "desconhecidos" emitidos pelo TSQLConnection. Infelizmente, não tive sucesso nos testes com projetos normais client/server e por isso nem cogitei utilizá-lo com o Embeded.

Na verdade, estou bem próximo de uma decisão relação à camada de acesso: assim que sair o FB 2.0 ou eu compro o driver da Upscene e continuo com dbExpress ou compro o FIB+.
Depois que migrei todos os meus projetos para Midas, felizmente, substutuir a camada de acesso é bem simples.

Vinicius, pode nos dizer quais "3 soluções" são essas?

Caros colegas,

Trabalho com PDV's para segmento de supermercados e postos de combustivel, os PDV's tbem são offline porem os dados são guardados em banco de dados que posteriormente são importados pelo aplicativo Gerencial, eu gosto deste modelo pois não tenho problemas como perda de dados. As informações como clientes, parametros, etc são exportadas pelo gerencial direto para a Base do PDV.

Wesley Silva.

Acho que as "soluções" que o Vinicius comentou são softwares de PDV (de terceiros) que ele usa em conjunto com o Retaguarda dele... Ou seja, gerar o TXT adequado a rotina de Importação de dados do programa PDV...

Sim, eu sei. Estou perguntando os nomes dos produtos.

Caro Vinicius,
Pela data de sua postagem vc deve ter resolvido o problema do fb embarcado.
Estou sendo obrigado a desenvolver um pdv off line e uso D7 + DBexpress + FB 1.5 com a seguinte implementação :
Dois SqlConnection com a VendorLib setadas para FBEMBED.DLL e FBCLIENT.DLL;
Tive que usar sua dica para carregar a Dll Embarcada para evitar mensagens de erros insperadas;

O que esta acontecendo é que quando saio da aplicação ocorre o erro : Access Violation at address 00C9591B in module 'FBCLIENT.DLL'. Read of Address XXXXX e so fecha pela IDE do delphi.

Descobri que se acessar apenas localmente ou seja mesmo a conexão de rede tendo sido feita, mas nenhuma operação ( um simples select ) realizado, a aplicação fecha na boa.
Desabilitei o carregamento do banco local via dll embarcada e nenhuma mensagem de erro foi registrada.

Para contornar temporariamente ( para poder continuar trabalhando tive que fazer no evento close do form principal

try
SqlConnection1.Close;
SqlConnection2.Close;
except
Application.Terminate;
end;

O colega tem algum comentário para ajudar-me ?

Olá para todos
a solução off line que desenvolvi funciona da seguinte forma:

o frente de caixa trabalha sempre on line, com opcao de off line em caso de pane.
base de dados servidor SQL SERVER 2000
base de dados cliente SQL MSDE (gratuito)

criei um banco chamado SERVIDOROFF que fica no servidor, este por sua vez e alimentado atravez de triggers de inclusao,alteracao,exclusao
existente no bancoprincipal tambem hospedado no servidor da empresa, assim as alterações, inclusoes, exclusoes, sao feitas de forma automatica
e totalmente transparente para o usuario do retaguarda. sem compromentimento de performance.
existe um programinha monitor no servidor que e configurado para a cada x horas realizar um backup desse banco e zipa-lo e deixa-lo em uma pasta no servidor, o processo de backup e zip, nao demora mais que 10 segundos, com base de dados com 60.000 produtos, e 30.000 clientes.

cada apos o fechamento do cupom, ou abertura de sistema, o frente de caixa verifica se esse arquivo q esta no servidor e mais recente, e entao faz uma copia para o caixa local.

se der uma pane no servidor, ou rede, basta o usuario do caixa, entrar no sistema atravez de um outro atalho especial, onde entao o frente de caixa
descompacta o arquivo, restaura o backup, e comeca a incluir as vendas, e contas a receber localmente, qdo o servidor for restaurado, e entrar
no sistema em modo normal, ele ira incluir as vendas e contas a receber no servidor.


incialmente tentamos fazer com que o sistema trabalhasse totalmente off line,
mas a realidade de alguns clientes aqui nos forçou a usar esse outro conceito, pois totalmente off line houve os seguintes problemas:

o cliente acabou de fazer a compra no caixa, e quer emitir uma nota fiscal, as vendas ainda nao estavam no servidor, a nota nao era possivel
de ser impressa, optamos entao para enviar as vendas a cada fechamento do cupom, mas isso ficou lento, e acabava dependendo da rede
do mesmo jeito.

o cliente acabou de ir no crediario e pagou suas 'notinhas' pois aqui a maioria trabalha (senao todos) com convenios e venda na promissoria.
fez uma nova compra, e indo ao caixa, seu saldo do contas a receber ainda nao estava atualizado, o que gerava constragimento, pois era solicitado
senha de liberação da venda, sendo que o cliente tinha acabado de pagar.

o cliente acabou de fazer uma compra na promissoria, e se dirige ao crediario, onde tem outras notas do mes anterior, o cliente quer da um cheque
para pagar as notas do mes anterior e da venda que acabou de fazer no caixa, mas a venda ainda nao estava no servidor.


---
inicialmente a base de dados era access, mas o monitor no servidor, para garantir que a base de dados estivesse 100 confiavel
optamos em a cada x horas recriar a base inteira, transferindo todos os produtos, clientes para o banco access no servidor
esse processo era demorado e dependendo do servidor sobrecarregava, e demorava +- 10 minutos.
mudamos para o MSDE por ser 100% compativel com o SQL server, e por ser mais rapido e simples mante-lo atualizado no servidor atravez
das trigges. alem de ser tambem gratuito. agora o processo no servidor e apenas de executar o backup e zipa-lo.

obviamente esse modo para uso em caso de emergencia, servidor parado, queima do hub da rede.
na nossa experiencia, isso se mostrou satisfatorio. pois tudo fica on line, estoque, vendas, estatisticas, contas a receber.

Oi Wilton,

Obrigado por compartilhar conosco sua experiência...

Olá pessoal, eu adotei a seguinte técnica: o pdv, quando iniciado a primeira vez depois de instalado, carrega todos os produtos, funcionarios, dados de configurações necessários para um banco LOCAL. A partir desse momento, toda vez que iniciam uma nova venda, o sistema checa na tabela de produtos se houve alguma alteração, da seguinte forma: ao ser incluido ou alterado um produto, é gravado em um campo a data/hora da alteração. Quando o pdv faz a "checagem", ele pega apenas os que foram alterados depois da ultima vez que checou. Assim a base local vai estar com os produtos sincronizados. Quando se inicia uma venda e o banco não está disponível, ele entra em modo OFF, efetuando vendas no banco local. Ao iniciar uma venda em que o banco no servidor esteja ON-LINE, ele avisa o usuario e sincroniza as vendas, informando ao servidor tudo que foi feito OFF, inclusive ajustando o estoque. Meu PDV é simples, apenas achei legal vocês compartilharem as idéias e senti vontade também...

-------------------------
Pelo que li até agora percebo que é bem complicado implementar pdv off-line e a falta de um padrão de programação complica ainda mais. parece que não existe uma idéia formada.
Estou no termino de um sistema de automação mas não sei se vou encarar o pdv off-line. Não iniciei o projeto preparando o sistema para pdv-offline será que terei problemas?

Em Supermercados um PDV off-line é essencial... Já imaginou se a rede cai e todos os caixas param de funcionar ?

Olá Fábio, eu "ganhei" um cliente de prensente por justamente "garantir" pra ele que meu PDV não precisa de servidor nem da rede pra continuar trabalhando, OFF-line sem dúvida...

Temos um PDV totalmente online que roda há 5 anos em vários clientes, onde a maior loja tem cerca de 20 caixas. Muito raramente algum caixa fica fora do ar por problemas de rede, e nunca ficaram todos fora do ar. Há switches de reserva para troca em caso de pane, a rede está estruturada de forma a não ser tão vulnerável.

Acredito que hoje em dia isso seja mais uma questão de infra-estrutura de rede do que de modelagem de dados.

Olá amigos,

Este debate foi um dos mais ricos deste forum, e serviu para que eu fizesse a coisa certa aqui. Bem fica uma duvida, na questão da pré-venda, como vc resolvem a questào do pcv offline. supondo q a rede esta em pane. O que fazer com as vendas inicadas no balcào????


Michel Penna

Unica solução: Exporte para um Disquete e execute o Disquete do PDV, ou se forem mais modernos, pode usar Pen Drive

Se a rede cair, começou no balção tem que terminar no balção ou esperar a rede voltar, pois da máquina não tem como sair hehehe... entretanto se apenas o servidor cair, é possível implementar uma transmissão da pré-venda do balcão para o caixa. Mas isso com a rede online....

Com a rede offline tem que apelar para o papel, ou salva em disquete (pendrive pls) um "arquivo de remessa" e leva para o caixa.

[]'s

Olá a todos, soluções criativas são sempre bem vindas, só tomem cuidado com a CONCOMITÂNCIA. Tem clientes que são obrigados e clientes que não o são...

Certamente, mas situação de pre-venda acredito que são situações onde a concomitancia é desobrigada. O CF é gerado localmene... o risco é no caso de um sistema remoto (onde o terminal só faz a leitura e a nota/cupom é gerada no sistema que está em outra máquina). Mas neste caso ou a rede funciona, ou funciona!

[]'s

Olá a todos...
Estou trabalhando num projeto de PDV que irá funcionar de forma parecida as que estão descritas neste tópico...

também estou criando um retaguarda para ele...

vai ser um sistema multi camadas...

onde algumas algumas tabelas serão armazenadas localmente e serão atualizadas via carga...

o método para carga eu ainda estou projetando. Pretendo abusar no uso do ClientDataSet e XML...

---------------------------------------------------------------------------------------------------------------------------------------------

Vou manter no projeto, um servidor de Aplicação que irá trabalhar mais ou menos parecido com o "Monitor" do Daniel,
porém, no meu caso o servidor vai trabalhar tanto com o PDV quanto com o retaguarda, pois, o projéto é de um sistema
multi camadas. Estou afim de implementar de tudo no PDV (TEF discado e dedicado, Contagem de Estoque e assim por diante...)

O tópico ajudou bastante, pois vimos aqui vários métodos que não se usa discutir muito em fóruns...rsrsr
e como é dificil encontrar informação para quem está começando na área de automação comercial hen...

jah revirei a NET procurando alguns exemplos para a questão do ClientDataSet Atualizar o XML quando conectado mas tah difícil...

O Daniel usou um método no começo do tópico que abril um pouco mais a minha mente, valew Daniel...

Se tiverem mais algum método para faze - lo, postem para discutirmos sobre o assunto...

Já que é tão dificil encontrar informações sobre o assunto, vamos disponibilizar as nossas idéias...

Abraço a todos...

Estou aguardando os post's OK...

Olá Leandro,

Estive ausente por algumas semanas... Apenas para atualizar o tópico...

Atualmente tenho usado arquivos DBF (com o componente TDBF) para as tabelas com muita movimentação, como a de Vendas, pois o ClientDataSet sempre salva TODO o conteudo da memória para o arquivo... e quanto maior o arquivo, mais lenta e suscetível a falha é essa operação...

DBF ??? sim... DBFs são extremamente resistentes a quedas de energia... O que corrompe são os arquivos de índices (CDX, NTX MDX)... Portanto, sempre que o PDV inicia, os índices são apagados e re-criados via código

Blz Daniel...

to estudando um mecanismo para fazer o armazenamento via XML usando o próprio CDS (ClientDataSet), tipo assim...

Ele vai salvar o arquivo pela data da venda, isso, numa pasta separada tipo "MOVDIA" ou coisa assim.

para cada dia ele vai salvar um arquivo como backup, pois, quando conectado com o Servidor da Aplicação (Só para lembrar, o projeto é Multtier) ele deverá enviar o movimento de vendas para o Servidor, desta forma eu mantenho um arquivo no HD Local e o banco de dados é atualizado instantaneamente.

Caso o PDV esteja OFF ele enviará os dados assim que conectar...

Que acha da Idéia?

Olá pessoal,

Aproveitando esse tópico,

Tenho um PDV rodando com essas características e estou usando o CLIENTDATASET para armazenar as tabelas locais,
porém está acontecendo um problema que é na questão de queda de energia.
Quando estamos em uma venda acontece uma queda de energia, os registros de produtos lançados quando o sistema volta simplesmente desaparece.
Já procurei alguma método que salve esses dados fisicamente para quando o sistema voltar conseguir ver esses registros mas não consegui.

Alguém já passou por essa situação e sabe como resolver?

muito obrigado a todos.
sucesso!

Olá Automação, no AfterPost do CDS, vc coloca o código:

quando seu pdv voltar da queda de energia vc verifica se existe o arquivo 'C:\venda.CDS'. Se exister vc lê:


Daniel, já usei DBF e pretendo voltar a usar para colocar o movimento do dia, mas uma coisa que pega é que momento ou quando o Servidor irá buscar esse movimento, ou o Caixa irá enviar esse movimento, envia a tabela inteira?, várias tabelas por dia???. Hoje armazeno tudo em Firebird, cada caixa é seu próprio servidor e no servidor de todos os caixas eu fico puxando as vendas de tempo em tempo, mas isso acarreta vários erros com queda da rede, registros duplicados, etc... Qualquer luz é bem vinda...

Uso o CDS apenas para Tabelas "estáticas" como Lista de Produtos e Clientes, para tabelas com grande volumes de inserção de dados (como as de movimento) uso os DBFs... Os CDS fica extremamente lento para ler e gravar arquivos muito grandes... A operação "SaveToFile" fica cada vez mais lenta, com o aumento do arquivo... e se a "SaveToFile" falhar, todo arquivo CDS pode ser corrompido... Se usar o formato em XML, ao invés do formato binário (CDS) a lentidão aumenta ainda mais...

No meu caso, todas as vendas (em DBFs) são descarregadas no Servidor FireBird, assim que a conexão estiver presente... e o PDV, verifica isso no final de cada Venda... Um campo FLAG indica se a venda já foi ou não "descarregada" no Servidor.

No fechamento de Turno, todas as vendas já "commitadas" são eliminadas das tabelas locais em DBF, ou seja, se tudo estiver certo (servidor ok) os arquivos de movimento são zerados...

Olá Daniel, mas quem faz o serviço de descarregar de fato, o caixa ou o servidor, isso muito me preocupa, acho que o caixa não deveria se preocupar com isso, pq eu imagino uma cena do tipo ficar um dia inteiro sem rede, no final do dia a rede volta, quando a próxima venda for finalizada o caixa vai ficar parado esperando todas as vendas serem enviadas???, eu penso que essa responsabilidade de ficar buscando os dados nos caixas deveria ser do Servidor e a limpeza dos dados já enviados da tabela também ser do servidor... No seu caso os DBF são todos sem indices??? e sem BDE???

No meu caso, é o Caixa que envia as informações para o Servidor... Atualmente eu descarrego tudo que estiver pendente... Logo após a abertura de turno ele já faz a verificação, e se todo o movimento estiver pendente, ele já tentará enviar tudo, antes de liberar o caixa para vendas...

BDE nem pensar... Uso o TDBF (que é OpenSource), e já é nativo no Lazarus.... Crio novos índices sempre que o PDV é iniciado... DBFs tem má fama por causa da corrupção de índices, mas o real problema são os índices, corromper o DBF é muito difícil.