PC Toledo

Pessoal,

tenho alguns clientes que são supermercados e como todos sabem nesse ramo de atividade o cliente compra por caixa, por exemplo, mas vende na unidade. Então, em vez de o cliente dar entrada no estoque em uma caixa de leite ninho, ele dá entrada em 24 latas de leite ninho, que é a qtde que vem numa caixa e é como o cliente vende. Até aí, blz. Ocorre que como o cliente compra de atacadistas, nas notas fiscais não vem unidade, mas em cx, sacos, etc... sendo necessário o cliente ficar fazendo essa transformação todas as vezes no ato do lançamento da nota fiscal de entrada, tando quanto a quantidade, como no preço do produto, que vem em caixa também, não em unidade.

Pensei em colocar no cadastro de produtos um campo para UNIDADE DE VENDA e outro para UNIDADE DE COMPRA, nesse caso, se o cliente vende em unidade, mas compra em caixa, colocaria um indice de transformação de caixa para unidade, de modo que na entrada da nota fiscal, o cliente lançaria do mesmo modo como consta na nf, mas o sistema se encarregaria de ao gravar os dados, gravá-los já com as devidas transformações. Até ae também blz.

Ocorre que como tenho que gerar um arquivo sintegra, fiquei pensando se isso pode dar algum problema na geração desse arquivo, visto que na ENTRADA terei produtos de um jeito, e na SAÍDA, de outro.

Como vcs tratam esses casos?

Janio

Olá Combatente,
a maneira mais prática que já vi para essa situação é colocar um campo para indicar o fator de conversão.
Exemplo:
Leite ninho adquirido em caixas com 24 e vendido em unidades.
O fator é 0,04 ou seja, 1 dividido por 24, igual a 0,0416666...
Muito embora o cumpom indique uma unidade, considerando o campo fator, o estoque vai ser convenientemente tratado deduzindo-se o total de 0,04 da quantidade em caixa.

Espero ter ajudado.

MarceloG

Pessoal,

preciso de mais opiniões. Preciso implementar esta regra com urgência, mas preciso encontrar a melhor maneira de tratar esta questao.

Janio

Amiguinho,

Como o MARCELOG não deu uma indicação prática eu também não entendi direito como ele usa.

Mas no meu caso em meu arquivo de estoque tenho campos unidade e mascara onde armazeno a unidade principal de entrada a mascara usada nos gets e unidade2 e mascara2 para salvar a unidade extra de saida e mascara utilizada, e por final um campo rendimento onde guardo o meu fator, exemplo:

- cliente comprou um rolo de tecido de 70 metros linear por R$ 500,00. Ao lançar o sistema receberá unidade=RL, rendimento=70 e custo unitario=500,00
- se cliente vender por unidade, venderá então por RL-rolo(campo unidade), ou seja, 1 rolo de 500,00 assumindo que vendeu pelo que pagou
- se cliente vender por MT-metro(campo unidade2), ai o campo rendimento trará o valor do metro, ou seja, R$500,00/70MT=R$7,14 o metro

Neste caso não exemplifiquei outras figuras que complicam o movimento do estoque relativo as quantidades, pois a cada metro vendido, deverá ser baixado de um campo no estoque até que chegue ao total de rendimento para então baixar um rolo inteiro. Fui claro.

Comprou um rolo, vendeu um rolo baixou o estoque, zerou, acabou.
ou
Comprou um rolo, vendeu 20 metros, baixou do estoque, sobram 50 metros e 1 rolo, ao vender o restante dos metros, baixa-se também o rolo.

No momento da venda meu cliente escolhe uma das duas medidas cadastradas para o item.

Vale tambem criticar a possibilidade da utilização da medida na venda e sua critica, ou seja, se no momento da venda quer se vender 1 rolo, mas não se tem ele inteiro, critica, trava e só vende pelo segunda medida, metros.

Se o item ainda puder ser vendido por uma terceira medida ai cabe encontrar a forma de dinamizar o processo. Exemplo drástico: compra-se barril e vende-se, por lastas e galões de diferentes tamanhos.

Ai haja dinamismo.

Falei de mascara pois no momento de movimentar o item eu não quero que apareça virgulas num campo onde só posso colocar inteiros, pois ficaria confuso. então tenho em minha tabela de medidas alguns campos de suporte como:

IDMEDIDA - Campo com sigla da medida(KG, MT, RL, M2, M3, ETC)
UNIDADE - Nome da unidade(KILO, METRO, ROLO, METRO QUADRADO, METRO CUBICO, etc) lembrando que UN não é elemento e sim um grupo, usamos por preguiça.
MASCARA - Para Kilo uso @E 99999.999, para Metros uso @E 999999.99 e para rolo/peça uso @E 999999999

Os outros campos de suporte que uso nesta tabela são COMPRIMENTO, LARGURA e ALTURA, pois no momento de calcular a segunda unidade posso usa-los, exemplo:

Saida por M2-metro quadrado calcularei por COMPRIMENTO, LARGURA
Saida por M3-metro cubico calcularei por COMPRIMENTO, LARGURA e ALTURA

No momento de sua escolha habilito campos para permitir a entrada destas caracteristicas.

As medidas M2 e M3 são usadas quando o cliente compra chapas e bloco(respectivamente) e vendem em pequenas peças com as medidas manipuladas por COMPRIMENTO, LARGURA e ALTURA.

Estendi demais a resposta, mas espero ter dado uma alusão ou idéia do que fazer neste caso.

Tudo isto, lógico, sem desmerecer a colocação do colega MARCELOG.

http://www.5volution.com.br/downloads/forum/unidades.zip

Olá companheiros, eu não utilizo esse procedimento em meus sistemas.

Todavia, analisando códigos e mais códigos, a técnica anteriormente informada, no meu modesto entendimento, foi a de mais fácil compreensão e implantação.

No cadastro de produtos criam-se campos para conter o fator de conversão de compra e venda.

Sendo necessário, crie campos para as unidades de compra e venda (Santo, mas precioso, Perfeccionismo!)

Assim, se o cliente compra e vende na mesma unidade o fator é 1.

Se o cliente compra em unidades diferentes, o fator vai depender da quantidade de unidades envolvidas.

Exemplo:

compra un - vende un = fator de compra 1 - fator de venda 1
Na entrada, cada quantidade é multiplicada por 1.
Na saída, cada quantidade é multiplicada por 1.

compra cx c/24 - vende un = fator de compra 24 - fator de venda 1
Na entrada, cada quantidade é multiplicada por 24.
Na saída, cada quantidade é multiplicada por 1.

compra un - vende cx c/24 = fator de compra 1 - fator de venda 24
Na entrada, cada quantidade é multiplicada por 1.
Na saída, cada quantidade é multiplicada por 24.

Isso é o básico, considerando que o destinatário do sistema queira controlar o estoque pelas unidades de venda.

Se quiser controlar o estoque pelas unidades de compra, mais adequada para a fiscalização, auditoria, etc. é só inverter os procedimentos anteriormente informados ou criar um relatório para conveter as unidades em estoque pelos fatores de compra.

Nesse caso, por exemplo, havendo 24 un de um produto que é adquirido em caixas com 24 un, o relatório apresentará o saldo de 1 cx (24 : Fator(24) = 1).

Espero ter ajudado.

MarceloG

Amiguinhos,

Agora entendi seu esquema de fator.

No meu caso eu não conseguiria porque com a integração com as nfe-s de fornecedores um mesmo produto tinha variações de rendimento e eu precisava controlar o rendimento também ou o mesmo produto muitas vezes vinha na nf-e em formato bruto, exemplo bloco ou em pequenas peças.

Na hora de lançar no estoque o usuário se confundia e muitas vezes lançava 500 peças ao inves de 500 blocos e o estoque fica com 25000 peças e ai sobrava pra mim.

No caso de se usar mais de uma unidade no movimento de saida ao agilizar este recurso na entrada facilitamos em muito a nossa vida, seja usando fatores ou controle de rendimentos.

Janio, eu faco assim:

No cadastro do produto defino qual a unidade que o produto tem para compra e venda, se elas forem diferentes, solicito que indique o fator, o fator é relativo a quantidade que vem na caixa.

Na venda, sempre vendo pela menor unidade e na reposicao (entrada em estoque, compra) na hora de indicar o produto, os que tem fator maior que 1, pedem para o usuario indicar se a quantidade é cheia ( unidade de compra) ou minima ( unidade vendida )

Exemplo

CADASTRO DO PRODUTO
Unid. de Compra: UN
Unid. de Venda..: UN
Fator: 1
ou
Unid. de Compra: RL
Unid. de Venda..: MT
Fator: 70

Na Compra se o fator for maior que 1 pede para o usuario indicar qual unidad usar

Qtd.Entrada: 10 [1]=RL [2]=MT ---> Opcao:

Se escolher 1, o sistema add ao estoque 70mt se for escolhida a opcao 2, o sistema add 1MT.

Bom, espero ter contribuido para aumentar suas duvidas, rs.
Ate+

Colegas,

Estou planejando fazer mais ou menos como os colegas indicaram, ou seja:

Exemplo:

Compra cx c/24, mas vende unitario, entao FATOR DE CONVERSAO é igual a 24.
Na entrada, cada quantidade é multiplicada por 24.
Na saída, cada quantidade é multiplicada por 1.

Então, se o cliente compra 50 cxa de leite ninho, no seu estoque entrará 50 x 24 = 1200 latas (que é a unidade de venda que o cliente utiliza).

Resumindo:
Na entrada terei 50 caixas, mas
No estoque do produto teria 1200 latas

Até aí, filé!

Pq ainda não fiz isso?

Pq como tenho que gerar o arquivo do sintegra, neste bendito arquivo só há lugar para colocar uma UNIDADE por produto. Como nesse caso eu vou utilizar DUAS UNIDADES (uma para compra e uma para venda), nesse caso não sei qual das duas tenho que colocar no arq do sintegra.

O registro 54 do sintegra são os produtos constantes nas nf's de entrada (compra)
O registro 60i do sintegra são os itens (produtos) constantes em cada cupom fiscal (saída)

No registro 75 devemos colocar todos os produtos que tiveram movimentacao tanto na ENTRADA quanto na SAIDA.

Olá Janio,

No caso do sintegra, para os registros de compra, talvez (se for possivel) converta a unidade comprada para a unidade usada na venda. Tipo se na nota de compra esta 1 CX e esta tem 24, no registro do sintegra, poderia referenciar com 24 UN ou não? Estas 24 UN sera resultado do calculo do seu sistema usando o fator do produto. Acho assim melhor que fazer o contrario, tipo 1 CX para compra e venda de 1 UN , voce lancar 0,041.

Ate+

Amiguinhos,

Nos registros do SINTEGRA relativos a compra não será preciso converter pois a relação entre este registro e o combate de informações se dará pelo nota fiscal ou NFe relacionada.

O Registro 75 solicita apenas a unidade de comercialização e nãoa quantidade portanto o SINTEGRA nao ira apresentar a movimentação por quantidades e sim por operação.