Histórico da Página
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|
(Obrigatório)
Informações Gerais
Especificação | |||
Produto | Protheus | Módulo | SIGAPCP |
Segmento Executor |
| ||
Projeto1 | M_MAN_PCP001 | IRM1 | PCREQ-367 |
Requisito1 | PCREQ-6132 | Subtarefa1 |
|
Chamado2 |
| ||
Release de Entrega Planejada | 12.1.8 | Réplica | 11.8 |
País | (x ) Brasil ( ) Argentina ( ) Mexico ( ) Chile ( ) Paraguai ( ) Equador ( ) USA ( ) Colombia ( ) Outro _____________. | ||
Outros | <Caso necessário informe outras referências que sejam pertinentes a esta especificação. Exemplo: links de outros documentos ou subtarefas relacionadas>. |
Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos).
Objetivo
Desenvolver funções ( adapters ) que serão executadas nas rotinas de cadastro de itens, cadastro de local de estoque, cadastro de recurso, cadastro de centro de trabalho, rotinas de inclusão ordens de produção ( cadastro manual e MRP), para que os dados sejam enviados via mensagem XML ao PCFactory. O envio das mensagens se dará via WEBSERVICE.
<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
Desenvolver rotinas para realizar o envio dos dados do Protheus para o PCFactory usando Adapters que irão gerar os XML´s que serão enviados ao Webservice da PPi MultTask.
O projetos está divido em 3 fases. Nesta primeira fase de desenvolvimento serão integrados os seguintes dados :
- Cadastro de Itens
- Cadastro de Local de Estoque ( depósitos)
- Cadastro de Centro de Trabalho
- Cadastro de Recurso
- Ordens de produção ( Operações, Roteiros, Componentes )
A integração entre os dois sistemas ocorrerá utilizando o conceito de troca de mensagens XML trafegadas sobre o protocolo HTTP ou HTTPS – com o uso do padrão SOAP (WebServices). Em seguida, deverá enviar para o Webservice disponibilizado pelo PCFactory (software MES da PPI Multitask), caracterizando o envio como síncrono.
Conforme o padrão da TOTVS, todas as mensagens trafegadas usarão o conceito de Mensagem Única – sob o layout da TOTVSMessage (que pode ser conferido em $/STABLE/xmlschema/general/totvsmsg.xsd).
Segue regra de envio (TOTVS-> PPI) usada para todos os arquivos(utilizando o exemplo de uma Ordem de Produção):
- No momento do <Enter> na criação ou alteração de uma Ordem de Produção, o WebService será avisado de forma síncrona antes da efetivação no próprio TOTVS.
- O PC Factory, ao receber a mensagem já irá executar a rotina de efetivação no mesmo momento, permitindo retornar ao TOTVS se a OP foi incluída com sucesso ou se há alguma inconsistência de negócio.
- Caso não ocorra erro, o procedimento é concluído e a sessão do usuário já é liberada.
Em caso de exceção (erros de transporte ou inconsistências de negócio), o usuário será avisado no mesmo momento que a Ordem não foi efetivada no PC Factory, detalhando qual foi a causa do problema, e permitirá ao usuário tomar 2 ações:
- Ignorar o erro (Tratar mais tarde) – a ordem é efetivada no ERP, porém será gerada uma pendência de integração em banco de dados(Protheus) , para que um usuário responsável consiga visualizar as informações que não foram enviadas e possa tomar alguma ação sobre ela(controle de pendências).
- Cancelar processo – a ordem não é efetivada no ERP, permitindo ajustes do próprio usuário e após isso ele poderá refazer sua alteração.
- Exportar o XML e gerar dados da tabela de integração tanto da transação com erro como da transação OK, respeitando o padrão estabelecido no item 1.2.4.
Abaixo vamos detalhar o envio de cada mensagem. A criação/alteração dos adpaters bem como a alteração dos pontos de geração e alteração dos dados que deverão startar o envio das mensagens.
Mensagens TOTVS enviadas:
1 - Item
O cadastro de itens é o MATA010. Gera a tabela SB1.
A Mensagem utilizada será: Item_3_002
1.1 Mensagem:
A mensagem possui vários tags, porém serão enviados apenas alguns ao usadas algumas para o PCFactory:
Bloco | PC-Factory | Totvs |
BusinessContentType | PlantExtCode | CompanyId (Empresa) |
BusinessContentType | PlantCode | BranchId (Filial) |
BusinessContentType | PlantAuxField1 | CompanyInternalId (Empresa+Filial) |
BusinessContentType | Code | Code (Código do item) |
BusinessContentType | Name | Name (Descrição do item) |
BusinessContentType | SecondName | ShortName ( Nome curto) |
BusinessContentType | FlgEnable | Active ( Item ativo?) |
BusinessContentType | Unit1Code | UnitOfMeasureCode (Unidade de Medida) |
BusinessContentType | EconomicLot | EconomicLot (Lote econômico) |
BusinessContentType | MinLot | MinimumLot (Lote mínimo) |
BusinessContentType | FamilyProductCode | FamilyCode (Família) |
BusinessContentType | FamilyProductName | FamilyDescription (Descrição da família) |
BusinessContentType | Unit2Code | SecondUnitOfMeasureCode (Segunda Unidade de medida) |
BusinessContentType | Unit2Factor | MultiplicationFactorValue (Fator de conversão) |
BusinessContentType | ProductTypeCode | ProductType (Tipo do Item) |
ValuesType | QtyPackage | PackingQuantity (Quantidade Embalagem) |
Algumas tags deverão ser geradas somente quando usa integração com o PC-Factory(atualmente não são geradas):
- Detail: Especificação do item. Gerar em branco. <Detail/>
- MultipleLot: Lote múltiplo do item. Não tem no Protheus. Gerar 0.
<MultipleLot>0</MultipleLot>
- CostCenterCode : Centro de custo. Usar SB1.B1_CC
- SecondUnitOfMeasureCode: Segunda unidade de medida. Usar SB1.B1_SEGUM
- PackingQuantity: Quantidade da embalagem. Usar SB1.B1_QE
As demais tags continuam sendo geradas normalmente.
1.2 Alterações necessárias:
1.2.1 MATA010
O cadastro de itens já executa função que gera XML padrão TOTVS e integra com o EAI. Atualmente executa o Adapter MATi010.
Será alterado o cadastro de itens para que também execute o adapter quando a integração com o PPI MultTask estiver ativa.
Para ativar o MATI010 é verificado se existe cadastrado nas rotinas do EAI usando a variável abaixo:
Local lIntegDef := FWHasEAI("MATA010",.T.,,.T.)
Para integração Protheus x PC-Factory não será usado o EAI e desta forma a variável lIntegDef não será utilizada. Para não interferir com o processo do EAI,será criada uma função no PCPXfun(com o nome de PCPIntgPPI ) para a verificação de integração com o PC-Factory registrada na tabela SOD, campo OD_ATIVO. O cadastro da SOD é feito pelo PCPA109, parâmetros da integração entre Protheus x PPI.
Obs.: A função PCPXfun(PCPIntgPPI) de verificação será padrão que possa ser utilizada em outras rotinas.
A função IntegDef(que é executada pela FwIntegDef) é chamada de diversos pontos da rotina(Exclusão, Inclusão,Alteração). A IntegDef executa o adapter MATi010. Esta rotina é usada quando o EAI está ativo.
No caso da integração com o PCFactory será necessário executar o MATi010 de outra forma, executando-o antes de comitar os dados no banco, pois só poderá comitar se a integração for concluída com sucesso ou por geração de pendência.
Inclusão e Alteração - A010TudoOk:
Quando incluir deverá executar a integração diretamente na função A010TudoOk. Somente efetivar a inclusão se ocorrer a integração(ver item 1.2.4)
..........
If lRet .AND. <PCPIntgPPI >
aRet := MATI010(cXml, nTypeTrans, cTypeMessage)
Se o retorno for positivo poderá prosseguir com a exclusão e geração do XML nos diretórios correspondentes.
<função para gerar o XML nos diretórios>
<função para gerar tabela de integração SOF>
EndIf
RestArea(aArea)
Return(lRet)
...............
Exclusão - Static Function A010Deleta:
Após realizar as validações, que possibilitam a exclusão, antes de iniciar a transação Begin Transaction deverá executar a integração com o PPI. Somente efetivar a exclusão se ocorrer a integração(ver item 1.2.4).
.........
If !lPodeApagar
Exit
Endif
If <PCPIntgPPI > Then
aRet := MATI010(cXml, nTypeTrans, cTypeMessage)
Se o retorno for positivo poderá prosseguir com a exclusão e geração do XML nos diretórios correspondentes.
<função para gerar o XML nos diretórios>
<função para gerar tabela de integração SOF>
End if
Begin Transaction
..........
Deverá ser enviado os seguintes parâmetros para o MATI010 quando integração com pc-factory:
cXml =
nTypeTrans = TRANS_SEND
cTypeMessage = EAI_MESSAGE_BUSINESS
1.2.2 Function MATi010
A função MATI010 é a rotina responsável por gerar o XML.
Será usada a mesma função, sendo necessário algumas adequações. Alterar a Function MATI010(cXml, nTypeTrans, cTypeMessage)
........
ElseIf nTypeTrans == TRANS_SEND
IF <integraçao-pc_factory>
//Fixo 2. Na fase 2 deverá cadastrar a versão na rotina de parâmetros
cVersao := "2"
ELSE
dbSelectArea('XX4')
aAreaXX4 := XX4->(GetArea())
XX4->(dbSetOrder(1))
IF XX4->(dbSeek(Xfilial('XX4') + PADR('MATA010', Len(XX4_ROTINA)) + PADR('ITEM', Len(XX4_MODEL))))
If Empty(XX4->XX4_SNDVER)
lRet := .F.
cXmlRet := STR0008 //"Versão não informada no cadastro do adapter."
Return {lRet, cXmlRet}
Else
cVersao := StrTokArr(XX4->XX4_SNDVER, ".")[1]
EndIf
Else
lRet := .F.
cXmlRet := STR0009 //"Adapter não encontrado!"
Return {lRet, cXmlRet}
Endif
..................
1.2.3 Function v2000
Na função Static Function v2000, deverá fazer algumas validações pois a função é executada via EAI e também passará a ser executada via integração com o PCFactory.
Geração do LOG (verificar em todos os pontos - somente no envio da mensagem):
IIf(lLog, AdpLogEAI(1, "MATI010", nTypeTrans, cTypeMessage, cXML), ConOut(STR0011)) //"Atualize o UPDINT01.prw para utilizar o log"
Quando a execução for via integração com o pc-factory <integraçao-pc_factory> somente irá gerar o ConOut.
Na montagem do XML a rotina gera a partir do BusinessEvent (que fica dentro da tag BusinessMessage). Para integração com PCFactory deverá montar o cabeçalho da mensagem que consta com as tags TOTVSMessage e MessageInformation.
Abaixo modelo(seguindo padrão de integração entre PCFactory a Datasul):
<?xml version="1.0" encoding="UTF-8" ?>
<TOTVSMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="xmlschema/general/events/Item_3_001.xsd">
<MessageInformation version="3.001">
<UUID>d97aeb6f-1440-8c81-fc13-ec8cf87b82ad</UUID>
<Type>BusinessMessage</Type>
<Transaction>Item</Transaction>
<StandardVersion>1.0</StandardVersion>
<SourceApplication>dts11cordas8480</SourceApplication>
<CompanyId>10</CompanyId>
<BranchId>10</BranchId>
<UserId>xxx</UserId>
<Product name="Datasul" version="11.5.X"/>
<GeneratedOn>2015-07-10T16:25:21.971-03:00</GeneratedOn>
<DeliveryType>Sync</DeliveryType>
</MessageInformation>
<BusinessMessage>
<BusinessEvent>
......................
</BusinessEvent>
....................
....................
<\BusinessMessage>
Onde:
- TOTVSMessage xmlns:xsi Indica o xsd para gerarção do XML. Usar o conteúdo do modelo.
- MessageInformation version Indica a versão da mensagem. Usar “3.001”
- UUID : Sequencial usado pelo EAI. Gerar fixo “1’.
- Type: Tipo da mensagem. Gerar fixo “BusinessMessage”
- Transaction: Indica o que está sendo enviado. Gerar fixo “Item”
- StandardVersion: Versão. Gerar fixo “1.0”
- SourceApplication: Aplicação que está executando. Gerar fixo “SIGAPCP”
- CompanyId: Código da empresa. Empresa que estiver logada
- BranchId: Código da filial. Filial logada.
- UserId: Usuário. Usuário logado.
- Product: Nome do produto. Name = “MATA010” version = versão do programa.
- GenerateOn = Data e hora da geração da mensagem
- DeliveryType:Tipo de envio da mensagem. Gerar fixo “Sync”.
Dentro do BusinessMessage existe o bloco BusinessEvent com as seguintes tags:
<BusinessEvent>
<Entity>Item</Entity>
<Event>upsert</Event>
<Identification>
<key name="Code">651140049</key>
</Identification>
</BusinessEvent>
Onde:
- Entity: Entidade . Gerar fixo “Item”
- Event: Inclusão/Alteração ou exclusão. Pode ser ‘delete’ ou ‘upsert’
- Identification: Identificação do item.
Usar key name="InternalID" : gerar com o código do item B1_CODE
Na função está gerando key name =”Code”. Quando for integração com o Pc-Factory deve usar o IntenalID.
Dentro do BusinessMessage existe o bloco BusinessContent, que contém os dados do item. Está gerando o XML com muitas informações que não serão usadas pela integração. Pode continuar gerando.
Somente deve gerar os campos necessários conforme descrito no item 1.1
1.2.4 Filtros e , geração do XML XML e Tabela para registrar a mensagem (XML)
No cadastro de parâmetros PCPA109, é definido se gera o arquivo XML. Quando este indicador, OD_GERAXML, estiver como 'N' não será gerado o arquivo XML, será gravado apenas o conteúdo em tabela (SOF).
Deverá alterar a função no PCPXfun, criando a PCPXmLPPI ( função para gerar os XML com nome e diretório correspondente).
Caso o indicador , Caso o indicador , OD_GERAXML, estiver como 'S' deverá seguir a seguinte regra de geração:
- Enviados com sucesso : Enviar o o XML e o retorno do PCFactory for OK.
XML será gravado no diretório definido no campo Enviados(OD_DIRENV) do PCA109
- Enviados sem sucesso : Enviar o o XML e o retorno do PCFactory for ERRO ou WebService desligado.
XML será gravado no diretório definido no campo Pendência (OD_DIRPEND) do PCA109. Neste caso, como o retorno do PCFactory será impeditivo para o commit do registro, deverá ser questionado se deseja salvar no Protheus mesmo com o erro/pendência no PCFactory(neste caso sempre deve exibir a mensagem de erro que impossibilitou a integração). A rotina permitirá salvar o item para que depois seja realizada a integração via programa de controle de pendências, ou possibilitará que seja feito ajustes no cadastro e o reenvio dos dados.
Importante: Os arquivos gerados e dados da tabela SOF somente serão gerados se a inclusão/alteração/exclusão do item for comitada no banco, conforme descrito no item 1.2.1.
Os nomes do arquivos seguirão o seguinte padrão:
OK_<MSG>_<DATAHORA>_<REGISTRO>
PEND_<MSG>_<DATAHORA>_<REGISTRO>
ERR_<MSG>_<DATAHORA>_<REGISTRO>
Onde: OK - Se mensagem entregue sem problemas
PEND- Se mensagem não foi enviada
ERR - Se mensagem enviada, porém retornou erro.
MSG - ITEM
DATAHORA: Data e Hora do envio
REGISTRO: Código do item que está sendo enviado.
Obs.: o conteúdo também será gravado em tabela (SOF)
Em ambas as situações(sucesso ou erro/pendencia) será gerada a tabela SOF.
Criar a PCPCriaSOF, que será uma função genérica para gerar a SOF de qualquer rotina.
A tabela SOF conterá os seguintes campos:
- Transação : Nome da tabela ( SB1)
- Registro : código do item
- Status: 1 - OK; 2 - Pend; 3 - Erro
- Gerou XML : Sim ou não
- Nome arquivo XML
- Data Envio
- Hora de envio
- Usuário
- Mensagem de retorno
- Xml
IMPORTANTE:
Só poderá ter uma pendência para o registro.
Para gerar o XML e gravar a tabela SOF terá que respeitar as pendencias geradas. Se existir uma pendência de envio de algum registro e for gerada uma nova mensagem para o mesmo registro a pendencia deverá ser excluída e trabalhar somente com a última mensagem, que poderá ser enviada sem problemas ou gerar nova pendência.
Obs.: Mais informações verificar a especificação ERObs.: Mais informações verificar a especificação ER_PCREQ-6129_PPI_MultTask_Parametros
Filtros:
No PCPA109 são definidos os filtros que indicam quais registros serão enviados ao PCFactory.
No caso do item, deverá ler os dados da tabelas SOE onde o campo OE_TABELA seja = 'SB1'. O campo OE_FILTRO conterá o filtro que deverá ser aplicado ao registro que está sendo enviado. Somente poderá enviar(gerar xml) se satisfazer a condição do PCPA109.
Deverá alterar a função no PCPXfun, criando a PCPFiltPPI ( fará o filtro de todas as tabelas que são integradas com o PCFactory).
Essa função irá receber como parâmetro o nome da tabela. No caso do cadastro de item será enviado SB1 como parâmetro. Deverá ser executada no MATi010,.no mesmo ponto onde verifica a versão. Somente executa se for integração via PCFactory.
A função irá retornar TRUE se satisfazer a condição, ou seja, o item pode ser enviado e false caso o item não satisfaça.
Obs.: Se não existir filtro na SOE , OE_FILTRO, enviará todos os registros, ou seja, a função sempre retornará TRUE.
........
ElseIf nTypeTrans == TRANS_SEND
IF <integraçao-pc_factory>
//Fixo 2. Na fase 2 deverá cadastrar a versão na rotina de parâmetros
cVersao := "2"
lRetorna := PCPFiltPPI('SB1')
IF Not lRetorna THEN Return
ELSE
ELSE
.....................1.2.5 Tabela para Registrar o XML.
2 - Local de Estoque
Rotina | Tipo de Operação | Opção de Menu | Regras de Negócio |
[ACAA040 – Parâmetros] | [Alteração] | [Atualizações -> Acadêmico-> Tesouraria] | - |
[ACAA050 – Negociação Financeira] | [Envolvida] | [Atualizações -> Acadêmico-> Tesouraria] | - |
[ACAA060 – Cadastro de Pedidos] | [Criação] | [Atualizações -> Acadêmico-> Cadastros] | - |
Exemplo de Aplicação:
- Criar o campo “% Mínimo Espécie” (AAA_PERESP) onde o usuário informará o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação.
- Criar o campo “Referência Mínima para Cálculo” (AAA_REFCAL) onde o usuário informará um dos 4 valores disponíveis para pagamento das mensalidades como a referência mínima para calcular o débito total do aluno.
- Criar o parâmetro MV_ACPARNE que definirá se as informações de “% Mínimo Espécie” e “Referência Mínima para Cálculo” serão obrigatórias.
- O parâmetro MV_ACPARNE deve ter as seguintes opções: 1=Obrigatório e 2=Opcional. Deve ser inicializado como opcional>.
Tabelas Utilizadas
- SE2 – Cadastro de Contas a Pagar
- FI9 – Controle de Emissão de DARF>.
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: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/
Índice | Chave |
01 | <FI9_FILIAL+FI9_IDDARF+FI9_STATUS> |
02 | <FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_EMISS+FI9_IDDARF> |
03 | <FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_PREFIX+FI9_NUM+FI9_PARCEL+FI9_TIPO> |
Campo | <AAA_PERESP> |
Tipo | <N> |
Tamanho | <6> |
Valor Inicial | <Varia de acordo com o tipo informado. Por exemplo, quando o campo “tipo” for date, neste campo pode ser informado uma data>. |
Mandatório | Sim ( ) Não ( ) |
Descrição | <Referência Mínima para Cálculo> |
Título | <Ref.Calc.> |
Picture | <@E999.99> |
Help de Campo | <Informar o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação> |
(Opcional)
Grupo de Perguntas
<Informações utilizadas na linha Protheus>.
Nome: FINSRF2
X1_ORDEM | 01 |
X1_PERGUNT | Emissão De |
X1_TIPO | D |
X1_TAMANHO | 8 |
X1_GSC | G |
X1_VAR01 | MV_PAR01 |
X1_DEF01 | Comum |
X1_CNT01 | '01/01/08' |
X1_HELP | Data inicial do intervalo de emissões das guias de DARF a serem consideradas na seleção dos dados para o relatório |
(Opcional)
Consulta Padrão
<Informações utilizadas na linha Protheus>
Consulta: AMB
Descrição | Configurações de Planejamento |
Tipo | Consulta Padrão |
Tabela | “AMB” |
Índice | “Código” |
Campo | “Código”; ”Descrição” |
Retorno | AMB->AMB_CODIGO |
(Opcional)
Estrutura de Menu
<Informações utilizadas na linha Datasul>.
Procedimentos
Procedimento |
|
|
|
Descrição | (Max 40 posições) | (Max 40 posições) | (Max 40 posições) |
Módulo |
|
|
|
Programa base |
|
|
|
Nome Menu | (Max 32 posições) | (Max 32 posições) | (Max 32 posições) |
Interface | GUI/WEB/ChUI/Flex | GUI/WEB/ChUI/Flex | GUI/WEB/ChUI/Flex |
Registro padrão | Sim | Sim | Sim |
Visualiza Menu | Sim/Não | Sim/Não | Sim/Não |
Release de Liberação |
|
|
|
Programas
Programa |
|
|
|
Descrição | (Max 40 posições) | (Max 40 posições) | (Max 40 posições) |
Nome Externo |
|
|
|
Nome Menu/Programa | (Max 32 posições) | (Max 32 posições) | (Max 32 posições) |
Nome Verbalizado[1] | (Max 254 posições) | (Max 254 posições) | (Max 254 posições) |
Procedimento |
|
|
|
Template | (Verificar lista de opções no man01211) | (Verificar lista de opções no man01211) | (Verificar lista de opções no man01211) |
Tipo[2] | Consulta/Manutenção/ Relatório/Tarefas | Consulta/Manutenção/ Relatório/Tarefas | Consulta/Manutenção/ Relatório/Tarefas |
Interface | GUI/WEB/ChUI/Flex | GUI/WEB/ChUI/Flex | GUI/WEB/ChUI/Flex |
Categoria[3] |
|
|
|
Executa via RPC | Sim/Não | Sim/Não | Sim/Não |
Registro padrão | Sim | Sim | Sim |
Outro Produto | Não | Não | Não |
Visualiza Menu | Sim/Não | Sim/Não | Sim/Não |
Query on-line | Sim/Não | Sim/Não | Sim/Não |
Log Exec. | Sim/Não | Sim/Não | Sim/Não |
Rotina (EMS) |
|
|
|
Sub-Rotina (EMS) |
|
|
|
Localização dentro da Sub Rotina (EMS) |
|
|
|
Compact[4] | Sim/Não | Sim/Não | Sim/Não |
Home[5] | Sim/Não | Sim/Não | Sim/Não |
Posição do Portlet[6] | 0 – Top Left 1 – Top Right 2 – Bottom Left 3 – Bottom Right | 0 – Top Left 1 – Top Right 2 – Bottom Left 3 – Bottom Right | 0 – Top Left 1 – Top Right 2 – Bottom Left 3 – Bottom Right |
Informar os papeis com os quais o programa deve ser vinculado |
|
|
|
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>.
Código Papel | (máx 3 posições) |
Descrição em Português* |
|
Descrição em Inglês* |
|
[1] Nome Verbalizado é obrigatório para desenvolvimentos no Datasul 10 em diante.
[2] Tipo é obrigatório para desenvolvimento no Datasul 10 em diante
[3] Categorias são obrigatórias para os programas FLEX.
[4] Obrigatório quando o projeto for FLEX
[5] Obrigatório quando o projeto for FLEX
[6] Obrigatório quando o projeto for FLEX
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|