ER_MANCORE1-131_MOVIMENTACAO

(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

1) Alterar geração da mensagem de ordens para tratar a alocação e tipo de requisição.

2) Deverá tratar movimentações avulsas de estoques, como entrada, saídas

3) Transferências.

<Nesta etapa informar o objetivo da especificação do requisito, ou seja, o que a funcionalidade deve fazer. Exemplo: Permitir que o usuário defina o percentual mínimo em espécie (dinheiro), a referência mínima para calculo dos débitos do aluno e o período de validade do parâmetro de negociação>.

(Obrigatório)

Definição da Regra de Negócio

 1) Alterar mensagem de ordem de produção - Alocação e tipo de requisição

Será alterada a mensagem de ordem de produção  para considerar um novo campo que indica se o item é apropriação direta ou indireta.

Segue denominação dos tipos de produtos e como o sistema age de acordo com esse tipo:

"

Apropriação Direta ou Indireta de material.

Produtos de Pequeno Valor Agregado,Grande Giro e/ou Dificil Quantificacao podem utilizar a Apropriacao indireta.
Exemplo:
========
Definimos que na montagem de 1 Cadeira utilizam-se 8 Parafusos.
Parafusos com APROPRIACAO DIRETA:
Durante o dia cada Ordem de Producao de 1 Cadeira irá Requisitar 8 parafusos do Armazem Padrao; na prática o funcionario deverá se dirigir ao
Almoxarife com uma requisição de 8 parafusos cada vez que for montar 1cadeira.
Parafusos com APROPRIAÇÃO INDIRETA:
No início do dia é feita uma Requisição Manual de 1 Caixa de Parafusos (1000 Parafusos).
Esta Requisição irá fazer com que estes 1000 parafusos sejam transferidos para o Armazem de Processo(definido no MV_LOCPROC). Cada OP de 1
Cadeira irá requisitar 8 parafusos do Armazém de Processo; na prática a caixa de parafusos ja terá sido requisitada e estará disponível para que o funcionário pegue os 8 parafusos.

"

Na consumo dos componentes o processo se dá seguindo 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.

Na mensagem de ordem deverá tratar 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)

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.

Alteração da mensagem ProductionOrder, incluindo o seguinte campo na lista de materiais:

Para a lista de Materiais também deverá enviar as seguintes tags existentes:

Também será criada uma lista denominada ListOfAllocatedMaterial para registrar a alocação dos componentes. Esta lista ficará dentro da da lista de material ListOfMaterialOrders.

Conterá os seguintes campos:

No PCP, deverá ser alterado  as rotinas que geram a mensagem de ordem para considerar esse novo campo. Rotinas:

• MATA650
• MATA651
• MATA632
• MATA380
• MATA381
• MATA637 
• MATA712
• SFCA310 
  Nesta rotina existem várias ações relacionadas ao SPLIT que deverão ser integradas:
  - Dividir Split
  - Alocar Split
  - Unir Split
  - Desalocar Split
  - Alocar vários splits

Todos os programas listados acima  executam o MATA650, processando a função mata650PPI. Deverá ser alterado o MATI650 para gerar a nova tag - RequestType( Deverá pesquisar na SB1 o campo B1_APROPRI do componente) e a ListOfAllocatedMaterial.

Origem das TAGs:

Obs.: Para gerar a SDC deve usar o conceito de localização "MV_LOCALIZ".

Algumas regras para o alocação:

Se o item controlar endereço e não gerou a SBC não deve gerar os dados da lista ListOfAllocatedMaterial ( verificar somente se o parâmetro MV_LOCALIZ = S )

Se o item controlar rastro e não gerou o lote na SD4  não deve gerar os dados da lista ListOfAllocatedMaterial

Se o item não controlar endereço nem lote  deve gerar os dados da lista ListOfAllocatedMaterial com base na SD4.

2) Deverá tratar movimentações avulsas de estoques, como entrada e saídas

Criar rotina para receber as movimentações de estoques. Será alterado o webservice, WSPCP para receber a mensagem MovementsInternal.

2.1 Mensagem

A Mensagem utilizada será:  MovementsInternal_1_001

A mensagem será gerada pelo PC-Factory, e  possui cabeçalho padrão TOTVSMessage:

Abaixo modelo de como será a mensagem para o cabeçalho:

<?xml version="1.0" encoding="UTF-8" ?> 

<TOTVSMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="xmlschema/general/events/MovementsInternal_1_001.xsd"> 

    <MessageInformation version="1.001"> 

        <UUID>d97aeb6f-1440-8c81-fc13-ec8cf87b82ad</UUID> 

        <Type>BusinessMessage</Type> 

        <Transaction>MovementsInternal</Transaction> 

        <StandardVersion>1.0</StandardVersion> 

        <SourceApplication>dts11cordas8480</SourceApplication> 

        <CompanyId>10</CompanyId> 

        <BranchId>01</BranchId> 

         <UserId>xxx</UserId> 

        <Product name="Datasul" version="11.5.X"/> 

        <GeneratedOn>2015-07-10T16:25:21.971-03:00</GeneratedOn> 

        <ContextName>PROTHEUS</ContextName> 

        <DeliveryType>Sync</DeliveryType> 

    </MessageInformation> 

    <BusinessMessage> 

        <BusinessEvent> 

           ......................

        </BusinessEvent>

            ....................

            ....................          

    <\BusinessMessage>

   O que espera-se:

•    TOTVSMessage xmlns:xsi Indica o xsd para gerarção do XML. O nome da mensagem deverá ser: MovementsInternal_1_001 
•    MessageInformation version Indica a versão da mensagem. A versão deverá ser “1.001” 
•    UUID : Sequencial usado pelo EAI. Gerar fixo “1’. Não será validado pelo Protheus
•   Type: Tipo da mensagem. Gerar fixo “BusinessMessage”
•    Transaction: Indica o que está sendo enviado. A transação deverá ser:“MovementsInternal” 
•    StandardVersion: Versão. Deverá ser  “1.001” 
•    SourceApplication: Aplicação que está executando. Não será validado pelo Protheus
•    CompanyId: Código da empresa. Deverá retornar a empresa em que será processado a movimentação
•    BranchId:  Código da filial. Deverá retornar a filial em que será processado a movimentação
•    UserId: Usuário. Não será validado pelo Protheus
•    Product: Name. Nome do produto. O Nome deverá ser PPI
•    GenerateOn = Data e hora da geração da mensagem. Não será validado pelo Protheus
•    ContextName = Sistema que gerou. Não será validado pelo Protheus
•    DeliveryType:Tipo de envio da mensagem. Gerar fixo “Sync”. Tem que ser Sync, pois faremos o retorno.

Dentro do BusinessMessage existe o bloco BusinessEvent com as seguintes tags:

<BusinessEvent>
    <Entity>Item</Entity>
    <Event>upsert</Event>
</BusinessEvent>

Onde:

• Entity: Entidade . Gerar fixo “MovementsInternal” 
• Event: Inclusão/Alteração ou exclusão. Pode ser ‘delete’ ou ‘upsert’. No caso do movimento deverá ser upsert.
  
  

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

A mensagem possui vários tags, porém serão usadas algumas para o PC-Factory:

Incluir os seguintes campo na mensagem:

Deverá registrar que a movimentação teve  origem via integração com PC-Factory. Para tal, deverá incluir um campo na SD3. Incluir o campo D3_OBSERVA CHAR(30).

Deverá gravar com o conteúdo: "TOTVSMES". Usar o Product Name do cabeçalho da mensagem para validar. Quando for PPI gravar o novo campo.

2.2 Serão desenvolvidos os seguintes requisitos:

2.2.1 - WebService

No caso das movimentações, deverá validar se existe o campo InputOrOutput. Se for E(entrada) deverá executar o adapter MATI250. Se for S(saída) executar MATI240. Diferente de E ou S, rejeitar a mensagem.

Case cTransac == "MOVEMENTSINTERNAL" //Movimentação Avulsa
changeEmp(cEmpIntg,cFilIntg)

<<Validar o campo InputOrOutput>>

aAdapter := MATINNN(oXml, TRANS_RECEIVE, EAI_MESSAGE_BUSINESS)

aAdd(aAdapter, cEmpIntg)
aAdd(aAdapter, cFilIntg)
aAdd(aAdapter, "MATINNN")

onde: MATINNN, pode ser MATI250 ou MATI240

2.2.2  Adapter de Movimentos 

Quando o PC Factory for o produto gerador da informação o fluxo da integração será o seguinte:

a. Operador efetua movimentação  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, essa movimentação 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).

2.2.2.1 MATI250

Adapter será desenvolvido usando padrão EAI. No caso dos movimentos de produção simples desenvolver apenas o processo de recebimento da mensagem - TRANS_RECEIVE. Usar como modelo o MATI010.

Function MATI250(cXml, nTypeTrans, cTypeMessage) 

//Mensagem de Entrada

If nTypeTrans == TRANS_RECEIVE

....

If cVersao == "1"

aRet := v1000(cXml, nTypeTrans, cTypeMessage)
Else
lRet := .F.
cXmlRet := STR0007 //"A versão da mensagem informada não foi implementada!"
Return {lRet, cXmlRet}
EndIf

.........

.........

Na função v1000 tratar somente o recebimento:

Static Function v1000( cXML, nTypeTrans, cTypeMessage )

........

........

//Tratamento do recebimento de mensagens

If ( nTypeTrans == TRANS_RECEIVE )

{VALIDAÇÕES}

........

          //Carrega o array com os valores necessários 

         aAdd(aMata250, {{'D3_TM' ,c_Tm ,Nil},;

          {'D3_COD' ,cProduto ,Nil},;
          {'D3_QUANT' ,nQtd ,Nil},;
          {'D3_EMISSAO',ddatabase ,Nil},;

           ..........

          ..........  }})

        MSExecAuto({|x,y| mata250(x,y)},aMata250[1],3)

         If lMsErroAuto

            aErroAuto := GetAutoGRLog()

            For nCount := 1 To Len(aErroAuto)

                Conout("      "+aErroAuto[nCount])

                If AT('HELP:',aErroAuto[nCount]) > 0 .Or. AT('< --',aErroAuto[nCount]) > 0

                   //Retorna somente a mensagem de erro (Help) e o valor que está inválido, sem quebras de linha e sem tags '<>'

                   cLogErro += StrTran( StrTran( StrTran( StrTran( StrTran( aErroAuto[nCount], "/", "" ), "<", "" ), ">", "" ), CHR(10), " "), CHR(13), "") + ("|")

                EndIf

            Next nCount

            lRet    := .F.

            cXMLRet := cLogErro

            Return {lRet,cXmlRet}

         Else

            lRet    := .T.

            cXmlRet := cValToChar(SD3->(Recno()))

         EndIf

EndIf

O Adapter fará as seguintes validações antes de executar a rotina de movimentação  MATA250. Abaixo algumas regras:

• Irá validar se a mensagem é MOVEMENTSINTERNAL.
• 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 de retorno 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. 

• Criar ponto de entrada para executar no Adapter, antes do execAuto afim de possibilitar aos clientes alguma validação especifica. Estas validações ficarão a cargo dos clientes, pois cada um terá sua regra. Não pode alterar os valores dos campos que foram gerados pela mensagem.

• Na mensagem a tag InputOrOutput indica se é entrada ou saída. Com base nessa informações deverá buscar o tipo do movimento do cadastro PCPA109, folder MOVIMENTACOES. Se for Entrada usar o campo OE_VAR1. Se for Saída usar o campo OE_VAR2
• Não terá a opção de estorno. Para realizar um processo de estorno deverá enviar a movimentação contrária, ou seja, para estornar uma entrada deverá enviar um movimento de saída.
• Para a tag ProductionOrderNumber deverá validar se o conteúdo é uma ordem de produção (SC2), Se for OP gravar no campo SD3.D3_OP, caso contrário gravar no campo SD3.D3_DOC
• Quando o chão de fábrica está em uso (MV_INTSFC = 1) a rotina não permitirá realizar o movimento de entrada manual. Somente apontamento via chão de fábrica.
  

   

2.2.2.2 MATI240

Será alterado o adapter MATI240, colocando-o no padrão de verificação de versão. Deverá ser alterado para atender qualquer tipo de integração. Usar como base o MATI010.

Será alterado somente o recebimento da mensagem - TRANS_RECEIVE.

If nTypeTrans == TRANS_RECEIVE

 ....

 If cVersao == "1"

 aRet := v1000(cXml, nTypeTrans, cTypeMessage)

Else
lRet := .F.
cXmlRet := STR0007 //"A versão da mensagem informada não foi implementada!"
Return {lRet, cXmlRet}
EndIf

 .........

 .........

Na função v1000 tratar somente o recebimento:

Atualmente a rotina faz algumas validações que devem ser executadas somente quando NÃO for startado pelo TOTVS MES. A integração com o PC-Factory deve realizar as validações padrões da rotina MATA240 via execauto. Exemplo:

A validação abaixo não  deve ser executa quando integração for entre Protheus e PPI. Fazer o tratamento da variável lIntegPPI

if lIntegPPI = False

     If (oXmlMvInt:_TotvsMessage:_BusinessMessage:_BusinessContent:_InputOrOutput:Text) == "E"
     cTpMov := SuperGetMv('MV_MTI241E',.F.,"")
    ElseIf (oXmlMvInt:_TotvsMessage:_BusinessMessage:_BusinessContent:_InputOrOutput:Text) == "S"
     cTpMov := SuperGetMv('MV_MTI241S',.F.,"")
    EndIf

EndIf

O Adapter fará as seguintes validações antes de executar a rotina de movimentação MATA240. Abaixo algumas regras: 

• Irá validar se a mensagem é MOVEMENTSINTERNAL.
• 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 de retorno 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. 

• Criar ponto de entrada para executar no Adapter, antes do execAuto afim de possibilitar aos clientes alguma validação especifica. Estas validações ficarão a cargo dos clientes, pois cada um terá sua regra. Não pode alterar os valores dos campos que foram gerados pela mensagem.

• Na mensagem a tag InputOrOutput indica se é entrada ou saída. Com base nessa informações deverá buscar o tipo do movimento do cadastro PCPA109, folder MOVIMENTACOES. Se for Entrada usar o campo OE_VAR1. Se for Saída usar o campo OE_VAR2
• Para a tag ProductionOrderNumber deverá validar se o conteúdo é uma ordem de produção (SC2), Se for OP gravar no campo SD3.D3_OP, caso contrário gravar no campo SD3.D3_DOC

3) Transferências

Criar rotina para receber as movimentações de transferências. Será alterado o webservice, WSPCP para receber a mensagem TransferWarehouse.

3.1 Mensagem

A Mensagem utilizada será:  TransferWarehouse_1_001

A mensagem será gerada pelo PC-Factory, e  possui cabeçalho padrão TOTVSMessage:

Abaixo modelo de como será a mensagem para o cabeçalho:

<?xml version="1.0" encoding="UTF-8" ?> 

<TOTVSMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="xmlschema/general/events/TransferWarehouse_1_001.xsd"> 

    <MessageInformation version="1.001"> 

        <UUID>d97aeb6f-1440-8c81-fc13-ec8cf87b82ad</UUID> 

        <Type>BusinessMessage</Type> 

        <Transaction>TransferWarehouse</Transaction> 

        <StandardVersion>1.0</StandardVersion> 

        <SourceApplication>dts11cordas8480</SourceApplication> 

        <CompanyId>10</CompanyId> 

        <BranchId>01</BranchId> 

         <UserId>xxx</UserId> 

        <Product name="Datasul" version="11.5.X"/> 

        <GeneratedOn>2015-07-10T16:25:21.971-03:00</GeneratedOn> 

        <ContextName>PROTHEUS</ContextName> 

        <DeliveryType>Sync</DeliveryType> 

    </MessageInformation> 

    <BusinessMessage> 

        <BusinessEvent> 

           ......................

        </BusinessEvent>

            ....................

            ....................          

    <\BusinessMessage>

   O que espera-se: 

•    TOTVSMessage xmlns:xsi Indica o xsd para gerarção do XML. O nome da mensagem deverá ser: TransferWarehouse_1_001 
•    MessageInformation version Indica a versão da mensagem. A versão deverá ser “1.001” 
•    UUID : Sequencial usado pelo EAI. Gerar fixo “1’. Não será validado pelo Protheus
•   Type: Tipo da mensagem. Gerar fixo “BusinessMessage”
•    Transaction: Indica o que está sendo enviado. A transação deverá ser:“TransferWarehouse” 
•    StandardVersion: Versão. Deverá ser  “1.001” 
•    SourceApplication: Aplicação que está executando. Não será validado pelo Protheus
•    CompanyId: Código da empresa. Deverá retornar a empresa em que será processado a transferência
•    BranchId:  Código da filial. Deverá retornar a filial em que será processado a transferência
•    UserId: Usuário. Não será validado pelo Protheus
•    Product: Name. Nome do produto. O Nome deverá ser PPI
•    GenerateOn = Data e hora da geração da mensagem. Não será validado pelo Protheus
•    ContextName = Sistema que gerou. Não será validado pelo Protheus
•    DeliveryType:Tipo de envio da mensagem. Gerar fixo “Sync”. Tem que ser Sync, pois faremos o retorno. 

Dentro do BusinessMessage existe o bloco BusinessEvent com as seguintes tags: 

<BusinessEvent>

    <Entity>Item</Entity>
    <Event>upsert</Event>
</BusinessEvent> 

Onde: 

• Entity: Entidade . Gerar fixo “TransferWarehouse” 
• Event: Inclusão/Alteração ou exclusão. Pode ser ‘delete’ ou ‘upsert’. No caso do movimento deverá ser upsert.
  
  

Dentro do BusinessMessage existe o bloco BusinessContentType, que contém os dados da transferência. 

A mensagem possui vários tags, porém serão usadas algumas para o PC-Factory:

Incluir os seguintes campo na mensagem:

Obs.: Estes campos não serão utilizados peplo Protheus, porém devem ser criados para atender os demais ERPs.

Deverá registrar que a movimentação teve  origem via integração com PC-Factory. Para tal, deverá incluir um campo na SD3. Incluir o campo D3_OBSERVA CHAR(30).

Deverá gravar com o conteúdo: "TOTVSMES". Usar o Product Name do cabeçalho da mensagem para validar. Quando for PPI gravar o novo campo.

3.2. - WebService 

No caso das transferências, deverá executar o adapter MATI261.  

Case cTransac == "TRANSFERWAREHOUSE" //Transferencias
changeEmp(cEmpIntg,cFilIntg) 

aAdapter := MATI261(oXml, TRANS_RECEIVE, EAI_MESSAGE_BUSINESS) 

aAdd(aAdapter, cEmpIntg)
aAdd(aAdapter, cFilIntg)
aAdd(aAdapter, "MATI261")

3.3  Adapter de Transferência 

Quando o PC Factory for o produto gerador da informação o fluxo da integração será o seguinte: 

a. Operador efetua movimentação  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, essa movimentação 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). 

No caso das transferência será executado o MATI261. 

Será alterado o adapter MATI261, colocando-o no padrão de verificação de versão. Deverá ser alterado para atender qualquer tipo de integração. Usar como base o MATI010. 

Será alterado somente o recebimento da mensagem - TRANS_RECEIVE. 

If nTypeTrans == TRANS_RECEIVE 

 .... 

 If cVersao == "1" 

 aRet := v1000(cXml, nTypeTrans, cTypeMessage) 

Else
lRet := .F.
cXmlRet := STR0007 //"A versão da mensagem informada não foi implementada!"
Return {lRet, cXmlRet}
EndIf 

 .........

 ......... 

Desenvolver apenas o recebimento(TRANS_RECEIVE) da mensagem na função v1000 :

Atualmente a rotina faz algumas validações que não necessitam ser executadas quando for executado pelo TOTVS MES. A integração com o PC-Factory deve realizar as validações padrões da rotina MATA261 via ExecAuto. 

Exemplo:

A rotina verifica a função CFGA070INT para ler o XML. Quando for via PPI não deve fazer essa validação.

O Adapter fará as seguintes validações antes de executar a rotina de transferência MATA261. Abaixo algumas regras:  

• Irá validar se a mensagem é TransferWarehouse.
• 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 de retorno 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. 

• Não terá a opção de estorno. Para realizar um processo de estorno deverá enviar a movimentação contrária, ou seja, para estornar uma transferência de X para Y deverá enviar um movimento de transferência de Y para X.

Criar ponto de entrada para executar no Adapter, antes do execAuto afim de possibilitar aos clientes alguma validação específica. Estas validações ficarão a cargo dos clientes, pois cada um terá sua regra. Não pode alterar os valores dos campos que foram gerados pela mensagem.

<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

Arquivo ou Código do Script: SD3– Movimentações

(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>.