AJUDA COM NUMERO DE PEDIDO.

KURTGU 25/06/2017 18:50:49
#474716
Pessoal quero uma ideia de como posso fazer isso estou com um sistema, aonde é gerado o numero do pedido ao pesquisar o cliente se ele achar o cliente na lista ele gera um numero de pedido, e apos isso a pessoa faz venda ao finalizar venda com forma de pagamento tudo certo, ele salva no banco o pedido, uma duvida se tiver trabalhando em duas estacoes como poderia gerar esse numero de pedido? para que a outra estacão não gerar o mesmo numero de pedido...

Estou usando banco de dados Mysql....Gostara de uma ideia de como posso fazer.
KERPLUNK 25/06/2017 19:46:49
#474718
Com uma Sequence. Cada vez que se pega um número, ele é único. O ruim é que podem haver [Ô]gaps[Ô] na sequência. Caso alguém comece um pedido e não termine, jamais haverá um pedido com aquele número.
KERPLUNK 25/06/2017 19:51:50
#474719
Mysql não tem sequnce propriamente, mas é possível ter o mesmo comportamento, tem vários artigos descrevendo isso.
KURTGU 25/06/2017 19:58:15
#474720
Citação:

:
Mysql não tem sequnce propriamente, mas é possível ter o mesmo comportamento, tem vários artigos descrevendo isso.



Kerp o que acha da ideia criei um tabela _temp ao gero o pedido Salvo nessa tabela, antes de gerar e inserir verifico se o numro do pedido nao existe na tabela se existe ele pula para o proximo, se a pessoa cancelar ele deleta desta tabela temp, se concluir salvo na tabela tb_pedidos...
GUIMORAES 26/06/2017 09:16:55
#474729
KURTGU,

é melhor você gerar o número após a finalização do pedido, assim você evita de ocorrer as lacunas entre as numerações que não foram utilizadas.
A outra alternativa seria fazer o insert na tabela e reservar a numeração, mas se o pedido não for finalizado, ficará uma lacuna vazia entre a numeração. Ao meu ver, isto não é um problema, pois você pode justificar a ausência da numeração justificando o ocorrido (como por exemplo, por qual motivo o cliente não comprou).
SINCLAIR 26/06/2017 10:00:53
#474733
Colega KURTGU,

Eu, particularmente, faço assim:

1) Se foi confeccionado pedido, obrigatoriamente terá um número, atribuído no final, pode ser por controle de sequence (uso isto no PostGreSQL) ou mesmo através de [Ô]max[Ô] na tabela para pegar o maior número já existente e somar 1.

2) Pedido não concretizado ainda assim é pedido. Se foi transformado em venda é outra questão. Costumo utilizar uma data, hora e ID do usuário que transformou o pedido em venda, além da data, hora e ID de quem criou o pedido. Na verdade são eventos, em tabela separada. Se a data, hora e ID de usuário que transformou em venda estiverem sem preenchimento, é porque não houve transformação do pedido em venda.

Exemplo de tabela auxilar:

tab_eventos_pedidos
data
hora
id_usuário
observacoes
fl_evento (1 - Criação como pedido / 2 - Transformação em venda / 3 - Abandono por parte do cliente / 4 - Empresa não pode atender / 5 - Outros motivos para abandono)

Assim, pela tabela tab_eventos_pedidos consigo saber como está a situação em tab_pedidos (tabela principal).

Uso o conceito de eventos para tudo: contas a pagar/receber, pedidos, logs, cadastro de usuários, cadastro de clientes e fornecedores, etc.

Tudo de bom.
LUIS.HERRERA 26/06/2017 10:43:33
#474734
Kurtgu eu tive problemas com várias formas de implementar isso, principalmente porque meu sistema hoje é multiempresas, então podem existir (n) empresas no mesmo banco e cada uma com todos os dados individuais (funcionários, departamentos, etc...)

Todos os meus controles precisam ter numerações independentes para cada empresa sem lacunas e iniciados por 1 em cada empresa, então para resolver isso, eu criei nestas tabelas 2 campos: um ID Automático e outro IDSequencial onde incremento + 1 a cada novo item. Para que isso funcione é necessário que o ID Automático não seja chave primaria, mas você tem de incluir um outro campo como IDEmpresa ou outro específico que funcionará como Chave dupla junto com o IDSequencia. Assim usei esses dois campos como Chave dupla. Se você tentar incluir um Pedido nessa empresa com mesmo IDSequencia, irá gerar o erro Number == 2627 tratado no Try Catch.

Como funciona a Rotina de Gravar:
1) Faço o Insert já alterando o valor do IDSequencia + 1 na empresa que estou trabalhando,
2) Nesse insert tem um try catch para evitar erro, caso já exista esse ID sequencia (algo meio impossível de ocorrer, pois ele é incrementado na hora, mas fica como segurança
3) Se ocorrer o erro, verifico se é de valor repetidor e refaço o insert em loop.


try
{
string sql = [Ô]INSERT INTO TABELA (campos, IDSequencia, campos) VALUES (@campos, ISNULL((SELECT Max(IDSequencia) FROM TABELA WHERE IDEMPRESA = @IDEMPRESA),0) + 1, @campos); [Ô]
+ [Ô]SELECT CAST(scope_identity() AS int)[Ô];

// ..aqui vem a rotina de passar parâmetros, abrir banco e gravar ...
}
catch (SqlException ex) //erro foi de sequencia já cadastrada por outro usuário (Concorrência na gravação = meio impossível, mas uma precaução extra.)
{
transacao.Rollback();
if (ex.Number == 2627)
{ DeuErroNaInclusao = true; }
else
{
throw;
}
}
catch (Exception)
{
transacao.Rollback();
throw;
}
finally
{ Dados.FecharConexao(); }


Explicando o código do SQL
ISNULL((SELECT Max(IDSequencia) FROM TABELA WHERE IDEMPRESA = @IDEMPRESA),0) + 1
// isso é incluído no Value do campo IDSequencia, assim antes de incluir o SQL pega o maior IDSequencia dessa empresa informada e soma + 1
Se este campo já tiver um valor igual, cai no Try e se for o primeiro registro da tabela inclui 1

+ [Ô]SELECT CAST(scope_identity() AS int)[Ô];
// Essa parte final da SQL irá retornar o ID Automático do registro gravado, caso queira exibir ou fazer outras ações com ele.

Nota: Isso funciona no SQL Server, não sei em outros bancos como seria os correspondentes.

PS: Foi a forma mais prática, fácil, rápida e segura que encontrei.
FOXMAN 26/06/2017 13:02:59
#474739
Seguinte,
Recentemente, criei um novo Frente de Caixa para meu mercado.
E mudei totalmente a metodologia utilizada no controle de Código de pedido.
A ideia é simples, porém não há uma sequencia numérica. Existe porém uma sequencia de pedido.

Cada PDV é nomeado com seu numero de identificação.
PDV1, PDV2, PDV3,PDV4 .... PDVn

A formação do numero do pedido é gerado pelo banco de dados que atribui a data e hora atual , juntando com o nome do pdv.

Ficando assim :

PDV1-26062017085845
PDV1 - Nome do Computador.
26062017 - DATA ATUAL(DATA DA VENDA)
085845 - HORA DA GERACAO DO PEDIDO.

Sendo assim posso ter 2 pedidos com códigos praticamente idênticos, diferenciando apenas o caixa que gerou.

PDV2-26062017090115
PDV1 - Nome do Computador.
26062017 - DATA ATUAL(DATA DA VENDA)
090115 - HORA DA GERACAO DO PEDIDO.

Há casos em que os clientes querem que a numeração seja sequencial, mas como ultimamente somente desenvolvo para meu próprio negócio eu faço da forma que melhor me atende.

Inclusive utilizando dessa forma foi possível localizar uma venda cujo cartão de crédito passou com valor errado. Bastou puxar a hora/min do comprovante do cartão para localizar os cupons equivalentes.




NILSONTRES 26/06/2017 13:57:51
#474741
FOX,
Sua ideia é boa, utilizo para outros tipos de dados como por exemplo ordem de serviço, mas no caso de ser obrigatório o numero sequencial, a melhor forma que encontrei, isso a mais de 10 anos, antes tive problemas, foi a seguinte, uma tabela que incrementa a cada venda um numero, mas isso não é a solução, o problema é que mesmo assim pode haver em milésimos de segundos 2 iguais, o que corrigi isso; é um looping no ato da geração do pedido, onde o campo id é chave primaria e gera um erro ao identificar a duplicidade, então o looping fica até achar um numero valido e ao mesmo tempo acrescentando 1 ao numero, dessa forma nunca ira duplicar.
KURTGU 26/06/2017 14:20:37
#474743
Citação:

:
Seguinte,
Recentemente, criei um novo Frente de Caixa para meu mercado.
E mudei totalmente a metodologia utilizada no controle de Código de pedido.
A ideia é simples, porém não há uma sequencia numérica. Existe porém uma sequencia de pedido.

Cada PDV é nomeado com seu numero de identificação.
PDV1, PDV2, PDV3,PDV4 .... PDVn

A formação do numero do pedido é gerado pelo banco de dados que atribui a data e hora atual , juntando com o nome do pdv.

Ficando assim :

PDV1-26062017085845
PDV1 - Nome do Computador.
26062017 - DATA ATUAL(DATA DA VENDA)
085845 - HORA DA GERACAO DO PEDIDO.

Sendo assim posso ter 2 pedidos com códigos praticamente idênticos, diferenciando apenas o caixa que gerou.

PDV2-26062017090115
PDV1 - Nome do Computador.
26062017 - DATA ATUAL(DATA DA VENDA)
090115 - HORA DA GERACAO DO PEDIDO.

Há casos em que os clientes querem que a numeração seja sequencial, mas como ultimamente somente desenvolvo para meu próprio negócio eu faço da forma que melhor me atende.

Inclusive utilizando dessa forma foi possível localizar uma venda cujo cartão de crédito passou com valor errado. Bastou puxar a hora/min do comprovante do cartão para localizar os cupons equivalentes.






Man boa ideia to lendo todas aqui, mais gostei muito desse sistema...
FOXMAN 28/06/2017 12:02:09
#474826
Citação:

:
FOX,
Sua ideia é boa, utilizo para outros tipos de dados como por exemplo ordem de serviço, mas no caso de ser obrigatório o numero sequencial, a melhor forma que encontrei, isso a mais de 10 anos, antes tive problemas, foi a seguinte, uma tabela que incrementa a cada venda um numero, mas isso não é a solução, o problema é que mesmo assim pode haver em milésimos de segundos 2 iguais, o que corrigi isso; é um looping no ato da geração do pedido, onde o campo id é chave primaria e gera um erro ao identificar a duplicidade, então o looping fica até achar um numero valido e ao mesmo tempo acrescentando 1 ao numero, dessa forma nunca ira duplicar.


Eu já utilizei sequencial, e no meu Retaguarda ainda é utilizado a metodologia anterior.

No meu caso, eu tenho uma tabela sequencia(tblSequencial) que faz a gestão/controle de todos os códigos que o sistema necessita para seu funcionamento.
na tabela sequencial eu tenho por exemplo IDPEDIDO, IDPDV,IDNF,IDPESSOA. Nunca tive problemas com duplicidade, no entanto já houve quebra de sequencia por conta de um pedido estar sendo digitado, e não concluído(como por exemplo a desistência do cliente).

Eu particularmente estou abolindo sequenciais, pois não há mais tanta necessidade (no meu caso/ponto de vista) de se controlar algo por sequencial sabendo que temos o DateTime a nosso favor.

Mas como eu disse : NO MEU PONTO DE VISTA e diante da MINHA NECESSIDADE.
Cada um é cada um.....
Página 1 de 2 [13 registro(s)]
Faça seu login para responder