Op.europa.eu
[pic]
GENERAL INVITATION TO TENDER
No 10203
Maintenance and software development of the GESCOMX-SAGAPX-DWH/PUBLICATIONS system and related services
SPECIFICATIONS
CONTENTS
1. Preliminary information concerning the invitation to tender 5
1.1. Presentation of the Publications Office 5
1.2. Nature of the contract 5
1.3. Subject and background of the contract 6
1.4. Starting date of the contract and duration of the tasks/contract 6
1.5. Price 6
1.6. Terms of payment 6
1.7. Financial Guarantees 6
1.8. Place of performance 7
1.9. General terms and conditions for the submission of tenders 7
1.10. Period of validity of the tender 7
1.11. Visit to the premises 7
1.12. Date and place of opening of the tenders 7
2. The tender and the evaluation 8
2.1. Assessment and award of contract 8
2.2. Form and content of the tender 8
2.3. Structure of the tender 9
2.4. Section one: administrative information 9
2.5. Section two: exclusion criteria 10
2.5.1. Documents relating to the exclusion criteria 10
2.5.2. Grounds for exclusion 11
2.5.3. Administrative and financial penalties 11
2.6. Section three: selection criteria 12
2.6.1. Financial and economic capacity of the tenderer 12
2.6.2. Technical and professional capacity of the tenderer 13
2.7. Section four: award criteria – technical bid 14
2.7.1. Documents to provide concerning the technical award criteria 14
2.7.2. Evaluation of the technical award criteria 14
2.8. Section five: award criteria – financial bid 15
2.8.1. Documents to provide relating to the financial award criteria 15
2.8.2. Evaluation of the financial award criteria 16
2.9. Final evaluation 16
2.10. Information for tenderers 16
2.11. Award of the contract 17
3. Joint bid and subcontracting 18
3.1. Making a bid in collaboration with other companies 18
3.1.1. Joint bid 18
3.1.2. Subcontracting 18
3.2. Documents to submit – joint bid 19
3.3. Documents to submit – subcontracting 20
3.4. Evaluation of the bids in case of joint bids or subcontracting 21
3.4.1. Exclusion criteria 21
3.4.2. Selection criteria 21
3.4.3. Award criteria 21
4. Technical specifications 22
4.1. Subject of the call for tender 22
4.2. Working methods and general constraints 27
4.2.1. Introduction 27
4.2.2. Working methods 27
4.2.3. Fixed price services 28
4.2.4. Time and means Orders 30
4.2.5. Staff replacement (only in case of Time and Means) 31
4.2.6. Contractual transition periods 31
4.2.7. General constraints 33
4.3. Service Level Agreement 33
4.4. Profile description 37
4.5. Acronyms 41
5. Annexes 42
Annex 1 Price Schedule and Estimation Form 43
Annex 2A financial identification form 44
Annex 2B Legal Entity Form 44
Annex 2C Agreement / Power of attorney 45
Annex 3 Form for identification of the tenderer 47
Annex 4 questionnaire for joint bids and subcontracting 49
Annex 5 list of documents to be provided in the tender 51
Annex 6 declaration on the grounds for exclusion 53
Annex 7 Economic and financial capacity questionnaire 55
Annex 8 Company Form 57
Annex 9 Project / activity reference forms ( PARFs) 59
Annex 10 Best practice documents 63
Annex 11 Quality expectations and service proposals 65
Annex 12 Technical environment and standard operating procedures of the Publications Office 71
12.1. Purpose of the document 71
12.2. Disclaimer 71
12.3. Technical environment of the Office 71
Appendix A: Current backup policy and procedures 77
Appendix B: Standard file system organization on Unix systems (directory structure) 79
Annex 13 Security Requirements 82
13.1. Introduction 82
13.2. Application level security 85
13.3. Logical access control 91
13.4. Network level security 93
13.5. System level security 93
13.6. Test, development and acceptance 94
13.7. Communications and operations 95
13.8. Physical security 95
Annex 14 Provisional/Final (end of guarantee) Acceptance Note 100
Annex 15 GESCOMX description 101
15.1 Introduction 101
15.2 Description of GESCOMX 101
15.3 Management of global data 102
15.3.1 The "administrative entity" 102
15.3.2 Management of user profiles 103
15.3.3 Tracking of operations 103
15.3.4 Management of items 103
15.3.5 Management of customers 105
15.3.6 Management of orders 106
15.3.7 Management of invoices 108
15.3.8 Management of stocks 110
15.4 Description of the interfaces 113
15.4.1 Schema of the interfaces (status as of 2008) 113
15.4.2 List of interfaces 113
15.5 The Data of GESCOMX 122
15.5.1 Overview 122
15.5.2 Reference data 122
15.5.3 Living items 122
15.5.4 Items with minimal data 123
15.5.5 Stock of items 123
15.5.6 Archived copies 123
15.5.7 Customers 123
15.5.8 Other data 124
15.6 List of interactive/batch functions of GESCOMX (as of 2008) 125
15.7 Interactive functions of GESCOMX 125
15.8 Batches of GESCOMX 140
Annex 16 SAGAPX description 143
16.1 Functions of SAGAPX lot 1 143
16.1.1 Addresses management 143
16.1.2 Mailing lists management 143
16.1.3 Subscriptions management 143
16.1.4 Invoicing of subscriptions 143
16.1.5 Label creation 143
16.2 Functions of SAGAPX lot 2 144
16.2.1 The creation of a distribution dossier 144
16.2.2 The calculation of the distribution costs 144
16.2.3 Simplified stock management 145
16.2.4 Schematic of the interfaces 145
16.3 Module A: Addresses, mailing lists and subscriptions management 146
16.4 Module B: Warehouse & Orders management 147
16.4.1 Catalogue Number 147
16.4.2 Reception coding 147
16.4.3 Administrative entities 149
16.4.4 Example of an edition request: 150
16.5 Module C: Distribution actions management 151
16.5.1 Distribution Dossier 151
16.5.2 The distribution line 154
16.5.3 Screen views of the current application 155
16.5.4 Re invoicing Fee schedule 164
16.5.5 Example of a distribution price estimate 165
16.5.6 Example of the "Distribution dossiers follow up" table 167
16.5.7 Distribution Procedure 168
16.6 Module D : Sorting & Routing management 189
16.6.1 Packing modes 189
16.6.2 Sorting signals 190
16.6.3 Printers 192
16.7 Module E : Transport management 194
16.7.1 Delivery type modes 194
16.7.2 Dispatch notice sample 195
16.7.3 Delivery slip sample 196
16.8 Module F : Re-invoicing to authors management 197
16.9 Module G : Subscriptions Invoicing 199
16.9.1 VL Codes and Country Codes 199
16.9.2 Function codes 201
16.9.3 Theme codes 202
16.9.4 Requester codes / Administrative Entity Codes 204
16.9.5 Organization Codes 207
Annex 17 Description of the DWH Publications 212
17.1 Business Processes 212
17.2 Functionality of the Data Warehouse system 213
17.3 Information Retrieval 213
17.4 Technical environment and elements 213
17.5 Database size 213
17.6 Technical environment: 214
17.7 Database design 214
Preliminary information concerning the invitation to tender
These specifications follow the publication of:
- the pre-information notice in OJ S – 47 of 10/03/2009 and,
- the contract notice in OJ S, see reference in the invitation letter.
1 Presentation of the Publications Office
The Office for Official Publications of the European Communities, hereinafter referred to as “the Publications Office”, (2, rue Mercier, L-2985 Luxembourg) is the publishing house of the European institutions in the broadest sense, responsible for producing and distributing, on all media and by all means, all the publications of the European Union. The Publications Office, whose current organisation and operation are laid down by Decision 2000/459/EC, ECSC, Euratom (Official Journal of the European Communities, L 183, 22.7.2000, p. 12), is managed by a Management Committee in which each institution is represented by its Secretary-General. The Publications Office is administratively attached to the European Commission. More information can be found on the Publications Office website: .
As a publisher, the Publications Office has a duty to offer the highest quality service to its customers – the originating departments of the institutions and other bodies of the European Union and to its public – the people of the European Union and those throughout the world who are interested in European affairs. In the field of new technologies, the Publications Office must place itself in the forefront of the publishing profession.
Under the provisions of the Treaties establishing the European Communities, the publication of certain titles, such as the Official Journal of the European Union or the General Report on the Activities of the European Union, is a legal obligation.
Useful web sites
|Office for Official Publications | |
|EU-bookshop: the Union's online bookshop | |
|EUROVOC: multilingual thesaurus | |
|CORDIS: Community R&D Information Service | |
|Eur-Lex: the gateway to European Union law | |
|IDEA: inter-institutional directory of the European Union | |
|TED: supplement to the Official Journal of the European Union | |
|SIMAP: EU-information for public procurement | |
|DG MARKT: DG Internal Market | |
|Other useful links | |
2 Nature of the contract
The contract is a cascade framework service contract with the title "Maintenance and software development of the GESCOMX-SAGAPX-DWH/PUBLICATIONS system and related services".
As exact implementing conditions, quantities and/or delivery times cannot be indicated in advance, the Commission intends to conclude a framework contract, which shall establish the basic terms for a series of Order Forms ("Orders") to be issued over its duration. Framework contracts do not give rise to any direct obligation to the Commission but only their implementation through Orders is binding on the Commission.
The estimated volume of the contract is 660.000 euros for a period of its maximum duration (4 years).
3 Subject and background of the contract
The purpose of the call for tender is the selection of an economic operator for provision of the “Maintenance and software development of the GESCOMX-SAGAPX-DWH/PUBLICATIONS system and related services".
For more details on the tasks to be performed, refer to section 4 (technical specifications).
4 Starting date of the contract and duration of the tasks/contract
The Contract shall enter into force on the 6th of December 2009, if it has already been signed by both contracting parties. The execution of the tasks may not start before the contract has been signed.
The initial duration of the contract shall be 1 year. The contract may be renewed automatically up to three times, each time for one year, under the same conditions, unless written notification to the contrary is sent by one of the contracting parties by registered mail and received by the other not later than three months before its expiry. Renewal does not imply any modification or deferment of existing obligations.
5 Price
• Prices must be all inclusive and expressed in euro. For tenderers in countries which are not part of the euro zone, the price quoted may not be revised in line with exchange rate movements;
• Prices can only be revised according to Article I.3 of the contract. Please note that the price revision is conditional to a request which must be put in place at the latest three months before the anniversary date of the entry into force of the contract. In case of a justified and timely request, the revised prices shall enter into force on the anniversary date of the entry into force of the contract. The price revisions will be calculated with the same number of decimals as was accepted in the initial original Price Schedule and also the revised prices will have the same number of decimals.
For details on how to present the financial bid in the price schedule and estimation form, see: point 2.8.1.
6 Terms of payment
Payments shall be made in accordance with Article I.5 of the draft service contract.
7 Financial Guarantees
Not applicable, except in case of pre-financing exceeding 150.000 euros.
8 Place of performance
The place of performance of the tasks shall be the contractor's premises or any other place indicated in the tender. The meetings may be held at the premises of the Publications Office in Luxembourg
9 General terms and conditions for the submission of tenders
Participation in the tendering procedure is open on equal terms to all natural and legal persons coming within the scope of the treaties and to all natural and legal persons in a third country which has a special agreement with the European Communities in the field of public procurement on the conditions laid down in that agreement.
Submission of a tender implies that the tenderer accepts all the terms and conditions set out in the invitation letter, in these specifications (including the annexes) and in the draft contract and waives all other terms of business. Submission of a tender binds the tenderer to whom the contract is awarded during performance of the contract.
Once the Publications Office has accepted the tender, it shall become the property of the Publications Office and the Publications Office shall treat it confidentially.
The Publications Office shall not reimburse any costs incurred in preparing and submitting tenders.
The Protocol on the Privileges and Immunities or, where appropriate, the Vienna Convention of 24 April 1963 on Consular Relations shall apply to this invitation to tender.
10 Period of validity of the tender
The offer must remain valid for a period of 6 months following the final date for submitting tenders (see invitation letter). During this period, tenderers must maintain all the conditions of their bids.
11 Visit to the premises
Not applicable.
12 Date and place of opening of the tenders
Tenders will be opened at 10h00 on 03/08/2009 at the following location:
|Address of the Publications Office: |
|Publications Office |
|2, rue Mercier |
|L-2985 Luxembourg |
An authorised representative of each tenderer may attend the opening of the bids. Companies wishing to attend are requested to notify their intention by sending a fax or e-mail at least 48 hours in advance to the address below. This notification must be signed by an authorised officer of the tenderer and specify the name of the person who will attend the opening of the bids on the tenderer's behalf.
|Fax: (352) 2929-42672 |
|E-mail: opoce-appels-offres@publications.europa.eu |
The tender and the evaluation
1 Assessment and award of contract
The assessment of tenderers and offers will take place in three main stages:
The aims of each of these stages are:
• to check, in the first stage (exclusion criteria), whether tenderers can take part in the tendering procedure and, where applicable, be awarded the contract;
• to check, in the second stage (selection criteria), the economic and financial capacity and the technical and professional capacity of each tenderer who has passed the first stage;
• to assess, on the basis of the award criteria, each bid which has passed the first and second stages.
The assessment procedure may end with the award of the contract.
The assessment will be based on the tenderer’s offer. Concerning the exclusion and selection criteria, the Publications Office reserves the right to request additional evidence in relation to the bid submitted for clarification or verification purposes within a time-limit stipulated in its request. All the information will be assessed against the criteria specified in this chapter.
Please note that concerning the award criteria, the Publications Office can contact the tenderer only if clarification is required or if obvious clerical errors must be corrected. This contact can only lead to clarification of points already mentioned in the bid and may not lead to an alteration of the terms of the bid. Only the offers meeting the requirements of a stage will pass on to the next stage of the assessment.
2 Form and content of the tender
Tenders must be clear and concise and assembled in a coherent fashion (e.g. bound or stapled, etc.). The tenderer is also asked to provide a completed list indicating where to find the required documents (Annex 5). If the tender is divided into different files, it is advised to make a table of contents in each file.
Since tenderers will be judged on the content of their written bids, these must make it clear that they are able to meet the requirements of the specifications.
Information on the general requirements and on how to submit the bid is provided in the invitation letter.
Please pay attention to the fact, that the tender shall be signed[1] by a person or persons who is/are entitled to represent the economic operator in accordance with its articles of association and/ or extract from the commercial register, or by a person(s) who received power of attorney to do so from (a) person(s) who is/are mentioned in those documents. The documents showing that the person is entitled to represent the economic operator must be submitted as explained in point 2.4.
The same rule is applicable to the person(s) designated to sign the contract.
3 Structure of the tender
All tenders must be presented in the following five sections:
Section One: administrative information
Section Two: exclusion criteria
Section Three: selection criteria
Section Four: award criteria - technical bid
Section Five: award criteria - financial bid
Sections one to four on the one hand and Section five on the other hand must be submitted in two separate sealed envelopes, which together are placed in double sealed envelopes as described in the invitation letter. Each inner envelope must clearly indicate its contents (“technical” and “financial”).
Please observe that all documentation has to be provided in triplicate (original and two copies) and that this also applies to any diskette, CD or similar medium that is part of the offer.
4 Section one: administrative information
In the first section, the tenderer must provide the following:
• A duly signed cover letter
• the completed form for identification of the tenderer, as provided in Annex 3,
• a financial identification form filled in and signed by an authorised representative of the tenderer, stamped by the bank and signed by a bank representative. If you attach the copy of a recent bank statement, the stamp and signature of the bank's representative is not needed. A standard form is provided in Annex 2A and a specific form for each Member State is available at the following Internet address:
• the "Legal Entity" form, to be signed by a representative of the tenderer authorised to sign contracts with third parties. There is one form for individuals, one for private entities and one for public entities. A model is provided in Annex 2B. Specific forms in each Member state language are available at:
The Legal Entity Form must be supported by the following documents in order to prove the administrative information of the tenderer:
• a legible copy of the instrument of incorporation or constitution, and a copy of the statutes, if they are contained in a separate instrument, or a copy of the notices of such constitution or incorporation published in the national or other official journal, if the legislation which applies to the tenderer requires such publication;
• a legible copy of the most recent amendment to the instruments mentioned in the previous indent, including that involving any transfer of the registered office of the legal entity, or a copy of the notice published in the relevant national or other official journal of such amendment, if the legislation which applies to the tenderer requires such publication;
• if the above documents don’t show the registration number, a proof of registration, as prescribed in their country of establishment, on one of the professional or trade registers or any other official document showing the registration number;
If the most recent document submitted according to this or one of the two previous paragraphs is more then one year old at the time the offer is sent, a written confirmation, signed by a legal representative of the tenderer, that there has been no amendment or transfer of registered office since the most recent of these documents were issued must be added.
• if the above documents don’t show the VAT number, a copy of the VAT registration document, where applicable;
• a legible copy of the notice of appointment of the persons authorised to represent the tenderer in dealings with third parties and in legal proceedings, if it is not included in the abovementioned documents, or a copy of the publication of such appointment if the legislation which applies to the legal entity concerned requires such publication. If the person(s) signing the tender or the person designated to sign the contract is/are entitled to represent the economic operator by a Power of Attorney from the abovementioned authorised persons, the Power of Attorney must also be submitted;
5 Section two: exclusion criteria
1 Documents relating to the exclusion criteria
In Section Two, the tenderer(s) must provide the declaration on grounds for exclusion (Annex 6) and the following related certificates or documents:
• a recent extract from the ‘judicial record’ or equivalent as evidence that they are not in one of the situations listed in paragraph (a), (b) or (e) of point 2.5.2, or, failing this, of an equivalent recent document issued by a competent judicial or administrative authority in the country of origin or residence, showing that these requirements have been met;
• a recent certificate by the competent authorities of the state concerned stating that the tenderer has fulfilled obligations relating to the payment of social security contributions or equivalent;
• a recent certificate by the competent authorities of the state concerned stating that the tenderer has fulfilled obligations relating to the payment of taxes or equivalent.
Where no such documents or certificates are issued in the country concerned, they may be replaced by a sworn or failing that a solemn statement made by the tenderer before a judicial or administrative authority, a notary or a qualified professional body in his country of origin or provenance.
2 Grounds for exclusion
In accordance with Article 93 of the Financial Regulation No 1605/2002 (OJ L 248, page 1, of 16 September 2002, as amended), tenderers shall be excluded from the selection and award procedures if they:
a) are bankrupt or being wound up, are having their affairs administered by the courts, have entered into an arrangement with creditors, have suspended business activities, are the subject of proceedings concerning those matters, or are in any analogous situation arising from a similar procedure provided for in national legislation or regulations; or
b) have been convicted of an offence concerning their professional conduct by a judgment which has the force of res judicata; or
c) have been guilty of grave professional misconduct proven by any means which the contracting authorities can justify; or
d) have not fulfilled their obligations relating to the payment of social security contributions or the payment of taxes in accordance with the legal provisions of the country in which they are established, or with those of the country of the contracting authority or those of the country where the contract is to be performed; or
e) have been the subject of a judgment which has the force of res judicata for fraud, corruption, involvement in a criminal organisation or any other illegal activity detrimental to the Communities' financial interests; or
f) are currently subject to an administrative penalty referred to in Article 96(1) of the Financial Regulation (Council Regulation N° 1605/2002 of 25/06/2002, as amended)..
In addition, contracts may not, according to Article 94 of the Financial Regulation, be awarded to tenderers who, during the procurement procedure:
g) are subject to a conflict of interest;
h) are guilty of misrepresentation in supplying the information required by the contracting authority as a condition of participation in the contract procedure or fail to supply this information.
The Publications Office reserves the right to check the above information.
3 Administrative and financial penalties
The tenderers should also be aware of the following points:
• A central database shall be set up and operated by the Commission in compliance with Community rules on the protection of personal data. The database shall contain details of candidates and tenderers which is in one of the situations referred to in point 2.5.2 above and candidates and tenderers which have been excluded from the contracts or grants financed by the budget of the European Communities.
• According to Article 96 of the Financial Regulation No 1605/2002 (OJ L 248, page 1 of 16.9.2002, as amended), administrative or financial penalties may be imposed by the Commission on tenderers who the situation in point 2.5.2 (h) above or who have been declared to be in serious breach of their obligations under contracts covered by the budget of the European Communities after they have been given the opportunity to present their observations.
These penalties may consist:
a) in the exclusion of the tenderer or contractor concerned from contracts and grants financed by the budget of the European Communities, for a maximum period of ten years;
b) in the payment of financial penalties by the tenderer or contractor up to the value of the contract in question.
The penalties imposed will be in proportion to the importance of the contract and the seriousness of the misconduct.
The details of those penalties are laid down in Article 133a of the implementing rules to the Financial Regulation, Commission Regulation No 2342/2002 (OJ L 357, page 1 of 31 December 2002, as amended).
6 Section three: selection criteria
Selection of the tenderer suitable for attribution of the contract will be based on an assessment of the tenderer’s:
• economic and financial capacity, and
• technical and professional capacity.
A tenderer may, where appropriate, rely on the capacities of other entities, regardless of the legal nature of the links which it has with them. In that case, it must prove to the contracting authority that it will have at its disposal the resources necessary for performance of the contract, for example by producing an undertaking on the part of those entities to place those resources at its disposal.
1 Financial and economic capacity of the tenderer
1 Documents to provide concerning the financial and economic capacity
Section Three must include in its first part, the information on the financial and economic capacity of the tenderer. The tenderer shall provide Economic and Financial capacity questionnaire (see: Annex 7), including supporting documents mentioned there.
2 Evaluation of the financial and economic capacity
The tenderers’ financial and economic capacity will be evaluated on the basis of the above mentioned documents which the tenderers have to submit according to point 2.6.1.1.
The minimum financial and economic capacity level is the following: the amount representing the estimated volume of the contract for one year must not exceed 60% of the annual overall turnover carried out by the tenderer over the last year, or the average annual turnover carried out by the tenderer over the past three years. For the estimated volume of the contract for four years see the Specifications, point 1.2.
2 Technical and professional capacity of the tenderer
1 Documents to provide concerning the technical and professional capacity of the tenderer
In the second part of Section Three, the tenderer must provide information on its technical and professional capacity. The following documents shall be submitted:
o a Company form (see Annex 8);
o a set of PARF's (minimum 1, maximum 5) (see Annex 9);
o a set of Best Practice Documents (see Annex 10).
By submitting a tender, each legal entity involved therein accepts the possibility of a check being carried out by the Publications Office on its technical capacities and, if necessary, on its research facilities and quality- control measures.
In addition, all tenderers are informed that they may be asked to prove that they are authorised to perform the contract under national law, as evidenced by inclusion in a professional or trade register or a sworn declaration or certificate, membership of a specific organisation, express authorisation, or entry in the VAT register.
Tenderers' attention is drawn to the fact that any total or partial omission of information for which one or more legal entities involved in the tender are responsible may lead the Publications Office to exclude the tender from the rest of the procedure.
2 Evaluation of the technical and professional capacity
The technical and professional capacity will be judged on the basis of the tenderer’s expertise relevant to the required services in particular with regard to their know-how, efficiency, experience and reliability.
Submitted PARFs will be evaluated to verify the tenderers experience with regard to the services requested under this call for tender. The tenderer has to provide a minimum of 1 and a maximum of 5 PARFs. If the tenderer presents more than 5 forms, only the first 5 forms as found in the offer will be evaluated. To pass the selection phase the PARFs shall cover for their actually executed part:
• at least 1500 relevant man-days[2] all PARFs together, of which at least 50 % of man-days ANA-PROG per PARF;
• at least 300 man-days per PARF.
Submitted Best Practice Documents will be evaluated against the requirements as set out in Annex 10.
7 Section four: award criteria – technical bid
The contract will be awarded to the tenderer who submits the most economically advantageous bid on the basis of the criteria set out below.
1 Documents to provide concerning the technical award criteria
This part has to contain the documents showing the merits of the bid, to make it possible to evaluate the technical award criteria. The following documents shall be submitted (for more details please refer to Annex 11):
• A document of maximum 15 pages of A4 format font-size 12 presenting tenderer's approach to quality assurance and to project management in software development;
• A document of maximum 10 pages of A4 format font-size 12 presenting tenderer's proposal describing the takeover phase;
• A document of maximum 10 pages of A4 format font-size 12 presenting tenderer's proposal describing the handover phase;
• A document of maximum 15 pages A4 format font-size 12 presenting tenderer's proposal of a service level-agreement.
In case a submitted document, including its table of content, figures, graphs, examples, annexes, and all other additional information, exceeds maximum limits as set out above, only the first 10 respectively 15 pages will be evaluated.
2 Evaluation of the technical award criteria
The award criteria have the purpose to choose between the tenders which have been submitted by tenderers not subject to exclusion and which meet the selection criteria.
The award criteria are intended to assess the quality of the bid based on the proposal of the tenderer. The criteria concerning the ability or capacity of the tenderers such as previous experience, professional education and references, which are taken into account for the evaluation of the selection criteria will not be taken into account for the evaluation of the award criteria. The technical evaluation will be based on the following criteria.
|No |Technical award criteria |Weighting (maximum |
| | |points) |
|1. |Tenderer's approach to quality assurance and to project management in software development |35 |
|2. |Tenderer's proposal describing the takeover fase |15 |
|3. |Tenderer's proposal describing the handover fase |15 |
|4. |Tenderer’s proposal of a draft service level-agreement |30 |
|5. |Overall quality of the presentation of the tenderer’s response |5 |
| |Total number of points |100 |
The result of the technical evaluation is the sum of the number of points obtained as a result of the evaluation of each criterion. Only those bids which are awarded at least half the points for each criterion and a total score of at least 65 points will be considered for the award of the contract.
Since assessment of the tenders will focus on the quality of the proposed services, tenders should elaborate on all points addressed by these specifications in order to score as many points as possible. The mere repetition of mandatory requirements set out in these specifications, without going into details or without giving any added value, will only result in a very low score.
8 Section five: award criteria – financial bid
1 Documents to provide relating to the financial award criteria
For the financial bid, the tenderer must use the annexed price schedule and estimation form.
The financial bid must fulfil the following requirements:
• prices must be expressed in euro;
• prices should be expressed to a maximum of two (2) decimal places;
• prices should be quoted free of all duties, taxes and other charges, i.e. also free of VAT, as the Communities are exempt from such charges in the EU under Articles 3 and 4 of the Protocol on the Privileges and Immunities of the European Communities of 8 April 1965 (OJ L 152 of 13 July 1967). Exemption is granted to the Commission by the governments of the Member States, either through refunds upon presentation of documentary evidence or by direct exemption.
For those countries where national legislation provides an exemption by means of a reimbursement, the amount of VAT is to be shown separately. In case of doubt about the applicable VAT system, it is the tenderer's responsibility to contact his or her national authorities to clarify the way in which the European Community is exempt from VAT.
The following must be taken into consideration when completing the Price schedule and Estimation form.
- the price schedules must include the name of the firm and each page must be duly completed and signed by one of the duly authorised representatives of the company (Annex 1). No amendments to the price schedule will be permitted and a full reply must be given to each question.
If no answer is given, the response will be assumed to be negative. Any omission or amendment to the original price schedule will cause the bid to be considered null and void.
- the Estimation forms must be duly completed and signed (Annex 1). The content must be based on the unit prices given in the price schedule and the price schedule will take precedence over the estimation form if there is any discrepancy between them. However, the estimation form is intended as a rough guide only and may not be cited in the event of litigation, only the work actually carried out is to be invoiced, on the basis of the unit prices given in the price schedule.
The price schedule and the estimation form shall also be provided electronically as excel files. In the case of a discrepancy between the paper version and the electronic file, the paper version will take precedence.
2 Evaluation of the financial award criteria
The evaluation of the financial award criteria will be based on the final total price in the estimation form ("Total" in the estimation form).
9 Final evaluation
Only those offers that have passed the previous stages will be considered for this final evaluation.
The contract will be awarded to the tenderer offering the best value for money, in accordance with the following formula.
In order to identify the offer presenting the best value for money, quality will be given a weighting of 50 % and price will be given a weighting of 50 % , using only data from bids that have reached the final evaluation stage.
|R= |(50x |Q |) + (50x |Pmin |) |
| | |Qmax | |P | |
where:
|R |stands for value for money |
|Q |stands for quality score for the bid in question |
|Qmax |stands for quality score for the bid obtaining the highest quality mark |
|Pmin |stands for the total final amount of the specimen quotation for the lowest bid |
|P |stands for the total final amount of the specimen quotation of the bid in question |
10 Information for tenderers
The Publications Office will inform tenderers of decisions reached concerning the award of the contract, including the grounds for any decision not to award a contract or to recommence the procedure.
If a written request is received, the Publications Office will inform all rejected tenderers of the reasons for their rejection and all tenderers submitting an admissible tender of the characteristics and relative advantages of the selected tender and the name of the successful tenderer.
However, certain information may be withheld where its release would impede law enforcement or otherwise be contrary to the public interest, or would prejudice the legitimate commercial interests of economic operators, public or private, or might prejudice fair competition between them.
11 Award of the contract
The procurement procedure is concluded by a contract signed by the parties, or by a decision not to conclude the contract.
After the period of validity of the tender has expired, conclusion of the contract shall be subject to the tenderer's agreement in writing.
Joint bid and subcontracting
This section only applies for tenders involving joint bid or subcontracting. If this is not the case, please continue to the next section (4. Technical specifications).
1 Making a bid in collaboration with other companies
Where a tender involves several legal entities, they may choose between:
• making a joint bid, in which case all the economic operators must be considered as tenderers and, if theirs is the successful bid, as contractors (in this case, one of the tenderers must be put forward as co-ordinator to manage the contract); and
• making a bid in the name of only one tenderer, who is then the sole contractor if the bid is successful, the other legal entities being considered as subcontractors.
Whichever type of bid is chosen (joint bid or bid in the name of one tenderer), the tenderer(s) must stipulate the role, qualifications and experience of each legal entity and, where relevant, the monitoring arrangements that exist between them.
1 Joint bid
Tenderers in a joint bid assume joint and several liability towards the Publications Office for the performance of the contract as a whole. Statements saying, for instance:
• that one of the partners of the joint bid will be responsible for part of the contract and another one for the rest, or
• that more than one contract should be signed if the joint bid is successful,
are thus incompatible with the principle of joint and several liability.
The Publications Office will disregard any such statement contained in a joint bid, and reserves the right to reject such offers without further evaluation on the grounds that they do not comply with the tendering specifications.
In the case of a joint bid, one of the partners of the joint bid (co-ordinator) should be given power of attorney to represent the other parties to sign and administrate the contract.
If the joint bid is selected the tenderers may be required to adopt a given legal form after they have been awarded the contract if this change is necessary for proper performance of the contract.
2 Subcontracting
If certain tasks provided for in the contract are entrusted to subcontractors, the contractor retains full liability towards the Publications Office for performance of the contract as a whole. Accordingly:
• the Publications Office will treat all contractual matters (e.g. payment) exclusively with the contractor, whether or not the tasks are performed by a subcontractor;
• under no circumstances can the contractor avoid liability towards the Publications Office on the grounds that the subcontractor is at fault.
Tenderers must inform the subcontractor(s) that Article II.17 of the contract will be applied to them. Once the contract has been signed, Article II.13 of the above-mentioned service contract shall govern the subcontracting. During execution of the contract, the contractor will need the Publications Office’s express authorisation to replace a subcontractor with another and/or to subcontract tasks for which subcontracting was not envisaged in the original offer.
2 Documents to submit – joint bid
In the case of a joint bid, the following documents must be provided:
Section One: Administrative Information and evidence for access to the contract
1. A declaration based on the model agreement on the “Power of Attorney” attached in Annex 2C, signed by the legal representatives of all the partners of the joint bid including the following:
• recognising joint and several liability for all the partners of the joint bid for the performance of the contract;
• giving one of the partners of the joint bid (co-ordinator) power of attorney to represent the other parties to sign and administrate the contract.
2. If the tenderers have already set up a consortium or similar entity to that end, they should state this in their offer, together with any other relevant information and documentation in this connection.
3. The questionnaire for joint bids and subcontracting (Annex 4) must be provided signed by a legal representative of the co-ordinator.
4. The form for identification of the tenderer (Annex 3) must be provided by each partner of the joint bid.
5. The "legal entity" form (Annex 2B) for each tenderer with all the abovementioned supporting documents as specified in point 2.4.
Only the co-ordinator must return the financial identification form.
Section Two: Documents relating to the exclusion criteria
6. Each tenderer must fill in and return the declaration on grounds for exclusion (Annex 6) and provide the supporting documents as specified above in point 2.5.
Section Three: Documents relating to the selection criteria
7. Each of the parties of a joint bid must provide the Economic and Financial capacity questionnaire (see: Annex 7), including documents mentioned there.
The documents concerning the technical and professional capacities only have to be submitted once for all partners of a joint bid, but it must be indicated to which partner the described capacities belong.
Sections Four and Five: Documents relating to the award criteria
The documents relating to the award criteria shall be provided once by the co-ordinator representing the group of tenderers.
3 Documents to submit – subcontracting
If the offer envisages subcontracting, it must include the following.
Section One: Administrative Information and evidence for access to contract
1. the questionnaire for joint bids and subcontracting provided in Annex 4., signed by a legal representative of the tenderer. The third page of this questionnaire must be provided once for each subcontractor, including the following information:
• the reasons for subcontracting;
• the roles, activities and responsibilities of each subcontractor, and
• the volume / proportion for each subcontractor;
2. a letter of intent by each subcontractor stating its intention to collaborate with the tenderer if the contract is awarded to him.
Section Two: Documents relating to the exclusion criteria
3. subcontractors must provide the duly signed declaration on grounds for exclusion (Annex 6). Where, in a bid, the value of the subcontracting which is to be executed by a subcontractor is equal to or exceeds 20% of the value of the contract, the subcontractor must be prepared to provide all the supporting documents to the declaration as specified in point 2.5. Where those services represent less than 20% of the contract, the subcontractor shall not be required to provide the supporting evidence. The Publications Office, however, reserves the right, to request the evidence if considered necessary.
Section Three: Documents relating to the selection criteria
4. Where, in a bid, the value of the subcontracting which is to be executed by a subcontractor is equal to or exceeds 20% of the value of the contract, the subcontractor must provide the documents related to the economic and financial capacity as specified in point 2.6. Where those services represent less than 20%, the subcontractor does not have to provide the Economic and Financial capacity questionnaire (Annex 16). However, in case the tenderer relies on the capacities of subcontractors for fulfilling the selection criteria as he indicates in the questionnaire for joint bids and subcontracting the Publications Office will ask for those documents. The Publications Office also reserves the right to ask for those documents if considered necessary.
5. With regard to the technical and professional capacities, the subcontractor has to submit the documents concerning the services he or she is proposed to perform.
Sections Four and Five: Documents relating to the award criteria
The documents relating to the award criteria shall be provided only by the tenderer.
4 Evaluation of the bids in case of joint bids or subcontracting
1 Exclusion criteria
The exclusion criteria will be assessed in relation to each tenderer or subcontractor individually.
2 Selection criteria
Joint bid
If several tenderers are involved in the bid as partners of a joint bid, each of them must prove that they have the required economic and financial capacity. However if the criteria are to be achieved above a certain level, a consolidated assessment shall be made.
The selection criteria concerning the technical and professional capacity will be assessed in relation to the group as a whole.
Subcontracting
The selection criteria concerning the economic and financial capacity will be assessed in relation to the tenderer and each proposed subcontractor individually if the Publications Office finds it necessary due to the role of the subcontractor and volume of the subcontracting. However if the criteria are to be achieved above a certain level, a consolidated assessment shall be made to the extent that the subcontractor puts its resources at the disposal of the tenderer for the performance of the contract.
The selection criteria concerning the technical and professional capacity will be assessed in relation to each proposed subcontractor only as regards the subcontracted services.
Only in the case where the tenderer intends to rely on capacities from the subcontractor in order to fulfil the selection criteria, as he indicates in the questionnaire for joint bids and subcontracting (Annex 4), the selection criteria for technical and professional capacity will be assessed in relation to the combined capacities of the tenderer and the subcontractor as a whole, to the extent that the subcontractor puts its resources at the disposal of the tenderer for the performance of the contract.
3 Award criteria
The evaluation (award) criteria will be assessed in relation to the tender as a whole.
Technical specifications
Acronym definitions are given in section 4.5.
1 Subject of the call for tender
Hereafter tenderers may find the description of the various services that could be requested during the course of the contract.
(a) Software development
▪ Extensions, evolutions and functional enhancements of the GESCOMX-SAGAPX-DWH/PUBLICATIONS system including development of complementary modules and technical migrations of any components of the system. The system includes all interfaces between applications of the system itself and half interfaces with outside.
▪ The different types of services to provide include: project management, detailed technical analysis, progamming, FAT testing, packaging, writing documentation and delivering.
▪ Technical analysis would typically include feasibility studies and technical proposals to implement the functional specifications, test cases, impact studies concerning planned changes at technical level.
▪ Elaboration of various types of documentation according to the different phases of the software development process.
▪ Assistance to FAT testing and to the deployment phase including the development of scripts and similar tasks in order to integrate the delivered software components into the existing environment.
(b) Corrective maintenance
▪ Bug fixing of operational information system, including supervision of the maintenance team, detailed technical analysis, programming, FAT testing, packaging, writing documentation and delivering.
▪ Update of existing documentation.
▪ Respect of the SLA defined for bug fixing.
(c) Technical assistance
▪ Assistance of the Office in the execution of various tasks concerning technical matters in the scope of this call for tender.
(d) Training
▪ Provision of training in English and/or French as and when necessary about the different functionalities (existing or new ones) of the system.
(e) Elaboration of functional analysis or specifications
▪ Elaboration of detailed functional analysis or specifications based on the requests formulated by the Publications Office.
(f) Takeover:
▪ Takeover of the global service from the previous contractor. For details, see chapter 4.2.7.1.
(g) End-user support
▪ Second-level support and end-user assistance concerning functional and technical matters about the information system within the specified domain. First-level support is provided by the Office Helpdesk and is not subject of this call for tender.
(h) Handover
▪ Handover of the global service to the next contractor(s). For details, see chapter 4.2.7.2.
i) Production and administration reporting
▪ The Publications Office currently uses Business Objects as the standard reporting tool. The activities that can be ordered may include:
← Maintenance of the existing universes, including updating them as necessary.
← Development of new universes or reports.
← Maintenance of the existing reports.
Detailed description of the requested services
GESCOMX-SAGAPX-DWH/PUBLICATIONS is one of the main production systems of the Publications Office as it handles the management and the dissemination of the publications, including the Official Journal of the European Communities. The Publications Office will expect from the contractor complete availability, high quality, customer oriented approach and high flexibility to adapt the work patterns to the lifecycle of the dissemination of the publications of the European Union.
Please refer to Annexes 15, 16 and 17 for functional and technical details of the system in question.
Orders requested will be either Time and means or Fixed Price, depending on the scope of the work to implement (see section 4.2 for detailed information of both order types).
The Publications Office does not commit itself to order all the activities listed in this section. They have been described with the sole purpose of giving the tenderers an idea of the activities that may be ordered during the duration of the contract.
Regular meetings are foreseen during the whole duration of the contract. In addition to working meetings, regular progress meetings will be held in Luxembourg (every month, although the frequency may be modified depending on specific situations). Physical presence of a representive will be requested at every meeting. In addition, attending steering committees (every 2 months on average) in Luxembourg will be also requested. Meetings are normally arranged at short notice meaning that the contractor must be available at short notice.
The tasks required will be:
o Software development: according to the Publications Office’s evaluation, the following two situations may occur:
▪ Complex developments: will be based on functional specifications. The objective will be the implementation of the functional specifications according to the users' needs in terms of planning and priorities. This type of developments will be typically covered by Fixed Price Orders (see section 4.2.4).
▪ Basic developments: some more simple requests will not need a previous functional analysis. The contractor will be responsible for the development of this type of requests based on the specifications provided by the Publications Office. These tasks will be covered either by a Time and Means Order or by a Fixed Price Order (see sections 4.2.4 and 4.2.5).
It’s at the Publications Office’s discretion to decide whether a preceding functional analysis would be needed or not.
o Corrective maintenance of the system's applications: correction of bugs in a timely manner. The contractor will have to respect the SLA for bug fixing (see section 4.3).
o Technical assistance: in some specific situations, normally related to complex projects or technical migrations, a technical analysis may be requested in order to be used as a reference for decision making. The studies or technical analysis will be related to the GESCOMX-SAGAPX-DWH/PUBLICATIONS system, but may consider interfacing with other applications.
o Training: formal training can be requested, either as an isolated activity (for example, newcomers training) or as part of a complex subproject under development, so that users can receive formal training before a new functionality is put in production. Training can be requested either in English and/or French and should be provided in Luxembourg.
o Elaboration of functional analysis or specifications as and when required. Definition of test cases.
▪ Detailed functional analysis;
▪ Elaboration of User Cases or updating the existing ones.
o End user support: providing GESCOMX, SAGAPX and DWH/PUBLICATIONS users with adequate technical or functional support. The SLA for the end-user support activities shall be respected (see section 4.3).
o Incident management:
▪ the Office uses Peregrine Service Centre as the standard ticketing system. The incidents are first logged by the Publications Office central helpdesk, then assigned to the appropriate group. The contractor can be asked to take it in charge (for example, by either providing end-user support, a temporary workaround or a definitive patch). In this case, the contractor will be responsible to keep the information up-to-date, to follow-up the incident until resolution, to elaborate reports and to identify and communicate recurrent problems to find definitive solutions. The contractor will ensure that the end-users are always duly informed of the situation of the faults logged.
▪ In order to ensure reliable and efficient communication and follow-up for tasks and/or developments for the contractor as well as the Publications Office, a JIRA-based platform shall be set up at the Publications Office. It will be accessible by both parties (project and service managers – or SPOCs) and will allow to follow and communicate on the tasks and the status of ongoing developments (e.g. for establishing activity reports, checking that the KPI indicators and SLA conditions are respected, etc).
Other tasks and considerations:
o The contractor will ensure that the documentation is permanently up-to-date. It will involve udpating all relevant existing documentation, including Test Plans, User Manual, Operations Manual, Security Analysis, etc. Any other document produced as a consequence of the developments carried out by the contractor will have to be updated as well if it's affected by any other activity related to the project.
o The contractor will usually participate in technical meetings, involving the Publications Office. Those meetings will take place in Luxembourg, at the Publications Office premises. In some circumstances, the contractor may be required to meet external users as well during the elaboration of the technical or functional specifications or during the testing phase for assistance after a software delivery. Meetings involving user participation take place in Luxembourg. The presence of different profiles can be requested at any meeting.
o The contractor shall be responsible for acquiring the software licenses he may need (Natural/Adabas, Oracle…) to perform the duties assigned to him wihin the scope of the contract. The Publications Office shall not provide such licenses to the contractor. The licences acquisition is not covered by this call for tenders.
o The contractor shall be responsible for taking all necessary measures (technical installations etc.) in order to be able to develop, on his own premises, the software requested under the scope of this contract. There will be no reimbursement of expenses.
o Each delivery made by the contractor is subject to the following workflow. Once received, the delivery is installed in a testing environment by the "Infrastructure" (R4) unit of the Publications Office. R4 performs the installation and gives a feed-back to the "IT Projects" (R5) unit when it is complete. R5 then informs the Service Manager or the users to start testing. When a package has been tested clean, the Service Manager requests the installation in production, which is arranged between R4 and R5 according to the users needs.
o There is an internal tool to manage the software deliveries, the installation in test environment and the subsequent installation in production environment. It is a web-based application (JIRA based) and it basically consists of two types of requests: DMT: Request to Install on Test and DMP: Request to Install on Production. R5 will be responsible for introducing the requests in the system (although handling DMPs may be eventually transferred to the Service Manager). R4 is responsible for handling all the requests. A software delivery can be rejected by R4 if some important information (release notes, installation instructions…) is missing in the delivered documentation.
The relationships between all the stakeholders are described in the following diagram:
[pic]
Fig 4.1 Organisational diagram
Estimation of the annual volume of work per year
The following table includes a global estimation of the annual resource requirement and a possible distribution of the estimated volume per profile.
For the detailed description of the profiles please refer to point 4.4.
Please note that these estimations are purely indicative.
|Profile (code) |Estimation of the annual workload in man-days |
|Analyst–programmer (ANA-PROG) |220 |
|Project Manager (PRO-MAN) |55 |
|Technical Consultant (TEC-CONS) |55 |
|Total |330 |
Table: Estimation of man-days for one year, per profile.
2 Working methods and general constraints
1 Introduction
This point defines the common procedures to be followed and the general constraints and arrangements to be respected by the contractor in order to deliver the different types of services requested by the Publications Office.
Delivery of services is based on Orders issued by the Publications Office. Orders may be either on a fixed price or on a time and means basis. In general, the Publications Office prefers to work on a fixed price basis. Time and means requests will be restricted to cases where a fixed price agreement is not adequate, due to a lack of specifications or to the urgency or the nature of the work.
In the following text, the term ‘working days’ means the official working days of the Publications Office.
2 Working methods
Delivery of services has to be in conformity with the Orders placed, which may be either fixed price or time and means.
The provisions of the framework contract have to be respected. Special attention is drawn to the rules concerning the guarantee period, invoicing conditions and liquidated damages.
For work on the Publications Office’s premises, contractors must comply with the following rules:
|Period of normal working hours: |between 7 AM and 8 PM |
|Normal working days: |Monday to Saturday |
|Normal working hours (between 7 AM and 8 PM), excluding lunch break: |8 hours |
|Minimum compulsory lunch break: |30 minutes |
The working hours must be in accordance with the requirements of the service.
In case of time and means work, a detailed monthly attendance sheet has to be provided for each individual person.
Work outside the period of normal working hours can only be accepted in case of an agreement with the Publications Office.
For work outside normal working hours, on Sundays and on public holidays, tenderers must specify separately the price per day and type of overtime (see Price schedules and Estimation forms, Annex 1).
3 Fixed price services
Projects based on fixed price agreements will be initiated on request of the Publications Office. The request will normally come together with a functional and/or a technical specification detailing the work to be done or the service to be provided.
The contractor will answer to the request by introducing a fixed price proposal which must be submitted within 15 working days after initiation of the request by the Publications Office. The results of a fixed price project are defined by deliverables. In consequence, every fixed price proposal has to include the definition of all deliverables which will be provided as final or intermediate results. A fixed price must be indicated for each deliverable. This price has to be calculated on the basis of the day rates of the appropriate profiles included in the Price schedule of the framework contract. Every fixed price proposal has to contain a global project plan. The project plan has to point out the major phases of the project. Underlying assumptions and restrictions have to be clearly indicated. For each phase an estimation of its duration has to be defined.
On acceptance of the contractor’s proposal, the Publications Office will establish an Order.
The start of the project will be formalised by a kick-off meeting which must take place within 10 working days either after acceptance of the Order by the contractor. The contractor will also submit at this occasion a detailed version of his project plan as well as a quality assurance plan for validation by the Publications Office. The project plan has to indicate clearly all actions demanding intervention or active participation of the Publications Office, such as interviews, installations - or acceptance periods. The Publications Office has to validate the proposed planning within 10 working days. In the case of disagreement, a second meeting has to be scheduled to negotiate the necessary changes and to validate the modified planning.
Deliveries may include one or more deliverables. A delivery has to be accompanied by a delivery note. Intermediate deliveries in common agreement are possible, but they do not have any contractual impact.
For software deliverables and related documentation the acceptance period will take up to 30 working days. The acceptance period consists of three consecutive phases:
1. Installation phase of up to 5 working days. The Publications Office may request the support of the contractor in case of problems during the installation phase, without supplementary charges.
2. Test or validation phase of up to 20 working days.
3. Wrap-up phase of up to 5 working days in order to establish the Provisional acceptance note (see the model "Provisional / Final (end of guarantee) acceptance note" in Annex 14 of this document).
The Provisional acceptance note (see model in Annex 14) will include the conclusions of the testing period. One of three situations may occur:
1. The delivery is accepted with no reserves. No problems have been detected during the test or validation phase. The guarantee period starts with the date of countersignature of the Provisional acceptance note by the contractor.
2. The delivery is accepted with reserves. One or several minor non-blocking problems have been identified during the test or validation phase as specified in the Provisional acceptance note. The contractor has to communicate his position within 5 working days after reception of the Provisional acceptance note by organising a meeting with the Publications Office. The contractor accepts the result of the acceptance by countersignature of the Provisional acceptance note. At the same time he communicates his planning for the delivery of the necessary corrections respective the new delivery. The planning has to be reasonable and accepted by the Publications Office. The contractor has to prove that he has taken the necessary arrangements in order to re-deliver without delay. The guarantee period starts on the date of countersignature of the Provisional acceptance note by the contractor.
3. The delivery is rejected due to the existence of major blocking problems found during the testing or validation period. The contractor has to communicate his position within 5 working days after receipt of the Provisional acceptance note by organizing a meeting with the Publications Office. As the contractor has to make a new delivery, the contractor will propose a new delivery date during the meeting. A new acceptance period of 30 days starts on the date of signature by the Publications Office of the delivery note for the new delivery. If the new delivery is rejected, a new cycle as described in this point will take place again (meeting + new delivery date).
If no Provisional acceptance note is submitted at the end of the acceptance period, the deliverables are implicitly accepted without reserve and the guarantee period starts 30 working days after the date of signature of the delivery note by the Publications Office.
Deliveries which are only composed of documentation (analysis documents, technical studies, etc.), will follow exactly the same test/validation and acceptance procedure (including deadlines) as described above.
Exceptionally the above defined delays may be adapted in common written agreement for a subset of deliverables due to the specific requirements of a particular project. In this case, such an agreement will be reached during the kick-off meeting.
Fixed price projects will normally be executed at the contractor’s premises. The contractor nominates a project manager who is the principal contact person for the Publications Office.
To ensure the follow-up of a fixed price project the Publications Office also designates a project leader on its side, who will be the main contact for the contractor’s project manager.
The contractor will present the financial balance of each and every order to the Publications Office on a monthly basis. The minimum information included in the balance shall be: commitments, expenses made, remaining budget available and the planning of submission of the remaining invoices.
At the end of the guarantee period, the contractor will establish an "End of guarantee letter".
Upon receipt of the "End of guarantee letter", the Publications Office will verify that all reserves stated during the provisional acceptance period have been solved and that all corrections of bugs found during the guarantee period have been delivered, installed and validated.
In this case, the Publications Office will draw up the Final acceptance note without reserves.
If not, the Final acceptance note is drawn up with reserves due to the existence of remaining problems. The contractor has to communicate its position within 5 working days after receipt of the Final acceptance note by organizing a meeting with the Publications Office. As the contractor has to make a new delivery, the contractor will propose a new delivery date during the meeting. A new acceptance period of 30 days starts on the date of signature by the Publications Office of the delivery note for the new delivery. If the new delivery is rejected, a new cycle as described in this point will take place again (meeting + new delivery date).
4 Time and means Orders
In case of time and means requests the contractor submits within 15 working days after initiation of a request by the Publications Office a proposal concerning the required resources, including a commitment concerning the availability of each person.
In case of agreement the Publications Office may directly establish an Order form based on the Price schedule of the framework contract.
To ensure the follow-up of Time and Means Orders the Publications Office also designates a project leader on its side.
The contractor shall present the financial balance of each and every Order to the Publications Office on a monthly basis. The minimum information included in the balance shall be: the commitments, expenses made, remaining budget available and the planning of submission of the remaining invoices. This document shall be accompanied by a detailed attendance sheet.
5 Staff replacement (only in case of Time and Means)
The contractor has the right to ask for an adjustment to the profile attribution of a person. This request has to be accompanied by a justification and the request has to be validated by the Office. In order to validate such a request, the Office may schedule an interview with the person. The Office has the right to reject a proposal.
If for exceptional circumstances the contractor wants to exchange a member of personnel during an engagement, he has to submit a formal request to the Publications Office at least 2 months in advance. An equivalent replacement shall be proposed to the Publications Office.
For a member of staff who is proposed for the first time to the Office, the proposition concerning the profile has to be provided by the contractor. This proposition has to be validated by the Office.
In general, the Office reserves the right to schedule an interview with a proposed candidate in the case of a first engagement. The Office has the right to reject a proposal.
The proposed candidate must be available during the whole time foreseen for his/her engagement.
If a person is unavailable due to reasons beyond the contractor’s control, the contractor has to ensure that an equivalent replacement will be available within 10 working days.
For any personnel replacement, the contractor will ensure that the transition is smooth and the interests of the Publications Office are not affected. In particular, the contractor will ensure that the person to be replaced remains in place until his/her replacement is fully operational. The contractor will provide the appropriate reports in order to document the handover process.
For any personnel replacement, all the costs generated (for example training expenses) shall be borne by the contractor.
6 Contractual transition periods
1 Takeover
There will be a takeover phase of a maximum of 3 weeks. During that period, the new contractor will ensure that he takes all the necessary steps in order to be fully capable to work autonomously when the takeover phase has finished. The transition between the old and the new contractor will take place during one of the most critical periods of the year in the production cycle (November/December). Therefore, the new contractor will take all the necessary steps in order to make the transition as smooth and transparent to the users as possible.
During the takeover period, the current contractor will continue working as the main service provider handling all kinds of services. No distribution of the ongoing works or any other kind of cross-work between the existing contractor and the future one has been foreseen.
The new contractor will take over from the previous contractor all specific activities, documentation and existing tools, which have been acquired/developed/implemented/operated for the purpose of the service via the previous contract. The previous contractor will undertake corresponding handover efforts until the end of his contract.
Within the areas of his responsibility as defined in the specifications, the contractor shall establish and carry out the necessary takeover activities in such a way that there is no interruption or degradation in services. These tasks will include (but are not limited to) the following items:
o Procedures and files of project operations;
o Complete source code, binaries, tools… of the application;
o Computer programs and PC packages;
o Documentation;
o Project forms and statistical reports;
o Any information on paper or otherwise belonging to the project;
o Full operation of all services taken over.
The tenderer will deliver a detailed takeover plan elaborating on the above actions as requested in Annex 11. Once the contract has been awarded, the takeover plans will be reviewed by the Publications Office. If necessary, further details or changes will be requested until its final approval by the Publications Office Project Leader. This approved takeover plan will be the basis for the phase-out plan of the previous contractor.
Should the contract be awarded to the same previous contractor, this takeover phase will not be necessary.
2 Handover
The contractor shall prepare for and contribute pro-actively to a complete, timely and smooth handover of the service to the next contractor – or to the Publications Office – allowing a similar takeover as the one just described.
All computer hardware, software and other capital equipment which may have been paid for by the Institutions, including the Publications Office, shall be handed back by the contractor. This also applies to all documents.
During the handover period, which is likely to cover a maximum of 3 weeks of this contract,the contractor will fully co-operate with the next contractor to achieve the continuation of high standard service quality.
If the contract is terminated or upon expiry of the contract, the contractor shall provide the following deliverables without further payment by the Publications Office:
a) Consolidated reports covering the whole period;
a) Backups of the entire software configuration of each and every service component stored in a secure manner prior to its delivery to the Publications Office;
b) A package allowing reproducing the complete operational environment (with anonymized data and optionally without data) in the environment of the next contractor.
c) Archives and all associated information according to specifications defined by the Publications Office;
d) Software application systems and all data that have been managed, further developed or newly developed under the contract;
e) Blue prints and scenarios for the work processes and quality control;
f) Any confidential data in physical files (paper or electronic) that has been provided to him or has otherwise come into his possession during execution of the work;
g) A statement stating the respect of confidentiality for the period as defined in the contract (article II.9 of the contract);
h) A statement stating that no malicious code (backdoors, time-bombs, Trojan horses, worms, viruses, etc.) has been installed by any of contractor’s staff and that the latter have taken all the necessary measures to ensure that no malicious code exists in the systems left behind and/or provided to the Commission;
Apart from those deliverables, the contractor will destroy any security critical information and piece of software that was provided by the Institutions for the purpose of accessing servers at the Institutions during the execution of the contract. This may include sensitive information, passwords, encryption keys, personal data of people involved in the project, firewall and router configuration files, etc.
The tenderer will deliver a detailed handover plan elaborating on the above actions as requested in Annex 11. The handover plan is then subject to the approval of the Publications Office.
7 General constraints
1 Language constraints
Documents must be provided in English and/or French. All written or oral communication must be done either in English and/or French.
2 Security constraints
The Publications Office has developed its specific Baseline Information System Security Policies (see Annex 13).
3 Service Level Agreement
The principal purpose of the Service Level Agreement (SLA) (see also Annex 11) is to define a certain number of key areas of activity that represent the most important qualities expected by the Publications Office and the users. For each of those areas, a level of performance is agreed, representing the minimum level of service to be provided. The SLA is intended to establish a clear set of measurable parameters against which the performance of the contractor can be measured.
Thus the establishment of the SLA ensures that the Publications Office and the contractor:
• share a common understanding of the levels of service required in the key areas of operating the service;
• share a common approach in measuring the levels of service provided.
The SLA has been based upon the current scope and operational environment of the GESCOMX-SAGAPX-DWH/PUBLICATIONS system. Any major changes to the service may require a revision of the terms and conditions of the SLA. Both sides may introduce change requests in order to adapt the service level agreement. A change request has to be approved by either party. Every party has the right to reject a change request.
The SLA shall define the detailed performance indicators covering the main activities of the contractor’s tasks. The Publications Office Project Leader will evaluate the key performance indicators on a monthly or yearly basis depending on the indicator.
The Publications Office will be responsible for providing all the necessary information to the contractors in order to solve a given problem or to progress a given request. At any given time, the contractor can request additional information or assistance from the Publications Office. If the requested information proves to be necessary in order to progress the request or to resolve the problem, the elapsed time since the information/assistance is requested until it is provided will not be accounted for the SLA calculation.
Any breach of SLA will be analysed by the Publications Office. In this regard, the Publications Office reserves the right to apply liquidated damages as described in article I.11 of the draft contract.
Key Performance Indicators (KPI)
In order to evaluate the performance of the contractor, the Publications Office will use the following Key Performance Indicators as described in the table below:
|ID | |Definition |Target |
|KPI_01 | |Number of contractor’s proposals rejected by the Publications |Less than 10% |
| | |Office | |
|KPI_02 | |100% of all reports (including timesheets) will be given to the |100% |
| | |Office in time | |
|KPI_03 | |Number of requests submitted by the Publications Office for |Maximum: 1 per year |
| | |personnel replacement due to non-performance | |
|KPI_04 | |Number of major complaints per year for the overall service |Maximum: 1 per year |
| | |delivery | |
|KPI_05 | |Number of problems related to user satisfaction (annual user's |Less than 15% |
| | |survey to be done by the Publications Office) that remains | |
| | |unresolved after one month of the date of communication of the | |
| | |problems to the contractor by the Publications Office | |
Those KPIs will be initially evaluated on a yearly basis. However, if the requirements of the services require so, they could be evaluated on a 6-monthly basis.
Any deviation of the targets as described in the previous table will be considered as a breach of SLA.
In addition, the following sections will describe the specific key areas. These specific key areas will be evaluated on a bi-monthly basis.
Bug Fixing
GESCOMX-SAGAPX-DWH/PUBLICATIONS is a production-critical system. Therefore, the resolution of bugs will be a high-priority activity.
An initial analysis of the bug will be made by the Publications Office to classify it under one of two situations:
• Bug covered by the guarantee of any fixed price order: the resolution of the bug will be at the contractor’s expense.
• Production bug: meaning that it’s not covered by any guarantee of any ongoing fixed price order. The resolution of the bug will be done by the contractor under corrective maintenance, using either a Time and Means order or a Fixed Price order, at the discretion of the Publications Office.
The Publications Office would like to stress that the resolution of all bugs, independently of the classification in any of both groups mentioned, will be a high-priority activity. Thus, the resolution of all bugs will be governed by the SLA as described below.
The bugs will also be assigned a priority according to their severity:
- Critical (Priority 1): blocking problem affecting the whole system or any specific critical functionality becoming unusable. It also comprises performance problems making the system unworkable by the users.
- Normal (Priority 2): non-blocking problems affecting some functionalities of the systems, including performance degradation when it doesn’t critically affect production activities.
The classification of the priority of the bug will be made by the Publications Office.
The contractor will be informed by email of the classification of the incident (guarantee covered or production bug) and the severity (priority). In case of discrepancy of the classification of the incident the contractor will inform the Publications Office who can initiate bilateral meetings for discussion. Nonetheless, the time to resolve the incident must be respected by the contractor. The severity of the incident will not be negotiated unless the contractor can prove that the incident is not blocking a critical function of any of the systems.
Overall incident resolution time: maximum elapsed time between reporting the incident by the Publications Office and the delivery of a working solution or acceptable temporary by-pass situation.
| |PRIORITY 1 |PRIORITY 2 |
|Overall incident resolution time |24 |40 |
| |clocking hours |Working hours |
The contractor will ensure that the resolution times will be respected for both: bugs covered by a guarantee period or for production bugs.
As specified in the ‘Overall incident resolution time’ definition, a solution to a given bug may consist of the delivery of a software package or the delivery of an acceptable workaround in order to bring the system back to service. The workaround can consist of a specific software delivery, a configuration change or a procedure to allow the users to satisfactorily process the task. After implementing the workaround, the incident could be re-classified according to the new situation (the severity of the problem could be downgraded from Priority 1 to Priority 2) to solve definitively the incident.
The contractor will deliver a software package or a document explaining the workaround. The Publications Office may reject the delivery if the solution is not satisfactory.
Any time exceeding the overall incident resolution time will be considered as a breach of SLA, including both cases:
▪ The contractor doesn’t deliver the solution within the time specified in the SLA.
▪ The contractor delivers a solution, which is rejected by the Publications Office as not satisfactory. In this case, the resolution time will be considered as the total time taken to deliver the first solution plus the time taken to deliver subsequent solutions until delivering one which is satisfactory. The elapsed time between the contractor’s delivery and the Publications Office’s communication of non-conformity will be excluded.
Service Request
For either Time and Means or Fixed Price projects, the contractor will have to submit a proposal within the first 15 working days after receiving the formal request made by the Publications Office, as specified in section 4.2.4 and 4.2.5 of the technical specifications.
Any deviation to this deadline will be considered as a breach of SLA.
Services Provided
For fixed price projects, the contractor will ensure that the deadlines, as specified in the offer, are completely respected. Any deviation of the agreed delivery deadlines will be considered as a breach of SLA.
For either Time and Means or Fixed Price projects, the contractor will ensure that the services are delivered with the quality required. Any software package must be thoroughly tested by the contractor before being delivered. Functional and performance tests will have to be carried out by the contractor in order to ensure that the delivery will comply with the requirements specified in the order or request. FAT(Factory Acceptance Tests)-reports detailing the tests carried out must be delivered along with the software package and the documentation related. The Publications Office will reject any software package which doesn’t succeed the testing or which quality doesn’t fulfil the standard requirements (including the related documentation). Any rejection due to non-conformity will be considered as a breach of SLA.
Deliveries which are only composed of documentation will have to present the required quality as well. If the documentation is not accepted by the Publications Office, the contractor will have to submit a new delivery. The same procedure as described for software deliveries will apply.
Personnel replacement
Any deviation to the conditions as set out in section 4.2.6 of the specifications related to staff replacement will be considered as a breach of SLA.
4 Profile description
Profiles required to evaluate the technical capacity of the tenderer
The following table defines the profiles that have to be provided in order to evaluate the technical capacity of the tenderer.
|Profiles required (Code) |
|Project manager (PRO-MAN) |
|Analyst–programmer (ANA-PROG) |
|Technical Consultant (TEC-CONS) |
Profiles description
Project Manager – PRO-MAN
|Nature of the tasks |Project management including proposals for project strategies, planning, definition of tasks and |
| |deliverables, review of project deliverables, quality control, risk analysis and management, status |
| |reports, problem reporting and management systems, follow up and organisation. |
| |Guide sub-contractors in charge of project activities and review their deliverables. |
| |Participate in functional and technical working groups and progress meetings. |
| |Estimate costs, timescales and resource requirements for the successful completion of each project to |
| |agreed terms of reference. |
| |Prepare and maintain project and quality plans and tracks activities against the plan, provide regular |
| |and accurate reports. |
| |Monitor costs, timescales and resources used, and take action where these deviate from agreed |
| |tolerances. Ensure that delivered systems are implemented within these criteria. |
| |Manage the change control procedure gaining agreement for revisions to the project from project |
| |sponsors. |
| |Provide effective leadership for the project team ensuring that team members are motivated and |
| |constantly developing their skills and experience. |
|Education |University degree, in a relevant subject. |
|Languages |Good knowledge of English and French. |
|Knowledge and skills |Excellent knowledge of at least 1 international standard in Project Management (PMI, Prince2, IPMA, RUP)|
| |and tool (MS Project, Primavera…). |
| |Good knowledge of reporting methods and tools. |
| |Ability to give presentations. |
| |Ability to apply high quality standards to all tasks in hand, no matter how small and ensuring that |
| |nothing is overlooked. |
| |Ability to participate in multi-lingual meetings, good communicator. |
| |Capability of integration in an international/multi-cultural environment, rapid self-starting capability|
| |and experience in team working, understanding the needs, objectives and constraints of those in other |
| |disciplines and functions. |
| |Leadership capability. |
| |Ability to work under heavy work- and time pressure. |
| |Excellent knowledge on at least two of the different standards (UML, RUP, Merise…) used in the analysis |
| |and design phase of an IT system. |
|Experience |A minimum of 3 years of professional experience working with project management tools (MS Project, |
| |Primavera…) and methodologies (PMI, Prince2, IPMA, RUP…). |
| |A minimum of 1 year of professional experience working with quality procedures. |
| |Good knowledge of Unix, XML, UTF-8, SQL, Adabas/Natural and Oracle databases; |
| |A minimum of 6 years of professional experience in IT. |
| |A minimum of 3 years of professional experience as a Project Manager in software development projects. |
| |Practical hands-on experience with most stages of the system development life-cycle is desirable. |
Technical consultant – TEC-CONS
|Nature of the tasks |Consultancy studies in the specific technical domain regarding the information systems described in this|
| |call for tender. |
| |Technical evaluations. |
| |Expert advise |
|Education |University degree, in a relevant subject. |
|Languages |Good knowledge of English and French. |
|Knowledge and skills |Excellent knowledge of Unix, XML, Business Objects, UTF-8, SQL, Adabas/Natural and Oracle databases. |
| |Ability to participate in multi-lingual meetings. |
| |Good communicator. |
|Experience |A minimum of 5 years of professional experience in IT. |
| |A minimum of 3 years of professional experience working with Unix, XML, Business Objects, UTF-8, Adabas |
| |and Oracle databases. |
| |A minimum of 2 years of professional experience working as a technical consultant in a similar software |
| |development environment as the one described in this call for tender. |
Analyst-Programmer - ANA-PROG
|Nature of the tasks |Technical analysis of new user requirements. |
| |Prototyping. |
| |Write, maintain and test software programs which reflect the specifications based on user requirements. |
| |Assist with the testing of such software programs together with the other programs making up the system. |
| |Assist with evaluating and testing products delivered by external system suppliers to ensure that they |
| |conform to the Publications Office requirements and methodology. |
| |Participation in the definition of the standards for the use of the Business Objects software and the |
| |creation of universes. |
| |Definition of the security schema to be applied to the databases, the universes and the reports reachable |
| |by the users. |
| |Consultancy studies regarding specific aspects of the Publications Office Business Objects environment. |
| |Technical evaluations regarding the Publications Office Business Objects environment. |
| |Participation in technical meetings. |
| |Second level end-user support |
|Education |Successful training in computer science by a competent institute. |
|Languages |Good knowledge of English and French. |
|Knowledge and skills |Excellent knowledge of Unix, XML, UTF-8, Adabas/Natural and Oracle databases. |
| |Capability of integration in an international/multi-cultural environment, rapid self-starting capability |
| |and experience working in team. |
| |In depth knowledge of the Business Objects software. |
| |In-depth technical knowledge of all parts of the information system including extensive administration |
| |capabilities for the specific products used in the context of this call for tenders and notably |
| |Adabas/Natural |
|Experience |A minimum of 5 years of professional experience in IT. |
| |A minimum of 3 years of professional experience working with Oracle and Adabas databases. |
| |A minimum of 3 years of professional experience as a software developer using Natural and SQL. |
| |A minimum of 1 year of professional experience working in multi-client and multi-national environments. |
5 Acronyms
BO: Business Objects
FAT: Factory Acceptance Tests
KPI: Key Performance Indicator
LDAP: Lightweight directory access protocol
PARF: Project Activity Reference Form
Publications Office: Office for Official Publications of the European Communities
SAT: Site Acceptance Tests
WOOD: Worldwide Object Dispatcher. Besides the exchange of data files between processes eventually running on distinct servers, this tool allows the triggering of processes based on the arrival of a file in a predefined directory. The tool is written in Perl and usually uses FTP as underlying protocol but could use any standard file transfer protocol. The Office strongly advises the contractor to ask for practical implementation guidelines before starting any development that could require integration/interaction with the WOOD.
Annexes
1. price schedule and estimation form
2.A financial identification form
2.B legal entity form
2.C agreement /power of attorney, model 1 and model 2
3. form for identification of the tenderer
4. questionnaire for joint bids and subcontracting
5. list of documents to provide in the tender
6. declaration on the grounds for exclusion
7. Economic and Financial capacity questionnaire
8. Company Form
9. Parfs
10. Best Practice Documents
11. Quality expectations and service proposals
12. Technical environment and standard operating procedures of the Publications Office
13. Security requirements
14. Model "Provisional / Final (end of guarantee) Acceptance note "
15. GESCOMX description
16. SAGAPX description
17. DataWarehouse description
Annex 1 Price Schedule and Estimation Form
AO 10203
Maintenance and software development of the GESCOMX-SAGAPX-DWH/PUBLICATIONS system and related services
Price Schedule
|Profiles |Price per day on contractor’s premises or Office premises in Luxembourg |
|Standard-profile code |Normal working hours: |Sunday / Public holidays |8 p.m. (day) to 7 a.m. (day + 1) |
| |Mo-Sa | | |
| |7 a.m. – 8 p.m. | | |
|PRO-MAN | | | |
|ANA-PROG | | | |
|TEC-CONS | | | |
|Takeover Phase (fixed price) | |
|Handover Phase (fixed price) | |
Estimation Form
|Profiles |Estimation |
|Standard-profile code |Price per day on contractor’s premises or |Estimation of the annual |Total price for four years |
| |Office premises in Luxembourg |workload in man-days | |
| |Normal working hours: | | |
| |Mo-Sa | | |
| |7 a.m. – 8 p.m. | | |
| |(A) |(B) |(A) × (B) × 4 |
|PRO-MAN | |55 | |
|ANA-PROG | |220 | |
|TEC-CONS | |55 | |
|Handover Phase (fixed price) | |
|Total | |
Company: ______________________ Date: ________________________
Name: _____________________ Signature: _________________________
• The tenderer’s attention is drawn to the fact that fixed price day rates have to include all costs regarding the management of the service Contract. This concerns in particular all coordination and reporting activities.
• All prices have to be indicated in euro. The prices should be expressed to a maximum of two (2) decimal places.
• The price per day is all-inclusive net of tax, since the European Community is exempt of all taxes.
• If any work for Fixed Price projects and Time and Means projects is to be done outside the contractor's premises, on the premises of the Publications Office, EU Institutions, bodies or its agents in Brussels, Luxembourg or Strasbourg, mission expenses will not be taken into account
Annex 2A financial identification form
Specific form for each Member State is available at the following Internet address:
.
Annex 2B Legal Entity Form
Specific form for each Member State is available at the following Internet address: .
Annex 2C Agreement / Power of attorney
Agreement / Power of attorney
Model 1
(DESIGNATING ONE OF THE COMPANIES OF THE GROUP AS LEADER AND
GIVING A MANDATE TO IT)
We the undersigned:
– Signatory 1 (Name, Function, Company, Registered address, VAT number)
– Signatory 2 (Name, Function, Company, Registered address, VAT number)
– …..
– Signatory N (Name, Function, Company, Registered address, VAT number),
Each of them having the legal capacity required to act on behalf of his/her company,
HEREBY AGREE AS FOLLOWS:
1) The European Commission has awarded the Framework Contract 10203 (« the Contract ») to Company 1, Company 2, …, Company N (« the Group Members »), based on the joint offer submitted by them on … ….. for “Maintenance and software development of the GESCOMX-SAGAPX-DWH/PUBLICATIONS system and related services" (« the Services »).
2) As co-signatories of the Contract, all the Group Members:
a) Shall be jointly and severally liable towards the European Commission for the performance of the Contract.
b) Shall comply with the terms and conditions of the Contract and ensure the proper execution of their respective share of the Services.
3) To this effect, the Group Members designate Company X as Group Leader.
[N.B.: The Group Leader has to be one of the Group Members]
4) Payments by the European Commission related to the Services shall be made through the Group Leader’s bank account.
[Provide details on bank, address, account number, etc.].
5) The Group Members grant to the Group Leader all the necessary powers to act on their behalf in connection with the Services. This mandate involves in particular the following tasks:
a) The Group Leader shall sign any contractual documents — including the Framework Contract, Orders and Amendments thereto — and issue any invoices related to t the Services on behalf of the Group Members.
b) The Group Leader shall act as single point of contact for the European Commission in connection with the Services to be provided under the Contract. It shall co-ordinate the provision of the Services by the Group Members to the European Commission, and shall see to a proper administration of the Contract.
Any modification to the present agreement / power of attorney shall be subject to the European Commission’s express approval.
This agreement / power of attorney shall expire when all the contractual obligations of the Group Members towards the European Commission in connection with the Services to be provided under the Contract have ceased to exist. The parties cannot terminate it before that date without the Commission’s consent.
Signed in …. on ……….. ………
Name Name
Function Function
Company Company
Agreement / Power of attorney
Model 2
(CREATING THE GROUP AS A SEPARATE ENTITY, APPOINTING A GROUP
MANAGER AND GIVING A MANDATE TO HIM/HER)
We the undersigned:
– Signatory 1 (Name, Function, Company, Registered address, VAT number)
– Signatory 2 (Name, Function, Company, Registered address, VAT number)
– …..
– Signatory N (Name, Function, Company, Registered address, VAT number),
Each of them having the legal capacity required to act on behalf of his/her company,
HEREBY AGREE AS FOLLOWS:
1) The European Commission has awarded the Framework Contract 10203 (« the Contract ») to Company 1, Company 2, …, Company N (« the Group Members »), based on the joint offer submitted by them on … ….. for the provision of “Maintenance and software development of the GESCOMX-SAGAPX-DWH/PUBLICATIONS system and related services" (« the Services »).
2) As co-signatories of the Contract, all the Group Members:
a) Shall be jointly and severally liable towards the European Commission for the performance of the Contract.
b) Shall comply with the terms and conditions of the Contract and ensure the proper execution of their respective share of the Services.
3) To this effect, the Group Members have set up under the laws of ……. the Group ….. (« the Group »). The Group has the legal form of a .…..
[Provide details on registration of the Group: VAT number, Trade register, etc.].
4) Payments by the European Commission related to the Services shall be made through the Group’s bank account.
[Provide details on bank, address, account number, etc.].
5) The Group Members appoint Mr./Ms ……. as Group Manager.
6) The Group Members grant to the Group Manager all the necessary powers to act alone on their behalf in connection with the Services. This mandate involves in particular the following tasks:
(a) The Group Manager shall sign any contractual documents – including the Framework Contract and amendments thereto – and issue any invoices related to the Services on behalf of the Group Members.
(b) The Group Manager shall act as a single point of contact for the European Commission in connection with the Services to be provided under the Contract. He/she shall co-ordinate the provision of the Services by the Group Members to the European Commission, and shall see to a proper administration of the Contract. Any modification to the present agreement / power of attorney shall be subject to the European Commission’s express approval.
This agreement / power of attorney shall expire when all the contractual obligations of the Group Members towards the European Commission in connection with the Services to be provided under the Contract have ceased to exist. The parties cannot terminate it before that date without the Commission’s consent.
Signed in ……….. on ……….. ………
Name Name
Function Function
Company Company
Annex 3 Form for identification of the tenderer
Identification of the tenderer
(to be completed)
acting in the capacity of:
□ member of consortium (specify role ……………………………)
members of a consortium, which are not the co-ordinator, only have to fill in the first paragraph – identity, a contact person and the last paragraph – declaration
□ single tenderer
Information to be included in the contract in case of award
|Identity |Answer |
|Official name of tenderer in full | |
|Official legal form | |
|Country of registration | |
|Statutory registration number | |
|Official address of tenderer in full | |
|(Internet address – if applicable) | |
|VAT registration number | |
|Person(s) designated to sign the contract – name in full and | |
|function. Please indicate if the person(s) are authorised to sign| |
|alone or together* | |
|Bank account |Answer |
|The information should be consistent with the financial | |
|identification form in Annex 2A | |
|Name of bank | |
|Address of branch in full | |
|Exact designation of account holder | |
|Full account number including codes | |
|IBAN code | |
|BIC code | |
|Contact person |Answer |
|For administrative matters | |
|Name in full and title | |
|Function | |
|Company name | |
|Address in full | |
|Telephone number | |
|Fax number | |
|E-mail address | |
|Contact person |Answer |
|for technical matters | |
|Name in full and title | |
|Function | |
|Company name | |
|Address in full | |
|Telephone number | |
|Fax number | |
|E-mail address | |
Declaration by an authorised representative*
|I, the undersigned, certify that the information given in this tender is correct, that I accept the conditions set out in the invitation |
|letter, the tender specifications and the draft contract and that the tender is valid |
|Name in full and title | |
|Function/Position (e.g. “manager”) | |
|Telephone number | |
|Fax number | |
|E-mail address | |
|DATE/ | |
|SIGNATURE | |
* The tender must include documents proving that the person(s) designated to sign the contract as well as the person(s) signing the tender are authorised to do so.
Annex 4 questionnaire for joint bids and subcontracting
This questionnaire only has to be completed if your tender involves a joint bid or subcontracting.
Joint bid
1. Does your bid involve more then one tenderer? Yes No
The questions No 2 – 4 shall be answered only if the answer is affirmative.
2. Please fill in the name of the company having power of attorney for the group of tenderers and acting as a co-ordinator:
3. Please fill in the names of the other companies taking part in the joint offer:
4. If a consortium or similar entity exists, please fill in the name and the legal status of the entity:
Subcontracting
5. Does your bid involve subcontracting? Yes No
If the answer is yes, please complete question number 6, and the next page once for each subcontractor.
6. List of subcontractors:
…….….……………………………….…
…….….……………………………….…
…….….………………………………….
……….………………………………..…
…….….……………………………….…
Reasons, roles, activities and responsibilities of subcontractors.
Please complete this page once for each subcontractor:
Name of the subcontractor:
…….….……………………………….………………………………………..
Official legal form:
…….….……………………………….………………………………………..
Country of registration:
…….….……………………………….………………………………………..
Statutory registration number:
…….….……………………………….………………………………………..
(Internet address, if applicable):
…….….……………………………….………………………………………..
Official address in full:
…….….……………………………….………………………………………..
…….….……………………………….………………………………………..
Contact person:
…….….……………………………….………………………………………..
Telephone number:
…….….……………………………….………………………………………..
Reasons for subcontracting:
…….….……………………………….………………………………………..
Role, activities and responsibilities of the subcontractor:
…….….……………………………….………………………………………..
…….….……………………………….………………………………………..
…….….……………………………….………………………………………..
The volume or the proportion of the subcontracting:
…….….……………………………….………………………………………..
Do you intend to rely on capacities from the subcontractor in order to fulfil the selection criteria? If yes, specify which selection criterion – financial and economic capacity or technical and professional capacity – and be aware that the tenderer must provide the documents which make it possible to assess the selection criteria to the extent that the subcontractor puts its resources at the disposal of the tenderer.
…….….……………………………….………………………………………..
…….….……………………………….………………………………………..
Annex 5 list of documents to be provided in the tender
| |DOCUMENT |Annex to the |Place in the |
| | |specifications |tender |
|Section One: Administrative information and evidence for access to contract |
|* |Duly signed cover letter |--- | |
| |(to be provided) | | |
|* |Financial identification form |2A | |
| |(to be completed) | | |
|* |Legal "entity form" (to be completed) with supporting documents as described in point 2.4 (to be |2B | |
| |provided) | | |
| |Articles of association | | |
| |Proof of registration number and of VAT number | | |
| |Documents showing that the person(s) signing the tender and designated to sign the contract are | | |
| |entitled to do so | | |
|* |Form for identification of the tenderer (to be completed) |3 | |
|* |Questionnaire for joint bids and subcontracting |4 | |
| |(if applicable, to be completed) | | |
|* |If it is a joint bid, a declaration (Agreement/Power of Attorney) signed by legal representatives of|2C | |
| |all the partners of the joint bid: | | |
| |recognising joint and several liability for all the partners of the joint bid for the performance of| | |
| |the contract, | | |
| |giving one of the partners of the joint bid (co-ordinator) power of attorney to represent the other | | |
| |parties to sign and administrate the contract, | | |
| |(if applicable, to be completed) | | |
|* |If subcontracting is involved in the bid, a letter of intent by each subcontractor stating its |--- | |
| |intention to collaborate with the tenderer if the contract is awarded to him | | |
| |(if applicable, to be completed) | | |
|* |This list of documents to provide (to be completed) |5 | |
|Section Two: Documents relating to the exclusion criteria |
|* |Declaration on grounds for exclusion (to be completed) with the following supporting documents (to |6 | |
| |be provided): | | |
| |a recent extract from the ‘judicial record’ or equivalent | | |
| |a recent certificate of having fulfilled obligations relating to the payment of social security | | |
| |contributions or equivalent | | |
| |a recent certificate of having fulfilled obligations relating to the payment of taxes or equivalent | | |
|Section Three: Documents relating to the selection criteria |
|a) financial and economic capacity |
|* |Economic and Financial capacity questionnaire (to be completed) Including documents mentioned there |7 | |
| |(to be provided) | | |
|b) technical and professional capacity |
|* |Company Form (to be completed) |8 | |
|* |Set of PARFs (to be provided) |9 | |
|* |Set of Best Practice Documents (to be provided) |10 | |
|Section Four: Documents relating to the technical award criteria |
|* |Document presenting Tenderer's approach to quality assurance and to project management in software |--- | |
| |development (to be provided) | | |
|* |Document presenting Tenderer's proposal describing the takeover phase (to be provided) |--- | |
|* |Document presenting Tenderer's proposal describing the handover phase (to be provided) |--- | |
|* |Document presenting Tenderer's proposal of a service level-agreement (to be provided) |--- | |
|Section Five: Documents relating to the financial award criteria |
|* |Price schedule (to be completed) |1 | |
|* |Estimation form (to be completed) |1 | |
Annex 6 declaration on the grounds for exclusion
|DECLARATION |
1. Pursuant to Council Regulation (EC, Euratom) No 1605/2002 of 25 June 2002 on the Financial Regulation applicable to the general budget of the European Communities (OJ L 248/1 of 16 September 2002, as amended), I, the undersigned, declare on my honour that the following grounds for disqualification do not apply to the company or organisation which I represent, or to me (if the tenderer/subcontractor is a natural person):
(a) being bankrupt or being wound up, having one's affairs administered by the court, having entered into an arrangement with creditors, having suspended business activities, being the subject of proceedings concerning those matters, or being in any analogous situation arising from a similar procedure provided for in national legislation or regulations;
(b) having been convicted of an offence concerning professional conduct by a judgement which has the force of res judicata;
(c) being guilty of grave professional misconduct proven by any means which the contracting authority can justify;
(d) not having fulfilled my obligations relating to the payment of social security contributions or my obligations relating to the payment of taxes in accordance with the legal provisions of the country of establishment or with those of the country of the contracting authority or those of the country where the Contract is to be performed;
(e) having been the subject of a judgment which has the force of res judicata for fraud, corruption, involvement in a criminal organisation or any other illegal activity detrimental to the Communities' financial interests;
(f) being subject of the administrative penalty for being guilty of misrepresentation in supplying the information required by the contracting authority as a condition of participation in the procurement procedure or for failing to supply an information, or for being declared to be in serious breach of his obligation under contract covered by the budget..
For (d), the applicant must submit, recent certificates issued by the competent authority of the country concerned showing that his or her situation is in order.
The Commission will accept as sufficient evidence that none of the cases quoted in (a), (b) or (e) applies to the tenderer, the production of a recent extract from the "judicial record" or, failing this, of an equivalent recent document issued by a competent judicial or administrative authority in the country of origin or residence, showing that these requirements have been met.
Where the country concerned does not issue documents or certificates of the kind required above, they may be replaced by a sworn, or failing this, a solemn statement, made by the interested party before a judicial or administrative authority, a notary or a qualified professional body in the country of origin or providence.
2. Pursuant to Council Regulation (EC, Euratom) No 1605/2002 of 25 June 2002 on the Financial Regulation applicable to the general budget of the European Communities, published in Official Journal No L 248 of 16 September 2002, as amended, I declare on my honour that:
- neither the company or organisation that I represent nor any member of its staff or of its board or any of its directors is placed in a situation of conflict of interests for the purposes of this tendering procedure;
- I will inform the Commission, without delay, if any situation of conflict of interests or that may lead to a conflict of interests arises;
- I have not been guilty of misrepresentation in supplying the information required by the awarding authority as a condition of participation in the contract procedure or failed to supply this information;
- the information given to the Commission for the purposes of this tendering procedure are accurate, honest and complete.
The Commission reserves the right to check this information.
Done at ....................................................., on ..................................................
Signature:
Name of the signatory(ies) of this form (representative(s) legally authorised to represent the tenderer vis-à-vis third parties and acting on behalf of the aforementioned company or organisation)
…………………………………………………………………………………….
Name of the company/organisation represented (if applicable):
…………………………………………………………………………………….
Legal address:
…………………………………………………………………………………….
Annex 7 Economic and financial capacity questionnaire
| |2008[3] |2007 |2006 |
|Total turnover | | | |
|Turnover related to the requested tasks | | | |
| |
|Total assets / liabilities | | | |
| |
|Fixed assets | | | |
|Intangible assets | | | |
|Tangible assets | | | |
|Financial assets | | | |
|Current assets | | | |
|Debtors / debts due within one year | | | |
|Debtors / debts due after one year | | | |
|Cash (bank & hand) | | | |
|Stocks | | | |
|Other current assets | | | |
| | | | |
|Capital | | | |
|Subscribed capital | | | |
|Reserves | | | |
|Profits and loss brought forward | | | |
|Provisions | | | |
|Creditors | | | |
|Short term bank debt (to be paid within one year) | | | |
|Long term bank debt (to be paid after one year) | | | |
|Short term non-bank debt (to be paid within one year) | | | |
|Long term non-bank debt (to be paid after one year) | | | |
|Other debts | | | |
| |
|Turnover | | | |
|Other operating income | | | |
| |
|Costs of staff | | | |
|Costs of material | | | |
| |
|Gross operating profit | | | |
|Net operating profit | | | |
|Financial profit | | | |
|Profit / loss on ordinary activity | | | |
|Profit / loss for the financial year | | | |
Company: Date:
Name: Signature:
The following documents shall be attached:
• Balance sheet for the year 2008 (if not available, so for 2007);
• Profit and loss account for the year 2008 (if not available, so for 2007);
• If financial statements have been audited during the any from the last three years, copy of auditor's statement (cover page of the auditor's report);
• Evidence of professional risk indemnity insurance.
Annex 8 Company Form
|Tenderer [4]: |
|acting as : |
|member of consortium (specify role ……………………………) |
|main contractor |
|subcontractor |
|Legal form of tenderer : |
|Date of registration: |
|Country of registration: |
|Registration number: |
|VAT number: |
|Registered address of tenderer: |
| |
|Usual administrative address of tenderer: |
| |
| |
|Person(s) authorised to sign contracts (together or alone) on behalf of the tenderer: |
|Surname, forename, title (e.g. Dr., Mr., Ms. ), function (e.g. manager…). |
| |
| |
| |
|Contact person for this call for tenders: |
|Surname, forename, title (e.g. Dr., Mr., Ms.…), function (e.g. manager…), telephone number, fax number, address, e-mail. |
| |
| |
| |
| |
|Structure of the company: |
|Number of technical staff : 2007: 2008: 2009: |
|Dispersion regarding the different types of services required in the scope of this call for tender : |
|Consulting : 2009: |
|Project management : 2009: |
| |
|Number of non-technical staff : 2007: 2008: 2009: |
|Dispersion per category : |
|Management : 2009: |
|Sales : 2009: |
|Secretaries : 2009: |
| |
|Total technical staff permanently employed by the tenderer, in the tenderer’s IT division and invoiced for provision of: |
|only fixed price services : 2009: |
|only time and means services : 2009: |
|both : 2009: |
| |
|Total technical staff non-permanently employed by the tenderer, in the tenderer’s IT division and invoiced for provision of: |
|only fixed price services : 2009: |
|only time and means services : 2009: |
|both : 2009: |
|Facts and figures about the company: |
|Current number of active accounts per activity sector: |
|Administration : |
|Banking : |
|Industry, Telecom and Commerce : |
|Energy : |
|Current number of technical staff without contract : |
|Staff turnover(in %) : 2006 2007 2008 |
Annex 9 Project / activity reference forms ( PARFs)
The project/activity reference form must be used to give details about relevant projects and/or activities the tenderer wants to present as proof of experience with the delivery of services comparable to those defined in the Technical Specifications.
General rules:
1. The use of the annexed project/activity form is mandatory. Only projects and/or activities references submitted by using the annexed form will be evaluated.
2. PARFs must be accompanied by certificates of satisfactory execution, specifying wether the services have been carried out in a professional manner.
3. A submitted PARF should be relevant in terms of volume and subject of this call for tender. (number of man-days/technologies/methodologies/tools). The accepted PARFs shall cover at least:
• at least 1500 relevant man-days[5], all PARFs together of which at least 50 % of man-days ANA-PROG per PARF;
• at least 300 man-days per PARF.
Projects or activities that do not conform will be eliminated.
4. Minimum number of PARFs to be submitted: 1.
5. Maximum number of PARFs to be submitted: 5.
6. One PARF can fulfil all the specific requirements at the same time.
7. If the tenderer submits more than 5 forms, only the first 5 as found in the offer will be analysed in the selection procedure.
8. PARFs shall not be outdated; the project shall be executed during the period 2006-2009. Projects which started before 31/12/2005 and which are ongoing may be submitted, but only with regards to its part executed during the reference period in question.
9. Framework contracts are acceptable as reference, but only with regard to their executed part during the reference period.
10. A PARF consists of three pages. All three pages must be completed. Adding of supplementary pages is not permitted.
Project/Activity Form (PARF)
PARF No: …..… page 1 of 3
Tenderer: ……………………………..…………………………………………….
Project/Activity name: ……………………………..………………………………
Client Information
|Client Name: ………………………………….……..……………………… |
|Client Economic Sector: ……………………………..……………………… |
|Public/Private sector? [6] |
|Contact persons: (at least one) |
|Names Function: Tel. E-mail |
|1. ……………………………..……………………………..………………………………… |
|2. ……………………………………………………………………………………………… |
Organisation, planning, volumes
|Principal contractor for this project/activity (check the appropriate): |
|Tenderer ( Other => please specify (consortium leader, consortium member, subcontractor...): |
|…………………………………….. |
| |
|Principal location for execution of this project/activity: |
|Tenderer's premises |
|Client's premises |
|Other: ……………... |
| |
|Fixed-price contract? (Y/N): ……. |
|Based on a service level agreement? (Y/N):……. |
| |
|Start date (mm/yyyy): ………………… End date (mm/yyyy): …………… (actual/planned 1) |
|Total value of the project executed during the period 2006-2009: ……..……………………………………. EUR |
|Value of the related services executed by the tenderer during the period 2006-2009 ……………………….. EUR |
| |
|Total number of man-days / Number of man-days provided by tenderer's own technical staff per profile (during the period 2006-2009) |
|Profile: …………. Man-days: …………… Profile: …………… Man-days: …………. |
|Profile: …………. Man-days: …………… Profile: …………… Man-days: …………. |
Project/Activity Form (PARF)
PARF No: …..… page 2 of 3
Tenderer: ……………………………..………………………
Project/Activity name: ……………………………..………………………………
Description of Project/Activity
|Explain the relevance of this project: |
| |
| |
| |
|Project/Activity type (development, maintenance, support, study): |
| |
| |
|Internet address of the project when applicable: |
|Description (objectives, executed tasks, main functions developed, data volume, etc.): |
| |
| |
| |
| |
| |
|This PARF demonstrates the specific experience required in the following domain: |
|Tasks related to NATURAL/ADABAS development / Amount related to NATURAL/ADABAS development [7] ……… EUR |
|Tasks related to ORACLE datawarehouse development in relation with Business Intelligence / Value related to ORACLE datawarehouse development in |
|relation with Business Intelligence: ………. EUR |
|Tasks related to project management |
PARF n°: …..… page 3 of 3
Tenderer: ……………………………..………………………
Project/Activity name: ……………………………..………………………………
Technical environment
|Project methodology: |
| |
| |
| |
| |
|Software tools (Name of product(-s) used; Type of software: open source, proprietary, in-house development, etc; Purpose of the tool): |
| |
| |
| |
| |
| |
| |
| |
|Hardware/operating systems involved: |
| |
| |
| |
|Multilingual coverage: |
| |
| |
| |
| |
|Others: |
| |
| |
| |
| |
| |
| |
| |
| |
Annex 10 Best practice documents
In order to enable the Publications Office to assess the quality of the work that the tenderer intends to provide with respect to the services requested by the Publications Office, each company should provide extracts of real documentation, which has been produced in order to accomplish similar tasks as the ones asked by the Publications Office. This means that the tenderer shall select extracts of real existing documentation. For each type of documentation a table of contents and a sample of the contents of about 5 to 10 pages shall be presented.
The designation used for the different types of documentation may differ from the company’s code of practice. In this case, the functional equivalent should be submitted.
The Publications Office reserves the right to consult the complete document, if necessary. The documents handed in and any other information obtained during this call for tender are considered confidential by the Publications Office and the project owner.
List of best practice documents
1 Strategy and requirements
• DOC-SYS-REQ: System requirements document. Document which specifies the functional requirements or specifications of a system. It will typically include the use cases.
2 Design
• DOC-DET-DES: Detailed design document. This document is intended for a non-technical audience in order to provide a detailed view of the design of the system. This type of document shall contain all the specific details concerning the design of the system based on the use cases or functional requirements.
• DOC-SOF-SPE: Software specification document. Document defining the different modules of a system: functionality, algorithm, interfaces, etc. This document is intended for a technical audience in order to provide all the technical specifications, details and constraints concerning a software development project or IT system.
• DOC-TES-PLA: Test plan for an information system or an important software component. This type of document shall typically show all the specific test cases to be executed after a software development in order to ensure that all the functionalities work as defined in the system requirements or use cases.
3 End-user documentation
• DOC-USE-MAN: User manual. Document instructing the user on how to use a specific system.
4 Technical documentation
• DOC-INS-MAN: Installation manual. Documentation describing the installation procedure of an information system. This document is intended for a technical audience in order to instruct the client exploitation teams how to install an information system which has been specifically developed for the client company. No commercial off-the-shelf software installation instructions shall be accepted.
• DOC-OPE-MAN: Operation manual. Documentation including all information to ensure the daily operation of an information system (user management, security, access, start, stop, back-up...). This document is intended for a technical audience in order to instruct the client exploitation teams how to manage an information system which has been developed for the client company. No commercial off-the-shelf software operation instructions shall be accepted.
5 Project control
• DOC-PRO-MAN: Project management document. Set of documents used to manage an IT project, including, but not limited to, planning, risk analysis, project meetings, resources, communications, software deliverables and acceptance protocol).
• DOC-QUA-PLA: Quality assurance plan. Document specifying the means, procedures and resources guaranteeing the quality of the services provided including the inputs, outputs, metrics and processes.
• Annex 11 Quality expectations and service proposals
The tenderer’s bid must include the four documents described hereafter.
These documents define relevant aspects of the future cooperation between the tenderer and the Publications Office. The proposals must be in accordance with the terms of the technical specifications and the draft contract.
It is very important to take the following remarks into account:
• Maintenance and software development of the GESCOMX-SAGAPX-DWH/PUBLICATIONS system: the contractor will maintain and develop the system for the logistic and commercial management of all general publications and their dissemination including the Official Journal. The system is composed of 3 interfaced applications (GescomX, SagapX and the Datawarehouse Publications), Natural programming, Adabas and Oracle databases and interfaces with other applications using mainly XML. Business Objects is the standard reporting tool used by the DHW (Datawarehouse Publications).
The contractor must have an excellent in-depth knowledge of the above mentioned technologies and should be able to perfectly and rapidly understand all aspects of the technical and functional specifications, organizational- and operating environment of the system.
The successful bidder will also be able to work under pressure, since this is a production critical system.
The contractor should also be able to work on a multi-national/multi-cultural environment, have an excellent reactivity, a proactive behaviour and fully master modern development methods (Merise, RUP/UML, RAD…) and quality standards (such as ISO 9001 or equivalent).
A constant and efficient reporting to the Publications Office is also requested.
• Elaboration of specifications, functional analysis related to the GESCOMX-SAGAPX-DWH/PUBLICATIONS system: main activities will consist in the elaboration of functional specifications as requested. In-depth knowledge of all "business analysis knowledge areas" related to the project, include:
o Requirements planning and management
o Requirements analysis
o Requirements communication
o Solution assessment and validation
The contractor will have a wide range of Soft Skills, including knowledge of the business, empathy, customer oriented approach, negotiation skills, motivation, and ability to work in a multi-cultural/multi-lingual environment among others.
The contractor will have wide experience and proven ability producing detailed, accurate and solution-oriented documentation. IT awareness is compulsory in order to deliver a complete set of clear, structured requirements.
The successful bidder will also be able to work under pressure, since this is a production critical system.
There will be regular contacts with the Publications Office’s project leader and frequent and detailed reporting is envisaged.
• End-user support and production and administration reporting related to the GESCOMX-SAGAPX-DWH/PUBLICATIONS system: permanent attention to the end-user needs and requests will be necessary.
The contractor will have wide experience and proven ability providing end-user support services. The role sought is based on a customer oriented approach, prompt response times, high quality of the delivered services, an eye for the detail, a sense of responsibility and a pro-active attitude to have things done and resolved as quick as possible. Willingness to learn the core business of the Publications Office in order to provide an adequate quality of service is also expected. The contractor will have a wide range of Soft Skills, including empathy, customer focus, negotiation skills, motivation, and ability to work in a multi-cultural/multi-lingual environments among others.
Good knowledge of the basic technical elements behind the system is also requested. Understanding the basics of Natural, Adabas and Oracle databases, SQL, XML and Business Objects is a must.
In brief: for this role, a combination of both customer facing attitude and good technical skills and knowledge are required.
Documents to provide (1/4): Tenderer’s approach to quality assurance and project management in software development
The tenderer must provide a document of a maximum of 15 A4 pages font-size 12 describing the company’s approach in order to ensure and to maintain a very high level of quality concerning the services related to the subject of this call for tender.
The document should cover at least the following topics:
• Overview of the company’s quality assurance proposal.
• Overview of the company’s project management proposal: standards or methods applied by the tenderer to manage projects, especially concerning scope management, risk management, change management and time and cost management.
• Production of documentation procedure proposed by the tenderer including any software tools used. In addition, the tenderer shall describe how they will handle document version control and naming conventions.
• Overview of the company's proposal to conflict resolution in complex environments related to the activities. Due to the specific environment where it takes place, different conflicts may arise during the life of the project.
• Overview of the software development proposal in general used by the company. The description has to list the different phases of a software development project, which in general are passed through. For each phase, methods and tools which are used have to be mentioned. The tenderer will describe how the source code is managed and how versions are handled.
A clear reference to the methods proposal for technical and functional software testing has to be made. Commercial tools or proprietary solutions will have to be clearly indicated. The tenderer will explain the advantages and possible limitations of using the proposed tools in the framework of the GESCOMX-SAGAPX-DWH/PUBLICATIONS system. In addition, the Publications Office would like to stress the fact that performance testing is a critical activity that has to be carried out for every software delivery. The tenderer will clearly indicate the methods and technologies proposed for software performance testing to be used in such environments and the advantages that they will bring along.
The company's proposal to improve the quality of software deliveries should be also explained in detail. If the tenderer owns specific examples they will be provided as well.
• Overview of the company's proposal to the provision of end-user support services, including reporting.
The contractor will be sometimes requested to provide a detailed report of a given incident or production problem in order to draw conclusions and take corrective actions.
The tenderer’s attention is drawn to the fact that the document should not be theoretical.
Documents to provide (2/4): Tenderer’s proposal describing the takeover phase
The tenderer has to provide a document of a maximum of 10 pages A4 font-size 12 describing the takeover phase. The tenderer will provide the required information:
• The proposal has to include the set-up of a development and testing environments at the contractor’s premises and the familiarisation of the tenderer’s staff with the applications and the documentation. In this context the tenderer’s staff means the members of the staff directly concerned by the contract.
• The proposal has to include familiarisation of the tenderer’s staff with the business processes, the different key actors, the production of publication cycles, the situation and status of the systems subject of this call for tender and the documentation, the different proposals for improvement and the foreseen evolutions.
• The proposal has to include the process to acquire the knowledge of the different procedures, applications and the related documentation. Proposals for quality control of the delivered services have to be also defined at this stage in order to have them fully operational as soon as the takeover phase is finished.
• The proposal will include a list of all tasks foreseen by the tenderer. For each task at least a brief description of the content and deliverables/resources associated and the estimated effort in man-days per profile have to be clearly indicated.
• The proposal shall provide a description of the reporting foreseen, when it will be delivered according to the proposed planning and the content of the reports. It shall include clear indicators of achievement and areas for improvement.
In order to ensure a valid comparison of the different offers the proposal should be limited to a start-up phase of 3 weeks.
A final report describing what has been done, achievements, strengths and risks has to be produced at the end of the start-up phase.
The proposal is purely indicative. The Publications Office has no obligation to accept the tenderer’s proposal in case of award of the contract.
Documents to provide (3/4): Tenderer’s proposal describing the handover phase
The tenderers will have to foresee a handover phase at the end of the contract in order to handover their works to a future contractor and/or to the Publications Office.
The tenderer has to provide a document of a maximum of 10 pages A4 font-size 12 describing the handover phase.
In the proposal the tenderer will define the works, processes and methods to be transferred to the next contractor, including:
• handover of the complete up-to-date source code of the application and the related documentation;
• handover of all documentation and accurate and detailed reports of the project status at the time of the handover in terms of present and future evolutions;
• handover of the documentation related to the detailed reports of the project situation in terms of ongoing incidents, envisaged resolutions and proposals for improvement.
See section 4.2.7.2 of the Technical Specifications for the specific information required during the handover phase.
The proposal will include a list of all tasks foreseen by the tenderer. For each task at least a brief description of the content and deliverables/resources associated and the estimated effort in man-days per profile have to be clearly indicated.
The proposal shall provide a description of the reporting foreseen, when it will be delivered according to the proposed planning and the content of the reports. It shall include clear indicators of achievement and areas for improvement.
In order to ensure a valid comparison of the different offers the proposal should be limited to a handover phase of 3 weeks.
The proposal is purely indicative. The Publications Office has no obligation to accept the tenderer’s proposal in case of award of the contract.
Documents to provide (4/4): Proposal to fulfil the conditions of the Service Level Agreement
The tenderer has to provide a proposal of a maximum of 15 pages A4 font-size 12 describing the SLA.
As a key element of his offer, the tenderer has to deliver a proposal describing in detail how the requested service will be delivered, guaranteeing a permanent high level of availability, technical competence and service quality according to the specific SLA as defined in section 4.3 of the technical specifications.
The proposal cannot overrule the terms and conditions defined by the contract and by the technical specifications.
The tenderer’s proposal is considered as a formal engagement. The contractor is obliged to implement and to follow the foreseen service elements and to apply the proposed procedures.
The proposal should cover, at least, the following aspects:
• Organisation
Description of the internal organisation and the procedures the tenderer will use and/or set up in order to deliver the requested services (see Technical specifications, section 4.1) according to the SLA specified (Technical specifications, section 4.3). The suitability of the proposed organization should be explained in detail.
For each role mentioned in the tenderer’s proposal it should be clearly indicated who will fulfil this role. Possible back-up persons should be mentioned.
The tenderer may include the escalation matrix in this section, with a clear reference to the level and the position of the proposed person for each level.
• Request handling
The proposal should define the procedures foreseen to handle different types of requests, which may arise. See Technical specifications, section 4.1 for a detailed description of the possible services that may be requested. Note also the requirements in terms of SLA related to handling requests.
• Methods
Common or proprietary methods proposed by the tenderer in order to deliver the requested service should be indicated. The Publications Office is particularly interested in the specific tenderer commitments in terms of methods, resources and procedures in order to deliver the services requested under the conditions specified in the SLA for each section of point 4.3 of the technical specifications. The tenderer should not repeat the information provided in the ‘Tenderer’s approach to quality assurance and project management in software development’-document. A reference can be made if the specific information concerning the fulfilment of the SLA has been already described in that document.
The Publications Office would like to stress once more the requirements in terms of response times and quality required in the framework of the systems subject of this call for tender.
• Key Service Performance Indicators
The tenderers must indicate the key performance indicators foreseen to measure effective service delivery in addition to the ones already defined in section 4.3 SLA. For each proposed KPI, a clear target shall be indicated as well as a description of the effective way those indicators will be measured and calculated. The Publications Office is particularly interested in KPIs and targets related to submission of offers and delivery of documentation, analysis, software packages and end-user services. The targets proposed cannot override any other target as specified in the technical specifications or the draft contract.
• Infrastructure
Specific, detailed and accurate information has to be provided concerning the tenderer’s technical infrastructure, which will be implemented in order to deliver the requested services. The description has to include an outline of the tenderer’s policy to keep his infrastructure up to date.
A complete description of the servers, workstations, network resources, licences and any other technical aspect related to the development environment which the contractor proposes to use, will be given. In addition, it should be described how the source code management will be implemented.
• Staff’s competences and knowledge transfer
Description of the measures foreseen to assure and to preserve a high level of competence of the tenderer’s staff concerned by the contract with respect to technical evolution of the domain. The procedure foreseen to assure the knowledge transfer in case of replacement of personnel has to be indicated. The tenderer will assure that any change will have the minimum impact on the stability of the project. See also restrictions for personnel replacement in the SLA section.
Annex 12 Technical environment and standard operating procedures of the Publications Office
12.1. Purpose of the document
This document gives a general overview of the technical environment of the Publications Office - hereafter referred to as the Office – as well as some general rules linked to the technical organisation of the Office and applicable to all applications hosted at the Office.
12.2. Disclaimer
The information contained in this annex reflects the situation in force at the Office at the time of publishing of this document.
It does not commit the Office for the future evolution of its technical environment. It is mainly given here for clarity reasons. Changes can happen at any time and without any prior notification from the Office.
However, the specific environment to take into consideration for a each project - especially the exact software versions - will be fixed at the very beginning of the project. This also includes the rules to apply by both parties in order to modify this environment.
The Office strongly advises the contractor/supplier to ask for clarification in case of doubt about the contents of this document. A meeting will anyway take place at the very beginning of the project to answer questions and, to a certain extent, examples of the expected documents could be provided.
12.3. Technical environment of the Office
a) Introduction
The Office makes a distinction between systems used for office automation and administrative information systems on the one hand and systems used for production on the other hand. The quality of service and the constraints of availability are more tying on the production systems, since external partners with contractual agreements are already in place. Another important difference between these two types of information systems is linked to their architecture. The production information systems are usually spread over several servers and include complex production chains with processing on all nodes, whereas administrative and office automation systems are simpler and frequently use a one-to-one relationship between a server and its clients.
However, the same basic infrastructure is made available for both types of information systems, as described hereafter.
The Office developed a DRP (Disaster Recovery Plan) making use of 2 different geographical sites and based on the following principles:
• The DRP is conform to the Contingency Plan of the Office
• The data replication between the 2 sites is synchronous
• Both sites are hosting "active" applications
Unix is the recommended environment for production systems while office automation systems are normally hosted on Windows servers.
The Office fosters professional methods of managing systems and therefore implements monitoring tools for critical systems and produces statistics on the use of resources and on the quality of service provided.
The Office promotes the implementation of the three tiers architecture, using thin clients, application servers and mainly Oracle databases because of performance, scalability and flexibility reasons.
The Office also promotes the virtualisation of services and the use of abstraction layers in order to increase flexibility. This implies in particular that:
• All web-based applications should allow the deployment and the correct operation behind any http reverse proxy chain.
• All applications should allow virtual hosting i.e. the binding of the application to only some of the IP addresses/hostnames of a multihomed server
• All applications should allow easy integration in the DRP of the Office
The Office’s core business applications are tested on dedicated machines, before the production is spread over several production servers tightly interconnected.
On the hardware side, the technical data processing infrastructure is currently made of several components that can be grouped into the following categories:
• Network and telephone
• Storage and backup systems
• Workstations and peripherals
• Unix servers
• Windows servers
b) Network and telephone
The Office’s staff is spread over several buildings. The Office’s buildings use a unique cabling system for the telephone as well as for the TCP/IP network for data. This structured cabling system uses copper connections category 5 (or higher) to desktop computer, and optical fibre connections for backbones and to high-end servers with a throughput up to 1 Gbps. The patching mechanism relies on the AT&T 110 standard and the RJ45 standard. Both networks deal with about 1000 telephones and 1000 Ethernet devices, and will continue to grow with potential new sites.
The telephone system is based on three Siemens Hicom telephone exchanges, carrying out all dial-up services, regular dial-up connections to contractors, and even backup connections for leased lines. The Office telephone network is part of the European Commission telephone network, but it’s fully managed by the Office network team. Most telephone sets are digital but some are still analogue. Videoconferencing is also made available to the end-user via ISDN gateways.
The Wide Area and the Metropolitan Area Networks (between buildings) use leased lines, either over dark fiber high speed connections (1 Gbps) or over 2 Mbps connections to the PSTN[8]. IP multiplexers are deployed to share high speed lines between voice and data.
The following picture shows the interconnection of the TCP/IP network of the Office.
[pic]
In particular, connections with the contractors working for the Office use 2Mbps leased lines or the EURO ISDN network for lower speed data transmission. These dial-up services are available through Basic Rate1 or Primary Rate2 interfaces of a TCP/IP router. Generally, FTP is used to exchange data with the contractors working for the Office.
The TCP/IP network is also interconnected with the network of the European Commission that is connected to the Internet and to the TESTA II network (Trans-European Services for Telematics between Administrations). The TESTA II network allows the Office to establish private connections with most of the national Administrations of the EU Member States and most of the EU Institutions.
All accesses that make use of the network of the European Commission (e.g. Internet accesses) have to comply with the general security rules of the Commission. This also implies that all sub-mentioned networks are interconnected through stateful inspection firewalls.
Three Windows servers running the MRS software offer fax services and are part of automatic production chains in the daily publishing process. The fax servers are running MRS of Cycos. These systems also integrate the voice mail system with the Office e-mail server in the computer telephone integration.
c) Storage and backup systems
The Office has decided to strengthen the quality and reliability of the data by centralising the administration of the data storage service on storage systems such as EMC² (mainly for production systems) and Sun Microsystems T3 (mainly for non-production systems).
Generally raid1 is used for production systems while raid5 is used for non-production systems. Around 20 Terabytes of data are currently made available to end-users and applications. This amount is steadily increasing as new users arrive and as more usage of electronic documents is spread in the Office; the increase rate is about 30%/year.
The backup system is currently under revision to implement an improved backup strategy based on LAN-less and server-less procedures used in a SAN[9] context.
The Office will focus its storage and backup strategy on:
• Online storage consolidation (SAN)
• Storage on demand
• Advanced centralised backup
• Archiving
The current backup policy and procedures are described in Appendix A.
d) Workstations and peripherals
In terms of software, the standard configuration for the workstations is the following:
|Type |Product/Version |
|Operating system |MS Windows XP SP2 |
|Office automation suite |MS Office 2003 |
|Web browser |MS Internet Explorer 6 SP2 (with 128 bits encryption) |
|XML tools |XMLSpy (development) |
| |XMetal (Authoring) |
| |Saxon (XSLT engine) |
| |XSV (XML instance validation against XML schemas) |
| |RXP (XML instance validation against DTD) |
|Reporting tools |Business Objects 5.1 – 6.x |
|Mail client |MS Outlook 2003 |
|Connection middlewares and runtimes |SQL*Net 2.3.4 |
| |NET 8.1.7 - NET 9.x |
| |ODBC |
|Anti-virus |McAfee VirusScan 8.1 |
Some other local productivity tools (Visio, Microsoft Project...) could also be found on the workstations as well as more specialised tools which are used for publishing (Adobe Photoshop, QuarkXPress, Indesign ...).
The Office can sometimes have to apply hotfixes to ALL workstations without any prior notification if deemed necessary (e.g. for security reasons).
A small number of workstations are Unix-based or Macintosh-based (for DTP).
In terms of hardware, the workstations are ranging from Pentium III 850 MHz to Pentium 4 2.5 GHz with 128 to 512 MB of memory.
Various types of peripheral equipment are also installed, such as local and remote printers, faxes, scanners, CD burners, etc.
All workstations are clients of the Landesk Workstation Manager server, which allows remote control and software/hardware inventory.
Local data on the workstations is not backed up and users are therefore encouraged to use only shared resources for storing valuable/persistent information.
e) Unix servers
The Office computing centre hosts more than 40 Sun Microsystems servers mainly based on the Sun Fire platform, ranging from the SF V120 up to the SF25000. This also includes SF3800, SF4800 and SF6800 servers. The CPU's are mainly Ultra Sparc III+ at 1200 MHz.
In terms of software, the following table gives an overview of the main products used:
|Type |Product/Version installed |Product/Version recommended for all new |
| | |developments |
|Operating system |Sun Solaris 2.6 - 8 – 9 and 10 |Solaris 10 |
|DBMS |Oracle from 8.0.5 to 10g Rel 2 |Oracle 10g Rel 2 |
| | |Character set: AL32UTF8 |
|Text retrieval |Oracle Intermedia/Context |Oracle Intermedia/Context |
|Web servers |Sun ONE Web Server |Sun ONE Web Server 6.1 |
| |Apache 2.x |Apache 2.x |
|Application servers |ColdFusion MX6.1 |ColdFusion MX6.1 |
| |Oracle iAS 9.0.2 |Tomcat 4.x/5.x |
| |JBoss 2.4 |BEA WebLogic 9.2[10] |
| |Tomcat 4.x | |
|Internet portal |Eversuite 3.5 |Eversuite 3.7 or above |
|ERP |Oracle Financials 11i |Oracle Financials 11i |
|Programming languages |Java 1.4.x/1.5.x |Java 1.5.x |
|Scripting languages |Perl 5.6 |Perl 5.8 |
| |sh/ksh |sh/ksh |
|Workflow/Document management systems |OT Livelink 9.1 SP3 |Documentum Content Svr 5.3 or above |
| |DORIS 3.51SP3 | |
| |Documentum Content Svr 5.2.5 | |
| |(incl CRS/DTS module) | |
|Reporting tools |Business Object WebI 2.7 (hosted at DIGIT/DC) |Business Object WebI 2.7 (hosted at DIGIT/DC) |
|XML related tools |XSV (XSML Schema) |XSV (XSML Schema) |
| |RXP (DTD) |RXP (DTD) |
| |SAXON (XSLT) |SAXON (XSLT) |
|Middelware |WOOD[11] |WOOD |
|Monitoring tools |BigBrother 1.9 |N/A |
| |TeamQuest | |
|Backup |Networker 7.2 |N/A |
More than 60 Oracle instances (production + test) are currently installed and about 100 web servers are installed.
Monitoring and reporting tools have been built around small third-party products and in-house developments.
For critical applications, Sun Cluster installations have been built.
In general, application processes exchange data either by mail or by FTP using a dedicated and in-house developed proprietary tool (WOOD – Worldwide Object Dispatcher).
Besides the exchange of data (files) between processes – eventually running on distinct servers – this tool allows the triggering of processes based on the arrival of a file in a predefined directory. The tool is written in Perl and uses normally FTP as underlying protocol but could theoretically use whatever standard file transfer protocol (e.g. scp). Due to the asynchronous character of this tool, the WOOD cannot guarantee the eventual sequencing of the data exchanged. If sequencing is an issue, it should be managed at application level.
The Office strongly advises the contractor/supplier to ask for practical implementation guidelines before to start any development that could require integration/interaction with the WOOD.
The standard file system organization (directory structure) for the Unix servers is described in Appendix B.
Direct dependencies between servers (e.g. NFS mounts, DB links, ...) are generally prohibited.
f) Windows servers
The Office computing centre hosts about 60 MS Windows servers in a Windows 2003 Active Directory domain. Some servers are virtual machines running on VMware. All new physical servers are 2 or 4 CPU servers. Some are installed in cluster mode (for critical data and processing).
Besides standard functions like user authentication, roaming profiles, home directories, shared drives (public/group) and print services that are spread over several servers in order to improve reliability and performance, the Windows servers also host services like email, fax gateways, standalone applications and other small information systems (in-house developments, automated tasks using Microsoft Office products, small SQL server DB, IIS servers with Coldfusion, etc.).
|Type |Product/Version installed |Product/Version recommended for all new developments|
|Operating system |MS Windows 2000 Server SP4 |MS Windows 2003 Server |
| |MS Windows 2003 Server |standard edition/enterprise edition |
| |standard edition/enterprise edition | |
|OS virtual servers |VMware ESX Server 2.51 – 3 |VMware ESX Server 3 |
|DBMS |MS SQL Server 2000 |MS SQL Server 2000 |
|Web servers |IIS 5 – 6 |IIS 6 |
|Application servers |ColdFusion MX6.1 -7 |ColdFusion MX7 |
|Programming languages |Visual Basic .Net |Visual Basic .Net |
|Mail servers |MS Exchange 2003 |MS Exchange 2003 |
|Reporting tools |Business Objects WebI 2.7 |N/A |
|Backup |Networker 7.2 |N/A |
|Anti-virus |McAfee VirusScan 7.1 |N/A |
| |Trend Micro Scan Mail | |
For business critical reasons, Windows clusters host the Exchange server with about 1000 mailboxes, the shared drives and the disk spaces accessible to all end-users. All production data is stored on the SAN.
Regarding security on the server side, anti-virus checking is performed on the Microsoft Exchange mailboxes and regularly on file systems.
Appendix A: Current backup policy and procedures
A.1. Categories of backup jobs
The following backup jobs are distinguished:
• full backup: backup of all data.
• level backup (differential backup): backup of all data changes since the last lower level backup (full backup corresponds to level 0). Only one level is currently defined. Thus, level backups are always performed with respect to a full backup.
• incremental backup: backup of data changed since the last backup, independently of its type.
A.2. Backup policy:
• All Unix and Windows servers are clients of one Unix central backup server running Legato Networker. This server stores the backup sets on one tape library. This library is able to handle up to 1200 tapes and is connected to the SAN.
• The jobs are scheduled between 8 p.m. and 2:30 a.m. The effective backup might start only after the scheduled pre-processing jobs (e.g. database snapshot) have been finished.
• Full backup jobs are generally run once per week and are distributed between all days of the week.
• Level jobs (i.e. differential jobs) are run 4 times per week between Monday and Friday every day the full backup job is NOT run.
• Incremental jobs are run once a day on Saturday or Sunday.
• The browse policy (direct access to file and directory information of the backuped file systems) and the retention policy are generally set to 3 months.
• Software compression is used on the client.
• Hardware compression is used at tape device level.
• The tapes are cloned.
• No separation is made between full, level (differential) and incremental job tapes.
• The backup tapes remain in the tape library. The reusability of these tapes is controlled by the software.
• Cloned tapes are removed regularly by the computer center operators and placed in the safe (3rd underground floor). A small and easy tool helps the operators to select and eject the correct tapes.
• Regularly, the operators of the computer center (data processing center, “centre de calcul”) check, which cloned tapes have been released by the backup software for re-use (i.e. set to the status “recyclable”). A small and easy tool helps the operators to create a list with the tapes that can be re-used. The corresponding tapes are removed from the safe and re-inserted into the tape library.
• The backup software provides appropriate features to assure that the data of a tape volume can be safely overwritten.
A.3. Backup of Oracle databases:
One or a combination of the following techniques is used:
• Logical database backup: Oracle export dump files are generated while the database is in restricted access mode. These files are written on the file system of the corresponding servers. The database is then stopped and backups of the server file systems are made within the global backup framework.
• Physical cold backup: The database is stopped and backups of the server file systems are made within the global backup framework.
• Physical hot backup: An open database backup is done (alter tablespace ... begin backup ; alter tablespace ... end backup).
• RMAN (oracle recovery manager): All standard features of RMAN are used.
• "Freeze"/Snapshot techniques: In order to limit the unavailability of the database during the physical cold backup, the database is stopped only during the time needed to make a "freeze" or a snapshot of the file systems hosting the database. The "freeze" or the snapshot is then available for tape backup or for restore purposes.
➢ A snapshot consists in attaching an additional mirror volume for the desired directories and to make a synchronisation between the additional mirror and the mirrored volume.
➢ A "Freeze" consists in keeping the state of a file system at the given “Freeze” time by means of a second file system with exactly the same directory structure. Prior to any modification of the "frozen" file system, the unmodified data is copied to the second file system. By combining both file systems, the “Frozen” state is always available.
A.4. Implementation:
It is the responsibility of the Office to define the objectives to reach in terms of availability/unavailability of the application.
Based on these requirements, the contractor/supplier should define the backup procedures to implement in order to fulfil the requirements. Ideally, the contractor/supplier should base these backup procedures on techniques the Office’s staff is familiar with (see contents of this appendix).
If the wishes of the Office in terms of availability cannot be satisfied with techniques the Office’s staff is familiar with, the contractor/supplier should provide a full description of the procedures and techniques to use so that the implementation by the Office’s staff could happen smoothly.
Appendix B: Standard file system organization on Unix systems (directory structure)
In order to ease the co-existence of applications on the same server and to ease the potential move of an application to another server, applications are generally installed under /applications/application_name/ where application_name refers to the name of the application.
This level is then subdivided into:
• /applications/application_name/users which is itself subdivided into:
o /applications/application_name/users/system: directory simulating the root directory for the application. Specific products used by the application are installed here (e.g. the web server is installed under /applications/application_name/users/system/apache/, the application server is installed under /applications/application_name/users/system/tomcat/).
o /applications/application_name/users/oracle: Oracle application, oracle environment, and oracle admin directory.
o one or more directories /applications/application_name/users/user_name: home directories of the users user_name used by the application. These directories are linked to /home/user_name. Generally, there is only one directory /applications/application_name/users/user_name and user_name is identical to application_name.
• /applications/application_name/xchange: root of interfaces (in case of exchange of data with remote applications). The following specific structure is used:
o /applications/application_name/xchange/remote_application_x/(sublevel if necessary)/in for incoming data and
o /applications/application_name/xchange/remote_application_x/(sublevel if necessary)/out for outgoing data
where application_name refers to the name of the application and remote_application_x refers to the name of the remote application.
e.g. /applications/eub/xchange/eudor/in is used for the data flow exchange from eudor to eub.
/applications/eub/xchange/gescom/gcb/out is used for the data flow exchange from eub to the gcb part of gescom.
• /applications/application_name/oradata: Oracle datafiles.
• /applications/application_name/oraexp: Oracle exports
• /applications/application_name/oralog: Oracle online archive logs.
Deviations from this description are possible but the Office should first validate the deviations.
|/applications |
|| |
|-- /application_name |
|| |
|-- /users |
|| | |
|| -- /system (to install by Publications Office) |
|| | | |
|| | -- /init.d Start/stop scripts |
|| | | |
|| | -- /product_1 (e.g Tomcat - Apache - ...) |
|| | | |
|| | -- /... |
|| | | |
|| | -- /product_n |
|| | |
|| -- /oracle oracle binaries |
|| | |
|| -- /user_name_1 (link to /home/user_name_1) |
|| | |
|| -- /... (if required - link to /home/...) |
|| | |
|| -- /user_name_n (if required - link to /home/user_name_n) |
|| |
|-- /oradata oracle datafiles |
|| |
|-- /oraexp (if required) oracle export |
|| |
|-- /oralog oracle logs |
|| |
|-- /data_1 (e.g. Documentum filestore) appli data |
|| |
|-- /data_... (if required) appli data |
|| |
|-- /data_n (if required) appli data |
|| |
|-- /xchange |
|| |
|-- /remote_appli_1 |
|| | |
|| -- /in |
|| | |
|| -- /out |
|| |
|-- ... other interfaces ... |
| |
|(The names of the different filesystems are in bold) |
Annex 13 Security Requirements
13.1. Introduction
13.1.1. Minimum security requirements objectives and positioning
The European Commission has developed and maintains the overall EC Information Systems Security Policies (EC ISSP).
The EC ISSP does not provide rules, procedures or guidelines for specific information systems. It defines, however, the general framework to derive Directorate-General / Department specific security policies and system specific security plans. All derived security policies and plans shall be consistent with the EC ISSP.
In line with this requirement, the Publication Office has developed its own specific Baseline Information System Security Policies (BISP).
The Publication Office BISP applies to information systems NOT processing EU CLASSIFIED information.
The BISP defines the boundaries within which all processes must take place. All products selected, processes, manuals and handbooks must be in compliance with the policy. The policy serves as main reference, to which all subsequent security documents, would it be Technical Security standards, User Security standards and Security procedures, must comply with.
The European Commission is committed to follow the COBIT framework to deliver IT governance to the business services. As part of this strategy, the Publication Office has been recommended by the EC auditor to implement the COBIT "Delivery & Support 5 – Ensure System Security" controls objectives.
To fulfil this requirement the Publication Office has adopted the ISO/IEC17799:2000 standard 'Code of practice for Information Security Management. Considering the importance of Business Continuity at the Publication Office, the chapter 11 (Business Continuity Management) of the ISO/IEC 17799:2000 has been supplemented with the British Continuity Institute (BCI) Publicly Available Standard (PAS) number 56 "Good practice guide to Business Continuity Management.
Accordingly, the Publication Office BISP is structured in line with the 10 ISO/IEC 17799:2000 domains. The Business Continuity Management domain is replaced by the BCI PAS56 framework.
The Publication Office BISP provides general requirements on the commonly accepted goals for managing information security. Collectively, the Publication Office BISP includes 10 domains, sub-divided in 41 sub-domains for a total of 137 security controls statements.
Security policy (1 sub-domain);
• Organizational security (3 sub-domains);
• Assets classification & control (2 sub-domains);
• Personnel security (3 sub-domains);
• Physical and environmental security (3 sub-domains);
• Communications and operations (7 sub-domains);
• Access Control (8 sub-domains);
• Systems development and maintenance (5 sub-domains);
• Business Continuity Management (6 sub-domains);
• Compliance (3 sub-domains).
The subsequent chapters define the minimum security requirements that have to be implemented on all information processing systems. Those requirement constitute a baseline, constructed
• to adhere to the Publication Office BISP, which it-self implement the EC Information System Security Policy,
• to specify applicable lower level requirements.
This set of minimum security requirement is intended to be attached to each 'Call For Tender' for information processing systems and/or services issued by the Publication Office. The Service Provider selection criteria must include assurance from the Service Provider to deliver services in line with those requirements.
The application being integrated within the existing Publication Office security infrastructure it will benefit from the standard infrastructural security, operational controls and human practices.
However, it is critical to properly and consistently communicate
• specific technical security requirement at:
o application level
o logical access control level
o network level
o system level
o physical level
• outsourcing and third party contractual, operational and procedural obligations, in line with the Publication Office BISP.
Information security controls must be considered at the systems and projects requirement specifications and design stage. Failure to do so can result in additional costs and less effective solutions, and maybe, in the worst case, inability to achieve adequate security
In order to assist the project owner to specify those security requirements, a simple check list of minimum security requirement is developed here under, based on common best practices and specialised organisation recommendations, such as OWASP, SANS, NSA and NIST.
The minimum security requirements are cumulative to the standard security services, as delivered by the Publication Office secure infrastructure.
Fig. 1: Specific IS Security policies, standards, practices and procedures taxonomy
13.1.2. Information classification
13.1.2.1 Confidentiality classification
If the target information system is planned to process EU CLASSIFIED Information, then Accreditation of information systems processing classified information shall be governed by Section 25 of Decision No 2001/844/EC, ECSC, Euratom.
If the target information system is NOT planned to process EU CLASSIFIED information, then a realistic classification in terms of confidentiality must be defined by the system owner on the basis of the likely consequences that unauthorised disclosure might have for the interests of the Commission, the other Institutions, the Member States or other parties.
The confidentiality levels for NON EU CLASSIFIED information are:
• “PUBLIC”: information system or information intentionally prepared and compiled for public disclosure.
• “LIMITED”: information system or information reserved for a limited number of persons on a need to know basis and whose disclosure to unauthorised persons might be prejudicial to the Commission, other Institutions, Member States or other parties, but not to an extent serious enough to merit classification as laid down in paragraph 16.1 of the provisions on security of the decision No 2001/844/EC, ECSC, Euratom. An additional marking may be attached for information at this level of security identifying the categories of persons or bodies that are the recipients of the information or authorised to access it.
The minimum security requirements for EU CLASSIFIED information are out-of-scope of this document.
13.1.2.2. Integrity and availability classification
Information systems and the information processed therein shall also be identified according to their level of integrity and availability, by the system owner, on the basis of the likely consequences that a loss of integrity or availability might have for the interests of the Commission, other Institutions, Member States or other parties.
The levels are as follows:
• “MODERATE” shall apply to information or information systems the loss of whose integrity or availability might threaten the internal working of the Commission; cases would include the non-application of the Commission’s Rules of Procedure without any outside impact or with limited outside impact, a threat to the achievement of the objectives of an action plan, or the appearance of significant organisational and operational problems within the Commission without any outside impact;
• “CRITICAL” shall apply to information or information systems the loss of whose integrity or availability might threaten the position of the Commission with regard to other Institutions, Member States or other parties; cases would include damage to the image of the Commission or of other Institutions in the eyes of the Member States or the public, a very serious prejudice to legal or natural persons, a budget overrun or a substantial financial loss with very serious adverse consequences for the Commission's finances;
• “STRATEGIC” shall apply to information or information systems the loss of whose integrity or availability would be unacceptable to the Commission, to other Institutions, to Member States to other parties because it might, for example, lead to the halting of the Commission's decision-making process, an adverse effect on important negotiations involving catastrophic political damage or financial losses, or the undermining of the Treaties or their application.
The minimum security requirements for STRATEGIC information are out-of-scope of this document.
13.1.3. Responsibility for security requirements
The Project Owner is responsible for:
• setting the security requirements of the project and allocating financial, technical and human resources as required for meeting the security requirements of the project, (BISP 10.1.1)
• ensuring that the security controls are tested and validated during acceptance test phase (BISP 8.2.2)
• maintaining the security controls throughout the life cycle of the product or the application (BISP 10.5.1).
Product or service specifications must include the requirements for security controls. Contracts with the Providers must also address the identified security requirements.
Where the security functionality in a proposed product does not satisfy specific security requirements then the risk introduced must be evaluated and additional controls must be reconsidered prior to purchasing the product. Where additional functionality is supplied and causes a security risk, this must be disabled or the proposed control structure must be reviewed to determine if advantage can be taken of the available enhanced functionality.
Design reviews must be conducted at periodic intervals during the development process to assure that the proposed design will satisfy the functional and security requirements specified by the owner.
Decisions not to implement security controls or to implement alternative controls, must be subject to formally documented exemption describing the residual risks. The exemption approval process must include the system owner and the Control & Security section.
13.2. Application level security
13.2.1 Input data validation
13.2.1.1. Web applications
• Web application and publicly available systems must not handle EU CLASSIFIED data.
• Each Web applications input data from HTTP requests must be checked against a strict format that specifies exactly what input will be allowed. All headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters) must be "positively" validated against a rigorous specification that defines:
o data type (string, integer, real, etc…)
o allowed character set
o minimum and maximum length
o whether null is allowed
o whether the parameter is required or not
o whether duplicates are allowed
o numeric range
o specific legal values (enumeration) and specific patterns (regular expressions)
• Input checks must be performed at server side. On top of the server side checks, client side checking can also be included to enhance the user experience for legitimate users and/or reduce the amount of invalid traffic to the server.
• A ‘positive’ security check that specifies what is allowed must be implemented. “Negative” approaches that involve filtering out certain bad input or approaches that rely on signatures are not effective and are difficult to maintain.
• Direct access to files and database must be positively filtered (in URL, system calls, shell commands) against the user's rights.
• Raw data modifications in databases must not be possible. Add, modify, and delete procedures must be implement to changes data.
• Only files that are specifically intended to be presented to web users must be marked as readable using the Operating System's permissions mechanism, most directories should not be readable, and very few files, if any, may be marked executable.
• Mechanisms, including HTTP headers and meta tags, must be used to be sure that pages containing sensitive information are not cached by user’s browsers.
• Protection against injection flaws must be implemented. The simplest way to protect against injection is to avoid accessing external interpreters wherever possible. For many shell commands and some system calls, there are language specific libraries that perform the same functions. Using such libraries does not involve the operating system shell interpreter, and therefore avoids a large number of problems with shell commands.
o For those calls that must be used, such as calls to backend databases, the input data must be validated to ensure that it does not contain any malicious content.
o The use of stored procedures or prepared statements will provide significant protection, ensuring that supplied input is treated as data, and not as active commands such as SQL statements.
o Web servers must not run as ROOT or access a database as DBADMIN, otherwise an attacker can abuse these administrative privileges granted to the web application. Instead, it must run with only the privileges it absolutely needs to perform its function.
o The Java sandbox must used, when feasible, to prevent the execution of system commands.
o If an external command must be used, any user information that is being inserted into the command must be checked. Mechanisms must be put in place to handle any possible errors, timeouts, or blockages during the call.
o All output, return codes and error codes from the call must be checked to ensure that the expected processing actually occurred.
• Session management
o Web applications must establish sessions to keep track of the stream of requests from each user.
o Session IDs chosen by a user should never be accepted.
o A connection time-out must be implemented on ""CRITICAL"" (or above) applications.
o For ""CRITICAL"" (or above) applications, the user’s entire session must be protected via SSL, based on at least 112-bit 3*DES (or equivalent) or 1024-bit RSA (or equivalent) digital signatures.
o For ""MODERATE"" applications, the user's entire session should be protected via SSL. If SSL is not used, then session IDs themselves must:
▪ never be included in the URL as they can be cached by the browser, sent in the referrer header, or accidentally forwarded,
▪ be long, complicated, including random numbers that cannot be easily guessed,
▪ must be changed when switching to SSL, authenticating, or other major transitions.
• Protections against Denial of Service attacks must be implemented
o Application’s session data must be as small as possible.
o Resources allocated to any user must be limited to a bare minimum.
o For authenticated users:
▪ quotas should be used to limit the amount of load a particular user can put in the system,
▪ one request per user should be handled at a time by synchronizing on the user’s session,
▪ any request being currently processed for a user should be dropped when another request from that user arrives.
o For unauthenticated users, any unnecessary access to databases or other expensive resources must be avoided by:
▪ architect the flow of the web site so that an unauthenticated user will not be able to invoke any expensive operations,
▪ cache the content received by unauthenticated users instead of generating it or accessing databases to retrieve it.
13.2.1.2. Publication Office back-office applications
• Data input must be done via menu and selection in a list.
• If the input is captured from key string then the format and syntax must be controlled by the application to reduce the risk of errors and to prevent classical attacks such as buffer overflow and code injection. Boundary checks or field limits to specific ranges of input data must be implemented to detect the following errors:
o out-of-range values,
o invalid characters in data fields,
o missing or incomplete data,
o exceeding upper and lower data volume limits,
o unauthorized or inconsistent control data.
• Raw data modifications in databases must not be possible. Add, modify, and delete procedures must be implement to changes data.
13.2.2. Control of internal processing
• Procedures and checks must be implemented:
o to prevent programs running in the wrong order or running after failure of prior processing,
o to recover from failures to ensure the correct processing of data,
o to ensure integrity of data, records files or software downloaded, or uploaded, between computers (e.g. hash code).
• reconciliation control counts to ensure processing of all data,
• Web applications must avoid implicit trust between components whenever possible. Each component should authenticate itself to any other component it is interacting with unless there is a strong reason not to (such as performance or lack of a usable mechanism). If trust relationships are required, strong procedural and architecture mechanisms should be in place to ensure that such trust cannot be abused as the site architecture evolves over time.
13.2.3. Error Handling
Error handling mechanisms must be able to gracefully handle any feasible set of inputs, any errors that can be generated by internal components such as system calls, database queries, or any other internal functions.
• When errors occur, the site should respond with a specifically designed result that is helpful to the user without revealing unnecessary internal details.
• Error messages must be produced and logged so that their cause, whether an error in the site or a hacking attempt, can be reviewed.
13.2.4. Policy on the use of cryptographic controls
Usage of cryptography is subject to the European Commission policy and isolated or local implementations are not authorized to avoid loss of unrecoverable encrypted data, loss of operational performance and/or law infringement. The Publication Office must only use cryptographic tools provided and supported by the European Commission which provide protection against:
• insecure storage of keys, certificates, and passwords,
• improper storage of secrets in memory,
• poor sources of randomness,
• poor choice of algorithm,
• attempting to invent a new encryption algorithm,
• failure to include support for encryption key changes and other required maintenance procedures.
13.2.5. "CRITICAL" system isolation
• ""CRITICAL"" applications must be running in dedicated computing environment, possibly implemented by virtual partitioning of the same physical system.
13.2.6. Documentation and operating procedures
• Documented procedures must be prepared for each system activities. All information processing system documentation must be released to the system owner, with access limited to the operators. The system documentation must be classified at the same level at the system it-self.
• The operating procedures must specify the instructions for the detailed execution of each job including, amongst others:
o start-up and close-down procedure, including interdependencies with other systems, earliest job start and latest job completion times,
o processing and handling of information, including scheduling requirements,
o instruction for media handling,
o backup,
o equipment maintenance,
o support contacts in the event of unexpected operational or technical difficulties,
o instructions for handling events or other exceptional conditions, which might arise during job execution, including restrictions on the use of system utilities,
o system restart and recovery procedures for use in the event of system failure,
o the management of log file.
13.2.7. Electronic commerce security
Electronic commerce must be protected against fraudulent activity, contract dispute and disclosure or modification of information.
The risks must be assessed and the following considerations must be taken into account:
• the level of confidence each party requires in each others claimed identity, e.g. through authentication in line with the authorization processes associated with who may issue or sign key trading documents,
• the requirements for confidentiality, privacy, integrity, proof of dispatch and receipt of key documents, and the non-repudiation of tendering and contracts,
• documented agreement which commits both parties to the agreed terms of trading, including details of authorization,
• compliance with all European directives and applicable international, national, regional and local laws, such as all tax acts, trade practices, Sale of Goods (or similar) acts, and so on.
If the Publication Office implements further electronic commerce facilities with on-line payment and financial transactions, then the risks must be reassessed including:
• the level of trust required in the integrity of advertised price lists,
• the level of protection required to maintain the confidentiality and integrity of order information,
• the confidentiality and integrity of any order transactions, payment information, delivery address details, and confirmation of receipts,
• the degree of verification appropriate to check payment information supplied by a customer,
• the liability associated with any fraudulent transactions,
• the insurance requirements.
All e-commerce payments by credit cards must comply with the Payment Card Industry Data Security Standard (PCI-DSS) and the merchant agreement.
In brief, the twelve requirements to handle credit card payments are:
|Build and maintain a secure network |Install and maintain a firewall configuration to protect data |
| |Do not use vendor-supplied defaults for system passwords and other security parameters |
|Protect Cardholder Data |Protect stored data |
| |Encrypt transmission of cardholder data and sensitive information across public networks|
|Maintain a Vulnerability Management Program |Use and regularly update anti-virus software |
| |Develop and maintain secure systems and applications |
|Implement Strong Access Control Measures |Restrict access to data by business need-to-know |
| |Assign a unique ID to each person with computer access |
| |Restrict physical access to cardholder data |
|Regularly Monitor and Test Networks |Track and monitor all access to network resources and cardholder data |
| |Regularly test security systems and processes |
|Maintain an Information Security Policy |Maintain a policy that addresses information security |
A summary of the PCI-DSS is available is in the OWASP guide, available at and full detailed PCI-DSS requirements are available on the major credit card site e.g.; at:
13.2.8. Application events logging
• Application logs must be enabled 24 hours per day, 7 days per week and kept for an agreed period to assist in case of future investigations and access control monitoring
• The following events must be logged:
o failed or rejected user authentication and access control policy violation,
o failed or rejected user action,
o use of system utilities,
o all activities performed by high level privileges accounts (System administrators, system operators) amongst others:
▪ system start-up and stop,
▪ changes, or attempt to change, configuration and security settings.
• Logs are classified as ""CRITICAL"" information and must be managed accordingly.
13.2.9. Clock synchronization
The Publication Office master clock is set to the local standard time with automatic feature to adjust the clock to the daylight savings time. The applications’ clock must be synchronised with the Publication Office master clock.
13.3. Logical access control
13.3.1. External users of Web applications
• User access control rules must define what types of users can access the system, and what functions and content each of these types of users should be allowed to access must be documented and enforced.
• User_id's can only be used to identify and reference users and not as proof of identity or authentication mechanism.
• Access control checks to access protected URL must not be bypassable by a user that simply skips over the page with the security check.
• Administrator access through the front door of the site must not be at all possible.
• All user account management functions must require re-authentication even if the user has a valid session id.
• For accessing URL containing ""LIMITED"" information, users must be uniquely identified and authenticated with a password according to the following policy:
o Password must be forced: :
▪ to contain at least 8 characters,
▪ to be a mixture of at least 3 of the following character classes:
• upper case letters (A .. Z),
• lower case letters (a .. z),
• digits (0 .. 9),
• punctuation characters (~!@#$%^&*()_+`-={}[]|\:”;’,.?/)
▪ to be different from the UserId (also reversed, capitalized, doubled …),
o To prevent a reuse of the same passwords or similar passwords, a password history must be maintained. The system must memorise the last 3 passwords, and accept only a new password which differs from the 3 previous ones.
o An account must be locked after 3 erroneous user authentication attempts and be locked for an undefined period.
o A password reset procedure must be defined. The actual password reset may only be done by the system manager.
▪ the reset procedure must include out-of-band steps to re-authenticate the user. For example, such procedure might be to request the user to answer to some specific and personalised questions, whose answers were provided during the User_id initialisation phase,
▪ the new password must be one-time usage,
▪ if the new password is sent to the user e-mail address, than the user must introduce twice the e-mail address for validation.
o Passwords must not be stored in the application system, but only a non-reversible hash of it. Passwords should never be hardcoded in any source code or executable.
• Repeated failed login attempts must be logged.
• The system should not indicate whether it was the username or password that was wrong if a login attempt fails.
• Users should be informed of the date/time of their last successful login and the number of failed access attempts to their account since that time.
• A "change password" function must be implemented. Users should always be required to provide both their old and new password when changing their password.
• Authentication and session data should never be submitted as part of a GET, POST should always be used instead. Authentication pages should be marked with all varieties of the no cache tag to prevent someone from using the back button in a user’s browser to backup to the login page and resubmit the previously typed in credentials. Many browsers now support the autocomplete=false flag to prevent storing of credentials in autocomplete caches.
13.3.2. Publication Office users of internal applications
Access to the Publication Office systems and application is subject to a formal authorization procedure (DMA – Demande d'Accès) operated by the Control & Security section. The procedure is supported by a Work Flow, "suivi3D".
• When a new application is developed and rolled-out, its access control must be integrated in the DMA access control management system, by updating the DMA Applications database.
• User access authorisation approvers must be designated by the system owner.
• The application must support the User_id convention, as integrated in the Publication Office Active Directory and the Publication Office password security rules.
o User_id convention:
o Password management rules:
▪ The initial password must be one-time usage.
▪ Password must expire automatically at the end of a period of 90 days. The period restarts at each new change.
▪ Seven days before the end of the password validity period (90 days), a warning must be sent to the user after login to remind him that his password will expire. The user must be invited to change it.
▪ If the user is away while the password period expires, on his return, at the first login, he is forced to change his password before continuing.
▪ To prevent a reuse of the same passwords or similar passwords, a password history must be maintained. The system memorises the last 3 passwords, and accepts only a new password which differs from the 3 previous ones.
▪ Password must be forced: :
• to contain at least 8 characters,
• to be a mixture of at least 3 of the following character classes:
• upper case letters (A .. Z),
• lower case letters (a .. z),
• digits (0 .. 9),
• punctuation characters (~!@#$%^&*()_+`-={}[]|\:”;’,.?/)
• to be different from the UserId (also reversed, capitalized, doubled …),
▪ An account must be locked after 3 erroneous user authentication attempts and be locked for an undefined period.
▪ Passwords can only be reset by a system manager, upon request to the help desk.
▪ Passwords must not be stored in the application system, but only a non-reversible hash of it.
13.4. Network level security
• Every implementation of a new information system must be requested by the “Demande Matériel Informatique" (DMI) procedure and approved by the Information Resource Manager.
• The servers running "CRITICAL" applications should be isolated from network segments of higher sensitivity in order to prevent attackers from using them as a platform for mounting attacks on systems in other segments.
• Connection of information processing systems to the Publication Office network must be performed by the Network section.
• Connection of workstation or information systems not owned by the Publication Office, such as contractor's PC, is not allowed.
• Remote access to the Publication Office information systems by third party users (e.g. printers) or Services Providers (e.g. remote system managers) can only be done by:
o Dedicated leased line, or
o Virtual Private Network (VPN).
13.5. System level security
13.5.1. System configuration hardening
• All applications must be able to run on the standardised Publication Office production servers configured to only offer functionality that is absolutely necessary for the provision of the envisaged service. The Service Provider must exhaustively specify the required operating system functionality, network services and security parameters.
• Software must be controlled and checked to protect against possible covert channels and Trojan code. The Publication Office applies the European Commission provided policy and settings to manage and control Java applets, Active-X controls and Java scripts.
o Unsigned Java applets which are downloaded from the Internet and executed in a “sandbox” are permitted.
o Unsigned Java applets which are downloaded from the Internet and installed locally are not permitted.
o Java applets which are certified by an external organisation that is not recognised by the Commission are not permitted.
o Java applets which are certified by an organisation inside the Commission or by an external one that is recognised by the Commission, are permitted (it is advisable to add the certificates of these organisations in the certification organisation database of the Internet browsers).
o Active-X controls that are unsigned or certified by an external organisation that is not recognised by the Commission are not permitted.
o Active-X controls that are certified by an organisation inside the Commission or by an external one that is recognised by the Commission may be permitted depending on their harmlessness and the needs of the Publication Office.
• Deviations from the standardised Publication Office servers configurations and settings must be documented and greed with the system owner and by the Publication Office LISO.
13.5.2. System utilities
All unnecessary system software, compilers, editors, and other development tools or system utilities are removed from the standardized Publication Office production servers.
• If the utilization of some system utilities is required for operational reasons, the utilization if the system utilities must:
o be subject to a formal authorization from the system owner and the Publication Office LISO,
o be limited to a minimal number of trusted authorized individuals,
o be logged.
13.5.3. Restricted access to sensitive files
• Access to the following files must be restricted to system managers:
o system configuration and software files,
o log files,
o hashed password files.
13.6. Test, development and acceptance
13.6.1. Separation of development, test and operational facilities
• Development and production software must run on different systems.
• Test and development software should run on either physically separated systems or different virtual partitions.
• The test system environment should emulate the production system environment as closely as possible.
• Production data or files including ‘LIMITED’ information, or private data should not be used to test applications software. If, for operational reasons, the test harness is constructed from production data:
o then those data or files must be anonimised and declassified as '"PUBLIC"' information,
o or the test system must be classified as ‘LIMITED’ and the same security controls must be applied as in the production environment.
• Prototypes must not be used in production.
13.6.2. System acceptance
• Prior to placing a system into operation, the Publication Office will verify that the required user functions are being performed completely and correctly, and that the technical, procedural and physical security controls are operational as per these security requirements.
• The system acceptance procedure must include tests of:
o all security related features of the information systems,
o secure web server configurations,
o resilience test against the applicable vulnerabilities:
▪ OWAPS Top Ten Web application vulnerabilities,
▪ SANS Top Twenty vulnerabilities.
• If the application is due to handle private data, than the Publication Office will check that those private data are handled according to the local jurisdiction (e.g. the CNPD in Luxembourg) and in accordance to the European Commission directive EC45/2001.
13.7. Communications and operations
13.7.1. Operational change controls
The Publication Office production systems are subject to strict change control management.
• All patches and service packs must be validated and tested before promotion to production.
• Automated updates must not be used as some updates may cause applications to fail.
• The decision to install changes in production is taken by the system owner. Installation is typically performed after business hours; otherwise the service interruption procedure must be used in agreement with the production manager.
13.7.2. Business Continuity Management
The Publication Office has developed a comprehensive Business Continuity Management framework, supported by disaster recovery plan.
• The target system must be integrated into the Publication Office BCM framework.
• A copy of the accepted production server content must be safe stored in a location distinct from the production site.
13.8. Physical security
13.8.1. Access to the Publication Office building by Service Provider staff
Access to the Publication Office building by Service Provider staff must be controlled in line with the Publication Office physical access control rules.
• All non-statutory staff at the Publication Office are primarily under the responsibility of the unit they are placed in. After the Service Provider contract has been signed, each contractor must sign an individual Non-Disclosure Agreement. After signature, each contractor will be provided with a long term building access card for external staff, under the following rules:
o presence must be minimum three days/week for minimum duration of stay of two weeks,
o validity is three months at a time,
o card may be taken out of the premises.
• Everyone must visibly wear his/her identification badge in the Publication Office building. It is recommended not to wear it outside the building not to attract undue attention.
13.8.2. Physical security within the Publication Office building
The Publication Office applies a clear desk and clean screen policy:
• Everyone, including Service Provider staff is responsible for maintaining his working environment clear and tidy. Everyone is encouraged to avoid:
o eating or drinking close to any IT equipment not to damage the equipment;
o leaving any non-business related information or equipment in the office.
• All paper based information which is not "PUBLIC" and any removable storage media or device must be locked in a closed cabinet at the end of the working day or when the office is not attended.
• It is the responsibility of everyone to ensure all obsolete "PUBLIC" paper based information is sorted in the dustbin foreseen for "paper to recycle".
• It is recommended to use local paper shredder to dispose obsolete "LIMITED" paper based information and zeroisation techniques to securely erase all storage media.
• The Publication Office does not allow removing Publication Office's assets out of the Publication Office buildings.
13.8.3. Physical security requirements for outsourced operations
System servers must be operated in compliance with the Publication Office BISP:
• Equipment shall be sited or protected to reduce the risks from environmental threats and hazards, and opportunities for unauthorized access. Operating centres must be equipped with blind and shielded windows.
• All offices and computer rooms must be equipped with regularly tested UPS outlets.
• All power and data cables must be laid down in separate cable trays.
• All equipments must be maintained in accordance with the equipment provider’s recommended service intervals and specifications. Only authorized maintenance personnel must carry out repairs and service equipment. Records must be kept of all suspected or actual faults, and all preventive and corrective maintenance. All requirements imposed by insurance policies must be complied with.
13.9. Third party and outsourcing service provider's contractual obligation
13.9.1. Adherence to the Publication Office BISP
• The criteria for selecting the contract shall include the capability of the contractor to meet the specified security requirements and to comply with the Publication Office BISP.
• All Service Provider's staff working at the Publication Office are required to comply with the Publication Office BISP and supporting practices and baselines.
13.9.2. Non Disclosure Agreement
• The Service Provider must undertake to comply with the standard Publication Office Non-Disclosure Agreement.
• After the Service Provider contract has been signed, each contractor assigned to the contract must sign an individual Non-Disclosure Agreement.
• Any information, data and/or materials of whatever kind or nature that is transmitted to the Service Provider related to the Publication Office shall be considered as "LIMITED" and proprietary to the Publication Office, unless explicitly released as "PUBLIC" information and must be treated as such by the Service Provider.
• The "LIMITED" information may also include information which has been submitted to the Publication Office by third parties, and which the Publication Office has been authorised to disclose, subject to security measures or confidentiality provisions. In such case, the Service Provider accepts that the terms of the service agreement shall be deemed to be also for the benefit of the Publication Office and any such third parties and fully binding upon the Service Provider with respect to such "LIMITED" information.
• However, the "LIMITED" information does not include information that the Service Provider can prove by written records:
o was in the public domain at the time it became known or was transmitted to the Service Provider,
o becomes part of the public domain thereafter through no breach of the service agreement,
o was already in the Service Provider's possession free of any obligation of confidentiality.
• The Service Provider shall neither use nor copy the "LIMITED" information for any purpose other than the execution of the service agreement and shall neither directly nor indirectly disclose or permit such "LIMITED" information to be made available to any third party without prior written authorisation from the Publication Office system owner or the Publication Office LISO.
• The Service Provider undertakes that it will only disclose any "LIMITED" information to those of its employees, subcontractors, or any other third parties on a "need to know basis". Prior to disclosing any "LIMITED" information to any third party the Service Provider will:
o inform that third party of the restrictions on the use and disclosure of the "LIMITED" information,
o ensure that the third party is bound by a confidentiality undertaking or obligations of confidence which protect the "LIMITED" information to at least the extent that it is protected under the Service Provider agreement.
• Upon the written request of the Publication Office, the Service Provider shall, at the Publication Office’s option, promptly return or destroy all documents and other materials in whatever form containing "LIMITED" information from the Publication Office.
13.9.3. Third party access to the Publication Office processing systems
• Third parties may not access the Publication Office internal processing systems unless formal contractual agreement is signed.
• Only after signature, the third party is allowed to issue an access request via the DMA procedure.
13.9.4. Private data protection
• The Service Provider acknowledges and agrees that the Publication Office reserves the right to process personal data relating to or supplied by the Service Provider, and/or its staff for purposes relating to staff administration and management, security, accounting and records keeping, and, more generally, the performance of its obligations and the enjoyment of its rights and remedies.
• Where such data are collected and supplied to the Publication Office by the Service Provider, the Service Provider must ensure that such data are collected and supplied for such purposes to the Publication Office in accordance with the European directive 45/2001 on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movement of such data..
13.9.5. Intellectual Property Rights and legal software copies (IPR’s)
• All materials, including documents in written or pictorial forms, on magnetic or non-magnetic media, drawings, designs, computer programs, source codes developed by the Service Provider or its contractor(s) for the Publication Office in pursuance of the Service Agreement shall be and shall remain the property of the Publication Office.
• The Service Provider must warrant that it is entitled to agree to such transfer of rights to the Publication Office, and has obtained all the rights and necessary authorisations from all parties concerned, including from its staff and Commercial Off The Shelf (COTS) packages provider, if such COTS are embedded in the deliverables.
• All materials supplied by the Publication Office to the Service Provider or its contractor(s) shall remain the property of the Publication Office, and shall be returned to the Publication Office, with all copies thereof, when the Service Provider's assignment in the context of this Service Agreement is terminated, for whatever reasons or immediately upon request by the Publication Office, without need to justify such a request.
• The Service Provider shall be responsible to obtain the return of all such materials from its staff immediately upon such person(s) ceasing to render any services to the Publication Office.
13.9.6. Right to audit and monitoring activities.
• At any time the Publication Office reserves the right to audit the Service Provider for compliance with its contractual obligation, especially adherence to the Publication Office BISP. Such audit should be announced in advance with a reasonable notice.
• The Publication Office has the ability and right to monitor or examine any information stored on its information processing systems or communicated over its network or equipment.
• The Publication Office can, and will, access this information without the Service Provider or it(s) contractor consent or advance notice only:
o for capacity planning purpose,
o for back-up and archiving purpose,
o if there is sufficient cause or evidence indicating abuse, non respect of the Publication Office BISP or the suspicion of a fraud or crime. In such case, the explicit authorization of the Publication Office LISO will be required before conducting any investigation.
13.9.7. Security incident, software malfunction and weaknesses reporting
The Service Provider has the obligation to report all security incidents, software malfunctions, security weaknesses or threats to systems or services that their staffs notice or is made aware of to the Publication Office help desk or the Publication Office LISO.
All users are instructed that they must not, unless formally authorized by the Publication Office LISO, attempt to prove a suspected weakness because this will be interpreted as a potential misuse of the system, could also cause damage to the information system or service and result in legal liability for the individual performing the testing
Annex 14 Provisional/Final (end of guarantee) Acceptance Note
|1. Context |
|1.1. Contract | |
|1.2. Contractor | |
|1.3. Project reference | |
|1.4. Order reference | |
|2. Deliverables list |
|2.1. Deliverable |2.2. Name |2.3. Delivery date |
| | | |
| | | |
| | | |
|3. Conclusion of Acceptance |
|( |3.1. General or Clean Acceptance. |
|( |3.2. Acceptance with reserves (the provider undertakes to correct, within the framework of guarantee, faults noted and described|
| |within chapter 6 of the current document). |
| |3.3.Guarantee period: |Start date: | |End date | |
|( |3.4. Refusal (the provider undertakes to correct faults noted and described within chapter 6 the current document). The product |
| |will be the subject of new delivery. |
OR
|3. Conclusion of guarantee period |
|( |3.1. All reserves have been resolved.. |
|( |3.2. The reserves, which are described within chapter 6 of the current document are still open but will be corrected by the |
| |contractor on his cost. |
|4. Visas |
|5.1. PROVIDER |5.2. Publications Office |
| |Project owner |Project leader |Head of Unit |
|Date : | |Date : | |Date : | |Date : | |
|Name : | |Name : | |Name : | |Name : | |
|Function : | |Function : | |Function : | |Function : | |
|Visa : | |Visa : | |Visa : | |Visa : | |
|6. Observations |
|7. Remarks |
|8. Annexes |
Annex 15 GESCOMX description
1 Introduction
The following chapters describe:
➢ the GESCOMX application;
➢ the interfaces between GESCOMX and others applications or systems;
➢ the data of GESCOMX.
The Publications Office (PO) has estimated for this application:
➢ 1.200.000 lines of ADABAS/NATURAL programs;
➢ about 6.500 objects (program, subprogram, data area, map…) and about 8000 Predict objects;
➢ the most 23rd important ADABAS files represent:
➢ about 80.000.000 records;
➢ more than 13 Gb.
➢ The most important ADABAS file represents about 6 Gb and 60.000.000 records
2 Description of GESCOMX
The commercial management application covers the following domains:
➢ Management of global data (users, administrative entities...);
➢ Management of items;
➢ Management of customers;
➢ Management of orders;
➢ Management of invoices;
➢ Management of stocks.
GESCOMX consists of about 580 interactive functions and about 200 batches. The complete list is at the end of this document including informations on volume.
3 Management of global data
4 The "administrative entity"
An administrative entity can represent any component, large or small, of a Community institution or agency.
Administrative entities are to be found in every domain of the management applications. These applications are in fact intended to be used by the Publications Office and other administrative entities:
- a publication can be produced on the initiative of one or more administrative entities;
- the stock of that publication can be owned by one or more administrative entities;
- administrative entities may place orders for the publication;
- the profit from sales of the publication can be shared between several administrative entities;
- the costs of storage and distribution are borne by the administrative entities.
An administrative entity is identified by a number allocated by the system at the time of its creation and by a mnemonic code employed by the user.
An administrative entity is now characterised in particular by the following:
- a number allocated by the system at the time it is created;
- a mnemonic code;
- a name;
- a name for export;
- a type;
- an opening date;
- a closing date, if any. An administrative entity cannot be deleted, but it can be closed;
- a hierarchically superior administrative entity;
- a customer number, if the administrative entity is a customer of the Publications Office;
- the number of an administrative entity which is managing the entity's stock. The administrative entity may appoint another entity to manage its stock;
- a beneficiary institution code identifying the administrative entity in the current accounting application (accountancy tracking);
- distribution requester codes identifying the administrative entity in the current routing application (distribution tracking);
- production requester codes and author codes identifying the administrative entity in the publication production tracking application;
- address roles;
- functional entitlements;
- commercial authorisations.
5 Management of user profiles
Management of several user profiles and association with each profile:
- consultation and management authorisation (creation, amendment, deletion) for a list of functions;
- attachment to an administrative entity; this has to allow orders to be taken from the stock of the entity or of a specified entity for which it is defined as manager, or of an entity further down in the hierarchy.
6 Tracking of operations
Any operation involving the creation, amendment or deletion of data is entered in a log file containing, apart from the data manipulated, the date and time of the operation and the manager's identification.
7 Management of items
The "Item" domain groups all functionalities allowing the definition and management of all items distributed and/or marketed by the Publications Office and the institutions of the European Union.
An item is any item "processed" (i.e. edited, co-edited, stored, archived, marketed, distributed, etc) by the Publications Office, whatever the typology of that item (physical item, electronic item, supplied item, subscription, access to public databases, miscellaneous service, etc).
The items managed by the Publications Office are mainly publications, i.e.:
– individual publications: the majority of items;
– periodicals: publications occurring at a known and fixed interval;
– series: a set of publications considered as a whole, dealing with a specific subject and with no fixed publication interval;
– collections: sets of a known number of publications attached to one or more periodicals or series and having their publication date fixed within a given timespan.
Links between items
The links between items are:
- commercial links: creation of a new item by putting together several (composite item);
- proximity links: language versions;
- composition links (hierarchical): collection, volume.
These links concern only composite items .publications, collections and multi-elements, as well as subscriptions as regards the language version.
Item identifiers and diverse identifiers
The different identifiers, apart from the system number (either for a item or for a group of items), are as follows:
- the catalogue number: unique to each item (its root – the first nine digits - should be common to all the different language versions);
- the ISBN number;
- the ISSN number: identifies all the publications belonging to one and the same periodical or series and to the same language version;
- the management number: unique to a publication no matter what the language version. In the case of periodicals or multi-element items the management number is identical, but there are additional attributes defining the issues of the periodicals or the volumes of the multi-element item (the root of the number is common to all the elements);
- the structured number (only certain publications): corresponds to the number printed on the cover, e.g. the series, number and year of the OJ;
Item properties
The items have the following properties in particular:
- one or more owners (AE);
- a sale revenue beneficiary (AE) (if there is a charge for the item);
- a tariff in euros; the current commercial management application manages the tariff history (with tariff start and end dates);
- item status: e.g. 'item for completion', 'ready for early order', 'ready for order/distribution', 'out of stock', 'out of print', 'defined', 'not for distribution';
- reproducibility: flag indicating whether the item may or may not be printed on demand (POD);
- date of start and end of availability;
- physical characteristics: weight, size (length, width, thickness);
- print runs (this information is inherited from the production tracking system; usually the print runs are divided up according to the owners of the stock and for certain consignments specified in the distribution record (cf 'Distribution' domain)
- user reference: this information is inherited from the production tracking system and is the reference which applies to the production requester;
- 'sale family';
- individual orderability flag (publications only): either the item can be ordered individually or it can only be ordered as part of a composite item, a multi-element item or a subscription.
Free items
Where an item has been defined as free of charge, all quantities of the item are free.
The possibility of ordering, order picking (and from what stock to pick), and/or granting discounts is specified in the user profile.
Sale revenue beneficiary
The sale revenue beneficiary is the administrative entity to which the revenue from the sale will be transferred.
The beneficiary may differ according to whether the copies sent are taken from stock or produced by the POD ('print on demand') procedure.
Sale family
In the current commercial management application a 'sale family' is assigned to each item. This concept is used in particular for calculating an automatic discount percentage.
Item blocking
An item may be blocked, i.e. its distribution suspended and its order lines not yet carried out, either for quality reasons ('blocking' as such), or for political reasons ('embargo') or because a quality check still has to be made ('acceptance of the quality copy'). This quality control is systematic for all publications in general.
When an item is blocked, it is still possible to prepare the distribution dossier, but distribution as such must not take place.
Volume
There are currently some 225 000 items, 50 000 of which are held physically in stock.
8 Management of customers
In the current commercial management application, the customer who places an order is rarely the ultimate (final) customer who receives the order, sales offices often acting as intermediary between the final customer and the Publications Office. The administrative entities of the European Union are also often customers using the Office’s services (storage, distribution, etc.) to serve their own clients. Note that the application allows sales offices to work with sales on consignment.
The Publications Office has developed applications to consult and place orders online from the Internet. These orders are placed by final customers. Increasing use of these applications will entail an increase in the number of orders placed directly by final customers, who themselves will grow in number. Currently there are noticeably fewer invoiced customers than recipient customers.
Since the Publications Office's customers come mainly - though not exclusively - from within the European Union, the application's handling of names and addresses must cope with alphabet characters in use in the EU (Greece, Nordic countries and Slav countries, etc). Customers break down into the following types:
– private customers ('general public’);
– sales offices and other commercial agents;
– administrative entities of the EU;
– civil servants;
– etc.
Customer properties
When a customer is registered, the following information is recorded:
a system identifier, a registration number, a name or trade name, a Publications Office manager, mother tongue, language used for correspondence.
Management of addresses
A customer has one or more addresses of different types: delivery address(es), invoice address(es), or generic address. The system must keep a history of address changes.
Customer type
The customer type involves two concepts: default discount rates and invoicing frequency.
9 Management of orders
This domain groups all functionalities allowing the definition and management of all orders for the items marketed and disseminated by the Publications Office for its usual customers or occasional recipients.
There are three types of order:
– standard type: processed according to the execution constraints specified for the order;
– sales on consignment/deposit type: processed according to a specific workflow;
– electronic type: created by a process when the information is received from e-applications.
An order can be about a physical or electronic item, or about a subscription.
Orders can be invoiced before or after shipment (especially with sales on consignment orders).
General
Orders are managed on a line-by-line basis, each line corresponding to an order for a single quantity of a given item.
Order management details:
- each line of an order is dealt with individually: every evening, all executable lines are picked up by shipment preparation processing without waiting until the whole of the order can be executed;
- nevertheless, all the lines of the same order that are executed on the same day with the same destination address are grouped together if possible.
An item can be ordered if its status so permits. This status depends in particular on the stock situation and the availability and quality of the publication (ready for distribution, reproducible).
Whether or not a user is able to place an order against payment is laid down in his user profile.
Only sales offices with a specific authorisation are allowed to place sales on consignment orders.
Item and orders
The properties of an item which permit it to be ordered are as follows:
- status of the item: 'ready for ordering/distribution';
- the item may be distributed;
- the item has been classed as reproducible if the stock is down to zero;
- the start of availability date has been reached;
- the item has an up-to-date tariff;
- the item has at least one stock owner and one sale revenue beneficiary (unless it is free of charge).
Delivery address
When an order is placed, a temporary address may be entered for the purposes of that specific order.
Discounts
When an order line is created, the discount percentage is calculated automatically. We have to be able to determine this automatic discount (in %) either in the customer type and sales family (of the item) or for a particular item or for a range of prices.
However, the manager may still change the discount calculated for a particular order line (provided that his profile allows him to and that the operation is tracked in a log file).
VAT
The price given in the order line must be linked to a VAT according to the rate in force in the country/region of destination, the item type and the customer type.
Order volume
On average, the current application manages about 250 orders a day averaging 4 lines each.
Sales on consignment/deposit orders
Authorised sales offices can place "sales on consignment" orders. For these orders, the sales offices are shipped with a certain (generally large) amount of items, initially for free. The invoice(s) is (are) sent later, and will concern only the items that the sales offices have reported to have sold. The remaining, unsold stock can be returned to the Publications Office, free of charge, up to 18 (negociable) months after the initial consignment order, afterwhat the remaining non-returned, non-invoiced stock will be charged.
10 Management of invoices
This domain groups all functionalities allowing the preparation and generation of invoices (in euro) related to the publications and services marketed by the Publications Office.
The majority of invoices are generated automatically.
The interface of the commercial accounting application allows:
- accounting operations related to invoices;
- production of duplicates for the management of reminders;
- processing of order settlement;
- creation of historical records for the different steps in the life of an order (from generation of pre-invoice to invoice breakdown).
An invoice consists of a heading and invoice lines.
The invoice heading contains the following information in particular:
- a customer number;
- an invoicing address;
- the gross and net total amounts of the different invoice lines.
An invoice line contains the following information:
- the reference of the item (catalogue number) to be invoiced;
- the quantity of the item;
- the gross amount (i.e. the price of the item multiplied by the quantity);
- the discount granted;
- the net amount;
- the rate of VAT;
- any comments.
An invoice line may correspond to an expense (in which case the code of the expense replaces the item reference and there is no discount) or to a comment.
Sales on consignment orders generate specific orders called 'order-invoices' ('commandes-factures' in French), so that the sales offices are charged only for the stocks they have effectively reported as sold.
Types of invoice
The different types of invoice are as follows:
- customer orders;
- customer orders prepaid by bank account ('invoice settled');
- credit notes on customer returns;
- manual invoices/credit notes;
- order-invoices ('commandes-factures') for sales on consignment orders;
The different statuses of an invoice/credit note
An invoice/credit note passes today through the following statuses:
- the creation of a pre-invoice/pre-credit note;
- validation of the pre-invoice/pre-credit note;
- production of the invoice/credit note (this is really the same as its creation: the last value of the identification changes) - batch processing;
- accounting of the invoice(*) (i.e. generation of accounting entries messages) – batch processing;
- settlement of the invoice;(*)
- breakdown of the invoice(*) - batch processing;
(*) These statuses are managed in the accounting application under Oracle Financials and the information is exported to the commercial management application.
Manual management of invoices
Only 'manual' type invoices and credit notes can be generated manually, either by copying the invoice/credit note already existing (without any link to the invoice/credit note copied) or by cancelling an existing invoice (with a link to the invoice cancelled).
Invoicing of orders
An invoice groups together all the order lines to be invoiced which have a common
- administrative entity;
- customer to be invoiced;
- invoicing address.
Every evening the day's invoices are generated automatically according to the invoicing frequency for that customer type. It is also possible to speed up invoicing by explicitly entering the date of the next invoice for that customer.
For sales on consignment orders, specific 'order-invoices' are manually filled in the application when sales offices' effective sales report are received.
Management of customer returns
This makes it possible to prepare a total or partial refund for the items returned by a customer.
There is no specific functionality for this apart from the production of a manual credit note if necessary.
For sales on consignment orders, customers can return the stocks that haven't been sold, on which they will not be charged.
Invoicing of subscriptions
A subscription is invoiced at the time of ordering (automated invoicing).
Invoicing of delivery/postage costs
The system calculates these charges in accordance with the type of item, the geographical area, the weight of the package, the total amount of the order and the mode of delivery (if by a carrier, in accordance with the contracts signed with the carrier). A customer may ask for delivery by carrier rather than by mail. It has to be possible for the value calculated by the algorithm to be corrected manually.
Invoicing frequency
The frequency of invoicing (monthly, on dispatch, etc) is linked to the customer type.
11 Management of stocks
The stock application groups all functionalities allowing on the one hand the definition and management of storage areas, warehouses and locations, and on the other hand the storage management of the items defined as stock elements.
Storage management includes the follow-up of item quantities according to two aspects:
– the physical aspect, which corresponds to the follow-up of quantities by location; all item-handling operations are therefore recorded in the system (entry in a location, handling between locations, extraction, archiving, etc);
– the logical aspect, which corresponds to the follow-up of quantities by stock owner; all the operations that modify the quantities in stock have an impact on the stock breakdown by owner.
The total physical quantity of an item has to be equal to the total logical quantity.
Management of stock may be at the level of the elements and/or the multi-volume publication.
There is no storage management of the electronic documents.
Organisation
The stock of an item may be scattered over several warehouses and locations. A stock location may contain several items.
An item stock may have several different owners.
Part of the quantity in stock may be "reserved" for an order. Where stock is available in a number of warehouses, there are rules to be complied with regarding the priority of the location of the stock to be extracted.
There are currently some 50 000 items in stock.
Stock movements
Stock movements, which reflect stock entries and exits in the accounts, are characterised by the entry/exit/movement aspect, the logical/physical aspect and a type.
Stock locations
Locations are defined hierarchically in relation to each other, the highest level corresponding to the warehouse.
Stock can only be defined for a location at the lowest level in its hierarchy.
The number of levels may differ from one hierarchy to another.
Stock owner
Rights of access: entitlement to order an item from an owner's stock is laid down in the user profile.
Logical transfer: quantities of an item can be moved from one logical stock to another by the logical transfer procedure.
Reception of items
On reception of physical delivery of a publication, some copies are picked from it and sent to various departments as documentary evidence. The physical characteristics of the publication are measured (length, width and thickness in mm and weight in grams) and the number of copies delivered is counted. The pallet or pallets are then placed in a temporary storage area (corresponding to a specific stock location) from where they will be disseminated. Those left over after distribution will be placed definitively in stock. At this point the final breakdown of stock owners will be established.
Two copies are systematically archived.
Order picking from quantities in the temporary and the archive stock locations must not be authorised.
Stock exits
Extraction for basic distribution
Extraction is carried out on the basis of the distribution record from the temporary stock location. This proces represents the ‘routing’ domain.
Extraction for executing orders
The system generates a 'picking list’ every evening on the basis of the quantities ordered during the day. This list enables the operator to carry out physical extraction from the various locations.
Stock movements are managed manually.
Multi-element, composite items and collections
An item may consist of several other items (volumes of a multi-element item or components of a composite item or a collection) which may or may not be ordered individually, as the case may be. Stock management is at the level of the volumes/components and/or of the multi-element/composite item/collection. If the stock of the multi-element/composite item/collection is zero or insufficient, the stock of elements is used.
For example, an item A is made up of two elements, e.g. A1 and A2.
An order line is created ordering 25 copies of item A. Two picking lines are created: one for A1 and one for A2. It has to be confirmed that A1 and A2 have been picked in order to confirm A. If A2 is stored at several locations, the same number of picking lines for A2 will be created. On dispatch, on the other hand, two lines grouping the extractions will be created: one for A1 and one for A2.
Inventory
Inventory is done in the conventional manner. The quantities in stock at the location inventoried stay blocked until that inventory is closed.
Destocking
A file injected into the system has to allow all the items in it to be taken out of stock. The items are then in "out of print" status (unless they are reproducible).
12 Description of the interfaces
13 Schema of the interfaces (status as of 2008)
[pic]
14 List of interfaces
|N° |Types |Applications |Interfaces |
|1 |Input/ output |Plan-Publi |(1) Import of items/ request for an item |
|2 |Input |Plan-Publi |(2) Import of authorisation to dispatch an item |
|3 |Input |Plan-Publi |(3) Import of blocked/unblocked status of an item |
|4 |Output |ProCat |(4) Export of pre-notices |
|5 |Output |EU-Bookshop |(5a) Export of users profiles |
| | | |(5b) Export of items |
|6 |Input |EU-Bookshop |(6) Import of items orders, for shipment and invoice (registered users) |
|7 |Output |EU-Bookshop |(7) Export of orders status |
|8 |Input/ output |SAGAPX |(8) Exchange of information (invoices, stocks changes, address of a subscriber…) |
|9 |Output |Compta/OF |(9a) Export of customer profile |
| | | |(9b) Export of invoices |
|10 |Output |Data Warehouse / |(10a) Export of administrative entities |
| | |Publications | |
| | | |(10b) Export of reference data |
| | | |(10c) Export of items |
| | | |(10d) Export of orders in progress |
| | | |(10e) Export of stock movements per locations |
| | | |(10f) Export of stock movements per owners |
| | | |(10g) Export of stocks per locations |
| | | |(10h) Export of stocks per owner |
| | | |(10i) Extract of orders and deliveries concerning the orders |
| | | |(10j) Export of accounted invoices |
|14 |Input |CERES |(11) Import of data concerning COM publications |
(1) Import of items/ request for an item
|Data processing type |Data file |
|Origin |The Plan-Publi application |
|Purpose |When Plan-Publi sends the final proof for a publication, it also sends to GESCOMX the data which are needed to |
| |create the item and to begin its commercial and logistics follow-up. |
| |GESCOMX could also request for an item sending the reference of a publication in order to create the item when |
| |Plan-Publi sends back the characteristics of that item. |
|Main data |identifiers of the origin of the request (application, user, timestamp) |
| |catalogue number and management number |
| |volume number |
| |language version |
| |ISBN number and ISSN number |
| |typology of the item |
| |one or more owners (administrative entity) |
| |production requester (administrative entity) |
| |free of charge (Y/N) |
| |tariff in euros |
| |sale revenue beneficiary (administrative entity) |
| |medium |
| |format |
| |number of pages |
| |belonging to a bundle |
| |expected date of delivery |
| |date of sent of the final proof |
(2) Import of authorisation to dispatch an item
|Data processing type |Data file |
|Origin |The Plan-Publi application |
|Purpose |After acceptance of the quality copy, Plan-Publi sends to GESCOMX the authorisation to dispatch the item. |
|Main data |identifiers of the origin of the request (application, user, timestamp) |
| |event code (acceptance of the quality copy, other…) |
| |event date |
| |catalogue number |
(3) Import of blocked/unblocked status of an item
|Data processing type |Data file |
|Origin |The Plan-Publi application |
|Purpose |At receipt of this request, GESCOMX must immediately block/unblock an item. Blocking must prevent the dispatch of|
| |the item (orders and distribution). The management of blocking is made in the PLAN-PUBLI system. |
|Main data |identifiers of the origin of the request (application, user, timestamp) |
| |event code (block/unblock) |
| |event date |
| |catalogue number |
(4) Request for title of an item - import of an item
|Data processing type |Data file. |
|Destination |ProCat |
|Purpose |This interface is required to consult the bibliographical data for the different instances of a publication, which|
| |are managed in the ProCat application. |
| |It is primary used to consult the title in language version. |
|Main data sent to ProCat |Pre-notices |
Interfaces with EU-Bookshop web site:
The commercial system is interfaced with one web site:
EU-Bookshop is the central access point to present the publications of the European Union. This portal is used by partners of Publication’s Office (such as the sales agents) and by general public to order publications.
(5a) Export of users profiles
|Data processing type |Extract of a XML-document |
|Destination |EU-Bookshop |
|Purpose |This interface extracts daily the data concerning the customers, which are registered into the web site. Only one |
| |XML DTD or schema defined for the whole lot of web sites |
|Main data |Identifier of the customer, name, default invoicing address, default delivery address, status. |
(5b) Export of items
|Data processing type |Extract of a XML-document |
|Destination |EU-Bookshop |
|Purpose |This daily interface allows sending towards the web sites the data about the items, which were modified since the |
| |last execution of the interface. Only one XML DTD or schema defined for the whole lot of web sites. |
|Main data |All identifiers of item (n° catalogue, n° management), language version, membership in a bundle, status, available|
| |quantity in stock, reproducibility, price… |
(6) Import of orders, for shipment and invoice (registered users)
|Data processing type |Import of a XML document |
|Origin |EU-Bookshop |
|Purpose |This interface allows importing orders created on a web site, in order to execute and/or invoice them. It concerns|
| |the orders of publications made from the front-office application by customers that are registered in the |
| |commercial management application. The commercial management application assures the treatment and the shipment. |
| |An invoice is created by the commercial management application according to rules applied to this customer and |
| |current rate of the sent products. |
| |This treatment is made several times a day, automatically at every reception of a file from the web site. |
| |A file contains one or several orders, from one or more customers. Only one XML DTD or schema defined for the |
| |whole lot of web sites. |
|Main data |Always: identifier of the origin, n° order attributed by the web site, identifier of the customer, invoiced |
| |address, delivery address, status of shipment, status of invoicing, and for each line of order: n° line attributed|
| |by the web site, n° catalogue and quantity ordered. |
(7) Export of orders status
|Data processing type |Import of a XML document |
|Destination |EU-Bookshop (concerning orders imported from EU-Bookshop) |
|Purpose |This interface periodically extracts the status of execution of each pending order, and of each pending line of |
| |this order. |
| |The first status is returned as acquirement of the receipt of the order and of each line (status = accepted or |
| |rejected). The last returned status of each line of order is the final status: (status = rejected or sent). The |
| |last returned status of each order is the final status: reject or confirmation of sent of the delivery. Only one |
| |XML DTD or schema defined for the whole lot of web sites. |
|Main data |Identifier of the origin, n° order attributed by the web site, n° order attributed by GESCOMX, identifier of the |
| |customer, status of the order. |
| |For each line of order: n° line attributed by the web site, n° line attributed by GESCOMX, status of the order |
| |line, n° catalogue, quantity ordered on web site, quantity ordered in GESCOMX and quantity actually dispatched by |
| |GESCOMX (these 2 last quantities can be less than quantity ordered on web site, for example in case of |
| |out-of-stock condition). |
(8) Exchange of information (invoices, stocks changes…)
|Data processing type |Database files direct changes (SAGAPX and GESCOMX share the same production database) or temporary Adabas file |
| |(for invoices) |
|Destination |GESCOMX - SAGAPX |
|Purpose |stocks changes are done in GESCOMX after dissemination of a publication via SAGAPX; |
| |GESCOMX automatically generates invoices of subscriptions from the lines of pre-invoices prepared by SAGAPX |
| |(temporary Adabas file); GESCOMX updates the Adabas file by indicating the number of invoices lines generated; |
| |SAGAPX needs GESCOMX tables (postal rates…); |
| |expedition lines are written in GESCOMX after dissemination of a publication via SAGAPX; GESCOMX gives feedbacks |
| |acknowledging the expeditions and generates expedition notes; |
| |other various crossed consultations of information (GESCOMX needs SAGAPX addresses for orders management; SAGAPX |
| |needs to check in GESCOMX if a publication is available or not for dissemination and if its stock is sufficient or|
| |not…). |
|Specific requirement |Files changes or files consultations between applications are done via batch functions or via interactive |
| |functions |
|Main data |Stock data; usual data of an invoice; address of a subscriber; expedition lines… |
(9a) Export of customer profile
|Data processing type |Flat file in the specific format. This file is copied in a temporary table in an Oracle database. |
|Destination |This file is imported in the Account Receivable module of the Oracle Financials Application. |
|Purpose |The commercial management application extracts daily the essential data describing a customer. |
|Main data |customer number |
| |name |
| |contacts |
| |invoicing address |
| |language |
(9b) Export of invoices
|Data processing type |Flat file in the specific format. This file is copied in a temporary table in an Oracle database. |
|Destination |Account Receivable module of the Oracle Financials Application. |
|Purpose |The commercial management application extracts daily the essential data describing a invoice or a credit note, in |
| |order to import these invoices or credit notes into the Account Receivable module and the to account them into the|
| |General Ledger module. |
|Main data |usual data of an invoice |
| |all data that are required to transfer the revenue from the sale to the beneficiary administrative entity |
(10) General characteristics of these interfaces
|Data processing type |Several csv flat files. These files are copied in temporary tables of an Oracle database. |
|Destination |Data Warehouse |
(10a) Export of administrative entities
This interface extracts daily the essential data describing an administrative entity.
(10b) Export of reference data
This interface extracts daily the reference data of the logistics and commercial application, including codes and libels for all codes used in the data warehouse.
(10c) Export of items
This interface extracts daily the essential data describing an item.
(10d) Export of orders in progress
This interface extracts daily the essential data describing all orders in progress.
It is imported in a specific data universe, which is reinitialised each day.
(10e) Export of stock movements per locations
This interface extracts daily the physical stock movements which have been created since the last execution.
(10f) Export of stock movements per owners
This interface extracts daily the logical stock movements which have been created since the last execution.
(10g) Export of stocks per locations
This interface extracts monthly the stock movements per locations: quantity in stock at first day of the month, at last day of the month, minimal and maximal quantity during the month.
It also provides the average quantity, the average volume and the average weight of this stock.
(10h) Export of stocks per owners
This interface extracts monthly the stock movements per locations: quantity in stock at first day of the month, at last day of the month, minimal and maximal quantity during the month.
This interface also provides the average quantity, the average volume and the average weight of this stock.
(10i) Extract of orders and deliveries concerning the orders
This interface concerns the deliveries of orders. A delivery must be fully extracted, and fully imported in the data warehouse. Then each partial reject must reject the whole delivery (all lines of the delivery).
It extracts daily the essential data of each line of deliveries that have been sent since the last execution, including the shipping cost.
(10j) Export of accounted invoices
This interface extracts daily the essential data describing the invoices, which have been accounted since the last execution. ‘Accounted’ means that these invoices have been imported with success by the Account Receivables module of Oracle Financials.
(11) Import of data concerning COM publications
GESCOMX imports COM publications from CERES.
CERES permits the creation of an excel file containing identification data about COM publications. This file is converted to a text file which is transfered to GESCOMX.
GESCOMX is then able to automatically create the item directly in the database.
15 The Data of GESCOMX
16 Overview
|Reference data |
|Reference data |Nearly 100 tables and 3000 codes. |
|Items and stock |
|Items |225.000 items in the database |
|Items with minimal data |200.000 items in the database |
|Stock of items |50 000 different items physically in stock |
| |(40 000 000 copies) |
| |60.000 relations item/storage location |
| |80.000 relations item/administrative entity |
|Archived copies |Two copies of each publication are systematically archived. Then the stock of |
| |archives concerns nearly 460.000 items. |
|Customers |
|Customers |12.500 customers |
| |
17 Reference data
Nearly 100 tables and 3000 codes.
For example: list of the country (ISO codes, names), list of the administrative entities…
18 Living items
There are currently some 532.000 items in the database.
For one item, estimate number of properties:
Commercial data: 70
Specific data depending on the type of item: 70
The number of properties to convert may be less than this estimation.
19 Items with minimal data
There are currently some 200.000 other items in the database, for which only minimal data will be converted in the new database. These items are used for archive management.
But they are not in a final status: it must be possible to later complete the data, in order to allow ordering or diffusion.
For one item, estimate number of properties to study and convert: depending on the minimal data required by the tools to create an item and to allow the management of a stock.
20 Stock of items
There are currently some 50.000 items in stock. That represents nearly 60.000 physical records and 80.000 logical records.
Current properties concerning the physical stock: n° catalogue, storage location, quantity and entrance date (optional).
Current properties concerning the logical stock: n° catalogue, administrative entity, and quantity.
For each item in stock, the total physical quantity is equal to the total logical quantity
All items must be ‘living items’
22 Archived copies
Two copies of each publication are systematically archived. Then the stock of archives concerns nearly 460.000 items. Items can be either ‘living item’ or ‘item with minimal data’.
Current properties, concerning the archived stock: n° catalogue, archive location, quantity.
23 Customers
There are currently some 12.500 customers.
Estimate number of properties to study: 70. The number of properties to convert may be less than this estimation.
Main current properties:
Properties: registration number, name or trade name, Publications Office manager, mother tongue, language used for correspondence, etc.
Status: status, period of validity, ‘bad payer’, etc.
Type: type, discount rates, invoicing frequency, characteristics of the last invoicing process.
Addresses: one or more addresses of different types: delivery address, invoice address, or generic address, history of address changes. For each address: contact, contact language, telephone, fax, validity period, delivery mode, etc.
Profile: specific rights for customers that are registered in the front office applications.
24 Other data
Conversion is required for the other data, unless study findings prove otherwise.
- Pending orders (before creation of deliveries)
- Pending deliveries
- Invoicing of subscriptions
- Historical data
- Common data in the database with other applications
25 List of interactive/batch functions of GESCOMX (as of 2008)
|Application |Intercative functions |Batch functions |
|GESCOMX |576 |109 |
|GESCOMX outils |6 (PTOOL) |92 |
|Total |582 |201 |
|Type |Number |
|Program |1069 |
|Subroutine |95 |
|Subprogram |170 |
|Helproutine |109 |
|Copycode |60 |
|Map |963 |
|Data Area |2285 |
|TOTAL |4751 |
N.B.: hereafter, a few functions or batches may not be currently used.
26 Interactive functions of GESCOMX
| |Commande directe |Libellé |
| |AFFICHER BASE |Visualisation des bases de donnees publiques |
| |AFFICHER BORDEREAU |Visualisation d'un bordereau d'expedition |
| |AFFICHER CLIENT |Visualisation d'un client |
| |AFFICHER COMMANDE |Visualisation d'une commande |
| |AFFICHER COMMANDE LIGNE |Visualisation standard d'une ligne de commande |
| |AFFICHER COMMANDE SUIVI |Suivi des commandes et lignes de commande |
| |AFFICHER CONTRAT |Visualisation d'un contrat d'acces aux B.D.P. |
| |AFFICHER CONTRAT TYPE |Visualisation d'un type de contrat d'acces aux B.D.P. |
| |AFFICHER EA |Visualisation d'une entite administrative |
| |AFFICHER EMPLACEMENT |Visualisation d'un emplacement |
| |AFFICHER ENTREPOT |Visualisation des caracteristiques d'un entrepot |
| |AFFICHER EXPEDITION |Visualisation d'une expedition |
| |AFFICHER FABRICATION |Visualisation des tirages d'une publication |
| |AFFICHER FACTURE |Visualisation d'une facture ou d'une note de credit |
| |AFFICHER FORMATION |Visualisation d'une session de formation |
| |AFFICHER FOURNITURE |Visualisation des caracteristiques d'un article utilitaire |
| |AFFICHER FRAIS |Visualisation des caracteristiques d'un frais de service |
| |AFFICHER FTRANSPORTEUR |Visualisation d'une facture/note de credit transporteur |
| |AFFICHER GROUPE |Visualisation d'un groupe utilisateur |
| |AFFICHER INSCRIPTION |Visualisation d'une inscription a une session de formation |
| |AFFICHER JOB |Consultation d'un job |
| |AFFICHER PERIODIQUE |Visualisation d'un periodique/serie indep. de la langue |
| |AFFICHER PRODUIT |Visualisation des caracteristiques d'un produit |
| |AFFICHER PRODUIT HISTORIQUE |Visualisation de l'historique des ventes d'un produit |
| |AFFICHER PRODUIT STATISTIQUE |Visualisation des donnees statistiques d'un produit |
| |AFFICHER PUBLICATION |Visualisation d'une publication independante de la langue |
| |AFFICHER PUBLICATION DIFFUSION |Visualisation des specificites d'une publication dependante |
| |AFFICHER PUBLICATION MULTI-ELEMENTS |Visualisation d'un multi-elements independant de la langue |
| |AFFICHER RETOUR |Visualisation d'un retour |
| |AFFICHER SERIE |Visualisation d'un periodique/serie independant de la langue |
| |AFFICHER STOCK |Visualisation du stock d'un article |
| |AFFICHER STOCK EA |Visualisation du stock d'un article (par proprietaire) |
| |AFFICHER STOCK EMPLACEMENT |Visualisation du stock d'un article (par emplacement) |
| |AFFICHER TABLE |Visualisation d'une table |
| |AFFICHER TABLE PERIODIQUE |Visualisation d'une table |
| |AFFICHER TABLE VL |Visualisation d'une table |
| |AFFICHER TRANSFERT |Visualisation d'une demande de transfert logique |
| |AFFICHER USER-ID |Visualisation d'un user-id |
| |CHARGER ABONNEMENTS |Chargement des abonnements SAGAPX a partir d'un fichier EXCEL |
| |CHERCHER PRODUIT |Recherche de produit |
| |CLOTURER GRILLE |Cloture des grilles de tarifs transport |
| |EXECUTER | |
| |EXECUTER JOB |Lancement d'un job automatique |
| |EXECUTER PABD002F |Visualisation des specificites d'un acces aux BDP |
| |EXECUTER PABD041F |Gestion des specificites d'un acces aux BDP |
| |EXECUTER PARC111F |Liste des mouvements des masters de publication |
| |EXECUTER PART003F |Visualisation des caracteristiques d'un produit avec 30 VL |
| |EXECUTER PART006F |Gestion des specificites d'une publication dependante |
| |EXECUTER PART021F |Visualisation des caracteristiques de stockage |
| |EXECUTER PART026F |Liste de la composition d'un article commercial |
| |EXECUTER PART031F |Visualisation des specificites d'une collection |
| |EXECUTER PART036F |Gestion des specificites d'une collection |
| |EXECUTER PART041F |Visualisation de la reproductibilite d'un article |
| |EXECUTER PART046F |Gestion de la reproductibilite d'un article |
| |EXECUTER PART056F |Gestion des caracteristiques de stockage |
| |EXECUTER PART061F |Gestion de la composition d'un article commercial |
| |EXECUTER PART071F |Visualisation des attributs d'un produit off-line |
| |EXECUTER PART076F |Gestion des attributs d'un produit off-line |
| |EXECUTER PART086F |Liste des stocks par proprietaire |
| |EXECUTER PART091F |Gestion de la liste des stocks minimums par proprietaire |
| |EXECUTER PART141F |Visualisation du reapprovisionnement |
| |EXECUTER PART146F |Gestion du reapprovisionnement |
| |EXECUTER PART151F |Appartenance de la publication a un periodique ou une serie |
| |EXECUTER PART156F |Historique des etats d'un article (aspect stockage) |
| |EXECUTER PART161F |Visualisation du stock par emplacement |
| |EXECUTER PART336F |Scenario pour passer les produits en PAD |
| |EXECUTER PCDC006F |Visualisation de l'adresse de livraison par defaut |
| |EXECUTER PCDC016F |Choix d'un produit dans une liste d'alternatives |
| |EXECUTER PCDC021F |Visualisation du commentaire de la ligne de commande |
| |EXECUTER PCDC026F |(Annulation) Reservation logique / Validation |
| |EXECUTER PCDC031F |Modification de l'adresse de livraison par defaut |
| |EXECUTER PCDC036F |Modification du commentaire de la ligne de commande |
| |EXECUTER PCDC046F |Memorisation de la demande initiale |
| |EXECUTER PCDC051F |Liste des elem. de stock reserves pour la ligne de commande |
| |EXECUTER PCDC056F |Scission d'une ligne de commande |
| |EXECUTER PCDC061F |Liste des lignes d'expedition de la ligne de commande |
| |EXECUTER PCDC066F |Liste des etats de la ligne de commande |
| |EXECUTER PCDC071F |Liste des etats de la commande |
| |EXECUTER PCDC076F |Creation des lignes de commande de volumes de multi-elements |
| |EXECUTER PCDC081F |Visualisation de la demande initiale |
| |EXECUTER PCDC086F |Validation d'une ligne de commande |
| |EXECUTER PCDC091F |Suivi d'une ligne de commande : preparation |
| |EXECUTER PCDC092F |Suivi d'une ligne de commande : expedition |
| |EXECUTER PCDC093F |Suivi d'une ligne de commande : facturation |
| |EXECUTER PCDC096F |Creation des lignes de commande de volumes de multi-elements |
| |EXECUTER PCDC121F |Gestion rapide des lignes d'une commande |
| |EXECUTER PCDC141F |Modification de la priorite des lignes de commande |
| |EXECUTER PCDC221F |Gestion d une ligne de commande de mise en depot |
| |EXECUTER PCDC241F |Gestion d une ligne de commande facture de mise en depot |
| |EXECUTER PCDC311F |Visualisation rapide des lignes d'une commande |
| |EXECUTER PCLI006F |Visualisation d'une adresse du client |
| |EXECUTER PCLI011F |Liste des conditions de facturation d'un type de client |
| |EXECUTER PCLI016F |Gestion des conditions de facturation d'un type de client |
| |EXECUTER PCLI031F |Liste des clients utilisant l'adresse |
| |EXECUTER PCLI036F |Liste des entites administratives utilisant l'adresse |
| |EXECUTER PCLI041F |Modification de la periode contractuelle |
| |EXECUTER PCLI046F |Modification d'une adresse partagee |
| |EXECUTER PCLI061F |Gestion d'une adresse du client |
| |EXECUTER PCLI071F |Gestion des adresses electroniques du client |
| |EXECUTER PCLI076F |Liste des adresses electroniques du client |
| |EXECUTER PCLI081F |Visualisation de l'historique du client |
| |EXECUTER PCLI091F |Scenario de gestion des adresses du client |
| |EXECUTER PCLI106F |Modification de l'etat 'mauvais payeur' d'un client |
| |EXECUTER PCLI161F |Liste des conditions de facturation accordees au client |
| |EXECUTER PCLI181F |Gestion des conditions de facturation accordees au client |
| |EXECUTER PCLI196F |Creation simplifiee d'un client |
| |EXECUTER PCSM006F |Gestion d'une consommation d'acces aux B.D.P. |
| |EXECUTER PCSM011F |Visualisation d'une consommation d'acces aux B.D.P. |
| |EXECUTER PCTC011F |Gestion du profil d'un contrat d'acces aux B.D.P. |
| |EXECUTER PCTC016F |Gestion des frais de service d'un contrat d'acces aux B.D.P. |
| |EXECUTER PCTC021F |Gestion de la periode de facturation d'un contrat d'acces B.D.P. |
| |EXECUTER PCTC031F |Visualisation d'un profil de contrat d'acces aux B.D.P. |
| |EXECUTER PCTC036F |Visualisation des actions sur profil d'un contrat d'acces B.D.P. |
| |EXECUTER PCTC041F |Visualisation des frais de service d'un contrat d'acces B.D.P. |
| |EXECUTER PCTC046F |Visualisation de la periode de facturation d'un contrat |
| |EXECUTER PCTC051F |Visualisation de l'historique des etats d'un contrat d'acces BDP |
| |EXECUTER PCTT011F |Gestion d'un profil de type de contrat d'acces aux B.D.P. |
| |EXECUTER PCTT016F |Gestion des remises par acces |
| |EXECUTER PCTT021F |Gestion des gratuites periodiques |
| |EXECUTER PCTT026F |Gestion des remises sur C.A. |
| |EXECUTER PCTT031F |Gestion des remises avec bareme |
| |EXECUTER PCTT036F |Scenario de gestion des remises et gratuites |
| |EXECUTER PCTT046F |Visualisation du profil de type de contrat |
| |EXECUTER PCTT051F |Visualisation des actions sur profil d'un type de contrat |
| |EXECUTER PCTT056F |Visualisation des remises sur acces |
| |EXECUTER PCTT061F |Visualisation des gratuites periodiques |
| |EXECUTER PCTT066F |Visualisation des remises sur C.A. |
| |EXECUTER PCTT071F |Visualisation des remises avec bareme |
| |EXECUTER PDEV006F |Gestion des cours de change d'une devise |
| |EXECUTER PDEV016F |Liste des cours de change d'une devise |
| |EXECUTER PDPL016F |Enregistrement des deplacements de stock |
| |EXECUTER PDVR021F |Modification d'une proposition de prelevement pour composition |
| |EXECUTER PDVR031F |Composition ou decomposition d'un article |
| |EXECUTER PEAD011F |Scenario de gestion des adresses d'une entite administrative |
| |EXECUTER PEAD016F |Gestion d'une adresse d'une entite administrative |
| |EXECUTER PEAD021F |Gestion des habilitations fonctionnelles d'une E.A. |
| |EXECUTER PEAD026F |Gestion des autorisations commerciales d'une E.A. |
| |EXECUTER PEAD041F |Visualisation des habilitations fonctionnelles d'une E.A. |
| |EXECUTER PEAD046F |Visualisation des autorisations commerciales d'une E.A. |
| |EXECUTER PEAD051F |Visualisation d'une adresse d'une entite administrative |
| |EXECUTER PEFS011F |Liste des tarifs d'un frais de service |
| |EXECUTER PEFS021F |Visualisation des tarifs par bareme d'un frais de service |
| |EXECUTER PEFS026F |Visualisation des tarifs d'urgence ou d'acheminement d'un frais |
| |EXECUTER PEFS046F |Gestion de la liste des tarifs d'un frais de service |
| |EXECUTER PEFS056F |Gestion des tarifs par bareme d'un frais de service |
| |EXECUTER PEFS061F |Gestion des tarifs d'urgence ou d'acheminement d'un frais |
| |EXECUTER PEMP021F |Visualisation des articles d'un emplacement |
| |EXECUTER PEXE006F |Validation des lignes d'un ordre extraction |
| |EXECUTER PEXE011F |Confirmation du prelevement des articles |
| |EXECUTER PEXE026F |Repartition des quantites conditionnees sur les expeditions |
| |EXECUTER PEXE041F |Validation des lignes d'un ordre de copie |
| |EXECUTER PEXE101F |Visualisation des lignes d'un ordre de reproduction |
| |EXECUTER PEXE102F |Visualisation des lignes d'un ordre d'extraction |
| |EXECUTER PEXE106F |Gestion des lignes d'un ordre de reproduction |
| |EXECUTER PEXP006F |Validation de l'affectation des lignes d'une expedition |
| |EXECUTER PEXP011F |Gestion des lignes d'une expedition |
| |EXECUTER PEXP021F |Gestion d'une expedition |
| |EXECUTER PEXP022F |Gestion d'une expedition cloturee (bloc-notes) |
| |EXECUTER PEXP026F |Prise en charge d'une expedition |
| |EXECUTER PEXP041F |Validation de l'affectation des expeditions sur le bordereau |
| |EXECUTER PEXP046F |Prise en charge d'un bordereau d'expedition |
| |EXECUTER PEXP056F |Visualisation des caracteristiques d'une expedition |
| |EXECUTER PEXP066F |Visualisation des lignes d'une expedition |
| |EXECUTER PEXP071F |Gestion d'un bordereau d'expedition |
| |EXECUTER PEXP072F |Gestion d'un bordereau d'expedition cloture (bloc-notes) |
| |EXECUTER PEXP091F |Scenario de constitution des bordereaux d'expedition |
| |EXECUTER PEXP101F |Visualisation de l'historique des etats d'une expedition |
| |EXECUTER PEXP106F |Visualisation de l'historique des etats d'un bordereau d'expe. |
| |EXECUTER PEXP116F |Modification de l'adresse de l'expedition |
| |EXECUTER PEXP121F |Modification de l'adresse du bordereau |
| |EXECUTER PFBD002F |Visualisation des specificites d'une formation BDP |
| |EXECUTER PFBD011F |Visualisation des manuels d'une formation BDP |
| |EXECUTER PFBD026F |Visualisation des gratuites associees a une formation BDP |
| |EXECUTER PFBD036F |Gestion des specificites d'une formation BDP |
| |EXECUTER PFBD046F |Gestion des manuels d'une formation BDP |
| |EXECUTER PFBD061F |Gestion des gratuites associees a une formation BDP |
| |EXECUTER PFCO326F |Visualisation des releves de facturation (mande) |
| |EXECUTER PFCO331F |Visualisation des releves de facturation (detail m.) |
| |EXECUTER PFCO336F |Visualisation des releves de facturation (expeditions) |
| |EXECUTER PFCO406F |Visualisation des lignes de facture |
| |EXECUTER PFCO411F |Visualisation des factures liees |
| |EXECUTER PFCO416F |Visualisation de l'historique des etats d'une facture |
| |EXECUTER PFCO426F |Gestion des lignes de facture |
| |EXECUTER PFCO436F |Visualisation detaillee des lignes de facture |
| |EXECUTER PFCO556F |Gestion des lignes d une note de credit mise en depot |
| |EXECUTER PFIR005F |Affichage d'une firme |
| |EXECUTER PFIR010F |Gestion d'une firme |
| |EXECUTER PFRN006F |Gestion d'une commande de fourniture |
| |EXECUTER PFRN021F |Gestion des lignes d'une commande de fourniture |
| |EXECUTER PFRN046F |Gestion des firmes commercialisant la fourniture |
| |EXECUTER PFRN056F |Liste des firmes commercialisant la fourniture |
| |EXECUTER PFRN071F |Gestion des commentaires des articles utilitaires |
| |EXECUTER PFRN076F |Visualisation des commentaires articles utilitaires |
| |EXECUTER PFRN086F |Visualisation des conditions fournisseurs |
| |EXECUTER PFRN091F |Gestion des conditions fournisseurs |
| |EXECUTER PFRN096F |Gestion de la composition d'un article utilitaire |
| |EXECUTER PFRN101F |Liste de la composition d'un article utilitaire |
| |EXECUTER PFRN106F |Visualisation des etats d'une commande de fourniture |
| |EXECUTER PFRN111F |Visualisation d'une commande de fourniture |
| |EXECUTER PFRN116F |Visualisation des lignes d'une commande de fourniture |
| |EXECUTER PGMTMP01 | BOITE A OUTILS |
| |EXECUTER PIBD011F |Gestion des gratuites d'une session de formation aux B.D.P. |
| |EXECUTER PIBD021F |Visualisation des gratuites sur session de formation aux B.D.P. |
| |EXECUTER PIBD026F |Visualisation de l'historique des etats d'une session form. BDP |
| |EXECUTER PIBD037F |Gestion des adresses d'une inscription |
| |EXECUTER PIBD042F |Visualisation de l'historique des etats d'une inscription |
| |EXECUTER PIBD043F |Visualisation des adresses d'une inscription |
| |EXECUTER PINV006F |Saisie des quantites inventoriees |
| |EXECUTER PINV026F |Affectation logique des ecarts d'inventaire |
| |EXECUTER PMNU011F |Scenario de gestion des lignes d'un menu |
| |EXECUTER PMNU051F |Gestion d'une ligne d'un menu |
| |EXECUTER PMVT006F |Imputation des proprietaires pour une sortie de stock |
| |EXECUTER PMVT101F |Visualisation des mouvements de stock - aspect physique |
| |EXECUTER PMVT102F |Visualisation des mouvements de stock - aspect logique |
| |EXECUTER PMVT112F |Visualisation d'une operation sur stock - aspect logique |
| |EXECUTER PMVT113F |Visualisation d'une operation sur stock - aspect physique |
| |EXECUTER PMVT114F |Visualisation d'une operation sur stock |
| |EXECUTER PPAB002F |Visualisation des specificites d'un abonnement |
| |EXECUTER PPAB026F |Gestion des specificites d'un abonnement |
| |EXECUTER PPAB031F |Generation automatique des abonnements |
| |EXECUTER PPDT002F |Liste des intitules commerciaux |
| |EXECUTER PPDT006F |Gestion des intitules commerciaux |
| |EXECUTER PPDT011F |Liste des E.A. beneficiaires des ventes |
| |EXECUTER PPDT016F |Gestion des E.A. beneficiaires des ventes |
| |EXECUTER PPDT021F |Historique des etats d'un produit (aspect diffusion) |
| |EXECUTER PPDT051F |Visualisation des caracteristiques d'un produit |
| |EXECUTER PPDT056F |Modification du numero de gestion d'une publication |
| |EXECUTER PPDT091F |Liste des volumes associes a un multi-elements |
| |EXECUTER PPDT096F |Liste des volumes associes a un multi-elements |
| |EXECUTER PPDT101F |Visualisation stockage / diffusion d'un multi-elements |
| |EXECUTER PPDT106F |Gestion stockage/diffusion d'un multi-elements |
| |EXECUTER PPDT111F |Liste des remises d'un produit par type de client |
| |EXECUTER PPDT116F |Gestion de la liste des remises produit par type de client |
| |EXECUTER PPDT121F |Visualisation de l'historique des exportations vers CATDIF |
| |EXECUTER PPDT126F |Gestion du code exportation a destination de CATDIF |
| |EXECUTER PPDT131F |Visualisation historique des exportations titres vers CATDIF |
| |EXECUTER PPDT305P |Recherche de produit : Recherche generale |
| |EXECUTER PPDT310P |Recherche de produit : Abonnement / Collection |
| |EXECUTER PPDT320P |Recherche de produit : Acces BDP / Formation BDP |
| |EXECUTER PPDT325P |Recherche de produit : Service divers / Contrat d'edition |
| |EXECUTER PPDT330P |Recherche produit : Gadget |
| |EXECUTER PPDT335P |Recherche de produit : Article compose |
| |EXECUTER PPDT340P |Recherche de produit : Fourniture / Archive administrative |
| |EXECUTER PPDT345P |Recherche de produit : Accessoire |
| |EXECUTER PPDT470P |Mise a jour en masse des versions linguistiques - aspect OP4 |
| |EXECUTER PPDT471P |Mise a jour en masse des versions linguistiques - aspect OP6 |
| |EXECUTER PPDT486F |Visualisation de l'historique des beneficiaires de ventes |
| |EXECUTER PPDT496F |Visualisation de l'historique des proprietaires de stock |
| |EXECUTER PPUB000P |Recherche de produit : publication |
| |EXECUTER PPUB015F |Gestion des publications cousines par support |
| |EXECUTER PPUB020F |Gestion des manuscrits |
| |EXECUTER PPUB025F |Gestion du commentaire |
| |EXECUTER PPUB036F |Gestion des versions linguistiques liees |
| |EXECUTER PPUB040F |Gestion des themes |
| |EXECUTER PPUB046F |Visualisation des versions linguistiques liees |
| |EXECUTER PPUB060F |Gestion du titre dans une langue d'une publication |
| |EXECUTER PPUB065F |Gestion des publications cousines par contenu |
| |EXECUTER PPUB070F |Gestion des services auteurs |
| |EXECUTER PPUB075F |Gestion du titre independant de la langue |
| |EXECUTER PPUB085F |Gestion d'un volume d'un multi-elements |
| |EXECUTER PPUB110F |Gestion des caracteristiques du produit fini |
| |EXECUTER PPUB115F |Gestion des numeros dans un periodique ou une serie |
| |EXECUTER PPUB125F |Scenario de gestion des titres par langue et commentaires |
| |EXECUTER PPUB130F |Gestion des rubriques cibles |
| |EXECUTER PPUB135F |Visualisation des rubriques cibles |
| |EXECUTER PPUB140F |Gestion des rubriques cibles d'un periodique/serie |
| |EXECUTER PPUB145F |Visualisation des rubriques cibles d'un periodique/serie |
| |EXECUTER PPUB195F |Visualisation des ordonnateurs par defaut d'un periodique/serie |
| |EXECUTER PPUB200F |Visualisation des themes par defaut |
| |EXECUTER PPUB205F |Visualisation des beneficiaires par defaut d'un periodique/serie |
| |EXECUTER PPUB210F |Visualisation des titres independants d'un periodique/serie |
| |EXECUTER PPUB215F |Visualisation d'un titre par langue d'un periodique/serie |
| |EXECUTER PPUB220F |Visualisation des versions linguistiques d'un periodique/serie |
| |EXECUTER PPUB235F |Visualisation des caracteristiques produit fini d'une pub. |
| |EXECUTER PPUB240F |Visualisation des publications cousines par contenu |
| |EXECUTER PPUB245F |Visualisation des publications cousines par support |
| |EXECUTER PPUB250F |Visualisation des donnees des manuscrits d'une publication |
| |EXECUTER PPUB255F |Visualisation des numeros dans un P/S d'une publication |
| |EXECUTER PPUB260F |Visualisation des services auteurs d'une publication |
| |EXECUTER PPUB270F |Visu. des titres independants de la langue d'une pub. |
| |EXECUTER PPUB275F |Visualisation du titre dans une langue d'une publication |
| |EXECUTER PPUB285F |Visualisation d'un volume d'un multi-elements |
| |EXECUTER PPUB290F |Visualisation du commentaire d'une publication |
| |EXECUTER PPUB295F |Visualisation du titre unicode d'une publication |
| |EXECUTER PPUB350F |Visualisation des themes d'une publication |
| |EXECUTER PPUB400P |Recherche de produit : Periodique / Serie |
| |EXECUTER PPUB410F |Scenario de gestion des titres par langue |
| |EXECUTER PPUB440F |Gestion des themes par defaut |
| |EXECUTER PPUB445F |Gestion des ordonnateurs par defaut |
| |EXECUTER PPUB450F |Gestion du titre independant de la langue |
| |EXECUTER PPUB455F |Gestion du titre par langue d'un periodique/serie |
| |EXECUTER PPUB460F |Gestion des beneficiaires de vente par defaut |
| |EXECUTER PPUB805F |Gestion d'un blocage |
| |EXECUTER PPUB815F |Gestion d'un deblocage |
| |EXECUTER PPUB820F |Visu. d'un blocage/deblocage d'une pub. ou d'un accessoire |
| |EXECUTER PQUO002F |Liste des quotas associes a un article |
| |EXECUTER PQUO006F |Gestion des quotas associes a un article |
| |EXECUTER PREM036F |LIste des remises particulieres du client |
| |EXECUTER PREM041F |Liste des remises d'un type de client |
| |EXECUTER PREM051F |Gestion des remises particulieres du client |
| |EXECUTER PREM056F |Gestion des remises d'un type de client |
| |EXECUTER PRET061F |Liste des etats d'un retour |
| |EXECUTER PRPN006F |Visualisation des caracteristiques d'une reception |
| |EXECUTER PRPN011F |Gestion de la repartition du stock entre proprietaire |
| |EXECUTER PRPN021F |Gestion des lignes d'une reception |
| |EXECUTER PRPN026F |Affichage de la repartition du stock entre proprietaires |
| |EXECUTER PRPN031F |Visualisation des lignes d'une reception |
| |EXECUTER PSRV006F |Visualisation des specificites du droit d'edition |
| |EXECUTER PSRV011F |Gestion des specificites du droit d'edition |
| |EXECUTER PSTS006F |Gestion d'une proposition de reduction de stock |
| |EXECUTER PSTS026F |Visualisation d'une proposition de reduction de stock |
| |EXECUTER PTAR002F |Liste des tarifs d'un produit |
| |EXECUTER PTAR006F |Visualisation des tarifs de type bareme |
| |EXECUTER PTAR011F |Gestion de la liste des tarifs d'un produit |
| |EXECUTER PTAR016F |Gestion des tarifs de type bareme |
| |EXECUTER PTAR021F |Visualisation des tarifs de frais d'envoi sur elt de diffusion |
| |EXECUTER PTAR026F |Gestion des tarifs de frais d'envoi sur element de diffusion |
| |EXECUTER PTAR031F |Visualisation des tarifs de type document delivery |
| |EXECUTER PTAR036F |Gestion des tarifs de type document delivery |
| |EXECUTER PTAR041F |Visualisation des tarifs de type bareme forfaitaire mixe |
| |EXECUTER PTAR046F |Gestion des tarifs de type bareme forfaitaire mixe |
| |EXECUTER PTRP011F |Scenario de gestion des grilles de tarifs de transport |
| |EXECUTER PTRP016F |Visualisation d'une grille de tarifs de transport |
| |EXECUTER PTRP021F |Scenario de gestion des tarifs de transport d'une grille |
| |EXECUTER PTRP026F |Visualisation d'un tarif de transport |
| |EXECUTER PTRP031F |Gestion d'un tarif de transport |
| |EXECUTER PTRP036F |Liste des prix par classe de masse |
| |EXECUTER PTRP041F |Gestion des prix par classe de masse |
| |EXECUTER PTRP046F |Simulation calcul frais d'un envoi |
| |EXECUTER PTRP056F |Gestion d'une grille de tarifs de transport |
| |EXECUTER PTXT011F |Gestion d'un texte standard d'un etat |
| |EXECUTER PUSB016F |Visualisation historique des implementations pour un user-id |
| |EXECUTER PUSR021F |Gestion des habilitations Planning |
| |EXECUTER PUSR026F |Gestion des droits sur commandes (droits sur stocks EA) |
| |EXECUTER PUSR031F |Gestion des habilitations entrepots |
| |EXECUTER PUSR041F |Gestion des droits sur commandes (conditions commerciales) |
| |EXECUTER PUSR046F |Gestion des droits sur commandes (conditions d'execution) |
| |EXECUTER PUSR056F |Visualisation des habilitations entrepots |
| |EXECUTER PUSR061F |Visu. des droits sur commandes (droits sur stocks EA) |
| |EXECUTER PUSR066F |Visu. des droits sur commandes (conditions commerciales) |
| |EXECUTER PUSR071F |Visu. des droits sur commandes (conditions d'execution) |
| |EXTRAIRE | |
| |EXTRAIRE DIFFUSION |EXTRACTION DES AVIS DE DIFFUSION DANS UN FICHIER CSV |
| |EXTRAIRE DOSSIER |Extraction de dossiers de diffusion |
| |EXTRAIRE LOGARCH |Saisie des critères pour lancement TP interface LogArch |
| |FIN | |
| |GERER | |
| |GERER ARCHIVAGE |Entree en archive d'un article |
| |GERER BASE |Gestion des bases de donnees publiques |
| |GERER CLIENT |Gestion d'un client |
| |GERER COMMANDE |Gestion d'une commande |
| |GERER COMMANDE DEPOT |Gestion d'une commande de mise en depot |
| |GERER COMMANDE FACTURE |Gestion d'une commande-facture de mise en depot |
| |GERER COMMANDE LIGNE |Gestion standard d'une ligne de commande |
| |GERER CONTRAT |Gestion d'un contrat d'acces aux B.D.P. |
| |GERER CONTRAT TYPE |Gestion d'un type de contrat d'acces aux B.D.P. |
| |GERER DEVISE |Gestion des devises |
| |GERER EA |Gestion d'une entite administrative |
| |GERER EMPLACEMENT |Gestion d'un emplacement |
| |GERER ENTREPOT |Gestion d'un entrepot |
| |GERER FACTURE |Gestion d'une facture ou d'une note de credit |
| |GERER FORMATION |Gestion d'une session de formation |
| |GERER FOURNITURE |Gestion d'un article utilitaire |
| |GERER FRAIS |Gestion d'un frais de service |
| |GERER FTRANSPORTEUR |Gestion d'une facture/note de credit transporteur |
| |GERER FTRANSPORTEUR COMPTABLE |Gestion du controle comptable des factures transporteur |
| |GERER FTRANSPORTEUR TECHNIQUE |Gestion du controle technique des factures transporteur |
| |GERER GROUPE |Gestion d'un groupe utilisateur |
| |GERER INSCRIPTION |Gestion d'une inscription a une session de formation |
| |GERER MASTER |Gestion de l'archivage des masters de publication |
| |GERER MENU |Gestion d'un menu |
| |GERER MOUVEMENT RECEPTION |Creation de mouvements d'entree en stock d'un article |
| |GERER MOUVEMENT SORTIE |Creation de mouvements de sortie en stock d'un article |
| |GERER MULTI-ELEMENTS VL |Gestion des versions linguistiques d'un multi-elements |
| |GERER NOTE CBV |Gestion d une note de credit de mise en depot |
| |GERER PARAMETRE |Gestion des parametres d'environnement |
| |GERER PERIODIQUE |Gestion d'un periodique ou d'une serie indep. de la langue |
| |GERER PERIODIQUE VL |Gestion des versions linguistiques |
| |GERER PRODUIT |Gestion d'un produit |
| |GERER PUBLICATION |Gestion d'une publication independante de la langue |
| |GERER PUBLICATION VL |Gestion des versions linguistiques d'une publication |
| |GERER RECEPTION |Gestion des caracteristiques d'une reception |
| |GERER RECEPTION MULTI-VL |Gestion d'une reception multi VL |
| |GERER RETOUR |Gestion d'un retour |
| |GERER RETOUR LIGNE |Gestion des lignes d'un retour |
| |GERER SERIE |Gestion d'un periodique ou d'une serie indep. de la langue |
| |GERER SERIE VL |Gestion des versions linguistiques |
| |GERER SORTIE STOCK |Saisie des emplacements et proprietaires pour sortie de stock |
| |GERER STOCK EA |Visualisation du stock d'un article (logique par proprietaire) |
| |GERER TABLE |Gestion d'une table |
| |GERER TABLE PERIODIQUE |Gestion d'une table |
| |GERER TABLE VL |Gestion d'une table |
| |GERER TEXTE ETAT |Gestion des textes standards d'un etat |
| |GERER TEXTE TABLE |Gestion des textes standards des codes d'une table |
| |GERER TRANSFERT |Gestion d'une demande de transfert logique |
| |GERER USER-ID |Gestion d'un user-id |
| |GERER UTILISATEUR |Gestion d'un utilisateur |
| |IMPRIMER CONTRAT TYPE |Edition des fiches signaletiques de type de contrat |
| |IMPRIMER EA |Edition des fiches signaletiques d'Entite Administrative |
| |IMPRIMER EXPEDITION |Reedition des avis, etiquettes et listes de conditionnement |
| |IMPRIMER FACTURE COMMANDE |Edition des releves de facturation de commandes client |
| |IMPRIMER FACTURE DUPLICATA |Edition de duplicatas de factures ou notes de credit |
| |IMPRIMER FORMATION |Edition de la liste des participants a une session de formation |
| |IMPRIMER FTRANSPORTEUR |Edition des factures/notes de credit transporteur |
| |IMPRIMER JOB |Edition des fichiers d'impression d'un job |
| |IMPRIMER UTILISATEUR |Edition des fiches signaletiques groupe/utilisateur |
| |INSERER GRILLE |Mise à jour des tarifs de transport |
| |LISTER DEVISE |Liste des devises |
| |LISTER FABRICATION |Visualisation de l'historique des retirages d'une publication |
| |LISTER FIRME |Liste des firmes |
| |LISTER MOUVEMENT |Visualisation de la liste des mouvements de stock |
| |LISTER MULTI-ELEMENTS VL |Visualisation des versions linguistiques d'un multi-elements |
| |LISTER PERIODIQUE VL |Visualisation des versions linguistiques d'un periodique/serie |
| |LISTER PUBLICATION VL |Visualisation des versions linguistiques d'une publication |
| |LISTER RETOUR LIGNE |Visualisation des lignes d'un retour |
| |LISTER SERIE VL |Visualisation des versions linguistiques d'un periodique/serie |
| |MAINTENIR | |
| |MAINTENIR ARTICLE |Scenario de gestion des articles (aspect stockage) |
| |MAINTENIR ARTICLE ETAT |Scenario de suivi des articles sans stock |
| |MAINTENIR ARTICLE STOCK |Gestion des articles a completer (aspect stockage) |
| |MAINTENIR BLOCAGE SUIVI |Scenario de suivi des blocages et deblocages |
| |MAINTENIR BORDEREAU |Scenario de gestion des bordereaux d'expedition |
| |MAINTENIR CBV |Recherches multi-criteres commandes de mise en depot |
| |MAINTENIR CLIENT |Scenario de gestion des clients |
| |MAINTENIR COMMANDE |Scenario de gestion des commandes |
| |MAINTENIR COMMANDE FOURNITURE |Scenario de gestion des commandes de fournitures |
| |MAINTENIR COMMANDE LIGNE |Scenario de gestion des lignes de commande |
| |MAINTENIR CONSOMMATION |Scenario de gestion des consommations d'acces aux B.D.P. |
| |MAINTENIR CONTRAT |Scenario de gestion des contrats d'acces aux B.D.P. |
| |MAINTENIR CONTRAT TYPE |Scenario de gestion des types de contrat d'acces aux B.D.P. |
| |MAINTENIR DEPLACEMENT |Gestion des deplacements de stock |
| |MAINTENIR DESTOCKAGE |Scenario de gestion des propositions de reduction de stock |
| |MAINTENIR EA |Scenario de gestion des entites administratives |
| |MAINTENIR EMPLACEMENT |Gestion hierarchique d'emplacements |
| |MAINTENIR EXPEDITION |Scenario de gestion des expeditions |
| |MAINTENIR FACTURE |Scenario de gestion des factures |
| |MAINTENIR FACTURE COMMANDE |Scenario de visualisation des releves de facturation |
| |MAINTENIR FACTURE LIGNE |Scenario de gestion des lignes de facture |
| |MAINTENIR FORMATION |Scenario de gestion des sessions de formation |
| |MAINTENIR FOURNITURE |Scenario de gestion des articles utilitaires |
| |MAINTENIR FTRANSPORTEUR |Scenario de gestion des factures/notes de credit transporteur |
| |MAINTENIR GROUPE |Scenario de gestion des groupes utilisateurs |
| |MAINTENIR INSCRIPTION |Scenario de gestion des inscriptions aux sessions de formation |
| |MAINTENIR INVENTAIRE |Scenario de gestion des inventaires |
| |MAINTENIR JOB |Liste des jobs |
| |MAINTENIR MENU |Scenario de gestion des menus |
| |MAINTENIR OPERATION |Scenario de visualisation des operations sur stock |
| |MAINTENIR ORDRE |Validation des ordres d'execution |
| |MAINTENIR ORDRE LIGNE |Scenario de gestion des lignes d'ordre |
| |MAINTENIR PERIODIQUE |Scenario de gestion des periodiques et des series |
| |MAINTENIR PRODUIT |Scenario de gestion des produits |
| |MAINTENIR PRODUIT TECHNIQUE |Scenario de gestion des produits - version test |
| |MAINTENIR PUBLICATION |Scenario de gestion des publications |
| |MAINTENIR RECEPTION |Scenario de gestion des receptions |
| |MAINTENIR RETOUR |Scenario de gestion des retours |
| |MAINTENIR RETOUR LIGNE |Scenario de gestion des lignes de retours |
| |MAINTENIR SERIE |Scenario de gestion des periodiques et des series |
| |MAINTENIR STOCK VL |Scenario de gestion des stocks (par versions linguistiques) |
| |MAINTENIR TABLE |Scenario de gestion des tables |
| |MAINTENIR TABLE VL |Scenario de gestion des tables |
| |MAINTENIR TRANSFERT |Scenario de gestion des transferts logiques |
| |MAINTENIR USER-ID |Scenario de gestion des user-id |
| |MAINTENIR UTILISATEUR |Scenario de gestion des utilisateurs |
| |MAINTENIR VOLUME |Scenario de gestion des volumes d'un multi-elements |
| |MENU |Menu principal du profil utilisateurs |
| |MENU ADMINISTRATION |MENU ADMINISTRATION |
| |MENU ARCHIVAGE |GESTION DE l'ARCHIVAGE DES ARTICLES |
| |MENU ARTICLE |MENU DE GESTION DES PRODUITS - "OP/6" |
| |MENU BASE |MENU DE GESTION DES BASES DE DONNEES PUBLIQUES |
| |MENU BASE TABLE |MENU DE GESTION DES BASES DE DONNEES ET DES TABLES |
| |MENU CLIENT |MENU DE GESTION DES CLIENTS |
| |MENU CLIENT REMISE |GESTION DES REMISES CLIENTS |
| |MENU CLIENT STATISTIQUE |STATISTIQUES CLIENTS |
| |MENU CLIENT TYPE |GESTION REMISES ET CONDITIONS FACTURATION D'UN TYPE CLIENT |
| |MENU COMMANDE |MENU DE GESTION DES COMMANDES CLIENTS |
| |MENU COMMANDE DEPOT |MENU DE GESTION DES COMMANDES DE MISE EN DEPOT |
| |MENU COMMANDE EXECUTION |PREPARATION DES COMMANDES |
| |MENU COMMANDE FOURNITURE |GESTION DES COMMANDES DE FOURNITURES |
| |MENU COMMANDE STATISTIQUE |STATISTIQUES COMMANDES CLIENTS |
| |MENU CONTRAT |MENU DE GESTION DES CONTRATS D'ACCES AUX B.D.P. |
| |MENU CONTRAT TYPE |MENU DE GESTION DES TYPES DE CONTRAT D'ACCES AUX B.D.P. |
| |MENU DATE |MENU TEST MENU |
| |MENU DEPLACEMENT |GESTION DES DEPLACEMENTS ET COMPOSITION |
| |MENU DESTOCKAGE |GESTION DU DESTOCKAGE DES ARTICLES |
| |MENU DEVISE |MENU DES FONCTIONS DE GESTION PARTICULIERES |
| |MENU EA |MENU DES FONCTIONS DE GESTION PARTICULIERES |
| |MENU EMPLACEMENT |GESTION DES ENTREPOTS ET EMPLACEMENTS |
| |MENU EXPEDITION |GESTION DES EXPEDITIONS |
| |MENU FACTURE |MENU DE GESTION DES FACTURES |
| |MENU FIRME |MENU DE GESTION DES FIRMES |
| |MENU FORMATION |MENU DE GESTION DES SESSIONS |
| |MENU FRAIS |MENU DE GESTION DES FRAIS DE SERVICE |
| |MENU FTRANSPORTEUR |MENU DE GESTION DU CONTROLE DES FACTURES TRANSPORTEURS |
| |MENU GESCOMX |Menu general de l'environnement de developpement |
| |MENU GROUPE |MENU DE GESTION DES MENUS ET DES UTILISATEURS |
| |MENU INVENTAIRE |GESTION DES INVENTAIRES DE STOCK |
| |MENU JOB |MENU DE SUIVI DES JOS |
| |MENU MENU |MENU DE GESTION DES MENUS ET DES UTILISATEURS |
| |MENU MOUVEMENT |MENU GESTION DES MOUVEMENTS DE STOCK |
| |MENU PARAMETRE |MENU DE GESTION DES TABLES |
| |MENU PERIODIQUE |MENU DE GESTION DES PERIODIQUES ET DES SERIES |
| |MENU PLANNING |MENU APPLICATION PLANNING |
| |MENU PRODUIT |MENU DE GESTION DES PRODUITS - "OP/4" |
| |MENU PRODUIT STATISTIQUE |STATISTIQUES PRODUITS |
| |MENU PUBLICATION |MENU DE GESTION DES PUBLICATIONS |
| |MENU RECEPTION |GESTION DES RECEPTIONS |
| |MENU RETOUR |MENU DE GESTION DES RETOURS |
| |MENU SERIE |MENU DE GESTION DES PERIODIQUES ET DES SERIES |
| |MENU STOCK |GESTION DES STOCKS |
| |MENU SUIVI FABRICATION |MENU DE SUIVI DE FABRICATION |
| |MENU TABLE |MENU DE GESTION DES TABLES |
| |MENU TARIF TRANSPORT |MENU DE GESTION DES TARIFS DE TRANSPORT |
| |MENU TRANSFERT |MENU DE GESTION DES TRANSFERTS LOGIQUES |
| |MENU UTILISATEUR |MENU DE GESTION DES UTILISATEURS |
| |MODIFIER ARTICLE |Gestion des caracteristiques de stockage |
| |MODIFIER STOCK |Correction du stock disponible d'un article |
| |SUPPRIMER JO |Scenario de suppression des JO inutilises |
| |SUPPRIMER JOB |Suppression ou arret d'un job |
| |SUPPRIMER PUBLICATION |Suppression d'une publication |
| |VALIDER EXPEDITION ARTICLE |Validation des quantites à conditionner par article |
| |VALIDER TRANSFERT |Enregistrement des reponses des proprietaires |
| |AFFICHER BASE |Visualisation des bases de donnees publiques |
| |AFFICHER BORDEREAU |Visualisation d'un bordereau d'expedition |
| |AFFICHER CLIENT |Visualisation d'un client |
| |AFFICHER COMMANDE |Visualisation d'une commande |
| |AFFICHER COMMANDE LIGNE |Visualisation standard d'une ligne de commande |
| |AFFICHER COMMANDE SUIVI |Suivi des commandes et lignes de commande |
| |AFFICHER CONTRAT |Visualisation d'un contrat d'acces aux B.D.P. |
| |AFFICHER CONTRAT TYPE |Visualisation d'un type de contrat d'acces aux B.D.P. |
| |AFFICHER EA |Visualisation d'une entite administrative |
| |AFFICHER EMPLACEMENT |Visualisation d'un emplacement |
| |AFFICHER ENTREPOT |Visualisation des caracteristiques d'un entrepot |
| |AFFICHER EXPEDITION |Visualisation d'une expedition |
| |AFFICHER FABRICATION |Visualisation des tirages d'une publication |
| |AFFICHER FACTURE |Visualisation d'une facture ou d'une note de credit |
| |AFFICHER FORMATION |Visualisation d'une session de formation |
| |AFFICHER FOURNITURE |Visualisation des caracteristiques d'un article utilitaire |
| |AFFICHER FRAIS |Visualisation des caracteristiques d'un frais de service |
| |AFFICHER FTRANSPORTEUR |Visualisation d'une facture/note de credit transporteur |
| |AFFICHER GROUPE |Visualisation d'un groupe utilisateur |
| |AFFICHER INSCRIPTION |Visualisation d'une inscription a une session de formation |
| |AFFICHER JOB |Consultation d'un job |
| |AFFICHER PERIODIQUE |Visualisation d'un periodique/serie indep. de la langue |
| |AFFICHER PRODUIT |Visualisation des caracteristiques d'un produit |
| |AFFICHER PRODUIT HISTORIQUE |Visualisation de l'historique des ventes d'un produit |
| |AFFICHER PRODUIT STATISTIQUE |Visualisation des donnees statistiques d'un produit |
| |AFFICHER PUBLICATION |Visualisation d'une publication independante de la langue |
| |AFFICHER PUBLICATION DIFFUSION |Visualisation des specificites d'une publication dependante |
| |AFFICHER PUBLICATION MULTI-ELEMENTS |Visualisation d'un multi-elements independant de la langue |
| |AFFICHER RETOUR |Visualisation d'un retour |
| |AFFICHER SERIE |Visualisation d'un periodique/serie independant de la langue |
| |AFFICHER STOCK |Visualisation du stock d'un article |
| |AFFICHER STOCK EA |Visualisation du stock d'un article (par proprietaire) |
| |AFFICHER STOCK EMPLACEMENT |Visualisation du stock d'un article (par emplacement) |
| |AFFICHER TABLE |Visualisation d'une table |
| |AFFICHER TABLE PERIODIQUE |Visualisation d'une table |
| |AFFICHER TABLE VL |Visualisation d'une table |
| |AFFICHER TRANSFERT |Visualisation d'une demande de transfert logique |
| |AFFICHER USER-ID |Visualisation d'un user-id |
| |CHARGER ABONNEMENTS |Chargement des abonnements SAGAPX a partir d'un fichier EXCEL |
| |CHERCHER PRODUIT |Recherche de produit |
| |CLOTURER GRILLE |Cloture des grilles de tarifs transport |
| |EXECUTER | |
| |EXECUTER JOB |Lancement d'un job automatique |
| |EXECUTER PABD002F |Visualisation des specificites d'un acces aux BDP |
| |EXECUTER PABD041F |Gestion des specificites d'un acces aux BDP |
| |EXECUTER PARC111F |Liste des mouvements des masters de publication |
| |EXECUTER PART003F |Visualisation des caracteristiques d'un produit avec 30 VL |
| |EXECUTER PART006F |Gestion des specificites d'une publication dependante |
| |EXECUTER PART021F |Visualisation des caracteristiques de stockage |
| |EXECUTER PART026F |Liste de la composition d'un article commercial |
27 Batches of GESCOMX
| |Commande directe ou automatique |Libellé |
| |PARC011B |Edition liste des archives sorties pour prêts non retournées |
| |PARC021B |Edition liste des publications destockées associées a un master |
| |PART201B |Génération de masse des Journaux officiels |
| |PCDC131B |Génération des lignes de commande pour un périodique ou une série |
| |PCDC411B |Edition de la liste des alternatives |
| |PCSM016B |Statistiques sur les consommations d'accès aux B.D.P. |
| |PCSM021B |Enregistrement d'un fichier de consommations d'accès aux BDP |
| |PCTC056B |Statistiques sur les contrats d'accès aux B.D.P. |
| |PDVR006B |Edition de la liste "Stock moyen" des articles |
| |PDVR011B |Composition ou décomposition d'une collection |
| |PDVR041B |Edition des articles en deça du seuil mini par entrepôt |
| |PEMP031B |Edition d'une proposition de stockage |
| |PEPT011B |Edition de la liste de contrôle d'un entrepôt |
| |PEXE053B |Exécution d'une commande immédiate ou urgente |
| |PEXE056B |Réédition de la liste des copies physiques |
| |PEXE057B |Réédition de la liste de prélèvement |
| |PEXE064B |Exécution immédiate d'une commande de fournitures |
| |PEXP075B |Edition des bordereaux d'expédition |
| |PFAB931B |Edition de la liste des publications ou accessoires bloques |
| |PFCO361B |Statistiques sur factures d'abonnement |
| |PFCO441B |Edition des factures |
| |PFCO516B |Statistiques sur factures de consommation d'accès aux B.D.P. |
| |PFCO526B |Statistiques sur les factures de formation |
| |PIBD051B |Statistiques sur les sessions de formation |
| |PINV016B |Edition de la liste des écarts d'inventaire |
| |PINV021B |Edition d'un ordre d'inventaire |
| |PINV051B |Clôture d'un inventaire |
| |PINV101B |Génération d'un ordre d'inventaire |
| |PMNU016B |Impression d'un menu |
| |PPDT452B |Mise a jour de masse des quotas JO |
| |PPDT470P |Mise a jour en masse des versions linguistiques - aspect OP4 |
| |PPDT471P |Mise a jour en masse des versions linguistiques - aspect OP6 |
| |PPUB991B |Edition d'une publication indépendante de la langue |
| |PPUB996B |Edition d'un périodique ou d'une série indép. de la langue |
| |PRPN036B |Edition des réceptions d'articles |
| |PSTA021B |Edition des fiches signalétiques commandes clients |
| |PSTA032B |Edition du relevé d'activité en volume commande |
| |PSTA041B |Edition des remises des commandes clients |
| |PSTA051B |Edition du relevé d'activité en volume et montant |
| |PSTA101B |Edition des fiches signalétiques des tables simples |
| |PSTA121B |Edition des fiches signalétiques clients |
| |PSTA131B |Edition des fiches signalétiques produits |
| |PSTA141B |Statistiques sur clients |
| |PSTA221B |Statistiques comptables |
| |PSTA311B |Liste des articles et quantités en stock |
| |PSTA331B |Exportation multi-critères des articles après 1ere livraison |
| |PSTS016B |Edition des propositions de réduction de stock |
| |PSTS101B |Génération des propositions de réduction de stock |
| |PSTS151B |Edition des articles périmés |
| |PSTS156B |Edition des publications obsolètes |
| |PSTS161B |Déstockage en masse des articles |
| |PSTS201B |Edition de la liste des réductions de stock |
| |PART096B |Proposition de réapprovisionnement |
| |PART221B |Interface "1ere entrée en stock" de GESCOMX / CRENOT- CATEL |
| |PART251B |Interface "Notices et Titres" de GESCOMX vers CATDIFF |
| |PART266B |Interface PROCAT / GESCOMX des titres riches |
| |PART281B |Interface SEIDOC / GESCOMX |
| |PCDC401B |Clôture automatique des commandes |
| |PCDC421B |Passage des commandes à l'état |
| |PCDC452B |Interface « COMMANDE » de CATDIFF dans GESCOMX |
| |PCDC462B |Renvoi des commandes vers CATDIFF |
| |PCTC061B |Implémentation des user-id |
| |PDEL001B |DELETE / A-STPORD : suppression des ordres clôturés |
| |PDVR006B |Calcul stock moyen |
| |PDVR020B |Extraction du fichier des articles pour datawarehouse stock |
| |PDWH001B |Extraction des fichiers mouvements et stock pour datawarehouse stock |
| |PDWH010B |Extraction des fichiers emplacements et propriétaires pour datawarehouse stock |
| |PEAD061B |Interface "Entites Administratives" de GESCOMX vers CATDIFF |
| |PEXE051B |Génération ordres et expéditions |
| |PEXE055B |édition liste prélèvement et copie physique |
| |PEXE059B |Edition étiquettes et avis expédition |
| |PEXE060B |Réédition étiquettes expédition |
| |PEXE201B |Edition demande reproduction par lot |
| |PEXE301B |Déblocage des commandes en attente |
| |PEXE302B |Déblocage qualité |
| |PEXP111B |Clôture des expéditions et bordereaux |
| |PFCO301B |Facturation commandes clients |
| |PFCO311B |Edition des relevés de factures de commandes client |
| |PFCO316B |Règlement factures anticipées de commande |
| |PFCO341B |Remboursement des retours clients |
| |PFCO371B |Facturation des abonnements |
| |PFCO441B |Edition des factures |
| |PFCO474B |Suppression des retours annules |
| |PFCO501B |Facturation des consommations et frais BDP |
| |PFCO505B |Simulation des facturations des consommations et frais BDP |
| |PFFX026B |Edition des informations sur les factures transporteur |
| |PSTA321B |Contrôle d’intégrité des stocks |
| |PTAB101B |Interface "Tables de références" de GESCOMX vers CATDIFF |
| |PUSB023B |Extraction manuelle de demandes d’implémentation de user-id |
| |PUSR036B |Edition des fiches signalétiques groupe/utilisateur |
Annex 16 SAGAPX description
Introduction
The SAGAPX functions are divided into 2 fields:
• the addresses and subscriptions management (field called SAGAPX lot 1)
• the distribution management (field called SAGAPX lot 2)
1 Functions of SAGAPX lot 1
23 Addresses management
The main function of lot 1 is the addresses management. These addresses are created manually or imported in bulk (importation of files). Their coding is standardised, and is the object of a large number of quality controls.
The addresses can be exported for the use of the Institutions ‘owners’ of these addresses. There are also several statistics or multi-criteria checklists.
The direct costs of creation and storage of addresses are invoiced to the institutions via PRESTOPX.
24 Mailing lists management
The addresses are organised via mailings lists. A mailing list represents all the addresses to which one ore more publications have to be distributed (official journal, magazines or monographs depending on the requests of the author).
25 Subscriptions management
A subscription is managed as the relation between one address and a mailing list, for one language version and a given period. SAGAPX supports annual and monthly subscriptions.
26 Invoicing of subscriptions
The invoicing of subscriptions is prepared in SAGAPX. For this purpose mailing lists concerning paying subscriptions contain the references of the corresponding GESCOMX articles of the type ‘subscription’. On the basis of this preparation the corresponding invoices will be generated by GESCOMX.
27 Label creation
The lot 1 of SAGAPX implements the first stage of the distribution process.
Originally, Lot 1 ensured the totality of the distribution as far as the creation of the labels corresponding to mailing lists. These labels were than used by the distribution team in Gasperich. The distribution of the Official Journal is still carried out in this way.
For the OJ distribution, SAGAPX lot 1 extracts two lists of labels:
• one is transmitted by dossier to the SITMA machine, for automatic folding and packing,
• the other for manual folding and packing (according to number of copies, weight and format).
SAGAPX lot 1 also provides statistics, making it possible to divide the distribution costs among the authorising entities. The costs are then inserted in PRESTOPX.
On the other hand, the history of the consignments details is not done: no distribution lines are created and there is no loading into the data warehouse.
1 Functions of SAGAPX lot 2
The lot 2 of SAGAPX allows preparation and execution of distribution dossiers, with calculation of the transport costs, and historisation of the details of each consignment.
28 The creation of a distribution dossier
A distribution dossier is made up to distribute a publication to a selection of addresses.
The addresses to be selected are defined in a distribution plan. This consists of a collection of one or several distribution mailing lists.
A distribution list can be:
• one or several mailing lists in their entirety (created in lot 1 and representing a ‘stable’ population)
• a list of addresses selected by means of certain criteria (e.g. list of lobbies, members of Parliament)
• a list of addresses selected one by one (in lot 1)
A distribution dossier covers usually one publication. On the other hand it can concern all the language versions of this publication.
The distribution can only be implemented after receipt of the ‘permission to distribute’ and the availability of the publication in GESCOMX.
It is possible to generate statistics and to estimate the transport costs before the execution of the dossier. It is thus possible to know the exact quantity to be distributed.
29 The calculation of the distribution costs
The distribution costs are calculated and transferred to PRESTOPX.
30 Simplified stock management
Certain publications do not have their stock management in GESCOMX (e.g. the COM documents). SAGAPX lot 2 has a very simplified stock management, allowing to execute one or more stock entries, and exits after distribution. The recorded exit is always equal to the total of deliveries. It’s therefore a transitory stock limited to the lifetime of the dossier.
31 Schematic of the interfaces
[pic]
1 Module A: Addresses, mailing lists and subscriptions management
Structure example
This implementation example hereafter, taken from SagapX lot 1, is given in order to help the tenderer to understand the working of our current application and to determine whether the proposed software corresponds to the requirements. It must not be considered as the required structure for the new application.
Structure example (non limitative):
[pic]
In our application a customer can subscribe to one or several publications (Subscription (a)). A mailing list (Mailing(b)) is associated to each subscription, this mailing list gathers together all the subscriptions to a publication. For each publication the subscriber can choose to receive one or more copies in one or several linguistic versions (Subscriptions (a)). In the case of a paying publication, the subscription contains information about the invoicing.
For each operation on the database, the name of the operator (Operators) and the date of the modification are saved. In addition, several fields (shipping methods, function code, etc…) can be filled in by selecting a value in an associated table.
It is possible to define two different shipping methods; the first one is the default value and is stored with the address’s data, the second one is part of the subscriptions data.
Example : If Mr X wants to receive 5 copies in Portuguese and 10 copies in English of the Official Journal, OPOCE will register him to one mailing list called OCDJOS (Official Journal) and will create two attached subscriptions : one for the delivery of 5 copies in Portuguese and one for 10 copies in English.
2 Module B: Warehouse & Orders management
32 Catalogue Number
A catalogue number is a unique number given by the OPOCE to a publication in one language version. This number is used by several applications at the OPOCE for warehouse, order and distribution management and is also printed on the publication itself. It consists of a series of numbers and letters:
Example : KO 63 04 416 FR C
Positions 1-2 = authors code (DG)
Positions 3-4 = if letters = magazine and if numbers = monograph (sequential number)
Positions 5-6 = year of the publication (year of edition request)
Positions 7-8-9 = sequential number
Positions 10-11 = language version
Position 12 = type of support of the document (paper/cd/.etc.)
33 Reception coding
Reception coding is done in GescomX. The physical characteristics, date, title and reference numbers for each publication arriving at the distribution centre, are inserted in the system as shown by the following.
[pic]
34 Administrative entities
Actually there are 266 defined administrative entities in GescomX (some examples in the window below).
[pic]
35 Example of an edition request:
[pic]
[pic]
1 Module C: Distribution actions management
37 Distribution Dossier
Creation of the distribution dossier
A distribution dossier is a computerised dossier which gathers the elements necessary for the constitution of the complete list of the recipients to which a publication has to be distributed as well as all information about the publication to be sent (See 1.4 Screen view “General Information” n° 1).
Additional information or changes can be implemented until its closure for execution. However thanks to a complementary function (RPDO), the dossier can be reopened but only on the day of the execution.
A dossier is made up of mailing lists and edition parameters of labels for each type of packing (machine/manual).
A dossier contains the following data:
• a heading including the creation date, the last update date and the name of the user having carried out the last update;
• a unique identifier automatically generated (7 digits);
• a state code which can take the following values:: ‘O’ = ‘ouvert’ (open), ‘F’ = ‘fermé’ (closed), ‘X’ = ‘exécuté’ (implemented), ‘S’ = ‘supprimé logiquement’ (deleted), ‘P’ = ‘pris en compte pour les frais’ (taken into account for expenses), ‘C’ = ‘pris en compte pour les envois initiaux’ (taken into account for initial consignments)) and ‘T’ = ‘terminé’ (finished);
• the date of a state change, updated at each stage of the dossier;
• a catalogue number identifying the publication to be distributed;
• the estimated delivery date as listed on the associated distribution list;
• the estimated delivery hour also listed on the distribution list (useful for the OJ);
• the total quantity expected at delivery also listed on the distribution list ;
• the list number in the header of the dossier;
• the weight of the publication to be distributed in grammes, obligatory for the execution of the dossier;
• the limiting weight accepted by the poste, set by default at 5 kg (allows definition of the transport method according to the total parcel weight);
• an area of 180 characters used by default for a free text article title. This title is copied to the monthly invoices;
• a number of copies by label, as 4 digits. It is defined by default as 9999 (value without effect) and makes it possible to define the number of copies of the publication to be distributed and to put in the same packaging (or same envelope);
• a maximum number of labels, as 2 digits. It is set to 99 by default (value without effect) and makes it possible to limit the number of labels generated for each consignment;
The edition parameters of a distribution dossier allow to define the type of paper and the format of label to be used for each listing of labels (machine and manual) (See 1.4 Screen view “Printing parameters” n° 2).
These parameters are composed of :
• the type of packing as 1 character (M=machine et D = ‘divers’/manual);
• sorting criteria for each type of packaging, with an associated code allowing a jump of page or a change of value of a criterion. The sorting criteria are those of the SETR table of the PARAMETRES dossier;
• the format of the label to be produced for each type of packaging, checked in the STQ table of PARAMETRES;
• the wording to be published on each label and each type of packaging;
• the type of paper to be used for printing the labels of each type of packaging, checked in the table 0050 of PARAMETRES;
• the title published at the beginning of the list for each type of packaging;
• the name of the printer to be used for each type of packaging, as entered in the table of PARAMETRES.
Creation of mailing lists
A mailing list is an element of a distribution dossier which gathers the consignments of one distribution requester (See 1.4 Screen view “Distribution” n° 3).
There are several types of lists :
• lists compiled from individual recipients identified by their registration number (See 1.4 Screen view “Details of an ad-hoc distribution list” n° 4)
• mailing lists used in their entirety
• mailing lists with addresses from existing lists selected by means of selection criteria (See 1.4 Screen view “Details of an ad-hoc distribution list” n° 5 and “Selection criteria’s Part 1 & Part 2” n° 6 & 7)
A mailing list is composed of :
• a heading including the creation date, the last update date and the name of the user having carried out the last update;
• an identifier composed of the number of the associated dossier (7 digits) and of the number of the list (2 digits);
• a state code which can take the value of: V = ‘feu vert’ green light for using the list in the distribution, R = ‘feu rouge’ red light (list can’t be used for distribution), A = ‘forcée en annulation’ forced cancellation, S = ‘supprimée logiquement’ suppressed logically;
• date of a state change
• a type A = individual recipients, B = selection, C = empty;
• an owner group limiting the management of the list to the users authorized to deal with this list;
• an object allowing to indicate the contents of the list (table S014 of PARAMETRES);
• a distribution requester/owner code (table S016 of PARAMETRES).
For the lists of the ‘selection’ type, the following data exists :
• a deduplication code for the chained addresses;
• a simple deduplication code;
• an effective date making it possible to limit the selection of the subscriptions to those active at that date;
• a notional quantity to be published on the label in the place of the selected subscription line;
• a selection of the mailing to be processed (maximum 30);
• a selection of mailings to be excluded (maximum 30);
• a selection of VLs (language versions) to be processed. This selection is initialised with the VL of the publication of the dossier. In all the cases the totality of the selected subscriptions will give rise to labels with the VL of the publication of the dossier;
• a selection of order codes to be treated ( maximum 10);
• a selection of order codes to be excluded ( maximum 10).
39 The distribution line
• A distribution line is an element of a mailing list of a distribution dossier which defines a consignment to a final recipient. It allows a trace of what is sent for the monthly statements and the detailed invoicing. It also makes it possible to store temporarily the recipients of a publication (individual recipients, subscribers list and lists of potential customers) (See 1.4 Screen view “Available information” n° 8).
A line is defined by :
• a line number composed of the distribution dossier number (7 digits) + the mailing list number from which it arises (2 digits) + a line number of 6 digits;
• a state code which can take the values ‘ ‘ for a line to be treated at the time of the execution of the dossier. ‘A’ for a line attached in a cancelled list, ‘S’ for a line attached in a logically suppressed list, ‘C’ for a line treated « initial consignments », ‘P’ for a line treated « costs » and ‘T’ for a finished line (can’t be treated anymore);
• a code “discount” making it possible to invoice the initial processing;
• type of packing (machine or manual) stored after the processing of the dossier;
• an order code defining the nature of the consignment;
• a quantity to be distributed;
• a transport method, specifying whether a consignment will leave by post or by carrier
• a distribution date stored at the time of the processing of the dossier if consignment is done by post, and at the time of the closure of the expedition form if the consignment is done by carrier;
• a number of avis d’expédition (DO-AVIS) generated at the time of the processing of the dossier if the consignment is done by carrier;
• a price if the consignment has been invoiced (postal or carrier expenses);
• a return code if parcel returns to sender
40 Screen views of the current application
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
41 Re invoicing Fee schedule
This fee scale is not exhaustive, costs for creation of e-mail addresses or orders input for example, might be added in the near future. Only charges under sections 1 and 4 are generated by SAGAPX.
Fee Schedule
(for information)
applicable on 1er January 2005 following the OPOCE Management Committee Decision
of 22 October 2004
|Designation |Calculation Unit |Unit price |
| | |(in €) |
|1. Basic Distribution | | |
|Labour & parts (DMA) : | | |
|1 copy per recipient |Per copy |0.05 |
|2 to 99 copies per recipient |Per copy |0.06 |
|100 to 1 000 copies per recipient |Per copy |0.02 |
|> 1 000 copies per recipient |Per copy |0.01 |
|2. Storage/clearance of stock | | |
|Storage : labour & space (SMA) |Per cubic metre per month |7.70 |
|3. Orders processing | | |
|Command line processing (CMA) |Per command line |0.50 |
|Labour & parts (CMA) : | | |
|1 copy per recipient |Per copy |0.15 |
|2 to 99 copies per recipient |Per copy |0.06 |
|100 to 1 000 copies per recipient |Per copy |0.02 |
|> 1 000 copies per recipient |Per copy |0.01 |
|4. Dossier Management | | |
|Inputting Address or Subscription (FSA) |Per Address or Subscription |1.10 |
Remarks :
1. The transport for initial distribution (DAC) and for delivery of orders (CAC) is invoiced at real cost, determined by weight. A precise proforma invoice is available on request.
2. The processing of “De Luxe packaging (EML)“ and “Kits assembling (EMK)“ are invoiced at real costs, calculated case by case.
3. The management and storage of subscriptions and addresses (FST) is now free of charge.
42 Example of a distribution price estimate
[pic]
[pic]
• 43 Example of the "Distribution dossiers follow up" table
[pic]
44 Distribution Procedure
This distribution process is as currently used in the Distribution Centre. It will be adapted according to the selected application. There are 10 people working directly and permanently within the framework of this process.
DISTRIBUTION DOSSIER
Procedure of work
Services Concerned: 1) Fulfilment/Infrastructures & Stocks/Reception & Warehouses
2) Fulfilment/Infrastructures & Stocks/Stocks & Inventories
3) Fulfilment/Infrastructures & Stocks/Equipments & Supplies
4) Fulfilment/Distribution/ Distribution Planning
5) Fulfilment/Distribution/Dossiers and Orders
6) Transfluvia
Contract concerned: 1869 – Handling
The distribution dossier is drawn up in SagapX Lot 2 and is made up physically of a pre-printed yellow dossier.
Circuit of the distribution dossier and principal tasks to carry out at each stage
NB. The language versions are distributed progressively with their reception
Yellow dossier
|Task |Support |Actor |
|Transmission of a copy of the edition request by the Planning team |Edition request |DP |
|If necessary, on the basis of information received in advance from the | | |
|author/requester and on the basis of the edition request, initialisation of|Form “Demand for |DP |
|the form “demand of tubes“ (annex 1), completed by Equipment & Supplies in |tubes“ | |
|Excel format and stored in the dossier. | | |
| | | |
| | | |
| | | |
| | | |
| | |E&S |
|If the necessary stock of tubes isn’t available, launching of an external |form “Demand for |E&S |
|order procedure |tubes“ | |
|If the stock is available, initialisation of a GescomX order, on which | | |
|title and distribution date are put in the “Address“ zone | | |
|At the reception of the tubes, preparation of the ordered articles in the |- |TF |
|physical zone “before distribution”, awaiting their specific use | | |
|At the receipt of the publications (normal deliveries, reprints and PAD), each |Green copy of |TF |
|publication has to be accompanied by a green copy of the reception bulletin and the |reception bulletin | |
|delivery form. |and delivery form | |
|If delivery incomplete : if the number of copies is less than expected, |mail with |R&E |
|insert the mail with the information in the yellow dossier. Indicate on the|information | |
|dossier that the delivery is incomplete. | | |
|If partial delivery : indicate it on the 1st yellow dossier. For the |- |TF |
|following partial deliveries of the same publication, the Transfluvia | |R&W |
|reception will not execute a ‘pre-picking’ and will transmit directly the | | |
|reception bulletin and the delivery form to R&W. A yellow dossier will be | | |
|initialised for each partial and incomplete delivery | | |
|If anomaly : in case of anomaly, (see procedure 5-Reception) inserts the |Anomaly report |R&W |
|anomaly report in the yellow dossier | | |
|Weighting and measuring of the publication (see Procedure 5-Reception) - Input into |- |R&W |
|GescomX the stock entries, the weights, measures and ventilation of the quantities by | | |
|owner . | | |
|Initialisation of the yellow dossier and indication of the date of entry of the |Yellow dossier |R&W |
|product, the title, the catalogue number, the management number and the weight for |(annex 2) | |
|each language version (LV). | | |
|NB. The OJ ‘competition’ in 3 LV is also initiated with the same yellow dossier as the| | |
|other publications. | | |
|Control of the publication in order to detect possible packaging characteristics – |Label |E&S |
|Affixing of a label on the green copy of the reception bulletin : Packaging control OK| | |
|or Consultation necessary before distribution according to the characteristics of | | |
|packaging of the product. | | |
|In case of Consultation necessary before distribution, indicate YES on the |Yellow dossier |E&S |
|label “Consultation necessary” of the distribution dossier. | | |
|If the choice of a source of supply is dictated by the rupture of that |Yellow dossier |E&S |
|stock normally to be used or if specific instruction was given (by the | | |
|requester for example), indicate it in the ‘remarks’ area of point 4.bis | | |
|“Equipments and supplies”. | | |
|In the event of use of a special routing sheet : |Yellow dossier |E&S |
|- if the sheet exists, insert it in the distribution dossier and specify | | |
|the catalogue number in the ‘remarks’ area |Routing sheet | |
|- otherwise, indicate on the yellow dossier (Remarks area) the later use of| | |
|a special routing sheet. E&S will inform the F&O team by mail of the |Mail | |
|availability of the routing sheet. | | |
|If partial deliveries (there are then several yellow dossiers) : insert in |Yellow dossiers |E&S |
|the 2nd yellow dossier and in the following a copy of the 1st yellow | | |
|dossier and a copy of the instructions of E&S from the 1st dossier. | | |
|Confirm the existance of the distribution plan (add it to the dossier) and check if |Distribution plan |DP |
|the quantities are sufficient for the distribution | | |
|In case of absence of a distribution plan or if insufficient quantities or |Mail |DP |
|if incomplete information, the distribution dossier will be blocked and the| | |
|author/requester is informed immediately. | | |
|If the author wishes, the planning team can help him to draw up the |Temporary |DP |
|distribution plan. This results in a temporary distribution form. |distribution form | |
| |If the “Demand of tubes” form is required, then add this form to the |Yellow dossier |DP |
| |distribution dossier if necessary | | |
|Transcription of the distribution plans in SagapX Lot 2 into the yellow dossier. |Yellow dossier |F&O |
|Preparation of the dossier with the computer dossiers and address lists; check the | | |
|printing quality of the lists and the labels (inking, positioning of the addresses, | | |
|etc). | | |
|Indicate on the yellow dossier the job numbers, the dossier numbers and the quantities| | |
|to be distributed. | | |
|The actual weight of each article is increased by 5 gr. to take account of the |Yellow dossier |F&O |
|packaging. | | |
|If the unit weight > 50 gr, the real weight is indicated |Yellow dossier |F&O |
|If less than 500 addresses, annex a paper listing (Davac or auto) with the |Paper listing |F&O |
|labels | | |
|If Multiple dossier : Indicate the multiple dossier number on the yellow |Yellow dossier |F&O |
|dossier and refer to point 4 hereafter, without omitting the 4th page of | | |
|the yellow dossier. | | |
|If mass distribution (several pallets), fix a colored sheet, format C5, |Information sheet |F&O |
|with following 3 sentences : | | |
|“Cette publication vous est gracieusement offerte par… DG ordonnateur” | | |
|“This is a complimentary copy, offered by…” | | |
|“Diese Veröffentlichung stellt Ihnen … Kostenlos zur Verfügung” | | |
|on each pallet with the agreement of the requester. | | |
|Label « Consultation necessary » on 1st page of distribution dossier = YES | | |
|Or | | |
|Multiple Dossier | | |
|Or | | |
|Complementary distribution (point 5 for quantities in stock) | | |
|contact E&S and the TF coordinator for a common decision on the |- |F&O |
|packaging according to the distribution plan known at that moment and| | |
|according to the type of machine to be used | | |
|fill out the “packaging” section on page 4 of the yellow dossier if |Yellow dossier |E&S |
|necessary | | |
|indicate the instructions of E&S and the TF coordinator (and possibly|Yellow dossier |E&S |
|of a person responsible for the technical part of TF) in the remarks | |TF |
|area on the 1st page of the distribution dossier (packaging and type | |F&O |
|of machine to be used). If the choice of a supply has been dictated | | |
|by a stock rupture of that stock normally to be used or if a specific| | |
|instruction was given (by the requester for example), indicate it in | | |
|the ‘remarks’ area of point 4.bis “Equipments and supplies”. | | |
|fill out part 4 bis of the yellow dossier at page 4 |Yellow dossier |E&S |
|Indicate the distribution instructions (as detailed as possible) in the Remarks area |Yellow dossier |F&O |
|of the 1st page of the yellow dossier. | | |
|Put all the mails which do not concern Transfluvia (email exchanges and others) in a |Yellow dossier |F&O |
|plastic pocket and keep it in the yellow dossier. | | |
|A double control is carried out by a different person of the team : reading and |Yellow dossier |F&O |
|comprehension of the various plans and distribution forms, verification of the whole | | |
|dossier (catalogue number, stock owner, product, requester, mailings to be treated, | | |
|VLs, selections, and more if necessary). Then validation on the yellow dossier under | | |
|point 4 « remarks » with the valuators name. | | |
|The execution of the distribution closes the dossier in SagapX Lot 2; the status |Displacement |F&O |
|changes into X-executed and the “avis d’expédition” are generated. |bulletin | |
|The ”avis d'expédition” > 5 kg are put inside the yellow dossier. |“Avis d'expédition” |F&O |
|The exact quantities to be distributed were placed in the GEXPE zone by Reception; the|Displacement |F&O |
|remaining quantities are put in the GQA00 zone (“ buffer zone”) and the displacement |bulletin | |
|bulletin for this quantity is placed in the distribution dossier. | | |
|Transmission of the dossier to the contractor Transfluvia : |Yellow dossier |F&O |
|- if simple dossiers, put the dossiers on the table in the corridor |Yellow dossier |F&O |
|- if complex, priority dossiers, call the TF coordinator (and not the team |Yellow dossier |F&O |
|leader) to explain orally the work to be carried out and this before 16h30.| | |
|The explanation is also written in the Remarks area. | | |
|Execution of the requested distribution |- |TF |
|The counting of the products to be distributed is carried out on the quantity to be |- |TF |
|distributed and not on the quantity to be stored after the distribution. | | |
|To inform R&W if the weight of the product is different from the announced |- |TF |
|weight | | |
|If the real weight is < 5 kg, the « avis d’expédition » has to go back the |“Avis d'expédition” |TF |
|Transport team with indication of the real weight and transport mode, and a| | |
|copy to the Reception team. | | |
|When a problem occurs, fill out the packaging « Remarks » zone TF on the |Yellow dossier |TF |
|4th page of the distribution dossier. | | |
|Indicate the quantity really put in stock and the final warehouse zone. The bulletin |Displacement |TF |
|is send to S&I separately from the yellow dossier. |bulletin | |
|All the finished dossiers are deposited at Distribution Planning in the tray “Sortie |Yellow dossier |TF |
|de stock”. | | |
|The temporary distribution forms for the temporary mailings are handed over to the |Temporary |DP |
|Mailing Management team who will delete these mailings. |distribution form | |
|Inform the requester regarding the end of the distribution. | Mail |DP |
|If requester asks to receive all the stock after distribution, ask him |Mail |DP |
|whether it’s really necessary because the Opoce can ensure the storage and | | |
|orders through GescomX. | | |
|Immediate transfer of the dossiers to the F&O team via the tray “Dossiers après |Yellow dossier |DP |
|distribution Transfluvia”. | | |
|Manual global stock exit from GEXPE only to SagapX Lot 2 (for each dossier number), |SagapX Lot 2 |F&O |
|including the stock exits for the OJ every morning at 8h00 ([12]). | | |
|Check if the 2 numbers are equal (qty in GEXPE and qty distributed). | | |
|If the 2 numbers are (, execute a manual stock transfer for the difference |GescomX |F&O |
|in GescomX | | |
|Classification of the paper dossier |Yellow dossier |F&O |
Documents to attach to the distribution dossier
Annexed documents necessary for the physical execution of the distribution
- The article to be distributed
- Special routing sheet if necessary
- “Demand of tubes” form if necessary
- Displacement bulletin if it exists
- Copy of the reception bulletin
- “Avis d'expédition”, labels, statistics
Documents belonging to the dossier
Documents such as mails, notes or various annotations unnecessary for the distribution as such are gathered in a transparent small pocket placed inside the yellow dossier.
Distribution list
The list is drawn up at the end of the day by the F&O team and is transmitted on paper to the Transfluvia coordinator, and by mail to a list of recipients.
At the end of a shift, the following day Transfluvia transmits to the F&O team, the distribution list with the accomplished distributions.
Distribution of several articles simultaneously (Multiple Distribution Dossier)
green dossier
NB. Reminder : the VLs are distributed progressively with their reception
At the time of the reception, the ‘multiple’ concept is not yet known. This is why each received article is placed in a separate yellow dossier.
The DP team or F&O opens one or more green dossiers in which will be placed the yellow dossiers of the articles to be distributed together; the list of the catalogue numbers of the articles to be distributed together is indicated on the 1st page of the green dossier.
In SagapX Lot 2, the F&O team treats the dossier of the 1st catalogue number on the list to be distributed and adds the weight of the following articles to it.
1. If the delivery of the various VLs is spread out, the team opens several green dossiers (one for each distribution, with one or more VLs according to the availability).
If one VL is treated, the team treats in SagapX Lot 2 the dossier of the relevant VL. The SagapX number of the dossier is indicated in the dossier number area of the green dossier.
If several VLs are treated, each dossier of each VL has a SagapX number. One indicates the 1st number in the dossier number area of the green dossier.
2. If all the VLs are available, only one green dossier is opened. The team deals with the dossiers of all the VLs in SagapX Lot 2; each dossier of each VL has a number. One indicates the 1st number in the dossier number area of the green dossier.
N.B.. The distribution of an article accompanied by a letter is not a multiple dossier but a normal dossier.
|Task |Support |Actor |
|Creation of the multiple distribution dossier |Green dossier |DP or F&O |
|Indicate the multiple distribution dossier number: SagapX Lot 2 dossier |Green dossier |F&O |
|number of the first LV to be distributed. |(annex 3) | |
|Only one distribution dossier is created in SagapX Lot 2 with the real | | |
|total weight of all the articles to be distributed, and an explanatory | | |
|comment in the SagapX dossier and on the exit moves in GescomX (where the | | |
|number of the multiple dossier is indicated), and this for each | | |
|publication. | | |
|Insert an example of each publication to be distributed in the green |Green dossier |F&O |
|dossier for multiple distribution. | | |
|Indicate a comment in the Remarks area. | | |
|In any case consult E&F for technical advice before any multiple distribution. |Green dossier |F&O |
|The advice will be indicated in the remarks area on the first page below |Green dossier |E&S |
|the catalogue numbers composing the multiple distribution. | | |
|Classification of the green dossier with the yellow paper dossiers . |Yellow dossier |F&O |
Complementary Distribution
It can happen that a second distribution of a publication has to be made after the first which is already closed. The publication is then already in LVBBB or GL zone.
For each complementary distribution, the F&O team checks if the requested quantity is available for the appropriate stock owner and in the requested LV.
If the quantity is not sufficient, a dossier analysis is made:
• if the quantities are available at Gasperich, the F&O team makes a “displacement bulletin for distribution” by language, indicating the quantities to be brought out from the indicated location and puts the quantities in the GEXPE zone.
• If the desired quantities are not available at Gasperich, the team indicates on the ‘repatriation’ bulletin the exact number necessary to repatriate from the LVBB zone, the stock owner by LV and the distribution dossier number.
The “repatriation bulletin for distribution” is send by mail to the Stocks & Inventories team.
They enter details of the picking and displacement zones and send back the form by mail to the F&O team for insertion in the distribution dossier.
First delivery of a publication without distribution
Within the framework of a first delivery of a publication for which the requester decided not to make any distribution, the F&O team draws up an electronical distribution dossier in SagapX Lot 2 with the obligatory lists, i.e. :
- the list of the justifying copies,
- the two lists for the libraries (Luxembourg and Brussels).
Official Journal
At the F&O team:
1. daily OJ : it’s the « cahier de bord » which acts as yellow dossier of distribution dossier. This « cahier de bord » circulates between the Distribution/F&O team and Transfluvia. The « cahier de bord » is initiated by the Distribution/F&O team the day before delivery of the OJ.
The distribution of the OJs is based on the permanent distribution form (initiated once a year by the Subscriptions team of the Distribution unit). It should be noted that the Maltese language is regarded as the Gaelic language in the JOGAMT mailing (free subscriptions in GA and MT).
2. OJ Competition in 3 VLs : a distribution dossier with yellow dossier is used for the treatment in SagapX Lot 2 only.
Special instructions for this OJ :
- the OJ routing sheets are not used
- consignments in PP are done under the OP 2205 contract
- the “cahier de bord” shows that the distribution is made during the day.
3. OJ Competition in 19 VLs : the distribution is done in 2 phases: the subscriptions are treated with the “cahier de bord”; a complementary distribution is made with a yellow dossier for the specific EPSO mailing (mailing ‘JO CONC’).
This OJ is distributed with the daily OJ L. Another part is treated in SagapX Lot 2 for the specific competition mailings.
4. Weights of the Competition OJs : As the weight of the Competition OJs isn’t known at the moment of the compiling of the distribution dossier, the average weight below will be used for input in GescomX and treatment in SagapX Lot 2 :
- Cover : 12 gr,
- Grey OJ paper : 3 gr per sheet,
- Divider sheet : 5 gr per sheet.
It is a requirement that the indicated number of pages on the delivery form communicated by the OJ unit be divided by 2., to convert it to sheets for this calculation.
ANNEX C.1’ Demand for tube’ form
ANNEX C.2 Distribution Dossier
ANNEX C.3 – Multiple distribution dossier
[pic]
[pic]
[pic]
ANNEX C.4 – Non permanent distribution form
[pic]
Annex C.5 - Distribution Procedure Scheme
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
1 Module D : Sorting & Routing management
45 Packing modes
Mechanical packing
The Centre has three ‘SITMA’ automated packing line machines. The Sitma machine is able to sort publications by country post code and shipment mode. Up to 7 different publications can be regrouped in one parcel. The maximum thickness handled is 6 cm. The machine has a maximum rate of 12 000 parcels per hour.
[pic]
The addresses are printed directly on the routing sheets. The routing sheet is considered as one of the 7 different publications.
[pic]
At the end of the assembling and address printing, the publications are wrapped in a recyclable polyethylene film.
Manual packing
Multiple-content parcels are handled manually. The selected packaging depends on the weight of the parcel and on the shipment mode.
[pic]
46 Sorting signals
[pic]
[pic]
[pic]
47 Printers
Types of printers
The specific printers are put at the disposition of DIFFUS by INFRA and are installed in different offices of the Distribution Centre of Gasperich. They are connected directly to the network for some people and to PCs as bridges for others.
This equipment supports an industrial working environment (variations in temperature, humidity and dust) and an intensive use.
Types of printers:
• 380 mm listing printers (currently 5 including 1 at high speed) for Blanco paper or sticker labels of the type ‘3 across’
• 240 mm listing printers (currently 3) for NCR forms 4 to 5 copies
• Printers for label stickers (currently 3) continuous ‘1 across’ 107 x 49 mm
This list is non exhaustive and can be amended according to later requirements.
[pic]
Label file structure
[pic]
Routing sheet
[pic]
1 Module E : Transport management
48 Delivery type modes
Parcel > 5 kg :
N Navette
CE Courrier express (Délégations, via DHL)
D Distribution interne
U Urgent
UE Urgent Express
Y Via Délégation
W (sans calcul de frais)
Parcel < 5 kg :
BV Bureau deVente
I Poste
N Navette
D Distribution interne
U Urgent
UE Urgent Express
49 Dispatch notice sample
[pic]
50 Delivery slip sample
[pic]
1 Module F : Re-invoicing to authors management
Re-invoicing report sample :
[pic]
[pic]
2 Module G : Subscriptions Invoicing
This screen abstract shows the last invoice number encoded in a subscription record.
MAILING : O/VZI004 ( / ) RECUEIL DE LA JURISPRUDENCE DE LA CDJ - ANNEE 20
MATRICULE: O/06672566 NOM: VANDERSANDEN, GEORGES ABONNES: 1067
ORDRE DEP ------------ FACTURATION --------
VL QTE EXP REM DEBUT FIN FIN ANNEE ADRESSE DERN NUM SELEC
FR 1 D I 13 S 01/01/04 31/12/04 31/12/04 4 2005000310 COP04
Tables
THE MOST USUAL TABLES ARE LISTED BELOW, CODES IN BOLD ARE THE MOST COMMONLY USED.
51 VL Codes and Country Codes
|VL |Country Name |Country |
|ISO 639 Code | |ISO 3166 Code |
|DE |ALLEMAGNE |DE |
|DE |AUTRICHE |AT |
|GR[13] |CYPRE |CY |
|DA |DANEMARK |DK |
|ES |ESPAGNE |ES |
|ET |ESTONIE |EE |
|FI |FINLANDE |FI |
|FR |FRANCE |FR |
|EN |GRANDE-BRET. |GB |
|GR[14] |GRECE |GR |
|HU |HONGRIE |HU |
|EN |Irlande |IE |
|IT |ITALIE |IT |
|LV |LETTONIE |LV |
|LT |LITUANIE |LT |
|- |LUXEMBOURG |LU |
|MT |MALTE |MT |
|NL |PAYS-BAS |NL |
|PL |POLOGNE |PL |
|PT |PORTUGAL |PT |
|SK |SLOVAQUIE |SK |
|SL |SLOVENIE |SI |
|SV |SUEDE |SE |
|CS |REP. TCHEQUE |CZ |
|TR |TURQUIE |TR |
52 Function codes
|Code |Description |
|A |JOURNALISTE |
|AA |JOURNALISTE ACCREDITE AUPRES DES CE |
|A1 |JOURNALISTE SCIENTIFIQUE |
|B |ENSEIGNANT |
|C |SCIENTIFIQUE, CHERCHEUR, INGENIEUR, TECHNICIEN |
|D |CADRE SUPERIEUR |
|E |EMPLOYE, SALARIE |
|F |INDUSTRIEL, DIRIGEANT D'ENTREPRISE |
|G |INDEPENDANT |
|GA |INDEPENDANT DANS L'AGRICULTURE |
|GB |INDEPENDANT DANS L'ARTISANAT |
|GC |INDEPENDANT DANS LE COMMERCE |
|GD |EXPERT COMPTABLE |
|GE |CONSULTANT/EXPERT |
|GZ |INDEPENDANT DANS D'AUTRES DOMAINES |
|H |PROFESSION LIBERALE |
|HA |AVOCAT |
|HB |MEDECIN |
|HC |ARCHITECTE |
|HD |EXPERT COMPTABLE |
|HZ |AUTRE PROFESSION LIBERALE |
|I |?????? |
|J |SYNDICALISTE |
|K |CADRE OU REPRESENTANT D'UNE ORGANISAT.NON COMMERC. |
|L |REPRESENTANT D'UN PAYS ETRANGER, DIPLOMATE |
|M |MAGISTRAT, MEMBRE DE L'APPAREIL JUDICIAIRE |
|N |POLITICIEN |
|O |FONCTIONNAIRE CCE |
|P |ETUDIANT, ELEVE |
|Q |APPRENTI |
|R |ARTISTE |
|S |MENAGERE |
|T |RETRAITE |
|TCE |RETRAITE CE |
|U |MILITAIRE |
|V |RELIGIEUX(SE) |
|Z |AUTRES ACTIVITES |
|ZA |CADRE SUPERIEUR DE LA FONDATION EUROPEENNE DUBLIN |
53 Theme codes
|Code |Description |
|01 |QUESTIONS INSTITUTIONNELLES |
|02 |UNION DOUANIERE ET POLITIQUE COMMERCIALE |
|03 |AGRICULTURE, SYLVICULTURE, PECHE |
|04 |EMPLOI ET TRAVAIL |
|0410 |POLITIQUE DE L'EMPLOI |
|0420 |MARCHE DU TRAVAIL ET LIBRE CIRCULATION DES TRAVAILLEURS |
|0430 |FORMATION PROFESSIONNELLE |
|0440 |CONDITIONS DE TRAVAIL, SANTE ET SECURITE |
|05 |QUESTIONS SOCIALES |
|0510 |POLITIQUE SOCIALE |
|0520 |POLITIQUE ET SANTE |
|0530 |PROTECTION DE LA SANTE |
|0540 |FONDS SOCIAL EUROPEEN |
|06 |DROIT ET QUESTIONS JURIDIQUES |
|07 |TRANSPORTS |
|08 |CONCURRENCE ET ENTREPRISES |
|09 |FINANCES |
|0910 |POLITIQUE MONETAIRE ET SME |
|0920 |INTEGRATION FINANCIERE ET LIBRE CIRCULTATION DES CAPITAUX |
|0930 |FISCALITE |
|10 |QUESTIONS ECONOMIQUES CONSOMMATION |
|1010 |POLITIQUE ECONOMIQUE |
|1020 |MARCHE INTERIEUR (ACHEVEMENT) |
|1030 |POLITIQUE INDUSTRIELLE |
|1040 |SECTEUR TERTIAIRE |
|1041 |BANQUES ET ASSURANCE |
|1042 |LIBERTE D'ETABLISSEMENT ET DE PRESTATION DE SERVICES |
|1050 |CONSOMMATEURS ET CONSOMMATION |
|12 |ENERGIE |
|13 |POLITIQUE |
|14 |ENVIRONNEMENT |
|1410 |POLITIQUE ET PROTECTION DE L'ENVIRONNEMENT |
|1420 |DETERIORATION DE L'ENVIRONNEMENT |
|15 |RECHERCHE SCIENTIFIQUE ET TECHNIQUE |
|1510 |POLITIQUE DE RECHERCHE |
|1520 |ENERGIE |
|1521 |SCIENCE NUCLEAIRE ET RADIOPROTECTION |
|1530 |CHIMIE, SCIENCES PHYSIQUES ET PROCEDES INDUSTRIELS |
|1540 |MEDECINE ET SCIENCES BIOLOGIQUES |
|1550 |AGRONOMIE ET TECHNOLOGIE ALIMENTAIRE |
|1560 |TECHNOLOGIE DE L'INFORMATION ET TELECOMMUNICATIONS |
|1570 |RECHERCHE SPATIALE |
|1580 |AUTRES SECTEURS |
|16 |INFORMATION, EDUCATION, CULTURE |
|17 |STATISTIQUES |
|1710 |STATISTIQUES GENERALES |
|1720 |ECONOMIE ET FINANCES |
|1730 |POPULATION ET CONDITIONS SOCIALES |
|1740 |ENERGIE ET INDUSTRIE |
|1750 |AGRICULTURE, SYLVICULTURE ET PECHE |
|1760 |COMMERCE EXTERIEUR |
|1770 |SERVICES ET TRANSPORTS |
|1780 |ENVIRONNEMENT |
|1790 |AUTRES |
|D0005 |GENERAL INFORMATION ABOUT THE FOUNDATION'S ACTIVITIES |
|D0445 |HEALTH AND SAFETY |
|D0455 |WORK ORGANISATION AND LABOUR RELATIONS |
|D0555 |SOCIAL COHESION/EQUAL OPPORTUNITIES |
|D1425 |SOCIO-ECONOMIC ASPECTS OF THE ENVIRONMENT |
|D1435 |URBAN ENVIRONMENT |
|D1445 |WORKPLACE AND THE ENVIRONMENT |
|D1455 |ENVIRONMENTAL MANAGEMENT TRAINING |
|D1465 |HAZARDOUS WASTES MANAGEMENT |
|D4451 |HEALTH AND SAFETY AT THE WORKPLACE |
|D4452 |SYSTEMS OF MONITORING WORKING CONDITIONS |
|D4453 |OCCUPATIONAL HEALTH STRATEGIES IN EUROPE |
|D4454 |STRESS AT THE WORKPLACE |
|D4551 |UNEMPLOYMENT |
|D4552 |SHIFTWORK |
|D4553 |NEW FORMS OF WORK |
|D4554 |PARTICIPATION AT THE WORKPLACE |
|D4555 |INDUSTRIAL RELATIONS |
|D4556 |ECOLOGY AT WORK |
|D5551 |PUBLIC SERVICES |
|D5552 |THE ELDERLY |
|D5553 |RURAL AREAS |
|D5554 |WOMEN'S ISSUES |
|D5555 |VULNERABLE GROUP/MINORITIES |
|D5556 |MIGRATION |
| | |
|T0430 |FORMATION PROFESSIONNELLE (thème général) |
|T4331 |PROMOTION DES COMPETENCES |
|T4332 |QUALIFICATION ET MARCHE DU TRAVAIL |
|T4333 |FORMATION CONT. ET EDUCATION ET FORM. TOUT AU LONG..... |
|T4334 |QUALITE DE LA F.P., EVALUATION ET CERTIF. D. COMP. |
|T4335 |FORMATION DES FORMATEURS |
|T4336 |SYSTEMES DE F.P., DONNEES-CLEFS ET STATISTIQUES |
|T4337 |COUTS ET FINANCEMENT |
|T4338 |RECHERCHE ET DEVELOPPEMENT EN MATIERE DE F.P. |
|T4339 |PROGRAMME DE VISITES D'ETUDE POUR SPECIALISTES DE F.P. |
|T4340 |PARTENAIRES (SOCIAUX) DANS LA POLITIQUE DE F.P. |
54 Requester codes / Administrative Entity Codes
|Code |Description |
|02A |COMMISSION - DG 02 |
|03A |COMMISSION - DG 03 |
|04A |COMMISSION - DG 04 |
|05A |COMMISSION - DG 05 |
|06A |COMMISSION - DG 06 |
|06P |DG AGRICULTURE-PROGRAM LEADER PLUS |
|07A |COMMISSION - DG 07 |
|08A |COMMISSION - DG 08 |
|09A |COMMISSION - DG 09 |
|09B |COMMISSION - DG 09 - BRUXELLES |
|09L |COMMISSION - DG 09 - LUXEMBOURG |
|10A |COMMISSION - DG 10 |
|10B |REPRESENTATION EN Belgique |
|10C |COMMISSION - DG 10 - CDE/DEP |
|10D |REPRESENTATION EN ALLEMAGNE |
|10F |REPRESENTATION EN FRANCE - |
|10G |REPRESENTATION EN GRECE |
|10I |REPRESENTATION EN IRLANDE - |
|10K |REPRESENTATION AU DANEMARK - |
|10L |REPRESENTATION AU LUXEMBOURG - |
|10M |REPRESENTATION EN ESPAGNE - |
|10N |REPRESENTATION AUX PAYS BAS - |
|10P |COMMISSION - DG 10 - PROGRAMME PRIORITAIRE |
|10R |COMMISSION - DG 10 - CARREFOURS RURAUX |
|10T |COMMISSION - DG 10 - TF ACTIONS PRIORITAIRES |
|10U |REPRESENTATION AU ROYAUME UNI - |
|10X |CITIZENS FIRST - DG XV |
|10Z |EURO - DG X |
|11A |COMMISSION - DG 11 |
|12A |COMMISSION - DG 12 |
|12G |COMMISSION - DG 12/CCR - GEEL |
|12I |COMMISSION - DG 12/CCR - ISPRA |
|12K |COMMISSION - DG 12/CCR - KARLSRUHE |
|12P |COMMISSION - DG 12/CCR - PETTEN |
|13A |COMMISSION - DG 13 |
|13B |COMMISSION - DG 13 - BRUXELLES |
|13L |COMMISSION - DG 13 - LUXEMBOURG |
|14A |COMMISSION - DG 14 |
|15A |COMMISSION - DG 15 |
|16A |COMMISSION - DG 16 |
|17A |COMMISSION - DG 17 |
|18A |COMMISSION - DG 18 |
|19A |COMMISSION - DG 19 |
|20A |COMMISSION - DG 20 |
|21A |COMMISSION - DG 21 |
|22A |COMMISSION - DG 22 |
|23A |COMMISSION - DG 23 |
|23E |COMMISSION - DG 23 EIC |
|24A |DG XXIV POLITIQUE DES CONSOMMATEURS |
|31A |COMMISSION - SECRETARIAT GENERAL |
|32A |COMMISSION - SERVICE JURIDIQUE |
|33A |COMMISSION - PORTE-PAROLE |
|34A |COMMISSION - OFFICE STATISTIQUE |
|35A |AGENCE DE L'APPROVISIONNEMENT DE L'EURATOM |
|47A |DG TRADUCTION |
|51A |COMMISSION - OFFICE HUMANITAIRE DE LA CE |
|A00 |EUR-OP |
|A4A |EUR-OP, OP4, UNITE VENTE |
|A4P |EUR-OP, OP4 - PROMOTION |
|A4R |EUR-OP, OP4 - RESEAUX |
|A4V |EUR-OP, OP4 - VENTE |
|A6D |EUR-OP, OP6-DIFFUSION |
|ACO |CORDIS (OPOCE) |
|ACP |ACP - EU COURRIER DG DEV |
|AID |AIDCO-EUROPAID OFFICE DE COOPERATION |
|BEI |BANQUE EUROPEENNE D'INVESTISSEMENT |
|CC0 |COUR DES COMPTES |
|CDF |CEDEFOP |
|CES |COMITE ECONOMIQUE ET SOCIAL EUROPEEN |
|CJ0 |COUR DE JUSTICE |
|CJ1 |COUR DE JUSTICE (ACTIVITES DE LA COUR) |
|CL0 |CONSEIL |
|COS |COST |
|CPD |CONTROLEUR EUROPEEN DE LA PROTECTION DES DONNEES |
|CR0 |COMITE DES REGIONS |
|CSU |CENTRE SATELLITAIRE DE L'UE |
|CTO |CENTRE DE TRADUCTION DES ORGANES DE L'U.E. |
|CVE |LA CONVENTION EUROPEENNE |
|EAS |EUROPEAN AGENCY FOR SAFETY AND HEALTH AT WORK |
|EEA |AGENCE EUROPEENNE POUR L'ENVIRONNEMENT |
|EEB |ECOLE EUROPEENNE - BRUXELLES |
|EEL |ECOLE EUROPEENNE, LUX |
|EFD |FONDATION EUROPEENNE |
|EFS |EFSA - AUTORITE EUROPEENNE DE SECURITE DES ALIMENTS |
|EJU |EUROJUST |
|EMA |AGENCE EUROPEENNE DE L'EVALUATION DES MEDICAMENTS |
|EMI |BANQUE CENTRALE EUROPEENNE |
|EPS |OFFICE EUROPEEN DE SELECTION DU PERSONNEL |
|ETF |EUROPEAN TRAINING FOUNDATION |
|HA0 |OFFICE DE L'HARMONISATION |
|IES |INSTITUT D'ETUDES DE SECURITE DE L'UE |
|IUE |UNIVERSITE DE FLORENCE |
|MED |MEDIATEUR EUROPEEN |
|NA |PRESS - SERVICE PRESSE ET COMMUNICATION |
|NB |ENTR - DG ENTREPRISES |
|NC |EAC - DG EDUCATION ET CULTURE |
|ND |SANCO - DG SANTE ET PROTECTION DES CONSOMMATEURS |
|NE |JAI - DG JUSTICE ET AFFAIRES INTERIEURES |
|NF |RELEX - DG RELATIONS EXTERIEURES |
|NG |TRADE - DG COMMERCE |
|NH |DEV - DG DEVELOPPEMENT |
|NI |ELARG - DG ELARGISSEMENT |
|OCV |OFFICE COMMUNTAUTAIRE DES VARIETES VEGETALES |
|OED |OBSERVATOIRE EUROPEEN DES DROGUES ET TOXICOMANIES |
|OIB |OFFICE INFRASTRUCTURES ET LOGISTIQUE-BRUXELLES |
|OIL |OFFICE INFRASTRUCTURES ET LOGISTIQUE-LUXEMBOURG |
|OLA |OLAF |
|ORX |OBSERV.PHENOM RACISTES XENOPHOBES |
|P3D |PARLEMENT EUROPEEN-DG3-DEBATS SUR L'EUROPE |
|POL |EUROPOL |
|TRN |DG TRANSPORT - ENERGIE |
|XPA |COMMISSION - DG X - DIRECTION A |
|XPB |COMMISSION - DG X - DIRECTION B |
|XPC |COMMISSION - DG X - DIRECTION C |
|XPD |COMMISSION - DG X - DIRECTION D |
|XPE |REPRESENTATION EN ESTONIE |
|XPG |CONTRUISONS L'EUROPE ENSEMBLE |
|XPH |REPRESENTATION EN HONGRIE |
|XPI |REPRESENTATION A MALTE |
|XPL |REPRESENTATION EN LITUANIE |
|XPM |REPRESENTATION A CHYPRE |
|XPN |REPRESENTATION EN ITALIE - |
|XPP |REPRESENTATION EN POLOGNE |
|XPQ |REPRESENTATION EN SLOVAQUIE |
|XPS |REPRESENTATION EN SLOVENIE |
|XPT |REPRESENTATION EN LETTONIE |
|XPR |REPRESENTATION EN REP. THCEQUE |
|XPU |REPRESENTATION EN AUTRICHE- |
|XPV |REPRESENTATION EN SUEDE |
|XPW |REPRESENTATION EN FINLANDE |
|XPX |REPRESENTATION AU PORTUGAL |
55 Organization Codes
|Code |Description |
|A |LA PRESSE |
|AA |PRESSE ECRITE |
|AA1 |QUOTIDIEN |
|AA2 |HEBDOMADAIRE |
|AA3 |PRESSE SPECIALISEE |
|AA31 |PRESSE SCIENTIFIQUE |
|AA32 |PRESSE ENVIRONNEMENT ET CONSOMMATEUR |
|AA33 |PRESSE DROIT |
|AA34 |PRESSE AGRICOLE |
|AA35 |PRESSE SOCIALE |
|AA36 |PRESSE UNIVERSITAIRE |
|AA4 |PRESSE D'ENTREPRISE |
|AA5 |PRESSE SYNDICALE |
|AA9 |AUTRE ORGANE DE PRESSE |
|AB |RADIO-TELEVISION |
|AB1 |RADIO |
|AB2 |TELEVISION |
|AB3 |ENVIRONNEMENT ET CONSOMMATEURS |
|AB4 |DROIT |
|AB5 |AGRICULTURE |
|AB6 |AFFAIRES SOCIALES |
|AB7 |UNIVERSITAIRES |
|AB8 |CODE POUR CEDEFOP |
|AC |PUBLICITE |
|AD |AGENCE DE PRESSE |
|AE |ORGANISATION DE JOURNALISTES |
|AF |PRESSE ACCREDITEE CE |
|AG |PRESSE INTERNATIONALE |
|AH |PRESSE NATIONALE |
|AI |PRESSE REGIONALE |
|AJ |PRESSE SPECIALISEE AUTORITES REGIONALES |
|B |LE LIVRE |
|BA |MAISON D'EDITION |
|BB |LIBRAIRIE |
|BC |BUREAU DE VENTE |
|C |BIBLIOTHEQUE-CENTRE DE DOCUMENTATION |
|CA |BIBLIOTHEQUE DE CULTURE GENERALE |
|CB |BIBLIOTHEQUE SCIENTIFIQUE ET TECHNIQUE |
|CC |CENTRE DE DOCUMENTATION |
|CD |DEPOSITAIRES (DEP) |
|CE |CENTRE DE DOC EUROP (CDE) |
|CF |CENTRE DE REFERENCES EUROPEENNES |
|CG |EURO INFO CENRE |
|CH |BUSINESS COOPERATION-NETWORK |
|CI |BUSINESS INNOVATION CENTER |
|D |CULTURE-LOISIR-SPORT |
|DA |MUSEE |
|DB |THEATRE, FILM, VIDEO |
|DB1 |THEATRE |
|DB2 |FILM |
|DB3 |VIDEO |
|DC |ANIMATION ARTISTIQUE |
|DD |SPORT |
|E |ENSEIGNEMENT |
|EA |UNIVERSITES. ENSEIGNEMENT SUPERIEUR |
|EB |ENSEIGNEMENT TECHNIQUE |
|EC |ENSEIGNEMENT GENERAL SECONDAIRE |
|ED |ENSEIGNEMENT PRIMAIRE |
|EE |FORMATION DES ADULTES, EDUCATION PERMANENTE |
|EF |CENTRE D'ETUDE |
|EX |ENSEIGNANTS |
|EY |EDUCATION SPECIALISEE |
|EZ |AUTRE TYPE D'ENSEIGNEMENTS |
|F |ORGANE CONSTITUE DE L'ETAT |
|FA |ASSEMBLEE PARLEMENTAIRE |
|FB |APPAREIL JUDICIAIRE |
|FC |GOUVERNEMENT, MINISTERE, ADMINISTRATION CENTRALE |
|FC1 |MINISTERE AFFAIRES ETRANGERES |
|FC2 |DIRECTION GENERALE POLITIQUE REGIONALE |
|FC3 |ELUS NATIONAUX |
|FD |ADMINISTRATION REGIONALE, CORPS ELU REGIONAL |
|FD1 |BUREAU DE REGION |
|FD2 |ORGANISATION REGIONALE ET SOUS REGIONALE |
|FE |ADMINISTRATION LOCALE, CORPS ELU LOCAL |
|FF |CORPS DIPLOMATIQUE |
|FF1 |AMBASSADES |
|FG |FORCES ARMEES |
|FH |DOUANES |
|FI |OFFICES STATISTIQUES |
|FZ |AUTRES OU PARAPUBLIQUES |
|G |PARTI POLITIQUE, MOUVEMENT POLITIQUE |
|H |ORGANES DES COMMUNAUTES EUROPEENNES |
|HA |PARLEMENT EUROPEEN |
|HA1 |PARLEMENTAIRES |
|HA11 |PE (COMMISSION POLITIQUE REGIONALE) |
|HA7 |P.E. - GROUPE POLITIQUE - AFFAIRES SOCIALES |
|HB |CONSEIL DES MINISTRES DE CE |
|HC |COMMISSION DES CE |
|HCAA |AGENCE D'APPROVISIONNEMENT D'EURATOM |
|HCBS |BUREAU DE SECURITE |
|HCCA |CABINETS |
|HCCF |COMITE DEFER (DGXVI) |
|HCCP |CELLULE DE PROSPECTIVE |
|HCCR |CENTRE COMMUN DE RECHERCHE |
|HCCS |COMITE SPATIAL (DGXVI) |
|HCDI |DIRECTION INFORMATIQUE - DELEGATION DGI |
|HCD1 |DELEGATION AUX PAYS TIERS |
|HCD2 |DELEGATION AUPRES DES ORGAN. INTERNATIONALES |
|HCD8 |DELEGATIONS DG VIII |
|HCEL |TASK-FORCE ELARGISSEMENT |
|HCIC |SERVICE COMMUN INTERPRETATION-CONFERENCES |
|HCIG |INSPECTION GENERALE DES SERVICES |
|HCOH |OFFICE HUMANITAIRE DE LA CE |
|HCOP |OFFICE DES PUBLICATIONS OFFICIELLES DES CE |
|HCOS |OFFICE STATISTIQUE |
|HCPC |SERVICE POLITIQUE DES CONSOMMATEURS |
|HCPI |BUREAU DE PRESSE ET D'INFORMATION |
|HCPP |SERVICE DU PORTE-PAROLE |
|HCSG |SECRETARIAT GENERAL DE LA COMMISSION |
|HCSJ |SERVICE JURIDIQUE |
|HCTF |TASK FORCE RESSOURCES HUMAINES,EDUCATION,FORM+JEUN |
|HCTR |SERVICE DE TRADUCTION |
|HC01 |DG I - RELATIONS EXTERIEURES |
|HC02 |DG II - AFFAIRES ECONOMIQUES ET FINANCIERES |
|HC03 |DG III - MARCHE INTERIEUR ET AFF. INDUSTRIELLES |
|HC04 |DG IV - CONCURRENCE |
|HC05 |DG V - EMPLOI, AFFAIRES SOCIALES ET EDUCATION |
|HC06 |DG VI - AGRICULTURE |
|HC07 |DG VII - TRANSPORTS |
|HC08 |DG VIII - DEVELOPPEMENT |
|HC09 |DG IX - PERSONNEL ET ADMINISTRATION |
|HC1 |CABINETS, DG, OU SERVICES DE LA CCE |
|HC1A |DG IA - RELATIONS EXTERIEURES-A |
|HC1B |DG IB - RELATIONS EXTERIEURES-B |
|HC10 |DG X - INFORMATION, COMMUNICATION ET CULTURE |
|HC11 |DG XI - ENVIRON.,PROTECT.CONSOMMAT.,SECUR.NUCL. |
|HC12 |DG XII - SCIENCE, RECHERCHE ET DEVELOPPEMENT |
|HC13 |DG XIII - TELECOMMUN.,INDUSTR.DE L'INFORM.,INNOVA |
|HC14 |DG XIV - PECHE |
|HC15 |DG XV - INSTITUT.FINANCIER.ET DROIT DES SOCIET. |
|HC16 |DG XVI - POLITIQUE REGIONALE |
|HC17 |DG XVII - ENERGIE |
|HC18 |DG XVIII - CREDIT ET INVESTISSEMENTS |
|HC19 |DG XIX - BUDGETS |
|HC2 |DELEGUES DE LA CCE |
|HC20 |DG XX - CONTROLE FINANCIER |
|HC21 |DG XXI - UNION DOUANIERE ET FISCALITE INDIRECTE |
|HC22 |DG XXII - COORDINAT. DES INSTRUMENTS STRUCTURELS |
|HC23 |DG XXIII - POL.D'ENTREPR.,COMMERCE,TOURISME+EC.SOC |
|HC24 |DG24 - POLITIQUE DES CONSOMMATEURS |
|HC3 |COMITES CONSULTATIFS |
|HC9 |AUTRES |
|HD |COUR DE JUSTICE |
|HE |COMITE ECONOMIQUE ET SOCIAL |
|HF |COUR DES COMPTES |
|HG |BEI |
|HH |EUROCONTROL |
|HI |CEDEFOP |
|HJ |FONDATION EUROP. POUR L'AMELIORATION DES CONDITIONS DE VIE |
|HK |COMITE DES REGIONS |
|HZ |ORGANE ASSIMILE (BEI, EUROCONTROL) |
|I |ACTUELLEMENT SANS EMPLOI |
|J |ORGANISATION INTERNATIONALE |
|JA |ORGANISATION INTERNATIONALE GOUVERNEMENTALE |
|JB |ORGANISATION INTERNATIONALE NON GOUVERNEMENTALE |
|K |REPRESENTATION ETRANGERE, CORPS DIPLOMATIQUE |
|KA |REPRESENTATIONS PERMANENTES, MISSIONS ACCREDITEES |
|KA1 |REPRESENTATIONS PERMANENTES |
|KA2 |MISSIONS |
|KA3 |REPRESENTATIONS AUPRES DE LA COMMISSION |
|KB |MEDECINS ET PHARMACIENS |
|KC |ARCHITECTES GEOMETRES URBANISTES |
|KD |EXPERTS COMPTABLES CONSEILLERS FISCAUX |
|KE |INGENIEURS CONSEILS |
| | |
|L |ORGANISATION SYNDICALE OU PROFESS. DE SALARIES |
|LA |SYNDICATS |
|LB |ORGANISATIONS PROFESSIONNELLE INDUSTRIELLES |
|LC |ORGANISATIONS ARTISANS ET COMMERCANTS |
|LD |ORGANISATIONS AGRICOLES |
|LE |CHAMBRES DE COPMMERCE ET D'INDUSTRIE |
|LF |ORGANISATIONS PROFESSIONNELLES LIBERALES (ORDRES) |
|M |ORGANISATION PROFESSIONNELLE |
|MA |ORGANISATION PROFESSIONNELLE D'INDUSTRIELS |
|MB |ORGANISATION PROFESSIONNELLE D'ARTISANS |
|MC |ORGANISATION PROFESSIONNELLE DE COMMERCANTS |
|MD |ORGANISATION PROFESS. DE PRODUCTEURS AGRICO./PECHE |
|ME |ORGANISATION PROFESS. DES BANQUES ET ASSURANCES |
|MF |COMITE D'ENTREPRISE EUROPEEN |
|MX |ORGANISATION D'EMPLOYEURS |
|MZ |AUTRE ORGANISATION PROFESSIONNELLE D'INDEPENDANTS |
|N |INDUSTRIE, ENTREPRISE, 8PRIVE OU PUBLIQUE) |
|NA |AGRICULTURE,CHASSE, SYLVICULTURE, PECHE |
|NA1 |AGRICULTURE ET CHASSE |
|NA2 |SYLVICULTURE |
|NA3 |PECHE |
|NB |EAU (CAPTAGE, TRAITEMENT, DISTRIBUTION DE L'EAU |
|NC |ENERGIE |
|NC1 |PETROLE ET GAZ NATUREL (HYDROCARBURES) |
|NC2 |CHARBON, COMBUSTIBLES SOLIDES |
|NC3 |NUCLEAIRE |
|NC4 |PRODUCTION ET DISTRIBUTION D'ELECTRICITE ET DE GAZ |
|NC5 |FABRICATIONS METALLIQUES |
|NC6 |AGRO-ALIMENTAIRE |
|NC9 |AUTRE INDUSTRIE DU SECTEUR DE L'ENERGIE |
|ND |METALLURGIE ET SIDERURGIE, MINES |
|ND1 |MINES H |
|ND2 |TRANSPORTS |
|ND9 |AUTRES SERVICES |
|NE |INDUSTRIE DE TRANSFORMATION,INDUST.MANUFACTURIERE |
|NE1 |TRANFORMATION DES METAUX, MECANIQUE |
|NE2 |CONSTRUCTION DE MOYENS DE TRANSPORT |
|NE21 |AERONAUTIQUE ET AEROSPATIAL |
|NE22 |CONSTRUCTION NAVALE |
|NE23 |AUTOMOBILE |
|NE26 |AUTRE MOYEN DE TRANSPORT TERRESTRE |
|NE3 |ELECTRONIQUE, TELECOMMUNICATION, INFORMATIQUE |
|NE4 |CHIMIE, PRODUITS PHARMACEUTIQUES,PLAST.,CAOUTCHOUC |
|NE5 |TEXTILE, CUIR, HABILLEMENT |
|NE6 |ALLIMENTATION |
|NE7 |BOIS, PAPIER |
|NE9 |AUTRE INDUSTRIE MANUFACTURIERE |
|NF |BATIMENT, MATERIAUX DE CONSTRUCTION, GENIE CIVIL |
|NG |COMMERCE |
|NH |ENTREPRISE FINANCIERE, BANQUE, ASSURANCE |
|NH1 |ENTREPRISE FINANCIERE |
|NH2 |BANQUE |
|NH3 |ASSURANCE |
|NI |TOURISME (RESTAURATION, HOTELLERIE, VOYAGE) |
|NJ |SOCIETES DE SERVICE, CONSEIL, AGENCE |
|NK |TRANSPORT ET COMMUNICATIONS (SERVICES) |
|NK1 |TRANSPORT (SERVICES) |
|NK11 |TRANSPORT AERIEN |
|NK12 |TRANSPORT TERRESTRE (SERV PUBLIC)TRANSP EN COMMUN |
|NK13 |TRANSPORT TERRESTRE (ENTREPRISE PRIVEE) |
|NK15 |TRANSPORT MARITIME ET FLUVIAL |
|NK2 |POSTES ET TELECOMMUNICATIONS (SERV PUBL.ET PRIVES) |
|NK9 |AUTRES SERVICES |
|NL |ARTS GRAPHIQUES |
|NM |CONSULTANCE |
|NN |SOCIETE DE DEVELOPPEMENT |
|NO |PME - (MOINS DE 250 SALARIES) |
|NP |ENTREPRISE ARTISANALE ET MICRO-ENTREPRISE |
|NZ |AUTRE INDUSTRIE, ENTREPRISE |
|O |INSTITUTIONS COMMUNAUTAIRES |
|OA |COMMISSION DELEGATION BUREAU DE PRESSE |
|OB |OFFICE DES PUBLICATIONS |
|OC |PARLEMENT EUROPEEN |
|OE |AUTRES |
|P |INSTITUT SCIENTIFIQUE, INSTITUT DE RECHERCHE |
|PA |INSTITUT ETUDE EUROPEENNE |
|PB |INSTITUT ETUDE ECONOMIQUE |
|PZ |INSTITUT AUTRES ETUDES |
|Q |ORGANISME DE SECURITE SOCIALE OU D'ASSIST.SOCIALE |
|R |INSTITUTION DE SANTE, SERVICE VETERINAIRE |
|S |ORGANISATION RELIGIEUSE, ASSOCIATION PHILOSOPHIQUE |
|X |ASSOCIATION NON COMMERCIALE DIVERS |
|XA |ASSOCIATION DE CONSOMMATEURS |
|XB |ASSOCIATION POUR LA PROTECTION DE L'ENVIRONNEMENT |
|XC |ASSOCIATION DE JEUNES |
|XD |MOUVEMENT EUROPEEN |
|XE |MOUVEMENTS FIMININS |
|XF |ASSOCIATION HUMANITAIRE |
|XG |ASSOCIATION D'INTERET AGRICOLES |
|XH |ORGANISATION POUR LES PERSONNES HANDICAPES |
|XI |ORGANISATION POUR L'ENFANCE |
|XJ |ORGANISATION POUR LA FAMILLE |
|XK |ORGANISATION POUR LES PERSONNES AGEES |
|XL |ORGANISATION POUR LES PERSONNES MIGRANTES |
|XM |ORGANISATION POUR LA SANTE |
|XZ |AUTRES GROUPES |
|Y |ASSOCIATION COMMERCIALE DIVERSE |
|YA |ASSOCIATION D'AUTORITES LOCALES/REGIONALES |
|YB |ASSOCIATION D'ENTREPRISES |
|Z |AUTRE ORGANISME OU INSTITUTION |
|ZB |PARTICULIERS |
Annex 17 Description of the DWH Publications
The Data Warehouse “Stock” and “Dissemination” is used to collect information about the Publications Office’s commercial and logistics activities from GescomX and SagapX applications.
1 Business Processes
Three main business processes are covered:
➢ Warehouse transaction management (logical and physical transactions)
➢ Inventory management (periodic logical and physical warehouse snapshots)
➢ Shipments (based on subscriptions or on orders)
Business process “Warehouse transaction management”
Warehouse management allows the user to follow the lifecycle of each publication from reception until shipment or destruction. GescomX records each warehouse transaction. On this base the full history for each publication is available. Periodically data is extracted from GescomX and imported into the Data Warehouse.
Business process “Inventory management”
The inventory management process of GescomX allows the user to track the actual inventory levels. Monthly snapshots are taken to feed the Data Warehouse. The information is used to produce statistics about inventory evolution, inventory value or warehouse occupation level.
Business process “Shipments”
Contacts and subscription management are handled by the Publications Office’s logistics management system (SagapX). The system contains all the addresses needed for shipment. Addresses are regrouped by mailing lists. Periodically all information about shipments is extracted and imported into the Data Warehouse.
2 Functionality of the Data Warehouse system
The following functionality is provided by the Data Warehouse system:
➢ Import procedures for all business processes. Data is provided as flat files, which are first loaded to temporary tables and then to the final datawarehouse. The loading procedure contains following transactions:
➢ Daily loading of warehouse transactions.
➢ Weekly loading of logical and physical inventory snapshots.
➢ Monthly loading of logical and physical inventory snapshots.
➢ Periodical loading of shipment data.
➢ Harmonization of data in order to share, merge and present the information in a uniform way to the user.
➢ Validation of the data according to the Publications Office’s nomenclatures (for example country codes, warehouse locations, languages, etc.)
3 Information Retrieval
Information retrieval is done by using the Business Objects (BO) software. The results are obtained either by using standard - or by creating specific reports.
Each business process, which has been described above, is also represented by a BO universe.
Different aggregations exist:
➢ by shipment destination.
➢ by distribution network.
➢ by product category.
4 Technical environment and elements
Server: SUN 15000 - OS Solaris 10 (SunOS 5.10)
Database: Oracle 10.2.0.3 64bit
5 Database size
Data size: 46GBs
Number of tables: 67
Number of functions: 11
6 Technical environment:
[pic]
7 Database design
1. Table D_ARTICLES (Diffusion Elements)
|Column Name |Type |P |M |Data Source |
|ART_ID |NUMBER(9) |Yes |Yes |Item ID |
|ART_NUMCAT |VARCHAR2(12) |No |Yes |Catalogue number |
|ART_LIBELLE |VARCHAR2(64) |No |No |Description |
|ART_STOTYP |VARCHAR2(3) |No |No |Type d’élément de stock |
|ART_LIB_STOTYP |VARCHAR2(80) |No |No |Libellé du type d’élément de stock |
|ART_STOFAM |VARCHAR2(3) |No |No |Famille de stockage |
|ART_LIB_STOFAM |VARCHAR2(80) |No |No |Libellé de la famille de stockage |
|ART_NUMSEQIND |NUMBER(6) |No |No |Numéro séquentiel indépendant de la|
| | | | |langue (le même pour toutes les VL)|
|ART_NUMSEQDEP |NUMBER(3) |No |No |Numéro séquentiel dépendant de la |
| | | | |langue (spécifique à chaque VL) |
|ART_NUMDOSS |VARCHAR2(9) |No |No |Numéro de dossier |
|ART_NUMOUVR |VARCHAR2(3) |No |No |Numéro d’ouvrage |
|ART_NUMVOL |VARCHAR2(3) |No |No |Numéro de volume |
|ART_PUBCTGCOD |VARCHAR2(3) |No |No |Numéro structuré: Catégorie |
|ART_LIB_PUBCTGCOD |VARCHAR2(80) |No |No |Libellé de la catégorie du numéro |
| | | | |structuré |
|ART_PUBSTRANN |NUMBER(4) |No |No |Numéro structuré: année |
|ART_PUBEX_NUM |VARCHAR2(10) |No |No |Numéro structuré: numéro |
|ART_SUPPORT |VARCHAR2(3) |No |No |Support |
|ART_LIB_SUPPORT |VARCHAR2(80) |No |No |Libellé du support |
|ART_VL |VARCHAR2(2) |No |No |Version linguistique |
|ART_LONG |NUMBER(7,3) |No |No |Longueur (mm) |
|ART_LARG |NUMBER(7,3) |No |No |Largeur (mm) |
|ART_HAUT |NUMBER(7,3) |No |No |Hauteur (mm) |
|ART_MASSE |NUMBER(7,3) |No |No |Masse (g) |
|ART_LOGDATE |DATE |No |No |Date of first entry (log.) |
|ART_MULTI_ELEM |VARCHAR2(3) |No |No |Code multi-élément |
|ART_LIB_MULTIELEM |VARCHAR2(80) |No |No |Libellé du code multi-élément |
|ART_TYP_PUB |VARCHAR2(8) |No |No |Type de publication |
|ART_LIB_TYPPUB |VARCHAR2(80) |No |No |Libellé du type de publication |
|ART_FORIFRCOD |VARCHAR2(3) |No |No |Format d’information |
|ART_LIB_FORIFR |VARCHAR2(80) |No |No |Libellé du format d’information |
|ART_FABFORCOD |VARCHAR2(3) |No |No |Format du produit fini |
|ART_LIB_FABFOR |VARCHAR2(80) |No |No |Libellé du format du produit fini |
|ART_PUBGRPNUM |NUMBER(4) |No |No |Référence du périodique ou de la |
| | | | |série rattachée à la publication |
|ART_PUBGRPTTA |VARCHAR2(64) |No |No |Titre du périodique ou de la série |
| | | | |rattachée à la publication |
|ART_PUBAUT_NUM |NUMBER(4) |No |No |Numéro Service auteur |
|ART_PUBAUT_CODE |VARCHAR2(9) |No |No |Code service auteur |
|ART_DFECMFCOD |VARCHAR2(3) |No |No |Famille commerciale |
|ART_LIB_DFECMF |VARCHAR2(80) |No |No |Libellé de la famille commerciale |
|ART_CPFCOD |VARCHAR2(3) |No |No |Famille comptable |
|ART_LIB_CPF |VARCHAR2(80) |No |No |Libellé de la famille comptable |
|ART_VNFCOD |VARCHAR2(3) |No |No |Famille de vente |
|ART_LIB_VNF |VARCHAR2(80) |No |No |Libellé de la famille de vente |
|ART_ISSN |VARCHAR2(8) |No |No |N° ISSN propre au produit ou N° |
| | | | |ISSN du périodique |
|ART_ISBN |VARCHAR2(13) |No |No |Numéro ISBN |
|ART_PUBLANEDTJRS |NUMBER(2) |No |No |Jour d’édition |
|ART_PUBLANEDTMOI |NUMBER(2) |No |No |Mois d’édition |
|ART_PUBLANEDTANN |NUMBER(4) |No |No |Année d’édition |
|ART_TYPCOD |VARCHAR2(3) |No |No |Type de produit |
|ART_LIB_TYPCOD |VARCHAR2(80) |No |No |Libellé du type de produit |
|ART_TYSCOD |VARCHAR2(3) |No |No |Sous-type de produit |
|ART_LIB_TYSCOD |VARCHAR2(80) |No |No |Libellé du sous-type de produit |
|ART_ETACOD |VARCHAR2(1) |No |No |Etat du produit |
|ART_LIB_ETA |VARCHAR2(80) |No |No |Libellé de l’état du produit |
|ART_STKETACOD |VARCHAR2(1) |No |No |Etat du stock |
|ART_LIB_STKETA |VARCHAR2(80) |No |No |Libellé de l’état du stock |
|ART_VNUCOD |VARCHAR2(6) |No |No |Unité de vente |
|ART_LIB_VNUCOD |VARCHAR(80) |No |No |Libellé de l’unité de vente |
|ART_VNUPRX |NUMBER(6,2) |No |No |Tarif € |
|ART_TFTTYPCOD |VARCHAR2(1) |No |No |Type de tarif |
|ART_LIB_TFTTYP |VARCHAR2(80) |No |No |Libellé du type de tarif |
|ART_TFTDAD |DATE |No |No |Date de début de validité du tarif |
|ART_RPDTYPCOD |VARCHAR2(1) |No |No |Type de reproductibilité |
|ART_LIB_RPDTYP |VARCHAR2(80) |No |No |Libellé du type de reproductibilité|
|ART_LANBLKIDC |VARCHAR2(1) |No |No |Blocage |
|ART_CATDIFTRSCOD |VARCHAR2(1) |No |No |Code d’exportation CATDIFF |
|ART_LIB_CATDIFF |VARCHAR2(80) |No |No |Libellé du code d’exportation |
|ART_REPCATDIFF |VARCHAR2(1) |No |No |Reprise sur CATDIFF |
|ART_PUBLANDIMQTE |NUMBER(4) |No |No |Nombre d’unités |
Loaded From: Batch PDWH020B
Loading period: Daily + on demand
Primary key index PK_D_ARTICLES on ART_ID.
Unique index on ART_NUMCAT_U1 (ART_NUMCAT)
2. Table D_EAD (Stock owners)
|Column Name |Type |P |M |Data Source |
|EAD_NUM |NUMBER(4) |Yes |Yes |N° de l’entité |
|EAD_CODE |VARCHAR2(9) |No |No |Code l’EA |
|EAD_DESCRIPTION |VARCHAR2(75) |No |No | |
|EAD_SUPNUM |NUMBER(4) |No |No |N° de l’entité parente |
Loaded From: Batch PDWH010B
Loading period: Daily + on demand
Primary key index PK_D_EAD on EAD_NUM
3. Table D_EMPLACEMENT (Warehouses and subdivisions)
|Column Name |Type |P |M |Data Source |
|EMP_NUM |NUMBER(5) |Yes |Yes |N° de l’emplacement |
|EMP_COD |VARCHAR2(10) |No |No |Code de l’entrepôt |
|EMP_ENTREPOT |VARCHAR2(3) |No |No |Entrepôt |
|EMP_TYPE |VARCHAR2(2) |No |Yes |Type d’emplacement |
|EMP_EMPSUP |NUMBER(5) |No |No |Emplacement sup. |
|EMP_BARCODE |VARCHAR2(13) |No |No |Code barre (non util.) |
|EMP_LONG |NUMBER(7,3) |No |No |Longueur (mm) |
|EMP_LARG |NUMBER(7,3) |No |No |Largeur (mm) |
|EMP_HAUT |NUMBER(7,3) |No |No |Hauteur (mm) |
Loaded From: Batch PDWH010B
Loading period: Daily + on demand
Primary key index PK_D_EMPLACEMENT on EMP_NUM
4. Table F_MVTPHY (Physical movements)
This is the fact table for physical stock transactions.
|Column Name |Type |P |M |Data Source |
|PHY_MVTNUM |NUMBER(11) |Yes |Yes |N° de mouvement |
|PHY_MVTTYP |VARCHAR2(4) |No |Yes |FK type de mouv. |
|PHY_DATE |DATE |No |Yes |Date du mouvement |
|PHY_ART_ID |NUMBER(9) |No |Yes |FK articles |
|PHY_EMPNUM |NUMBER(5) |No |Yes |FK emplacements |
|PHY_QTEMVT |NUMBER(9) |No |No |Quantité |
|PHY_QTESTKFIN |NUMBER(9) |No |No |Qté finale en stock |
|PHY_WEIGHT |NUMBER(11,3) |No |No |Poids |
|PHY_VOLUME |NUMBER(9,5) |No |No |Volume |
The movement number will be split in Business Objects in two objects:
Numéro d’opération
Numéro de mouvement
The weight and volume may be are computed at data loading and may be recomputed later by a separate procedure that will also provide a report of updates (Items, old weight & vol. , new weight. & vol.).
Partitioned by range on PHY_DATE.
Loaded From: Batch PDWH001B
Loading period: Daily
PK index PK_PHYMVT on PHY_MVTNUM.
Local bitmap index on PHY_MVTTYP
Local bitmap index on PHY_ART_ID
Local bitmap index on PHY_EMPNUM
5. Table D_MVTTYPE (Movement types)
|Column Name |Type |P |M |Data Source |
|MTY_CODE |VARCHAR2(4) |No |No |Code du type de mouvement |
|MTY_DESCRIPTION |VARCHAR2(40) |No |No |Description du type |
|MTY_CODE_OPER |VARCHAR2(1) |Yes |Yes |Code operation |
|MTY_DESC_OPER |VARCHAR2(40) |No |No |Description opération |
Primary key index PK_D_MVTTYPE on MTY_CODE
6. Table D_ORDO (Ordonnateur de diffusion)
|Column Name |Type |P |M |Data Source |
|ORD_CODE_SAGAP |VARCHAR2(3) |Yes |Yes |Code ordonnateur SAGAP |
|ORD_DESC_SAGAP |VARCHAR2(64) |No |No |Description SAGAP |
|ORD_NUM_EA |NUMBER(4) |No |No |N° de l’EA GescomX |
|ORD_CODE_GESCOMX |VARCHAR2(9) |No |No |Code EA GescomX |
Loaded From: Batch PDWH010B
Loading period: Daily + on demand
Primary key index PK_D_ORD on ORD_CODE_SAGAP
Table F_MVTLOG (Logical movements)
This is the fact table for logical stock transactions.
|Column Name |Type |P |M |Data Source |
|LOG_MVTNUM |NUMBER(11) |Yes |Yes |N° de mouvement |
|LOG_MVTTYP |VARCHAR2(4) |No |Yes |FK type de mouv. |
|LOG_DATE |DATE |No |Yes |Date du mouvement |
|LOG_ART_ID |NUMBER(9) |No |Yes |FK articles |
|LOG_EAD_NUM |NUMBER(4) |No |Yes |FK EAD |
|LOG_QTEMVT |NUMBER(9) |No |No |Quantité |
|LOG_QTESTKFIN |NUMBER(9) |No |No |Qté finale en stock |
|LOG_WEIGHT |NUMBER(11,3) |No |No |Poids |
|LOG_VOLUME |NUMBER(9,5) |No |No |Volume |
The movement number will be split in Business Objects in two objects:
Numéro d’opération
Numéro de mouvement
The weight and volume may be are computed at data loading and may be recomputed later by a separate procedure that will also provide a report of updates (Items, old weight & vol. , new weight. & vol.).
Partitioned by range on LOG_DATE
Loaded From: Batch PDWH001B
Loading period: Daily
PK index PK_MVTLOG on LOG_MVTNUM.
Local bitmap index on LOG_MVTTYP
Local bitmap index on LOG_ART_ID
Local bitmap index on LOG_EAD_NUM
Local bitmap index on LOG_DATE
7. Table F_STOPHYS (Physical stocks)
This is the fact table for physical inventory.
|Column Name |Type |P |M |Data Source |
|SPH_ART_ID |NUMBER(9) |Yes |Yes |FK articles |
|SPH_EMPNUM |NUMBER(5) |Yes |Yes |FK emplacements |
|SPH_DATE |DATE |Yes |Yes |Date (année/mois) |
|SPH_QTEBEG |NUMBER(9) |No |No |Qté en début de mois |
|SPH_QTEEND |NUMBER(9) |No |No |Qté en fin de mois |
|SPH_AVGQTY |NUMBER(14,3) |No |No |Quantité moyenne |
|SPH_QTEMIN |NUMBER(9) |No |No |Quantité minimale |
|SPH_QTEMAX |NUMBER(9) |No |No |Quantité maximale |
|SPH_AVGWEIGHT |NUMBER(12,3) |No |No |Poids moyen |
|SPH_COST |NUMBER(12,3) |No |No |Frais de stockage |
|SPH_VALUE |NUMBER(14,5) |No |No |Valeur du stock |
|SPH_AVGVOL |NUMBER(12,3) |No |No |Volume moyen |
Partitioned by range on SPH_DATE
Loaded From: Batch PDWH001B
Loading period: Monthly + on demand
Local bitmap index on SPH_ART_ID
Local bitmap index on SPH_EMPNUM
Local bitmap index on SPH_DATE
8. Table F_STOLOG (Logical stocks)
This is the fact table for logical inventory.
|Column Name |Type |P |M |Data Source |
|SLO_ART_ID |NUMBER(9) |Yes |Yes |FK articles |
|SLO_EAD_ID |NUMBER(4) |Yes |Yes |FK EAD |
|SLO_DATE |DATE |Yes |Yes |Date (année/mois) |
|SLO_QTEBEG |NUMBER(9) |No |No |Qté en début de mois |
|SLO_QTEEND |NUMBER(9) |No |No |Qté en fin de mois |
|SLO_QTEMIN |NUMBER(9) |No |No |Quantité moyenne |
|SLO_QTEMAX |NUMBER(9) |No |No |Quantité minimale |
|SPH_AVGQTY |NUMBER(14,3) |No |No |Quantité maximale |
|SLO_AVGWEIGHT |NUMBER(12,3) |No |No |Poids moyen |
|SLO_COST |NUMBER(12,3) |No |No |Frais de stockage |
|SLO_VALUE |NUMBER(14,5) |No |No |Valeur du stock |
|SLO_AVGVOL |NUMBER(12,3) |No |No |Volume moyen |
Partitioned by range on SLO_DATE
Loaded From: Batch PDWH001B
Loading period: Monthly + on demand
Local bitmap index on SLO_ART_ID
Local bitmap index on SLO_EAD_ID
Local bitmap index on SLO_DATE
9. Table D_TRANSPORTEUR (Courier)
|Column Name |Type |P |M |Data Source |
|EXP_CODE |VARCHAR2(16) |Yes |Yes |Code |
|EXP_DESCRIPTION |VARCHAR2(80) |No |No |Description |
PK index PK_TRANSPORTEUR on EXP_CODE
Loaded From: NA
Loading period: Daily + on demand
10. Table D_MODENVOI (Mode d’envoi)
|Column Name |Type |P |M |Data Source |
|MOD_CODE |VARCHAR2(2) |Yes |Yes |Code du mode d’envoi |
|MOD_DESCRIPTION |VARCHAR2(40) |No |No |Description |
|MOD_PAYANT |VARCHAR2(1) |No |No |G=Gratuit, P=Payant |
Loaded From: NA
Loading period: Daily + on demand
Primary key index PK_MODENVOI on MOD_CODE
11. Table D_LANG (Versions linguistiques)
|Column Name |Type |P |M |Data Source |
|BAS_COMPCODE |VARCHAR2(2) |Yes |Yes |Code VL composée |
|BAS_BASCODE |VARCHAR2(2) |Yes |Yes |Code langage (base) |
|LNG_DESCRIPTION |VARCHAR2(80) |No |No | |
PK index PK_VL on (BAS_COMPCODE, BAS_BASCODE)
This table defines the different languages (as well as associations of languages) used by the products. There are number of basic languages (FR for French, DE for Germany, EN for English) and associations of different languages (2A: EN + FR). For basic languages, BAS_COMPCODE = BAS_BASCODE.
The two attributes BAS_COMPCODE and BAS_BASCODE should appear in the BO universe so that users are able to issue both type of queries.
12. Table D_DESTINATAIRE (Recipient of diffusion, customer)
|Column Name |Type |P |M |Data Source |
|DES_ID |NUMBER |Yes |Yes |Identifiant destinataire |
|DES_TYPE |VARCHAR2(1) |No |No |Type d’adresse: |
| | | | |G: GescomX |
| | | | |S: Sagap |
| | | | |T: Temporaire |
| | | | |E : EA |
|DES_NUMTMP |NUMBER(9) |No |No |N° de l’adresse temporaire |
|DES_NOM |VARCHAR2(35) |No |No |Nom du destinataire |
|DES_MATRICULE |VARCHAR2(10) |No |No |Matricule SAGAP |
|DES_CLIENT |NUMBER(8) |No |No |N° de client GESCOMX |
|DES_ROLEADR |VARCHAR2(3) |No |No |Rôle / Adresse |
|DES_NUMEAD |NUMBER(4) |No |No |N° de l’EA destinataire |
|DES_VILLE |VARCHAR2(21) |No |No |Ville |
|DES_CODEREG |VARCHAR2(3) |No |No |Code région |
|DES_LIBCODEREG |VARCHAR2(80) |No |No |Libellé du code région |
|DES_PAYS_CODE |VARCHAR2(2) |No |No |Code ISO pays |
|DES_PAYS_DESC |VARCHAR2(40) |No |No |Libellé pays |
|DES_BEGINVAL |DATE |No |No |Date de début de val. |
|DES_ENDVAL |DATE |No |No |Date de fin de val. |
Loaded From: NA
Loading period: Daily + on demand
Primary key index PK_D_DESTINATAIRE on DES_ID
Non unique index on DES_NOM
Non unique index on (DES_CLIENT, DES_ROLEADR)
Non unique index on DES_MATRICULE, DES_NUMEAD
Bitmap index on DES_PAYS_CODE
Bitmap index on DES_VILLE
13. Table F_DIFFUSION
This is the fact table for the shipments.
|Column Name |Type |P |M |Data Source |
|DIF_TYPE |VARCHAR2(2) |No |Yes |Type de diffusion (Commande ou |
| | | | |abonnement SAGAP) |
|DIF_LIB_TYPE |VARCHAR2(120) |No |No |Libellé du type de diffusion |
|DIF_ORDEXP_ID |NUMBER(4) |No |No |Ordonnateur d’expédition GESCOMX |
|DIF_ORD_ID |VARCHAR2(3) |No |No |FK ordonnateur Sagap |
|DIF_PROPSTK |NUMBER(4) |No |Yes |Propriétaire du stock |
|DIF_EXP_ID |VARCHAR2(16) |No |No |Identifiant transporteur |
|DIF_ENVMOD |VARCHAR2(10) |No |Yes |FK Mode d’envoi |
|DIF_DES_ID |NUMBER |No |No |Identifiant destinataire |
|DIF_DES_TYPE |VARCHAR2(1) |No |No |Type de destinataire |
|DIF_ORDER_NUM |NUMBER(10) |No |No |N° de commande |
|DIF_ORDER_LINE |NUMBER(3) |No |No |Ligne de commande |
|DIF_ORDER_DATE |DATE |No |No |Date de commande |
|DIF_ORDER_QTY |NUMBER |No |No |Qté commandée |
|DIF_DOSSIER |NUMBER(7) |No |No |Dossier de diffusion Sagap |
|DIF_LISTDIFF |NUMBER(2) |No |No |Liste de diff. Sagap |
|DIF_DELIVERY_NUM |NUMBER(12) |No |No |N° d’expédition |
|DIF_DELIVER_LINE |NUMBER(13) |No |Yes |Ligne d’expédition |
|DIF_DELIVER_QTY |NUMBER |No |No |Qté envoyée |
|DIF_ART_ID |NUMBER |No |No |Identifiant article |
|DIF_COUT |NUMBER(8,2) |No |No |Frais de transport |
|DIF_POIDS |NUMBER |No |No |Poids |
|DIF_VOLUME |NUMBER |No |No |Volume |
|DIF_VALUE |NUMBER |No |No |Prix unitaire de l’article |
|DIF_MNT_BRUT |NUMBER(9,2) |No |No |Montant brut |
|DIF_DISCOUNT |NUMBER(5,2) |No |No |Remise (%) |
|DIF_DELIV_DATE |DATE |No |Yes |Date d’envoi |
|DIF_CODORDRE |VARCHAR2(1) |No |No |Code ordre Sagap |
|DIF_LIB_CORORDRE |VARCHAR2(80) |No |No |Libellé du code ordre |
|DIF_COND |VARCHAR2(1) |No |No |Conditionnement Sagap |
|DIF_LIB_COND |VARCHAR2(80) |No |No |Libellé du conditionnement |
|DIF_NUMBOR |NUMBER(9) |No |No |N° bordereau expéd. |
|DIF_ZONEGEO |VARCHAR2(3) |No |No |Zone géographique |
|DIF_LIBZONEGEO |VARCHAR2(80) |No |No |Libellé de la zone géo. |
|DIF_DATDOSS_M |DATE |No |No |Date de passage de la commande à |
| | | | |l’état M |
|DIF_DATDOSS_X |DATE |No |No |Date de passage de la commande à |
| | | | |l’état X |
Partitioned by range on DIF_DELIV_DATE
Loaded From: NA
Loading period: Daily + on demand
Volume estimation: 53000 rec. by day * 220 ( 12 M rows by year ( 2 Gbyte by year without indexes (raw data).
Local bitmap index on DIF_DES_ID
Local bitmap index on DIF_ART_ID
Local bitmap index on DIF_ORD_ID
Local bitmap index on DIF_PROPSTK
Local bitmap index on DIF_EXP_ID
Local bitmap index on DIF_DELIV_DATE
Local bitmap index on DIF_ENVMOD
14. Table D_LIBELLES
|Column Name |Type |P |M |Data Source |
|LIB_TYPE |VARCHAR2(12) |Yes |Yes |Type de libellé |
|LIB_MAXCODLEN |NUMBER(2) |No |No |Longueur max. du code |
|LIB_MAXLIBLEN |NUMBER(2) |No |No |Longueur max. du libellé |
|LIB_CODE |VARCHAR2(20) |Yes |Yes |Code du libellé |
|LIB_LIBELLE |VARCHAR2(120) |No |No |Libellé |
15. Table D_FACTURES
|Column Name |Type |P |M |Data source |
|FAC_NUM |NUMBER(10) |Yes |Yes |Numéro de la facture |
|FAC_LINE_SEQ_NUM |NUMBER(3) |Yes |Yes |Numéro séquentiel de la ligne de facture |
|SAC_LFACNUM_ANL |NUMBER(10) |No |No |Numéro de la facture annulée par la note |
| | | | |de crédit courante |
|SAC_FACNUMLIG_ANL |VARCHAR2(3) |No |No |Libelle du Numéro de la facture annulée |
| | | | |par la note de crédit courante SAGAP |
|FAC_NUM_REMPLACEE |NUMBER(10) |No |No |Numéro de la facture remplacée par la |
| | | | |facture courante. |
|FAC_TYPE_CODE |VARCHAR2(3) |No |Yes |Code du type de facture client |
|FAC_TYPE_CODE_LIB |VARCHAR2(50) |No |No |Libelle du Code du type de facture client|
|FAC_LINE_TYPE |VARCHAR2(2) |No |Yes |Indique le type de la ligne de facture. |
|FAC_LINE_TYPE_LIB |VARCHAR2(50) |No |Yes |Indique le libellé du type de la ligne de|
| | | | |facture. |
|FAC_LINE_BRUT_UNITPRICE |NUMBER(8,2) |No |No |Prix unitaire brut de vente. |
|FAC_LINE_BRUT_MONT |NUMBER(11,2) |No |Yes |Montant brut de la ligne de facture |
|FAC_LINE_NET_MONT |NUMBER(11,2) |No |No |Montant net de la ligne de facture |
|FAC_REMISE_MONT |NUMBER(9,2) |No |No |Montant total des remises de la facture |
| | | | |client |
|FAC_LINE_REMISE |NUMBER(11,2) |No |No |Remise accordée sur la ligne de facture |
|FAC_ISO_CURRENCY_CODE |VARCHAR2(3) |No |No |Code ISO de la devise. (Devise associée |
| | | | |au pays de l'adresse de facturation). |
|FAC_ISO_CURRENCY_CODE_LIB |VARCHAR2(50) |No |No |Libellé du Code ISO de la devise. (Devise|
| | | | |associée au pays de l'adresse de |
| | | | |facturation). |
|FAC_COURS_CHANGE_ECU |NUMBER(14,7) |No |Yes |Cours de change de l'ECU par rapport à la|
| | | | |devise a la date d'édition de la facture.|
|FAC_PAY_PREAUTORISATION_REF |VARCHAR2(20) |No |Yes |Référence de la pré-autorisation de |
| | | | |paiement fournie par CETREL lors de la |
| | | | |prise de commande CATDIFF. |
|FAC_TOP_DEBIT_CODE_CATDIFF |VARCHAR2(1) |No |No |Code du top débit envoyé a CATDIFF par |
| | | | |GESCOMX. |
|FAC_TOP_DEBIT_CODE _CATDIFF_LIB_ |VARCHAR2(50) |No |No |Libelle du Code du top débit envoyé a |
| | | | |CATDIFF par GESCOMX. |
|FAC_ISO_LAN_CODE |VARCHAR2(2) |No |No |Code ISO de la langue utilisée pour |
| | | | |l'édition de la facture. Il s'agit de la |
| | | | |langue dans laquelle sont exprimés les |
| | | | |textes standards édités sur la facture. |
|FAC_ISO_LAN_CODE_LIB |VARCHAR2(50) |No |No |Libellé du Code ISO de la langue utilisée|
| | | | |pour l'édition de la facture. Il s'agit |
| | | | |de la langue dans laquelle sont exprimés |
| | | | |les textes standards édités sur la |
| | | | |facture. |
|FAC_EDITION_DATE |DATE |No |Yes |Date d'édition de la facture. |
|FAC_FIRST_ECHEANCE_DATE |DATE |No |No |Date de première échéance de la facture. |
|FAC_REGLEMENT_DATE |DATE |No |No |Date de règlement de la facture |
|FAC_LINE_DATE_DEB |DATE |No |No |Date de début de la période de |
| | | | |facturation concernée par la ligne de |
| | | | |facture. |
|FAC_LINE_DATE_FIN |DATE |No |No |Date de fin de la période de facturation |
| | | | |concernée par la ligne de facture. |
|FAC_LINE_ART_ID |NUMBER(9) |No |Yes |Numéro de l’article de la facture |
|FAC_LINE_SELL_UNIT_CODE |VARCHAR2(6) |No |No |Code de l'unité de vente |
|FAC_LINE_SELL_UNIT_CODE_LIB |VARCHAR2(50) |No |No |Libellé du Code de l'unité de vente |
|FAC_LINE_FRAIS_CODE |VARCHAR2(3) |No |Yes |Code du frais. |
|FAC_COMMENT |VARCHAR2(75) |No |No |Commentaires sur la facture |
|FAC_LINE_COMMENT |VARCHAR2(150) |No |No |Commentaires sur la ligne de facture |
|FAC_LINE_ELEM_DIF_QTY_FAC |NUMBER(10) |No |Yes |Quantité d'élément de diffusion facturée |
|FAC_LINE_CLI_CNT_NUM |NUMBER(10) |No |No |Numéro du contrat client BDP facture. |
|FAC_LINE_CLI_CNT_TYPE_CDE |VARCHAR2(3) |No |Yes |Code du type de contrat client BDP. |
|FAC_LINE_CLI_CNT_TYPE_CDE_LIB |VARCHAR2(50) |No |Yes |Libellé du Code du type de contrat client|
| | | | |BDP. |
|FAC_LINE_RET_CLI_CNT_NUM |NUMBER(11) |No |No |Numéro de la ligne de retour client |
| | | | |facturée. |
|FAC_NUM_CLIENT |NUMBER(9) |No |No |Numéro du client. |
|FAC_LINE_USERID_VALUE |VARCHAR2(8) |No |No |Valeur du user-id BDP. |
|FAC_DEBIT_INDICATOR |CHAR(1) |No |Yes |Indique si la facturation est créditrice |
| | | | |ou débitrice. |
|FAC_USER_GEST_INITIALES |VARCHAR2(5) |No |No |Initiales de l'utilisateur gestionnaire |
| | | | |de la facture. |
|FAC_IND_BENEF_MULT |NUMBER(2) |No |Yes |Indicateur de bénéficiaire multiple |
|FAC_LINE_BENEF_EAD_NUM |NUMBER(4) |No |No |Numéro de l'entité administrative |
| | | | |bénéficiaire (si unique). |
|FAC_CLIENT_FAC_ID |NUMBER |No |Yes |Numéro du client facture de la facture |
Loaded From: NA
Loading period: NA
Primary key index PK_D_FACTURES on FAC_NUM and FAC_LINE_SEQ_NUM
16. Table D_CODE_FRAIS
|Column Name |Type |P |M |Data source |
|CFR_CODE |VARCHAR2(3) |Yes |Yes |Code de frais |
|CFR_LIB |VARCHAR2(40) |No |No |Libelle du Code de frais |
Loaded From: NA
Loading period: NA
Primary key index PK_D_CODE_FRAIS on CFR_CODE
17. Table D_FAC_BENEF
|Column Name |Type |P |M |Data source |
|FAB_NUM |NUMBER(10) |Yes |Yes |Numéro de facturation. |
|FAB_LINE_SEQ_NUM |NUMBER(3) |Yes |Yes |Numéro séquentiel de la ligne de |
| | | | |facture |
|FAB_EAD_BENEF_NUM |NUMBER(4) |No |No |Numéro de l'entité administrative |
| | | | |bénéficiaire. |
|FAB_FAC_LINE_MONTANT_NET |NUMBER(11) |No |No |Montant net de la ligne de facture |
| | | | |réparti à l'entité administrative |
Loaded From: NA
Loading period: NA
Primary key index PK_D_FAC_BENEF on FAB_NUM and FAB_LINE_SEQ_NUM
18. Table D_CMD_FAC
|Column Name |Type |P |M |Data source |
|CLF_FAC_NUM |NUMBER(10) |Yes |Yes |Numéro de la facture |
|CLF_FAC_LINE_SEQ_NUM |NUMBER(3) |Yes |Yes |Numéro séquentiel de la ligne de |
| | | | |facture |
|CLF_CMD_NUM |NUMBER(10) |Yes |Yes |Numéro de la commande |
|CLF_CMD_LINE_NUM_SEQ |NUMBER(3) |Yes |Yes |Numéro séquentiel de la ligne de |
| | | | |commande |
Loaded From: NA
Loading period: NA
Primary key index PK_D_CMD_FAC on CLF_FAC_NUM and CLF_FAC_LINE_SEQ_NUM and CLF_CMD_NUM and CLF_CMD_LINE_NUM_SEQ
19. Table D_USERS
|Column Name |Type |P |M |Data source |
|USER_CODE |VARCHAR2(8) |Yes |Yes |Code de l'utilisateur |
|USER_INITIALES |VARCHAR2(5) |No |Yes |Initiales de l'utilisateur, |
| | | | |identifiant de manière unique |
| | | | |l'utilisateur |
|USER_NAME |VARCHAR2(35) |No |No |Nom officiel de l'utilisateur |
|USER_GROUP_USER_CODE |VARCHAR2(8) |No |Yes |Code du groupe utilisateur auquel |
| | | | |appartient l'utilisateur. |
Loaded From: NA
Loading period: NA
Primary key index PK_D_USERS on USER_CODE
20. Table D_USER_GROUP
|Column Name |Type |P |M |Data source |
|USER_GROUP_CODE |VARCHAR2(8) |Yes |Yes |Code du groupe utilisateur |
|USER_GROUP_EAD |NUMBER(4) |No |Yes |Numéro de l'entité administrative a|
| | | | |laquelle appartient le groupe |
| | | | |utilisateur |
|USER_GROUP_LIB |VARCHAR2(40) |No |No |Libelle du groupe utilisateur |
|USER_GROUP_DEF_NUM_CLIENT |NUMBER(8) |No |No |Numéro du client a utiliser par |
| | | | |défaut pour équiper le champ |
| | | | |"client facture" des commandes |
| | | | |créées par le groupe d'utilisateur.|
|USER_GROUP_DEF_NUM_CLIENT_UPD |CHAR(1) |No |Yes |Indique si le numéro de client |
| | | | |utilise pour équiper le champ |
| | | | |"client facture" des commandes |
| | | | |crées par le groupe est a utiliser |
| | | | |obligatoirement ou s'il peut être |
| | | | |modifie |
Loaded From: NA
Loading period: NA
Primary key index PK_D_USER_GROUP on USER_GROUP_CODE
21. Table D_COMMANDES_EXECUTEES / D_COMMANDES_EN_COURS
|Column Name |Type |P |M |Data source |
|CMD_NUM |NUMBER(10) |Yes |Yes |Numéro de la commande |
|CMD_LINE_NUMSEQ |NUMBER(3) |Yes |Yes |Numéro séquentiel de la ligne de |
| | | | |commande |
|CMD_CODE _TYPE |VARCHAR2(1) |No | |Code du type de commande |
|CMD_CODE_TYPE_LIB |VARCHAR2(50) |No |No |Libelle du Code du type de commande|
|CMD_FACTURATION_ANTICIPEE |CHAR(1) |No |Yes |Indique si une facturation |
| | | | |anticipée est demandée. |
|CMD_LIVRAISON_MAIL_ADDRESS |VARCHAR2(60) |No |No |Adresse électronique de livraison |
| | | | |enregistrée en caractères |
| | | | |minuscules |
|CMD_LINE_ART_ID |NUMBER(9) |No |Yes |Numéro de l’article de la ligne de |
| | | | |commande |
|CMD_LINE_GEST_EAD_NUM |NUMBER(4) |No |Yes |Numéro de l'entité administrative |
| | | | |gestionnaire de la ligne de |
| | | | |commande = numéro E.A. gestionnaire|
| | | | |de la commande |
|CMD_LINE_PROPRIO_EAD_NUM |NUMBER(4) |No |Yes |Numéro de l'entité administrative |
| | | | |propriétaire du stock |
|CMD_LINE_DEF_NUM_EAD_GRATUITE |NUMBER(4) |No |No |Numéro de l'entité administrative |
| | | | |prenant en charge par défaut la |
| | | | |gratuite de la ligne de commande. |
|CMD_LINE_QTY_DIF_ELEMENT |NUMBER(7) |No |Yes |Quantité d'éléments de diffusion |
| | | | |commandée sur la ligne de commande |
|CMD_LINE_QTY_DIF_ELEMENT_EXE |NUMBER(7) |No |No |Quantité d'éléments de diffusion |
| | | | |réellement expédiée ou traitée |
|CMD_LINE_TYPE |CHAR(1) |No |No |Code du type de ligne de commande |
|CMD_LINE_TYPE_LIB |VARCHAR2(50) |No |No |Libellé du Code du type de ligne de|
| | | | |commande |
|CMD_LINE_REF_SALE_OFFICE |VARCHAR2(20) |No |No |Référence donnée a la ligne de |
| | | | |commande par le bureau de vente |
|CMD_LINE_TAUX_REMISE |NUMBER(5,2) |No |No |Taux de remise a appliquer sur la |
| | | | |ligne de commande (exprime en %) ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.