fin.nrd.reg.e.001 - registro 4.2.1 - clientes e fornecedores_v4

RICEF – ESPECIFICAÇÂO DETAIL

Módulo SAP - FIComplexidade MediumSolicitação FIN.NRD.REG.E.001 - Registro 4.2.1 - Clientes e FornecedoresDescrição Registro 4.2.1 - Clientes e Fornecedores

1. Responsáveis pela RICEF DetailNomes do criador do documento por parte da Accenture e do aprovador por parte da Unilever.

Empresa Nome Telefone E-mail

Criador – HL Accenture Gustavo Dumont 011 – 3306-8896 [email protected]

Validador – HL Accenture Johnny Hamamura 011 – 3306-8896 [email protected]

Aprovador Unilever Estela Zilioto - [email protected]

2. Tipo da RICEFDefinição do tipo de solução a ser desenvolvida.

Report Interface Conversion Enhancement FormX

3. Objetivo e Escopo

Descrever – detalhadamente – o cenário no qual o GAP será inserida.

Esta especificação tem como objetivo criar uma transação em que possibilite gerar um arquivo

em formato txt de acordo com as informações do “Registro 4.2.1 - Clientes e Fornecedores”.

Para gerar este aquivo, será necessário executar a transação em “Background” e assim, este

arquivo txt será salvo no “servidor UNIX” ou será salvo via “Spool”.

4. Situação Atual – Problema/DefeitoDescrever a situação atual do cenário em relação ao escopo

Atualmente não existe esta funcionalidade dentro do SAP, impossibilitando assim, a extração

das informações de acordo com o “Registro 4.2.1 - Fornecedores e Clientes” e o envio do

arquivo txt para a EY.

5. Premissas da Solução

Modificado: 4/21/2023 11:08 AM©2010 Accenture. Todos Direitos Reservados.

1 de 11 Última modificación:

mailto:[email protected]





Listar as premissas que influenciam a solução a ser desenvolvida.

O escopo deste projeto atende apenas ao país Brasil;

Irão ser utilizados os dados existentes dentro dos ambientes para a realização das provas.

Se necessário criar dados, os usuários deverão gerá-los;

Considerado suporte das 08:00 as 17:00 em días úteis (Brasil);

Será de responsabilidade do negócio abrir algúm ticket (CSR, SIR, REs) caso necessário;

Não será considerado integração com qualquer legado;

Qualquer modificação diferente dos mencionados em esta documentação, será

considerado como “Change Request” dentro do projeto;

Em esta transação não será possível realizar nenhuma modificação, sua funcionalidade é

de gerar um arquivo txt com as informações existentes no ambiente a ser executado;

Não está sendo considerado nenhuma atividade de “Performance”;

Não está sendo considerado documentos “Archives (documentos arquivados)”.

Os arquivos txt, serão salvos apenas no servidor “UNIX” ou apenas via “SPOOL”. Ainda

está sendo definido a melhor solução.

6. Definição da Solução e Especificação funcionalExplicar, resumidamente, lo que hará el programa a ser desarrollado.

Em esta especificação será detalhado como será criado a nova transação para que seja

possível gerar um arquivo txt conforme as informações do “Registro 4.2.1 – Clientes e

Fornecedores”. Este arquivo irá trazer todas as movimentações de clientes e fornecedores

independentemente se foram pagos ou não.

Esta transação será executado em “Background” e assim salvo no “servidor UNIX” ou via

“SPOOL” devido ao seu tamanho e quantidade de dados.

Para gerar o arquivo txt, será utilizada as seguintes tabelas:





Para Fornecedor

BSIK ( Nesta tabela, será encontrado os documentos em abertos)

BSAK ( Nesta tabela, será encontrado os documentos pagos)

Para Clientes

BSID (Nesta tabela, será encontrado os documentos em abertos)

BSAD (Nesta tabela, será encontrado os documentos pagos)

Para Clientes e Fornecedores

BSEG (Nesta tabela, será encontrado os itens dos documentos)

6.1 Tela de Seleção – Registro 4.2.1 Fornecedores e Clientes:





Obs: Durante a execução, o programa deverá validar se a data de contabilização preenchida é

o mesmo ano inserido na tela de seleção. Caso não seja, o programa deverá mostar uma

mensagem de erro impossibilitando assim a execução.

Legenda:

6.2 Layout – TXT

Obs: Ao gerar o arquivo txt, o programa deverá realizar diferentes buscas dependendo do que

for selecionado no “Radion Button” da tela de seleção.

Caso seja selecionado “Fornecedor”, o programa deverá utilizar as tabelas BSIK e

BSAK e caso seja selecionado “Cliente”, o programa deverá utilizar as tabelas BSID e BSAD.





Obs2: Os campos “Data da Operação”, “Data de Emissão do Documento” e “Data do

Vencimento” deverão vir da seguintes maneira: (sem pontos ou barras)

Exemplo: DDMMAAAA – 28012014

Obs3: Os campos “Valor da Operação” e “Valor Original do Título” deverão vir da seguinte

maneira:

Exemplo: Como este campo possui 17 caracteres, o valor deverá vir preenchido a direita e o

restante dos caracteres deverá vir com zeros a esquerda e os 2 primeiros digitos a direita são

os campos decimais. Não poderá ter ponto ou vírgula para separar os números.

Valor: 25 mil reais - 00000000002500000

00 – Decimais

25000 – Valor do documento sem decimais

0000000000 – quantidade de zeros até dar 17 caracteres

Obs4: Para gerar o arquivo txt, não deverá vir as informações de cabeçalho.

6.3 - Lógica do Programa:

Ao ser selecionado o “Radion button Fornecedor”, o programa deverá primeiramente, deixar

desabilitado o campo “Cliente” na tela de seleção. Caso seja selecionado o “Radion button

Cliente”, o programa deverá desabilitar o campo “Fornecedor” da tela de seleção.





Ao executar o programa e caso não tenha sido preenchido o campo “Tipo da

Operação”, o programa deverá considerar os seguintes tipos de documentos (será

criado uma paramneg):

Legenda

Assim, junto as informações inseridas na tela de seleção + os tipos de documentos informados

acima, deverá ser utilizada para fazer as buscas nas tabelas dependendo do que foi marcado

no “Radio Button”, ou seja, caso seja marcado “Fornecedor”, o programa deverá pegar as

informações nas tabelas BSIK e BSAK e caso seja marcado “Cliente”, nas tabelas BSID e

BSAD.





Dessa maneira, para montar o arquivo txt no campo “Tipo da Operação”, o programa deverá

verificar qual o tipo do documento + se é debito ou crédito para obter o “Tipo da Operação”.

Ao executar o programa e o campo “Tipo da Operação” tenha sido preenchido, o

programa deverá primeiramente eliminar todos os tipos de documentos que não

estejam cadastrados na paramneg para esse tipo de Operação.

Assim, o programa irá buscar nas tabelas as informações inseridas na tela de seleção +

os tipos de documentos para este tipo de operação.

Além disso, o programa deverá realizar uma nova busca para verificar se os

documentos são “Credito” ou “Debitos”, pois é possível ter o mesmo tipo de documento

mas para “Credito” ele é um tipo de operação e para “Debito” é um outro tipo.

Exemplo: Conforme imagem abaixo, para o mesmo tipo de documento, é possível ter 2

tipos de operações. Dessa maneira, será realizado uma nova busca para que seja

possível definir o campo “Tipo da Operação” de cada documento.

Parmdesc Char1 Char2

Tipo de Documento H - Credito / S - Debito Tipo da OperaçãoDK H R

DK S B

Para buscar o campo “Data do Vencimento”, o programa deverá buscar o campo

“ZFBDT” e somar com o campo “ZBD1T” e assim será possível somar a data base + as

condições de pagamento por documento.

Exemplo:





Data Base Condição de Pgto Resultado

ZFBDT ZBD1T -

01012014 10 11012014

Para buscar o campo “Valor Original do Titulo”, o programa após a seleção das tabelas

BSID/BSAD ou BSIK/BSAK, deverá pegar o documento contábil (BELNR) e ir na tabela

BSEG com o documento (BSEG – BELNRS) + empresa (do documento) + ano (do

documento).

Assim, com essa busca, o programa deverá buscar o campo “Conta Razao (BSEG –

HKONT) de acordo com a nova tabela Z a ser criada para o armazenamento das contas

contábeis de desconto e assim pegar o valor do campo “Montante em moeda local

(BSEG – DMBTR).

Obs: Nesta tabela Z, deverá conter 3 colunas, a qual as 2 primeiras deverão ser

campos obrigatórios e o último, ao inserir as informações da coluna 1 e 2, deverá ser

preenchido automaticamente.

Para o preenchimento automático, o programa deverá pegar a conta inserida nda

coluna 2 e ir na tabela com “SKAT – SAKNR” e pegar o campo “SKAT – TXT50”. Alem

disso, o idioma é sempre PT (SPRAS) e o plano de contas será sempre SCOA

(KTOPL).



Empresa Cta Contábil Descrição2236 21201031 DESCONTO S/VENDA PRODUTOS EM MAU ESTADO



Caso haja mais de uma conta razao encontrado para este documento, o programa

deverá sumarizar todos os itens do documento contábil.

Com este valor, deverá ser somado com o campo “BSID/BSAD – DMBTR ou

BSIK/BSAK – DMBTR) do documento, trazendo assim o valor do campo “Valor Original

do Titúlo”.

Exemplo:

Para buscar o campo “Número de Arquivamento”, o programa deverá concatenar os

seguintes campos e colocar um traço entre eles: (Centro Físico + Local de Negócio)

Centro Físico: BSEG – WERKS

Para este campo, após coletar os documentos na BSID/BSAD ou BSIK/BSAK, ao inserir

esses documentos na bseg com documento + ano + empresa, o programa deverá

coletar o campo “Centro Físíco” do item em que o campo “Cliente – KUNNR ou

Fornecedor – LIFNR” esteja preenchido.

Local de Negócio: BSIK/BSAK ou BSID/BSAD – BUPLA

Para este campo, o programa irá encontrá-lo nas tabelas iniciaís.

Resultado final: 5446-4575





Para buscar o restante dos campos, o programa encontrará todos os valores e campos

nas tabelas BSID/BSAD ou BSIK/BSAK.

Assim, após todas as seleções, o programa deverá gerar um txt em que cada campo

deverá estar na posição correta conforme item “6.2 – Layout TXT”.

Este arquivo TXT, ficará disponível no servidor “UNIX” ou via “SPOOL” a qual os

usuários irão definir o caminho e o nome do arquivo a ser gerado. Para acessar o

servidor, o usuário irá utilizar a transação ZUNIX. Para extrair este arquivo, será

utilizado as transações CG3Y ou AL11.

Caso o arquivo seja enviado para SPOOL, o usuário deverá acessar o spool gerado e

extrair as informações.

Após gerar o arquivo TXT, deverá aparecer uma mensagem informando que foi gerado

com sucesso o arquivo txt.(Arquivo gerado com sucesso)

Caso ocorra algum erro e o arquivo não tenha sido gerado, deverá aparecer uma

mensagem de erro. (Arquivo não pode ser gerado)

7.0 - TestesEn esta sección, el equipo de Configuración DC deberá proveer al equipo de desenvolvedores, todos los datos requeridos para las Pruebas Unitarias, así como los resultados esperados.

Ambiente Teste Unitários: ZMF





Condiciones de Testes:

# Teste Unitários Dados para Teste Resultado Esperado

1

Acessar a nova transação e inserir

os campos obrigatórios.SAP ZMF-310 Gerar com sucesso o arquivo txt.

8.0 - Histórico de Versión Alterações feitas em cada versão do documento

Data Versão Descrição Autor

28.01.2014 1.0 Gustavo Dumont



fin.nrd.reg.e.001 - registro 4.2.1 - clientes e fornecedores_v4

Documents