ProcessoCompras

De Stoq Wiki
Ir para: navegação, pesquisa

=== Cadastro de produtos

=

O cadastro de produtos deverá ser completo e oferecer suporte ao cadastro dos itens: - custo bruto - descontos - ICMS (este não influi no custo líquido) - diferença ICMS - frete - IPI - custo líquido sendo que a diferença de ICMS entre a taxa destacada pela empresa e a taxa destacada pelo produto deverá ser considerada no cálculo do custo líquido do produto.

Também deveremos oferecer uma opção parametrizada para registrarmos sempre um histórico contendo todas as alterações nos campos de valores da ficha de um produto. Isto ajudará o comprador no momento em que este precisar de fazer alguma avaliação baseada em um preço antigo de um produto ou mesmo fazer alguma previsão futura baseado na média de variação do passado.

=== Processo global de uma compra

=

O processo global de uma compra envolve as seguintes etapas:

[1]

=== Detalhes do processo de uma compra

=

Teremos a possibilidade da criação direta de um pedido de compra ou uma cotação. Uma cotação, em seu aspecto mais básico, seria uma compra com um status especial, que a identifica como uma cotação, isto é, um possível pedido de compra. Quando confirmada, uma cotação se torna um pedido de compra e ficará no aguardo da confirmação da compra.

 - Um orçamento será uma compra com status especial: ORDER_QUOTING.
 - A deleção de cotações antigas (e não utilizadas) deve ser parametrizada, o motivo para isto é que algumas empresas necessitam de todas as cotações por motivos de histórico enquanto outras não precisam.
 - As interfaces para cadastro de compras/cotações serão as mesmas e só permitirão a especificação de um único fornecedor por cadastro.
 - A aplicação purchase será responsável pelo cadastro de produtos, que deverá ser completo, isto é, possuir todos os campos para preenchimento de todos os atributos que o objeto produto deve possuir, com a observação de que somente campos básicos devem ser obrigatórios, permitindo assim, indiretamente, um cadastro "simples" e um cadastro completo na mesma interface.
- No cadastro de compras, deve ser possível especificar os seguintes dados: Tipo de Frete (FOB/CIF), Valor do Frete, IPI, ICMS e Descontos, sendo todos estes dados em porcentagem.
 - A aplicação purchase deve possuir um "link" para o cadastro de serviços. A razão disto é que possibilitaremos que o próprio comprador seja também o responsável pela contratação de serviços terceirizados ou mesmo definição dos preços dos serviços executados pela própria empresa.
 - Durante o cadastro de novas compras, a interface deve permitir a alteração do preço de cada produto inserido na lista de compra, isto é, cada item da lista deve ser (ou deve possuir) uma referência ao objeto Product e, a alteração do valor do item na interface, refletirá no objeto. No caso do cadastro de cotações, a alteração do valor de um item da lista não refletirá de forma alguma o objeto Product à qual ele se refere, e sim à um objeto que representará um item de cotação.


=== Estados de uma compra

=

  • Orçamento(ORDER_QUOTING)
  • Compra pendente(ORDER_PENDING)
  • Compra confirmada(ORDER_CONFIRMED)
  • Compra Fechada(ORDER_CLOSED)
  • Compra Cancelada(ORDER_CANCELLED)

=== Auxílio no processo de decisão

=

É de suma importância para o comprador de uma empresa se dispor de uma ferramenta para auxílio durante o processo de decisão de uma compra. Este processo de decisão constitui-se dos seguintes parâmetros a saber:

  • Prazo de pagamento
  • Prazo de entrega
  • Grau de pontualidade do fornecedor
  • Preço dos produtos
  • Qualidade dos produtos

Dos parâmetros acima tenho dúvidas relacionadas a implementação dos seguintes itens: - Grau de pontualidade - penso em fornecer uma interface ao usuário de forma a categorizar os atrasos de fornecedores. Teríamos então dois parâmetros para isso: o número de dias de atraso e uma descrição para esse valor, 'satisfatório', 'insatisfatório' ou 'regular' por exemplo. No ato do recebimento de compra iriamos sempre comparar a data do recebimento com a data do pedido e o prazo de entrega. Havendo atraso iriamos então marcar na ficha do fornecedor um status de pontualidade de acordo com os parâmetros previamente estabelecidos pela direção.

- Qualidade dos produtos - Uma vez definidos os possíveis graus de qualidade permitidos para um produto('ruim', 'regular', 'médio', 'bom', 'excelente' por exemplo), poderíamos avaliar isso de duas formas:

 * A própria direção iria atribuir estas definições aos produtos já cadastrados no sistema baseando-se em um conhecimento prévio junto aos mesmos.
 * Definiríamos automaticamente a qualidade de um produto baseado no número de reclamações. Para isso teríamos também de permitir a direção categorizar um número máximo de reclamações para cada definição de qualidade e associar um determinado serviço ou vários serviços como decorrentes de falha no produto. A partir daí teríamos apenas de criar um atributo "contador" na ficha de cada produto. A cada assistência técnica para o mesmo estariamos incrementando este campo e automaticamente setando seu atributo "qualidade" baseado no conteúdo do campo incrementado. É claro que deveríamos também permitir a gerência alterar o grau de qualidade de um produto manualmente pois é frequente que produtos antes tidos como ruins recebam uma reformulação do fornecedor e se tornem depois produtos de qualidade.

XXX: Penso que o ideal seja fornecer um parâmetro na aplicação admin de forma que a direção da empresa decida como operar diante das idéias propostas no último item "qualidade dos produtos".

Em geral, ao avaliar um conjunto de cotações um comprador executa as seguintes perguntas:

  • Qual fornecedor me oferece o produto com a qualidade desejada e com o preço desejado ?
  • O prazo de pagamento se adequada a minha realidade financeira ?
  • O produto chegará em tempo hábil a fim de suprir o meu estoque?

Para atender a tais necessidades precisaríamos fornecer uma interface que permitisse, a partir da análise dos requisitos expostos, gerar pedidos de compra a partir das cotações ideais. Esta interface deveria oferecer as seguintes opções de pesquisa: produto, fornecedor, prazo de pagamento, faixa de preço bruto, faixa de preço líquido, prazo de entrega, qualidade e pontualidade do fornecedor. O comprador poderá então selecionar os produtos desejados e, a partir daí, lançar um pedido de compra que conterá os mesmos.

=== Recebimento de compra

=

 - Durante o recebimento de produtos, a alteração dos valores de impostos, assim como o valor da compra em si não serão passíveis de alteração (por padrão), mas poderão ser parametrizados pela aplicação de administração para permitir esta característica. No caso destas alterações ocorrem, os novos valores definidos serão vinculados à nota fiscal, permitindo assim que se mantenha (por motivo histórico) os valores originais estabelecidos.
 - O sistema deve incluir suporte à combinação de múltiplas requisições de compras (cotações) em um simples pedido de compra, desde que seus fornecedores sejam os mesmos.
 - Recebimento de produtos sem pedidos de compras não devem ser permitidos. Nos casos onde isto é necessário, a aplicação deve permitir ao usuário cadastrar um novo pedido e definí-lo como "Pronta-Entrega". Quando isto for feito, no final do cadastro do pedido a interface de recebimento de produtos será aberta automaticamente já com o pedido selecionado para recebimento, cabendo ao usuário finalizar o processo.

=== Destino de compra

=

O destino de uma compra é o local para onde estamos enviando os produtos adquiridos. em síntese, será a empresa na qual deveremos creditar os produtos no saldo de estoque

 - O destino de uma compra será especificado somente no cadastro da mesma, não sendo, portanto alterável após a situação da compra ser igual a confirmado(ORDER_CONFIRMED).
 - Haverá sempre um único destino para cada compra.
 - Destino de compras irá se referir à compra inteira e não à itens da compra.

=== Qual será o conteúdo do atributo "origem" para os pagamentos que forem gerados após o recebimento de uma compra ou após a confirmação de uma compra com pagamento antecipado ?

=

Na aplicação admin permitiremos configurar uma conta destino padrão para todos os pagamentos gerados pelas aplicações purchase/warehouse. Se este parâmetro não estiver setado usaremos sempre as contas-correntes associadas a cada empresa. Vide app financial - contas correntes/caixa.

=== Lançamento no contas a pagar

=

O processo normal de uma compra não envolve a emissão de lançamentos no contas a pagar. Ao cadastrar uma compra definimos o fornecedor, o prazo de entrega e de pagamento, os produtos, impostos e taxas que pagaremos no recebimento. Sendo assim, em geral uma compra apenas nos estabelece uma regra de como deverá chegar a nota fiscal no momento do recebimento e, uma vez estando nesta etapa, iremos lançar o respectivo CP.

Há porém uma excessão a esta regra: compras cujo pagamento é antecipado. Trataremos este caso através da inserção de um atributo extra denominado "ispaid" na classe PurchaseOrder e que representará uma compra paga antecipadamente. Uma vez que o usuário setar este atributo através da interface de compras estaremos exibindo uma interface genérica de emissão de contas a pagar onde o mesmo poderá setar adequadamente os vencimentos e os valores das parcelas. Só iremos permitir o lançamento de contas a pagar no recebimento de compra para os pedidos cujo atributo "ispaid" for igual a falso.

Deverá haver um parâmetro que permitirá a gerência da empresa definir se poderemos ou não alterar os valores e vencimentos das parcelas durante o recebimento de uma compra. Não podendo, iremos gerar os valores e vencimentos das parcelas automaticamente e ficará a cargo do financeiro corrigir eventuais diferenças.

=== Transportadoras e fornecedores

=

 - Cadastro de fornecedores será idêntico ao da Consave. O Cadastro de transportadoras será idêntico ao cadastro de fornecedores, mas não deverá exibir campo para cadastro de produtos fornecidos.

=== Preço de Promoção para Produtos

=

Um preço de promoção, uma vez definido para um produto, substituirá sempre o preço de venda normal do mesmo, sendo este o preço a ser sugerido ao vendedor no momento da venda de um produto.

Na interface para cadastro de produtos, devemos possibilitar ao usuário o cadastro de preços promocionais referentes à determinados períodos. Baseado no preço promocional cadastrado e no preço do produto, será gerada uma taxa de markup. Tais dados sobre preço promocial serão gravados em um objeto à parte que conterá somente os atributos: - "data de cadastro" - "taxa de markup", baseado no preço promocional entrado e no preço de custo do produto - "data de validade" referente ao período no qual esse preço é válido

Deve ser parametrizado também a alteração de preços promocionais durante o ato de venda. Como acreditamos que isto será uma ação rara, por padrão a alteração de preços promocionais não será permitida durante uma compra.

_Nota-se aqui que propositalmente não teremos um campo "valor do preço de promoção" a ser persistido. A razão para isso é que o preço de promoção é baseado no preço de venda e este por sua vez pode ser alterado a qualquer momento. Sendo assim , o que interessa no momento de elaborarmos um preço de promoção é a taxa de markup desejada pelo comprador/equipe de vendas e calcularemos o preço de promoção sempre em tempo de execução._