Escolar Documentos
Profissional Documentos
Cultura Documentos
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 à 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.
i
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.
iii
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.
v
Í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
vii
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
viii
Índice de Figuras
ix
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
x
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
xi
Índice de Tabelas
xii
Índice de Acrónimos
xiii
1 Introdução
À 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.
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).
1
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.
2
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.
3
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.
5
Figura 2 - Deloitte 1880 - 1920
6
“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:
7
PricewaterhouseCoopers / AG - Assessoria de Gestão, Lda (PwC AG);
PricewaterhouseCoopers / MFAS – Management, Finance & Accounting Services,
Lda.
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).
8
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 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.
9
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 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.
10
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.
11
3 Formação
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.
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
13
de dados de/para várias tipos de documentos, aplicados a casos próximos da realidade da
Banca e Seguradoras.
14
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.
15
4 Áreas de Consultoria
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).
17
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.
18
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.
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).
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).
19
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.
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.
20
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).
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.
21
Estes sistemas cada vez mais abrangentes de quase todas as actividades do negócio das
empresas receberam o nome de ERP.
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).
22
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).
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).
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
23
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).
24
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.
25
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).
26
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
27
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 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.).
28
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.
29
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.
Neste módulo é onde se efectua o planeamento, controlo e supervisão dos recursos e custos
associados aos projectos da empresa.
30
Planeamento da Produção (Production Planning, PP)
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.
31
Outros módulos disponíveis:
32
Tabela 1 - Fase Roadmap ASAP
Fases de Descrição
Implementação
Preparação do O objectivo desta fase é definir o início do projecto, identificando os elementos da
Projecto 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 Consiste em criar uma análise de processos de negócio, que se caracteriza numa
Processos de descrição pormenorizada dos resultados das entrevistas (Workshops) entre os
Negócio 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 Esta etapa é marcada pelo culminar de um ambiente pré-produtivo para o início
Produtivo e Suporte 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.
33
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.
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.
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
34
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.
35
5 Projectos de Consultoria
É 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.
Este projecto está relacionado com o módulo de Gestão de materiais e com o módulo
ABAP.
37
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.
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.
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.
38
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.
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.
39
Figura 17 - Principais relações entre as tabelas de Materiais
40
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.
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.
41
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.
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.
42
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.
Período de análise:
Empresas:
Escolha múltipla com base na tabela T001 (esta tabela contém as empresas que
constam no sistema).
43
Na Tabela 3 estão apresentadas as tabelas e os campos a serem exportados.
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.
44
Tabela 4 - Campos RFSABL00
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
45
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.
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.
46
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.
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.
47
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.
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.
48
Figura 27 - Concatenação valores
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.
49
Figura 28 - Exemplo extracção CSV
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:
50
Tabela 8 - Campos tabela USR02
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.
51
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.
52
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.
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.
53
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.
54
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:
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
55
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.
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.
56
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)
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.
57
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.
58
(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.
59
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.
60
Tabela 12 - Correspondência campos artigo 47 e SAP
Nome do
Nº Informação Descrição SAP Nome SAP
campo
1 The journal entry code JournalCode Document Type BLART
2 The journal entry label JournalLib Description LTEXT
The number of the accounting entry Document Number BELNR
3 (follows a chronological and sequential EcritureNum
numbering)
4 The accounting entry date EcritureDate Posting Date BUDAT
The accounting number , which refers to ACC Number GACC_NUM
the appropriate accounting terminology –
5 CompteNum
the first three characters three characters
must meet the French accounting standard
The account label, under the French ACCT Shot Text TXT20
6 CompteLib
Accounting Standard
The sub ledger account number (field must ACC Number ACC_NUM
7 CompAuxNum
be left empty if not used)
The sub ledger account label (field must be Name NAME1
8 CompAuxLib
left empty if not used)
Reference of the relevant supporting Reference XBLNR
9 PieceRef
document
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
The lettering/marking of the accounting Clearing Document AUGBL
14 EcritureLet
entry (field must be left empty if not used)
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
Code of the currency (leave blank if not Currency WAERS
18 Idevise
used)
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.
61
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.
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.
62
5.1.5.2 Requisitos
Os requisitos neste trabalho são:
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.
63
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.
64
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.
65
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:
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.
66
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.
67
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.
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.
68
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.
69
ou rejeitada, se a requisição fosse aprovada, era então passada para o sistema SAP para ser
criada uma ordem de compra.
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.
À medida que o pedido vai sendo aprovado ou rejeitado essa informação é armazenada
numa tabela de logs criada para o efeito.
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
70
basta indicar um número, ou um intervalo no caso de ser necessário imprimir várias, na
mesma operação.
71
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.
72
Figura 44 - Formulário de requisição de compra
73
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.
74
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.
75
Tabela 14 - Notas SAF-T PT
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.
76
Figura 45 - Exemplo de objecto a registar
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.
77
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:
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
78
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.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.
79
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).
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.
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.
80
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.
Código Descrição
Common Reporting - Own Funds and Leverage, Consolidated (Prudential scope)
COREP_Con
IFRS or National GAAP
Common Reporting - Own Funds and Leverage, Individual IFRS or National
COREP_Ind
GAAP
Liquidity Coverage - COREP, Consolidated (Prudential scope) IFRS or National
COREP_LCR_Con
GAAP
COREP_LCR_Ind Liquidity Coverage - COREP, Individual IFRS or National GAAP
Large Exposures - COREP, Consolidated (Prudential scope) IFRS or National
COREP_LE_Con
GAAP
COREP_LE_Ind Large Exposures - COREP, Individual IFRS or National GAAP
Stable Funding - COREP, Consolidated (Prudential scope) IFRS or National
COREP_NSFR_Con
GAAP
COREP_NSFR_Ind Stable Funding - COREP, Individual IFRS or National GAAP
Código Descrição
FINREP_Con_GAAP Financial Reporting, Consolidated (Prudential scope) National GAAP
FINREP_Con_IFRS Financial Reporting, Consolidated (Prudential scope) IFRS
81
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).
5.2.1.2 Taxonomia
Uma taxonomia XBRL é composta por schemas e linkbases, ambos ficheiros XML:
82
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.
5.2.1.3 Instância
Uma instância XBRL contém a seguinte informação:
83
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).
Template C00.01:
Nature of Report
Accounting framework National GAAP
Reporting Level Consolidated
1. Instruments that
qualified for point a) of 100000000.00 60000000.00 0.80 48000000000.00 -52000000.00 48000000.00
Article 57 of 2006/48/EC
2. Instruments that
qualified for point ca) of
Article 57 and Article
57050000.00 450000.00 0.80 360000.00 -56690000.00 360000.00
154(8) and (9) of
2006/48/EC, subject to the
limit of Article 467
2.2 Grandfathered
instruments with a call
and incentive to
4050000.00 ------------- ------------ --------------- --------------- --------------
redeem
2.2.1 Instruments
with a call 2000000.00 ------------- ------------ --------------- --------------- --------------
exercisable after
the reporting date,
84
Amount of
(-) Amount that
instruments Base for Total
Applicable exceeds the
plus related calculating Limit grandfathered
percentage limits for
share the limit amount
grandfathering
premium
2.2.2 Instruments
with a call
exercisable after
the reporting date,
and which do not
meet the
1500000.00 ------------- ------------ --------------- --------------- --------------
conditions in
Article 49 of CRR
after the date of
effective maturity
2.2.3Instruments
with a call
exercisable prior
to or on 20 July
2011, and which
do not meet the
551000.00 ------------- ------------ --------------- --------------- --------------
conditions in
Article 49 of CRR
after the date of
effective maturity
3.2 Grandfathered
items with an incentive 4585456.56 ------------- ------------ --------------- --------------- --------------
to redeem
85
Amount of
(-) Amount that
instruments Base for Total
Applicable exceeds the
plus related calculating Limit grandfathered
percentage limits for
share the limit amount
grandfathering
premium
effective maturity
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.
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
86
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.
87
Figura 47 - Fluxo data point
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
88
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.
89
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.
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.
90
Figura 51 - Todos os módulos 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
91
intervalos e das folhas de cada relatório. Esta estrutura de pastas pode ser observada na
Figura 53.
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.
92
Figura 54 - Método excel_init
93
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.
94
Foram criadas as seguintes classes:
As declarações das classes podem ser observadas nas Figura 58, Figura 59 e Figura 60
respectivamente.
95
Figura 60 - Declaração classe CelulaEXCL
96
Figura 62 - Declaração do método excel_getRange
97
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.
98
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.
99
Figura 69 - Excerto método get_context_list_celulas_db (1)
100
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.
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.
101
Figura 72 - Excerto método lista_contextos_por_sheet
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.
102
Figura 74 - Ficheiro XBRL da folha C00.01 do excel template
103
Tabela 17 - Resumo principais métodos
104
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.
105
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.
106
6 Considerações Finais
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.
107
6.2 Resultados e principais contributos
Na Tabela 18 estão apresentados os principais contributos em cada desenvolvimento
apresentado neste relatório.
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.
108
Á 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.
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.
109
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.
110
7 Bibliografia
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.
Davenport, Thomas H. Putting the Enterprise into the Enterprise System. Harvard
Business School, 1998.
Esteves, José Manuel. Definition And Analysis of Critical Success Factors For ERP
Implementation Projects. Barcelona: Universitat Politècnica de Catalunya, 1999.
111
Expresso. http://expressoemprego.pt. 2014.
http://expressoemprego.pt/carreiras/gestao/comercial-e-consultor/4644 (acedido em
04 de 07 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.
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.
112
KPMG. www.kpmg.com. 2014.
http://www.kpmg.com/pt/pt/about/organization/paginas/default.aspx (acedido em
01 de 02 de 2014).
Oliveira, Ana Lígia Queirós. O ERP SAP na Gestão de Materiais: o caso do Grupo
Martifer. Universidade de Aveiro, 2009.
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.
113
SAP. http://www.sap.com/index.html. 2014. http://www.sap.com/index.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.
114
8 Anexos
115
8.1 Anexo Um - Planeamento do Projecto
117
118
119
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.
120
8.2 Anexo Dois - Requisitos do projecto de extracção de
dados “JET”
121
122
123
124
8.3 Anexo Três - Manual do programa “JET”
125
126
127
128
129
130
8.4 Anexo Quatro - Especificação Funcional - Pedido de
compra - Centro de custo
131
132
133
134
135
8.5 Anexo Cinco - Especificação técnica - Pedido de Compra
- Centro de custo
136
137
138
139
140
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'.
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.
141
if sy-subrc is initial.
clear: ls_sipt_likp,
lt_sipt_likp[].
check sy-subrc eq 0.
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.
endform. "get_sipt_likp_counter
142
8.7 Anexo Sete - Especificação Técnica - Guias de Remessa
143
144
145
146
147
148
149
8.8 Anexo Oito - Manual Utilizador SAF-T PT
150
151
152
153
154
155
156
157
158
159
160
8.9 Anexo Nove - Formação Programa SAF-T PT
161
162
163
164
165
166
167
168
169
170
171
172
173
174
Manual de operações
175
176
177
178
179
180
181
Caso de teste
182
183
184
185
8.10 Anexo Dez - Exemplo de Instância XBRL
<!--(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>
186
<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>
187
<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>
188
<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>
189
</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>
190
<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>
191
<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>
192
8.11 Anexo Onze - XBRL - Comunicação trocada com o Banco
de Portugal
193
194
195
196
197