4 ÁREAS DE CONSULTORIA
5.1 P ROJECTOS SAP
5.1.1 Programa de Etiquetas
Este projecto consistiu na criação de um programa de impressão de etiquetas para um cliente da Deloitte.
Este projecto está relacionado com o módulo de Gestão de materiais e com o módulo ABAP.
5.1.1.1 Caracterização do cliente
O cliente deste projecto é uma multinacional especializada no Trading, que através de uma pesquisa mundial de soluções oferece aos seus clientes uma concentração dos melhores fornecedores em termos de qualidade, preço e capacidade de resposta. Neste caso os seus clientes são firmas do mesmo grupo que actuam em diferentes sectores de negócio, como por exemplo: sector das bebidas, retalho, construção, alimentação.
38
Este cliente opera principalmente no mercado Angolano onde factura anualmente valores superiores a quinhentos milhões de euros anuais. Um estudo da Revista Exame, que abrangeu 26 sectores de actividade, indica as melhores e maiores empresas portuguesas do ano 2008, o cliente ficou posicionando em 137º no ranking das 500 empresas do topo.
5.1.1.2 Requisitos
O cliente lançou recentemente uma loja de mobiliário e necessitava de simplificar o processo de etiquetagem dos seus produtos em exposição. O processo que estava implementado consistia em desenhar o layout da etiqueta manualmente, colocar os dados a constar na etiqueta no programa da impressora, gerar o código de barras manualmente e juntar ao desenho.
Neste processo foram identificados vários problemas:
Processo demorado, pois o layout era desenhado totalmente de forma manual, e o código de barras tinha que ser gerado manualmente;
Os empregados tinham que ter formação sobre o programa de desenho; O layout apresentava inconsistências de produto para produto.
5.1.1.3 Implementação
Para esta implementação o cliente pretendia um programa simples de operar: os funcionários do armazém efectuam a inserção do número do material em sistema e o número de cópias pretendidas, para a obtenção das etiquetas.
As etiquetas deveriam conter as seguintes informações: preço, descrição, unidade de venda (Kg, Litro, Metro, Caixa, Unidade, etc.), proveniência, logotipo da loja, número em sistema e código de barras.
Como os produtos podem vir de vários armazéns, foi adicionado um terceiro campo na tela do programa, com o número do centro, que corresponde ao armazém. Deste modo, só será possível imprimir etiquetas que correspondam aos materiais que existem em cada armazém.
Na Figura 16 podemos observar a tela do programa, onde são visualizados os campos a inserir. São todos de preenchimento obrigatório, caso não estejam preenchidos ou não existam na base de dados, o programa gera uma mensagem de erro.
Figura 16 - Tela do programa de impressão de etiquetas
Os dados foram adquiridos a partir de consultas às respectivas tabelas da base de dados. Na Figura 17 podemos observar as tabelas principais usadas e as suas relações. Neste caso as principais tabelas são:
MARA contém os dados gerais dos materiais; MAKT contém as descrições para cada língua; MARC contém o centro para cada material.
As tabelas relacionam-se entre si através campo MATNR que corresponde ao número de material.
De salientar que a tabela MARA contém um campo denominado EAN11 que corresponde ao código de barras, que quando configurado em Smartforms, apresenta o código de barras. Foi criada uma tabela auxiliar para configurar as impressoras por centro (Figura 18), com o nome da impressora em sistema. Esta tabela permite que as etiquetas sejam impressas apenas na impressora destinada para o efeito, eliminando o erro humano na escolha da impressora. Só utilizadores com permissões podem aceder à configuração desta tabela. Na Figura 19 podemos observar a lista de impressoras configuradas para o programa.
40
Figura 17 - Principais relações entre as tabelas de Materiais
Figura 18 - Tabela configuração impressoras
Figura 19 - Listagem de impressoras configuradas para o programa
O layout foi desenhado em Smartforms, a ferramenta que permite desenhar formulários. Na Figura 20 podemos observar o layout final e na Figura 21 podemos observar a etiqueta no seu estado final depois de impressa. O campo BARCODE tem que ser configurado com a
propriedade EAN11 de forma a que o código de barras possa ser visível com o formato de código de barras, senão, será apresentado como número.
Figura 20 - Layout da etiqueta em Smartforms
Figura 21 - Etiqueta impressa
5.1.1.4 Conclusões
O programa de impressão de etiquetas permitiu reduzir o tempo do processo, uma vez que o desenho manual do layout e geração do código de barras passou a ser automático, bastando agora introduzir o número do material, o centro e a quantidade de etiquetas desejadas. O layout ficou genérico para todos os materiais. Reduziu o desperdício de etiquetas em testes. Houve poupança também ao nível dos recursos gastos com formação de funcionários, uma vez que já não é preciso saber como operar o programa de desenho e de geração de códigos de barras.
Seria uma mais-valia para o sistema SAP oferecer nativamente um processo de etiquetagem semelhante ao que foi desenvolvido para este cliente de forma a que o mesmo possa ser usado ou adaptado de acordo com as necessidades dos clientes.
42
5.1.2 Projecto de extracção de dados “JET”
Este projecto consistiu num programa de extracção de dados para ajudar na detecção de fraude nos sistemas SAP dos clientes da Deloitte Consultores. O programa recebeu a denominação de JET devido às iniciais de Journal Entries Test.
O objectivo do programa consistia na extracção dos dados de lançamentos contabilísticos, para serem analisados por ferramentas de auditoria de forma a conseguirem ser detectados indícios de fraude nos documentos lançados em sistema tais como:
Lançamentos em dias de calendários suspeitos (Sábados, Domingos, feriados, etc.); Lançamentos a horas suspeitas (fora do horário de trabalho);
Valores elevados comparativamente aos valores normais; Valores certos (10,00; 10000,00);
Documentos lançados por pessoas que não as destinadas à tarefa; Alterações a valores de documentos.
Até ao momento da criação do JET, os clientes auditados pela Deloitte tinham que fornecer os dados em bruto e depois a equipa de auditoria conciliava os dados de forma a estes poderem ser auditados. Este processo requer um esforço da equipa de TI dos clientes, pois têm que percorrer tabela a tabela e retirar os dados necessários para o efeito. Muitos clientes não têm os conhecimentos necessários para a execução desta tarefa.
Constitui, também, um processo bastante moroso para a equipa de auditoria, tendo em conta que é necessário analisar uma grande quantidade de dados e a carteira de clientes é elevada.
A nova solução foi desenvolvida no módulo de Contabilidade Financeira e módulo ABAP.
5.1.2.1 Caracterização do cliente
O cliente foi a divisão de auditoria da Deloitte Consultores, empresa que faz parte da Deloitte, e que se encontra caracterizada no segundo capítulo.
5.1.2.2 Requisitos
A divisão de auditoria forneceu os requisitos que podem ser consultados no Anexo Dois. Neste ponto serão apresentados os requisitos mais relevantes para explicar o projecto. O programa deverá considerar como entrada os seguintes parâmetros:
Período de análise:
Data de início e data de fim do ano em análise (n) Data de início e data de fim do ano posterior (n+1) Empresas:
Escolha múltipla com base na tabela T001 (esta tabela contém as empresas que constam no sistema).
O programa deverá gerar um ficheiro CSV (Comma Separated Values – Ficheiros separados por vírgulas) por cada tabela exportada, se possível agregados num ficheiro compactado.
Deverão ser consideradas as formatações para os ficheiros CSV apresentadas na Tabela 2.
Tabela 2 - Formatações gerais para ficheiros CSV
Descrição Formatação / caracter
Casas decimais Vírgula (,) Milhares Ponto (.) Separadores Ponto e vírgula (;)
Datas YYYYMMDD
44
Na Tabela 3 estão apresentadas as tabelas e os campos a serem exportados.
Tabela 3 - Tabelas e campos de SAP a exportar para CSV
Tabela Campos necessários
BSEG BUKRS, BELNR, GJAHR, BUZEI, KOART,BSCHL, SHKZG, PSWBT, PSWSL, KOSTL, SGTXT, HKONT, KUNNR, LIFNR
BKPF BUKRS, BELNR, GJAHR, BLART, MONAT, BLDAT, BUDAT, CPUDT, CPUTM, USNAM, KURSF, TCODE, BKTXT
SKB1 BUKRS, SAKNR, XINTB
LFA1 LIFNR, NAME1, LAND1, ORT01, STRAS, PSTLZ, STCEG LFBK LIFNR, BANKS, BANKL, BANKN, BKONT
UST04 Todos os campos T001 BUKRS, BUTXT
RFSABL00 UDATE, UTIME, BUKRS, SAKNR, USERNAME, F_OLD, F_NEW RSUSR002 Todos os campos
5.1.2.3 Implementação
Após a análise concluiu-se que as tabelas RFSABL00 e RSUSR002 apresentadas na Tabela 3 não correspondiam a tabelas, mas sim a programas que depois de executados devolviam os campos necessários para proceder à auditoria. Foi necessária uma análise cuidada ao programa para encontrar as tabelas e os campos que eram consultadas pelos mesmos, de forma a fazer a extracção dos dados. Durante esta análise foram requisitados mais campos para o programa RFSABL00, na Tabela 4 podemos observar os requisitos finais do mesmo.
O programa RFSABL00 fornece todas as alterações feitas em sistema, neste caso os campos necessários a obter, provêem da consulta a três tabelas, a tabela CDHDR que armazena os cabeçalhos dos objectos alterados, a tabela CDPOS que armazena os itens dos objectos alterados, e a tabela SKB1 que armazena os dados das contas do razão. As contas do razão são as contas de onde/para onde são movimentados os pagamentos/recebimentos, por exemplo um pagamento de mil euros tem duas contas, a conta de onde é feito o pagamento e a conta para onde é movimentado o dinheiro. Nas Tabela 5 e Tabela 6 podemos observar os campos necessários a consultar de cada tabela, e como se relacionam, objectclas, objectid, changenr, são campos comuns e são campos chave.
Tabela 4 - Campos RFSABL00
RFSABL00 Alterações às contas do razão durante o período contabilístico
Nomenclatura
SAP Nomenclatura ACL Formato Tamanho Descrição
BUKRS EMPRESA ASCII 4 Empresa SAKNR CONTA ASCII 10 Conta de razão UDATE DATA Date DD.MM.YYYY Data do movimento
UTIME HORA ASCII 6 Hora do movimento
USERNAME MODIF_POR ASCII 12 Utilizador que modificou a conta N/A DATA_FECHO Date DD.MM.YYYY Data do fecho
N/A HORA_FECHO HHMMSS 8 Hora de fecho
VALUE_NEW VALOR_NOVO ASCII 254 Novo conteúdo do campo modificado VALUE_OLD VALOR_ANTIGO ASCII 254 Conteúdo antigo do campo modificado
FÑAME NOME_CAMPO ASCII 30 Nome do campo
Tabela 5- Campos tabela CDHDR
CDHDR Campos necessários tabela CDHDR para RFSABL00
Nomenclatura SAP Formato Tamanho Descrição
OBJECTCLAS ASCII 15 Classe de objectos OBJECTID ASCII 90 Valor do objecto
CHANGENR ASCII 10 Nº modificação do documento
USERNAME ASCII 12 Nome usuário que modificou documento de modificação UDATE DATA DD.MM.YYYY Data do documento
UTIME HORA HHMMSS Hora lançamento
Tabela 6 - Campos tabela CDPOS
CDPOS Campos necessários tabela CDPOS para RFSABL00
Nomenclatura SAP Formato Tamanho Descrição
OBJECTCLAS ASCII 15 Classe de objectos OBJECTID ASCII 90 Valor do objecto
CHANGENR ASCII 10 Nº modificação do documento VALUE_NEW ASCII 254 Novo conteúdo do campo modificado
VALUE_OLD ASCII 254 Conteúdo antigo do campo modificado FNAME ASCII 30 Nome do campo
De forma a podermos observar algumas particularidades da linguagem ABAP irá ser descrita uma pequena parte técnica da implementação.
Primeiro foi feita uma consulta à tabela CDHDR dos campos apresentados na Tabela 5. Os campos foram guardados numa tabela interna gt_cdhdr, que só existe em tempo de execução, a instrução into corresponding fields of table apresentada na Figura 22 indica que os campos serão guardados nos campos correspondentes da tabela interna, pois a
46
mesma apresenta estrutura igual à tabela física, caso esta instrução não seja indicada os campos serão preenchidos nas primeiras posições; se os tipos dos campos forem iguais não será apresentado nenhum erro, mas os campos necessários não vão conter informação. Na mesma figura estão apresentadas as restrições da cláusula where, objectclass representa o tipo de objecto, neste caso ‘SACH’ corresponde ao tipo de objecto das contas do razão, a consulta está restrita também ao espaço temporal, pelo campo udate, onde o in representa um intervalo de valores contidos no parâmetro s_dat, parâmetro esse que é indicado pelo utilizador na tela de selecção e era um requisito, o eq representa equal (igual).
Figura 22 - Consulta tabela CDHDR
Com esta tabela foram recolhidos todos os cabeçalhos dos itens alterados durante o período de tempo indicado, mas nem todos os dados são relevantes, os mesmos têm que ser filtrados por forma a que sejam descartados os dados relativos a contas que não pertençam à(s) empresa(s) escolhidas pelo utilizador.
Para que tal aconteça é feita a instrução loop, como se pode observar na Figura 23, esta instrução itera a tabela interna e coloca linha a linha para uma estrutura que representa uma linha dessa tabela, neste caso para a estrutura gs_cdhdr. Á medida que esta instrução vai ocorrendo o número de conta vai sendo extraído do campo objectid. O campo objectid contém nas primeiras quatro posições o número da empresa em sistema e nas restantes dez posições o número da conta, a linha gs_cdhdr-saknr = gs_cdhdr-objectid+4(10) significa que o campo saknr da estrutura gs_cdhdr vai ser igual aos dez números (10) do objectid a contar da quarta posição (+4).
Depois de preencher o campo saknr a linha actual é modificada nesse campo por forma à tabela assumir o valor. Esta operação é efectuada com a instrução modify gt_cdhdr from gs_cdhdr transporting saknr, significa que a tabela gt_cdhdr vai ser alterada na linha que corresponde à estrutura gs_cdhdr alterando o valor do saknr.
Figura 23 - Relação tabela CDPOS com contas do razão
Neste momento a tabela interna gt_cdhdr já tem o número de conta preenchido, agora é necessário apurar apenas os registos das contas da(s) empresas seleccionadas pelo utilizador.
Esse apuramento é realizado através da comparação das tabelas gt_cdhdr e da gt_skb1 que contém os dados relativos às contas da(s) empresa(s) seleccionadas. A comparação é efectuada pelo número de conta, o campo saknr e as linhas da tabela gt_cdhdr que têm o número de conta na tabela gt_skb1 vão ser colocadas numa tabela auxiliar com o nome de gt_cdhdr_aux, como se pode observar na Figura 24.
Figura 24 - Relacionamento CDPOS contas empresas seleccionadas
Para obter os dados dos itens relativos aos cabeçalhos já adquiridos foi feita uma pesquisa à tabela CDPOS como apresentado na Figura 25. Com ABAP é possível fazer pesquisas a tabelas filtrando por valores já existentes em tabelas internas com o comando for all entries in. Neste caso foi feita uma pesquisa aos campos apresentados na Tabela 6 filtrando essa pesquisa pelos campos existentes na tabela gt_cdhdr_aux, adquirida na consulta anterior. A pesquisa foi restringida pelas chaves objectclas, objectid, changenr.
48
Figura 25 - Consulta tabela CDPOS
Depois de adquiridos os dados das tabelas foram efectuadas operações para juntar os campos de forma a obter a saída necessária. Na Figura 26 está construída a primeira linha da tabela, que será o cabeçalho. Os nomes a constar como cabeçalho de cada coluna são fornecidos no campo “Nomenclatura ACL” nas especificações das tabelas e dos campos a extrair.
Figura 26 - Construção do cabeçalho da tabela
O ABAP possui métodos internos para transformar tabelas internas em formato excel que pode ser descarregado e guardado em formato CSV. Depois de feitos testes em alguns clientes e devido ao grande volume de dados a extrair chegou-se à conclusão que os métodos internos do ABAP exigiam muito tempo e recursos dos servidores.
Foi tomada a decisão de concatenar todos os valores de cada linha e separá-los por ‘;’ com recurso a um ciclo loop, os valores foram guardados numa variável do tipo string e a cada iteração foi feito um append a uma tabela de strings gt_str_tbl, como se pode observar na Figura 27. Usando depois um outro método SAP para descarregar dados em formato bruto, ou seja, sem estarem formatados como sendo ficheiros excel.
Figura 27 - Concatenação valores
A opção de substituir o método SAP para formatar a informação pela concatenação de campos e a utilização de um método SAP próprio para extrair dados, reduziu em cerca de 80% o tempo de extracção.
Esta substituição foi possível, pois o software que irá analisar os ficheiros resultantes da extracção pode ser parametrizado de forma a poder reconhecer os valores sem tratamento, por exemplo, a data no SAP é armazenada como AAAAMMDD, ou seja, 20140101 representa o dia 1 de Janeiro de 2014, os métodos internos da SAP efectuariam a transformação para 01.01.2014. Os separadores dos milhares e das décimas são outro exemplo que os métodos da SAP efectuariam uma transformação, os separadores dos milhares em SAP são vírgulas (,) e o separador decimal são os pontos (.), os métodos internos SAP transformariam o valor 1,000.00 em 1.000,00.
Nas figuras seguintes estão apresentados exemplos em CSV e excel dos valores que o programa RFSABL00 extrai de SAP. Os campos DATA_FECHO e HORA_FECHO estão em branco pois são para serem preenchidos mais tarde pela equipa de auditoria.
50
Figura 28 - Exemplo extracção CSV
Figura 29 - Exemplo extracção excel
O programa RSUSR002 devolve dados dos utilizadores em sistema, este programa permite a obtenção os campos que constam na Tabela 7. Os principais objectivos deste programa são:
Obter o tipo de utilizador, através do campo ustyp, as possibilidades são: Diálogo, Sistema, Comunicação, Referência e Serviço, a fraude é mais provável de ser cometida por utilizadores de Diálogo (utilizador normal), sendo que os outros tipos são usados de forma automática pelo SAP;
Caso os utilizadores estejam bloqueados, obter o motivo do bloqueio; E a data até quando os utilizadores podem aceder ao sistema.
Tabela 7 - Campos RSUSR002
RSUSR002 Campos necessários RSUSR002
Nomenclatura
SAP Nomenclatura ACL Formato Tamanho Descrição
BNAME USER ASCII 12 Nome do usuário no mestre de utilizador USTYP TIPO_USER ASCII 1 Tipo de usuário
NAME_TEXT NOME ASCII 80 Nome completo da pessoa UFLAG MOTIVO ASCII 8 Motivo de bloqueio do utilizador GLTGB VALIDO_ATE DATE 8 Usuário válido até
À semelhança do programa RFSABL00, este também reúne informação de várias tabelas para construir o relatório final. As tabelas usadas para recolher a informação necessária foram: Tabela 8, Tabela 9 e Tabela 10.
Mais uma vez, foram usadas as características do ABAP evidenciadas na descrição do método usado para adquirir os dados do programa RFSABL00.
Tabela 8 - Campos tabela USR02
USR02 Campos necessários tabela USR02 para RFSABL00
Nomenclatura SAP Formato Tamanho Descrição
BNAME ASCII 12 Nome do usuário no mestre de usuários USTYP ASCII 1 Tipo de usuário
UFLAG ASCII 3 Status bloqueio usuário GLTGB DATE 8 Usuário válido até
Tabela 9 - Campos tabela URS21
USR21 Campos necessários tabela USR21 para RFSABL00
Nomenclatura SAP Formato Tamanho Descrição
BNAME ASCII 12 Nome do usuário no mestre de usuários PERSNUMBER ASCII 10 Nº pessoa
Tabela 10 - Campos tabela ADRP
ADRP Campos necessários tabela ADRP para RFSABL00
Nomenclatura SAP Formato Tamanho Descrição
PERSNUMBER ASCII 10 Nº pessoa
NAME_TEXT ASCII 80 Nome completo da pessoa
Foi desenvolvido um ecrã de selecção de dados apresentado na Figura 30, onde é possível ao utilizador escolher várias empresas, intervalos de datas, dados a extrair, e modo de extracção.
Depois do programa entrar em produção, em alguns clientes começaram a ocorrer casos de time-out dos utilizadores e de esgotamento de memória reservada aos utilizadores em sistema. O problema de time-out relaciona-se com o facto da ligação do SAP GUI se fechar depois de longos períodos de inactividade, o que acontecia quando os utilizadores começavam a extracção dos dados e que devido à grande quantidade de dados, deixavam o programa a executar e ausentavam-se do posto de trabalho. Já o problema do esgotamento de memória ocorre quando os dados a extrair representam uma grande quantidade de informação e mediante os parâmetros de cada sistema, que podem ser variáveis (mais ou menos memória reservada para cada utilizador), a memória esgota-se e torna-se impossível extrair os dados.
52
A primeira solução indicada para este problema foi a forma de utilização do programa por parte dos utilizadores. Foi pedido aos utilizadores para escolherem uma só empresa de cada vez e indicar períodos de um mês apenas, para a extracção.
A solução apresentada resultou para a maioria dos clientes, mas persistiu em outros, que diminuíram ainda mais os períodos de selecção. Esta solução resultou mas, a nível operacional, era muito demorada para os utilizadores.
Consultou-se a área de administração de sistemas SAP da AMS que informou que, em vez de se efectuar a extracção directamente para o computador pessoal do utilizador, essa mesma extracção deveria ser efectuada para uma pasta do servidor; depois os ficheiros deveriam ser descarregados dessa pasta com recurso ao programa CG3Y, que a SAP