ER_MANCORE1-132_Apontamentos

(Obrigatório)

Informações Gerais

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

(Obrigatório)

Objetivo

Alterar  rotinas para realizar o processamento dos apontamentos de produção realizados pelo PC-Factory no Protheus, considerando o consumo dos componentes, refugo e informações do chão de fábrica.

(Obrigatório)

Definição da Regra de Negócio

 Será usada a mensagem de apontamento de produção ProductionAppointment_1_001. Serão lidos os campos da sessão  ListOfSUpplyOrders, ListOfWasteAppointments, ListOfResourceAppointments e ListOfReportToolActivities,  e campos relacionados ao SIGASFC. O uso do chão de fábrica não é obrigatório e serão atualizados somente se o parâmetro MV_INTSFC for igual a '1'.

O Webservice (WSPCP) não necessita ser alterado para a leitura destas informações. A geração da mensagem pelo PC-Factory deve continuar da mesma forma, porém, considerando os novos campos:

Dentro do BusinessMessage existe o bloco BusinessContentType, que contém os dados do apontamento.  

A mensagem possui vários tags, porém serão descritas somente as tags usadas na integração com o PCFactory. 

Abaixo segue mensagem( incluída a coluna Fase, onde fase 1 já desenvolvido e fase 2 é o que será desenvolvido): 

Quando o PC Factory for o produto gerador da informação no caso do reporte de produção o fluxo da integração será o seguinte: 

a. Operador efetua reporte normalmente conforme sua operação no PC-Facotry. 

b. Em um processo batch ou disparado paralelamente no sistema, há a montagem do XML conforme XML Schema de Mensagem Única TOTVS e o envio desse XML para o ERP TOTVS, que validará o XML contra o XSD e encaminhará ao respectivo adapter de negócio para processamento. 

c. Em caso de erros, esse reporte ficará com um status de pendente para envio dentro do software MES e o usuário poderá tomar ações no próprio PC Factory (o ERP TOTVS não manterá rastreabilidade das mensagens recebidas).

O que será desenvolvido:

1.  Tratar o consumo dos componentes,  considerar os novos campos da fase 2 e também considerar o SIGASFC alterando o adapter  MATI681.

1.1 Consumo dos componentes

O consumo dos componentes é válido na fase 2 da integração, porém deverá respeitar parametrização do PCPA109. Na rotina de parâmetros será definido como será o tratamento do consumo dos componentes.

Deverá verificar o conteúdo o campo SOE.OE_VAR1, quando a tabela(OE_TABELA) for SC2. Este campo pode conter os seguintes valores:

"1" - BackFlush: Sempre irá realizar a baixa dos componentes conforme o definido na engenharia. Desconsidera a lista de consumo SupplyOrder. (FASE1)

"2" - Consumo Real: Irá consumir conforme lista de componentes, SupplyOrder, enviada na mensagem. (FASE2)

Abaixo alterações necessárias para atender o processo quando o parâmetro estiver como '2'.

Alterar o MATA681 para validar se está executando via integração com o PC-FACTORY no momento de fazer as baixas. Deve ser feita essa validação pois ao executar a função de baixa A250Atu não deverá baixar conforme os dados da SD4 e sim os componentes que foram enviados na mensagem. A baixa é feita com base na variável aBaixaComp, sendo que, quando estiver nula a rotina baixa conforme a SD4. Para a integração e com consumo real, deverá gerar esse array conforme a lista de componentes que forem enviadas pelo PC-Factory antes de executar a função A250Atu. Quando parametrizado para o consumo real e não existindo informações na lista de componentes, SupplyOrder, não deverá fazer o backflush. Também deverá aceitar apontamento de produção com quantidade zerada e somente a lista de componentes, SupplyOrder, só que deverá ter o tempo informado.

Usar os campos abaixo:

No consumo dos componentes o processo deverá seguir a seguinte regra, conforme parametrização:
Caso o parâmetro MV_REQAUT estiver como 'D' os materiais DIRETOS serão digitados e os INDIRETOS serão baixados automaticamente.
Caso o parâmetro MV_REQAUT estiver como 'A' o consumo dos materiais será realizado para todos os componentes.

Obs.: Esta informação é relevante, pois se o PC-FACTORY enviar na mensagem de apontamento um componente com apropriação DIRETA e o parâmetro estiver como 'D' a baixa não será realizada.

          Para baixar os Indiretos o tipo de movimento deve ter o campo "Aprop. Indir" como "S' na rotina MATA230.

Na mensagem de existe o campo REQUESTTYPE: Identifica se a requisição pode ser feita separadamente do reporte da produção.
Protheus - identifica o tipo de apropriação do componente (1-Direta, 2-Indireta)

As maioria das regras definidas na fase 1 continuam inalteradas:

• Os campos Máquina,Ordem de Produção,Operação,Produto e Data/Hora Reporte serão obrigatórios.

• Caso o campo código do depósito vier sem preenchimento deverá usar o local padrão do cadastro de item(SB1.B1_LOCPAD).

• Se precisar fazer alguma validação deverá usar o ponto de entrada MT680VAL. Ponto de entrada útil para validar se alguma informação deverá ser obrigatória como tempo , quantidade, entre outros. Estas validações ficarão a cargo dos clientes, pois cada um terá sua regra. 

• O campo CloseOperation vai indicar se o apontamento é TOTAL ou PARCIAL. Caso envie true deverá ser T=total. Caso false será considerado como P=Parcial.

• Quando for apontamento quantidade/tempo/recurso o SH6.H6_TIPO = 'P'.

• Como o padrão é MATA681, se precisar validar informações do carga máquina na tabela SH8, deverá usar o ponto de entrada MT680VAL.

  Regras novas

  
  

• Será considerada a operação que vier informada BusinessContentType

• Se estiver parametrizado para BackFlush não deverá considerar a lista de componentes SupplyOrder.

• Gravar o campo SH6.H6_OBSERVA como 'TOTVSMES'. Atualmente grava "PPI"

• Deverá considerar o tipo de movimento do cadastro de parâmetros PCPA109, folder MOVIMENTAÇÕES. Se for Entrada usar o campo OE_VAR1. Se for Saída usar o campo OE_VAR2. Quando usa o chão de fábrica, deverá usar as movimentações parametrizadas no SIGASFC (MV_SFRQMB e MV_TMPAD).

• No PC-Factory, não é utilizado lote e número de série ao mesmo tempo. O retorno desse conteúdo será via tag SupplyOrder - LotCode, que pode ser o Lote ou número de série, conforme o cadastro do item.

• Quando o item controlar endereço deverá validar a geração da tabela SDB.

A mensagem de retorno deve continuar sendo executada da mesma forma.

Os estornos dos apontamentos deverão seguir o modelo atual, enviando o campo ReversedReport, sem necessidade de enviar lista de componentes. 

As demais Tags serão verificadas somente quando usar o chão de fábrica.

1.2 Chão de Fábrica

Quando usa o SIGASFC, MV_INTSFC =1, fará o mesmo processo do apontamento de produção, porém gerando as tabelas do chão de fábrica.

Será usado como base o processo do apontamento  modelo 2 , SFCA316.

Alterações:

1.2.1 Adapter MATI681

Alterar adapter de apontamento de produção para validar se existe integração com SFC.

O Adapter fará a leitura do XML para gerar os dados que serão passados automaticamente para a rotina de apontamento SFCA314. Se estiver usando o chão de fábrica(<IF MV_INTSFC = '1' THEN >) ira gerar os dados correspondes da rotina SFCA314. O XML contém inúmeros campos, porém, para a integração Protheus com o PC-Factory vamos usar somente os descritos na tabela da mensagem do apontamento.

Pode usar como modelo o ACDV314 para executar rotina do chão de fábrica.

Exemplo:

// Instancia o modelo
oModel := FWLoadModel( "SFCA314" )
oModel:SetOperation( 3 ) //incluir apontamento

oModel:SetValue("CYVMASTER","CYV_NRORPO",CZH->CZH_NRORPO)
oModel:SetValue("CYVMASTER","CYV_IDAT" ,CZH->CZH_IDAT)
oModel:SetValue("CYVMASTER","CYV_IDATQO",CZH->CZH_IDATQO)
oModel:SetValue("CYVMASTER","CYV_CDMQ" ,CZH->CZH_CDMQ)

....

...

// Valida o modelo
If oModel:VldData()
VtClear()
If !oModel:CommitData()
Return .F.
EndIf
Else
VtClear()
aErro := oModel:GetErrorMessage()
VTAlert(AllTrim(STR0010)+": "+oModel:GetErrorMessage()[6], oModel:GetErrorMessage()[5])
Return .F.
EndIf

Deverá fazer o SetValue nas seguintes tabelas: CYV,CZP,CYO,CYW,CZO ( os valores vem do XML, vide tabela de apontamentos). Ao executar o SFCA314 já irá atualizar automaticamente as tabelas do PCP, pois faz o exectAuto do MATA681: msExecAuto({|x,y| MATA681(x,y)},aMata681,3).

Onde( ver na tabela a origem de cada campo):
CYV - Tabela principal do apontamento
CZP - Componentes ( considerar o parâmetro - BackFlush ou Consumo Real)
CYO - Refugo
CYW - Recursos
CZO - Ferramentas

ATENÇÃO: As tabelas geradas automáticas no SFCA314, como por exemplo a tabela de componentes CZP, deverão ser geradas conforme a mensagem, no caso da parametrização CONSUMO REAL. Quando for BackFlush será desconsiderado o que estiver na mensagem XML.

ATENÇÃO: As outras tabelas como recurso (CYW) e ferramenta(CZO) deve respeitar o que está na mensagem.

O Adapter fará as seguintes validações antes de executar a rotina de apontamento.

• Irá validar se a mensagem é ProductionAppointment.
• Irá validar se a versão é 1.001
• Quando o nome do produto(Product: Name) for PPI, deverá verificar se a integração Protheus x PC-Factory está ativa(SOD.OD_ATIVO). Somente processar se estiver ativa, senão irá dar mensagem que a integração não foi realizada.
• Quando as tags CompanyId e BranchId não forem enviados pelo XML será utilizado o que estiver registrados nos parâmetros de configuração(appserver.ini) na configuração do WEBSERVICE. Abaixo exemplo no campo PREPAREIN.

             [WebServices]

              Enable=1

              Environment=p12_gestao

              Conout=1

              Trace=1

         PrepareIn=99,01

              NameSpace=http://10.80.62.136:8090

              URLLocation=http://10.80.62.136

              Mais detalhes sobre a configuração do appserver.ini WEBSERVICE deverá ser verificado no manual de instalação.

Algumas regras para o chão de fábrica:

• Quantidade reportada CYV_QTATRP, será a soma das quantidades aprovadas e refugadas.
• Data/Hora Início e Fim e código da Preparação apesar de serem virtuais, se a máquina exigir setup(CYB_LGUSU) deverá enviar as tags SetupCode, StartSetupDateTime e EndSetupDateTime .
• Caso o documento, tag DocumentCode,  esteja em branco será gravado o número da ordem de produção.
• Os campos Data da Reserva  'CZP_DTMT' deve receber o conteúdo da tabela CYP.CYP_DTMT 
  A quantidade reserva  'CZP_QTMT'  deve receber o conteúdo da tabela  CYP.CYP_QTMT
  O estado  'CZP_TPST' deve receber o conteúdo da tabela CYP.CYP_TPST 
• O tempo unidade operação, CZ0_QTTEUN, deverá ser gerado conforme regra do SFCA314
• A mensagem de retorno deve continuar sendo executada da mesma forma, porém deverá enviar o campo CYV.CYV_NRSQRP ( sequencia do reporte). 
  
  
  2. Estorno
  

Os estornos dos apontamentos deverão seguir os procedimentos abaixo:

• O estorno ocorre quando o campo o campo ReversedReport (Estorno do apontamento) possuir o conteúdo TRUE.
  Quando for estorno deverá, obrigatoriamente ter o número do apontamento, campo IntegrationReport. (CYV.CYV_NRSQRP quando usa o chão de fábrica)
• Diferente do PCP que exclui o registro na SH6, o chão de fábrica mantem o registro nas tabelas, porém registra a data,usuário e indicador do estorno do estorno.
  Neste caso serão atualizados os campos:
  CYV_DTEO - Data do estorno. Tag ReversalDate
  CYV_LGRPEO - Indicador de estorno. Tag ReversedReport
  CYV_CDUSOE - Usuário do estorno. Usuário do processamento (UserId)
  
• O estorno pode ser gerado de duas formas no arquivo: somente o estorno ou estorno + apontamento. Quando a mensagem possuir o estorno e o apontamento só pode commitar as movimentações quando ambas forem concluídas. 
  Para identificar se a mensagem possui somente estorno ou estorno + apontamento deverá verificar as seguintes situações:
  Somente estorno: possui quantidade aprovada e refugado zerado ( ou sem conteúdo) e dados do ReversedReport. 
  Estorno + apontamento: possui ReversedReport informado e dados da ordem e quantidade aprovada ou refugada maior que zero.
  
  

3. Refugo

Na FASE 1, quando for apontado Refugo/Perda(ScrapQuantity for maior que zero), não está registrando o motivo de refugo tags do ListOfWasteAppointments devido a rotina MATA681 que não atualiza dados da tabela SBC quando a execução for decorrente de processamentos automáticos.

 Deverá ser alterado o processo para registrar o motivo e também gerar dados do chão de fábrica

3.1 Registrar Motivo

No Mata680 quando possuir refufo/perda é executada a função abaixo:

Function DigiPerda(cProduto,cNumOp,nQtd)

Nesta função, é verificada se a execução é automática não abre a tela e sai da rotina.

If (Type("l680Auto") == "L" .And. l680Auto) .Or. ;
   (Type("l681Auto") == "L" .And. l681Auto) .Or. ;
   (Type("l250Auto") == "L" .And. l250Auto)
    lRet     := .T.
    lContinua:= .F.
Endif

Deverá alterar para que seja verificado, se o apontamento de refugo está sendo gerado via integração com o PC-Factry gerar os dados da SBC , ou seja, preparar a rotina para executar via execução automática.

Na tabela que define a mensagem está descrito a origem dos campos, motivo, descrição do motivo e quantidade do refugo. Os demais campos da tabela SBC podem ser obtidos do BusinessContentType. 

Obs: A validação do parâmetro MV_DIGIPER deve continuar.

3.2 Atualizar cadastro do motivo PCP

No adpater MATI681 deverá verificar se o motivo está cadastrado. Caso não esteja deverá ser incluído o motivo utilizado no apontamento na tabela SX5. 

Deverá pesquisar na tabela SX5 da seguinte maneira:

select X5_CHAVE from sx5990 where X5_TABELA = '43'

Onde:
- O código do motivo é X5_CHAVE
- A tabela do motivo é '43'.
   Se não encontrar o motivo deverá incluir na SX5 usando código e descrição.

3.3 Atualizar Chão de Fábrica ( MV_INTSFC igual a '1')

Para o chão de fábrica deverá atualizar a tabela do chão de fábrica CY0.

No adapter SFCI314 deverá verificar se o motivo está cadastrado.  Caso não esteja deverá ser incluído o motivo utilizado no apontamento na tabela CY0. 

Sempre considerar o tipo(CYO_LGRFMP) como REFUGO.

Quando usar o chão de fábrica a geração do apontamento no PCP é executada automaticamente, porém como o refugo não é gerado na SX5 nesse cenário, a validação do motivo deverá ser alterada:

Na Function PerdaIniCp(), se estiver integrado com o chão de fábrica e a origem do apontamento foi o SFCA314 deverá validar o motivo na tabela CYO.

3.4 Tamanho dos campos

O motivo de refugo tem tamanhos diferentes nas tabelas. Deverá validar se o código recebido não vai ultrapassar o tamanho das colunas no Protheus.
Quando usa o PCP deve validar contra o SX5.X5_CHAVE e SBC.BC_MOTIVO.
Quando usa o SIGASFC validar contra o CYO.CYO_CDRF, CY0.CY0_CDRF  e SBC.BC_MOTIVO

4. Parada

O apontamento de parada foi desenvolvido na FASE 1. Deverá gerar as informações  do chão de fábrica. No chão de fábrica a rotina é o SFCA311.

4.1 Alterar o adapter do apontamento de produção MATI682.

O Adapter fará a leitura do XML para gerar os dados que serão passados automaticamente para a rotina de apontamento SFCA311. O XML contém inúmeros campos, porém, para a integração Protheus com o PC-Factory vamos usar somente os descritos na tabela da mensagem do apontamento de parada. O Adpater será desenvolvido usando padrão EAI. No caso dos apontamentos desenvolver apenas o processo de recebimento da mensagem - TRANS_RECEIVE.

Mensagem de parada  

Deverá tratar o parâmetro de integração do chão de fábrica MV_INTSFC. Se for igual '1' deverá executar o ExecAuto no SFCA311 ao invés do MATA682.

Se PCP Gera SH6: 

//Carrega o array com os valores necessários para o apontamento.
aSH6 := {{"H6_RECURSO" ,cMaquina , NIL },;
{"H6_MOTIVO" ,cMotPar , NIL },;
{"H6_FERRAM" ,cFerr , NIL },;
{"H6_DATAINI" ,dDateIni , NIL },;
{"H6_HORAINI" ,cHoraIni , NIL },;
{"H6_DATAFIN" ,dDateFim , NIL },;
{"H6_HORAFIN" ,cHoraFim , NIL },;
{"H6_DTAPONT" ,dDtRep , NIL },;
{"H6_OPERADO" ,cOper , NIL },;
{"H6_OBSERVA" ,cProduct , NIL },;
{"H6_TIPO" ,"I" , NIL },;
{"REPORTSEQUENCE",cSeqReporte,NIL}} //contém o ID da parada no PPI.

Se SFC Gera :

CYX {......

        ..........}

• Modelo do turno e número do turno será gerado  automaticamente pela rotina SFCA311
• Se a mensagem não  enviar o StopType será considerado como 2= Não Programada
• O número do apontamento é enviado ao Pc-Factory pelo Protheus na mensagem de retorno da StopReport é corresponde ao RECNO da CYX. Este mesmo número será utilizado quando precisar registrar um estorno(IntegrationReport)
• O Estorno continua no caso do chão de fábrica é o processo de EXCLUSAO do SFCA311.
• Quando estiver integrado com o chão de fábrica,  caso o motivo de parada não esteja cadastrado, deverá gerar a tabela do chão de fábrica - CYN. Fazer essa geração no adapter . 

4.2 Tamanho dos campos

O motivo de parada tem tamanhos diferentes nas tabelas. Deverá validar se o código recebido não vai ultrapassar o tamanho dos campos no Protheus.
Quando usa o PCP deve validar contra o SX5.X5_CHAVE e SH6.H6_MOTIVO.
Quando usa o SIGASFC validar contra o CYN.CYN_CDSP, CYX.CYX_CDSP e SH6.H6_MOTIVO

Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.

Opcional

Protótipo de Tela

<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.

Protótipo 01

Opcional

Fluxo do Processo

<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>. 

Opcional

Dicionário de Dados

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.