Estratégia 40 - Planejamento com Montagem Final

Provavelmente a estratégia MAKE TO STOCK mais utilizada. 
Faz sentido utilizar essa estratégia de planejamento quando é possível prever as quantidades de produção para o produto final.
As necessidades independentes previstas (PIR) são consumidas por entradas de ordens de cliente; assim, o plano mestre é sempre ajustado para atender à situação das necessidades atuais.

Selecione o Grupo de Estrategias 40




Inicialmente temos um estoque de 15 pc



Vamos fazer um Planejamento de Necessidades Independentes para 6 meses daqui a 6 meses , podemos ver que o tipo da necessidade esta como VSF (Planning with final assembly)





Consultando a MD04 já podemos ver o PIR ( Necessidade Independente)


Executando o MRP



Clicar em Materials



O Planejamento é exibido, vamos verificar a Disponibilidade do Material R-F218




Como podemos conferir o MRP fez todo o planejamento para atender as Necessidades



Agora vamos fazer uma Ordem de Venda simulada de 10 peças na Gestão da Demanda
Vamos apontar essa OV 4 dias uteis após o primeiro PIR. Reparem no Tipo da Necessidade KSV(Sales Order with Consumption)




Na Lista Atual de Estoques/Necessidades podemos verificar que a Ordem de Vendas já aparece (CusReq) e que a Ordem de Venda  nessa Estrategia 40 já é relevante no Planejamento

Estratégia 10 Make-to-Stock com Ordem de Venda

Na Estratégia 10 as Ordens não são levadas em Conta. A Gestão da Demanda é feita através de Necessidades Planejadas Independentes (PIR). Porem as Ordens de Venda podem consumir o Customer Requirement.

--inicialmente o Produto deve estar com a Estrategia 10 setada   MM03




-- Preparei um Estoque inicial de 25 Peças      MD04




--Vamos planejar necessidades semanais de 25 Pc por semana durante 3 semanas
--Devido a Estratégia este é uma Necessidade tipo LSF (Make to Stock Production)    MD61



Vamos rodar o MRP e na olhar    MD02



Podemos ver que as Necessidades aparecem nas datas programas e o MRP criou Ordens Planejadas para atender as Necessidades Independentes



Agora vamos criar uma Necessidade do Cliente e ver o que acontece no MRP. O tipo de Necessidade é o KSL                          MD81




Consultando na MD04 podemos verificar que Aparece a ‘Customer Requirement’  que criamos acima , porém está aparecendo apenas para conferencia, o mesmo não afetou em nada os calculos



Agora vamos consumir Estoque para a Necessidade do cliente




Verificando agora , nossa Necessidade do Cliente consumiu as 5 peças apontadas, diminuindo o estoque (15 peças agora ) e  a Necessidade do Cliente para 15 peças 


Com isso foi demonstrado que apesar da Estrategia 10 ser Make to Stock, podemos exibir as Ordens de Venda (CusReq) sem que as mesmas interfiram no Planejamento e podemos consumir as quantidade em estoque para as Ordens de Venda que vai entrar no MRP.

Não execute uma Instrução DDL quando tiver Transação DML em andamento na sessão

Pode ser desastroso, pois ddls possuem commit implícito. Por esta razão , commit , rollback , savepoint não podem ser usados em ddls. Vamos fazer um teste.

-- criando a tabela t

9.2>create table t (data date) ;
Table created.

-- populando alguns dados na tabela

9.2>insert into t values (sysdate ) ;
1 row created.
9.2>insert into t values (sysdate + .04166);
1 row created.
9.2>insert into t values (sysdate + 2* (.04166) ) ;
1 row created.
9.2>select * from t ;

-- consultando
9.2>select * from t ;
DATA---------
17-DEC-08
17-DEC-08
17-DEC-08

--vamos colocar um inocente comentario na tabela

9.2>comment on table t is 'tabela para testar commit implicito';
Comment created.

--decidi que o insert não é mais necessário , então vou fazer um rollback

9.2>rollback;
Rollback complete.

-- consultando novamente a tabela não pode ter mais nada nela , certo?

9.2>select * from t ;
DATA---------
17-DEC-08
17-DEC-08
17-DEC-08

Apesar do rollback o commit foi efetuado pelo COMMENT. Qualquer ddl faz isto. Portanto muito cuidado. 

Via de Regra, se precisa fazer algum DDL , faça antes de iniciar uma transação -- SEMPRE --. O exemplo acima pode não ser comum, mas não é raro em triggers ter algum DDL chamado por um execute immediate, e neste caso a transação que disparou a trigger vai commitar implicitamente mesmo que mais adiante ocorra um erro.