Embed Size (px)
Citation preview
Projecto
Mestrado Em Gestão De Sistemas De Informação Médica
Projectos de Consultoria em SAP e Tecnologias
Microsoft: Análise e desenvolvimento de soluções de
software à medida
Luís Filipe Leal Sismeiro
Leiria, Setembro de 2014
Projecto
Mestrado Em Gestão De Sistemas De Informação Médica
Projectos de Consultoria em SAP e Tecnologias
Microsoft: Análise e desenvolvimento de soluções de
software à medida
Luís Filipe Leal Sismeiro
Projecto de Mestrado realizado sob a orientação da Doutora Dulce Gonçalves
Professora da Escola Superior de Tecnologia e Gestão do Instituto Politécnico de Leiria
Leiria, Setembro de 2014
i
Agradecimentos
Apesar de este trabalho ser de natureza individual, não queria deixar de agradecer a todos
os que deram o seu contributo e que tornaram esta etapa possível.
Agradeço aos meus colegas do primeiro ano do Mestrado em Gestão de Sistemas de
Informação Médica pela sua companhia e ajuda ao longo deste percurso.
Agradeço à professora Dulce Gonçalves pelo incentivo e interesse demonstrado em me
orientar na escrita deste documento.
Agradeço à comissão de curso do Mestrado por tornar este projecto possível, em particular
ao professor Rui Rijo que foi um dos grandes impulsionadores do Mestrado e da
possibilidade de ingressar na Deloitte.
Agradeço à Deloitte pela oportunidade para poder realizar os projectos que aqui apresento
e fazer parte de uma grande empresa mundial.
Agradeço ao IPL e à FMUP por me terem proporcionado grande conhecimento na área dos
Sistemas de Informação Médica
Agradeço a toda a minha família, em especial à Joana, que me apoiou e motivou durante
este período e que sem ela não teria sido possível a realização deste relatório.
A todos o meu muito obrigado.
iii
Resumo
À medida que a sociedade evolui, também as profissões evoluem com ela. Uma profissão
que tem crescido de forma notável é a de consultor na área das tecnologias de informação.
De facto, há alguns anos atrás, esta profissão não tinha o relevo que tem na actualidade,
pois com a evolução das tecnologias da informação, as ferramentas ao dispor das empresas
diversificaram-se e como tal, a mão-de-obra vai-se especializando nestas ferramentas. As
empresas, na impossibilidade de contratar mão-de-obra para instalar, manter e evoluir
todas as suas ferramentas, recorrem cada vez mais à experiência de consultores externos;
estes são contratados para realizar tarefas específicas que as empresas não têm capacidade
de executar com os próprios recursos e a sua ligação com estas entidades termina após a
conclusão destas tarefas.
Cada vez mais as empresas procuram tirar o máximo partido das ferramentas informáticas
à sua disposição e os sistemas de Enterprise Resource Planning não são excepção. À
medida que os utilizadores vão usufruindo dos sistemas, surgem novas necessidades que,
depois de colmatadas, permitem a sua optimização. Além disso, com a alteração das leis, é
preciso adaptar os sistemas para que estes evoluam e possam reflectir os novos requisitos
legais.
Com o aumento da regulação bancária, as entidades bancárias são obrigadas a comunicar
informação sobre as suas finanças ao Banco de Portugal, de modo a que o banco possa
analisar a saúde financeira das entidades e emitir recomendações sobre a sua forma de
actuar. Esta nova forma de comunicação será efectuada por meio de relatórios em
eXtended Business Reporting Language (XBRL).
Pretende-se caracterizar a profissão de consultor e apresentar alguns projectos realizados
enquanto consultor numa consultora de grande dimensão.
Palavras-chave: Consultoria, ERP, SAP, XBRL.
v
Abstract
As society evolves, jobs evolve as well. A job which as been growing considerably is the
one of consultant in the field of information technologies. In fact, some years ago, this job
did not have the importance it has currently because, as information technologies develop,
the number of tools that can be used by companies keeps increasing and, due to that,
manpower becomes more and more specialized in these tools. Companies cannot hire
manpower to install, maintain and develop all their tools so they resort to external
consultants’ work experience; these workers are hired to accomplish specific tasks that
companies are not able to perform using their own resources and when the job is done,
they are dismissed.
Companies are increasingly looking forward to get the most out of the computer
applications at their disposal and Enterprise Resource Planning Systems are no exception.
As users take advantage of the systems, new needs arise which, after being solved, lead to
the optimization of the systems. Apart from that, laws are changing and therefore there is
an urge to adapt the systems so that they can fulfill the new legal requirements.
Due to the increase of banking regulation, banking entities are obliged to share information
regarding their finances with the Bank of Portugal so that it can assess their financial
health and issue recommendations about their modes of operation. This new way of
communication will be carried out using reports in eXtended Business Reporting Language
(XBRL).
It is intended to characterize the consulting job and to present some projects developed in a
large-scale consulting company.
Keywords: Consulting, ERP, SAP, XBRL.
vii
Índice
AGRADECIMENTOS .................................................................................................................................. I
RESUMO .................................................................................................................................................... III
ABSTRACT .................................................................................................................................................. V
ÍNDICE ...................................................................................................................................................... VII
ÍNDICE DE FIGURAS .............................................................................................................................. IX
ÍNDICE DE TABELAS ............................................................................................................................ XII
ÍNDICE DE ACRÓNIMOS .................................................................................................................... XIII
1 INTRODUÇÃO .................................................................................................................................... 1
1.1 ENQUADRAMENTO .......................................................................................................................... 1 1.2 MOTIVAÇÕES E OBJECTIVOS ........................................................................................................... 2 1.3 ORGANIZAÇÃO DO DOCUMENTO .................................................................................................... 2
2 CARACTERIZAÇÃO DA ENTIDADE RECEPTORA .................................................................. 5
2.1 CARACTERIZAÇÃO DA DELOITTE .................................................................................................... 5 2.2 CONCORRÊNCIA .............................................................................................................................. 7
2.2.1 PricewaterhouseCoopers 7 2.2.2 KPMG 8 2.2.3 Ernst & Young 8
2.3 CARACTERIZAÇÃO DA ÁREA DE NEGÓCIO .................................................................................... 10
3 FORMAÇÃO ..................................................................................................................................... 13
4 ÁREAS DE CONSULTORIA ........................................................................................................... 17
4.1 CONSULTORIA .............................................................................................................................. 17 4.2 SECTORES DA BANCA E RETALHO ................................................................................................ 18 4.3 SISTEMAS ENTERPRISE RESOURCE PLANNING ................................................................................ 19
4.3.1 Caracterização 20 4.3.2 Evolução 21 4.3.3 Sistemas ERP Existentes 23
4.4 CICLO DE VIDA DE UM ERP .......................................................................................................... 24 4.5 FACTORES CRÍTICOS NA IMPLEMENTAÇÃO DE UM ERP ................................................................ 25 4.6 CARACTERIZAÇÃO SAP ................................................................................................................ 26
4.6.1 Módulos SAP R/3 29 4.6.2 Metodologia de desenvolvimento SAP 32 4.6.3 Fluxo de desenvolvimento 33
5 PROJECTOS DE CONSULTORIA ................................................................................................ 37
5.1 PROJECTOS SAP ........................................................................................................................... 37 5.1.1 Programa de Etiquetas 37 5.1.2 Projecto de extracção de dados “JET” 42 5.1.3 Determinação automática do Centro de Custo para Pedido de Compra de Imobilizado 53 5.1.4 Fichiér des Écritures Comptables 58 5.1.5 Certificação de Guias de Remessa 62 5.1.6 Formulário de aprovação de Requisições de Compra 69 5.1.7 Implementação do programa RPFIEU_SAFT - SAF-T PT 74 5.1.8 Apoio funcional à certificação de facturas, guias de remessa e SAF-T PT 78
5.2 PROJECTOS TECNOLOGIAS MICROSOFT ........................................................................................ 79
viii
5.2.1 Conversor eXtended Business Reporting Language – XBRL 80
6 CONSIDERAÇÕES FINAIS .......................................................................................................... 107
6.1 SÍNTESE DO RELATÓRIO .............................................................................................................. 107 6.2 RESULTADOS E PRINCIPAIS CONTRIBUTOS .................................................................................. 108 6.3 PROPOSTAS DE TRABALHO FUTURO ............................................................................................ 109 6.4 CONCLUSÃO ............................................................................................................................... 110
7 BIBLIOGRAFIA ............................................................................................................................. 111
8 ANEXOS .......................................................................................................................................... 115
8.1 ANEXO UM - PLANEAMENTO DO PROJECTO ................................................................................... 117 8.2 ANEXO DOIS - REQUISITOS DO PROJECTO DE EXTRACÇÃO DE DADOS “JET” ....................................... 121 8.3 ANEXO TRÊS - MANUAL DO PROGRAMA “JET” ............................................................................... 125 8.4 ANEXO QUATRO - ESPECIFICAÇÃO FUNCIONAL - PEDIDO DE COMPRA - CENTRO DE CUSTO ....... 131 8.5 ANEXO CINCO - ESPECIFICAÇÃO TÉCNICA - PEDIDO DE COMPRA - CENTRO DE CUSTO .............. 136 8.6 ANEXO SEIS - CERTIFICAÇÃO DE GUIAS DE REMESSA -EXCERTO DE CÓDIGO ABAP ................. 141 8.7 ANEXO SETE - ESPECIFICAÇÃO TÉCNICA - GUIAS DE REMESSA ................................................. 143 8.8 ANEXO OITO - MANUAL UTILIZADOR SAF-T PT ....................................................................... 150 8.9 ANEXO NOVE - FORMAÇÃO PROGRAMA SAF-T PT ................................................................... 161 8.10 ANEXO DEZ - EXEMPLO DE INSTÂNCIA XBRL ........................................................................... 186 8.11 ANEXO ONZE - XBRL - COMUNICAÇÃO TROCADA COM O BANCO DE PORTUGAL ...................... 193
ix
Índice de Figuras
Figura 1 - Deloitte 1830 - 1870 ............................................................................................. 5
Figura 2 - Deloitte 1880 - 1920 ............................................................................................. 6
Figura 3 - Deloitte 1930 – 1970 ............................................................................................ 6
Figura 4 - Deloitte 1980 - 2020 ............................................................................................. 6
Figura 5 - Quota de mercado em Auditoria PSI 20 ............................................................... 9
Figura 6 - Quota de Mercado em Consultoria Fiscal 250 Maiores Empresas em Portugal .. 9
Figura 7 - Quota de Mercado Big4 Volume de Negócios em 2012 ...................................... 9
Figura 8 - Hierarquia AMS .................................................................................................. 10
Figura 9 - Características ERP Uwizeyemungu e Raymond (2004) (Adaptado) ................. 21
Figura 10 - Anatomia de um Sistema de Informação Empresarial (Davenport 1998) ........ 22
Figura 11 - Ciclo de vida de ERP (Esteves, 1999) .............................................................. 24
Figura 12 - Arquitectura cliente-servidor SAP R/3 (SAP 2009) ......................................... 27
Figura 13 - Tecnologia SAP: Sistema Aberto (ISPGAYA s.d.) .......................................... 28
Figura 14 - Principais módulos SAP (ISPGAYA s.d.) ........................................................ 29
Figura 15 - Fluxo de desenvolvimento SAP R/3 ................................................................. 34
Figura 16 - Tela do programa de impressão de etiquetas .................................................... 39
Figura 17 - Principais relações entre as tabelas de Materiais .............................................. 40
Figura 18 - Tabela configuração impressoras...................................................................... 40
Figura 19 - Listagem de impressoras configuradas para o programa .................................. 40
Figura 20 - Layout da etiqueta em Smartforms ................................................................... 41
Figura 21 - Etiqueta impressa .............................................................................................. 41
Figura 22 - Consulta tabela CDHDR ................................................................................... 46
Figura 23 - Relação tabela CDPOS com contas do razão ................................................... 47
Figura 24 - Relacionamento CDPOS contas empresas seleccionadas ................................ 47
Figura 25 - Consulta tabela CDPOS .................................................................................... 48
Figura 26 - Construção do cabeçalho da tabela ................................................................... 48
Figura 27 - Concatenação valores ....................................................................................... 49
x
Figura 28 - Exemplo extracção CSV ................................................................................... 50
Figura 29 - Exemplo extracção excel .................................................................................. 50
Figura 30 - Layout do ecrã do JET ...................................................................................... 52
Figura 31 - Dados mestre do imobilizado ........................................................................... 54
Figura 32 - Tela pedido de compra ..................................................................................... 54
Figura 33 - Criação intervalo numérico SNRO ................................................................... 64
Figura 34 - Tabela com os tipos de documento a assinar .................................................... 65
Figura 35 - Tabela SIPT_LIKP ............................................................................................ 66
Figura 36 - Perform de aquisição de dados da tabela de certificação ................................. 67
Figura 37 - Área da mensagem da certificação ................................................................... 67
Figura 38 - Chamada do perform get_sipt_likp_counter .................................................... 68
Figura 39 - Mensagem de certificação ................................................................................ 68
Figura 40 - Programa de impressão de requisições de compra ........................................... 71
Figura 41 - Tabela requisições de compra – EBAN ............................................................ 71
Figura 42 - Tabela ZMM_REQC_APP_LOG ...................................................................... 71
Figura 43 - Layout formulário de requisição de compra em smartforms ............................ 72
Figura 44 - Formulário de requisição de compra ................................................................ 73
Figura 45 - Exemplo de objecto a registar .......................................................................... 77
Figura 46 - Exemplo de data point ...................................................................................... 87
Figura 47 - Fluxo data point ............................................................................................... 88
Figura 48 - Exemplo Contexto em XBRL .......................................................................... 88
Figura 49 - Excel de configuração de intervalos ................................................................. 89
Figura 50 - Arquitectura de alto nível do funcionamento do programa .............................. 90
Figura 51 - Todos os módulos do programa Authority Connect ......................................... 91
Figura 52 - Módulo XBRL do programa Authority Connect .............................................. 91
Figura 53 - Estrutura de pastas da solução .......................................................................... 92
Figura 54 - Método excel_init ............................................................................................. 93
Figura 55 - Método excel_close .......................................................................................... 93
Figura 56 - Inclusão da biblioteca Microsoft.Office.Interop.Excel ..................................... 94
Figura 57 - Classe RangesExcel .......................................................................................... 94
Figura 58 - Declaração classe Contexto .............................................................................. 95
Figura 59 - Declaração classe Context ................................................................................ 95
Figura 60 - Declaração classe CelulaEXCL ........................................................................ 96
Figura 61 - Declaração método get_sheets_and_ranges ..................................................... 96
xi
Figura 62 - Declaração do método excel_getRange ............................................................ 97
Figura 63 - Declaração método corep_by_sheet ................................................................. 97
Figura 64 - Declaração método get_datapoints_by_sheet ................................................... 97
Figura 65 - Declaração do método get_datapoints_excel ................................................... 97
Figura 66 - Declaração excel_getRangeCorep_by_sheet .................................................... 98
Figura 67 - Declaração método GetRangeCorepColumn_by_sheet .................................... 98
Figura 68 - Método trata_listas_celulas ............................................................................. 99
Figura 69 - Excerto método get_context_list_celulas_db (1) ............................................ 100
Figura 70 - Excerto método get_context_list_celulas_db (2) ............................................ 100
Figura 71 - Método get_trata_unitRef_precision .............................................................. 101
Figura 72 - Excerto método lista_contextos_por_sheet .................................................... 102
Figura 73 - Declaração método escreve_xbrl .................................................................... 102
Figura 74 - Ficheiro XBRL da folha C00.01 do excel template ........................................ 103
xii
Índice de Tabelas
Tabela 1 - Fase Roadmap ASAP ......................................................................................... 33
Tabela 2 - Formatações gerais para ficheiros CSV ............................................................. 43
Tabela 3 - Tabelas e campos de SAP a exportar para CSV ................................................ 44
Tabela 4 - Campos RFSABL00 .......................................................................................... 45
Tabela 5- Campos tabela CDHDR ...................................................................................... 45
Tabela 6 - Campos tabela CDPOS ...................................................................................... 45
Tabela 7 - Campos RSUSR002 ........................................................................................... 50
Tabela 8 - Campos tabela USR02 ....................................................................................... 51
Tabela 9 - Campos tabela URS21 ....................................................................................... 51
Tabela 10 - Campos tabela ADRP ...................................................................................... 51
Tabela 11 - Campos Artigo 47 ............................................................................................ 60
Tabela 12 - Correspondência campos artigo 47 e SAP ....................................................... 61
Tabela 13 - Tipos documentos a assinar ............................................................................. 64
Tabela 14 - Notas SAF-T PT............................................................................................... 76
Tabela 15 - Tipo de relatório COREP ................................................................................. 81
Tabela 16 - Tipo de relatório FINREP ................................................................................ 81
Tabela 17 - Resumo principais métodos ........................................................................... 104
Tabela 18 - Resumo de conclusões dos projectos ............................................................. 108
xiii
Índice de Acrónimos
Advanced Business Application Programming ABAP
Application Management Services AMS
Autoridade Tributária AT
Banco de Portugal BdP
Enterprise Resource Planning ERP
eXtended Business Reporting Language XBRL
eXtensible Markup Language XML
Sistemas, aplicações e produtos em processamento de dados SAP
Sistemas de Informação SI
Standard Audit File for Tax Purposes - Portuguese Version SAF-T - PT
Sistemas, Aplicações e Produtos SAP
Tecnologias de Informação TI
1
1 Introdução
Vivemos num mundo em constante mudança, as Tecnologias de Informação (TI)
acompanham essa mudança fazendo-a reflectir nos Sistemas de Informação (SI). Com
exigências cada vez maiores, quer das autoridades legais, quer da melhoria constante dos
seus processos de negócio, quer dos proprietários que pretendem aumentar os lucros e
tornar as empresas mais competitivas, as organizações vêm nos seus SI a ferramenta ideal
para ajudar a vencer os obstáculos constantes.
À medida que as empresas se vão deparando com novos obstáculos, torna-se inevitável que
os seus SI sejam alvos de melhoria, ou sejam desenvolvidas novas ferramentas de forma a
existir uma resposta eficaz.
1.1 Enquadramento
Este documento mostra os projectos desenvolvidos na área de Application Management
Services da entidade associada da Deloitte, a Serviços Gerais de Gestão.
Este documento apresenta projectos de duas tecnologias: SAP e Microsoft.
Na área de SAP foram realizados projectos de curta duração onde foram analisadas e
desenvolvidas soluções de forma a responder aos requisitos legais e optimização dos
processos dos clientes. Foi também prestado apoio funcional a alguns clientes
internacionais que contrataram os serviços da Deloitte para os ajudarem com requisitos
legais de Portugal; Na vertente das tecnologias Microsoft foi criada uma ferramenta com
recurso à linguagem de programação C# e à framework .NET. Esta ferramenta foi criada
devido a novos requisitos legais de comunicação de informação financeira dos bancos
portugueses ao Banco de Portugal (BdP).
2
1.2 Motivações e Objectivos
Em alguns projectos documentados, os clientes estavam em transgressão das leis
Portuguesas, as soluções apresentadas têm como principal objectivo colocar os clientes em
situação legal e assim evitar possíveis multas por parte das autoridades.
Foram desenvolvidas soluções com o objectivo de melhorar os processos dos clientes,
tornando assim as tarefas mais rápidas, uniformes e mais eficazes.
Quando se efectuam trabalhos de consultoria o foco primordial é a satisfação do cliente,
como tal a motivação principal é trabalhar de forma a resolver os desafios lançados pelos
clientes da maneira mais eficaz e eficiente possível que o leve a ter confiança no trabalho
desenvolvido sabendo que pode contar com a firma para o apoiar nas iniciativas actuais e
em iniciativas futuras.
1.3 Organização do Documento
Este documento está estruturado em sete capítulos. No Capítulo um está apresentada uma
breve descrição sobre os temas do relatório.
No Capítulo Dois é feita uma caracterização da entidade onde os projectos foram
desenvolvidos, são apresentadas as principais características, concorrentes, bem como a
área de negócio.
No Capítulo Três é descrita a formação recebida enquanto membro da equipa, sendo
abordados os principais assuntos da mesma.
No Capítulo Quatro é feita uma caracterização sobre o trabalho na área de consultoria. É
também feito um enquadramento em relação à tecnologia de Enterprise Resource Planning
(ERP), esta tecnologia é onde os projectos de consultoria são desenvolvidos. Neste capítulo
o ERP SAP é detalhado em mais pormenor pois, é nesta tecnologia que a actividade de
consultoria em SAP é prestada.
No capítulo Cinco são apresentados duas vertentes de consultoria em SAP: projectos de
análise e desenvolvimento; e projectos de consultoria, nestes últimos não há
desenvolvimento, há apenas apoio técnico e funcional como forma de ajudar clientes
estrangeiros que têm desconhecimento das leis portuguesas. Neste capítulo é apresentado
3
também o projecto em tecnologias Microsoft, mais propriamente um conversor de ficheiros
excel com dados financeiros para eXtended Business Reporting Language (XBRL). A
comunicação de informação financeira em formato XBRL dos bancos ao Banco de
Portugal é um novo requisito legal.
Por fim, no Capítulo Seis é apresentada uma síntese do documento, bem como principais
pontos apresentados. São também deixadas algumas sugestões de trabalho futuro e
apresentada uma conclusão.
No final do documento encontram-se os anexos que complementam o relatório e que pela
sua importância não poderiam estar omissos. Nos anexos encontram-se:
Anexo Um - Planeamento do Projecto;
Anexo Dois - Requisitos do projecto de extracção de dados “JET”;
Anexo Três - Manual do programa “JET”;
Anexo Quatro - Especificação Funcional - Pedido de compra - Centro de custo;
Anexo Cinco - Especificação técnica - Pedido de Compra - Centro de custo;
Anexo Seis - Certificação de Guias de Remessa -Excerto de código ABAP;
Anexo Sete - Especificação Técnica - Guias de Remessa;
Anexo Oito - Manual Utilizador SAF-T PT;
Anexo Nove - Formação Programa SAF-T PT;
Anexo Dez - Exemplo de Instância XBRL;
Anexo Onze - XBRL - Comunicação trocada com o Banco de Portugal.
5
2 Caracterização da Entidade Receptora
Neste capítulo será apresentada uma caracterização da entidade receptora dos projectos que
vão ser relatados neste documento.
Será apresentada uma breve história da Deloitte, com os marcos principais da sua
existência, áreas de negócio e concorrência.
2.1 Caracterização da Deloitte
A história da Deloitte remonta ao século XIX, e o seu nome internacional – Deloitte
Touche Tohmatsu – deriva dos três percursores William Welch Deloitte, George Touche e
Nobuzo Tohmatsu - líderes na área dos serviços profissionais.
Nas imagens seguintes podemos observar os principais marcos temporais da empresa ao
longo de quase duzentos anos (Deloitte 2014).
Figura 1 - Deloitte 1830 - 1870
6
Figura 2 - Deloitte 1880 - 1920
Figura 3 - Deloitte 1930 – 1970
Figura 4 - Deloitte 1980 - 2020
7
“Deloitte” é a marca sob a qual dezenas de milhares de profissionais, trabalhando em
firmas independentes espalhadas por todo o mundo, colaboram na prestação de serviços de
auditoria, consultoria fiscal, consultoria e corporate finance a clientes nos mais diversos
sectores de actividade. Estas entidades são firmas membro da Deloitte Touche Tohmatsu
Limited ("DTTL"), uma sociedade privada de responsabilidade limitada do Reino Unido.
Cada firma membro presta serviços numa determinada área geográfica e está sujeita às leis
e regulamentos profissionais do país ou dos países em que opera. A DTTL não presta
directamente serviços a clientes. A DTTL e as firmas membro são entidades separadas e
legalmente distintas, não podendo uma obrigar as outras. A DTTL e cada firma membro é
responsável pelos actos e omissões próprios não sendo responsável pelos dos outros. Cada
firma membro opera sob os nomes “Deloitte”, “Deloitte & Touche”, “Deloitte Touche
Tohmatsu”, ou outros nomes relacionados. Cada firma membro é estruturada de modo
diferenciado consoante as respectivas leis nacionais, regulamentos profissionais, costumes
e outros factores, podendo exercer a sua actividade nas respectivas áreas geográficas
através de subsidiárias, participadas ou outras entidades.
Em Portugal e Angola, a Deloitte tem escritórios em Lisboa, Porto e Luanda e conta com
cerca de 1.800 profissionais que assumem diariamente um compromisso com a excelência
e presta serviços de auditoria, consultoria fiscal, consultoria e corporate finance através
das seguintes entidades:
Deloitte & Associados, SROC S.A. (auditoria, consultoria fiscal e gestão de risco);
Deloitte Consultores, S.A. (consultoria e corporate finance);
SGG – Serviços Gerais de Gestão, S.A. (outsourcing de serviços financeiros);
Deloitte & Touche – Auditores Limitada (Angola) (auditoria, consultoria e
consultoria fiscal).
2.2 Concorrência
2.2.1 PricewaterhouseCoopers
A PwC está presente em Portugal há mais de 50 anos fazendo actualmente parte desta rede
as seguintes entidades:
PricewaterhouseCoopers & Associados - Sociedade de Revisores de Contas, Lda
(PwC SROC);
8
PricewaterhouseCoopers / AG - Assessoria de Gestão, Lda (PwC AG);
PricewaterhouseCoopers / MFAS – Management, Finance & Accounting Services,
Lda.
PwC refere-se à rede de entidades que são membros da PricewaterhouseCoopers
International Limited, cada uma das quais uma entidade legal autónoma e independente.
A PwC em Portugal conta com 28 Partners, dos quais 21 no escritório de Lisboa e 7 no
Porto, e cerca de 940 colaboradores permanentes distribuídos pelos escritórios de Lisboa,
Porto e Cabo Verde. A PwC Portugal tem ainda uma joint-venture com a PwC Africa
Central para o desenvolvimento da sua actividade em Angola. A grande maioria dos
profissionais é licenciada em gestão de empresas, finanças, economia, contabilidade,
direito, engenharia ou ciências sociais, a todos sendo proporcionada a hipótese de
complementarem a sua formação académica, além de receberem frequentemente formação
profissional específica (PWC 2014).
2.2.2 KPMG
A KPMG International Cooperative (“KPMG International”) é uma entidade suíça. As
firmas membro da rede KPMG são filiais da KPMG International. A KPMG International
não presta qualquer tipo de serviços a clientes das suas firmas membro. Nenhuma firma
membro tem autoridade para obrigar ou comprometer a KPMG International ou outra das
suas firmas membro perante terceiros. Da mesma forma, a KPMG International não tem
autoridade para obrigar ou comprometer nenhuma firma membro. A rede adopta uma
abordagem global às necessidades dos clientes, abrangendo disciplinas profissionais,
sectores industriais e fronteiras nacionais.
A rede da KPMG International tem 155.000 profissionais nas firmas membro em 155
países. Na KPMG em Portugal, a sua actividade está organizada em torno dos serviços de
Auditoria, Fiscalidade e de Consultoria (KPMG 2014).
2.2.3 Ernst & Young
A Ernst & Young, conhecida actualmente como EY é uma das maiores empresas de
prestação de serviços profissionais no mundo, que inclui auditoria, impostos, finanças,
contabilidade e consultadoria. É uma empresa multinacional composta por mais de
145.000 profissionais e com presença em 140 países. As origens da empresa remontam a
9
1903, quando Alwin Ernst cria Ernst & Ernst, e 1906 com Arthur Young a criar Arthur
Young & Company. A actual Ernst & Young nasce em 1989, momento que duas
importantes empresas, Ernst & Winney e Arthur Young se fundem.
A empresa EY encontra-se dividida 4 áreas geográficas: Américas; Ásia-Pacífico; Europa,
Médio Oriente, Índia, África; Japão (EY 2014).
A Deloitte, juntamente com as suas três grandes concorrentes são conhecidas como as Big4
(Big four) designação que tem origem no facto de serem consideradas como as quatro
grandes consultoras mundiais.
Em Portugal, a Deloitte é líder na prestação de serviços profissionais de auditoria e
consultoria em volume de facturação, e detém a maior quota de mercado na prestação de
serviços de auditoria às empresas do Índice PSI 20 e em consultoria fiscal às 250 maiores
empresas, nas imagens seguintes podemos observar a quota de mercado da Deloitte
(Deloitte 2014).
Figura 5 - Quota de mercado em Auditoria PSI 20
Figura 6 - Quota de Mercado em Consultoria Fiscal 250 Maiores Empresas em Portugal
Figura 7 - Quota de Mercado Big4 Volume de Negócios em 2012
10
2.3 Caracterização da Área de Negócio
Os projectos foram desenvolvidos na SGG – Serviços Gerais de Gestão, esta empresa é
uma filiada da Deloitte e presta serviços de outsourcing nas áreas de:
Contabilidade administrativa;
Consultoria geral.
A SGG é constituída por diversas divisões:
Application Management Services;
Finance & Accounting;
Human Resources;
Tax Compliance.
Foi na área Application Management Services (AMS) que os projectos foram
desenvolvidos.
A divisão AMS é focada essencialmente na manutenção, correcção e evolução do software,
no entanto tem capacidade e conhecimento para implementações de raiz.
A AMS tem nos seus quadros cerca de 90 colaboradores, distribuídos por diferentes
cargos/funções consoante o desempenho e antiguidade, na imagem Figura 8 podemos
observar a sua hierarquia.
Figura 8 - Hierarquia AMS
11
A AMS está dividida em duas grandes áreas, FSI - Financial Services Industry com
clientes nas áreas da Banca e Seguros e Manufacturing com clientes nas áreas da Indústria,
Banca e Retalho.
13
3 Formação
No princípio da colaboração na Deloitte foi realizada uma apresentação da empresa,
apresentação individual das áreas de actividade da empresa, normas internas, dress code e
também uma formação sobre ética e independência.
Seguiu-se um mês de formação em sala com profissionais da AMS de forma a adquirir
competências sobre as tecnologias nas quais os colaboradores desta área trabalham
diariamente e que permitam uma boa integração nos projectos que a área tem a decorrer,
ou em projectos que venham a ser adjudicados.
A primeira formação, com duração aproximada de dez dias, foi sobre conceitos de bases de
dados com grande incidência no desenho de modelos Entidade-Relacionamento e da
linguagem Structured Query Language (SQL), foram abordados vários casos, desde os
mais simples com consultas imediatas, aos bastante complexos com várias consultas
encadeadas (subconsultas) e consultas de várias tabelas. Seguiu-se uma formação de
Procedural Language/Structured Query Language (PL/SQL) onde foram abordados vários
aspectos sobre esta linguagem de programação, entre eles, os procedimentos e as funções.
Estas formações constituíram uma revisão de conhecimentos previamente adquiridos de
forma a preparar a próxima formação que foi em Oracle Forms. Este software permite a
criação de formulários para interagir com a base de dados, possui um editor de PL/SQL e
um Integrated Development Environment (IDE).
No final das formações foi efectuado um teste com o objectivo de testar os conhecimentos
adquiridos. O teste foi composto por perguntas teóricas e práticas.
A formação continuou com Microsoft Excel, onde foram apresentados conceitos sobre a
importância do Branding na formatação dos documentos, efectuar médias, somatórios
entre outros cálculos, fórmulas condicionais, validação de dados, importação e exportação
14
de dados de/para várias tipos de documentos, aplicados a casos próximos da realidade da
Banca e Seguradoras.
A formação seguinte foi em tecnologia SAP, na vertente técnica, ou seja, na vertente de
programação em sistemas SAP, com especial relevo para a linguagem ABAP (Advanced
Business Application Programming). Esta linguagem é uma linguagem de alto nível,
desenvolvida pela própria SAP e é a linguagem mais utilizada nos seus produtos.
Os aspectos focados nesta formação foram:
Dicionário de dados – Funciona como uma abstracção de um SGBD (Sistema de
Gestão de Base de Dados), permite a gestão de todas as definições de dados. No
dicionário de dados é permitido criar todos os tipos de dados para serem usados em
programas ABAP. Podem ser criados por exemplo:
o Domínios – Características que definem o tipo de dados (Date, String, Char) e o
seu tamanho.
o Elementos de dados – Descrevem o significado dos domínios, ou seja, a sua
semântica;
o Tabelas transparentes – são compostas por um conjunto de campos. Cada campo
possui uma definição semântica (Elemento de Dados), e uma definição técnica
(Domínio). Quando são criadas no Dicionário, automaticamente são criadas
espelhos, com a mesma estrutura, mesmos nomes, mesmos campos com o mesmo
nome, mas os dados de cada tipo são mapeados para os tipos de dados permitidos
pelo SGBD;
o Visões – são objectos que permitem visualizar o conteúdo das tabelas transparentes,
inserção, edição e eliminação de dados;
o Ajudas de Pesquisa – fornecem os valores possíveis para determinado campo
quando premida a tecla de atalho para o efeito.
ABAP Development Workbench – é um conjunto de ferramentas usadas para
desenvolver, testar e correr programas feitos em ABAP. Todas as ferramentas são
integradas. Quando se edita um objecto criado com outra ferramenta o Workbench
lança essa essa ferramenta para se poder proceder à edição do objecto. Ajuda a
organizar os desenvolvimentos pois oferece um navegador de objectos que fornece
uma navegação em forma de árvore (Ziegler 2011);
15
ALV – tem origem em ABAP List Viewer, é uma ferramenta que apresenta os dados
em forma de tabela (linhas e colunas), tem integrado funções que permitem
manipular os dados (ordenar, totais, filtros, esconder, etc) e exportá-los para ficheiros
excel, CSV, entre outros. É também possível que as ALVs sejam editáveis e com isso
seja possível introduzir, apagar, editar informação directamente nas tabelas (Rossi
2010);
Sapscript – foi a primeira tecnologia de impressão de formulários da SAP ainda
largamente utilizada pois existem muitos programas baseados nesta tecnologia, o
layout é todo desenhado manualmente, sendo usadas coordenadas e unidades de
medida para posicionar a informação nas páginas (Heidecker 2013);
Smartforms – tecnologia mais recente de impressão de formulários que trouxe a
facilidade de criação dos formulários permitindo a modelação lógica e o desenho do
layout com recurso a ferramentas gráficas (Heidecker 2013);
Smartstyles – definição dos estilos dos elementos dos Smartforms e Sapscript, como
por exemplo criação de tipos de parágrafos e seus tipos de letra, tamanho e
espaçamento.
Ampliações – são pontos onde a SAP permite a alteração do sistema standard de
forma a customizar o mesmo para que este responda a requisitos de negócio dos
mesmos. Estas ampliações podem ser Exit, BADI (Business Add-ins), Enhancement e
BTE (Business Transaction Events).
BAPI (Business Application Programming Interface) – permite o acesso a funções
SAP por via de código efectuado nos programas ABAP, por exemplo podem ser
usadas para criar vários documentos de forma automática em vez de serem criados de
forma manual, poupando assim tempo e automatizando processos.
17
4 Áreas de Consultoria
Neste capítulo é contextualizada a consultoria como actividade profissional bem como os
principais sectores onde os projectos foram desenvolvidos. São ainda abordados alguns
aspectos relacionados com sistemas Enterprise Resource Planning (ERP) de forma a
enquadrar uma das áreas do trabalho desenvolvido que inclui os projectos de consultoria
em tecnologias SAP. Devido ao facto dos projectos serem desenvolvidos na tecnologia
SAP, esta tecnologia será detalhada em mais pormenor. Estão presentes conceitos sobre
estes sistemas, a sua evolução ao longo do tempo, principais sistemas disponíveis no
mercado e aspectos sobre o seu ciclo de vida.
4.1 Consultoria
Nos dias que correm a maioria das empresas recorrem constantemente a serviços de
consultoria especializados que tragam valor acrescentado às empresas. Os consultores
tanto podem oferecer aconselhamento como apresentar um conjunto de soluções com vista
à resolução de problemas específicos.
A palavra consultor tem origem na língua Latim, palavra consultare, que significa “pensar
com”. Os consultores ajudam os clientes a pensar na melhor forma de resolver problemas
específicos e juntos determinam a melhor solução (Expresso 2014).
A consultoria pode ser dividida em duas categorias:
Consultoria interna: acontece quando um profissional é consultado por
colaboradores ou departamentos internos da sua empresa, sendo estes considerados
clientes;
Consultoria externa: acontece quando um profissional presta serviços aos clientes
externos da sua empresa. Os seus conhecimentos são fornecidos durante um
18
período de tempo a troco de uma tarifa. Normalmente neste tipo de consultoria o
consultor tem a oportunidade de trabalhar com muitos clientes.
Os projectos foram desenvolvidos nestas duas categorias, tanto apoiando clientes internos
da instituição como apoiando clientes da instituição. Os projectos na categoria de
consultoria externa foram realizados tanto nas instalações dos clientes, como nas
instalações da Deloitte através de trabalho remoto, acedendo aos sistemas dos clientes via
Virtual Private Network (VPN). A ligação via VPN permite a ligação aos sistemas dos
clientes por meio da infra-estrutura pública usando mecanismos de criptografia para
manter seguros os dados da ligação.
Existem vários ramos da consultoria, consultoria de recursos humanos, consultoria de
gestão, consultoria legal, entre outro. Neste caso os projectos foram desenvolvidos na
consultoria de tecnologias de informação, mais exactamente em tecnologias SAP e
Microsoft.
4.2 Sectores da Banca e Retalho
Os clientes aos quais foram prestados serviços operam sobretudo nos sectores da Banca e
do retalho.
O sector da Banca desempenha um papel muito importante no papel da economia, os
bancos são o principal meio para a obtenção de crédito para o investimento por parte das
empresas. Os bancos são também os principais financiadores dos privados para a obtenção
de moradia própria, por outro lado, os depósitos dos clientes constituem uma parte
importante na estrutura de financiamento dos próprios bancos (APB 2013). Pode-se
afirmar que este sector desempenha um papel muito importante no motor da economia,
pois as empresas sem financiamento não podem investir na inovação e tecnologia de forma
a se tornarem cada vez mais competitivas em relação ao mercado, e se posicionarem como
grande impulsionadoras de criação de emprego e geração de riqueza no país.
O sector do Retalho é caracterizado pela venda de produtos em pequenas quantidades aos
consumidores finais, ao contrário do sector grossista que consiste na venda de produtos em
grandes quantidades aos intermediários, que depois podem vender em pequenas
quantidades, chamado o retalho. Os produtos podem ser vendidos em lojas físicas, lojas
19
on-line, na rua, em mercados, entre outros. Podem-se considerar como exemplos da venda
a retalho os supermercados, lojas de conveniência, lojas de desporto, lojas de mobiliário e
lojas de ferragens.
4.3 Sistemas Enterprise Resource Planning
Num mundo empresarial em crescente competitividade as organizações necessitam cada
vez mais de obter informação em tempo quase real, não só sobre os competidores, mas
essencialmente do desempenho das suas operações. Tendo esta necessidade em mente as
organizações estão a optar pela adopção de sistemas de apoio à gestão como os ERPs.
No início dos anos noventa as empresas começaram a mudar a sua estratégia no campo das
Tecnologias da Informação (TI), deixaram de produzir internamente os seus softwares e
começaram a adquirir as aplicações de gestão, como os ERPs a empresas externas (Hong
2002).
Os ERPs são sistemas integrados que possibilitam o fluxo de informação entre os diversos
sectores do negócio, agregando a informação numa única base de dados consistente,
possibilitando a obtenção de um retracto em tempo real sobre o funcionamento das
organizações.
São ferramentas que melhoram os processos dos clientes, como por exemplo processos de
compras, recursos humanos, distribuição (Scott Buckhout 1999).
Segundo Davenport, um ERP é um software que integra toda a informação que circula pela
empresa, desde informação financeira, recursos humanos, clientes, compras e vendas
(Davenport 1998).
Estes sistemas são sistemas de informação configuráveis e que integram informação e
processos de negócio transversais a todas as áreas funcionais da organização (K. Kumar
2000).
Tadjer caracteriza os ERPs como sendo uma sistema que engloba uma única base de
dados, uma única aplicação e uma interface única transversal a toda a empresa (Tadjer
1998).
Segundo O’Leary, ERPs são sistemas informáticos desenhados para processar as operações
da organização, facilitar a integração, planeamento em tempo real, produção e resposta aos
utilizadores (O’Leary 2001).
20
Os ERPs incorporam as melhores práticas, estas práticas surgem da comparação efectuada
a processos de organizações idênticas (Galpin 1996), e devem ser implementados sem
exagero nas alterações, sob pena da diminuição do desempenho do sistema, problemas em
caso de upgrades futuros do sistema e dificuldades de manutenção.
Frequentemente os ERPs são implementados em empresas com os seus processos de
negócio claramente definidos e podem não incluir algumas funcionalidades que permitam
a transposição dos respectivos processos para o sistema. Por vezes os sistemas são
customizados para abarcar os processos de negócio, com as condicionantes anteriormente
referidas, ou em alternativa a empresa altera a sua filosofia para que alguns dos seus
processos reflictam o comportamento do ERP adoptado. Podemos concluir que as
implementações dos ERPs tentam reflectir as boas práticas transversais a todas as
empresas, mas que nem sempre esse conceito pode ser totalmente implementado devido
aos processos pré-existentes nas empresas não serem suportados nativamente pelos ERPs.
Apesar dos ERPs contemplarem uma grande variedade de áreas de actuação e incluírem os
seus processos mais comuns, os ERPs não oferecem processos de negócio que se adeqúem
a todos os processos das empresas.
4.3.1 Caracterização
Os ERPs possuem uma estrutura modular, em que cada módulo corresponde a uma área
funcional do negócio, estes sistemas permitem a integração de processos e integração de
informação ao longo do domínio de uma organização. São sistemas passíveis de serem
adaptados de forma a corresponderem às necessidades dos clientes, pois apesar de serem
sistemas que reúnem as melhores práticas, são sistemas muito abrangentes que têm que ser
configurados de forma a serem adaptados à realidade de cada cliente.
Os ERP permitem o acesso, integração e processamento dados em tempo real consolidados
sobre uma base de dados única. Oferecem um fluxo de informação transversal às áreas
funcionais.
Com os ERPs é possível automatizar processos, facilitando as operações e a gestão do
negócio. Estes sistemas suportam processos críticos nas mais variadas áreas do negócio
(Vincent A. Mabert 2003).
21
Na Figura 9 é apresentado um modelo, proposto por Uwizeyemungu e Raymond, das
principais características dos ERPs, que as divide em três áreas, área Técnica,
Organizacional e Informacional (Sylvestre Uwizeyemungu 2004).
Figura 9 - Características ERP Uwizeyemungu e Raymond (2004) (Adaptado)
4.3.2 Evolução
Pode-se afirmar que sistemas ERP têm origem na década de 70 nos sistemas Material
Resource Plannig (MRP), até então as aplicações existentes eram apenas para controlo de
stock, este tipo de sistemas permitiam gerir e planear inventários gerindo a procura dos
produtos pelo planeamento da produção. A estes sistemas na década de 80, foram
atribuídas mais funções sendo elas: funções de programação da produção; cálculo de
necessidades de capacidade de produção e controlo de compras e vendas.
Com estas funções os sistemas MRP alagaram as necessidades relacionadas ao cálculo de
necessidades de materiais, para incorporar também necessidades de informação para a
tomada de decisões relacionadas com a gestão de outras áreas da produção. O MRP
recebeu então a designação de MRP II.
Os fornecedores de software como forma de expandir a sua oferta depressa se apressaram a
desenvolver novos módulos para além dos relacionados com a produção, como por
exemplo: Gestão de recursos Humanos; Vendas e Distribuição; Financeiro.
22
Estes sistemas cada vez mais abrangentes de quase todas as actividades do negócio das
empresas receberam o nome de ERP.
Na Figura 10 podemos observar uma anatomia de um sistema de informação empresarial,
de notar a base de dados central onde todas as aplicações vão consultar/escrever
informação. Podemos constatar que estes sistemas são vitais no funcionamento das
organizações pois interligam de maneira transversal as áreas de negócio, empregados,
gestores, funcionários e fornecedores (Davenport 1998).
Figura 10 - Anatomia de um Sistema de Informação Empresarial (Davenport 1998)
O conceito de ERP existe desde os anos 60. No entanto, até 1972 não tinha nome ou
classificação. Era um conceito no qual as organizações tentavam integrar os departamentos
e funções de forma a aumentar os proveitos e fortalecer o negócio. Em 1972, cinco
directores da IBM abandonaram a empresa e formaram uma nova empresa para
desenvolver o seu conceito de ERP. Essa empresa, então fundada, é conhecida actualmente
por SAP (Systems, Applications and Products). Esta empresa alemã (SAP) tornou-se
eventualmente na primeira empresa a desenvolver e implementar aplicações ERP, sendo
actualmente a líder mundial (Gøtze 2009).
23
4.3.3 Sistemas ERP Existentes
SAP - Fundada em 1972 na Alemanha por cinco engenheiros da IBM. O seu sistema foi
optimizado para gerir os processos de produção e gestão, logística e recursos humanos. É
considerada a maior empresa fornecedora de ERP a nível mundial, contribuindo para isso
ter sido uma das pioneiras (Castro 2009).
Oracle - Produz e vende aplicações ERP desde 1987, sendo a maioria dos seus clientes
empresas ligadas à produção e consumo de dados, sendo assim um adversário directo da
SAP. Curiosamente em cerca de 80% dos casos, o software da SAP opera sobre uma base
de dados da Oracle (Castro 2009).
Primavera BSS - Empresa portuguesa de software, fundada em 1993. Desenvolve e
comercializa soluções de gestão e plataformas para integração de processos empresariais,
disponibilizando soluções para as Pequenas, Médias, Grandes Organizações e
Administração Pública (Castro 2009).
Microsoft Dynamics - Empresa multinacional norte americana fundada em 1975,
frequentemente abreviada como MS. Microsoft Dynamics é a linha da Microsoft destinada
a empresas. Era anteriormente conhecido pelo seu nome de projecto Green, e substitui a
família de aplicações da Microsoft Business Solutions. Esta família de produtos inclui
vários softwares como Microsoft Dymamics AX [ex-Axapta], direccionado para a gestão de
empresas – ERP (Castro 2009).
Sage – A empresa tem um produto de gestão integrado com o mesmo nome que cobre
todas as necessidades de gestão de uma empresa: Contabilidade e Gestão Financeira,
Gestão Comercial, CRM, Gestão de Produção, Gestão de Armazéns e logística. O grupo
Sage, fundado em 1981, é líder mundial em soluções de software de gestão para Pequenas
e Médias Empresas (PME), contando com mais de 5,5 milhões de clientes em todo o
mundo (SAGE 2014).
PHC – Fundada em 1989 possui sucursais em Portugal, Moçambique, Angola e Espanha.
A PHC oferece um ERP com o mesmo nome, possui uma carteira de mais de 29000
empresas, mais de 134 mil utilizadores, 420 Parceiros e cerca de 135 Colaboradores (PHC
2014).
Alidata – Com início da actividade em 1984, esta empresa oferece aos seus clientes o
Alidata® ERP, podendo ser Small Business ou Enterprise, conforme os módulos
24
disponíveis, entre eles: Gestão Comercial, Gestão de Oficinas/Concessionários, Gestão de
Obras e Gestão de Produção. A empresa é especialista no sector industrial e automóvel,
onde tem o seu ERP implementado em mais de 5.000 empresas e mais de 30.000
utilizadores (Alidata 2014).
4.4 Ciclo de Vida de um ERP
A definição de ciclo de vida dos ERPs é difícil de ser consensual entre os autores, Esteves
propôs uma definição que apresenta seis fases como se pode observar na Figura 11
(Esteves 1999).
Figura 11 - Ciclo de vida de ERP (Esteves, 1999)
As fases podem ser caracterizadas como:
Decision Planning – Planear a decisão – é a fase onde são questionadas as
necessidades de ter um ERP e recolha de informação sobre qual sistema se adequa
melhor à criticidade do negócio da organização. Esta fase inclui a definição de
requisitos, metas, benefícios e análise de impacto que esta adopção pode ter a nível
organizacional;
Acquisition – Aquisição – é a fase onde é escolhido o produto que melhor
corresponde aos requisitos e que requer o mínimo de customização. É escolhida
também uma consultora para ajudar nas próximas fases do ciclo de vida do ERP.
São considerados os factores como o preço, a formação e a manutenção. É
celebrado um contracto e é importante analisar o retorno do investimento deste
produto.
Implementation phase – Fase de implementação – Consiste na customização,
parametrização e adaptação do ERP de acordo com as necessidades da organização,
25
normalmente feita por consultores especializados que oferecem metodologias de
implementação, know-how e formação;
Use and maintenance phase – Uso e manutenção – Consiste no uso do produto para
que haja o benefício esperado. Nesta fase é necessário que o sistema seja mantido
de forma a corrigir maus funcionamentos e implementar pedidos de optimização
necessários de forma a garantir o correcto funcionamento dos sistemas;
Evolution phase – Fase de evolução – Corresponde à integração de novas
funcionalidades no ERP de forma a trazer mais e melhores benefícios como por
exemplo gestão de relação com o cliente (Customer Relationship Management),
gestão da cadeia de abastecimento (Supply-Chain Management);
Retirement phase – Fase de descontinuação – Esta fase acontece quando o ERP fica
obsoleto pelo aparecimento de novas tecnologias ou a incapacidade do ERP em
corresponder às novas necessidades do negócio.
4.5 Factores Críticos na implementação de um ERP
Quando se toma uma decisão de implementar um ERP há sempre dificuldades que se
encontram ao longo do percurso, mas a não consideração que um ERP poderá evoluir ao
longo do tempo conforme as necessidades, quer por verificação de que os processos podem
ser melhorados, quer por novas necessidades de negócio ou até obrigações legais poderá
ser a primeira dificuldade. O não reconhecer este facto poderá afectar o planeamento a
longo prazo, pois para estas alterações é preciso verba, que ao ser negligenciada poderá
faltar, ou em caso de não negociada com a empresa que fez a implementação poderá fazer
com que os custos de manutenção fiquem mais elevados que os custos de implementação
(Fernando Alexandre Rodrigues Gambôa 2004).
Outro factor crítico é a falta da clara definição por parte das pessoas chave da organização,
das metas estratégicas, e a forma que a companhia se deve posicionar no processo de
implementação do ERP de modo a satisfazer os clientes, desenvolver e dar poder aos
funcionários e facilitar a relação com os fornecedores. Deve existir uma ideia bastante
clara e cuidadosamente definida do porquê da implementação do ERP, bem como o que é
critico para o negócio e que o ERP tem que corresponder.
Para que uma implementação seja bem-sucedida é importantíssimo que a gestão de topo
esteja comprometida e participativa no projecto, porque se tal não acontecer os
26
colaboradores podem colocar entraves e prolongar a implementação.
A gestão do projecto é outro factor crítico, se não for feita uma boa gestão os prazos e os
custos podem derrapar, por diversos motivos como definição do âmbito errada, alocação de
recursos com capacidades técnicas erradas para o projecto, prazos irrealistas para as tarefas
necessárias. A implementação deverá ser orientada para os casos de negócio da
organização e desenhada em conjunto com as pelas pessoas que lidam com os processos
directamente.
A volatilidade do negócio e as constantes mudanças organizacionais podem condenar uma
implementação na medida que prazos muito longos de implementação podem fica
obsoletos quando a implementação terminar, ou a gestão mudar e não se rever na estratégia
traçada pela anterior gestão, postos de trabalhos extintos. É recomendável que as
implementações sejam incrementais e em períodos de tempo relativamente curtos.
É essencial que os dados sejam correctos para garantir o bom funcionamento do sistema
dado que a natureza do ERP o torna transversal e agregador de informação a toda a
organização, um erro pode ter um efeito negativo em forma de dominó ao longo de toda a
organização.
Um factor talvez, o de mais importância é o factor da formação aos utilizadores, são eles
quem vão utilizar o sistema e é importante que o saibam fazer bem, e só com formação e
treino é que vão perceber o funcionamento do mesmo. Se os funcionários não perceberem
como o sistema de forma a tirarem o máximo partido dele, vão inventar os seus próprios
processos e desvirtuar o seu uso, poderão até deixar de usar o ERP e tentar fazer o seu
trabalho em sistemas paralelos (Elisabeth J. Umble 2002).
4.6 Caracterização SAP
A SAP (Systeme Anwendungen Produkte in der Datevenverarbeitung), que em português
significa “Sistemas, aplicações e produtos em processamento de dados”, foi fundada em
1972 por cinco engenheiros ex-trabalhadores da IBM, um dos três maiores fornecedores de
software de gestão empresarial, oferecendo diversas aplicações e serviços para todo o tipo
de organizações, quer ao nível da dimensão quer de sectores de actividade. Tem
aproximadamente 285 mil clientes em mais de 180 países, emprega mais de 51.500
pessoas num total de 50 países dispersas por 140.000 instalações e conta com um total de
12 milhões de utilizadores finais, está presente em 86% das empresas da Fortune 500 (SAP
2014).
27
Em 1973 a empresa lança para o mercado o seu primeiro produto, um módulo de
contabilidade financeira. Este módulo é o ponto de partida para um desenvolvimento
contínuo de outros módulos de software de um sistema que mais tarde seria conhecido por
SAP R/1, sendo o R de real-time data processing.
Em 1979 a SAP começa a operar em servidores próprios e depois de uma inspecção a uma
base de dados IBM e da análise ao controlo do sistema em diálogo, a SAP começou a
repensar o seu software abrindo assim caminho para a nova geração chamada SAP R/2,
versão que ficou estável em 1981.
No início da década de 90, mais precisamente em 1992 a SAP lança a nova versão do seu
ERP, a versão R/3. Esta versão ao contrário das anteriores em que a sua arquitectura era de
servidor, esta versão apresenta uma arquitectura cliente/servidor, como se pode observar na
Figura 12
A arquitectura do R/3 consiste em servidores de aplicações e servidores de bases de dados
e computadores como clientes desses servidores numa rede, utilizando uma ferramenta
gráfica chamada SAP GUI ou o browser da internet podendo o utilizador navegar pelos
programas usando um menu ou inserindo as transacções destinadas os mesmos.
Figura 12 - Arquitectura cliente-servidor SAP R/3 (SAP 2009)
Os servidores de aplicações fornecem o software “aplicacional” enquanto os servidores de
bases de dados armazenam a informação, o SAP pode usar diversos sistemas de bases de
dados, entre eles ORACLE ou Microsoft SQL Server. O SAP possui uma camada
28
transparente que mapeia o os campos do software aplicacional em campos e formatos
específicos para o motor de base de dados que está instalado para o sistema.
O sistema suporta um número variado de servidores em várias máquinas diferentes,
também não há restrição quanto ao número de utilizadores.
O SAP R/3 é um sistema que pode ser implementado módulo a módulo conforme as
necessidades do cliente, ou pode ser implementada a versão completa.
Estas características fazem do sistema R/3 um sistema adaptativo aos diferentes tipos e
tamanhos de empresas. Por ser um sistema que pode ser implementado em organizações de
qualquer tamanho, mas devido a ser um sistema bastante completo e dispendioso de
implementar, torna-se um sistema que não está ao alcance de todas as organizações.
Para além do SAP R/3 ser um pacote standard configurável, de forma a que este possa dar
resposta às especificidades dos clientes, uma vez que o SAP engloba as melhores práticas
de negócio, mas não consegue albergar todos os processos de negócio de todos os clientes,
seja customizado através da sua linguagem de programação chamada ABAP (SAP 2014).
Desta forma o sistema pode acompanhar o crescimento de uma organização de uma forma
simples e consistente.
Na Figura 13 podemos observar a arquitectura SAP R/3 baseada num sistema aberto, este
sistema permite a independência de plataformas, deixando ao cargo da organização a
escolha dos sistemas operativos e sistemas de gestão de bases de dados, reduzindo assim o
custo do SAP R/3 (ISPGAYA s.d.).
Figura 13 - Tecnologia SAP: Sistema Aberto (ISPGAYA s.d.)
29
4.6.1 Módulos SAP R/3
O pacote base do SAP R/3 é constituído pelos módulos apresentados na Figura 14 e
caracterizados em baixo.
Figura 14 - Principais módulos SAP (ISPGAYA s.d.)
Contabilidade Financeira (Financial Accounting, FI)
O módulo de FI é o responsável pela gestão financeira da organização (contabilidade geral,
contas a pagar e contas a receber, tesouraria, consolidações), suporta o processo da tomada
de decisão estratégica. A integração deste módulo assegura o reflexo dos movimentos
logísticos de mercadorias.
Controlling (Controlling, CO)
A sua principal função é planear e controlar os custos internos do negócio da organização
(contabilidade de Classes de Custos, gestão de Centros de Custos, custos com projectos,
apuramento de resultados). Os cálculos apurados neste módulo são usados para controlar a
rentabilidade de áreas individuais e da organização como um todo. Como o módulo FI, este
módulo também apoia a tomada de decisões.
30
Gestão de Activos Fixos (Asset Accounting, AA)
Módulo onde são efectuadas as operações relacionada com o imobilizado, como por
exemplo cálculos de juros, seguros, actividades de manutenção, depreciações, etc.
Complementa o módulo FI.
Gestão Projectos (Project Systems, PS)
Neste módulo é onde se efectua o planeamento, controlo e supervisão dos recursos e custos
associados aos projectos da empresa.
Fluxo de Trabalho (Workflow, WF)
O Workflow é uma ferramenta de suporte a todos os módulos, automatizando o processo
empresarial com base em procedimentos e regras predefinidas e efectuando a ligação entre
os vários módulos.
Soluções Industriais (Industry Solutions, IS)
O IS é um módulo complementar desenvolvido especificamente para indústrias tais como
petróleo e gás, farmacêutica, etc.
Vendas e distribuição (Sales e Distribution, SD)
O módulo SD é responsável pela área logística da empresa e cobre todos os processos
relacionados com vendas, expedição e facturação. Este módulo fornece informações
preciosas em tempo real, sendo um uma ferramenta importante na tomada de decisões.
Gestão de materiais (Materials Management, MM)
O módulo MM está directamente ligado a todas as áreas funcionais, dá suporte a todas as
fases de gestão de materiais: planeamento e controlo, compras, entrada de mercadorias,
gestão de stocks e verificação de facturas.
31
Planeamento da Produção (Production Planning, PP)
No módulo PP é possível efectuar o controlo da produção, criação dos centros de trabalho,
criação de listas técnicas, planeamento de vendas, expedição e cálculo de custos de
produção.
Gestão da Qualidade (Quality Management, QM)
A Gestão da Qualidade permite efectuar o planeamento, execução e gestão das inspecções.
Neste módulo são estabelecidas as especificações de qualidade e procedimentos de ensaio,
controlo de criação de certificados. Permite o armazenamento de dados relacionados com a
qualidade das matérias primas bem como os dados dos produtos acabados.
Manutenção (Plant Maintenance, PM)
Este módulo permite o planeamento e programação de intervenções com intervalos de
tempo pré-definidos por forma a manter a operacionais as instalações, e preservação dos
equipamentos e materiais. Permite a criação de listas de materiais para serem gastos na
manutenção.
Recursos Humanos (Human Resources, HR)
Este módulo é o responsável pela gestão dos aspectos relacionados com os recursos
humanos da empresa, desde processamento de salários, registo do historial dos
colaboradores, planeamento da formação, recrutamento, gestão de carreias a indicadores de
análise como por exemplo desempenho e assiduidades (Oliveira 2009).
Para além dos módulos base ainda existem outros que são de instalação base, são os casos
dos módulos BASIS que é o módulo de administração do sistema, módulo ABAP que é
onde a customização é efectuada e sobre o qual o sistema efectua a compilação das
aplicações.
32
Outros módulos disponíveis:
SAP BW – Business Data Warehouse;
SAP EC – Enterprise Controlling;
SAP TR – Treasury;
SAP IM – Investment Management;
SAP CRM – Customer Relationship Management;
SAP SCM – Supply Chain Management;
SAP PLM – Product Life Cycle Management;
SAP SRM – Supplier Relationship Management;
SAP CS – Customer Service;
SAP SEM – Strategic Enterprise Management;
SAP RE – Real Estate.
4.6.2 Metodologia de desenvolvimento SAP
Em 1996, com o objectivo de acelerar os tempos de implementação dos projectos desta
tecnologia, a SAP criou uma metodologia a que chamou de Accelerated SAP (ASAP). Esta
é uma metodologia estruturada que facilita a adesão dos utilizadores ao sistema, com um
roadmap de implementação bem definido e documentação para as várias fazes do que a
compõem. Esta metodologia disponibiliza aos clientes SAP a experiência e conhecimentos
adquiridos devidos a um sem número de implementações em todo o mundo. A ASAP
unifica assim todo um processo de implementação com o fim de alcançar um bom porto
nas implementações de forma a alcançar a missão crítica das funcionalidades do negócio
da organização (José Esteves 2001).
Na Tabela 1 estão presentes as fases do roadmap ASAP e a respectiva Descrição.
33
Tabela 1 - Fase Roadmap ASAP
Fases de
Implementação
Descrição
Preparação do
Projecto
O objectivo desta fase é definir o início do projecto, identificando os elementos da
equipa e o desenvolvimento do plano de trabalho.
Oficialmente o preâmbulo dos trabalhos é marcado com uma reunião chamada de
Kickoff, onde estão presentes todos os intervenientes do projecto e se clarificam as
funções e responsabilidades de cada um dos elementos.
No preparar da implementação são definidos as metas e objectivos, esclarecimento
do âmbito e a estratégia de implementação, planeamento e sequência geral e o
estabelecimento da organização.
Análise dos
Processos de
Negócio
Consiste em criar uma análise de processos de negócio, que se caracteriza numa
descrição pormenorizada dos resultados das entrevistas (Workshops) entre os
consultores funcionais e os utilizadores chaves. Dessa forma são documentadas as
exigências do processo de negócio da organização através duma ferramenta de
perguntas e respostas, baseadas num fluxo de documentos. Tendo por base a
documentação compilada atinge-se um entendimento comum de como a organização
pretende gerir seus negócios no sistema SAP.
Realização Desenvolve-se um modelo de estado futuro, de uma forma integrada e de acordo com
as soluções documentadas nos processos de negócio do cliente. Cada um dos
processos analisados na fase anterior é parametrizado, testado, validado e
documentado de um modo cíclico. Conceptualmente o processo de refinamento é
interactivo, em que se obtém um resultado através das várias repetições, até à
obtenção de resultados satisfatórios das necessidades declaradas.
Preparação Final O intuito desta fase é concluir a preparação final, estratégia de arranque,
Migração dos dados de negócio, testes, treino dos utilizadores, administração do
sistema, preparação da saída dos consultores, de modo a finalizar os pendentes para o
início em produtivo. A preparação final serve para resolver todas as actividades
cruciais que estão pendentes. A conclusão bem-sucedida desta fase, irá permitir ao
utilizador as condições necessárias ao sistema activo SAP.
A SAP contempla um serviço de testes que permite que especialistas da própria SAP
inspeccionem remotamente o sistema e avalia potenciais problemas, disponibilizando
recomendações para a sua optimização.
Entrada em
Produtivo e Suporte
Esta etapa é marcada pelo culminar de um ambiente pré-produtivo para o início
oficial do sistema em produtivo. É chamada de Go-Live.
É necessário preparar uma organização de suporte para os utilizadores, não só nos
primeiros dias críticos das operações produtivas, mas para fornecer um suporte a
longo prazo. O principal produto do ASAP utilizado é a avaliação do desempenho do
sistema. Desta forma dá-se o projecto como concluído, passando a organização a ser
responsável pela sobrevivência do sistema onde poderão existir mudanças contínuas
de reengenharia de processos.
4.6.3 Fluxo de desenvolvimento
O fluxo de configuração e desenvolvimento dos sistemas SAP normalmente obedece a uma
sequência, a configuração e desenvolvimento em servidores próprios para o efeito, quando
o processo está concluído os trabalhos são enviados para um servidor de testes,
normalmente chamado de qualidade, para serem testados. Se os testes não tiverem sucesso,
os trabalhos são revistos e melhorados e novamente enviados para testes, se os testes
tiverem sucesso os trabalhos são enviados para o servidor de produção, é este servidor que
os utilizadores finais utilizam para o seu trabalho normal.
34
Na Figura 15 podemos observar o fluxo anteriormente descrito, em que DEV é o servidor
de desenvolvimento, QAS é o servidor de testes/qualidade e PROD, o servidor de
produção.
Figura 15 - Fluxo de desenvolvimento SAP R/3
Qualquer trabalho que seja feito em SAP, quer seja de configuração, quer seja de
programação fica associado a uma ordem, que é transmitida ao administrador de sistemas.
Com o identificador da ordem, o administrador transporta-a de sistema em sistema. A
ordem para poder ser transportada tem que ser liberada, quando isto acontece deixa de ser
possível efectuar mais trabalhos nessa ordem; caso seja necessário terá que ser gerada uma
nova ordem e o transporte das ordens terá que ser efectuado por ordem, da mais antiga para
a mais nova.
Estas ordens passam de sistema em sistema, até chegar ao sistema de produção. Os
sistemas de qualidade e produção estão configurados de forma a que seja impossível alterar
ou criar novos programas, sendo obrigatório sempre que seja necessário efectuar
modificações ou criar novos programas, o processo se inicie no sistema de
desenvolvimento.
As ordens podem ainda ser transportadas para outras máquinas de desenvolvimento,
podendo assim ser reutilizado o desenvolvimento e replicado para outros clientes que
tenham os mesmos requisitos de negócio.
As ordens de desenvolvimento são agrupadas num pacote que engloba todos os objectos
que pertencem ao mesmo desenvolvimento e que partilham o mesmo sistema. Usualmente
35
são criados pacotes que albergar os desenvolvimentos que fazem parte dos diferentes
módulos de SAP: SD, FI, MM.
Nestes sistemas é possível comparar as versões dos programas de sistema para sistema. Em
caso de erro consegue-se despistar as diferenças nas versões dos diversos sistemas. Em
caso de necessidade é possível reverter para versões anteriores, escolhendo assim a versão
onde o desenvolvimento se comporta como o desejado.
Podemos concluir que é um sistema bastante testado e maduro, reflexo de um processo
com grande maturação.
37
5 Projectos de Consultoria
Neste capítulo estão apresentados os projectos realizados no âmbito de consultoria prestada
aos clientes internos e externos da Deloitte.
É feita uma caracterização dos clientes, dos desafios propostos, é apresentada a solução
concebida para os ajudar a superar as suas dificuldades. É ainda, efectuada uma pequena
conclusão sobre cada projecto.
5.1 Projectos SAP
Neste subcapítulo estão apresentados os projectos de consultoria realizados na tecnologia
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.
39
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
41
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.
43
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
Horas HHMMSS
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.
45
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.
47
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.
49
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.
51
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
fornece para transferir ficheiros de pastas do servidor para uma pasta local do computador
do utilizador, ou directamente na pasta do sistema operativo sobre o qual corre o SAP; com
este processo os problemas de time-out e de esgotamento de memória não aconteceriam.
Foi então adicionada a função de execução em Background que representa a solução
apontada pela administração de sistemas SAP da AMS.
Figura 30 - Layout do ecrã do JET
53
Foi elaborado um manual de operação do programa, apresentado no Anexo Três, pois a
opção de execução em Background para quem não tem conhecimentos de administração de
sistemas SAP, mais propriamente no agendamento de jobs (agendamento de tarefas para
correr em background) poderá ter dificuldade em operar o programa.
5.1.2.4 Conclusões
O desenvolvimento deste programa permitiu uma centralização dos processos de extracção
dos dados, a partir do momento em que a versão final do programa foi colocada em
produção nos clientes, a extracção dos dados passou a ser feita num único lugar,
eliminando assim a execução de vários passos até se conseguir obter os dados desejados.
Eliminou também a conciliação dos dados por parte da equipa de auditoria, uma vez que as
tabelas finais já trazem os dados finais a analisar.
Este programa tornou todo o processo mais simples, mais rápido, mais eficaz e mais fácil
para os utilizadores.
As empresas que operam segundo regulação de entidades como o Banco de Portugal e
Comissão do Mercado de Valores Mobiliários são auditadas constantemente de forma a
poderem continuar com as suas operações, e devido a esse facto este desenvolvimento veio
facilitar a aquisição de dados de sistemas SAP para as tão necessárias auditorias.
Devido à complexidade do modelo relacional das tabelas em SAP, muitas vezes é difícil
conciliar a informação retirada de várias tabelas, no caso deste programa não foi excepção.
Os dados que este programa estrai são utilizados em programas comerciais de detecção de
fraude. Consideramos que poderia ser uma mais-valia para os sistemas SAP englobar um
programa como o que foi desenvolvido por forma a tornar mais simples a extracção de
dados para auditoria.
5.1.3 Determinação automática do Centro de Custo para Pedido de
Compra de Imobilizado
Este desenvolvimento consistiu na criação de uma funcionalidade que determinasse e
preenchesse o centro de custo no pedido de compra de imobilizado.
54
O principal objectivo desta funcionalidade é assegurar a consistência e transversalidade do
valor do centro de custo ao longo de todas as etapas do processo logístico, desde a criação
do pedido de compra de imobilizado à respectiva entrada de factura, prevalecendo em cada
uma o valor definido ao nível dos dados mestre do imobilizado para este campo, como
pode ser observado Figura 31. Os dados mestre são os dados que compreendem as
características de um item, como por exemplo o nome, dimensões e número de
identificação. Estes dados são preenchidos quando se cria um item em sistema, quer seja
um colaborador, cliente, material ou imobilizado, todos eles têm características que são
especificas a que são chamados dados mestre.
O valor é preenchido num campo que permite ao utilizador preencher qualquer valor para o
centro de custo, como se pode observar na Figura 32, desde que esse valor esteja na base
de dados, ou seja, o utilizador pode preencher um centro de custo para o imobilizado que
não corresponda ao correcto.
Este desenvolvimento está relacionado com o módulo Gestão de materiais.
Figura 31 - Dados mestre do imobilizado
Figura 32 - Tela pedido de compra
55
5.1.3.1 Caracterização do cliente
Esta funcionalidade foi desenvolvida para um banco Angolano. O banco tem cerca de 2000
colaboradores.
5.1.3.2 Requisitos
O levantamento de requisitos foi realizado pela equipa funcional que está responsável pela
manutenção e evolução do sistema SAP do banco.
A equipa forneceu os requisitos para esta funcionalidade que podem ser consultados no
Anexo Quatro , e onde constam os seguintes requisitos:
A criação de imobilizados em sistema é efectuada exclusivamente através da
transacção AS01;
O automatismo para preenchimento de forma automática do campo centro de custo
apenas se encontrará activo no momento de criação de pedidos de compra de
imobilizado (categoria de classificação contábil A – Imobilizado);
O centro de custo que prevalece em todas as etapas do processo logístico é aquele
que se encontra definido nos dados mestres do imobilizado, campo “ANLZ-
KOSTL”;
O desenvolvimento desta funcionalidade deve ser efectuado recorrendo à BADI
Z_ME_PROCESS_PO_COST já existente no BNA.
5.1.3.3 Implementação
Um dos requisitos foi a utilização da BADI Z_ME_PROCESS_PO_COST que já tinha sido
usada anteriormente na implementação de outras funcionalidades no sistema.
A palavra BADI tem origem em Business Add Ins, que são ampliações ao sistema
standard. As ampliações permitem acomodar requisitos de negócio que são demasiado
específicos para serem incluídos na solução standard.
Apesar da equipa funcional ter indicado a BADI a utilizar, não significa que se tenha que
utilizar a mesma uma vez o fluxo do programa pode não passar na BADI no momento no
56
qual é preenchido o imobilizado na tela. Quando o fluxo do programa não passa pela BADI
indicada, é necessário procurar uma outra onde o fluxo do programa passe no momento
certo.
Após análise do processo de criação do pedido de compra, verificou-se que a BADI pode
ser utilizada neste desenvolvimento.
Foi verificado que a variável im_item continha a informação necessária e que esta podia
ser colocada em variáveis locais através dos métodos get_data() para a informação sobre o
item, e get_accountings() para a informação sobre as contas do razão.
Com a informação das contas numa tabela adquirida com a instrução lt_accountings =
im_item->get_accountings( ) foi realizado um ciclo loop para percorrer todas as contas, no
ciclo foi feita uma pesquisa à base de dados à tabela anlz de forma a determinar o centro de
custo para aquela conta e preencher o campo kostl, que corresponde ao campo do centro de
custo na tela do pedido de compra, com as instruções ls_mepoaccounting-kostl = lv_kostl
e ls_accounting-accounting->set_data( ls_mepoaccounting ), é necessário utilizar o
método set_data pois uma simples atribuição não resulta neste caso.
Teve que ser colocada uma protecção para impedir que esta BADI interferisse noutro
processo que não o dos pedidos de compra, por isso foi adicionada a instrução if sy-tcode
eq 'ME21N' or sy-tcode eq 'ME22N' or sy-tcode eq 'ME23N' que utiliza uma estrutura de
sistema que é o sy que contém entre outros, o campo correspondente às transacções dos
processos, as transacções relativas aos processos de compras são a ME21N para criação,
ME22N para alteração e ME23N para exibição de pedidos de compra.
No código seguinte podemos observar parte do código desenvolvido.
method if_ex_me_process_po_cust~process_item.
* LSismeiro Jan/Fev - 2014 - Automatismo KOSTL (INÍCIO)
data: ls_item type mepoitem,
ls_mepoitem type mepoitem,
ls_mepoaccounting type mepoaccounting,
lt_accountings type purchase_order_accountings,
ls_accounting type purchase_order_accounting,
lv_kostl type anlz-kostl.
* Apenas para Transacções Pedido Compra
if sy-tcode eq 'ME21N' or sy-tcode eq 'ME22N' or sy-tcode eq 'ME23N'.
* Retorna Item
ls_item = im_item->get_data( ).
authority-check object 'Z_EKPO_MAT'
for user sy-uname
id 'ACTVT' field '02'
57
id 'MATKL' field ls_item-matkl.
if sy-subrc ne '0'.
message e398(00) with 'Sem autorização para o grupo de mercadorias'
.
else.
ls_mepoitem = im_item->get_data( ).
lt_accountings = im_item->get_accountings( ).
loop at lt_accountings into ls_accounting.
ls_mepoaccounting = ls_accounting-accounting->get_data( ).
if ls_mepoitem-knttp = 'A'.
select single kostl into lv_kostl
from anlz
where anln1 = ls_mepoaccounting-anln1.
if sy-subrc = 0.
ls_mepoaccounting-kostl = lv_kostl.
ls_accounting-accounting->set_data( ls_mepoaccounting ).
endif.
endif.
endloop.
endif.
endif.
endmethod.
* LSismeiro Jan/Fev -2014 - Automatismo KOSTL (FIM)
Como se pode observar o código tem comentários que indicam o autor do
desenvolvimento, a data e o motivo do desenvolvimento, assim se existirem erros que
tenham que ser corrigidos é mais fácil de chegar ao responsável pelo desenvolvimento e
qual foi o motivo da alteração do sistema standard.
Com o objectivo cumprido e ainda com algum tempo disponível para a disponibilização do
desenvolvimento, tentou-se acrescentar uma mais-valia ao desenvolvimento que passavam
pela protecção do campo de forma a não permitir alterar o valor, ou seja, tornar o campo
inactivo para edição. Depois de alguma investigação e testes, verificou-se que tal não seria
possível no tempo ainda disponível. É possível alterar o valor, mas sempre que se grava o
documento, o valor é novamente alterado para o valor do dado mestre.
Devido ao esforço envolvido e ao prazo para entregar a funcionalidade principal optou-se
por entregar o trabalho sem a protecção contra escrita, seria uma funcionalidade mais
estética e para ficar em conformidade com o campo Conta do Razão que está lado a lado
com o do Centro de custo, que é preenchido automaticamente como acontece agora com o
campo Centro de custo.
Depois dos testes no ambiente de desenvolvimento efectuados com sucesso, o
desenvolvimento foi transportado para o ambiente de qualidade para ser testado com o
58
cliente. Os testes foram concluídos com sucesso e o mecanismo já se encontra no ambiente
produtivo.
5.1.3.4 Conclusões
O cliente ficou bastante satisfeito com o mecanismo pois eliminou o erro humano no
preenchimento deste campo, o que permitiu adquirir relatórios de custos com compras de
imobilizado por centro bastante mais precisos, com estes relatórios os gestores têm em seu
poder dados para efectuar uma melhor gestão das verbas para o investimento dos diversos
centros que a organização possuí e assim efectuar orçamentos e planeamentos futuros de
verbas, bem como apurar o valor investido em cada centro.
Esta funcionalidade pelos benefícios e pelo valor que acrescenta na gestão das
organizações poderia ser incluída na solução standard do sistema SAP à semelhança do
que acontece para outros campos como o da determinação automática das Contas do
Razão.
5.1.4 Fichiér des Écritures Comptables
Este trabalho foi um levantamento de requisitos para a evolução de um programa que o
cliente, Fujitsu, possui. O programa actual extrai dados sobre a facturação e contabilidade
da empresa portuguesa de forma a construir um ficheiro mensal em XML (eXtensible
Markup Language) chamado SAF-T PT (Standard Audit File for Tax Purposes -
Portuguese version). O ficheiro SAF-T PT não é mais do que um ficheiro normalizado
com o objectivo de auxiliar a Autoridade Tributária (AT) nas suas competências de
controlo da situação tributária. Este ficheiro permite a análise por parte da AT das
transacções de uma forma similar para todas as empresas, independentemente dos sistemas
utilizados, uma vez que a construção do mesmo ficheiro obedece a uma estrutura publicada
em Diário da República e actualmente encontra-se na versão 1.3 que corresponde à portaria
274/2013 (Républica 2013).
O cliente pretende que o programa contemple as obrigações legais em vigor em França
desde 1 de Janeiro de 2014 através do L'article L. 47 A I du livre des procédures fiscales,
59
(Artigo Lei 47 A I do Código Fiscal). Este artigo estabelece os métodos de entrega do
ficheiro e a sua estrutura e informação que este deve conter.
A SAP costuma disponibilizar correcções e updates ao sistema por forma a estes
corresponderem aos requisitos legais em vigor nos seus países. A SAP costuma demorar
bastante tempo a lançar as correcções e updates nestes casos, segundo a experiência da
AMS em relação ao SAF-T PT foi cerca de um ano, sendo as multas bastante pesadas
podendo chegar aos quinhentos mil euros por cada cem milhões de receita, o cliente fruto
da boa experiência relativa ao desenvolvimento do programa para a extracção do SAF-T
PT pediu uma proposta para o ugrade do programa anteriormente desenvolvido, de modo a
ser poder fazer uma estimativa do esforço necessário para este desenvolvimento primeiro
teve que ser realizado um levantamento dos dados necessários a extrair e proveniência da
informação das tabelas.
Este trabalho está relacionado com o módulo de Contabilidade Financeira.
5.1.4.1 Caracterização do cliente
O cliente é um fornecedor global de Tecnologias de Informação para o mercado global.
Com cerca de 170.000 pessoas a apoiar clientes em mais de 100 países, o cliente combina
especialistas em serviços e sistemas com produtos na área da computação,
telecomunicações e micro electrónica avançada de modo a proporcionar valor acrescentado
aos clientes. Com sede em Tóquio, apresentou receitas consolidadas de 4,4 biliões de ienes
(47 mil milhões de dólares) para o ano fiscal que terminou a 31 de Março de 2013.
60
5.1.4.2 Levantamento de requisitos
Primeiro foi necessário perceber quais os campos necessários a extrair da base de dados, o
artigo 47 fornece os campos necessários a reportar que podem ser observados na Tabela
11.
Tabela 11 - Campos Artigo 47
Nº Informação Nome do campo
1 The journal entry code JournalCode
2 The journal entry label JournalLib
3 The number of the accounting entry (follows a chronological and sequential
numbering) EcritureNum
4 The accounting entry date EcritureDate
5
The accounting number , which refers to the appropriate accounting
terminology – the first three characters three characters must meet the French
accounting standard
CompteNum
6 The account label, under the French Accounting Standard CompteLib
7 The sub ledger account number (field must be left empty if not used) CompAuxNum
8 The sub ledger account label (field must be left empty if not used) CompAuxLib
9 Reference of the relevant supporting document PieceRef
10 Date of the relevant supporting document PieceDate
11 Label of the accounting entry EcritureLib
12 The debit amount Debit
13 The credit amount Credit
14 The lettering/marking of the accounting entry (field must be left empty if not
used) EcritureLet
15 Lettering date (kept blank if not used) DateLet
16 Validation date for the journal entry Validdate
17 Amount in currency (blank if not used) Montantdevise
18 Code of the currency (leave blank if not used) Idevise
Depois de uma análise exaustiva verificou-se que os campos provêm maioritariamente de
duas tabelas, a tabela BKPF e a BSEG, tabelas já abordadas no ponto 5.1.2.
A correspondência entre os campos do artigo 47 e as tabelas SAP pode ser observada na
Tabela 12.
61
Tabela 12 - Correspondência campos artigo 47 e SAP
Nº Informação Nome do campo
Descrição SAP Nome SAP
1 The journal entry code JournalCode Document Type BLART
2 The journal entry label JournalLib Description LTEXT
3
The number of the accounting entry
(follows a chronological and sequential
numbering)
EcritureNum
Document Number BELNR
4 The accounting entry date EcritureDate Posting Date BUDAT
5
The accounting number , which refers to
the appropriate accounting terminology –
the first three characters three characters
must meet the French accounting standard
CompteNum
ACC Number GACC_NUM
6 The account label, under the French
Accounting Standard CompteLib
ACCT Shot Text TXT20
7 The sub ledger account number (field must
be left empty if not used) CompAuxNum
ACC Number ACC_NUM
8 The sub ledger account label (field must be
left empty if not used) CompAuxLib
Name NAME1
9 Reference of the relevant supporting
document PieceRef
Reference XBLNR
10 Date of the relevant supporting document PieceDate Document Date BLDAT
11 Label of the accounting entry EcritureLib Text SGTXT
12 The debit amount Debit Debit/Credit Ind. SHKZG
13 The credit amount Credit Debit/Credit Ind. SHKZG
14 The lettering/marking of the accounting
entry (field must be left empty if not used) EcritureLet
Clearing Document AUGBL
15 Lettering date (kept blank if not used) DateLet Clearing Date AUGDT
16 Validation date for the journal entry Validdate Entry Date CPUDT
17 Amount in currency (blank if not used) Montantdevise TC Amount WBTR
18 Code of the currency (leave blank if not
used) Idevise
Currency WAERS
Depois deste levantamento de requisitos, o manager tem em seu poder os dados
necessários para realizar uma proposta ao cliente com a estimativa e custo do projecto.
5.1.4.3 Conclusões
Até ao momento este trabalho consistiu no levantamento de requisitos para dar suporte a
uma proposta para o cliente, a realizar pelo manager.
A proposta para a realização deste trabalho está em análise por parte do cliente, ainda não
há dados que permitam fazer uma análise detalhada do benefício para o cliente.
62
A dificuldade deste trabalho relacionou-se com a falta de informação acerca deste assunto,
mesmo nos canais mais usuais da SAP e de fóruns oficiais utilizados por developers SAP.
A falta de informação no site da autoridade tributária de França, bem como a falta de
validadores de ficheiros XML para este caso foi também um entrave, pois a análise dos
ficheiros que validam o XML, normalmente ficheiros XSD (Xml Schema Definition), que
poderiam ajudar a realizar uma engenharia reversa.
Com estes requisitos a área da AMS está preparada para responder a solicitações de
clientes que também tenham operações em França e que precisem de entregar estes
relatórios.
Pode-se afirmar que este trabalho representa um investimento ao nível do conhecimento
deste tema e do qual se poderão colher frutos no futuro.
5.1.5 Certificação de Guias de Remessa
Devido aos requisitos legais em vigor em Portugal e segundo o art.º 8.º do Decreto-Lei n.º
198/2012, foi publicada a Portaria n.º 161/2013, de 23 de Abril, as guias de remessa têm
que ser processadas por programas certificados e apresentar na impressão da guia, o código
de controlo e uma mensagem com número do programa registado na AT e com a frase:
“Processado por programa certificado”.
O SAP é um programa certificado pela AT e está registado com o número 631, sendo um
programa certificado, deve aplicar as correcções disponibilizadas pela SAP para certificar
as guias de remessa e efectuar os desenvolvimentos necessários para mostrar a mensagem
obrigatória por lei na impressão das guias.
Este trabalho é desenvolvido no módulo de Vendas e distribuição.
5.1.5.1 Caracterização do cliente
O cliente é uma empresa internacional da área do retalho, foi fundada na década de 1940.
Está presente em 15 países a nível mundial com mais de 140 lojas e escritórios de vendas
nacionais.
63
5.1.5.2 Requisitos
Os requisitos neste trabalho são:
Certificação das guias de remessa que implica a instalação de updates;
Parametrizações de tabelas;
Desenvolvimento de código para adquirir o código de controlo da base de dados;
Alteração dos formulários existentes de forma a contemplarem a mensagem que
indica ao consumidor e às autoridades que o programa e respectiva guia são
certificados.
5.1.5.3 Implementação
Durante o período de tempo em que foi feita a proposta para este desenvolvimento, o
departamento técnico do cliente instalou no sistema SAP os últimos updates disponíveis
que já contemplavam a certificação. Ficámos responsáveis por desenvolver o restante
trabalho mencionado no ponto anterior.
Foi criado um intervalo de numeração utilizando a transacção SNRO, como se pode
observar na Figura 33, este intervalo irá ser utilizado como intervalo externo, será
armazenado na tabela correspondente à certificação chamada SIPT_LIKP, e não será
visível ao utilizador. Este passo é necessário pois assim é garantido que há uma sequência
de numérica. O processo de certificação utiliza o número anterior juntamente com um
algoritmo para gerar uma cadeia de caracteres chamada hash, desta hash de 64 bits e as 1ª,
11ª, 21ª, e 31ª posições serão impressas na guia. Se alguma linha desta tabela for eliminada
o programa deixa de gerar as hash e interrompe o processo de certificação, ocorrendo
assim o cliente em transgressão, pois por lei não se podem eliminar guias depois de
certificadas. Os documentos podem ser apenas estornados, o que significa serem anulados.
64
Figura 33 - Criação intervalo numérico SNRO
Depois deste intervalo ter sido criado foram inseridos na tabela SIPT_NUMBR_OBD_V os
tipos de documentos a assinar, presentes na Tabela 13.
Tabela 13 - Tipos documentos a assinar
Tipo Descrição Tipo Descrição
BV Cash Sale NLR Repl.delivery ret.
DIG Inb.Deliv.Gds Mvmnt RL Returns (pur.ord.)
DOG Outb.Deliv.Gds Mvmnt RLL Return Del.to Vendor
DTR Central Postng Chnge SRCL Requests + Returns
EG Rough GR SRNP New Parts Returns
EL Shipping Notificat SRTC SPE Outbound Deliv
HID Inbnd Dlv. HU Mvmnt SRTR Outbound Deliv.
HOD Outb.Deliv.GI Mvmnt SRUP Used Parts Returns
HTP Deliv.for Post.Chge UL Del.for stock trans
JF Outbound delivery IN VNL Replen.Deliv. Trsfr
LB Delivery for subcon WID WMS Inbound Delivery
LB2 DFPS: Reloc. Shpmnts WIG Other WMS Inb. Dely
LD Decentrl.Shipping WMPP WM-PP Delivery
LF Delivery WNL Replenishment WMS
LFKO Correction Delivery WOD WMS Outbound Dely
LO Delivery w/o Ref WOG Other WMS Outb. Dely
LP Delivery from proj WRD Cust. Returns WMS
LR Returns Delivery WTR Decentr. Pstng Chnge
NCR Ret.StTranspOrd CC ZC Delivery Cons. Issue
NK Replen.Del.Consignmt ZF Delivery (counter)
NKR Replen.Ret.Consignmt ZNL Repl.Dlv. w/o cons
NL Replenishment Dlv. ZNLC Repl.CC w/o cons
NLCC Replen.Cross-company
65
Na Figura 34 pode observar-se a tabela SIPT_NUMBR_OBD_V preenchida com os tipos
de documento a assinar digitalmente. Os campos mais relevantes são:
NO: contém o nome do número do intervalo de numeração criado, neste caso ZD;
Doc. Type: contém o tipo de documento assinar;
Description: contém a descrição do tipo de documento a assinar;
Signature: é uma checkbox que deve ser checked para garantir que o tipo de
documento é assinado;
Series: se a empresa emitir guias de outros sistemas, deverá ser indicada uma série
por sistema, neste caso a empresa só emite guias de um sistema por isso tem o
número um;
Company Code: código da companhia em sistema, caso o sistema tenha outras
empresas que necessitem de guias certificadas, devem indicar o código
correspondente, isto acontece porque o SAP é multiempresa, e por isso os
processos são transversais, podendo ser utilizados por todas as empresas;
Company Name: nome da empresa correspondente ao Company Code.
Figura 34 - Tabela com os tipos de documento a assinar
66
Depois desta parametrização efectuada foi necessário criar vários exemplos por forma a
certificar as guias e preencher a tabela SIPT_LIKP, na Figura 35 podemos encontrar um
exemplo parcial de uma entrada na tabela de certificação. Podemos observar os seguintes
campos:
Campo VBELN que corresponde ao número da guia de remessa a certificar;
Campo XBLNR que é preenchido automaticamente conforme o intervalo de
numeração criado anteriormente;
Campo BUKRS que corresponde ao código da empresa;
Campo NRRANGENR que corresponde ao intervalo de numeração criado
anteriormente com o nome ZD;
Campo LEAD_DOCTYPE com o valor ZF que foi parametrizado na tabela
SIPT_NUMBR_OBD_V juntamente com o campo SERIES e o campo
PRINT_CHAR que é o mecanismo de controlo que deverá constar na guia
acompanhado da mensagem de certificação.
Figura 35 - Tabela SIPT_LIKP
O cliente utiliza dois tipos de formulários distintos para a impressão das guias, sendo que o
processo de aquisição dos dados da tabela é semelhante. Irá ser apresentado o
desenvolvimento para a assinatura do tipo de documento ZF que representa as guias de
venda de produtos ao balcão. Na Figura 36 pode ser observada a declaração do perform de
aquisição de dados da tabela de certificação, perform é o nome técnico do ABAP
equivalente ao nome método da programação orientada, da tabela SIPT_LIKP. O perform é
criado num pool de módulos, que é um local onde são colocados outros performs para
serem chamados por programas externos, neste caso o perform get_sipt_likp_counter será
chamado pelo programa responsável pela impressão da guia.
67
Figura 36 - Perform de aquisição de dados da tabela de certificação
Depois do código concluído foi necessário incluir uma nova área no layout dos formulários
de forma a que estes contenham a mensagem de certificação e assim estarem em
conformidade com os requisitos legais. Na Figura 37 pode ser observada a nova área no
layout do formulário com o nome CERTID.
Figura 37 - Área da mensagem da certificação
Na nova área é necessário colocar o perform criado anteriormente, o perform
get_sipt_likp_counter. Na Figura 38 está apresentada a chamada do perform juntamente
com as variáveis de entrada, que serão utilizadas no perform para consultar a tabela, que
são:
Variável VBDKA-VBELN que corresponde ao número da guia a certificar;
Variável VBDKA-VKORG que corresponde à organização de vendas, que neste
caso será a 1200, que corresponde ao número da empresa em sistema. Estas
variáveis são precedidas pela instrução USING que indica que são utilizadas no
perform;
Variável LV_PRINT_CHAR que corresponde ao campo PRINT_CHAR da tabela
SIPT_LIKP;
Variável LV_CERT_ID que corresponde ao número do programa certificado que
também está guardado numa tabela com o nome SIPT_CERT, assim se o número
68
for alterado pela AT não será preciso alterar o formulário, uma vez que basta alterar
o número na tabela. Estas variáveis são precedidas da instrução CHANGING que
indica que o valor será alterado pelo perform.
Figura 38 - Chamada do perform get_sipt_likp_counter
Na Figura 39 podemos observar um exemplo de uma mensagem de certificação, esta figura
representa o documento assinado que está apresentado na Figura 35, podemos observar o
valor da variável LV_PRINT_CHAR que neste caso é PNcm, impresso na mensagem.
Figura 39 - Mensagem de certificação
No fim do desenvolvimento foi criado uma especificação técnica para entregar ao cliente
onde foi caracterizado o trabalho efectuado. Em caso de necessidade de manutenção futura
ou evolução deste desenvolvimento, o cliente conseguirá através da especificação inteirar-
se do trabalho efectuado e conseguirá perceber as alterações efectuadas. Esta especificação
está anexada a este trabalho no Anexo Seis.
69
5.1.5.4 Conclusões
Com este desenvolvimento as guias de remessa do cliente passaram a estar de acordo com
os requisitos legais.
Este processo foi demorado pois estiveram envolvidos vários intervenientes no processo,
os utilizadores em Portugal, os responsáveis pelo SAP da empresa que se encontram na
Holanda e a Deloitte. Durante este processo, assistiu-se ainda a uma mudança de
tecnologia do acesso remoto aos sistemas do cliente. Esta alteração fez com que o processo
de credenciais de acesso tivesse que ser revisto.
Verificou-se que a equipa de TI do cliente não sabia quais os tipos de documentos a assinar
que seriam necessários parametrizar na tabela, e também desconheciam os formulários
alterar. Teve que ser feita uma análise com o lançamento de vários tipos de guias até serem
encontrados os tipos de documentos e de formulários a alterar. Concluiu-se que o esforço
inicial planeado era inferior ao necessário, mas este constrangimento não se reflectiu no
valor pago pelo cliente.
Concluiu-se que é importante analisar com pormenor o conhecimento do cliente em
relação aos seus sistemas por forma a elaborar propostas com esforço real.
O processo de emissão de guias de remessa tem um formulário standard, no último update
do sistema a SAP não colocou esta mensagem nos formulários. Apesar do cliente utilizar
formulários customizados, a utilização do código standard da SAP constituiria uma
vantagem para o desempenho dos sistemas, em vez de ser gerado mais um ficheiro com
código desenvolvido à medida. O código apesar de ser relativamente pequeno é guardado
em tabelas das bases de dados do SAP, o que implica o crescimento do tamanho das bases
de dados e a longo prazo pode comprometer o desempenho do sistema.
5.1.6 Formulário de aprovação de Requisições de Compra
A equipa de SAP da AMS implementou um processo de aprovação de requisições de
compra. Até à data, o processo era manual, o funcionário preenchia uma requisição de
compra em papel com a informação dos produtos que pretendia comprar. No fim de
preenchida essa folha transitava de aprovador em aprovador até a requisição ser aprovada
70
ou rejeitada, se a requisição fosse aprovada, era então passada para o sistema SAP para ser
criada uma ordem de compra.
Este trabalho foi desenvolvido no módulo de Gestão de Materiais.
5.1.6.1 Caracterização do cliente
O cliente é uma empresa que possui várias cadeias de lojas relacionadas com relojoaria,
possuindo mais de quinze lojas em Portugal continental, Madeira e Açores.
5.1.6.2 Requisitos
A equipa da AMS implementou o processo de aprovação de requisições de compra
recorrendo a uma ferramenta SAP que permite a criação de workflows. Este workflow
funciona da seguinte forma: é criada uma requisição de compra e consoante a área de
compras (economato, imobilizado, serviços, etc), tem associada uma estratégia de
liberação. Esta estratégia contém os aprovadores para cada área de compra.
Depois da requisição de compra criada, é despoletado um evento que envia a requisição de
compra para o primeiro aprovador da estratégia, cabe a este aprovar ou rejeitar, se rejeitar a
requisição de compra é arquivada e o próximo aprovador nem chega a ter conhecimento.
Este processo repete-se até se esgotarem os aprovadores no caso de ser aprovada por todos,
ou até algum aprovador rejeitar.
À medida que o pedido vai sendo aprovado ou rejeitado essa informação é armazenada
numa tabela de logs criada para o efeito.
O requisito deste desenvolvimento é criar de raiz um formulário que, no fim do processo
estar completo, possa ser impresso e apresentado à direcção geral e à administração sendo
estes os aprovadores finais.
5.1.6.3 Implementação
Foi criado um programa para a impressão das requisições de compra, a tela apresentada na
Figura 40 corresponde à tela do programa de impressão. Para imprimir uma requisição
71
basta indicar um número, ou um intervalo no caso de ser necessário imprimir várias, na
mesma operação.
As requisições são armazenadas na tabela EBAN, na Figura 41 podemos observar uma
requisição, onde podemos ver o número de requisição, o número do item, a descrição do
material, o número do material, o criador da requisição, a data, a quantidade, a unidade de
medida e o preço unitário.
Figura 40 - Programa de impressão de requisições de compra
Figura 41 - Tabela requisições de compra – EBAN
O programa de impressão com o número da requisição constrói as seguintes tabelas:
Tabela com os campos apresentados na Figura 41;
Tabela com os dados do fornecedor a quem poderá ser comprado o material;
Tabela com dados adicionais;
Tabela com os aprovadores e as datas de aprovação. Na Figura 42, são
apresentados os campos necessários para a construção da tabela dos aprovadores.
Figura 42 - Tabela ZMM_REQC_APP_LOG
72
Depois de construído o código, o passo seguinte passou pelo desenho do layout do
formulário, que foi desenvolvido em smartforms. Na Figura 43 podemos observar o
desenho do layout. Alguns pontos importantes: na janela HEADER_LOGO será
apresentado o logotipo da empresa; Na janela ENDERECO serão colocados os dados
relativos ao fornecedor; Na janela MAIN serão apresentados os itens que constam no
pedido de compra; Na janela APROVADORES serão apresentados os nomes dos
aprovadores e as datas da aprovação.
Figura 43 - Layout formulário de requisição de compra em smartforms
Depois de concluído o desenvolvimento, o programa de impressão chamará o smartform e
apresentará ao utilizador um formulário semelhante ao apresentado na Figura 44.
73
Figura 44 - Formulário de requisição de compra
74
5.1.6.4 Conclusões
O desenvolvimento deste formulário permitiu o fecho da implementação do processo, uma
vez que o workflow implementado já estava testado e aprovado pelo cliente.
Este processo acrescenta uma mais-valia uma vez que, ao contrário do processo antigo em
papel, não fica retido ou esquecido por entre outros processos ou papéis. A eliminação do
papel até à aprovação final foi benéfica pois permite a poupança de tempo no
preenchimento manual dos impressos e no fluxo entre departamentos e na respectiva
transcrição para o sistema. Como o sistema SAP do cliente está acessível aos funcionários
fora da empresa, caso haja alguma aprovação urgente, o aprovador responsável pode
aprovar a requisição em instantes, evitando atrasos.
O processo de requisição de pedidos de compra não tem formulário standard em SAP,
seria uma mais-valia para o SAP disponibilizar este formulário como já faz para outros
processos relacionados com o processo de compras, como por exemplo, o pedido de
cotação a fornecedores.
5.1.7 Implementação do programa RPFIEU_SAFT - SAF-T PT
Este projecto consistiu na implementação do update que a SAP disponibilizou aos seus
clientes para que seja possível extraírem dos seus sistemas a informação contabilística e
financeira a reportar à AT. O programa que consta neste update chama-se RPFIEU_SAFT
e é através dele, que no fim de cada mês, o cliente extrairá um ficheiro contendo a
informação necessária a reportar. Até aqui eram necessários vários programas e algumas
operações até o ficheiro estar no formato aceite pela AT, este novo update vem por cobro a
esse trabalho e centralizar as operações num único local.
O ficheiro a reportar às instâncias competentes chama-se SAF-T PT e já foi abordado no
ponto 5.1.4 deste trabalho.
Este trabalho é transversal aos módulos Contabilidade Financeira e de Vendas e
distribuição.
75
5.1.7.1 Caracterização do cliente
O cliente é uma empresa líder mundial em produtos farmacêuticos. As suas raízes
remontam aos inícios do século XIX. Tem actividades em mais de 60 países em todo o
mundo incluindo 12 países europeus e conta com mais de 32 mil colaboradores.
5.1.7.2 Requisitos
Os requisitos mínimos que a SAP indicava para que o sistema do cliente pudesse ser
actualizado estavam de acordo com os requisitos do sistema deste cliente, como tal foi só
necessário instalar todos as notas necessárias disponibilizadas pela SAP.
O termo nota em SAP refere-se às correcções ou evolução dos sistemas estão disponíveis
para serem consultadas no site da SAP. As correcções podem ser feitas de forma manual,
seguindo instruções de um manual, ou automáticas, ou seja, são descarregadas para o
sistema através de um programa chamado Snote e implementadas de forma automática.
5.1.7.3 Implementação
Depois de uma consulta no site da SAP, foram encontradas as notas apresentadas na
Tabela 14 - Notas SAF-T PT. Estas notas correspondem ao trabalho que tem que ser
efectuado para o cliente ter disponível no seu sistema o programa que lhe permita extrair o
ficheiro SAF-T PT.
Na coluna procedimento estão presentes os procedimentos Manual, que indicam que serão
efectuados os passos manualmente, snote que indicam que serão efectuadas instalações
automáticas e Documentação que fornece instruções em caso de necessidade de alterar o
programa standard.
76
Tabela 14 - Notas SAF-T PT
Notas SAP Descrição Procedimento
1862600 RPFIEU_SAFT Solution :DDIC Note Manual
1860026 RPFIEU_SAFT Solution : Report Note Snote
1929066 SAFT-PT: Reversal Documents to be excluded from SAFT file Manual
1937556 RPFIEU_SAFT : SAF-T Framework Corrections (1_F) Manual
1972297 Documentation for report RPFIEU_SAFT for Portugal Documentação
1973052 RPFIEU_SAFT : SAF-T Framework Corrections (2_F) Manual
1987687 Documentation for BAdi methods for report RPFIEU_SAFT Documentação
1988029 RPFIEU_SAFT : SAF-T Framework Corrections (3_F) Snote
1933567 SAF-T(PT):Customer Master Enhancement Manual
1988434 RPFIEU_SAFT: 274/2013 changes in SAF-T file for Portugal Manual
1988662 RPFIEU_SAFT : SAF-T Framework Corrections (4_F) Snote
1993020 RPFIEU_SAFT : SAF-T Framework Corrections (5_F) Snote
1996135 RPFIEU_SAFT : SAF-T Framework Corrections (6_F) Manual
1997528 SAFT: G/L accounts are missing in file for Portugal (1_P) Snote
2005829 RPFIEU_SAFT : SAF-T Framework Corrections (7_F) Snote
2008508 SAFT: Missing Manual Change Manual
2010250 SAF-T:Section 4.3 -Working Documents Section for Portugal (2_P) Manual
2010809 RPFIEU_SAFT : SAF-T Framework Corrections (8_F) Manual
2017548 RPFIEU_SAFT : SAF-T Framework Corrections (9_F) Snote
Há medida que se vão efectuando os trabalhos deste projecto vai sendo necessário registar
objectos, este registo é feito no site da SAP com a conta do cliente, este registo permite a
criação ou alteração de novos objectos no sistema. Este registo é obrigatório, se não é
impossível instalar as notas no sistema, só clientes com a sua conta regularizada podem
usufruir deste serviço. Esta é a forma que a SAP tem de permitir a alteração ao sistema
standard sem ser em locais previamente disponibilizados para o efeito como as BADIs.
Na Figura 45 podemos observar um exemplo de um objecto ao qual o sistema pediu ao
utilizador para registar. No site é necessário indicar o número da instalação, o objecto a
registar e a versão da instalação, só com estes dados o site permite o registo e fornece uma
chave para ser inserida no campo Access key.
77
Figura 45 - Exemplo de objecto a registar
Depois da implementação e parametrização do programa foi realizado um manual para
ajudar o cliente na operação do programa. O manual encontra-se no Anexo Oito deste
trabalho.
5.1.7.4 Conclusões
Com a conclusão deste projecto o cliente tem agora uma forma mais simples, rápida e
eficaz na tarefa de extracção do ficheiro, que apesar de ser uma vez por mês, da antiga
forma era necessário correr quatro programas de extracção dos dados, e um programa para
juntar esses dados e converter em XML, com esta melhoria implementada o processo
centralizado num único local.
O serviço de updates que a SAP oferece aos seus clientes é uma grande mais-valia, pois
com o constante evoluir das leis e dos consequentes requisitos legais os sistemas precisam
de ser actualizados para estarem em conformidade com a lei. Este serviço é um repositório
de informação que deve ser utilizado para pesquisa por parte dos técnicos de SAP e dos
administradores de sistemas SAP para resolver os problemas que vão ocorrendo nos
sistemas dos clientes. Caso não se encontre solução no repositório a SAP permite aos
utilizadores criar um incidente ao qual poderão surgir novas notas para implementar no
sistema, ou apenas instruções de configuração se os técnicos da própria SAP entrarem no
sistema e encontrarem erros de configuração.
78
5.1.8 Apoio funcional à certificação de facturas, guias de remessa e SAF-T
PT
A área da AMS tem um grande conhecimento sobre certificação de facturas e guias de
transporte, um cliente estrangeiro a operar em Portugal contratou os serviços da área para
apoiarem o seu departamento técnico na implementação destas certificações. Estas
certificações são imperativos legais e as empresas que não os cumpram podem ser sujeitas
a coimas por parte da AT. A certificação das guias de remessa já foram abordadas neste
trabalho, a certificação das facturas foi pela primeira ver regulamentada pela Portaria n.º
363/2010, de 23 de Junho, estando em vigor actualmente a Portaria 340/2013 de 22 de
Novembro de 2013 que obriga a utilização de programas de facturação certificados pelos
sujeitos passivos que:
Utilizem um software produzido internamente ou por empresa no mesmo grupo
económico, do qual sejam detentores dos respectivos direitos de autor;
Tenham no período de tributação anterior, um volume de negócios superior a
100.000€ (cem mil euros);
Optem a partir de 1 de Janeiro de 2014, pela utilização de um programa informático
de facturação;
Utilizem um programa de facturação multiempresa;
Usem programas de facturação que emitam apenas guias de transporte ou de
remessa, que sirvam de documento de transporte, de acordo com o disposto no
regime de bens em circulação, aprovado pelo Decreto-Lei n.º 147/2003, de 11 de
Julho (República 2013).
Este trabalho é transversal aos módulos Contabilidade Financeira e de Vendas e
distribuição.
5.1.8.1 Caracterização do cliente
O cliente é um grupo de 229 empresas e possui mais de 70 mil colaboradores.
As operações globais do cliente incluem uma grande diversidade de produtos: materiais
avançados, componentes, dispositivos, equipamento, engenharia de redes e outros serviços.
Uma tão vasta experiência permite ao cliente integrar uma gama completa de processos
numa determinada linha de produtos – desde o desenvolvimento e produção às vendas e
79
logística. Esta utilização eficaz de recursos gera sinergias ao nível do grupo, que
contribuem para produtos de desempenho, funcionalidade e valor superiores.
5.1.8.2 Trabalho desenvolvido
Como o cliente possui uma equipa de desenvolvimento mundial sediada na Alemanha que
foi responsável pelo desenvolvimento e implementação em sistemas SAP, o trabalho
passou por dar apoio funcional, ou seja, indicar os updates e as notas SAP necessárias para
a certificação, bem como a criação de manuais de utilização do programa que neste caso é
o RPFIEU_SAFT - SAF-T PT, já abordado no ponto 5.1.7 Implementação do programa
RPFIEU_SAFT - SAF-T PT, criação de um manual de treino para os colaboradores que
lidam com o processo de facturação e expedição, e também a criação dos casos de teste.
Esta documentação pode ser encontrada no Anexo Nove deste trabalho.
5.1.8.3 Conclusões
O apoio funcional a equipas estrangeiras de desenvolvimento em relação a aspectos legais
próprios do país, neste caso Portugal, é uma mais-valia pois, é difícil às empresas
estrangeiras terem nos seus quadros pessoal técnico qualificado que consiga perceber a
legislação dos outros países, um pouco à semelhança de outros trabalhos relatados durante
este trabalho as empresas têm técnicos SAP, mas é praticamente impossível que estes
consigam perceber todos os requisitos legais dos países onde as empresas operam. Neste
caso o apoio foi unicamente funcional, ao contrário dos outros desenvolvimentos ligados à
certificação, onde as empresas têm técnicos SAP, mas delegaram a implementação à AMS.
5.2 Projectos Tecnologias Microsoft
Neste subcapítulo encontra-se relatado o projecto de consultoria em tecnologias Microsoft.
Este foi um projecto de consultoria interna, a Deloitte foi requisitada pelos seus clientes
para a elaboração dos relatórios Common Reporting (COREP) e Financial Reporting
(FINREP) para comunicação de informação financeira ao Banco de Portugal (BdP). Foi
necessário desenvolver de raiz um conversor de ficheiros excel para eXtended Business
Reporting Language (XBRL).
80
5.2.1 Conversor eXtended Business Reporting Language – XBRL
Em resposta à crise financeira que ainda está bem presente na nossa memória e para
promover o bom funcionamento do mercado interno, o Parlamento Europeu e o Conselho
da União Europeia aprovaram um conjunto único de requisitos prudenciais aplicáveis às
instituições de crédito e às empresas de investimento a partir de 1 de Janeiro de 2014 –
Regulamento (UE) n.º 575/2013, de 26 de Junho de 2013, comumente designado
“Regulamento de Requisitos de Capital” (CRR, na sigla inglesa).
A existência de um regulamento único para todos os participantes no mercado evita
distorções de mercado e arbitragens regulatórias. Este destina-se a implementar definições
e requisitos de reporte uniformes, que serão transpostos através das linhas orientadoras de
Common Reporting (COREP) e de Financial Reporting (FINREP) (Portugal, Banco de
Portugal 2013).
Estes relatórios terão que ser entregues, numa primeira fase apenas por bancos a operar em
Portugal ao Banco de Portugal (BdP), mais tarde serão estendidos a seguradoras e a
empresas cotadas em bolsa.
Os relatórios serão comunicados por meio de ficheiros XBRL, que são ficheiros XML
construídos com a linguagem XBRL, e submetidos na área do cliente no site do BdP.
Estes ficheiros XBRL terão que seguir normas da Autoridade Bancária Europeia (EBA), a
uniformização dos requisitos de comunicação garante condições de concorrência mais
equitativas entre grupos comparáveis de instituições de crédito e empresas de investimento,
aumentando, assim, a eficiência das instituições.
Ao garantirem uma maior convergência entre as práticas de supervisão dos Estados-
Membros, estes requisitos permitem também avaliar de forma consistente os riscos para a
estabilidade financeira em toda a União Europeia, tornando mais eficaz a comparação entre
bancos e facilitando a identificação de riscos sistémicos emergentes.
Este novo requisito fez com que os bancos, clientes da Deloitte, passem a comunicar os
dados dos relatórios COREP e FINREP, sendo o XBRL uma linguagem praticamente
desconhecida em Portugal e as ferramentas de conversão inexistentes, nasceu a
necessidade da Deloitte criar a sua própria ferramenta de conversão para satisfazer as
necessidades dos seus clientes.
81
Os relatórios são entregues conforme periodicidade estipulada. Podem ser consultados na
Tabela 15 os dados para os relatórios do tipo COREP e na Tabela 16 os dados para os
relatórios do tipo FINREP.
Numa primeira fase apenas os bancos estão obrigados a elaborarem estes relatórios,
estando previsto, numa segunda fase as seguradoras, e numa terceira fase as empresas
cotadas em bolsa. Com estes relatórios pretende-se uniformizar a comunicação dos dados
às instâncias responsáveis, aumentar a transparência, e possibilitar uma fiscalização mais
efectiva das actividades das entidades pelos respectivos reguladores.
Tabela 15 - Tipo de relatório COREP
Código Descrição
COREP_Con Common Reporting - Own Funds and Leverage, Consolidated (Prudential scope)
IFRS or National GAAP
COREP_Ind Common Reporting - Own Funds and Leverage, Individual IFRS or National
GAAP
COREP_LCR_Con Liquidity Coverage - COREP, Consolidated (Prudential scope) IFRS or National
GAAP
COREP_LCR_Ind Liquidity Coverage - COREP, Individual IFRS or National GAAP
COREP_LE_Con Large Exposures - COREP, Consolidated (Prudential scope) IFRS or National
GAAP
COREP_LE_Ind Large Exposures - COREP, Individual IFRS or National GAAP
COREP_NSFR_Con Stable Funding - COREP, Consolidated (Prudential scope) IFRS or National
GAAP
COREP_NSFR_Ind Stable Funding - COREP, Individual IFRS or National GAAP
Tabela 16 - Tipo de relatório FINREP
Código Descrição
FINREP_Con_GAAP Financial Reporting, Consolidated (Prudential scope) National GAAP
FINREP_Con_IFRS Financial Reporting, Consolidated (Prudential scope) IFRS
5.2.1.1 O que é o XBRL
O XBRL é um acrónimo de eXtensible Business Reporting Language, é uma linguagem
criada para definir informação financeira. Esta linguagem é um standard e é baseada em
XML. O XBRL é mantido por um consórcio internacional e sem fins lucrativos, o XBRL
International Incorporated, é composto por mais de seiscentas organizações, entre elas
entidades reguladoras, agências governamentais e empresas de software. Os membros do
consórcio reúnem-se regularmente por forma a manter o standard actualizado.
82
Este esforço colaborativo começou em 1998 e produziu uma variedade de especificações e
taxionomias de forma a fornecer um standard para o reporte de informação de acordo com
as regras em vigor em cada país (XBRL 2014).
O XBRL, standard aberto e livre derivado do XML, foi definido na sua génese para dar
resposta às necessidades de informação financeira e de negócio e assume-se como o
standard para a troca electrónica de dados nestes domínios. Permite a identificação
unívoca de conceitos financeiros, a relação entre eles e a sua agregação em agrupamentos
lógicos ou para efeitos de apresentação. Toda esta representação é formalizada numa
taxonomia (Portugal, Banco de Portugal 2013).
A EBA assumiu a responsabilidade no desenvolvimento e manutenção das taxonomias
para o COREP e FINREP estando o Banco de Portugal incumbido do processo de recolha
dos dados (instâncias) por parte das instituições em solo nacional assim como de assegurar
a qualidade da informação reportada.
Alguns benefícios do XBRL:
Reduz o encargo de realizar relatórios;
Reduz os custos;
Aumenta a qualidade dos dados;
Aumenta a transparência;
Uniformidade na comunicação de informação;
Maior facilidade de interpretação dos dados e fiscalização.
5.2.1.2 Taxonomia
Uma taxonomia XBRL é composta por schemas e linkbases, ambos ficheiros XML:
Os schemas servem para definir os componentes Item e Tuple através de elementos
<xsd:element>, que indicam se diz respeito a um valor único ou lista de valores,
tipo de dados, e outros meta-dados que lhe possam estar associados. Os Items e os
Tuples são implementações dos conceitos. Adicionalmente, os schemas fazem
referências a documentos linkbase usados na taxonomia;
Os linkbases são colecções de referências (links) que por sua vez contêm locators,
arcs e resources. Os locators são elementos que referenciam conceitos e atribuem-
83
lhes etiquetas (labels) aleatórias. Os arcs são elementos que relacionam dois
conceitos entre si através das etiquetas geradas pelos locators. Os arcs podem
também associar conceitos a resources sendo o exemplo mais comum a criação de
etiquetas legíveis.
Segundo a especificação XBRL 2.1 existem os seguintes tipos de linkbases:
Label linkbase permite a criação de descrições para os conceitos mais amigáveis
para o utilizador de negócio. Um exemplo da sua utilização é a criação de
descrições em vários idiomas;
Reference linkbase associa aos conceitos referências a artigos ou legislação de
suporte, permitindo uma melhor compreensão do significado de cada elemento;
Calculation linkbase permite a associação de vários conceitos para que possam ser
definidos testes de consistência entre eles. Por exemplo, verificar se Revenue =
GrossProfit – CostOfSales;
Definition linkbase estabelece relações entre conceitos usando diferentes tipos de
arc roles para representar relações do tipo is-a ou whole-part;
Presentation linkbase permite a associação de conceitos da taxonomia de tal forma
que o resultado possa servir de base a uma interface de visualização ou geração de
um quadro. Os elementos de uma taxonomia podem ser organizados
hierarquicamente de modo a facilitar a leitura dos dados de negócio, como por
exemplo, a organização de rúbricas num balanço.
5.2.1.3 Instância
Uma instância XBRL contém a seguinte informação:
Factos reportados, que podem ser de dois tipos:
o Items são factos que contêm apenas um valor contido no elemento XML
que o representa;
o Tuples são factos que contêm vários valores, representados por items ou
tuples no elemento XML que o representa.
Associação entre factos e respectivo contexto constituído pelos seguintes itens:
o A entidade a que se referem os dados;
o A que períodos estão associados;
84
o Opcionalmente, o cenário (scenario) poderá fornecer um contexto
semântico adicional para caracterização dos factos reportados.
As unidades em que são reportados os factos, sejam numéricos ou fracções, como
por exemplo, o número de acções de uma participação ou euros;
As footnotes permitem associar mais conteúdo aos factos reportados;
As references associam a instância a taxonomias XBRL através de referências de
schema ou a linkbases (Portugal, Implementação COREP e FINREP 2014).
5.2.1.3.1 Exemplo de Instância XBRL
As tabelas seguintes apresentam os dados de uma instância de exemplo contendo os
templates C00.01 e C05.02:
Template C00.01:
Nature of Report
Accounting framework National GAAP
Reporting Level Consolidated
Template C05.02 (Grandfathered instruments: Instruments not constituting State aid):
Amount of instruments plus related
share premium
Base for calculating
the limit Applicable percentage Limit
(-) Amount that exceeds the
limits for grandfathering
Total grandfathered
amount
1. Instruments that
qualified for point a) of
Article 57 of 2006/48/EC 100000000.00 60000000.00 0.80 48000000000.00 -52000000.00 48000000.00
2. Instruments that
qualified for point ca) of
Article 57 and Article
154(8) and (9) of
2006/48/EC, subject to the
limit of Article 467
57050000.00 450000.00 0.80 360000.00 -56690000.00 360000.00
2.1 Total instruments
without a call or an
incentive to redeem 1000000.00 ------------- ------------ --------------- --------------- --------------
2.2 Grandfathered instruments with a call
and incentive to
redeem
4050000.00 ------------- ------------ --------------- --------------- --------------
2.2.1 Instruments
with a call exercisable after
the reporting date,
2000000.00 ------------- ------------ --------------- --------------- --------------
85
Amount of instruments plus related
share premium
Base for calculating
the limit Applicable percentage Limit
(-) Amount that exceeds the
limits for grandfathering
Total grandfathered
amount
and which meet the conditions in
Article 49 of CRR
after the date of effective maturity
2.2.2 Instruments with a call
exercisable after
the reporting date, and which do not
meet the
conditions in Article 49 of CRR
after the date of
effective maturity
1500000.00 ------------- ------------ --------------- --------------- --------------
2.2.3Instruments
with a call exercisable prior
to or on 20 July
2011, and which do not meet the
conditions in
Article 49 of CRR after the date of
effective maturity
551000.00 ------------- ------------ --------------- --------------- --------------
2.3 Excess on the limit
of CET1 grandfathered
instruments 52000000.00 ------------- ------------ --------------- --------------- --------------
3. Items that qualified for
points f), g) or h) of
Article 57 of 2006/48/EC,
subject to the limit of
Article 468
64775456.56 11403821.81 0.80 9123057.45 -55652399.11 9123057.45
3.1 Total items without
an incentive to redeem 3500000.00 ------------- ------------ --------------- --------------- --------------
3.2 Grandfathered
items with an incentive to redeem
4585456.56 ------------- ------------ --------------- --------------- --------------
3.2.1 Items with a call exercisable
after the reporting
date, and which meet the
conditions in
Article 60 of CRR after the date of
effective maturity
2100000.00 ------------- ------------ --------------- --------------- --------------
3.2.2 Items with a
call exercisable after the reporting
date, and which
do not meet the conditions in
Article 60 of CRR
after the date of
1250000.00 ------------- ------------ --------------- --------------- --------------
86
Amount of instruments plus related
share premium
Base for calculating
the limit Applicable percentage Limit
(-) Amount that exceeds the
limits for grandfathering
Total grandfathered
amount
effective maturity
3.2.3 Items with a
call exercisable prior to or on 20
July 2011, and
which do not meet the conditions in
Article 60 of CRR
after the date of effective maturity
1235456.56 ------------- ------------ --------------- --------------- --------------
3.3 Excess on the limit of AT1 grandfathered
instruments 56690000.00 ------------- ------------ --------------- --------------- --------------
Devido ao facto do código que representa a instância em formato XBRL tem alguma
dimensão o mesmo pode ser consultado no Anexo Dez.
5.2.1.4 Tecnologia
Este projecto foi realizado em C# e com recurso ao programa de desenvolvimento de
software Visual Studio 2012, uma vez que será incorporado num programa que a AMS
possui e que comercializa aos seus clientes. O programa actual serve para os clientes
comunicarem guias de transporte à AT através da comunicação via webservice ou para
criar o SAF-P PT em casos de empresas que por lei não tenham que ter o seu programa
certificado.
O programa é modular, sendo que o cliente só tem acesso ao módulo que comprar, no
limite terá os três módulos.
5.2.1.5 Desenho da solução
A EBA fornece templates excel que devem ser preenchidos e depois convertidos em XBRL
conforme a taxionomia que consta numa base de dados em access. Os templates excel e a
taxionomia ainda não estão completamente definidos, com isso em mente a solução foi
pensada para ser o mais flexível possível.
Um dos templates excel contém os data points, cada um destes data points tem
correspondência no template access com a base de dados. Na Figura 46 podemos observar
um exemplo de um data point, existem cerca de 39 mil data points no template excel
87
distribuídos por mais de 320 folhas do excel. O relatório com mais data points é o
COREP_Con com 24313 data points adquiridos de 218 folhas.
Figura 46 - Exemplo de data point
Depois da análise à documentação existente e ao estudo da base de dados chegou-se à
conclusão que o valor do data point do template excel está localizado na tabela
DataPointVersion no campo DataPointID. Com esse valor podemos adquirir o valor do
campo MemberID e desse modo pesquisar com esse campo chave na tabela Member o
valor da tag MemberXBRLCode necessária para a construção do campo do XBRL para o
data point. Com o ContextID podemos adquirir os valores do contexto na tabela
ContextDefinition, com o valor do ContextID chegamos aos valores do MemberID para a
tags XBRL da definição do contexto para o data point, com o MemberID voltamos à tabela
Member para adquirir o valor das tags XBRL. Na Figura 47 podemos observar um
diagrama que poderá ajudar a entender melhor os passos anteriormente descritos.
88
Figura 47 - Fluxo data point
Figura 48 - Exemplo Contexto em XBRL
Como os data points podem sofrer alterações e com essas alterações seria necessário
alterar o código do programa, a solução idealizada foi: o cliente preenche um template
excel igual ao template com os data points; o programa percorre o excel com os dados do
cliente, encontra as células preenchidas e depois percorre o template excel com os data
points com o objectivo de encontrar o data point correspondente para cada célula do excel
para posterior pesquisa à base de dados.
Como a posição dos data points muda conforme o relatório, a forma desenhada para
seleccionar os data points foi criar um excel com o nome das folhas e os intervalos onde os
mesmos se encontram, assim, caso seja necessário alterar um intervalo, adicionar uma
89
nova folha ou retirar uma nova folha, basta configurar o excel e o programa fica ajustado
para a nova revisão da taxionomia. Na Figura 49 podemos observar o excel de
configuração de intervalos, onde são preenchidas as seguintes colunas:
Coluna Sheet Name com o nome da folha do template excel dos data points;
Coluna Start Range (Columm) com o número da coluna onde começa o
preenchimento dos data points;
Coluna End Range (Columm) com a coluna onde acaba o preenchimento dos data
points;
Coluna Row com o número da linha onde começa o preenchimento dos data
points;
Coluna Generate que quando preenchida com X utiliza a folha dessa linha para
construir o ficheiro XBRL.
Figura 49 - Excel de configuração de intervalos
Foi definido que a interface do módulo teria as seguintes funcionalidades:
Permitir escolher um ou vários tipos de relatórios a entregar;
Ler um ficheiro excel com os dados a comunicar;
Permitir escolher uma pasta de destino dos relatórios;
Permitir inserir uma data.
Foi elaborada uma arquitectura conceptual de alto nível do funcionamento do programa,
com os dados de entrada e os dados de output do programa, a arquitectura pode ser
observada na Figura 50. O programa aceitará como input os ficheiros com os dados a
reportar, o ficheiro com os data points correspondentes, o ficheiro com a configuração dos
90
intervalos e a base de dados com a taxionomia e como output o programa deverá produzir
um, ou mais ficheiros XBRL conforme a quantidade de relatórios seleccionados.
Figura 50 - Arquitectura de alto nível do funcionamento do programa
5.2.1.6 Implementação
Na implementação deste projecto não foi utilizada uma metodologia clássica de
desenvolvimento de software, partiu-se do desenho de alto nível da arquitectura e foi-se
desenvolvendo o código à medida das necessidades. Não existia uma data de entrega
definida, o BdP permite o envio de ficheiros em excel durante um ano, só depois será
obrigatório enviar os ficheiros em XBRL.
Durante a implementação foram colocadas várias questões ao BdP para tentar esclarecer
alguns pormenores, algumas perguntas foram respondidas e outras continuam sem
resposta. As perguntas e respostas podem ser lidas no Anexo deste trabalho.
Foi implementado uma nova tablatura no programa existente. Na Figura 51 estão
apresentadas as tablaturas do programa Authority Connect, ao qual foi acoplado o módulo
de XBRL. Na Figura 52 podemos ver a interface do programa apenas para o módulo
XBRL, nas duas imagens é possível observar os tipos de relatórios que o módulo consegue
gerar, basta entrar um template excel com os dados a converter e seleccionar o tipo de
relatório e pressionar o botão Convert.
91
Figura 51 - Todos os módulos do programa Authority Connect
Figura 52 - Módulo XBRL do programa Authority Connect
Foram criadas novas pastas para conter os dados de entrada, foi criada a pasta Database
para albergar a base de dados com a taxionomia, a pasta DataPoints para conter o ficheiro
template excel com os data points e a pasta Ranges para conter o excel de configuração dos
92
intervalos e das folhas de cada relatório. Esta estrutura de pastas pode ser observada na
Figura 53.
Figura 53 - Estrutura de pastas da solução
Como o programa irá ler os dados de ficheiros excel, foi criada uma classe para aceder aos
dados de ficheiros excel. Os primeiros métodos criados foram:
Método excel_init, que irá abrir o ficheiro conforme o caminho que é passado para
o método por argumento;
Método excel_close que termina a ligação com o excel, este método é invocado
sempre que a interacção entre o programa e os ficheiros excel termina de forma a
que não fiquem ligações abertas que possam interferir com ligações futuras e a
ocupar memória em sistema.
Os métodos podem ser observados na Figura 54 e Figura 55 respectivamente.
93
Figura 54 - Método excel_init
Figura 55 - Método excel_close
A linguagem C# e Framework .Net já possuem métodos nativos que permitem a
manipulação destes ficheiros, devido a esse factor foi incluída uma biblioteca que permite
essa interacção chamada Microsoft.Office.Interop.Excel, como se pode observar na Figura
56.
94
Figura 56 - Inclusão da biblioteca Microsoft.Office.Interop.Excel
Foi criada uma classe para adquirir os dados relativos ao ficheiro de configuração de
intervalos, guarda o nome da folha, a coluna de início do preenchimento com data points, a
coluna do fim do preenchimento dos data points, a linha onde começa o preenchimento
dos data points, o valor da flag usada para processar ou não folha do excel, uma lista de
contextos e uma lista com os valores das células do excel com dados do cliente.
Figura 57 - Classe RangesExcel
95
Foram criadas as seguintes classes:
Classe Contexto para albergar os dados relativos aos contextos;
Classe Context para guardar os dados necessários para a construção do contexto,
uma vez que podem ser várias linhas a definir um contexto;
Classe CelulaEXCL para guardar os dados relativos à célula.
As declarações das classes podem ser observadas nas Figura 58, Figura 59 e Figura 60
respectivamente.
Figura 58 - Declaração classe Contexto
Figura 59 - Declaração classe Context
96
Figura 60 - Declaração classe CelulaEXCL
Foi implementado um método para carregar os dados do excel de configuração de
intervalos, a sua declaração pode ser observada na Figura 61.
Figura 61 - Declaração método get_sheets_and_ranges
No início da execução do método anterior é chamado o método excel_getRange, este
método recebe as colunas de início e de fim, e a linha de início de onde a informação a ler
começa, devolve uma lista de strings que contém um array de strings em cada posição da
lista, o array por sua vez em cada posição tem a informação sobre as folhas e os intervalos
de cada folha. Na Figura 62 podemos ver a sua declaração.
97
Figura 62 - Declaração do método excel_getRange
Depois da execução do método anterior é chamado o método corep_by_sheet dentro de um
ciclo que percorre a lista de strings e que recolhe os dados das células com dados do
cliente por todas as folhas que estão na lista. Na Figura 63 podemos observar a declaração
do método descrito anteriormente.
Figura 63 - Declaração método corep_by_sheet
Depois da obtenção da lista de células com dados do cliente é chamado o método
get_datapoints_by_sheet que através da lista de células preenchidas no excel do cliente
recolhe os respectivos data points. O método pode ser observado na Figura 64.
Figura 64 - Declaração método get_datapoints_by_sheet
Na execução o método anterior é invocado o método get_data_points_excel, este método é
responsável por adquirir o valor do data point do excel, recebe como entrada o nome da
folha e o Idexcel que é a posição da célula, e devolve o valor do data point para essa
posição.
Figura 65 - Declaração do método get_datapoints_excel
98
O método corep_by_sheet referenciado anteriormente invoca um método em todo
semelhante ao método excel_getRange, chamado excel_getRangeCorep_by_sheet, que
pode ser observado na Figura 66. Este método recebe os parâmetros que entram no
excel_getRange e o nome da folha a recolher informação e devolve uma lista de células
sem valores vazios, os valores vazios são ignorados pois não terão valores correspondentes
no excel template de data points. Isto acontece por causa da configuração dos templates
onde as folhas podem ter intervalos que não podem ser preenchidos, o que faz com que
existam células sem preenchimento entre células preenchidas.
Figura 66 - Declaração excel_getRangeCorep_by_sheet
O método anterior invoca o método GetRangeCorepColumn_by_sheet para preencher os
valores dos campos Cellvalue, Idexcel, e Folha. Para preencher o campo Idexcel foi
necessário criar um novo método chamado ExcelColummFromNumber, este método
transforma o número da coluna em letra, esta transformação é feita para ser possível
trabalhar com métodos internos da classe nativa Microsoft.Office.Interop.Excel, que
permite trabalhar com intervalos constituídos por apenas uma célula, depois da
transformação é concatenado o número da linha e assim o Idexcel é formado pela letra da
coluna e o número da linha.
Este Idexcel é utilizado para encontrar o campo Datapoint através do método
get_datapoints_by_sheet, já referido anteriormente. Na Figura 66 pode ser observada a
declaração do método.
Figura 67 - Declaração método GetRangeCorepColumn_by_sheet
99
Neste momento o programa já tem todos os dados necessários recolher em relação aos
ficheiros excel, dados relacionados com os intervalos, dados a reportar pelos clientes e os
data points correspondentes. O próximo passo é pesquisar a taxionomia para formar o
ficheiro XBRL na base de dados access.
Numa classe criada para tratar o acesso à base de dados, foi então criado um método
chamado trata_listas_celulas, ver Figura 68, para adquirir os dados da base de dados, por
cada folha da lista de RangesExcel o método invoca o método get_context_list_celulas_db,
ver Figura 69, que realiza as interacções com a base de dados e o método
get_trata_unitRef_precision, ver Figura 71, que trata os atributos UnitRef e Precision do
objecto CelulaEXCL.
Figura 68 - Método trata_listas_celulas
Durante a execução do método get_context_list_celulas_db a lista de células é percorrida
por um ciclo onde são feitas várias pesquisas à base de dados com o fim de preencher os
atributos DataTypeCode, FlowTypeCode, MemberCode e ContextID, dos elementos da
lista. Na Figura 69 podemos observar a declaração do método, a abertura da ligação à base
de dados, a construção da query string query_get_metric para a consulta do campo Metric,
na Figura 70, podemos observar a execução do comando com a query string e o
preenchimento do atributo Metric.
100
Figura 69 - Excerto método get_context_list_celulas_db (1)
Figura 70 - Excerto método get_context_list_celulas_db (2)
O método get_trata_unitRef_precision, apresentado na Figura 71, preenche os atributos
Precision e UnitRef da lista de célula que recebe de entrada. A informação que a base de
dados fornece para estes atributos é caso a Metric seja igual a m, ou seja, monetário, a
precisão é de duas casas decimais e a sua referência é uEUR (euros), caso seja igual a p
(percentagem) ou i (inteiro), a precisão é de quatro casas decimais e a sua referência é
uPure (número puro), se a Metric for vazia os atributos serão vazios também.
101
Na primeira abordagem estes atributos eram preenchidos com base em pesquisas à base de
dados, era necessário pesquisar várias tabelas e depois de analisadas as várias bases de
dados e documentação existente sobre as várias revisões da taxionomia verificou-se que
estes valores não sofriam alterações. Devido a este facto e para melhorar o desempenho
optou-se por fazer este método para preenchimento dos atributos.
Figura 71 - Método get_trata_unitRef_precision
Neste momento o programa já tem todos os dados necessários para construir o ficheiro
XBRL, só falta construir a lista de contextos por folha, este passo é talvez o mais
importante pois os contextos podem ser formados por várias células, estas tem que ser
agrupadas no contexto correspondente. Na Figura 72 podemos observar a declaração do
método e o ciclo foreach onde é feito o agrupamento das células por contexto.
102
Figura 72 - Excerto método lista_contextos_por_sheet
Neste momento a lista lista_sheets_tipoRel tem todos os dados ordenados de forma a
poderem ser escritos para um ficheiro. Foi criada uma classe para tratar do output do
programa e escrever o ficheiro XBRL.
Nesta classe estão construídos os cabeçalhos dos ficheiros XRBL que se assemelham aos
ficheiros XML, como referido anteriormente neste trabalho.
Na Figura 73 podemos observar a declaração do método responsável pela escrita dos dados
em ficheiros.
Figura 73 - Declaração método escreve_xbrl
O relatório COREP_Con escrito em ficheiro com taxionomia XBRL ocupa cerca de
duzentas e oitenta mil linhas, este é o reporte com mais data points da totalidade dos tipos
de relatórios. Na Figura 74 está apresentado um exemplo da folha C00.01 do template
excel.
103
Figura 74 - Ficheiro XBRL da folha C00.01 do excel template
Na Tabela 17 estão apresentados os principais métodos enunciados nesta descrição sobre a
implementação deste projecto, bem como um pequeno resumo relativo à sua função.
104
Tabela 17 - Resumo principais métodos
Método Função Principal
excel_init Abre os ficheiros excel para leitura dos dados.
excel_close Termina a ligação do ficheiro excel aberta pelo
método excel_init de forma a que esta não interfira
com ligações futuras e ocupar memória em sistema.
get_sheets_and_ranges Carrega os dados do excel de configuração de
intervalos para uma Lista de Ranges
excel_getRange Devolve a informação e o intervalo de cada folha.
corep_by_sheet Recolhe os dados das células com dados do cliente por
todas as folhas que estão na lista de Ranges.
get_datapoints_by_sheet Recolhe os data points da lista de células preenchidas
com dados.
get_datapoints_excel Adquire o valor do data point do excel, recebe como
entrada o nome da folha e o Idexcel que é a posição da
célula.
excel_getRangeCorep_by_sheet Devolve uma lista de células sem valores vazios,
devido à estrutura do excel poderão existir células com
valores vazios, logo não têm data points
GetRangeCorepColumn_by_sheet Preenche os valores dos campos Cellvalue, Idexcel, e
Folha.
trata_listas_celulas Responsável por adquirir os dados da base de dados
MS access.
get_context_list_celulas_db Preenche os atributos DataTypeCode, FlowTypeCode,
MemberCode e ContextID, dos elementos da lista
get_trata_unitRef_precision Preenche os atributos Precision e UnitRef da lista de
célula que recebe de entrada
lista_contextos_por_sheet Agrupa as células por contexto.
escreve_xbrl Escreve o conteúdo da lista para um ficheiro XBRL.
105
5.2.1.7 Testes
Neste momento aguardamos que o equipa da Deloitte que está encarregue de ajudar os
clientes a preencher os templates, nos forneça um ficheiro com dados reais para podermos
converter para XBRL e ser enviado para validação pelo BdP.
O BdP até à data ainda não disponibilizou um validador de ficheiros, nem um esquema
XSD que nos permita validar o nosso ficheiro global. Os ficheiros XSD que a EBA
disponibiliza permitem apenas testar o XBRL individual para cada folha, ou seja, apenas
temos garantias que se o BdP aceitar as folhas em separado, a sua construção está de
acordo com o XSD da EBA e por conseguinte o programa produz ficheiros válidos.
A solução foi testada dez vezes com o processamento do ficheiro com todas as sheets e
data points incluídos, numa máquina intel core i5 com 4 GB de memória volátil, máquina
standard dos colaboradores Deloitte, e a média de processamento foi cerca de 2 horas e 23
minutos. Mas numa utilização diária não levará tanto tempo de execução uma vez que os
vários tipos de reporte não utilizam a totalidade dos data points.
5.2.1.8 Conclusões
Esta primeira abordagem necessita da validação do ficheiro global, para se poderem tirar
conclusões mais profundas sobre o trabalho efectuado até aqui.
Este desenvolvimento foi o ponto de partida desta tecnologia, até agora desconhecida, na
AMS e na Deloitte Portugal. O conhecimento adquirido com o contacto e investigação
desta tecnologia poderá ser bastante útil no futuro uma vez que consolidado, poderão ser
estudadas propostas de consultoria para a implementação de funcionalidades nos sistemas
dos clientes que extraiam a informação necessária a reportar já em XBRL, eliminando o
preenchimento dos templates excel.
Esta solução poderá ajudar a Deloitte, a estar preparada para dar resposta imediata num
futuro próximo, aos seus clientes de outras áreas, como as seguradoras e empresas cotadas
em bolsa, uma vez que serão as próximas a serem obrigados a efectuar relatórios em
XBRL às entidades reguladoras.
106
5.2.1.9 Trabalho futuro
O trabalho futuro, depois da validação do ficheiro global, seria a optimização do programa,
caso a Deloitte tenha que preencher muitos templates dos seus clientes o tempo de
execução na conversão pode tornar este processo impraticável.
Outa alternativa seria disponibilizar a solução num portal, com a tendência crescente da
nuvem, esta solução poderia ser integrada no portal de clientes da Deloitte, para que estes
possam interagir com uma plataforma onde descarreguem os templates a reportar, que os
preencham, submetam na plataforma e depois descarreguem o XBRL correspondente.
Assim os clientes teriam sempre disponível a última versão dos templates.
107
6 Considerações Finais
Neste capítulo encontra-se uma síntese do trabalho desenvolvido, os resultados e principais
e principais contributos, propostas de trabalho futuro e conclusões.
6.1 Síntese do relatório
Conforme a sociedade evolui, as profissões vão evoluindo, as leis vão evoluindo, as
exigências competitivas vão sendo cada vez maiores.
São apresentados projectos em que a figura do consultor e a consultoria assumem um papel
preponderante, as empresas têm colaboradores que mantêm os sistemas core em
funcionamento, mas quando surgem novas necessidades, quer por requisitos de negócio,
quer por outros requisitos, como por exemplo, os legais, muitas vezes vêem-se na
necessidade de contratar pessoas com conhecimento específico no desafio que têm pela
frente. Quando o desafio é ultrapassado, o consultor deixa de ser necessário e a empresa
não terá que arcar com despesas futuras relacionadas com a sua contratação.
Neste relatório estão apresentados vários projectos de empresas com necessidade
optimizarem os seus sistemas ERP ao máximo, de forma a corresponderem às exigências
do mercado ou responderem aos requisitos legais que vão sendo incluídos na legislação.
Está também apresentado um projecto sobre XBRL, uma tecnologia que assumirá alguma
importância no futuro uma vez que vêm alterar a forma como as instituições financeiras
trocam informação entre si.
108
6.2 Resultados e principais contributos
Na Tabela 18 estão apresentados os principais contributos em cada desenvolvimento
apresentado neste relatório.
Tabela 18 - Resumo de conclusões dos projectos
Projecto Principais Contributos
Programa de Etiquetas Redução de tempo;
Redução de desperdício;
Uniformização do processo;
Poupança na formação de recursos humanos.
Projecto de extracção de dados
“JET” Centralização de extracções;
Simplificação de processos de extracção;
Rapidez no processo de extracção;
Eliminação da necessidade de conciliação de dados.
Determinação automática do
Centro de Custo para Pedido de
Compra de Imobilizado
Eliminação do erro humano;
Melhor qualidade dos dados;
Melhor precisão dos gastos com cada imobilizado.
Fichiér des Écritures
Comptables Análise dos requisitos de forma a conseguir ajudar
o Manager a ganhar negócio para a área.
Certificação de Guias de
Remessa Ajudar o cliente a ter o seu sistema de emissão de
guias de remessa em conformidade com a Lei.
Formulário de aprovação de
Requisições de Compra Optimização do processo e compras.
Eliminação do Papel no processo de compras,
Implementação do programa
RPFIEU_SAFT - SAF-T PT Ajudar o cliente a satisfazer os requisitos legais de
Portugal
Apoio funcional à certificação de
Facturas e Guias de Remessa Ajudar o cliente a satisfazer os requisitos legais de
Portugal
Conversor eXtended Business
Reporting Language – XBRL Ajudar o cliente a satisfazer os requisitos legais de
Portugal;
Desenvolvimento de uma ferramenta inovadora.
Com a realização destes projectos foi possível chegar a algumas conclusões gerais. Em
relação à tecnologia SAP, pode-se afirmar que não basta instalar um sistema, é necessário
pensar na sua manutenção e evolução como forma de os manter com capacidade de
responder às novas necessidades de negócio, desempenhando um papel fundamental na sua
operação.
109
Á medida que os sistemas vão evoluindo e ficando cada vez mais especializados e
complexos, também os profissionais vão ter que se qualificar de maneira a que consigam
manter os sistemas em bom funcionamento.
As alterações às leis podem muitas vezes acarretar problemas para as empresas, pois
muitas vezes os novos requisitos legais são dúbios em questões relacionadas com empresas
multinacionais e as autoridades competentes não são explícitas quando questionadas.
Em relação à tecnologia Microsoft, mais propriamente ao XBRL, podemos afirmar que é
uma tecnologia emergente em Portugal e na Europa, a primeira versão do conversor XBRL
ainda precisa que os ficheiros de saída sejam validados. Convém salientar que esta foi a
primeira abordagem à tecnologia e a disponibilidade do BdP para esclarecimentos tem sido
pouca. Esta falta de disponibilidade do BdP tem sido um entrave para a validação desta
primeira abordagem, pois é fundamental que a mesma seja validada antes de se prosseguir
com mais desenvolvimento.
6.3 Propostas de trabalho futuro
Todos os projectos foram implementados com sucesso, estando ainda um projecto
pendente de adjudicação por parte do cliente, tendo os clientes mostrado grande satisfação
pelo resultado dos mesmos, a proposta de trabalho futuro nesta área seria o
desenvolvimento/criação de processos, que permitam acompanhar as mudanças legislativas
em relação aos sistemas ERP, como forma a conseguir criar uma mais rápida e melhor
preparação na apresentação de soluções aos clientes quando eles nos requisitam para ajudar
na resolução de novos desafios.
O projecto que ainda está pendente de aprovação pelo cliente é o projecto relativo a
Fichiér des Écritures Comptables, caso a proposta seja adjudicada pelo cliente será
necessário analisar o programa existente e arquitectar as alterações necessárias de forma a
que este possa extrair a informação necessária.
Em relação ao desenvolvimento XBRL é necessário insistir na validação da primeira
abordagem, e desenhar uma solução mais optimizada, que permita a conversão mais rápida
dos templates excel.
110
6.4 Conclusão
A actividade de consultoria informática enquanto profissão, torna-se cada vez mais
importante, quanto à especificidade dos sistemas. Nos projectos de SAP apresentados é
notória a importância do consultor como agente facilitador de conhecimento específico a
empresas que não possuem nos seus quadros este tipo de conhecimento. A tecnologia SAP
é uma tecnologia dispendiosa, só usada por grandes organizações. A formação de
consultores SAP é igualmente onerosa, deste modo as empresas preferem contratar
consultores especificamente para resolver estes desafios do que formarem recursos e
mantê-los, assim vão contratando consultores com conhecimentos específicos à medida
dos desafios com que se vão deparando.
Cada vez mais as organizações procuram usufruir ao máximo das capacidades dos seus
sistemas ERP, pode-se observar que o SAP é um ERP que permite grande adaptabilidade
para responder a esses desafios. A SAP disponibiliza constantes actualizações para resolver
eventuais problemas que vão surgindo, como o caso de alterações legislativas.
Com a obrigatoriedade dos bancos comunicarem os dados financeiros ao BdP poderá
surgir um nicho de mercado para este tipo de tecnologia, é uma tecnologia muito específica
onde os conhecimentos de finanças e de informática se aliam e complementam.
111
7 Bibliografia
Alidata. www.alidata.pt. 2014. (acedido em 10 de 02 de 2014).
APB. “APB.” http://www.apb.pt. 04 de 2013.
http://www.apb.pt/content/files/Portuguese_Banking_Sector_Overview_Sept2013.
pdf (acedido em 07 de 2014).
BNA. http://www.bna.ao. 2011.
http://www.bna.ao/Conteudos/Artigos/detalhe_artigo.aspx?idc=139&idsc=168&idl
=1 (acedido em 15 de 02 de 2014).
Castro, Sandra de Jesus Esteves de. Caracterização da Adopção de Sistemas ERP nas
Grandes Empresas Portuguesas. Vila Real: Universidade de Trás-os-Montes e Alto
Douro, 2009.
Daiichi-Sankyo. http://www.daiichi-sankyo.pt. 21 de 06 de 2013. http://www.daiichi-
sankyo.pt/empresa/perspectiva-global.html (acedido em 06 de 05 de 2014).
Davenport, Thomas H. Putting the Enterprise into the Enterprise System. Harvard
Business School, 1998.
Deloitte. About Deloitte. Lisboa: Deloitte, 2014.
—. Deloitte. 2014. http://www.deloitte.com/view/pt_PT/pt/quem-somos/index.htm
(acedido em 01 de 02 de 2014).
Elisabeth J. Umble, Ronald R. Haft, M. Michael Umble. Enterprise resource planning:
Implementation procedures and critical success factors. Elsevier, 2002.
Esteves, José Manuel. Definition And Analysis of Critical Success Factors For ERP
Implementation Projects. Barcelona: Universitat Politècnica de Catalunya, 1999.
112
Expresso. http://expressoemprego.pt. 2014.
http://expressoemprego.pt/carreiras/gestao/comercial-e-consultor/4644 (acedido em
04 de 07 de 2014).
EY. www.ey.com. 2014. http://www.ey.com/BR/pt/About-us/Our-history (acedido em 01
de 02 de 2014).
Fabory. www.fabory.pt. 2014. http://fasteners.fabory.com/eCache/POR/10/112.html
(acedido em 15 de 04 de 2014).
Fernando Alexandre Rodrigues Gambôa, Márcio Saez Caputo, Ettore Bresciani Filho. Risk
Management Method to ERP Systems Implementation Based on Critical Sucess
Factors. Journal of Information Systems and Technology Management, 2004.
Fujitsu. http://www.fujitsu.com/. 2014. http://www.fujitsu.com/pt/about/ (acedido em 03 de
04 de 2014).
Galpin, T. J. The Human Side of Change: A Practical Guide to Organization Redesign.
San Francisco: Jossey-Bass Inc., 1996.
Gøtze, John. The Future Of ERP Systems. København: IT-Universitetet, 2009.
Heidecker, Norbert. Wiki SCN SAP. SAP. 12 de 09 de 2013.
http://wiki.scn.sap.com/wiki/display/ABAP/Form+Printing+-
+SAPscript,+Smart+Forms,+SAP+Interactive+Forms+by+Adobe (acedido em 05
de 02 de 2014).
Hong, K.-K., & Kim, Y.-G. "The Critical Sucess factors for ERP implementation: an
organizational fit perspective." In Information & Management , pp. 25-40. Elsevier,
2002.
ISPGAYA. http://paginas.ispgaya.pt. s.d. http://paginas.ispgaya.pt/~msantos/9-SI1-
sapR3.pdf (acedido em 20 de 02 de 2014).
José Esteves, João Jorge. Análise Comparativa de Metodologias de Implementação de SAP
. Évora: Conference of Associação Portuguesa de Sistemas de Informação, 2001.
K. Kumar, Jos van Hillegersberg. ERP Experiences and Evolution. COMMUNICATIONS
OF THE ACM, 2000.
113
KPMG. www.kpmg.com. 2014.
http://www.kpmg.com/pt/pt/about/organization/paginas/default.aspx (acedido em
01 de 02 de 2014).
Kyocera. www.kyocera.p. 01 de 04 de 2013.
http://www.kyocera.pt/index/about_us/vision.html (acedido em 02 de 06 de 2014).
O’Leary, Daniel E. Knowledge management across the enterprise resource. Vol.
Information Systems. Los Angeles: International Journal of Accounting, 2001.
Oliveira, Ana Lígia Queirós. O ERP SAP na Gestão de Materiais: o caso do Grupo
Martifer. Universidade de Aveiro, 2009.
PHC. www.phc.pt. 2014. http://www.phc.pt/portal/e/tquemsomos.aspx (acedido em 10 de
02 de 2014).
Portugal, Banco de. Banco de Portugal. 2013. http://www.bportugal.pt/pt-
PT/Supervisao/BasileiaIIDivulgacaodeInformacao/UniformizacaoreportesadocaoFI
NREPCOREP/Paginas/inicio.aspx (acedido em 01 de 05 de 2014).
Portugal, Banco de. Implementação COREP e FINREP. Lisboa, 22 de 01 de 2014.
PWC. www.pwc.pt. 2014. http://www.pwc.pt/pt/quem-somos/index.jhtml (acedido em 01
de 02 de 2014).
Républica, Assembleia da. Diário da República, 1.ª série — N.º 160. 21 de 08 de 2013.
http://dre.pt/pdf1sdip/2013/08/16000/0502105047.pdf (acedido em 20 de 03 de
2014).
República, Assembleia da. Portaria n.º 340/2013 de 22/11, DR n.º 227 – Série I. Lisboa,
2013.
Rossi, Sandra. Wiki SCN SAP. SAP. 20 de 05 de 2010.
http://wiki.scn.sap.com/wiki/display/ABAP/ALV (acedido em 05 de 02 de 2014).
SAGE. www.sage.pt. 2014.
http://www.sage.pt/Default.aspx?action=ArticleViewer&target=410&m=428
(acedido em 10 de 02 de 2014).
114
SAP. http://www.sap.com/index.html. 2014. http://www.sap.com/index.html (acedido em
20 de 02 de 2014).
—. www.sap.com. 2014. http://www.sap.com/bin/sapcom/en_us/downloadasset.2014-02-
feb-01-01.sap-corporate-2014-fact-sheet-en-pdf.bypassReg.html (acedido em 20 de
02 de 2014).
—. www.sap.com. 2009.
https://help.sap.com/saphelp_nw04/helpdata/en/fc/eb2c46358411d1829f0000e829f
bfe/BCAB4_PT_image002.gif (acedido em 20 de 02 de 2014).
Scott Buckhout, Edward Frey, Joseph Nemec Jr. Por um ERP. HSM Management, 1999.
Sylvestre Uwizeyemungu, Louis Raymond. “Essential Characteristics of an ERP System:
Conceptualization and Operation.” Porto: Sixth International Conference on
Enterprise Information Systems, 2004.
Tadjer, R. Enterprise resource planning. Internet Week, 1998.
Vincent A. Mabert, Ashok Soni, M.A. Venkataramanan. Enterprise resource planning:
Managing the implementation process. Vol. European Journal of Operational
Research, em European Journal of Operational Research, de Ashok Soni, M.A.
Venkataramanan Vincent A. Mabert. Elsevier, 2003.
XBRL. http://www.xbrl.org/. 2014. http://www.xbrl.org/AboutXBRL (acedido em 01 de
05 de 2014).
Ziegler, Klaus. Wiki SCN SAP. SAP. 05 de 10 de 2011.
http://wiki.scn.sap.com/wiki/display/ABAP/ABAP+Workbench (acedido em 05 de
02 de 2014).
115
8 Anexos
117
8.1 Anexo Um - Planeamento do Projecto
118
119
120
Na figura seguinte é apresentado um diagrama com os projectos desenvolvidos ao longo do
tempo passado como consultor da área da AMS. Em alguns casos foi possível trabalhar em
mais que um projecto em simultâneo dado que se aguardava que outras tarefas se
concluíssem, como no caso de testes do conversor de XBRL.
121
8.2 Anexo Dois - Requisitos do projecto de extracção de
dados “JET”
122
123
124
125
8.3 Anexo Três - Manual do programa “JET”
126
127
128
129
130
131
8.4 Anexo Quatro - Especificação Funcional - Pedido de
compra - Centro de custo
132
133
134
135
136
8.5 Anexo Cinco - Especificação técnica - Pedido de Compra
- Centro de custo
137
138
139
140
141
8.6 Anexo Seis - Certificação de Guias de Remessa -Excerto
de código ABAP *&---------------------------------------------------------------------*
*& Form get_sipt_likp_counter
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* -->INPUT_TABLE text
* -->OUTPUT_TABLE text
*----------------------------------------------------------------------*
form get_sipt_likp_counter tables input_table structure itcsy
output_table structure itcsy.
data: ls_itcsy type itcsy,
lv_vbeln type vbeln_vl,
lv_vkorg type vkorg,
ls_sipt_likp type sipt_likp,
ls_zsd12n type zsd12n,
lv_cert_id type sipt_cert_id,
ls_vbfa type vbfa,
lt_sipt_likp type table of sipt_likp.
clear ls_itcsy.
read table input_table into ls_itcsy with key name = 'VBDKA-VBELN'.
if sy-subrc is initial.
call function 'CONVERSION_EXIT_ALPHA_INPUT'
exporting
input = ls_itcsy-value
importing
output = lv_vbeln.
clear ls_vbfa.
* Get actual document for order 'J' Document category of subsequent doc
ument
select single *
from vbfa
into ls_vbfa
where vbelv eq lv_vbeln
and vbtyp_n eq 'J'.
check ls_vbfa is not initial.
clear ls_itcsy.
read table input_table into ls_itcsy with key name = 'VBDKA-VKORG'.
if sy-subrc is initial.
call function 'CONVERSION_EXIT_ALPHA_INPUT'
exporting
input = ls_itcsy-value
importing
output = lv_vkorg.
select single *
from zsd12n
into ls_zsd12n
where vkorg = lv_vkorg.
142
if sy-subrc is initial.
clear: ls_sipt_likp,
lt_sipt_likp[].
* sort lt_sipt_likp DESCENDING by creadate creatime.
* Get the last signed document.
select *
from sipt_likp
into corresponding fields of table lt_sipt_likp up to 1 rows
where vbeln = ls_vbfa-vbeln
and bukrs = ls_zsd12n-vkorg
order by creadate creatime descending.
check lt_sipt_likp[] is not initial.
read table lt_sipt_likp into ls_sipt_likp index 1.
check sy-subrc eq 0.
select single cert_id
from sipt_cert
into lv_cert_id.
if sy-subrc is initial.
clear ls_itcsy.
ls_itcsy-name = 'LV_PRINT_CHAR'.
ls_itcsy-value = ls_sipt_likp-print_char.
modify output_table from ls_itcsy
transporting value where name = ls_itcsy-name.
concatenate lv_cert_id '/AT' into lv_cert_id.
condense lv_cert_id no-gaps.
ls_itcsy-name = 'LV_CERT_ID'.
ls_itcsy-value = lv_cert_id.
modify output_table from ls_itcsy
transporting value where name = ls_itcsy-name.
endif.
endif.
endif.
endif.
endform. "get_sipt_likp_counter
143
8.7 Anexo Sete - Especificação Técnica - Guias de Remessa
144
145
146
147
148
149
150
8.8 Anexo Oito - Manual Utilizador SAF-T PT
151
152
153
154
155
156
157
158
159
160
161
8.9 Anexo Nove - Formação Programa SAF-T PT
162
163
164
165
166
167
168
169
170
171
172
173
174
175
Manual de operações
176
177
178
179
180
181
182
Caso de teste
183
184
185
186
8.10 Anexo Dez - Exemplo de Instância XBRL
<?xml version="1.0" encoding="utf-8"?>
<!--(C) EBA-->
<xbrli:xbrl xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xbrli="http://www.xbrl.org/2003/instance"
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xbrldi="http://xbrl.org/2006/xbrldi"
xmlns:iso4217="http://www.xbrl.org/2003/iso4217"
xmlns:find="http://www.eurofiling.info/xbrl/ext/filing-indicators"
xmlns:eba_dim="http://www.eba.europa.eu/xbrl/crr/dict/dim"
xmlns:eba_MC="http://www.eba.europa.eu/xbrl/crr/dict/dom/MC"
xmlns:eba_CI="http://www.eba.europa.eu/xbrl/crr/dict/dom/CI"
xmlns:eba_OF="http://www.eba.europa.eu/xbrl/crr/dict/dom/OF"
xmlns:eba_met="http://www.eba.europa.eu/xbrl/crr/dict/met"
xmlns:eba_BA="http://www.eba.europa.eu/xbrl/crr/dict/dom/BA"
xmlns:eba_AS="http://www.eba.europa.eu/xbrl/crr/dict/dom/AS"
xmlns:eba_RL="http://www.eba.europa.eu/xbrl/crr/dict/dom/RL"
xmlns:eba_SC="http://www.eba.europa.eu/xbrl/crr/dict/dom/SC">
<link:schemaRef xlink:type="simple"
xlink:href="http://www.eba.europa.eu/eu/fr/xbrl/crr/fws/corep/its-2013-02/2013-
12-01/mod/corep_con.xsd" />
<xbrli:unit id="uEUR">
<xbrli:measure>iso4217:EUR</xbrli:measure>
</xbrli:unit>
<xbrli:unit id="uPURE">
<xbrli:measure>xbrli:pure</xbrli:measure>
</xbrli:unit>
<xbrli:context id="c1">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
</xbrli:context>
<find:fIndicators>
<find:filingIndicator contextRef="c1">C_00.01</find:filingIndicator>
<find:filingIndicator contextRef="c1">C_05.02</find:filingIndicator>
</find:fIndicators>
<xbrli:context id="c0">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:BAS">eba_BA:x17</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<!-- table C 00.01 -->
<eba_met:ei4 contextRef="c0">eba_AS:x1</eba_met:ei4>
<eba_met:ei207 contextRef="c0">eba_SC:x7</eba_met:ei207>
<!-- table C 05.02 -->
<xbrli:context id="c2">
<xbrli:entity>
187
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:COI">eba_CI:x5</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x2</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi53 unitRef="uEUR" decimals="INF"
contextRef="c2">100000000.00</eba_met:mi53>
<eba_met:mi57 unitRef="uEUR" decimals="2"
contextRef="c2">60000000.00</eba_met:mi57>
<eba_met:pi188 unitRef="uPURE" decimals="4"
contextRef="c2">0.8000</eba_met:pi188>
<eba_met:mi160 unitRef="uEUR" decimals="INF"
contextRef="c2">48000000000.00</eba_met:mi160>
<eba_met:mi40 unitRef="uEUR" decimals="2" contextRef="c2">-
52000000.00</eba_met:mi40>
<xbrli:context id="c3">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x1</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi53 unitRef="uEUR" decimals="2"
contextRef="c3">57050000.00</eba_met:mi53>
<eba_met:mi57 unitRef="uEUR" decimals="INF"
contextRef="c3">450000.00</eba_met:mi57>
<eba_met:pi188 unitRef="uPURE" decimals="4"
contextRef="c3">0.8000</eba_met:pi188>
<eba_met:mi160 unitRef="uEUR" decimals="2"
contextRef="c3">360000.00</eba_met:mi160>
<eba_met:mi40 unitRef="uEUR" decimals="2" contextRef="c3">-
56690000.00</eba_met:mi40>
<xbrli:context id="c4">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:COI">eba_CI:x5</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x1</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
188
<eba_met:mi53 unitRef="uEUR" decimals="2"
contextRef="c4">1000000.00</eba_met:mi53>
<xbrli:context id="c5">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:COI">eba_CI:x4</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x1</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi53 unitRef="uEUR" decimals="-3"
contextRef="c5">4050000</eba_met:mi53>
<xbrli:context id="c6">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:COI">eba_CI:x2</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x1</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi53 unitRef="uEUR" decimals="2"
contextRef="c6">2000000.00</eba_met:mi53>
<xbrli:context id="c7">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:COI">eba_CI:x1</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x1</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi53 unitRef="uEUR" decimals="INF"
contextRef="c7">1500000</eba_met:mi53>
<xbrli:context id="c8">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
189
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:COI">eba_CI:x3</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x1</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi53 unitRef="uEUR" decimals="-3"
contextRef="c8">551000.00</eba_met:mi53>
<xbrli:context id="c9">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x397</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x1</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi53 unitRef="uEUR" decimals="2"
contextRef="c9">52000000.00</eba_met:mi53>
<xbrli:context id="c10">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x9</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi53 unitRef="uEUR" decimals="2"
contextRef="c10">64775456.56</eba_met:mi53>
<eba_met:mi57 unitRef="uEUR" decimals="2"
contextRef="c10">11403821.81</eba_met:mi57>
<eba_met:pi188 unitRef="uPURE" decimals="INF"
contextRef="c10">0.8000</eba_met:pi188>
<eba_met:mi160 unitRef="uEUR" decimals="2"
contextRef="c10">9123057.45</eba_met:mi160>
<eba_met:mi40 unitRef="uEUR" decimals="2" contextRef="c10">-
55652399.11</eba_met:mi40>
<xbrli:context id="c11">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:COI">eba_CI:x5</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x9</xbrldi:explicitMember>
</xbrli:scenario>
190
</xbrli:context>
<eba_met:mi53 unitRef="uEUR" decimals="2"
contextRef="c11">3500000.00</eba_met:mi53>
<xbrli:context id="c12">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:COI">eba_CI:x4</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x9</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi53 unitRef="uEUR" decimals="INF"
contextRef="c12">4585456.56</eba_met:mi53>
<xbrli:context id="c13">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:COI">eba_CI:x2</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x9</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi53 unitRef="uEUR" decimals="2"
contextRef="c13">2100000.00</eba_met:mi53>
<xbrli:context id="c14">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:COI">eba_CI:x1</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x9</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi53 unitRef="uEUR" decimals="2"
contextRef="c14">1250000.00</eba_met:mi53>
<xbrli:context id="c15">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
191
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:COI">eba_CI:x3</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x9</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi53 unitRef="uEUR" decimals="2"
contextRef="c15">1235456.56</eba_met:mi53>
<xbrli:context id="c16">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x397</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x9</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi53 unitRef="uEUR" decimals="2"
contextRef="c16">56690000.00</eba_met:mi53>
<xbrli:context id="c17">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:BAS">eba_BA:x11</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:COI">eba_CI:x5</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x2</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi243 unitRef="uEUR" decimals="2"
contextRef="c17">48000000.00</eba_met:mi243>
<xbrli:context id="c18">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:BAS">eba_BA:x11</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x1</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi243 unitRef="uEUR" decimals="2"
contextRef="c18">360000.00</eba_met:mi243>
192
<xbrli:context id="c19">
<xbrli:entity>
<xbrli:identifier
scheme="http://www.eba.europa.eu/fr/dummy">DUMMY</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2014-03-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember
dimension="eba_dim:BAS">eba_BA:x11</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:MCY">eba_MC:x342</xbrldi:explicitMember>
<xbrldi:explicitMember
dimension="eba_dim:TOF">eba_OF:x9</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<eba_met:mi243 unitRef="uEUR" decimals="2"
contextRef="c19">9123057.45</eba_met:mi243>
</xbrli:xbrl>
193
8.11 Anexo Onze - XBRL - Comunicação trocada com o Banco
de Portugal
194
195
196
197
