Histórico da Página

(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

Enviar o saldo de estoque do Protheus para o PC-Factory, por meio de solicitação do PC-Factory.

Enviar registros de saldo de estoque quando ocorrer alguma movimentação.

(Obrigatório)

Definição da Regra de Negócio

Gerenciar o envio de saldos em estoque do Protheus para o PC-Factory.  Será criado duas opções de envio. A primeira será via Request, onde o PC-Factory solicita um saldo. A segunda startada via alguma movimentação que atualiza o saldo.

1. Request

Para este tipo de atualização o PC-Factory solicita o saldo ao Protheus. 
Será a usada a mensagem StockLevel_2_00. A mensagem possui duas partes. A parte de Request , onde são passados os parâmetros para o consulta do saldo, e a parte do Return, que contem o retorno do saldo.

O Request da mensagem possui as seguintes tags que serão usadas para o Protheus:

A busca pode ocorrer das seguintes formas:
Por Produto: Retorna informação de todos os locais de estoque do produto.
Por Local de Estoque(Armazém): Retorna informação de todos os produtos no local de estoque.
Por Local de Estoque(Armazém) e Produto: Retorna informação sobre o Produto no Local de Estoque definido.

Para os demais campos, Lote, sub-Lote, número de série, localização e data de validade considerar somente se informar o código do produto. Se enviar estes campos sem o código do produto deve retornar mensagem de erro.

O Return da mensagem possui as seguintes  tags para o Protheus: 

Alterar mensagem StockLevel, gerando a versão 2_000. A mensagem terá o formato abaixo:

1.1 MATI225

O Webservice deverá ser alterado para executar o adapter MATI225 

Do Case

..........
Case cTransac == "STOCKLEVEL" //Saldo de estoque
changeEmp(cEmpIntg,cFilIntg)
aAdapter := MATI225(oXml, TRANS_RECEIVE, EAI_MESSAGE_BUSINESS)

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

Será alterado o adapter do saldo, MATI225 para tratar a nova versão da mensagem e também a integração com o PC-Factory. Criar funções v1000 e v2000 para tratar o xml de acordo com a versao

// Trata recebimento de mensagens
    Case ( nTypeTrans == TRANS_RECEIVE )
        Do Case
            // Recebimento da WhoIs
            Case ( cTypeMessage == EAI_MESSAGE_WHOIS )
                cXmlRet := '1.000'
            // Recebimento da Response Message
            Case ( cTypeMessage == EAI_MESSAGE_RESPONSE )
                cXmlRet := 'Mensagem processada'        
            // Receipt Message (Aviso de receb. em transmissoes assincronas)
            Case ( cTypeMessage == EAI_MESSAGE_RECEIPT )
                cXmlRet := 'Mensagem recebida'        
            // Recebimento da Business Message
            Case ( cTypeMessage == EAI_MESSAGE_BUSINESS )

                 CASE VERSAO = 1 OR VERSAO = ' ' OR VERSAO NULA 

                     aRet := v1000(cXml, nTypeTrans, cTypeMessage)

                CASE VERSAO = 2

                      aRet := v1000(cXml, nTypeTrans, cTypeMessage)

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

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

A função v1000 deve executar o processo ATUAL, ou seja, tratando a versão 1 da mensagem.

A função v2000 deve executar o processo considerando as alterações da mensagem para atender a integração com o PC-Factory.
Na v2000 deve considerar as mesmas regras de seleção dos campos, o que vai mudar é somente o formato do XML.

Após executar a geração da mensagem de retorno o WebService já está preparado para enviar a resposta, que será o saldo. A resposta conterá apenas um XML. Este XML pode ter um ou vários REQUEST.

Exemplo de XML Request:

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

<TOTVSMessage xsi:noNamespaceSchemaLocation=""

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <MessageInformation version="1.000">

        <UUID>459491c6-83bc-4bdf-9c49-71caac25de61</UUID>

        <Type>BusinessMessage</Type>

        <Transaction>stocklevel</Transaction>

        <StandardVersion>1.0</StandardVersion>

        <SourceApplication>PPI</SourceApplication>

        <CompanyId>99</CompanyId>

        <BranchId>01</BranchId>

        <Product version="12" name="PPI" />

        <GeneratedOn>2016-04-14T09:34:11.3137323-03:00</GeneratedOn>

    </MessageInformation>

    <BusinessMessage>

        <BusinessEvent>

            <Entity>stocklevel</Entity>

            <Event>upsert</Event>

        </BusinessEvent>

        <BusinessContent>

            <RequestItem>

                 <WarehouseInternalId>01</WarehouseInternalId>

                 <ItemInternalId>CRG01</ItemInternalId>

            </RequestItem>

        </BusinessContent>

    </BusinessMessage>

</TOTVSMessage>

           2. Movimentação

A integração deverá atualizar o saldo, sem que seja necessário realizar um request. Para atender essa necessidade deverá alterar as funções que atualizam saldo para gerar a mensagem.

Será a usada a mensagem ItemStockLevel_1_000.

2.1 Criar a mensagem

Incluir a nova mensagem ItemStockLevel contendo os seguintes campos:

 2,2 Atualização do saldo ( inlcusão do lote )

Quando incluir ou atualizar um saldo novo no ERP, deverá enviar a mensagem ao PC-Factory.

Todos os pontos que executam uma movimentação de estoque executam rotinas de atualização de saldo.

• NF de Entrada  - Função B2ATUCOMD1
• NF de Venda - Função B2ATUCOMD2
• Mov. Internas - Função B2ATUCOMD3

Estas funções serão alteradas para executar o adapter MATI255 com a opção de envio TRANS_SEND.

A execução destas do adapter nestas funções está condicionada a parametrização no PCPA109, do folder Saldo de Estoque. No PCPA109 também será definido o filtro sobre a tabela SB2.

2.2.1 Alterar Adapter MATI225 e MATA225PPI

Alterar as funções B2ATUCOMD1, B2ATUCOMD2 e B2ATUCOMD3 para executar a integração. Como será possível realizar filtros e algumas outras tratativas, deverá executar a função MATA225PPI que, depois de satisfazer os filtros deverá executar o adapter. Somente se o saldo for atualizado corretamente executar o adapter.

Exemplo:

If l PCPIntgPPI()

Criar a função MATA225PPI. Nesta função deverá executar a geração.

aRet := MATI225(cXml, nTypeTrans, cTypeMessage)

<função para enviar o XML para o WebService da PPI e recuperar o retorno> : PCPWebsPPI
Se o retorno for positivo poderá prosseguir com a inclusão/alteração e geração do XML nos diretórios correspondentes.
<função para gerar o XML nos diretórios> : PCPXmlPPI
<função para gerar tabela de integração SOF> : PCPCriaSOF

IMPORTANTE: Considerar a parametrização do PCPA109 que indica quais dessas funções deverá gerar a mensagem. Considerar a seguinte regra:

• Caso SOE.OE_VAR1 = 'S' a Função B2ATUCOMD1 deverá executar o MATA225PPI. 
• Caso SOE.OE_VAR2 = 'S' a Função B2ATUCOMD2 deverá executar o MATA225PPI. 
• Caso SOE.OE_PARINTG = 'S' a Função B2ATUCOMD3 deverá executar o MATA225PPI. 

A função MATI225 será responsável pela geração do XML. Somente o envio - TRANS_SEND.

Cabeçalho:

Quando for executado via integração com PCFactory deverá montar o cabeçalho da mensagem que consta com as tags TOTVSMessage e MessageInformation.

Abaixo modelo:

<?xml version="1.0" encoding="UTF-8" ?>
<TOTVSMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="xmlschema/general/events/ItemStockLevel_1_000.xsd">
<MessageInformation version="1.000">
<UUID>d97aeb6f-1440-8c81-fc13-ec8cf87b82ad</UUID>
<Type>BusinessMessage</Type>
<Transaction>ItemStockLevel</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>

 <ContextName>PROTHEUS</ContextName>
<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 “1.000”
UUID : Sequencial usado pelo EAI. Gerar fixo “1’.
Type: Tipo da mensagem. Gerar fixo “BusinessMessage”
Transaction: Indica o que está sendo enviado. Gerar fixo “ItemStockLevel”
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 = Rotina que foi executada pelo menu | version = versão do programa.
GenerateOn = Data e hora da geração da mensagem

ContextName = Protheus
DeliveryType:Tipo de envio da mensagem. Gerar fixo “Sync”.

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

<BusinessEvent>
<Entity>ItemStockLevel</Entity>
<Event>upsert</Event>
<Identification>
<key name="InternalId">651140049</key>
</Identification>
</BusinessEvent>

Onde:
Entity: Entidade . Gerar fixo “ItemStockLevel”
Event: Inclusão/Alteração ou exclusão. Pode ser ‘delete’ ou ‘upsert’
Identification: Código do item
Usar key name="InternalID" : gerar com o código do item B2_COD

Dentro do BusinessMessage existe o bloco BusinessContent, que contém os dados do saldo do item. 

Filtros e geração do XML ():

No cadastro de parâmetros PCPA109, é definido se gera o arquivo XML nos diretórios. Quando este indicador, OD_GERAXML, estiver como 2('N') não será gravado o arquivo XML nos diretórios correspondentes. Será gravado apenas o conteúdo em tabela (SOF).
Caso o indicador , OD_GERAXML, estiver como 1('S') deverá seguir a seguinte regra de geração:
- Processados com sucesso : XML processado pelo PPI com retorno do PCFactory OK. XML será gravado no diretório cadastrado no campo Enviados(OD_DIRENV) do PCA109.
- Processados sem sucesso : XML processado pelo PPI com retorno de ERRO pelo PCFactory ou WebService desligado ( não conseguiu enviar o XML).
 XML será gravado no diretório definido no campo Pendência (OD_DIRPEND) do PCA109. Caso gerar pendência, não deverá ser questionado se deseja salvar os dados, sempre deverá gerar pendência. 

Em ambos os casos(sucesso ou erro/pendencia), ocorrendo o commit, será gerada a tabela SOF.

Importante: Os arquivos XML´s gerados e dados da tabela SOF somente serão gerados se a inclusão/alteração/exclusão do saldo for comitada no banco.
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 - ITEMSTOCKLEVEL
DATAHORA: Data e Hora do envio
REGISTRO: Código do item

A tabela SOF conterá os seguintes campos:

Transação : Nome da tabela (SB2)
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 do PCFactory
Xml : Conteúdo do XML
Programa: Rotina que gerou o registro
Data Reprocessamento : Quando reprocessado pela rotina de pendências
Hora Reprocessamento : Quando reprocessado pela rotina de pendências

IMPORTANTE:

• Só poderá ter uma pendência para o registro.
• Para gerar o XML e gravar a tabela SOF terá que respeitar as pendências 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. 
  
  

Filtros:
No PCPA109 são definidos os filtros que indicam quais registros serão enviados ao PCFactory.

Para o saldo em estoque poderá ter até 3 filtros. Filtro da tabela SB2, SB8 e SBF.

Deverá ler os dados da tabelas SOE onde o campo OE_TABELA seja = 'SB2', OE_TABELA seja = 'SB8' e OE_TABELA seja = 'SBF'. Deverá fazer o JOIN destas tabelas para montar o filtro.

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.
Usar 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. 
A função irá retornar TRUE se satisfazer a condição, ou seja, a estrutura pode ser enviado ou false caso não satisfaça.

Observação

•  Se não existir filtro na SOE , OE_FILTRO, enviará todos os registros, ou seja, a função sempre retornará TRUE.
  
  

<Regra de negócio é o que define a forma de fazer o negócio, o processo definido e/ou as regras que devem ser contempladas. Devem ser descritas restrições, validações, condições e exceções do processo. Caso necessário, incluir neste capítulo também regras de integridade que devem ser observadas no momento do desenvolvimento>.

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

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*/

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Procedimentos

Programas

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