05 - (017) - EF - RM TotvsIntegração Da FOLHA

Especificação Funcional
Descrição da Funcionalidade
Solicitante: Brener Sales
Descrição: Integração da Folha e pagamentos específicos de pessoal

ID GAP: 002
e impostos e integração da folha para a contabilização no S4
Consultor Funcional: Eduardo Quintanilha Módulo: FI-GL
Consultor Técnico: Joelson Matias
Power-user: Brener Sales
Usuário Chave: Brener Sales
Autor Documento Localização (repositório / path / nome)

Eduardo Quintanilha
HISTÓRICO DE REVISÃO
Versão Data Descrição Modificado por
1 18/06/2021 Criação do documento
2 20/09/2021 Montagem do Documento Eduardo Quintanilha
SUMÁRIO
OBJETIVO 3
DESCRIÇÃO DO PROCESSO 4
TIPO DE DESENVOLVIMENTO – J58-017I01 5

Detalhes do Desenvolvimento 6
Comunicação/ Sistemas 6
Característica da Solução 6
Detalhes campos: 7
Componentes Requeridos para Interfaces 8
Diagrama Lógico 8
Sistema de Origem 8
Tecnologia de Comunicação 8
Leiaute 8
Cabeçalho 9
Itens 11
Determinação campo Divisão e Local de Negócio 13
Regras de Negócio 13
Autorizações 13
Sistema de Destino 13
Tecnologia de Comunicação 13
Leiaute 13
Regras de Negócio 15
Verificação de consistência dos itens 3.2.2.3 e 3.2.2.4 15
Mapeamento 17
Volume de dados 17
Frequência de Execução 17
Tipo de desenvolvimento – J58-017F02 18

Componentes Requeridos para FORMS e Reports (Aplicativos) 18
Ações sobre os Dados 18
Layout do Aplicativo 18
Protótipo da Tela de Log 19
Detalhamento dos Campos 19
Ações/Iterações na tela do Aplicativo 19
Cenários de teste 19
Cenário: 19
Componentes Requeridos para FORMS e Reports (Aplicativos) 19
Confidencial / 3 Corações
Especificação Funcional Estruturante 5.0 - Implantação S/4HANA Pag. 2 de 24
Ações sobre os Dados 19

Layout do Aplicativo 19
Protótipo da Tela de seleção do APP 20
Detalhamento dos Campos 20
Seleção 20
Ações/aLterações na tela do Aplicativo 23
Cenários de teste 23
Cenário: Gravação de documentos contábeis 23
REFERÊNCIAS 24
1. OBJETIVO
Aperfeiçoar a integração da folha de pagamento - RM x SAP, dando mais celeridade, possibilidade de

checagens e segurança ao processo.
2. DESCRIÇÃO DO PROCESSO
A integração atualmente funciona através da geração de arquivos com origem no RM apenas para
contabilização de FOLHA, posterior à geração do arquivo, conferido manualmente pela contabilidade em
uma atividade que demanda em torno de 6 horas, por fim importado no SAP.
Utilizando uma tecnologia eficiente (sem arquivos/conferência manual), como por sugestão WebService,
PI/PO.
3. TIPO DE DESENVOLVIMENTO – J58-017I01
ID: DESCRIÇÃO:
Report Interface X Conversion Enhancements Forms Workflow
3.1. Detalhes do Desenvolvimento
Será criado um programa para o tráfego de dados do RM (solução Folha) para o SAP.
Esse programa, receberá informações via WEBSERVICE e disponibilizará essas informações para as
devidas contabilizações da folha de pagamento no SAP.
No momento do recebimento das informações o programa devolverá uma mensagem de sucesso ou erro.
Caso haja a mensagem de sucesso, o usuário deverá clicar no botão Contabilizar para que a folha seja
contabilizada no SAP.
A disponibilização das informações a pagar serão dispostas em outro GAP.
3.1.1.Comunicação/ Sistemas
Utilizaremos o SAP PI como integrador entre o sistema RM e o S4 onde será disponibilizado um

WebService do tipo SOAP/XML ou do tipo REST/JSON (também chamado de API ou WebService).
Uma única interface síncrona (com resposta na mesma chamada) onde o RM enviará todas as informações
de contabilidade para a validação ABAP e daí teremos a resposta voltando para o legado.
3.1.2.Característica da Solução
-Controle de dados interfaceados.
Os dados serão armazenados em uma tabela com todos os campos interfaceados que serão citados neste
documento.
-Relatório de conferência.
Logo ao receber os dados a interface não irá efetivar a contabilização de imediato.
Botão Simular: Antes da contabilização será possível exibir um relatório com todos os dados recebidos para
que o usuário possa conferir antes da efetiva contabilização.
-Botão Eliminar
Caso exista algum problema com os dados, para que não sejam necessários estornos no FI-GL, e tendo em
vista que a movimentação ainda não é efetiva, será possível eliminar as informações recebidas e aguardar
uma nova execução após ajuste realizado no RM.
-Botão Contabilizar:
Após os dados de toda a contabilização conferidos, através do botão contabilizar será possível
efetivar/gravar os dados enviados.
-Relatório de Logs da interface:
Para acompanhamento da TI do que está sendo interfaceado, através de um relatório será possível verificar
o status da chegada da movimentação no S4/Hana.
3.1.3.Detalhes campos:
Campos:
Conta Contábil e Centro de Custo.
O RM irá utilizar os códigos de conta contábil e centro de custo mapeados pelas áreas de negócio para que
os eventos sejam contabilizados corretamente.
Campo:
Montante/Valor
Representa o montante de cada item do documento a contabilizar, onde a totalização dos montantes deve
resultar em R$0,00 para fechar o documento e estar apto a contabilização.
Um documento pode ter no mínimo dois itens sendo um débito e um crédito.
No máximo 9.999 itens entre débitos e créditos.
Exemplo:
Crédito
Conta contábil 2140100001/Ordenados e salários a pagar R$55.246,76-
Débito
Conta contábil 4413000001/Ordenados e Salários R$55.246,76
Totalização de itens do documento R$0,00
Campos:
Centro de Lucro e Segmento.
O preenchimento de Centro de Lucro e Segmento em lançamentos onde teremos despesa envolvida,

seguirá a derivação automática do SAP partindo do Centro de Custo.
O preenchimento de Centro de Lucro e Segmento onde não tenhamos despesa envolvida, deverá seguir
mapeamento em GAP especificado/desenvolvido para atender o spliting do New-GL.
3.2. Componentes Requeridos para Interfaces
3.2.1.Diagrama Lógico
N/A
3.2.2.Sistema de Origem
RM
3.2.2.1. Tecnologia de Comunicação
☐ABAP Proxy X Web Service (REST)

☐IDOC ☐Banco de dados
☐RFC ☐Arquivo texto
Web Service (SOAP) ☐Outro:
3.2.2.2. Leiaute
Conforme segue itens abaixo:
3.2.2.3. Cabeçalho
Cabeçalho:
Especificação Funcional SAP Raiz - Implantação S/4HANA Pag. 9 de 24
1 - Empresa: Verificação do código empresa SAP
Com a raiz do CNPJ (primeiros 8 números do campo CGC) ir a CDS P_CompanyCodeAddl e selecionar:
Tipo de Parâmetro (party) fixo: ‘J_1BCG’

Valor Parâmetro (paval), (preencher com 8 dígitos do CGC)
Com as informações acima obter a Empresa (CompanyCode).
2 - Preenchimento do campo Referência:
Folha (fixo) - mês/ano + LN
Folha: Texto fixo

Mês/ano: BKPF - BUDAT
LN: verificar item 3.2.2.5 - Determinação campo Divisão e Local de Negócio
3 - Datas:
Data de Geração = Data de Documento

Data de Lançamento = Data de Lançamento
OBS: A data de lançamento e a data do documento devem ser a mesma.
3.2.2.4. Itens
Ítem
4 - Preenchimento campo Atribuição:
Preencher com Centro de Custo + Evento (espaço entre as informações)

Centro de Custo = BSEG - KOSTL
Evento: Ler as informações recebidas e buscar conteúdo da posição 103 a 106. (campo complemento no
Layout RM)
5 - Criação SM30 (Parâmetros RM) nome sugerido.

Haverá a necessidade de criação de uma tabela de parâmetros (SM30) com as informações abaixo
para o preenchimento dos campos Divisão e Local de Negócio.
Segue estrutura da Tabela BSEG:
Obs:
Todos os campos deverão ser preenchidos manualmente pela área responsável.
O campo Matriz não será utilizado para esse GAP.
3.2.2.5. Determinação campo Divisão e Local de Negócio
Com o campo Centro de Custo, recebido no layout e divisão encontrado no dado mestre
do Centro de Custo (CSKS), ir a Tabela/SM30 e buscar o campo Local de Negócio.
Após encontrado preencher os campos na BAPI acima (item 3.2.2.4)
Onde: Centro de custo = BESG - KOSTL = CSKS - KOSTL

Ir a CSKS - KOSTL e buscar CSKS - GSBER.
Com CSKS - GSBER ir a SM30 (Parâmetros RM)

Buscar BUPLA
Após encontrar as informações, preencher a BAPI para criação dos documentos
contábeis..
BSEG - GSBER = SM30 / GSBER e

BSEG - BUPLA = SM30 / BUPLA
OBS: deverá ser criada uma Extensão na BAPI_ACC_DOCUMENT_POST para que

seja incluído o campo Filial (Local de Negócio).
3.2.2.6. Regras de Negócio
Uma única interface síncrona (com resposta na mesma chamada) onde o RM enviará todas as informações
de contabilidade para a validação ABAP e daí teremos a resposta voltando para o legado.
3.2.2.7. Autorizações
N/A
3.2.3.Sistema de Destino
SAP
3.2.3.1. Tecnologia de Comunicação
X ABAP Proxy ☐Web Service (REST)

☐IDOC ☐Banco de dados
☐RFC ☐Arquivo texto
Web Service (SOAP) ☐Outro:
3.2.3.2. Leiaute
Tabela ZDADOS:
LOG:
3.2.3.3. Regras de Negócio
Verificação de consistência dos itens 3.2.2.3 e 3.2.2.4
Após a recepção dos dados o programa irá realizar uma conferência nestes verificando dados básicos e a
possibilidade de contabilização.
Empresa: Verificação do código empresa SAP
Com a raiz do CNPJ (primeiros 8 números do campo CGC) ir a CDS P_CompanyCodeAddl e selecionar:
Tipo de Parâmetro (party) fixo: ‘J_1BCG’
Valor Parâmetro (paval), (preencher com 8 dígitos do CGC)
Com as informações acima obter a Empresa (CompanyCode).
Caso não encontrado registro devolver ao RM a mensagem:
“Empresa SAP não existe”
Conta do Razão: Verificação da conta contábil do razão enviada.
Com a empresa buscar verificar a conta contábil:

Empresa: (P_CompanyCodeAddl – CompanyCode)
Onde: (P_CompanyCodeAddl – CompanyCode = ESH_N_GL_ACC_COCD_SKB1 - bukrs)
Campo:
Conta Contábil: saknr
“Conta Razão & não existe para empresa &.”
Centro de Custo: Verificação do centro de custo enviado.
CDS: VFCO_CSKS_SHV_NO_AUTH
Preencher o campo Área de Contabilidade de Custos:
Onde: kokrs = AC3C (fixo)
Com a Área de Contabilidade de Custos buscar o Centro de Custo:
Campo: kostl

“Centro de Custo & não existe.”
Tamanhos e Formatos
Além da validação destes itens básicos, também devem ser aplicadas validações de tamanhos e formatos
dos valores recebidos dos campos quando não forem exatos, para isto deverá ser aplicado às mensagens
Standards dos elementos de dados de cada campo.
Montante formato. (CURR 23 posições / Separado por vírgula últimas duas casas decimais)
Moeda formato. (CHAR 3 posições / Fixo: BRL)
Datas
Data de Documento e Data de Lançamento formato. (DDMMAAAA)
Tipos de documento
Tipo de Documento valida a existência do objeto SAP. (CHAR 2 posições / RM - Contábil)
Tabelas/CDS:
a) ZDADOS (Layout item dados 3.2.3.2)
Criar uma CDS Z com os campos abaixo para armazenamento dos dados:
Tabela/CDS para armazenar todas as informações de dados na interface que serão recebidas.
Na sua estrutura deve possuir os seguintes campos como chave.
- Identificação (ZIDENTIFICAO)
Objeto criado na SNUM denominado “MOVFOLHA” com intervalo de numeração acionado a cada execução
da interface e chegada de dados para controle de todas as informações que serão recepcionadas.
Intervalo ‘0000000001’ á ‘9999999999’
Através deste será controlado o que possui erro, sucesso e contabilizado.
- Status (ZSTATUS)
S – Sucesso (quando dados importados não tiverem erro na validação)

E – Erro (erros nos dados importados)
C – Contabilizado (após disparada BAPI para contabilização)
E – Eliminado (dados deletados)
- Empresa: CDS (P_BKPF_COM - BUKRS)

- Data de Lançamento: CDS (P_BKPF_COM - BUDAT)
- Referência: CDS (P_BKPF_COM - XBLNR)
- Quantidade de Itens
- Data da execução da Interface
- Hora da execução da Interface.
- Mensagem Standard BAPI
***Após execução da BAPI e geração dos documentos (efetivação) gravar na tabela o número do respectivo
documento gerado em cada registro com a mensagem standard gerada:
“Documento & gravado Empresa &’
Exemplo:
Documento 1
10 Itens (Registros na tabela)
Gravar a mensagem nos 10 registros.
Documento 2
2 Itens (Registros na tabela)
Gravar a mensagem do novo documento nos 2 registros.
Tabelas/CDS
b) ZLOG (Layout item LOG 3.2.3.2)
Tabela/CDS para armazenar os logs do que está sendo interfaceado e seus respectivos status.
Criar uma CDS Z com os campos abaixo para armazenamento dos dados:
Campos necessários:
ZStatus, ZDenominação do Status, ZData Criação, ZHora Geração, ZIdentificação e ZTexto do Erro.
Observação: Quando houver erro na execução a cada mensagem retornada pela BAPI será criada linha de
registro repetindo todos os campos e exibido a mensagem no campo TEXTO DO ERRO.
Quando for sucesso apenas será necessário armazenar um único registro com o campo TEXTO DO ERRO
em branco.
3.2.3.4. Mapeamento
O Mapeamento consta no Layout do item 3.2.3.2
3.2.3.5. Volume de dados
☐Alto X Médio ☐Baixo

3.2.3.6. Frequência de Execução
X Eventual (mensalmente)
☐Programado por Job:
4. TIPO DE DESENVOLVIMENTO – J58-017F02
ID: DESCRIÇÃO:
Report Interface Conversion Enhancements Forms X Workflow
4.1. Componentes Requeridos para FORMS e Reports (Aplicativos)
Criação de um APP para verificação dos Logs.
4.1.1.Ações sobre os Dados
Ações:
X Exibir ☐Editar
☐Criar ☐Deletar
4.1.2.Layout do Aplicativo
Fiori Elements:
X List Report ☐Analytical Page
☐Worklist Page ☐Overview Page
☐Object Page
Fiori Freestyle: Essa opção deve ser utilizada apenas em exceções.
☐Freestyle
4.1.3.Protótipo da Tela de Log
4.1.4.Detalhamento dos Campos
Conforme item 3.2.3.2 (b) ZLOG)
4.1.5.Ações/Iterações na tela do Aplicativo
N/A
4.2. Cenários de teste
Preencher os dados de parâmetros para verificação das informações:
4.3. Cenário:
Empresa: 2000
Status: S
Data de Lançamento: data do dia de lançamento
4.4. Componentes Requeridos para FORMS e Reports (Aplicativos)
Criação de um APP para verificação dos Logs.
4.4.1.Ações sobre os Dados
Ações:
X Exibir ☐Editar
☐Criar ☐Deletar
4.4.2.Layout do Aplicativo
Fiori Elements:
X List Report ☐Analytical Page
X Worklist Page ☐Overview Page
☐Object Page
Fiori Freestyle: Essa opção deve ser utilizada apenas em exceções.
☐Freestyle
4.4.3.Protótipo da Tela de seleção do APP
Após a execução, os dados deverão ser exibidos com todas as características e funcionalidades previstas
para o tipo de relatório.
4.4.4.Detalhamento dos Campos
a) Seleção
b) Relatório de conferência:
4.4.5.Ações/aLterações na tela do Aplicativo
-Relatório de conferência.
Ao receber os dados a interface não irá efetivar a contabilização de imediato.
-Botão Simular: Antes da contabilização será possível exibir um relatório com todos os dados recebidos
para que o usuário possa conferir antes da efetiva contabilização.
Esse botão vai disparar a BAPI mapeada, porém sem gravação.

Caso de teste: TESTE_GL_QUINTANILHA_BAPI_GAP
-Botão Eliminar
Caso exista algum problema com os dados, para que não sejam necessários estornos no FI-GL, e tendo em
vista que a movimentação ainda não é efetiva, será possível eliminar as informações recebidas e aguardar
uma nova execução após ajuste realizado no RM.
-Botão Contabilizar:
Após os dados de toda a contabilização conferidos, através do botão contabilizar será possível
efetivar/gravar os dados enviados.
Após este pressionado será exibido na tela um popup para validação:
Botão SIM: executa a contabilização (BAPI_ACC_DOCUMENT_POST)
Botão NÃO: retira o poup-up da tela.
Caso de Teste: TESTE_GL_QUINTANILHA_BAPI_GAP
4.5. Cenários de teste
Gravar lançamentos contábeis da Folha
4.6. Cenário: Gravação de documentos contábeis
Selecionar informações de parâmetros e verificar em tela:

Gravar informações para gravação de documentos contábeis e verificar.
5. REFERÊNCIAS
N/A

05 - (017) - EF - RM TotvsIntegração Da FOLHA

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

05 - (017) - EF - RM TotvsIntegração Da FOLHA

Enviado por

Direitos autorais:

Formatos disponíveis

Especificação Funcional

Solicitante: Brener Sales

Descrição: Integração da Folha e pagamentos específicos de pessoal

Consultor Funcional: Eduardo Quintanilha Módulo: FI-GL

Consultor Técnico: Joelson Matias

Power-user: Brener Sales

Usuário Chave: Brener Sales

Autor Documento Localização (repositório / path / nome)

TIPO DE DESENVOLVIMENTO – J58-017I01 5

Tipo de desenvolvimento – J58-017F02 18

Ações sobre os Dados 19

Aperfeiçoar a integração da folha de pagamento - RM x SAP, dando mais celeridade, possibilidade de

3. TIPO DE DESENVOLVIMENTO – J58-017I01

3.1. Detalhes do Desenvolvimento

Utilizaremos o SAP PI como integrador entre o sistema RM e o S4 onde será disponibilizado um

-Controle de dados interfaceados.

Logo ao receber os dados a interface não irá efetivar a contabilização de imediato.

-Relatório de Logs da interface:

O preenchimento de Centro de Lucro e Segmento em lançamentos onde teremos despesa envolvida,

3.2. Componentes Requeridos para Interfaces

3.2.2.1. Tecnologia de Comunicação

☐ABAP Proxy X Web Service (REST)

Conforme segue itens abaixo:

1 - Empresa: Verificação do código empresa SAP

Tipo de Parâmetro (party) fixo: ‘J_1BCG’

2 - Preenchimento do campo Referência:

Folha (fixo) - mês/ano + LN

Folha: Texto fixo

Data de Geração = Data de Documento

OBS: A data de lançamento e a data do documento devem ser a mesma.

4 - Preenchimento campo Atribuição:

Preencher com Centro de Custo + Evento (espaço entre as informações)

5 - Criação SM30 (Parâmetros RM) nome sugerido.

Segue estrutura da Tabela BSEG:

3.2.2.5. Determinação campo Divisão e Local de Negócio

Onde: Centro de custo = BESG - KOSTL = CSKS - KOSTL

Com CSKS - GSBER ir a SM30 (Parâmetros RM)

BSEG - GSBER = SM30 / GSBER e

OBS: deverá ser criada uma Extensão na BAPI_ACC_DOCUMENT_POST para que

3.2.2.6. Regras de Negócio

3.2.3.1. Tecnologia de Comunicação

X ABAP Proxy ☐Web Service (REST)

3.2.3.3. Regras de Negócio

Verificação de consistência dos itens 3.2.2.3 e 3.2.2.4

Empresa: Verificação do código empresa SAP

Conta do Razão: Verificação da conta contábil do razão enviada.

Com a empresa buscar verificar a conta contábil:

Centro de Custo: Verificação do centro de custo enviado.

Caso não encontrado registro devolver ao RM a mensagem:

Data de Documento e Data de Lançamento formato. (DDMMAAAA)

Tipo de Documento valida a existência do objeto SAP. (CHAR 2 posições / RM - Contábil)

a) ZDADOS (Layout item dados 3.2.3.2)

Na sua estrutura deve possuir os seguintes campos como chave.

S – Sucesso (quando dados importados não tiverem erro na validação)

- Empresa: CDS (P_BKPF_COM - BUKRS)

- Mensagem Standard BAPI

“Documento & gravado Empresa &’

O Mapeamento consta no Layout do item 3.2.3.2

3.2.3.5. Volume de dados

☐Alto X Médio ☐Baixo

4. TIPO DE DESENVOLVIMENTO – J58-017F02

4.1. Componentes Requeridos para FORMS e Reports (Aplicativos)