Fandom

Scratchpad

BEX TEST

215,672pages on
this wiki
Add New Page
Discuss this page0 Share

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.

BEX Decisional Data

Overview

BEX delivers a pool of information containing the key performance measures of p&l, turnover, managed assets and the client base, with their evolution over time. These performance measures can be broken down by the analytical dimensions of organizational structure, client segmentation, products, operations, currency and accounting structure, as shown below.

There is complete mapping between management accounting information in the decisional database and OLYMPIC financial accounting. At a global accounting level, the figures contained in the two systems are the same.

Insert here "BEX Overview.gif"


Classifications

In order to give overview, it is useful to introduce hierarchical classifications, for example of products and of geographical locations, which are oriented specifically towards the needs of management accounting. To give progressively finer analysis, it is then possible to drill-down each dimension through successive hierarchical levels. The bank can organize its own classifications by means of a BEX proprietary tool, Classification Manager.


Object Catalogue

BEX uses the Business Intelligence approach to make available the information contained in the decisional database. The state of the art product Business Objects is integrated with the BEX database, which offers great simplicity in accessing data and navigating its complexity in order to uncover root causes and identify trends.

For ease of use, the performance measures and analytical dimensions of the decisional database are represented by "objects" in a catalogue, which can be easily selected for reporting. An overview of the catalogue is illustrated on the next page, showing the principal folders organizing the objects, with several cases of detailed objects.


Reporting

To prepare a report, the objects corresponding to the required items are selected from the catalogue, which is called a "universe". Dimensions are represented by cubes and measures by spheres, as illustrated below.

Insert here "BEX Object Catalogue.gif"

The user can create his own queries from scratch using the objects in the catalogue, without having to understand complex database schemas or SQL. There are currently about 400 objects in the catalogue. As we describe the database contents in this guide, we shall indicate which measures and dimensions are available for creating reports.



Analysis dimensions

This section describes those dimensions which are applicable to all performance measures. BEX contains additional dimensions that are specific to individual measures. These are described in the section for the corresponding performance measure.

The performance measures in the decisional database can be broken down across the major categories of dimensions below.

  • Organizational structure.
  • Clients.
  • Products and Instruments.
  • Currencies.
  • Operations.
  • Periods.


Organizational Structure

Several different organizational structures can coexist for the bank: relationship management structures and a profit / cost centre structure.

The relationship management hierarchy links to the client file through the id of the relationship manager contained in the file. This enables reporting for the relationship management structure of all items connected to the client: for example, the assets in the differents management profile categories.

The profit / cost centre hierarchy links to p&l items, enabling detailed analysis of revenues and costs.

When using the hierarchies to report data that changes over time, the applicable structure is automatically selected by BEX, based on its validity period. Examples of such data which evolve over time are client attributes, p&l items, turnover and assets.

The following are the objects in the catalogue for the Relationship Management and the Profit / Cost Centre hierarchies.

  • View of the hierarchy: enables multiple variants for different analysis purposes.
  • Start date of the validity period for the hierarchy.
  • Name and identifier of each of seven hierarchy levels of the hierarchy

BEX provides additional, separate hierarchies for members in Relationship Manager teams in addition to relationship manager himself.


Distribution Channels

 Agents

In addition to the name and identifier of agents, a hierarchy with three levels can be specified for the bank’s external agent structure.


 Intermediate Agents

Dimensions give the names and ids of the intermediate agents who receive retrocessions from the bank.

These objects can be combined with most other objects in BEX to give information relevant to the intermediate agents.


Clients

Client Attributes

The evolution of the attributes over time is recorded, so that when attributes are combined with data which carries a date, such as assets, turnover or p&l, those client attributes are retrieved which were applicable at the date concerned. The following client attributes are available:

  • Client’s legal domicile
  • Client’s nationality
  • Client type e.g. numbered client, bank, internal …
  • Client management type e.g. managed with constraints, institutional, external management …
  • Client nature e.g. individual, corporation, financial establishment
  • Client rating
  • Client’s language
  • Client objectives e.g. liquidities, income, growth …
  • Client investment plan identifier for automatic investment of a client’s cash in investment funds.
  • Client economic sector
  • Client potential
  • Client’s market segment
  • Client’s risk country
  • Client status code e.g. A = cancelled, B = blocked, C = disputed claim, S = suspended
  • A company’s legal structure or a person’s civil status
  • Client management profile e.g. growth, security, balanced …
  • Client’s profession or main business activity
  • Client’s geograhpic area
  • Client’s birth date
  • Client opening date
  • Client closing date
  • Client Group


Client Attribute Classifications

BEX provides the following hierarchical classifications:

  • Client Geographical Classification
  • Market Geographical Classification
  • Client Nature Classification
  • Management Profile Classification
  • Managment Type Classification
  • Market Segment Classification
  • Activity Domain Classification

The bank can create views containing different sets of classifications that reflect specific reporting needs. For example, a marketing view of geographic classification could be more general than for relationship management.


Asset Bands

BEX provides a set of asset bands in order to classify clients. For example 0 – 100’000, 100’001 – 500’000, 500’001-1’000’000, etc. The asset band segmentation is based on the net worth amount of each client calculated for a palette of products selected by the bank.

The bank can create views containing different sets of asset bands that reflect specific needs. For example, for a marketing view, it could be useful to have five asset bands, whereas for a top management view it could be more appropriate to use just three.

This segmentation can also be applied to groups of clients.


Client Relationships

  • Relationship between two clients
  • Related client
  • Region code of the related client. Other attributes from the Master File entry of the related client can be requested from ERI.

The starting-off point for assembling client relationship information need not necessarily be the client name or identifier. In BEX, it is possible to select this information through any client attribute such as domicile or client management type, as illustrated in the following example: for all clients domiciled in Colombia, select the related clients for whom they have power of attorney.


Legal Agreements

  • Agreement name
  • Attribution Status, whether an agreement is active (signed) or not (cancelled)
  • Comments or references
  • Agreement Code
  • Agreement Family Code
  • Signature Date
  • Cancelation Date
  • Last Change Date
  • User who last changed the agreement entry


Legal Agreements History

Since a given type of agreement can be successively signed and cancelled by a client, further objects give the history of agreement modifications:

  • Code of the agreement for which previous situations existed.
  • Previous agreement status for the client.
  • Signature date on this previous modification of the agreement.
  • Cancelation date on this previous modification of the agreement.
  • Comments or references on this previous modification of the agreement.
  • Identifier of the user who created this previous modification of the agreement.
  • Date when the agreement situation was modified.
  • System time when the agreement situation was modified.


Products and Instruments

For BEX, a product is a category of instruments, such as the Security Categories specified in OLYMPIC table 600 and the OLYMPIC instrument categories specified in OLYMPIC table 030.


Product Classification

A primary need for the bank is to have overview of its products at a higher level than the individual product itself. BEX offers this possibility by enabling the bank to establish a hierarchy consisting of a view specification and seven levels, built up from the BEX set of individual products.


Instruments

For a given category, details of those instruments which constitute that category may be needed as dimensions in analysis. BEX therefore provides the following objects for displaying instruments and their attributes.

  • Instrument short name.
  • Instrument long name
  • Instrument Id
  • Industrial group
  • Instrument Currency
  • Instrument Risk Currency
  • Instrument Nationality
  • Instrument Issuer Country
  • Instrument Maturity Date: depending on the instrument type, due date, redemption or expiration date.
  • Instrument Stock exchange


 Internal Funds

In the case of internal funds, it is important to be able to investigate revenue generated from investment activities related to the fund. To achieve this, BEX replaces the security identifiers of underlying instruments by the fund’s own identifier.


 Stock Exchange Classification

BEX provides an aggregation level above Stock Exchanges with the possibility of providing different groupings by specifying different views.


Currencies

BEX has different ways of representing currencies so that the bank can use the form it prefers:

  • Explicit text, eg. US Dollars
  • Numeric currency code, eg. 840
  • ISO currency abbreviation, eg. USD


Currency Classification

BEX provides a hierarchy for banks wishing to report information on currency baskets.


Operations

One of the principal objectives in management decision-making is to analyse banking activity and underlying operations. Since it is important for the bank to have overview of its operations at a higher level than the individual operation itself, BEX offers a hierarchy consisting of a view specification and four levels, built up over individual operations.


Periods

In order to provide reports which automatically adapt data selection based on dates as time progresses, BEX makes two types of periods available:

  • Periods relative to the present moment: for example, the series of immediately past months.
  • Fixed periods for specific years - the current and preceding years: for example the monthly periods of 2007, 2006 and 2005.

The following periods are available : years, semesters, quarters, bi-months, months. Each period has a symbolic identifier which can be used in a report and which doesn’t change over time: for example, the previous month is M-01 and the current year is Y-00. This use of symbolic period identifiers means that the report period titles and column headings change automatically at each successive reporting period, without having to modify the report specification.

The periods automatically cover the complete time-span of the installed BEX database.

The reporting year can start in the middle of the civil year. This provides for reporting needs such as for the UK, where the fiscal year starts on April 1st.



Performance Measures

P&L

In management accounting, it is important to be able to identify factors contributing towards profitability. To achieve this, BEX replaces global p&l amounts booked in OLYMPIC by individual amounts which reflect these contributing factors. For example, a global retrocession from an external fund manager for all funds is replaced by the amount earned on each client holding in individual funds.

The following functionalities are integrated on a standard basis:

  • Account Interest Accruals at the client level.
  • Contract Interest Accruals at the client level.

The following functionalities are optional and are implemented by customization:

  • Custody Fee Accruals
  • Management Fee Accruals
  • P&l for individual external and internal funds.
  • Fund p&l by client.
  • Refinancing Account Interest.
  • One-level refinancing: Treasury Margin.
  • Two-level refinancing: Asset / Liability Committee Margin.
  • Refinancing Contract Interest.
  • One-level refinancing: Treasury Margin.
  • Two-level refinancing: Asset / Liability Committee Margin.
  • Profit / Cost Centre Attributions.


Accruals

 Account Interest Accruals

Accrual information is taken from OLYMPIC simulations of account closure. This has the advantage of providing accruals at the client level whereas the standard account interest accruals in the Profit & Loss Statement of OLYMPIC Core System is at a higher level, such as the management group.


 Contract Interest Accruals

Accrual information is taken from an OLYMPIC auxiliary file for p&l accounts. BEX calculates the slice of interest accrued each month and the not the total accrual since the start of the contract.


 Periodic Fee Accruals

There are two alternative sources for Custody Fee Accruals and Management Fee Accruals:

  • If the bank books the accruals, BEX takes the information directly from the resulting p&l movements.
  • If the accruals are not booked, these custody fees can be simulated manually through their OLYMPIC menu and BEX retrieves the information from the generated simulation file, recording it in the BEX p&l movements file.


Fund P&L

 Internal Funds

The p&l stream is derived from operations for the fund, such as commissions on buying and selling securities in the fund’s portfolio, forex, transfers and other transactions for the fund. These fund operations are carried out in OLYMPIC for the entity in the Client Master File which identifies the fund – the virtual client owning the assets of the fund. The p&l items for each such "fund" client are enriched in BEX by adding the security number and the security category information for the fund. These added fields enable the p&l items for funds to be linked to the fund entries in the BEX product hierarchy, enabling analysis for the domain of funds to be targeted, with types of funds and individual funds to be accessed by drill-down.


 External Funds

An external fund management institute remits to the bank a single global payment for commissions on all its individual funds. This global amount recorded in OLYMPIC can be broken down in BEX by individual fund in order to measure profitability for each fund.


 Fund P&L by Client

The profits that a client brings to the bank through his holdings in a fund are not normally apparent because they are recorded at the fund level without any reference to the client. The p&l for each fund therefore needs to be broken down by client in order to see which clients are at the root of fund profits.

BEX does this by allocating the p&l amounts for each fund to its clients in proportion to the average number of fund units the client held during the month.


Refinancing

 Choice of the Refinancing Process

BEX offers the following choices for accrued and booked interest on contracts and accounts at client level:

  • No refinancing.
  • Refinancing through the bank’s treasury department (one-level refinancing).
  • Refinancing through an internal asset / liability committee (ALCO) and the bank’s treasury department (two-level refinancing).


 Margins for Interest-bearing Products

The BEX decisional database gives explicitly the refinancing margin details for ALCO and the treasury department. It also gives explicitly the remaining margin for the bank on each interest entry at the client level.

BEX calculates these margins both on booked and accrued interest.


 Treasury Margin

The primary source of the treasury margin rate is the base rate assigned to the client account.

As this rate does not always reflect current market rates (or corporate internal rates), BEX offers the possibility of applying pre-defined rules to correct it. This correction is based on reference rates chosen by the bank, such as LIBOR rates, entered into OLYMPIC interest rates files and tables either manually or automatically via an interface, for example from Reuters.

If the difference falls outside tolerance thresholds determined by the bank, the market rate is substituted for determining the refinancing amount.


 ALCO Margin

The source of the asset liability committee margin rate is information entered into OLYMPIC interest rates files and tables.


 Profit / Cost Centre Attributions

The bank’s margin on each type of transaction can be allocated to the profit / cost centres involved in the following ways:

  • Allocation of fixed amounts based on the transaction domain - useful to attribute transaction-based standard costs to operational units. On defining operations at the product level, the information provides the elements for product variable costs, proportional to the volume of operations for the product.
  • The remaining amount after any fixed transactional costs have been deducted can be allocated to profit centres on a percentage basis. The percentages and profit centres can be varied according to the transaction domain. Allocations can be made to the profit centres managing the client: the client relationship manager as well as to the client’s centre. In addition, allocations can be made to functional centres independent of the client.

An example of the client’s centre would be a branch office which is not hierarchically related to the relationship manager. An example of a functional centre is a marketing centre.


 Complementary P&L Items

The above sections cover standard cases where it is useful for p&l items from OLYMPIC Core System to be detailed. However, there may well be futher cases in the bank where items which are booked as global amounts within the financial accounting are best detailed for management accounting, so as to enable finer analysis. Any such cases can be handled by injecting the details directly into BEX via an interface and by neutralizing the original items.

An example is salary costs which are typically booked as a global item within OLYMPIC financial accounting but which can more usefully be detailed at the management group level for incorporation in profitability analysis.


 Integrating External Information Systems

Where the bank has revenues or costs which are not handled by OLYMPIC, for example for affiliated banks, these can be injected directly into BEX, so as to give a comprehensive view of profitability.


 P&L Neutralization

In cases where p&l items originating in OLYMPIC Core System are replaced by more detailed items generated for OLYMPIC Bank Expansion, the former are marked with a special class indicator within BEX, so as not to include duplicate information for reporting. The items are available within the detailed p&l file as an audit trail.


P&L Dimensions

 P&L Standard Structure

The hierarchy gives a ready-to-use overview of p&l without the bank needing to set up any classifications.

The top level contains the categories Commissions, Interest, Charges, Gross P&L, Net P&L. This means that when using this single object in a report, the broad categories of Commission, Interest and Charges are displayed in individual columns (or lines, if wished), followed by an aggregation of revenue items excluding agent retrocessions in a column Gross P&L and accompagnied by a further column Net P&L which gives an aggregation of p&l items including agent retrocessions. Any column which is not wanted can be filtered out on a report, so that only Gross P&L and Net P&L could be displayed, or Commissions, Interest, Charges, Net P&L.

Lower levels are available to present details.


 P&L Category / Item Classification

Further classification schemas gives hierarchies tailored to individual needs which are based on an inventory of unique combinations of p&l account category and item automatically extracted from movement data. The classification levels are determined by the bank.

At each subsequent BEX replication of p&l items, any new combinations of account category and item are automatically added to the lowest level of the hierarchy. with empty levels above these new entries. These are then completed by the bank.


 Profit / Cost Centre Hierar
chy

 Reporting Profitability at Hierarchical Levels

According to recommended performance measurement practice (see the section "Above the Line and Below the Line Approach" in "The Ernst & Young Guide to Performance Measurement for Financial Institutions", McGraw-Hill 1995, p.46 et seq.), costs and revenues which originate at a specific level should not normally be reported at lower levels if these levels are not directly responsible for these items. BEX fully implements this practice by allowing the linking of p&l items to a profit / cost centre at upper levels of the hierarchy. This is to be contrasted with practices in other banking circles which requiring linkage at the lowest level, accompanied by simple roll-up.


Turnover

Transaction Dimensions

Inflows and outflows can be selected, either seperately or combined, giving net inflow / outflow values. This information can be specified for cash, securities or overall. The selection of cash items or security items can also be specified for all other transaction information.

Transaction information can be specified for both system and value dates.

Reversal transactions can be identified.

Information can be selected for the order giver and the beneficiary of transactions, as well as for counterparties and custodians.

The accounting set of movements for a transaction can be selected and links are provided to underlying information in the transaction log file.


Transaction Measures

Transaction values are given both in local currency and in the currency of the transaction. BEX provides the exchange rate between these currencies.

Two types of transaction values are provided by BEX:

  • The gross value of the transaction from the point of view of the client, without costs and taxes.
  • The net value of the transaction from the point of view of the client.

Since it is important to measure overall transactional activities, regardless of whether they are inflows or outflows, BEX provides absolute values of transactions, disregarding their signs.

BEX also provides transaction counts to indicate how brisk transactional activity is.

For securities, in addition to transaction values, the quantities traded in transactions are given. BEX also gives absolute quantities in order to measure overall portfolio activity, regardless of whether a transaction is a purchase or a sale.


Assets

Two types of asset measures are provided by BEX:

Periodic Positions & Balances

These are given on a daily, weekly or monthly basis for clients, third parties and the bank itself.

Asset / liability values are given both in local currency and in the currency of the instrument involved. Since it can be significant to measure the overall magnitude of positions and balances, regardless of whether they are assets or liabilities, BEX provides absolute values in addition to net values.

BEX also provides net worth values for individual clients and for client groups, covering assets for a customizable palette of products, with the option of including or excluding negative balances of instruments.


 Securities

The average cost price of the position at the date of its evaluation is given as well as the total amount of accrued and booked interest for bonds and fiduciary deposits. This information is available in the currency of the position and in the bank’s currency.


Average Positions & Balances

 Accounts

Average balances are based on daily account balances, which can be taken by system, value, reference or transaction date.

In addition to overall average balances, averages are indicated separately for negative and positive balances over the month. This enables, for example, meaningful ratios to be established for interest-bearing products.


 Securities

The averages are based on the stock price applicable each day, multiplied by the position quantity and convertible to the bank’s currency according to daily exchange rates. In addition to position values, the quantities involved are given.



General Ledger Accounts

BEX provides extensive balance sheet and income statement information, which can be organized and summarized along multiple dimensions. This gives more flexibilty for analysis than in the Core System.
Examples are:

  • Overview at any level of the chart of accounts.
  • Drill-down from any level of the chart of accounts to explore the contribution of lower levels.
  • Incremental values of items over any period. View of exceptions to acceptable divergence.
  • Balance sheet and income statement broken down by the relationship management hierarchy.
  • Contributions to the balance sheet and income statement by clients, particularly based on their attributes -such as their geographical distribution or their asset bands.
  • Contributions to the balance sheet and income statement by currency, with the possibility of displaying amounts in the original currency.
  • View of balance sheet and income statement items with or without accruals.


Client Base

BEX enables the population of the current and past client base to be evaluated across many different dimensions, including client entry and departure dates.



Complementary Information

Budgets

Budgetary data can be established for the various Performance Measures given above. This data can be organized along the various axes given in Analysis Dimensions section above. The budgets can then be combined with the information in BEX derived from OLYMPIC Core System to give full budgetary analysis.


Simulations

Auxiliary and parametric data can be combined with data derived from OLYMPIC Core System to give simulations.


Key Performance Indicators

BEX has powerful auxiliary system, MyBEX, which tailors derived information to client needs. This enables sophisticated reporting to be easily established.

Differences with OLYMPIC Core System

OLYMPIC BANK EXPANSION (BEX) contains a vast amount of additional data compared to OLYMPIC CORE SYSTEM, in order to provide full management accounting facilities.

Additional Analysis Axes

For management accounting, it is essential to analyse data along dimensions which are not present in financial accounting. These include products and operations for which BEX enriches p&l information with data from log files. It is also provides auxiliary axes such as client asset bands based on client net worth: this measure is established by BEX for a customizable palette of products, usually excluding client credits, for example.

Hierarchical Axes

For overview, analysis axes need to be organized in hierarchies, for example of products, relationship management structure and of geographical locations, which are oriented specifically towards the needs of management accounting. Hierarchies are available not only on diverse attributes but also for synthetic information such as combinations of p&l account categories and items, to give overview on revenues / costs.

The bank can organize its own classifications by means of a BEX proprietary tool, Classification Manager. To give progressively finer analysis, it is then possible to drill-down each dimension through successive hierarchical levels.

Complete P&L Information

In management accounting, it is important to be able to identify factors contributing towards profitability. To achieve this, BEX replaces global p&l amounts booked in OLYMPIC CORE SYSTEM by individual amounts which reflect these contributing factors. For example, a global retrocession from an external fund manager for all funds is replaced by the amount earned on each client holding in individual funds.

The following complementary information is integrated within BEX:

  • Account & contract interest margins at the client level.
  • Account & contract interest accruals at the client level.
  • Custody Fee Accruals
  • Management Fee Accruals
  • P&l for individual external and internal funds.
  • Fund p&l by client.
  • Profit / Cost Centre Attributions.
  • External agent retrocessions, to give net revenue values.

General Ledger Accounts

BEX provides extensive balance sheet and income statement information, which can be organized and summarized along multiple dimensions. This gives more flexibilty for analysis than in OLYMPIC CORE SYSTEM.
Examples are:

  • Overview at any level of the chart of accounts.
  • Drill-down from any level of the chart of accounts to explore the contribution of lower levels.
  • Incremental values of items over any period. View of exceptions to acceptable divergence.
  • Balance sheet and income statement broken down by the relationship management hierarchy.
  • Contributions to the balance sheet and income statement by clients, particularly based on their attributes -such as their geographical distribution or their asset bands.
  • Contributions to the balance sheet and income statement by currency, with the possibility of displaying amounts in the original currency.
  • View of balance sheet and income statement items with or without accruals.

Accessibility Of History Data

Not only is performance information fully historized, but so are items such as relationship management structure and client attributes. This enables past performance measures on turnover, p&l and asset levels to be retrieved together with the relationship manager and client information which was applicable in the past. To give an example of the importance of this history data, bonuses must be based on performance achieved for clients based on their attribution to relationship managers at the time that profits were earned and not on their current attribution.

Key Performance Indicators

In order to establish key performance indicators, asset positions and balances are completed by average positions and balances. For accounts balances, average positive and negative balances are given separately.

BEX has powerful auxiliary system, MyBEX, which tailors derived information to client needs. This enables sophisticated reporting to be easily established.

Customization

The following document explains issues in customizing BEX. It is destined for the key user of the system, to enable him to understand the issues underlying preparatory activities carried out by the ERI consultant. In this way, he can make an informed choice on available alternatives.

Insert here the document BEX Customization Guide.pdf

Analyse de la rentabilité bancaire

Cette section présente l’application de BEX à l’analyse de la rentabilité bancaire

OLYMPIC Bank Expansion offre aux managers et aux gestionnaires de la banque une vision complète et précise de la rentabilité de leur établissement. D’abord, il établit l’état du p&l en intégrant la source de tous les charges et produits. Ensuite, par l’ajout d’informations complémentaires et par des ventilations, il dégage non seulement la rentabilité globale, mais aussi la rentabilité par client , par unité organisationnelle, par produit ou encore par segment du marché.

OLYMPIC Bank Expansion apporte ainsi la maîtrise de tous les facteurs qui contribuent au succès de la banque.

Intégration de sources multiples

L’analyse de la rentabilité bancaire nécessite une vue d’ensemble sur toutes les sources de charges et revenus.

OLYMPIC Bank Expansion offre cette vision en intégrant non seulement les informations contenues dans la base de données OLYMPIC Banking System, mais aussi des informations provenant de sources externes, telles qu’un institut externe de gestion de fonds.

Revenus courus

OLYMPIC Bank Expansion prend en compte les revenus courus traités par OLYMPIC Banking System. Certaines données sont stockées, d’autres calculées en amont.

Dans la comptabilité analytique, un horizon temps différent de l’horizon temps utilisé dans l’opérationnel est nécessaire. OLYMPIC Bank Expansion prend en charge la gestion du découpage des courus par période.

Rentabilité par produit

Pour la clarté descriptive, nous regroupons ici l’expression produits & services sous le terme « produits ».

Pour analyser la rentabilité par produit, il est essentiel d’attribuer des identifiants produit aux mouvements de p&l. OLYMPIC Bank Expansion gère cette attribution comme expliqué ci-dessous.

Mouvements P&L en provenance d’OLYMPIC Banking System

 Instruments usuels

Pour les mouvements p&l issus d’opérations sur un type de produit explicitement spécifié, OLYMPIC Bank Expansion extrait l’information de l’opération et rattache aux mouvements le code du type de produit concerné.

Exemples : contrats de trésorerie, fiduciaires, titres et coupons.

Pour les titres et les coupons, le code de la valeur est aussi rattaché aux mouvements p&l. Ceci permet l’analyse en fonction des attributs des produits, par exemple en fonction des places de bourses ou des pays risques.

 Fonds internes

L’identifiant d’un fonds interne est rattaché aux mouvements p&l qui concernent les instruments du fonds, ce qui permet de dégager la rentabilité réelle du fonds.

Exemples : les droits de garde ou intérêts en provenance d’un contrat de trésorerie associé au fonds.

 Services

Pour les services bancaires, il n’y a pas d’instrument explicite. Des types de produit par défaut sont ainsi rattachés par domaine (exemple : les transferts.) à chaque mouvement p&l. Ces identifiants par défaut peuvent être modifiés.

Bank Expansion permet d’attribuer à chaque ensemble « genre de compte et rubrique » un type de produit, accompagné d’un préfixe « base de codification ». Ce préfixe permet d’ajouter le code spécifique du domaine.

Des enregistrements de classification pour les clés « base de codification / type de produit » sont créés automatiquement dans les tables de regroupement de produits si ces cas n’existent pas encore.

Mouvements p&l de provenance externe à OLYMPIC

Des mouvements p&l externes à OLYMPIC peuvent être joints à Bank Expansion.

Exemple : les commissions provenant d’une société de gestion de fonds externe, qui sont normalement entrées dans OLYMPIC par une écriture globale. Pour l’analyse de rentabilité par produit, il est nécessaire que la société externe mette à disposition la répartition de ces commissions concernant chaque fonds qu’elle gère pour la banque.

Les mouvements p&l détaillés sont injectés dans Bank Expansion avec leurs identifiants produits. L’écriture globale originale passée dans la comptabilité financière, portant le montant total, est conservée dans Bank Expansion pour des raisons de piste d’audit, mais elle est neutralisée pour empêcher que les montants figurent deux fois (au niveau global et au niveau détaillé).

La neutralisation est effectuée grâce à une table paramétrée par la banque et contenant les genres et rubriques des mouvements p&l à neutraliser dans la comptabilité analytique.

Table de classification

La table de regroupement de produits d’OLYMPIC Bank Expansion intègre aisément les identifiants de produits gérés en détail hors OLYMPIC. La hiérarchie de classification permet à ces produits externes de figurer distinctement au niveau type de produit, mais aussi d’être consolidés aux niveaux des agrégats de lignes et de gammes de produits avec d’autres produits semblables gérés dans OLYMPIC.

Rentabilité client

Fonds – internes et externes

OLYMPIC Bank Expansion répartit automatiquement par client les montants de chaque mouvement p&l concernant le fonds, au pro rata des parts détenues dans le fonds. Cette répartition se base sur les soldes moyens des parts de fonds détenus par les clients.

Il faut noter que la répartition par fonds des commissions provenant d’une société de gestion de fonds externe (évoqué plus haut) est utile non seulement pour la rentabilité par produit mais également pour ventiler les montants p&l des fonds par clients.

Contrats de trésorerie et comptes

L’allocation des revenus entre la trésorerie et les autres intervenants de la banque est réalisée pro-rata des taux de base et taux de marges associés avec ces deux types de produits. OLYMPIC Bank Expansion rattache à chaque mouvement p&l ces taux en provenance des informations opérationnelles, pour les intérêts courus ou échus.
Ensuite, le taux de base est validé par rapport aux taux du marché selon des règles et des seuils de tolérance d’écarts paramétrés par la banque. Ceci est nécessaire car les taux de base attribués sont parfois déterminés par des considérations commerciales et ne sont pas toujours le reflet du coût réel du refinancement.

Exemple de validation pour un contrat : Un taux de référence est recherché, provenant d’une source tel que le LIBOR, (source spécifiée par la banque pour chaque type de contrat), qui correspond au même type de contrat, même monnaie et même durée. Le taux de base du contrat est applicable s’il ne s’écarte pas du taux de référence par des pourcentages paramétrés. Dans le cas contraire, c’est le taux de référence qui sera pris en compte, afin d’assurer une attribution équitable à la trésorerie.

Après cette phase de préparation, les montants d’intérêt sont ventilés entre la trésorerie et la gestion sur la base du ratio taux de base / taux de marge.

Changes

OLYMPIC prend en charge la distribution des revenus des changes entre les cambistes et la gestion sur la base de cours de compensation. OLYMPIC Bank Expansion reprend ces informations pour intégrer les attributions.

Mouvements p&l courus

Les courus au niveau client concernant les droits de garde et les commissions de gestion sont explicités, basé sur les procédures OLYMPIC de production, et intégrés dans Bank Expansion

Mouvements p&l externe à OLYMPIC

Le dispositif d’injection des mouvements de détail et la neutralisation du mouvement global correspondant de la comptabilité financière (évoqué ci-dessus dans le cas de rentabilité par produit) est important pour déterminer la rentabilité par client.

Exemple : les commissions de cartes de crédit au niveau client établies hors OLYMPIC peuvent être intégrées et leur mouvement global neutralisé.

Rentabilité de la structure de la banque

Refinancements

La première répartition à faire, selon la responsabilité des acteurs en présence, est l’attribution des revenus entre la gestion clientèle et l’administration d’une part et la trésorerie et les cambistes d’autre part.

Contrats de trésorerie et comptes

L’allocation des revenus entre la trésorerie et les autres intervenants de la banque est réalisée pro-rata des taux de base et taux de marges associés avec ces deux types d’instrument. OLYMPIC Bank Expansion rattache à chaque mouvement p&l ces taux en provenance des informations opérationnelles, pour les intérêts courus ou échus.
Ensuite, le taux de base est validé par rapport aux taux du marché selon des règles et des seuils de tolérance d’écarts paramétrés par la banque. Ceci est nécessaire car les taux de base attribués sont parfois déterminés par des considérations commerciales et ne sont pas toujours le reflet du coût réel du refinancement.

Exemple de validation pour un contrat : Un taux de référence est recherché, provenant d’une source tel que le LIBOR, (source spécifiée par la banque pour chaque type de contrat), qui correspond au même type de contrat, même monnaie et même durée. Le taux de base du contrat est applicable s’il ne s’écarte pas du taux de référence par des pourcentages paramétrés. Dans le cas contraire, c’est le taux de référence qui sera pris en compte, afin d’assurer une attribution équitable à la trésorerie.

Après cette phase de préparation, les revenus / charges sont ventilés entre la trésorerie et la gestion sur la base du ratio taux de base / taux de marge.

Changes

OLYMPIC prend en charge la distribution des revenus des changes entre les cambistes et la gestion sur la base de cours de compensation. OLYMPIC Bank Expansion reprend ces informations pour intégrer les attributions.

Ventilations administration / gestion

Après le dégagement des coûts de refinancement, les montants restants doivent être ventilés entre les centres d’administration et la gestion clientèle.

Les fonctions de ventilation suivantes sont spécialement mises à disposition pour la rentabilité de la structure de la banque :

  • Attribution de montants forfaitaires sur la base du genre de compte et rubrique rattachés à une transaction. Ces forfaits par transaction peuvent être attribués au choix à des centres fixes ou éventuellement au groupe de gestion et / ou au centre de gestion du client. Pour les ventilations qui suivent cette prise de forfaits, c’est le montant restant qui est ventilé.
    Le coût par transaction pour un centre administratif peut être préparé en amont en utilisant de l’information à disposition dans la base de données décisionnelle : les compteurs des transactions par genre de compte p&l / rubrique et le total des charges pour le centre,
  • Ventilation par pourcentages sur la base du genre de compte et rubrique rattachés à une transaction. Ces pourcentages peuvent être attribués au choix à des centres fixes ou au groupe de gestion et / ou au centre de gestion du client.

Les fonctions de ventilation par forfaits et par pourcentages sont basées sur une table établie par la banque, en utilisant une interface graphique conviviale. Une entrée est établie pour chaque combinaison de genre de compte / rubrique applicable et une vue d’ensemble est offerte sur toutes les ventilations par forfaits et par pourcentages pour cette combinaison.

La procédure de ventilation des commissions de gestion des fonds au pro-rata des parts détenues par les clients (évoquée plus haut), est décisive aussi pour la rentabilité de la structure de gestion de la banque, qui dépend directement de la rentabilité des clients gérés.

L’application et l’ordre d’exécution des fonctions de ventilation sont déterminés pour chaque source de mouvements p&l par une table et peuvent être adaptés aux besoins de la banque.

 Contrôles

Chaque enregistrement qui est à l’origine d’une ventilation est gardé dans un domaine de contrôle pour assurer la piste d’audit. Il est ainsi possible de tracer l’équivalence entre l’enregistrement d’origine et les mouvements résultants d’une ventilation. Bank Expansion fournit un instrument pour contrôler le pool total des mouvements p&l.

 Historique des structures

Comme la structure de gestion attribuée à un client change dans le temps, OLYMPIC Bank Expansion prend en charge l’historique des structures de gestion. Ainsi, c’est la structure de gestion active au moment de l’acquisition des revenus en provenance d’un client qui perçoit l’attribution et non la structure applicable lors de l’analyse.

Rentabilité d’operations

Lors du rattachement des identifiants de produit aux mouvements p&l (évoqué dans la section sur la rentabilité produit), des identifiants sont également rattachés aux opérations, ce qui permet d’analyser la rentabilité par opération.

Pour les domaines qui n’ont pas un identifiant d’opération explicite, des types d’opération par défaut sont rattachés à chaque mouvement p&l, selon leur domaine. (Exemple : l’ouverture d’un contrat de trésorerie.)

Ces identifiants par défaut peuvent être modifiés. Comme pour le cas des services évoqué plus haut, en utilisant la même table gérée par la banque, un type d’opérations peut être assigné à chaque ensemble « genre de compte et rubrique », accompagné d’un préfixe « base de codification ». Ce préfixe permet l’ajout d’un code d’opérations spécifique à chaque domaine.

Des enregistrements de classification pour les clés « base de codification / type d’opération » sont ajoutés automatiquement dans les tables de regroupement d’opérations, si ces cas n’existent pas encore.

La table de classification hiérarchique d’opérations d’OLYMPIC Bank Expansion donne une vue d’ensemble sur les groupes d’opérations à plusieurs niveaux. On peut ainsi dégager des vues distinctes sur des sous-ensembles d’opérations

Exemple : l’examen de la rentabilité de la gamme d’opérations titres et ses composantes, en vue de la sous-traitance éventuel de certaines activités.

Cette table de classification intègre aisément les identifiants d’opérations gérées en détail hors OLYMPIC. La hiérarchie de classification permet à ces opérations externes de figurer distinctement au niveau type d’opération, mais aussi d’être consolidées au niveau des agrégats de lignes et de gammes d’opérations avec d’autres opérations semblables gérés dans OLYMPIC. L’utilité est d’analyser par simulation l’opportunité de rapatrier à l’intérieur de la banque des activités actuellement externes.

Exemple : rapatriement d’activités de brokerage.

Les identifiants d’opérations restent rattachés aux mouvements p&l à travers toutes les ventilations, permettant ainsi l’examen par type d’opération des revenus et charges attribués à chaque acteur de la banque concerné.

Informations de référence

Des informations de référence sont incorporées dans la base de données :

  • Les capitaux moyens par client, instrument et monnaie.
  • Les taux du marché, à utiliser pour les contrats de trésorerie et les comptes (voir plus haut le refinancement, contrats de trésorerie et comptes). Ces taux permettent aussi l’évaluation de la trésorerie selon la méthode « taux du marché ».

De l’information finement disposée pour ces instruments est intégrable automatiquement en utilisant des interfaces OLYMPIC à des sources d’information externes.

Conclusion

OLYMPIC Bank Expansion offre un enrichissement et un approfondissement des mouvements p&l standard.

Les informations p&l de la comptabilité financière sont enrichies avec les courus rassemblés de sous-systèmes OLYMPIC et avec des sources externes. Dans ce cas, les identifiants externes sont intégrés dans le système de classification globale d’OLYMPIC Bank Expansion.
En ce qui concerne l’approfondissement, les informations issues des opérations sont jointes aux informations comptables afin d’établir les bases de vues multiples sur la rentabilité. Des ventilations assurent l’attribution équitable des revenus et charges, basée sur des clés de répartition établies automatiquement et sur la répartition entre les intervenants de la banque. Cette répartition est paramétrable à l’aide d’un outil convivial.

Par ces moyens, OLYMPIC Bank Expansion précise et complète l’information et présente ainsi la rentabilité réelle de la banque aux niveaux global, produit, client, structure interne et opérations.

Operational Analysis

The following document gives the aspects of BEX which are applicable to operational analysis. It contains principally a subset of the information covered in the section "BEX Decisional Data", but specifically oriented to operations.

Insert here the document Bank Expansion Operational Analysis.doc

Reporting Examples

OLYMPIC Bank Expansion enables the constitution of thousands of different M.I.S. (Management Information Systems) type reports, providing information adapted to each bank.

OLY-BEX proposes a catalogue full of ready-to-use objects, expressed in terms of bank businesses.

The creation of reports, both simple and user-friendly - see the section Example of Report Creation below. Standard reporting is based on Business Objects, leader in the Business Intelligence sector.

Inventory of Basic Reports

The information given below is available in French in the following document: Rapports Standards.doc

The key sectors covered by standard reporting are:

  • Profitability.
  • Managed assets.
  • Turnover.
  • Deposits / withdrawals.
  • Clients.
  • Client inventory.
  • Budgetary control.
  • Balance sheet, operating accounts, the off-balance sheet and off-the-book.
  • Management structure.
  • Profit / cost centers.
  • Bank products.

Report Presentation

The information is available either in the form of tables or graphics.

Both presentations can be combined in a single report.

Drill Down

For most of the variants, each report can be explored by the variables of other variants. For example, the p&l evolution displayed by management group and manager can then be explored by asset band, management type, geographical distribution, etc. and drilled down by client.

Reporting

See the document Standard Reports

PERIODS

Any fixed or dynamic set of periods can be referenced. In practice, reports are automatically adapted over the course of time. See the usable period types in annex.

For a set of periods, e.g. for the current month, the turnover displayed for each month can be:

  • The movements amount for this month.
  • The movements amount from the beginning of the year until the end of this month

These periods can be combined in a single report – e.g. a total for the previous year can be displayed next to amounts for the months of the current year.

The following period sets can be displayed in the reports:

Months The current month, the last n months, n rolling months, any interval of months defined in absolute or relative terms. Example: dates included between the past month (M-1), and the month preceding it by three months (M-4).
Bi-monthlies The current bi-monthly, the last n bi-monthlies, n rolling bi-monthlies, any interval of bi-monthlies defined in absolute or relative terms.
Quarters The current quarter, the last n quarters, n rolling quarters, any interval of quarters defined in absolute or relative terms. Example: the past quarter; the first quarter, four years ago.
Semesters The current semester, the last n semesters, n rolling semesters, any interval of semesters defined in absolute or relative terms. Example: the past quarter; the first quarter, four years ago.
Years Any fixed or relative year or set of years. Example: the last two years.

Example of report creation

The report below shows client segmentation by indicating the number of clients in each center by assets band.

Insert Report example.gif

The creation of this report entails the following three steps:

1. Selection of information via the catalogue of objects.

2. Guided specification of extraction conditions.

Insert Report construction.gif

3. Guided specification of graphic details

Insert Report Formatting.gif

The graphic is then created automatically.

Information pour les spécialistes

Cette section contient de l’information complémentaire, destinée aux collaborateurs ERI qui sont actifs dans le consulting et le développement de BEX

Structure de la banque

Liens avec les fichiers de faits

Les mouvements, les positions de clients, les comptes du grand livre et le comptage de clients sont reliés avec la structure hiérarchique au dessus du gestionnaire concerné. Ces liens sont disponibles aux structures hiérarchiques courantes et historiques.

Les mouvements de charges et produits sont imputables à un centre de charges / produits qui se trouve à n’importe quel niveau de la hiérarchie de la banque, car d’autres opérants que les gestionnaires peuvent être liés à ces mouvements.


Hiérarchies

 Unités organisationnelles

Les unités qui apparaissent dans une hiérarchie proviennent seulement en partie de la Table T002, qui spécifie les opérants OLYMPIC. Il y a également la nécessité d’inclure des centres de profits / coûts. Par exemple, il pourrait être nécessaire d’avoir l’entité « Back office titres », qui n’est pas un opérant.

Pour couvrir ce besoin, une table de centres de profits / coûts est spécifiée parmi les tables paramétriques OLYMPIC : la table T178 définie en ID-SPR.

Les champs sont les suivants

Champ Description / commentaire Format
SPR-ID Valeur 178 numérique 3
SPR-CODE La clé numérique 7
SPR-ETAT A = annulé alpha 1
SPR-DATOUV Date de création alpha 6
SPR-DATMUT Date de mutation alpha 6
SPR-OPERANT Opérant numérique 7
SPR-DES Désignation. Champ répétitif, 4 champs pour 4 langues alpha 35

Cette table appartient au domaine CTA – la comptabilité, comme il s’agit d’une base pour la comptabilité analytique.

Les centres et groupes de gestion et autres unités organisationnelles déjà spécifiés dans la Table T002 ne sont pas entrés à nouveau dans cette table.


 Synthèse des tables T002 et T178

Lors de l’utilisation des entrées de la table d’opérants et la table des centres de profits / coûts, une synthèse des deux tables est construite. Les entrées provenant de la T178 ont leur identifiants majorés de 10’000’000 afin d’assurer qu’il n’y a pas de doublons entre les deux tables.


 Construction d’une hiérarchie

 Principes

La création d’une hiérarchie organisationnelle passe par les étapes suivantes :

  • Spécification des vues qui sont significatives pour la banque : par exemple une vue par succursale et hiérarchie de responsabilité directe et une vue d’organisation par métier, tout succursale confondu.
  • Spécification des hiérarchies disponibles. Chaque hiérarchie porte les attributs suivants :
  • La vue qui s’applique. Celle-ci est sélectionnée de l’inventaire des vues.
  • La date à partir de laquelle la hiérarchie est active.
  • L’état de l’hiérarchie.
  • Pour une hiérarchie disponible, spécification de chaque unité qui y participe. Cette spécification se fait en sélectionnant une entrée sur un écran déroulant la synthèse des tables T002 et T178. Les attributs suivants sont spécifiés pour chaque unité :
  • Niveau de l’unité dans la hiérarchie – une valeur de 0 à 7, 7 étant le niveau le plus haut, celui de la banque lui-même.
  • Le nom de l’unité à utiliser dans l’exploitation de l’hiérarchie, si ce nom est différent de l’entrée dans la table T002 ou T178.
  • L’unité parent. Cette spécification se fait en sélectionnant une entrée sur un écran déroulant la synthèse des tables T002 et T178.
  • Génération automatique de l’hiérarchie complète.

 Fichiers concernant la structure organisationnelle

Nom de fichier Descriptif Emplacement
FDBIHD Définition des hiérarchies organisationnelles Bibliothèque OLYMPIC
FDBIVU Vues d’hiérarchies Bibliothèque OLYMPIC
DORG Structure Bibliothèque BEX

 Hiérarchies dispo'''n'''''''ibles

L’attribution d’un identifiant à une hiérarchie permet, par exemple, la copie de la structure détaillée assignée à une hiérarchie et son utilisation comme base, à modifier, pour une autre.

L’état de l’hiérarchie. Ceci permet d’annuler une hiérarchie au niveau global et de désactiver en conséquence la structure détaillée assignée.

 Procédure de construction

Les étapes suivantes sont présentes dans la construction de la structure détaillée d’une hiérarchie :

Cas 1. La hiérarchie d’intérêt n’a pas encore de structure détaillée.

  • La hiérarchie d’intérêt est sélectionnée dans le fichier de définition des hiérarchies organisationnelles, selon la vue et la date applicables, cette sélection se faisant moyennant un écran qui affiche les entrées saisies dans ce fichier.
  • La possibilité est offerte de copier la structure détaillée attribuée à une autre hiérarchie comme base, à modifier. Cette copie se fait moyennant un écran qui affiche les hiérarchies qui sont présentes dans le fichier de contenu des hiérarchies organisationnelles.
  • Les nouvelles entrées sont ajoutées successivement dans la hiérarchie, en spécifiant l’information suivante.

Afin de construire une hiérarchie, il est nécessaire d’avoir l’information suivante pour chaque unité qui participe dans l’organisation :

Champ Description
Code niveau hiérarchique Position de l’unité dans la hiérarchie de la banque. 7 = le niveau le plus élevé – celui de la banque lui-même.
Responsable Supérieur hiérarchique de l’unité ; se réfère à une entrée dans la Table 002 ou la table 178.
Pour l’unité au niveau 7, la valeur est nul.
  • Un membre existant de la hiérarchie peut être modifié

Si un niveau hiérarchique est inoccupé, il est rempli avec le premier niveau supérieur présent, afin de permettre un drill-down cohérent par Business Objects.

 Responsables

Les mouvements de charges et produits sont imputables à un centre de charges / produits qui se trouve à n’importe quel niveau hiérarchique de la banque.

Exploitation des structures hiérarchiques

 Noms des opérants

Dans le cas où un opérant change de nom, par exemple lors du mariage d’une collaboratrice, la version courante est utilisée même dans les rapports qui traitent l’information historique.

 Vue logique des structures

Une vue logique du fichier des structures, créée dans le datamart, met à la disposition des utilisateurs le descriptif libre des noms d’opérants associés avec leurs identifiants.

 Interface utilisateurs

Les structures peuvent être visionnées en mode hiérarchique car autrement leur visibilité n’est pas suffisamment claire.

 Objets de l’univers BEX

L’univers contient les noms des unités dans les hiérarchies de la banque et leur identifiants numériques. Les identifiants numériques sont utiles pour les raisons suivantes :

  • Le reporting de postes dont les numéros d’unités ont été réassignés à d’autres collaborateurs – p.e. certaines banques réutilisent l’identifiant d’un gestionnaire qui quitte l’établissement pour son remplaçant, à la place de modifier l’identifiant de gestionnaire de ses clients dans le fichier client.
  • La jointure avec des attributs des unités.

Plages de temps

Chaque enregistrement de structure est identifié par une date de début et une date de fin de validité.

Maintenance des plages de temps

 Création d’enregistrements

Si la fin de validité n’est pas connue au moment de la création de l’enregistrement, la date de fin prend la valeur « High value ». Cette date de fin est mise à jour lors de la création ultérieure de l’enregistrement qui le suit dans le temps, en prenant la valeur de la date de début de ce dernier moins 1 jour.

 Insertion et mise à jour d’enregistrements

Si un enregistrement est inséré dans une suite d’enregistrements comme correction, sa date de fin et la date de fin de l’enregistrement précédent sont adaptées pour créer une suite continue de plages de temps.

Mouvements

Types de mouvements

Le code Processing Type dans les mouvements p&l BEX indique les ensembles de mouvements suivants :

Ensembles de mouvements Processing Type
Intérêts sur contrats
Conditions de sélection :
Le champ origine dans le mouvement a la valeur 1.
Les contrats ne sont pas liquidés ou ont été liquidés dans la période en cours de traitement (p.e. le mois écoulé).
B
Mouvements p&l à éclater par centres.: base de détermination – une table de ventilation par centre. Les identifiants sont le genre et rubrique de compte (et d’autres champs dans une deuxième phase). H
Intérêts sur comptes : provenant de FDBJOU E
DDG, CDG courus I
Fonds interne F
Fonds externe G
Mouvement p&l externe, non fonds, provenant de OUTCDG O
Divers p&l : autres que les sources ci-dessus. X

Origine de mouvments OLYMPIC

Le provenance des enregistrements dans le fichier de mouvements OLYMPIC FDBMVT est indiqué par le code origine MVORIO, ou MVT-ORIGINE-OPE. Ce code est repris dans les fichiers de mouvements BEX, DMVT et ses agrégés, ’ORIGINE’ et dans les fichiers d’écritures p&l DPPC, DPPC0E et ses agrégés, ’TRANSACTION_ORIGINE’.

VALEUR du champ ORIGINE DOMAINE
0 Génération automatique,
p.e. nivellement de compte
1 Contrats de trésorerie
2 Fiduciaires
3 Changes
5 Titres
6 Coupons
7 Transferts
8 Transferts multiples
B Bouclement de comptes

Classes de mouvements

Les mouvements qui passent à travers le système de comptabilité analytique doivent être distingués pour les objectifs suivants :

Identifier l’ensemble de mouvements qui correspondent à la comptabilité analytique afin de pouvoir les analyser, en écartant les mouvements à l’origine de mouvements ventilés.

Vérifier les procédures de ventilation.

L’introduction de classes de mouvements permet la réalisation de ces objectifs, comme sera indiquée plus loin. Les classes sont :

Classe Signification
  Notes : le terme ventilation utilisé pour les classes concerne la ventilation selon les tables de ventilation de centres et la ventilation fonds pro-rata
0 Un mouvement en entrée à la comptabilité analytique ou en cours de traitement qui pourrait encore être ventilé.
1 Un mouvement à la comptabilité analytique qui n’est pas ventilé. Les parties éclatées, pour la trésorerie et le centre de gestion, d’intérêts sur contrats portent chacune la classe 1
2 Un mouvement qui est à l’origine d’une ventilation. Ce mouvement est conservé pour la piste d’audit. Il est ignoré dans l’ensemble de données actif de la comptabilité analytique.
3 Un mouvement qui est le résultat d’une ventilation.

Ainsi, pour vérifier que le système de ventilation est correct, les mouvements en entrée qui sont à l’origine d’une ventilation sont stockés dans le pool global de la comptabilité analytique. Ces mouvements sont assignés une classe 2. Les mouvements qui sont le résultat des ventilations portent une classe 3.

Les mouvements qui ne sont pas ventilés doivent également être présents dans le pool global de la comptabilité analytique et ces mouvements sont assignés une classe 1.

A la fin des ventilations, il n’y aura plus de mouvements de classe 0.

Codes d’opération

Cas particuliers dans FDBOPB et DMVT

 Changes

Origine = 3

Le champ OPB-TRN-CODE porte la valeur du champ FDBLOD/CHG-CODEOPE concaténée avec la valeur du champ FDBLOD/CHG-GENRE (exemple: VCT810)

 Titres

Origine = 5

Si OPB-TRN-CODE = ’120’, remplacer par la valeur du champ MVT-CODE-OPE-BOURSE (si <> "")

 Coupons

Origine = 6

Si OPB-TRN-CODE = ’190’, remplacer par la valeur du champ MVT-CODE-OPE-BOURSE (si <> "")

 Account Closing

Origine = B

OPB-TRN-CODE=’999’

En cas de traitement par BEX d’une situation d’erreur où si un mouvement n’a pas une entrée dans un log, les codes de transaction ci-dessous sont générés, accompagnés par les libellés indiqués :

TRN_
ORIGIN
TRN_
CODE
TRN_DESC Commentaire
0 000 #AUTOMATIC ENTRY#
 
0 NA0 #AUTOMATIC ENTRY#
Voir le note NAx ci-dessous
0 NAM #AUTOMATIC ENTRY#
Voir le note NAM ci-dessous
1 NA1 #AUTOMATIC ENTRY#
Voir le note NAx ci-dessous
1 NAM #AUTOMATIC ENTRY#
Voir le note NAM ci-dessous
2 NA2 #AUTOMATIC ENTRY#
Voir le note NAx ci-dessous
2 NAM #AUTOMATIC ENTRY#
Voir le note NAM ci-dessous
3 NA3 #AUTOMATIC ENTRY#
Voir le note NAx ci-dessous
3 NAM #AUTOMATIC ENTRY#
Voir le note NAM ci-dessous
5 NA5 #AUTOMATIC ENTRY#
Voir le note NAx ci-dessous
5 NAM #AUTOMATIC ENTRY#
Voir le note NAM ci-dessous
5 OUT #FUNDS# (utilisé dans OUTCDG)
Voir le note NAx ci-dessous
6 NA6 #AUTOMATIC ENTRY#
Voir le note NAx ci-dessous
6 NAM #AUTOMATIC ENTRY#
Voir le note NAM ci-dessous
7 NA7 #AUTOMATIC ENTRY#
Voir le note NAx ci-dessous
7 NAM #AUTOMATIC ENTRY#
Voir le note NAM ci-dessous
B 999 #ACCOUNT CLOSING#
(paramètre à créer dans BEXTAB)
 
B NAM #AUTOMATIC ENTRY#
Voir le note NAM ci-dessous
Z INC #ACCOUNT_INT#
 
Z INT #CONTRACT_INT#
 
Z NAM #AUTOMATIC ENTRY#
Voir le note NAM ci-dessous
Z OUT #EXTERNAL#
(paramètre à créer dans BEXTAB, utilisé dans OUTCDG)
 

Note NAM : NAM est attribué pour les enregistrements qui restent dans DPPC sans enrichissement et extraction vers DPPC0E. Ces enregistrements sont ensuite placés dans DPPC0E avec des valeurs par défaut, dont NAM pour le code d’opération.

Note NAx : NA1 à NA7 sont attribués pour les enregistrements dans DPPC qui n’ont pas d’entrées correspondants dans un fichier log. Ces enregistrements sont enrichi avec des valeurs par défaut dont NA1 à NA 7 pour le code d’opération et ensuite placés dans DPPC0E.

Conversion monetaire de montants

Modification du fichier OLYMPIC FDBOPB pour les taux de change en monnaie locale. Utilisation du champ OPCHGL (OPB-LC-CHGMLOC) à la place du champ OPSPOT (OPB-SPOT-FRX-SYST) qui contient le cours de change spot de l’opération OLYMPIC.

 Conversion de monnaie d’origine en monnaie locale

La conversion est erronée dans FDBMVT

A noter - la modification effectuée selon ERIGVA-230134 V2-1, voir "Sharebank:\ERIGVA\GAPS\2003\ERI 230134 V2-1.doc"

Le programme ASVMVT qui convertit le montant du mouvement (MVT-MONNAIET) en monnaie locale (MVMLOC) dans le champ MVCMTL est faux (cf INT ERI 230146).

Par conséquence BEX ne se base plus sur le montant contre-valeur en monnaie locale du fichier FDBMVT, mais effectue lui-même la conversion en monnaie locale.

La même logique est utilisée dans tous les programmes BEX qui effectuent une conversion d’une monnaie en une autre. Il s’agit de l’AS6796 qui lit FDBJOU et qui écrit dans FDBJOT les montants convertis en monnaie locale; et de l’AS6797 qui lit FDBRBC et qui écrit dans FDBRBD les montants convertis en monnaie locale.

La conversion doit se faire selon les règles suivantes:

1. Recherche de la monnaie locale associée au centre de la racine du mouvement en tenant compte du multi-centre (T910) et non seulement ID-SFR.

2. Recherche du cours de change moyen bilan du jour de comptabilisation (date_système) entre la monnaie du compte et la monnaie locale identifiée en 1.

3. Calculer le montant en contre-valeur monnaie locale en appliquant le cours de change trouvé en 2. au montant du mouvement et stocker le cours de change utilisé.

1. Recherche de la monnaie locale

La définition de la monnaie locale doit se faire sur la base des règles suivantes:

A. Test si recherche par centre ou monnaie locale unique:

Si le switch STD-ID-PAR-CENTRE (T900/999/L1/P1) est activé alors recherche par centre:

Table 900 TABLE TECHNIQUE NO 1

Référence 999

E Datcre Datmut Opérant

010193 050803 0010009

Désignation

YNNPNYY YAYNYI NYYBYGYY0NNYYN L1

NYYNN999999YY1YY N YN66YN L2

12Y10 YY YNN01 YYYYC999YYYNYLNYNYYN L3

NNYYYN66NYYNYYNYNNYAY 266Y---Y99YN L4

Sinon recherche par monnaie locale unique:


B.1. Si recherche par centre: La monnaie locale correspond à la monnaie du centre rattachée à la racine du montant à convertir. Exemple dans FDBMVT: racine = MVRACI= ’0000500’.


CARACTERISTIQUES CLIENT NO 0000500 E Datouv Datmut Datann Mut Opérant

Société no 0000000 301201 061202 000000 001 0010009

Type de client I INTERNE Agent 1 CENTRE 1 GENEVE

Etat civil Centre 1 CENTRE 1 GENEVE

Langue 1 FRANCAIS Groupe Ges 500 GESTION SUISSE

Intitulé 000 E-Mail Y N Y Gérant 1 OLY1 1

Nom (Raison 1) GROUPE DE GESTION 1 (GE) Gérant 2

Prénom (Raison 2) Gérant 3

Origine Groupe clients

Nom court GESTION 1 (GE)

Nationalité 756 SUISSE Domiciliation Y N Assujetti TVA N

La monnaie et la table des cours sont trouvées dans la table des caractéristiques des centres (dans notre exemple T910) :


Table 910 DEFINITION DES CARACTERISTIQUES DES CENTRES -SUITE T911-

Centre 0000001

E Datouv Datmut Nbrmut Opérant

010193 300403 000027 0010009

Désignation CENTRE 1 GENEVE

Type d’entité 1 (1-Siège 2-Succursale 3-Filiale 4-Externe) Pays 756 Langue 1

Entité juridique 0000001 Groupe comptable (même pays même entité) 0000001

Identificateurs des tables

Monnaie de base 756 Comm/frais opérations 024 Tarifs courtage 315

Cours de changes 041 Comm/frais fiduciaires 036 Tarifs timbre / taxes 620

Correspondants STD 017 Comm/frais de clôture 045 Frais corr. et autres 315

Cours fiscaux 043 Décompte de bourse 670 Impôt par pays 020

ID-CDG 695 ID-CGG 694 ID-CGE 696 ID-TFO 752 ID-NOP 701


B.2. Si recherche par monnaie locale unique:
La monnaie locale est égale à ID-SFR (T900/002/L3/P18-20);

La table des cours de change est égale à ID-CRS (T900/001/L2/P29-31)

2. Recherche du cours de change

La recherche du cours de change à appliquer doit se faire sur la base des règles suivantes:

  • Lecture du code monnaie du montant à convertir (ex. FDBMVT = MVT-MONNAIE), ainsi que la date_système du mouvement (ex. FDBMVT = MVDTSY)

RACINE DATE SYSTEME MONNAIE MONTANT

0000500 20031020 001 3,283.50

Si la Monnaie du mouvement = Monnaie locale
Alors cours de change = 1
Sinon procéder à la lecture du cours bilan moyen historique (date du mouvement).

  • Lecture du cours bilan moyen valable en date du 20/10/2003 dans la table des cours de change historique.

Table 041 COURS DE CHANGE **GENEVE - LAUSANNE**

Monnaie 001 Terme 00 Place

B A N Q U E C L I E N T B I L A N

Achat Vente Achat Vente Moyen

Convention A

DEVISES 00001 535000 00001 545000 00001 520000 00001 560000 00001 540000

BILLETS 00001 520000 00001 560000 00001 505000 00001 575000 00001 540000

CHEQUES 00001 520000 00001 560000 00001 505000 00001 575000 00001 540000

Convention B

DEVISES 00001 525000 00001 555000

BILLETS 00001 505000 00001 575000

3. Calcul du montant en contre-valeur monnaie locale

Effectuer le calcul avec les paramètres définis en 1. et 2., et le facteur qualifiant le cours "Multiplicateur" ou "Diviseur" :

Exemple avec facteur "M":

MVT-MONNAIE=’001’ Monnaie locale=’756’ MVT-MONNAIET= 3283.50 Cours de change= 1.54

Montant en monnaie locale = arrondi (3283.50 * 1.54) = arrondi(5056.59)

L’ensemble de ces données est à stocker dans le résultat afin de pouvoir reconstituer le calcul.

Les modifications apportées sont distinguées par programme:

AS6795: Lecture de FDBMVT et création de FDBPLB

1. Conversion en monnaie locale selon règles 1. à 3. spécifiées :

  • Les champs en entrée sont :
  • MVT-RACINE pour la recherche du centre et de la monnaie locale
  • MVT-MONNAIE pour la monnaie du montant à convertir
  • MVT-MONTANT pour le montant à convertir
  • Les champs en sortie sont :
  • PLB-MONLOC = code monnaie locale
  • PLB-MONTANT-MLOC = MVT-MONTANT convertit en monnaie locale
  • PLB-PP-CHGMCPT = cours de change utilisé pour conversion en monnaie locale

2. Conversion du montant d’origine exprimé en monnaie du compte P&L (PLB-MONTANT-MPP) en monnaie de la contrepartie client:

  • PLB-MONTANT-ORIG pour stocker la valeur de MVT-MONTANT (afin de garder une trace de ce montant avant conversion pour reprise éventuelle)
  • PLB-MLOC-CHGMCPT pour stocker le cours de change appliqué entre la monnaie de la contrepartie client (MVT-CONMON) et la monnaie locale du centre (PLB-MONLOC) défini en 1.
  • Appliquer la règle de calcul suivante pour le nouveau champ PLB-MLOC-CHGMCPT:
  • SI PLB-MONLOC = MVT-CONMON ALORS PLB-MLOC-CHGMCPT = 1
  • SINON mettre le cours bilan historique entre PLB-MONLOC et MVT-CONMON (sous sa forme multiplicateur) dans PLB-MLOC-CHGMCPT
  • SI, et seulement SI le cours bilan n’est pas trouvé, ALORS calculer le cours par la formule PLB-MONTANT-MPP / PLB-MONTANT-MLOC (la perte de précision du aux montants arrondis se répercutera alors sur le calcul des montants de refinancement en monnaie locale)

Intérêts

Intérêt sur comptes

Le résumé ce trouve ici dessous ; les détails sont dans le document «Sharebank:\ERIGVA\GAPS\2003\230068_v1.doc »

 Paramétrage OLYMPIC

On suppose que les mouvements DB et CR sont distincts dans FDBMVT. Dans le cas contraire, il faut désactiver le STD-COMPTA-INTBCL-TOTAL qui comptabilise les intérêts par totalisation des débits et crédits; et modifier le paramétrage de la T035 pour les genres de compte qui utilisent les mêmes genres de compte/rubrique pour comptabiliser les intérêts DB et CR.

 Enrichissement des mouvements intérêt sur compte

Les mouvements comptables dans FDBMVT, sont enrichis avec de l’information provenant des fichiers FDBRBC pour l’intérêt sur compte et FDBJOU pour l’intérêt courus : les taux d’intérêt de base et de marge, au débit ou crédit.

Les écritures concernant l’intérêt bouclé sont extraits de FDBMVT, enregistrés dans FDBPLB et ensuite dans DPPC0E.

Les mouvements donnant les détails concernant l’intérêt bouclé, contenus dans le fichier OLYMPIC FDBRBC, sont copiés dans le fichier FDBRBD, où ils sont sauvegardés. Ils sont ensuite extraits dans le fichier BEX TRBD.

Le refinancement se calcule de façon simple en multipliant le montant d’intérêt par le taux de refinancement et en divisant par le taux effectif. Afin de pouvoir refinancer des opérations ayant un taux effectif égal à 0%, à la place d’utiliser le taux de refinancement et le taux effectif dans un règle à trois, les valeurs du nombre d’intérêt dans FDBRBC et FDBJOU au débit ou crédit sont utilisées pour calculer le montant d’intérêt : -1 x Nombre / 360 / taux d’intérêt. On multiplie par "-1" car on se place côté banque. Un intérêt DB est un revenu et un intérêt CR une charge pour la banque.

exemple DB avec 7% TX REF 1: (-1) * -8’624 / (360 / 7)= 8’624 / 51.428 = 167.69
Les champs MVT-VREFERENCE, MVT-REFORIGINE dans FDBPLB font le lien entre les enregistrements provenant de FDBMVT et ceux provenant de FDBRBC.

 Calcule du montant de refinancement

Les nombres DB et CR des fichiers FDBRBC et FDBJOU sont utilisés pour calculer le montant de refinancement 1 et 2 au lieu de la règle de trois afin de pouvoir refinancer des opérations ayant un taux effectif égal à 0%.

  • Le cours de change de FDBMVT est utilisé pour faire la conversion en monnaie locale du montant de refinancement. Le champ dans FDBPLB PLB-MLOC-CHGMCPT sert à convertir le montant de refinancement en monnaie locale.

Intérêt courus

Values of the Accrual object in BEX:

0   = booked interest
1, 2, 3 = accrued interest.

The reason for the values 1, 2 and 3 of the accrued interest is as follows:

For treasury contracts, the accrued interest amount generated by OLYMPIC each month gives the total interest accrued since the beginning of the contract. In order to report the incremental amount which accrues each month, BEX takes the total interest accrued of the previous month and subtracts it from the total accrued interest of the current month.

BEX needs to mark the interest records with the values below in the Accrual Flag to show their different statuses:

Accrual Flag Value Significance
0 Booked interest.
1 Accrued interest of the current month, which must still be subtracted from the next month.
3 Accrued interest of the previous month, subtracted from the accrued interest of the month which follows in order to establish the net incremental accrual for the month.
In the example below, '166,920.85 is the total interest accrued in September. This has its sign changed and is placed in the month of October.
2 Accrued interest of the month, which has already been subtracted from the next month.


CATEGORY ITEM CLI_ID VAL_DATE SYS_DATE TRN_REF AMOUNT_LOC_CCY ACCRUAL_FLG
 
609 404 500 20060929 20060929 2 161,950,05- 3
609 404 500 20060929 20060929 2 166,920.85 2
 
609 404 500 20061031 20061031 2 166,920.85- 3
609 404 500 20061031 20061031 2 171,891.65 1
 

The difference between the value of 1 and 3 for the accrual flag is for security purposes, to make sure the amount isn’t subtracted again from the next month if a rerun of processing occurs. The flag is therefore set initially to 1 in the current month; only if it has the value of 1 is the reversal of the amount posted to the next month and at the same time, the value of the accrual flag in this record is set to 2.

Refinancement

En cas de besoin, les deux paramètres ci-dessous peuvent être utilises pour enregistrer les details des operations de refinancement.

REF_ACCT_LOGFILE C:\ACCT.TXT On peut spécifier le nom d’un fichier dans lequel sera écrit le détail du traitement de refinancement. Attention : à ne faire qu’avec des petits volumes !
REF_CONTRACT_LOGFILE C:\CTR.TXT On peut spécifier le nom d’un fichier dans lequel sera écrit le détail du traitement de refinancement. Attention : à ne faire qu’avec des petits volumes !

Contrats de change à terme

BCL 240035-001

Dans le cas des contrats de change à terme les champs STA-CLI-RACINE, STA-CTR-ID et STA-CTR-CONTRAT sont renseignés

Calcul de soldes moyens

Securites

Source : OLYMPIC file FDBHAU, generated each month for BEX

This file contains a record for each client, for each of his portfolios, for each security in the portfolio, and for each day of the month.

The stock price applicable for each day is retrieved from the securities history file FDHVAL and multiplied by the position quantity. If the option of the program to convert to the bank’s currency is set, the exchange rate applicable for each day is retrieved and the daily balance is converted to the bank’s currency.

Cash Accounts

Source : OLYMPIC file FDBCPP

The account balance for each account is recorded by OLYMPIC during the End of Day procedure in the file FDBCPP. This processing is dependent on the relevant switch being set. At month’s end, BEX calculates the average balance from the daily values recorded for the month.

Remisiers

Intégration des rétrocessions aux remisiers dans BEX

Granularité des mouvements de rétrocessions : pour chaque remisier, par période d’évaluation, par client du remisier et par type d’opération tel que spécifié dans la Table 716 – « Groupes d’opérations pour les remisiers ».

Piste d’audit

Les mouvements de rétrocession côté banque répliqués dans BEX pour chaque période traitée sont neutralisés - ces mouvements sont remplacés par des écritures de détail au niveau des clients du remisier dans le fichier de mouvements p&l de BEX. Les écritures neutralisées restent accessibles pour la piste d’audit par l’univers BEX de contrôle.

Spécification du remisier

Chaque remisier rattaché au client concerné dans les fichiers client de BEX : DCLI0E et CLI_HP.

 Champs contenant le remisier

Nom Descriptif Format Long. Commentaire
INTERMED_AGENT_ID N° du remisier Num. 7 Intermediate Agent Id
INTERMED AGENT Nom du remisier Char. 35 Le nom est obtenu du fichier client lui-même, où un enregistrement pour le remisier se trouve toujours.

 Fichier source

FDBCRM

CLIENT DATE DU SEQUENCE STATUS DATE OUVERTURE DATE MUTATION DATE ANNULATION NOMBRE MUTATION OPERANT REMISIER
10,038 20,050,101 0 270505 270505 1 11,038 13,038
11,038 20,050,101 0 270505 270505 1 11,038 13,038
12,038 20,050,101 0 270505 270505 1 11,038 13,038
10,030 20,050,101 0 030605 0 10,038 13,038

Le remisier est ajouté aux fichiers client dans un nouveau champ.

Ecritures de rétrocession

 Situation actuelle

Dans FDBMVT, il y a un ensemble d’enregistrements pour les rétrocessions au remisier (voir l’ensemble 1 ci-dessous) et un deuxième ensemble d’enregistrements au débit de la banque en contrepartie (voir l’ensemble 2 ci-dessous). Dans ces enregistrements, pour un remisier et pour un type d’opération, toutes les écritures pour les multiples clients du remisier sont regroupées dans un seul enregistrement. Actuellement, il y a ces mêmes enregistrements dans le datamart BEX, dans DPPC0E.

RACINE GENRE RUBRIQUE MONNAIE RACINE CON. GENRE CON. RUBRIQUE CON. MONNAIE CON. CONTREVALEUR MLOC
1
0013038 718 001 756 0000001 719 001 756 30.50
0013038 718 003 756 0000001 719 003 756 4.75
0013038 718 004 756 0000001 719 004 756 317.50
0013038 718 011 756 0000001 719 011 756 16,744.95
 
2
0000001 719 001 756 0013038 718 001 756 30.50-
0000001 719 003 756 0013038 718 003 756 4.75-
0000001 719 004 756 0013038 718 004 756 317.50-
0000001 719 011 756 0013038 718 011 756 16,744.95-

 Modification de la situation actuelle

Il est nécessaire de retravailler les enregistrements en débit de la banque :

1. Remplacement de l’enregistrement unique par rubrique qui consolide les rétrocessions pour tous les clients du remisier, par un enregistrement par rubrique pour chaque client du remisier.

2. Adjonction des attributs standard de BEX pour les écritures p&l, tels que le produit et le type transaction concernés.

Il n’est pas nécessaire d’agir comme pour le refinancement d’instruments portant d’intérêt en créant des écritures pour le remisier au débit du gestionnaire. Les débits de la banque sont déjà dans la comptabilité financière et il est seulement nécessaire de les éclater sur la base d’un fichier qui donne les détails des rétrocessions.

 Fichier source pour les détails des rétrocessions

Utilisation du fichier FDHRMC qui contient les enregistrements suivants pour les rétrocessions : 1 enregistrement par remisier, par client du remisier et par type d’opération – voir l’exemple ci-dessous.

REMISIER GENRE RUBRIQUE MONNAIE MONTANT RETROCEDE TYPE OPERATION CLIENT FIN PERIODE TRAITEE
13,038 718 1 756 30.50 10 0000000 20050527
13,038 718 3 756 4.75 30 0000000 20050527
13,038 718 4 756 317.50 40 0000000 20050527
13,038 718 11 756 16,744.95 98 0000000 20050527

Il faut noter qu’afin de renseigner le no. de client dans ce fichier FDHRMC, il faut enclencher le switch STD-REM-COMPTA-DETCLI :

Table 900 Elément 004 ligne 4 position 10 = Y

Note : il y a des écritures supplémentaires pour le remisiers provenant de la banque qui sont ensuite déversées dans le compte ayant le rubrique global 999, spécifié dans T716

0013038 718 999 756 0013038 718 001 756 30.50
0013038 718 001 756 0013038 718 999 756 30.50-
0013038 718 003 756 0013038 718 999 756 4.75-
0013038 718 999 756 0013038 718 003 756 4.75
0013038 718 004 756 0013038 718 999 756 317.50-
0013038 718 011 756 0013038 718 999 756 16,744.95-
0013038 718 999 756 0013038 718 004 756 317.50
0013038 718 999 756 0013038 718 011 756 16,744.95

 Neutralisation des écritures de rétrocession côté banque

Il est nécessaire de neutraliser les mouvements de rétrocession côté banque répliqués dans BEX pour chaque période traitée. En effet ces mouvements sont remplacés par des écritures dans le fichier de mouvements p&l, DPPC0E, dérivées du fichier FDHRMC

Il est essentiel que le genre de compte spécifié dans l’ID ID-TREMDB soit utilisé uniquement pour les rétrocessions débitées à la banque. Sinon il est impossible de neutraliser les écritures de rétrocession du côté de la banque.

Pour les détails du développement, voir Sharebank:\ERIGVA\GAPS\2005\250209

Information au niveau du portefeuille

The following has been developed for CBK under the ERIFlow CBK-260050, and can be applied to other clients.

A code and its description is added to the Client folder in the BEX universe for each of the following Client attributes specified in portfolio 000:

  • Charges Type (Spesenart).
  • Specific Rate (Spezialtarif)

The screen display below gives ringed examples of these attributes as present in OLYMPIC.

Insert Charges Type - Specific Rate.gif

The information is dated and recorded in the database, so that attributes applicable at a past date are applied to the data values concerning the past period.

The object names in the BEX universe are as follows:

Attribute Description object name Code object name
Charges Type (Spesenart) Charges Type Chrge. Type Code
Specific Rate (Spezialtarif) Specific Rate Spec. Rate Code

In the cases where no Charges Type or Specific Rate information is given for a client, the values below are assigned:

Object Value
Chrge. Type Code 999
Charges Type N/A (not applicable)
Spec. Rate Code ZZZZZZ
Specific Rate N/A (not applicable)

Opérations

Redonner les droits aux utilisateurs

ERIGVA-240223-000

Création d’un script d’exemple qui permet d’attribuer les droits pour tous les objets d’une librairie donné.

Ce script n’a qu’une valeur d’exemple, il doit être modifié en fonction du client. La commande RTVCLSRC doit être autorisé chez le client.

Ce script créé redonne les droits aux les utilisateurs finaux du Datamart,

Ce script pourra être rajouté à la fin des procédures de réplication (BEXREP, BEXHEBDO, ou autres). Ceci sert uniquement si le Datamart se trouve sur DB2

Reprises

 Reprise des données historiques

Procédure de reprise des données historiques OLYMPIC pour alimenter BEX lors de son installation.

Deux nouveaux CLs ont été mis au point:

BEXHIST01: permet d’alimenter la table DPPC0E et ses agrégats à partir du fichier FDBPLB qui aura été préalablement chargé avec l’historique voulu (CL AS917503 permettant de donner un intervalle de date pour la génération de FDBPLB). Les courus ne sont pas repris dans cette procédure.

BEXHIST02: permet de répliquer les positions (FDBPOP) et les mouvements (FDBOPB). Les capitaux moyens ne sont pas repris dans cette procédure. Un passage par mois est nécessaire avec changement dans BEXTAB des paramètres correspondant à chaque fois.

 Reprise d’un mois de soldes moyens titres

Si on a dépassé le 15 du mois suivant (ERIGVA-240230-000)

BEX utilise le CL AS629507 (lancement en mode batch de l’AS6295) pour renseigner le fichier FDBHAU avec les positions titres par jour par client du mois écoulé.

Le CL AS629507 définit le SWS = 0000010 afin d’activer l’upsi 6 : OPT-BATCH-MENS.

Cet upsi 6 permet de définir automatiquement les paramètres de sélection sans passer par un écran. La période à prendre en compte fait partie de ces paramètres. Elle est définie sur la base de la date système. Un test sur le jour permet de lancer le programme jusqu’au 14 du mois suivant pour générer les positions du mois.

Exemple :

  • Date Système = 14.6.04 -> génération du mois de mai 2004
  • Date Système = 15.6.04 -> génération du mois de juin 2004

Problème :

Comment faire une reprise d’un mois donné si on a dépassé le 15 du mois suivant tout en gardant les initialisations des paramètres effectués au travers de l’upsi OPT-BATCH-MENS ?

Solution

Modifier le programme afin qu’il puisse lire la JOBD. Il serait alors possible de faire un submit job en changeant la JOB DATE

SBMJOB CMD(CALL PGM(AS629507)) JOB(AS629507) DATE(310504)

Et que la période de sélection soit définie non plus sur la base de la date système de la machine, mais sur la job date (dans l’ exemple le mois de mai 2004 bien que la date système soit égale au 22 juin 2004).

Also on Fandom

Random wikia