Uniform Solution Target Solution Draft for Microsoft Business Solutions - Navision For company KonicaMinolta Business Solutions Europe Vienna Office Customer: KonicaMinolta Business Solutions Europe Vienna Office Amalienstrasse 59-61 A-1130 Wien tel. : +43 (1) 87 882 0 Fax : +43 (1) 87 882 152 Corporate Identification Number : FN 199738h Project manager: Ing. Dominik Vymetal tel.: +43 (1) 87 882 150 e-mail: dominik_vymetal@minolta.at Supplier: FUTURE Engineering, a.s. Sumavská 15 602 00 Brno tel : 541 425 911 fax : 541 425 999 Corporate Identification Number : 25517198 e-mail : eng@future.cz http : www.future.cz Project manager: Ing. Jiri Dostal tel.: +420 541 425 960 e-mail: jiri.dostal@future.cz Written : (in alphabetical order) Jiri Dostal Jindriska Machatova Kamil Sacek Antonin Sebesta Presented for authorization on: KMBS-V: FE: Authorized on: KMBS-V: FE: CONTENTS 1 Introduction.. 6 1.1 Target Solution Draft 6 1.2 Terminology 6 1.2.1 SW product 6 1.2.2 SW item.. 6 1.2.3 Target Solution Draft (TSD) 6 1.2.4 Bespoke Module (BM) 6 1.2.5 Local modification. 6 1.2.6 Uniform solution (US) 7 1.2.7 KMBS-LS. 7 1.2.8 LMBSP. 7 1.2.9 KMBS-V.. 7 1.2.10 FE.. 7 1.2.11 Navision. 7 2 Description of current status.. 8 2.1 Company processes 8 2.2 Infrastructure 11 2.3 Data engine 11 2.4 User‘s readiness for implementation 12 2.4.1 Finance. 12 2.4.2 Technology. 12 2.4.3 Work organisation. 12 2.4.4 Personnel 12 2.5 Anticipated co-operation of the user during implementation 12 2.5.1 Rules for work realisation. 12 2.5.2 Co-operation during the compilation of the Target Solution Draft 13 2.5.3 Co-operation during training. 13 2.5.4 Co-operation during acceptance. 13 2.5.5 Co-operation during the compiling of Bespoke Modules. 13 3 Solution Proposal.. 14 3.1 Basic unified licence Navision 14 3.2 Minolta Service Functionality 17 3.3 Data engine 17 4 Future Target methodology.. 18 4.1 Basic concepts 18 4.2 Project management 18 4.3 Contractual relations 18 4.4 Delivered documentation 19 4.5 Delivery of SW product 20 4.5.1 Target Solution Draft 20 4.5.2 Navision – licence. 20 4.5.3 Navision – licence for FUTURE application modules. 20 4.5.4 Parametrisation of the system.. 21 4.5.5 Data conversion. 21 4.5.6 Training. 22 4.5.7 Bespoke modules. 22 4.5.8 Acceptance. 23 4.5.9 Project proceedings. 23 4.5.10 Process reorganisation. 24 4.5.11 On-site assistance. 24 4.6 Transition method from the old system to the new system 25 4.7 Initiation into productive operation 25 4.8 SW product support 25 4.8.1 Warranty and post-warranty service. 25 4.8.2 Maintenance (including providing new versions) 26 4.8.3 Further SW product development 27 4.9 From expectation to assessment of IS benefits 27 4.10 Measuring IS benefits 28 4.11 Price 29 4.12 Payment conditions 29 4.13 Solution time schedule 30 4.14 Assessing customer satisfaction 30 5 Uniform Solution of company information system.. 32 5.1 Bookkeeping 35 5.1.1 Bank Connection. 35 5.1.2 Unified Set of Dimensions and Set up. 35 5.1.3 Leasing and Rent 36 5.1.4 Extended Application of Payments. 37 5.2 Planning & Budgeting 38 5.2.1 Budgeting of units as a base for sales planning. 38 5.3 Purchase and Logistics 42 5.3.1 Dynamic Purchase Orders. 42 5.3.2 ELC interface. 43 5.3.3 Branch stores and direct deliveries into [DEL: auto-store :DEL] [INS: car-stock :INS] s. 46 5.3.4 Centralized Item numbering. 50 5.3.5 Consignation stocks. 51 5.3.6 Limited display of acquisition and stock prices. 52 5.3.7 Special transfer prices. 53 5.3.8 Bar code use. 54 5.3.9 Report on Slow Moving Items. 55 5.4 Sales 56 5.4.1 Extended pricing with customer oriented discounts. 56 5.4.2 Configurator 57 5.4.3 External CRM and mobile salesman. 58 5.4.4 Direct connection to service (configurations sold). 59 5.4.5 e-Business. 60 5.4.6 Royalties (Fee to Author's organization) 64 5.4.7 Static sets. 66 5.4.8 Controls in sales orders. 67 5.4.9 Control of sales price. 68 5.4.10 Cancelling reservations. 68 5.4.11 Information on items in the sales line. 69 5.5 Service 69 5.5.1 Centralised Dispatch Board. 69 5.5.2 Counter readings over internet. 70 5.5.3 Mobile servicemen. 72 5.5.4 Calendars in SM contracts. 74 5.5.5 Functions. 74 5.5.6 Technician groups by competence. 76 5.5.7 Pre-configuration planning. 76 5.5.8 Service Pricelists. 77 5.5.9 Absence registration for technicians. 77 5.5.10 Extension of service order 78 5.6 Statistics 80 5.6.1 Standard reports to HQ.. 80 5.6.2 Manager screen. 84 5.6.3 SCA analysis. 85 5.7 Common Tasks 86 5.7.1 National language layer 86 5.8 Data conversion 86 6 Time Schedule of the Delivery.. 87 6.1 Target Solution Draft 87 6.2 Licence 87 6.3 Implementation 87 6.4 Akcceptation 87 6.5 Productive run 87 7 Project Risks.. 88 8 Conclusion.. 89 9 Appendices.. 90 9.1 Appendix 1 Target Solution Draft - Price Offer Uniform Solution 90 9.2 Appendix 2 Customer supplied documents 90 9.3 Appendix 3 Datasheets for barcode [DEL: reader :DEL] [INS: scanner :INS] 90 [INS: :INS] [INS: :INS] [INS: :INS] [INS: Na uvod :INS] [INS: : :INS] [INS: :INS] [INS: N :INS] [INS: eni prilis profesionalni nechat v dokumentu, ktery je posilan k pripominkovani :INS] [INS: zakaznikovi :INS] [INS: :INS] [INS: histori :INS] [INS: i :INS] [INS: vsech zmen a oprav :INS] [INS: . :INS] 1 Introduction 1.1 Target Solution Draft The document TargetSolution Draftt for Uniform solution of the Navision information system (hereinafter only the Target Solution Draft) is bound by contractual documents – Contract for Supply of SW Product – Creation of Uniform Solution. With approval by both contractual parties, the Target Solution Draft becomes an annex to the contract and is binding for the vendor and for the buyer. The main reason for the development of the Target Solution Draft is to have a tool to measure the subsequent work - implementation of a uniform information system solution (hereinafter only US). The form, range and content of the Target Solution Draft are subordinate to this key reason. The sense of the Target Solution Draft is not to compile a restructuralization plan for the company or even for a business plan. The Target Solution Draft is focused only on the area of information processing. The sense of the Target Solution Draft is not for compiling an exhaustive technical project with detailed description of the IS. With regard to the speed of change in the real world, such a technical IS project would be obsolete before it was even finished, never mind the subsequent realisation of the IS. 1.2 Terminology 1.2.1 SW product SW product - a complete set of computer programs, related documentation and data, designated for delivery to the customer. 1.2.2 SW item SW item - any identifiable part of the SW product in the course or final stages of development. 1.2.3 Target Solution Draft (TSD) Target Solution Draft (also Target Solution Concept) – A document completed at the beginning of the delivery, serving as a gauge for measuring the subsequent work against the aim established at the beginning of the work delivery. 1.2.4 Bespoke Module (BM) Custom module - a SW module created to order for a specific customer. 1.2.5 Local modification Local modification – a change in some of the objects of Navision conducted for a given locality (country, region). 1.2.6 Uniform solution (US) Uniform Solution (also Uniform Minolta Solution) – the following set of objects: · Navision - standard international version · Minolta Service customer module · Custom module realising additional buyer requirements (finance, etc.) · Custom module realising local legislative requirements. These sets of objects (or their subsets) cover uniform commercial procedures defined by the buyer in each individual country. 1.2.7 KMBS-LS KMBS-LS (Konica Minolta Business Solutions Local Subsidiary) – local subsidiary of the company Konica Minolta Business Solutions in the given locale (country, region). 1.2.8 LMBSP LMBSP (Local Microsoft Business Solutions Partner) – Microsoft Business Solutions Partner in the same locale (country, region) as the local subsidiary of the buyer and acting as a sub-contractor. 1.2.9 KMBS-V Konica Minolta Business Solutions Europe Vienna Office 1.2.10 FE FUTURE Engineering, a.s. 1.2.11 Navision Microsoft Business Solutions Navision 2 Description of current status Used as the source for a description of the current status as well as the solution proposal was the following: · Analysis of currently used Navision installations in 6 national representatives of Konica Minolta Business Solutions in Central and Eastern Europe. · Output from the project „Undelivered to service“ · Experience from providing support in 6 national representatives Konica Minolta Business Solutions in Central and Eastern Europe. · Implementation of Navision in Konica Minolta Business Solutions Czech. · Analysis of requirements in Konica Minolta Business Solutions Austria. 2.1 Company processes The following main company processes have been identified together for all national representatives of Konica Minolta in Central and Eastern Europe. For individual processes, defined inputs and outputs were compiled into the following table. [INS: Tabulka nehraje s obrazkem (Suply management, Vendor Management x Supplier Management, Post :INS] [INS: sales Support x After Sales Support :INS] [INS: :INS] [INS: Tvurce tabulky nema valnou paru o tom co je v KMBS dulezite jinak by jasne oddelil SM Contract management, Spoji :INS] [INS: l :INS] [INS: service s :INS] [INS: car stock management atd, tabulka v kap 5 nehraje s touto tabulkou, obrazek v kap 5 nehraje s nasledujici tabulkou. :INS] [INS: :INS] [INS: A vubec tady jste si to mohli usetrit :INS] [INS: :INS] Process Owner Key sub-processes Process release Process input Process output Marketing Management decision Market information, e.g. on individual customers (1) Marketing activity directed at customers (2) Market information, e.g. on individual customers (1) List in CRM, or new customer card (3) Market information, e.g. on individual customers (1) Company rules for assessing customer satisfaction (4) Diagnostics of requirements Customer requirement Customer requirements (5) Inquiry (6) Customer requirements (5) Sales order (7) Customer requirements (5) Complaint (8) Tender proceedings Inquiry Inquiry (6) Offer (9) Inquiry (6) Sales order (7) Contract formulation Offer Offer (9) Service agreement (10) Sales activity Sales order or service agreement Sales order (7) or service agreement (10) Sales invoice (11) Sales order (7) or service agreement (10) Delivery requirements (12) Sales order (7) or service agreement (10) Installation requirements (13) Sales order (7) or service agreement (10) Purchasing requirements (14) Storage Storage requirements Delivery requirements (12) Issued delivery note (16) Delivery requirements (12) Logistical requirements (17) Status of stock Status of stock Supply requirements (18) Requirements for items acceptance Acceptance of delivery note (21) Status of stock Logistics Logistical requirements Logistical requirements (17) Delivery note (19) Purchasing on order Purchasing requirements Purchasing requirements (14) Purchase order (20) Supply for stock Supply requirements Supply requirements (18) Purchase order (20) Supply management Management decision Company rules for supply management (23) Items cards (22) Vendor management Purchasing invoice Purchasing invoice (24) Requirements for payment of purchasing invoice (25) Cash-flow management Requirements on payment for purchasing invoices Requirements on payment for purchasing invoices (25) Payment order (26) Requirements on payment for purchasing invoices (25) Expenditures accounting document (27) Bank account statement (28) Bank account status Earnings accounting document (29) Bank account status Customer payment order (30) Bank account status Post-sales support Requirements for post-sales support Complaint (8) Complaint report (31) Installation requirements (13) Complaint report (31) Service Complaint report Complaint report (31) Service call report (32) Assessing satisfaction Management decision Company rules for assessing customer satisfaction (4) Requirements for assessing customer satisfaction (33) 2.2 Infrastructure Individual national representatives of Konica Minolta Business Solutions use individual technical facilities, which correspond to their own operation. 2.3 Data engine Currently, the distributed Navision Attain v. 3.01 W1 database is used. Native database is used on the Navision machine. Only BCZ uses a MS-SQL server[INS: a jinou verzi Navision :INS] [DEL: . :DEL] 2.4 User‘s readiness for implementation 2.4.1 Finance Buyers are informed of the total price of the work as well as payment conditions in advance. According to their own expression, the user has secured for this purpose sufficient financial resources and it prepared for the implementation. 2.4.2 Technology Technical facilities are at a sufficient level for realisation of the work. 2.4.3 Work organisation The user has appointed a managing committee for the project, a project lead and a realisation team. In its own opinion, the user is capable and willing to ensure realisation of the necessary organisational changes that will be required to perform in connection with the introduction of the new information system into operation. The user is prepared for the implementation from an organisational standpoint. 2.4.4 Personnel The user has designated a professional proficient team created by MNCC for the realisation of the project. From a personnel standpoint, the user is prepared for implementation. 2.5 Anticipated co-operation of the user during implementation 2.5.1 Rules for work realisation · The solution will be developed in one common database, which will serve as the "Master Copy" of the solution. · The solution will be primarily developed in English with regard to the national legislative specifics. · For the needs of the prototype, the vendor will prepare a special server with a working version of the solution, which will be located in the Konica Minolta network so that it will be accessible via a terminal connection from individual national representatives. · For each working version, a preliminary documentation will be placed on the special server enabling responsible testing by the buyer. · Acceptance of the solution will be conducted exclusively on the common database by members of the solution team of the buyer (MNCC). · Acceptance will be conducted at identified main company processes and key sub-processes arranged into the uniform solution. [INS: urcite ne podle obrazku a tabulky v teto kapitole. :INS] [INS: Navic akceptace je ve smlouve definovana jinak a jinak clenena :INS] · Local Microsoft Business Solutions partners in individual countries will conduct implementation in the national representatives. · The identified local requirements of individual national representatives will be delivered independently in the context of project support. 2.5.2 Co-operation during the compilation of the Target Solution Draft Co-operation of the user during the compilation of the Target Solution Draft has been provided by the members of the realisation team in the areas of gathering documents, their analysis and also the solution proposal. During the analyses, joint working meetings were organised and preliminary solution proposal discussed. 2.5.3 Co-operation during training [INS: :INS] [INS: Naprosto mi chybi jak budou pripravovani lokalni partneri na skoleni :INS] Part of the solution includes different trainings, which are designed for members of the realisation team of the user (from the standpoint of the information system). In order for training to take place always according to a previously approved methodology, the user must approve or agree with the vendor on the training methodology or any changes to it. Training is completed by verification of the knowledge of training participants (after eventual self-training). It is anticipated that training and verification of key employees of the user will continue independently according to the need to train process and temporary employees of the user (from the standpoint of the information system). 2.5.4 Co-operation during acceptance Co-operation of the user during acceptance rests in testing the IS according to identified company processes in various operational procedures and situations. The vendor always conducts the basic testing, but if only for providing trust, it is better if relevant employees of the user test the system themselves according to their own designs. 2.5.5 Co-operation during the compiling of Bespoke Modules Co-operation during the compiling of custom modules, in which some specific user problems are resolved, takes place at several levels on the basis of masked and functional prototypes. Co-operation of the user is critical in part during analysis of specific problems and in part during the proposal for a solution. 3 Solution Proposal 3.1 Basic unified licence Navision Functional Area Granule Yes/No Foundation Foundation Layer 1 1 Professional User a) 1 140 Unlimited Companies 5 010 Bank Account Management 3 780 Salespeople/Purchasers 1 400 User IDs & Passwords 1 410 Permissions 1 520 Windows NT (Intel) 5 200 Smart Tags 2 010 Microsoft SQL Server Option (does not include Microsoft SQL Server license) 2 020 Per Database License 0 1 540 IBM AIX 0 1 610 IBM iSeries 0 1 700 C/ODBC 0 1 750 C/OCX 0 1 800 C/FRONT 0 2 000 Client Monitor 0 1 150 Subsidiary (Each) 0 2 110 Navision 3.xx 1 Users Additional Professional Users a) Indiv. Additional Professional Users (1-5) Additional Professional Users (6-10) Additional Professional Users (11-25) Additional Professional Users (26-50) Additional Professional Users (51-150) Additional Professional Users (151+) Web Users (1) 0 Web Users (25) 0 Web Users (100) 0 General Ledger 3 010 Basic General Ledger 1 3 020 Allocation 0 3 030 Budgets 1 3 040 Account Schedules 1 3 050 Consolidation 0 3 060 Responsibility Centers 1 3 070 Basic XBRL 0 3 080 Change Log 0 Cash Manager 5 020 Check Writing 0 5 030 Bank Reconciliation 0 Sales & Receivables 3 260 Basic Receivables 1 3 270 Sales Invoicing 1 3 280 Sales order Management 1 3 290 Sales Invoice Discounts 0 3 310 Alternative Ship-to´s 1 3 320 Order Promising 0 3 340 Shipping Agents 0 3 350 Sales Return Order Management 1 3 360 Calendars 1 3 370 Sales Line Discounting 1 3 380 Sales Line Pricing 1 3 390 Sales Line - Campaign 0 CRM Marketing & Sales 5 110 Contact Management 0 5 120 Contact Classification 0 5 130 Campaign Management 0 5 140 Opportunity Management 0 5 150 Task Management 0 5 160 Interaction / Document Management 0 5 170 Contact Search 0 5 180 E-mail Logging for MS Exchange 0 5 190 Outlook Client Integration 0 CRM Service 5 911 Service Order Management 1 5 912 Service Price Management 1 5 921 Service Item Management 1 5 931 Service Contract Management 1 5 941 Planning & Dispatching 1 5 950 Job Scheduling 1 Purchases & Payables 3 510 Basic Payables 1 3 520 Purchase Invoicing 1 3 530 Purchase Order Management 1 3 540 Purchase Invoice Discounts 0 3 550 Requisition Management 1 3 560 Alternative Order Addresses 0 3 570 Purchase Return Order Management 1 3 580 Purchase Line Discounting 1 3 590 Purchase Line Pricing 0 3 770 Drop Shipments 0 Inventory 4 010 Basic Invertory 1 4 040 Multiple Locations 1 4 045 Stockkeeping Units 1 4 050 Alternative Vendors 1 4 060 Bills of Materials 1 4 100 Location Transfers 1 4 110 Item Substitutions 1 4 120 Item Cross References 0 4 130 Nonstock Items 0 4 140 Item Tracking 1 4 150 Item Charges 1 4 160 Cycle Counting 0 4 170 Bin 0 4 180 Put - Aways 0 4 190 Warehouse Receipts 0 4 200 Picks 0 4 210 Warehouse Shipments 0 4 220 Fixed Price Worksheets 0 Warehouse Management 4 620 Warehouse Management Systems 0 4 630 Internal Picks and Put-aways 0 4 640 Automated Data Capture System 0 4 660 Bin Setup 0 Resources 4 260 Basic Resources 1 4 270 Capacity Management 1 4 280 Multiple Sales Prices 1 4 290 Multiple Costs 1 Jobs 4 510 Basic Jobs 0 4 520 Budgets / Estimates 0 4 530 Phases / Tasks / Steps 0 Human Resources 5 760 Basic Human Resources 0 Fixed Assets 5 260 Basic Fixed Assets 1 5 270 Insurance 0 5 280 Maintenance 0 5 290 Allocations 1 5 300 Reclassifications 1 Application - Wide 3 760 Multiple Currencies 1 4 760 Basic Dimensions 1 4 020 Multiple Document Languages 1 4801..4999 Multiple Languages /each 1 3 800 Extended Text 1 4 770 Reason Codes 1 4 780 Advanced Dimensions 1 3 790 Intrastat 1 Basic Manufacturing 5 410 Production Orders 0 5 420 Production Bill of Materials 0 Agile Production 5 430 Version Management 0 5 805 Agile Production 0 Supply Planning 5 810 Basic Supply Planning 0 5 820 Demand Forecasting 0 Capacity Planning 6 010 Basic Capacity Planning 0 6 020 Machine Centers 0 6 030 Finite Loading 0 User Portal 6 710 User Portal 0 6 720 Base & Sales Activity Center 0 6 730 Product Design Activity Center 0 Commerce Gateway 99 008 510 Commerce Gateway Basic 0 99 008 520 CG - Unlimited number of partners 0 Commerce Portal 6 220 Commerce Portal 0 Navision Application Server 1 415 Application Server (1) 0 Design 7 110 Report & Dataport Designer 1 7 120 Form Designer 1 7 130 Table Designer 1 7 200 Application Builder 0 7 300 Solution Developer 0 Application Objects 7 730 Table (each) 3 8 200 Table (10) 3 7 800 Form (each) 0 8 300 Form (100) 1 7 900 Report (each) 35 8 400 Report (100) 1 8 000 Dataport (each) 9 8 500 Dataport (100) 0 8 100 Codeunits (each) 22 8 600 Codeunits (100) 0 Needed granules for each KMBS-LS are in appendix 1. 3.2 Minolta Service Functionality Standard functionality of the Minolta Service Functionality will be transferred to the actual Navision version as part of the solution. Local enhancements will be handled separately. [INS: Za prve tam mame funkce ve smlouvach, za druhe je prevod lokalnich enhacements casti projektu a tudiz nemuze zde byt odbyt holou vetou. :INS] 3.3 Data engine Uniform solution will be based on the same data engine as the actual system eg. Native Microsoft Business Solutions Navision database or Microsoft SQL Server 2000. 4 Future Target methodology[INS: celou kapitolu 4 ven a popsat dle kontraktu, skoleni nepotrebujeme uz jsme jej dostali pri minulem solution draftu :INS] [INS: duvody vyplyvaji z mych vzteklych poznamek k textu :INS] The methodology of Future Target contains: · A diagram and description of individual realisation processes · Tools for performing individual processes (forms, templates, sample solutions, calculations, etc.) · Specification of necessary infrastructure (competent employees, technical equipment, etc.). 4.1 Basic concepts Process is a group of mutually related or mutually applied activities that transform input into output. Project is a unique process comprised of a series of coordinated and guided activities, with data initiation and completion, performed to achieve a target, which corresponds to the specific requirements including limiting the given time, costs and resources. Software (SW) product is a complete set of computer programs, procedures, related documentation and data designated for delivery to the customer. SW item is any identifiable part of a SW product during the course or final stage of development. Information system is an integrated whole, which consists of a SW product and relevant technological bases necessary for its operation and which provides the capability to satisfy the established needs or goal. Productive operation of the system – such an operation, when the information system is already loaded with live data and the customer uses it for standard work. 4.2 Project management From the standpoint of the company FUTURE Engineering, delivery of the information system to the customer is considered to be the project. During project management for delivery of IS, FUTURE Engineering differentiates three phases of each project: · Pre-sales phase (up to the signing of the contract) · Implementation phase (from the signing of the contract to initiating productive operation of the IS) · Support phase (from initiation of productive operation). 4.3 Contractual relations The business relationship between the vendor and the customer – buyer is defined by a SW product delivery and support contract. The subject of the[INS: !!!?? :INS] contract is delivery of the SW product, which consists of the following SW items:[INS: mame smlouvu, zadny TSD ji nebude menit :INS] 1. Target Solution Draft 2. Navision - licence 3. Navision - licence for the FUTURE application modules 4. Parametrisation 5. Data conversion 6. Training 7. Bespoke modules 8. Acceptance 9. Project management 10.Process reorganisation 11.On site assistance The subject of the contract also includes SW product support, which consists of the following SW items:[INS: prosim pekne kdo to psal ze nevi ze mama maintenance smlouvu?? :INS] 1. Service (warranty and post-warranty) 2. Maintenance (including providing new versions) 3. Further development of the SW product The basic principle of contractual relations is formulated as: „Fixed price = fixed package of goods and services“ Implementation of the information system (i.e. delivery of SW product) begins with the signing of the SW product delivery contract between the vendor and the buyer and ends with the delivery of the complete system (i.e. the SW product) into productive operation. The warranty period for the SW product delivery also begins with this transfer. The SW product delivery and support contract shall be concluded for a definite time period – up to the period when the customer ceases to use of the SW product. Throughout the entire period, the customer is authorised to make use of vendor SW product support services (see below). Any of the contractual parties may withdraw from the contract in the case of a breach by the second contractual party. Among others in the contract, the vendor and the customer are also obligated to establish an adequate and suitable infrastructure (space, equipment, technology) and to allot adequate and suitable resources (the capacity of competent employees, designation of responsibilities). 4.4 Delivered documentation SW product shall be delivered in a single copy with Czech [INS: !! :INS] documentation: · Context on-line (help) Navision · User’s Guide – FUTURE application modules · Configuration management of SW product · Working procedure for installation and activation of the SW product · Training methodology for SW product · Validation methodology for SW product · Requirements form (service / further development). Programmer documentation is not a subject of the delivery. If [INS: ???? :INS] part of the documentation delivery is the Application Designer‘s Guide, which will be delivered in English. The text of the Application Designer Help Module is also in English. 4.5 Delivery of SW product [INS: Sem patri jako zasada ze se zachovaji lokalni bubliny jak uz jsem psal :INS] 4.5.1 Target Solution Draft During the compilation of the offer, the vendor will not know precisely all customer requirements for the information system. Therefore, implementation of the system begins with the compilation of the Target Solution Draft, the aim of which is primarily to formulate all customer requirements and to propose their solution. The Target Solution Draft is usually comprised of these main chapters: · Description of current status · Description of target status · Description of the solution · Time schedule (including metrics scanning time gauge) [INS: To sedi tak proc toto skoleni v TSD? :INS] After agreeing to the Target Solution Draft, the customer is responsible that if the vendor performs the solution of the information system in the manner described in the Target Solution Draft, then the delivery has been fulfilled. The requirements specified by the customer after approval of the Target Solution Draft could require overtime. Processing of the Target Solution Draft begins with an introductory orientation seminar. The goal of this seminar is: · Mutual acquaintance of employees · Agreement on communication methods · Reintroduction of the system and its terminology to employees of the customer’s realisation team (from the selection proceedings through the standard course of the defined time period) · Initiation of processing the Target Solution Draft. 4.5.2 Navision – licence Navision is a modular system, which can be easily expanded at any time by additional modules without the necessity of reconfiguring the database or changing saved data. The precise list of modules is shown in the price quote. 4.5.3 Navision – licence for FUTURE application modules Application modules from FUTURE (or a third party) appear to the user the same as standard Navision modules. The delivered SW product can easily be expanded at any time by additional modules without the necessity of reconfiguring the database or changing saved data. The precise list of modules is shown in the price quote. 4.5.4 Parametrisation of the system Navision is a flexible and open system. As a rule, adaptation of the system for specific customers is not conducted by programming but by setting system parameters. Parametrisation of the SW product is represented by these activities: · Setting modules or functional areas · - Pre-allocation · - Numerical order · - Access rights · - ….. · Setting windows · Change cover / display field · Change formats for displaying numbers. Of the standard initial standard settings for access rights, the following groups of users are considered for setting rights: · Accountant · Main accountant · Stock keeper · Merchant · Production dispatcher · Manager. A change in the program code is not part of SW product parameterisation. The precise conditions for system parameterisation are shown as part of the price quote. 4.5.5 Data conversion [INS: Ja bych tu radeji videl vyjadreni F :INS] [INS: E :INS] [INS: , ze provede konverzi dat z jednoho systemu Navision do druheho :INS] [INS: Navision systemu ( nakonec jak stary tak novy system duverne znate.) :INS] [INS: :INS] [INS: :INS] For initial productive operation of the Navision system, it is necessary to load the system with data (from the preceding system of the customer – if such data exists[INS: to se mi jen zda :INS] ). Here, it is normal to speak of data migration, which is the transfer of data from a source IS to the target IS. Data migration consists of data that will: - never be migrated to the target IS - be manually migrated to the target IS - be automatically migrated to the target IS – i.e. data conversion (with the help of the program). As a rule,[INS: !! :INS] data conversions (imports in .xls format) into Navision are as follows (if the purchased Navision licence contains the appropriate modules): · Customer catalogue · Vendor catalogue · Contact catalogue · Items catalogue · Stock location catalogue · Resources catalogue · Project catalogue · Human resources catalogue · Asset catalogue · Service contract catalogue · Service subject catalogue · Production piece list catalogue · Technological procedures catalogue · Machinery and operations centres catalogue · Production orders catalogue · Service orders catalogue · Input balance sheet (account balances) · Accounting plan · Input items inventory · Vendor balance · Customer balance Precise conditions for data conversion are shown as part of the price quote. [INS: Zato zde chybi prototyping :INS] 4.5.6 Training Training of customer employees is an inseparable part of the delivery and the vendor is to implement the training method. The training methodology originates from the solution of standard sample examples or from some specific examples of solutions at the customer. Prior to initiating the training, the vendor submits the training methodology to the customer for approval. Training of customer employees is completed by a verification of their knowledge acquired during the course of training. Therefore, training is conditioned and its uninterrupted course is ensured (buyer employees may not be interrupted by actual operational problems). Training conducted by the vendor is of three types (from the standpoint of the type of work with the system): · Training for key employees of the customer · Training for process employees of the customer · Training for occasional employees of the customer. Precise conditions for training are shown as part of the price quote. 4.5.7 Bespoke modules Bespoke modules are created especially upon a specific customer’s order. These are customers whose problem is entirely covered by the Navision standard licence and other customers who need several order modules.[INS: Up :INS] [INS: l :INS] [INS: ne zbytecn :INS] [INS: y :INS] [INS: o :INS] [INS: d :INS] [INS: stavec :INS] [INS: , :INS] [INS: my prece nebudujemne novy s :INS] [INS: y :INS] [INS: stem na zelene louce. :INS] [INS: Nakonec definice,ze se jedna o vyvoj spolecneho reseni na yaklade jiz bezicich systemu je v uvodu tohoto dokumento uvedeno :INS] [INS: . :INS] The eventual need, functionality and price of the custom modules are established definitively in the Target Solution Draft. With regard to the fact that custom modules are designed only for a single customer, costs for their creation and maintenance are relatively high in comparison with the standard modules. 4.5.8 Acceptance[INS: mame popsanou v smlouve a to uplne jinak :INS] The acceptance procedure contains: · Transfer of validation methodology by vendor to customer for approval · Approval of validation methodology by both parties · Control of vendor and buyer preparedness for validation · Performance of validation - Verification of implemented functionality - Verification of environment is operation environment - No special testing tools are used - No special testing SW is used - Marginal or operational tests are not performed · Description of submitted protocols. By verifying individual SW items or validation of the SW product and by signing the transfer protocol, the acceptance procedure is completed. 4.5.9 Project proceedings [INS: Neodpovida smlouve :INS] [INS: :INS] Project (realisation) teams and their leads will be designated by the vendor and the customer to resolve the problems related with delivery and support of the SW product. The leads of the project team (i.e. project leads) are persons authorised and responsible for management and coordination of the project and for all transfers and acceptances according to the contract. The basic line of communication between the vendor and the buyer is established between project leads of both contractual parties. The vendor is then obligated to acquire a written record from the meetings of the leads of the realisation teams. The terms, tasks or other arrangements agreed upon by both project leads and shown in the relevant record from meetings, are binding for the customer and the vendor. The managing committee of the project will decide on basic questions of the project delivery and SW product support and will consist of: · The statutory representative of the buyer · The project lead of the buyer · The statutory representative of the vendor · The project lead of the vendor. The vendor is also obligated to arrange a written record of the meetings of the managing committee. Both project leads will resolve requirements for changes to the SW Project after approval of the Target Solution Draft and if they cannot agree, the managing committee of the project will direct this resolution. 4.5.10 Process reorganisation As a rule, the transition from a single information system to another information also requires reorganisation of some operational processes within the enterprise. The customer may conduct this activity without the aid of the vendor or, to the contrary, the customer may request this activity from the vendor. In such a case, the customer submits its request to the vendor for the process reorganisation and the relevant documents (organisation chart, work performance etc.). On the basis of its knowledge and experience and on the basis of the accepted request of the customer, the vendor then will compile a Process Reorganisation Concept and submit it to the customer. Note Generally, FUTURE Engineering does not recommend process reorganisation as part of the SW product delivery but as part of the completed quality management system according to ISO 9001:2000. 4.5.11 On-site assistance [INS: Zbytecny odstavec, implementace vyzaduje pritomnost dodavatele. :INS] [INS: :INS] If the customer is interested, the vendor may assist the customer at its operation site. In the context of these services, employees of the vendor are present directly at the worksites of the customer, where consultations are provided to customer employees when resolving its operational problems. On-site assistance is provided on the basis of orders and paid at hourly rates. The SW item On-Site Assistance is not an obligatory item and as a rule the vendor does not provide this service. It has significance only for those customers whose employees have not devoted proper attention to training or were not prepared for the initiation of productive operation. 4.6 Transition method from the old system to the new system The methodology of Future Target does not anticipate parallel operation of an old and a new system, but on the contrary calculates with the removal of the old system by a designated date. Subsequently, data from the old system are converted into the new system (with the help of already tested programs for data conversion) and productive operation of the new system is initiated. For the most part, this operation lasts only a few hours. The old system is then usually removed on the last day of the designated month and the first day of the month following month, the new system is released. This is, of course, already fully prepared to operate, tested, and the necessary live data loaded, with training and testing of users. Transition from the old system to the new one may be divided into several stages at extensive systems. 4.7 Initiation into productive operation The best term for initiating productive operation from the standpoint of benefits is designated by the 80 / 20 Parete rule. This means to not wait until the absolute completion of the final version of the SW product, but to begin already when the operation of the system will bring significant benefits. 4.8 SW product support[INS: mame smlouvu :INS] 4.8.1 Warranty and post-warranty service The warranty period is established at 12 months from the date the SW product is brought into productive operation. In this period, the vendor will remove, free of charge, any defects subject to performance by a customer complaint (if such). After completion of the warranty period, the vendor will request compensation for resolution of possible defects subject to performance according to its actual price list. The warranty period for the new version (upgrade) is established at 3 months (90 days) from the date of delivery of the new version. The customer shall submit its complaint to the vendor for removal of defects by means of its authorised employee in writing, by fax or electronic mail within 5 business days from the determination of the breakdown. Defect – an incorrect command, process or definition of data in the computer program. A defect is the cause of a failure. Failure – termination of the capability of the product to perform the required function or its inability to complete it in the context of previously established limits. A failure is the manifestation of a defect. Failure of SW product – The SW product demonstrates behaviour different than the behaviour described in the delivered documentation or demonstrably fails to fulfil its functions during standard service and use. Common failure – A failure of the SW product complicating work at least for one SW product user and hampers its full value use. The vendor is obligated to initiate the removal of the relevant defect in the business day (8 a.m. to 4 p.m.) within 48 hours after acceptance of the request from the customer for removal of the defect. Serious failure – A failure of the SW product hampering the work of more than one group of SW product users (with the same rights) and limiting business activity of the buyer. The vendor is obligated to remove the relevant defect (also by alternative solution) no later than within 5 business days. Critical failure – A failure of the SW product hampering the work of all SW product users and endangering the business activity of the buyer. The vendor is obligated to remove the relevant defect (also by an alternative solution) no later than within 3 business days. The warranty and post-warranty service for the SW product may be conducted under different conditions if required by the customer and if these are contractually embodied conditions. 4.8.2 Maintenance (including providing new versions) Maintenance (i.e. providing new versions and all inclusive service to the customer) begins on the first day following generation of the Navision licence. The vendor is responsible for the actual form of the SW product in its actual form will correspond to the legal regulations valid in the territory of the Czech Republic throughout the duration of the contract between the customer and the vendor and that it will satisfy requirements established by these legal regulations. The vendor and also its sub-contractors (particularly Microsoft) are bound to work on improvement and perfection (revision, new version) of the SW product according to their own judgment. The customer is authorised to acquire a new version of the SW product only in the extent for which it has a valid and effective licence. Another part of maintenance: · Hot-line – professional consultation for the delivered SW product (implemented functionality) provided by the vendor immediately upon the request of the buyer (e-mail or telephone) to the extent of the solution within 15 minutes. This service is available to authorised employees of the customer during business hours from 8 a.m. to 4 p.m. to the extent of 10 hours per month. · Audit of SW product – systematic, independent and documented process for the purpose of judging whether the SW product is in compliance with the requirements for functionality, applicability, effectiveness, failure free, and maintainable for the SW product. The vendor will conduct this at the customer once annually to the extent of 4 – 8 hours. · Workshop – evaluation of conclusions from the audit, corrections and preventative measures, information of the vendor about new modules, documentation, services, and commercial conditions. The vendor will conduct this at the customer once annually to the extent of 4 – 8 hours. Maintenance of the SW product may take place also under other conditions, if the customer requires it and if its conditions are embodied in the contract. 4.8.3 Further SW product development All services that are not part of maintenance, particularly creation of program modules, training, consultation and advising, etc., provided by the vendor for payment. If the customer duly orders these modules or services, the vendor will provide appropriate fulfilment according to its actual commercial conditions. During fulfilment of further SW product development, the vendor has these additional responsibilities: · Proposal for further SW product development will be submitted by the project lead of the vendor always in documented form (electronic mail, fax or in writing). · The vendor is obligated to begin preparations of a proposal within 48 hours. The proposal must be submitted to the buyer no later than within 20 business days. · The proposal will always contain price, payment, deadlines or delivery conditions and, with regard to the demand, a brief description of the proposed solution (functionality). Additional SW product development may take place also under different conditions, if required by the customer and if these conditions are embodied in the contract. 4.9 From expectation to assessment of IS benefits Future Target methodology, with the help of an iterative feedback approach, determines that the primary expectations of the customer, sometimes hardly comprehensible, they are gradually compiled, approved and subsequently implemented. Then the vendor and also the customer will not release apparent specific benefits, which were planned and which have been achieved. It is simply to say that there are no benefits that need not be. [INS: Atd atd :INS] 4.10 Measuring IS benefits With the Future Target methodology, the customer receives a tool by which it may assess the benefits generated or which should be generated through the introduction of the information system. In this way, it is possible to anticipate situations when the vendor believes that it has satisfied the order but the customer has not recorded any positive change in comparison with the preceding status. For assessing benefits, it is also possible to incorporated the compensation part of the contract: – Planned measurable benefits were achieved => vendor receives price bonus – Planned measurable benefits were not achieved => vendor is stripped of the retainer price. For measuring benefits for introducing the IS, a gauge is used and the customer will rank individual gauges according to their importance. Gauge values will be measured prior to the beginning of IS implementation and then after initiation of productive operation. An example of the established process perspective may appear, for example, as follows: 4.11 Price[INS: mame smlouvu :INS] The negotiated price of the SW product is a fixed price and is shown in the appendix, including calculations. Prices for Navision modules are prices firmly established for the Czech Republic[DEL: . :DEL] [INS: !!!!!!!! :INS] Prices for services are established on the basis of a budget, which originates from the experience of the vendor with similar implementations. Columns marked Data Conversion, Training, Parametrisation, and Acceptance always set the number of hours necessary for performing appropriate services at given module. Four more columns marked the same are shown in CZK [INS: !!! :INS] (number of hours * hourly rate). On the basis of this budget, prices for individual SW items are calculated, which are shown in the final section of the price quote. The price for SW product maintenance equals 15% of the prices of licences annually and is shown in the appendix. 4.12 Payment conditions [INS: :INS] [INS: Vubec neodpocida dohodnutym podminkam ve smlouve :INS] [INS: . :INS] [INS: :INS] Payment conditions are established neutrally for the customer as well as the vendor. The vendor invoices the customer for a deposit in the amount of 50% of each SW item. The deposit invoice is payable always on the day of initial planned fulfilment of the given SW item. The vendor will issue a final invoice for each SW item after submission of the given SW item to the customer, whereas the customer always has the possibility to withhold the last part of payment in case the vendor fails to fulfil the delivery. The exception to these payment conditions is payment for the Navision licence. Delivery of this licence is irreversible and therefore the vendor requires payment in advance. The maintenance fee will always be invoiced by the vendor for an entire year in advance. 4.13 Solution time schedule [INS: Existuje clanek 4.3 ve smlouve :INS] [INS: :INS] During the conclusion of contractual relations between the vendor and the customer, these deadlines will be established: · SW product delivery and support contract between the customer and the vendor will be signed no later than……………... · The compiled Target Solution Draft will be submitted to the customer for approval no later than…………….. · Productive operation of the SW product from the vendor at the customer will begin no later than ………… The works deadlines will be established in the Target Solution Draft, which is subject to bilateral approval. 4.14 Assessing customer satisfaction The goal of each serious vendor is to have satisfied customers. This is possible to achieve only by continuous improvement of quality products, which the vendor provides to customers. For determining feedback, the company FUTURE Engineering systematically collects information about customer satisfaction in part by personal interviews and in part by standardised forms: · Customer satisfaction with commercial discussions · Customer satisfaction with implementation · Customer satisfaction with training · Customer satisfaction with support. The collected information is systematically assessed by vendor management and used for further improvement. 5 Uniform Solution of company information system For the Uniform Solution common processes for all KMBS-LS´s. Locale specific processes in different KMBS-LS are hold by in the analysis and will be delivered under the Support Contract. In the following diagram Uniform Company Processes entering in the Uniform Solution are shown. [INS: Vseobecne: zachovame lokalni bublin :INS] [INS: Je zalozeno na 3.7 nebo vyssim :INS] [INS: Obrazek :INS] [INS: si muzeme usetrit :INS] [INS: neb obsahuje jine hlavni procesy ne 1 sloupec tabulky kde se nazyva Area :INS] [INS: :INS] [INS: Akceptace dle smlouvy a do terminovaho planu :INS] [INS: Popsat jak zarucime kompetentni prosloleni lokalnich NSC :INS] [INS: Nebude nasazeno jako NEW SYSTEM data musi byt zachovana a prevedena :INS] [INS: 5.8 :INS] [INS: :INS] [INS: :INS] [INS: Postupy :INS] [INS: jak budou vyuzivany funkce, jak budou definovany, fakturovany, vyrovnavany jsou velmi strucne :INS] [INS: :INS] Choosen company processes described in the Uniform Solution are divided in following areas. Area Task Bookkeeping Bank Connection Unified Set of Dimensions and Set up Leasing and Rent Extended Application of Payments Planning & Budgeting Budgeting of units as a base for sales planning Purchase and Logistics Dynamic Purchase Orders ELC interface Branch stores and direct deliveries into [DEL: auto-store :DEL] [INS: car-stock :INS] s Centralized Item numbering Consignation stocks Limited display of acquisition and stock prices Special transfer prices Bar code use Report on Slow Moving Items Sales Extended pricing with customer oriented discounts Configurator External CRM and mobile salesman Direct connection to service (configurations sold) e-Business Royalties (Fee to Author's organization) Static sets Controls in sales orders Control of sales price Cancelling reservations Information on items in the sales line Service Centralised Dispatch Board Counter readings over internet Mobile servicemen Calendars in SM contracts Functions Technician groups by competence Pre-configuration planning Service Pricelists Absence registration for technicians Extension of service order Statistics Standard reports to HQ Manager screen SCA analysis Common tasks National language layer 5.1 Bookkeeping 5.1.1 Bank Connection Description of Current State: Transactions concerning bank statements are posted to Navision using standard functionality of Payment and Cash Received Journals. Uniform Solution: In 3.70 the same functionality remains. Two additional fields have been added: IBAN and SWIFT codes for the international bank identifier codes. Uniform Solution does not describe a solution for automated connection with banks (import of bank statements) due to country and bank specific data structure. Nevertheless an option exists for a local NSC to deliver the solution for automatic bank connection. The solution would also include automated matching of payments with invoices. 5.1.2 Unified Set of Dimensions and Set up Description of Current State: Individual KMBS-LS’s use posting groups which more or less differ among the individual KM’s. Global dimensions are the same for all KMBS-LS’s, but other sets of dimensions are often specific for each KM. Uniform Solution: FE suggests that definition and set up of posting groups, general posting groups, VAT posting groups, etc. are to be used according to specific needs of individual local Konica Minolta subsidiaries. Suggested General product posting groups, detailed values are to be specified by individual KMBS-LS’s: General Product Posting Groups: BEO-COP BEO Copiers BEO-COP-L BEO Copiers Leasing/Rent BEO-COP-MF BEO Copiers - Fixed Assets BEO-COP-P BEO Copiers Penalties BEO-COP-S BEO Copiers Services BEO-COP-SM BEO Copiers S+M BEO-FAX BEO Fax BEO-FAX-L BEO Fax Leasing/ Rent BEO-FAX-MF BEO Fax Fixed Assets BEO-FAX-P BEO Fax Penalties BEO-FAX-S BEO Fax Services BEO-FAX-SM BEO Fax S+M BEO-LBP BEO Printers BEO-LBP-L BEO Printers Leasing/Rent BEO-LBP-MF BEO Printers Fixed Assets BEO-LBP-P BEO Printers Penalties BEO-LBP-S BEO Printers Services BEO-LBP-SM BEO Printers S+M BEO-MAN BEO Manual CAMERA Cameras CREDITNOTE Credit Notes METER Meters OTHER Others TRANSP Transport For dimensions the following are suggested: Dimensions DEPARTMENT Sales, Logistics, HR, IT, etc. BRANCH Country branches CONTRACT Contracts in the service module AUTO Company cars PURCHASER Purchaser Name SALESPERSON Sales Person VENDORGROUP Vendor Group CAMPAIGN Marketing and sales campaigns CUSTOMERGROUP Customer Group LEASCONTRACT Leasing Contract EMPLOYEE Employee Care should be taken in assigning dimensions and dimension values to G/L accounts, Salesperson / Purchaser, etc., whether code is mandatory, etc. 5.1.3 Leasing and Rent Description of Current State: Leasing contracts are used both for purchase and sale, in some KM’s they are used in a very limited extent, in some quite a vast number of leasing contracts exist. For purchases of fixed assets on lease, payment terms are at a fixed monthly fee and fixed date in a month. For goods sold on lease, each month on a fixed date a batch of invoices is issued in a form required by the law. The accounting treatment of finance lease is dependant on local legislation. In some countries the monthly finance lease amount is divided into partial repayment of a fixed amount owed and into interest on the owed amount. In some countries finance lease treatment is similar to operating lease. For lease contracts in foreign currency, exchange rate gain/loss is calculated for each line. Posting is done either directly to the relevant G/L account or by using resources. Uniform Solution: In the Purchases & Payables (Sales & Receivables) Setup a new option will be added for Lease Contracts. By selecting this option a Lease Contract Card will be displayed, with the usual NA functionalities of displaying a list (F5), filtering, searching, etc. The Lease Contract Card will contain the following fields: o number and name of vendor (customer); o starting and ending date of contract; o purchase (sales) price of good; o currency of contract; currency of invoices; o first amount to be repaid plus date; type of account and account number to be posted to; o second amount to be repaid plus date; type of account and account number to be posted to; o regular amount to be repaid plus date of first regular payment plus period (monthly, two monthly, quarterly, 6 monthly); type of account and account number to be posted to; o last amount to be repaid plus date; type of account and account number to be posted to; In Purchases & Payables (Sales & Receivables) Periodic Activities a new option will be added for generating of invoices. By selecting Generate Lease Invoices, General tab, entering filters for contract number, customer number, dates, etc. will enable to limit the batch to only a group of lease contracts. On the Invoice tab the invoice number series is entered, this information will be necessary to enter only once, the program will keep the information about the number series for next time the invoice generation batch is selected. Press OK to proceed to invoice generation. 5.1.4 Extended Application of Payments Description of Current State: Currently a payment is matched with invoice / credit memo only in case the amounts are exactly the same. Uniform Solution: Payment Tolerance Amount Finance Setup · Payment [DEL: deviation :DEL] [INS: Tolerance :INS] % · Max. payment Tolerance Amount The setup defines conditions under which a [INS: payment :INS] tolerance amount is allowed. Cash paid to vendors or cash received from customers is fully applied within the given range of tolerance amount. Extended application functionality A batch for applying open items will find open customer (vendor) ledger entries and will attach an application sign to appropriate ledger entries. The batch will find the relevant customer (vendor) ledger entries according to Finance Setup and according to Navision rules for applying ledger entries. The batch will enable the following: · print a report which will show the suggested applications[DEL: ; :DEL] · application mode, i.e. a printout form with suggested applications and with an option to modify suggested applications and post them. 5.2 Planning & Budgeting 5.2.1 Budgeting of units as a base for sales planning Uniform Solution: The function of budgets is extended by an option enabling [DEL: generation :DEL] [INS: creating :INS] [INS: budgets :INS] of items [DEL: budgets based on a number of pieces :DEL] [INS: in units :INS] . Simultaneously[INS: with the budget in units :INS] [DEL: , :DEL] [INS: :INS] [DEL: the :DEL] [INS: a :INS] financial budget[INS: is automatically generated :INS] for [DEL: financial :DEL] [INS: G :INS] [INS: /L :INS] [INS: :INS] accounts for [DEL: goods :DEL] sales (accounts for [DEL: goods :DEL] sales [DEL: returns :DEL] and cost[DEL: s :DEL] o[INS: f :INS] [DEL: n :DEL] goods sold) and purchase[INS: s :INS] (increase on the [DEL: financial :DEL] [INS: G/L :INS] account of [DEL: the store :DEL] [INS: inventory :INS] [DEL: ) is automatically generated together with the goods budget based on a number of pieces :DEL] . ITEM[DEL: S :DEL] BUDGET The budget is displayed in a separate sheet by choosing the respective button in the [DEL: Finances :DEL] [INS: General Ledger :INS] menu. The filter Budget Source – Items is automatically selected. The item[DEL: s :DEL] budget allows: · Budget of unstored items · Budget of items [DEL: counted by pieces :DEL] [INS: in units :INS] o purchase budget o sales budget o balance of item[DEL: s :DEL] budget · automatic generation of the particular financial budget Description of Item[DEL: s :DEL] Budget functions. [DEL: Sheet adjustment :DEL] [INS: Set up :INS] . · Source ([DEL: Financial :DEL] [INS: G/L :INS] account, Items) · Type of items movement ( -, Purchase, Sales) · General post[INS: ing :INS] group filter · [DEL: Items :DEL] [INS: Inventory :INS] post[INS: ing :INS] group filter · Budget[INS: ed :INS] items filter · [DEL: Return :DEL] [INS: Sales :INS] account · Account of costs o[INS: f :INS] [DEL: n :DEL] goods sold · Purchase[INS: s :INS] account Source defining the source of budget data. The [INS: default :INS] value – [DEL: Goods :DEL] [INS: Items :INS] – is [DEL: adjusted :DEL] [INS: selected :INS] . Type of items movement · Empty - balance of items budget · Purchase - item[DEL: s :DEL] [DEL: purchase :DEL] budget[INS: for purchases :INS] · Sales - item[DEL: s :DEL] [DEL: sales :DEL] budget[INS: for sales :INS] [DEL: A kind :DEL] [INS: The Type :INS] of items movement must be [DEL: adjusted :DEL] [INS: set up :INS] prior to entering the budget[INS: ed values :INS] . [INS: The item budget for purchases :INS] [DEL: Items purchase budget :DEL] and [INS: the item budget for sales :INS] [DEL: Items sales budget :DEL] are entered separately. [INS: The item budget for purchases :INS] [DEL: Items purchase budget :DEL] is entered by the plus value; [INS: the item budget for sales :INS] [DEL: Items sales budget :DEL] is entered by the minus value. When Budget Type – Empty is [DEL: adjusted :DEL] [INS: selected :INS] , [DEL: a :DEL] [INS: it is not possible to :INS] [INS: enter any :INS] item[DEL: s :DEL] budget [INS: values :INS] [DEL: cannot be entered :DEL] . This option displays [INS: a sales/purchases :INS] item[DEL: s :DEL] balance. The balance of item[DEL: s :DEL] budget is [DEL: a :DEL] [INS: the :INS] sum of items purchase budget and items sales budget. General post[INS: ing :INS] group filter It displays only items [DEL: with :DEL] [INS: having :INS] the General post[INS: ing :INS] group selected. Simultaneously, it identifies [DEL: a financial :DEL] [INS: the G/L :INS] account for [DEL: generating a :DEL] [INS: creating the :INS] financial budget [INS: value :INS] [DEL: in :DEL] [INS: according to :INS] the [DEL: adjustment of :DEL] [INS: G :INS] [DEL: g :DEL] eneral [DEL: invoicing :DEL] [INS: posting setup :INS] . [DEL: Items :DEL] [INS: Inventory :INS] post[INS: ing :INS] group filter It displays only items with the post[INS: ing :INS] group selected. Simultaneously, it [INS: identifies the G/L account for creating the financial budget valueaccording to the General posting setup. :INS] [DEL: identifies a financial account for generating a financial budget in the adjustment of general invoicing. :DEL] Budget[INS: ed :INS] items filter Item[DEL: s :DEL] card, the field Budget[INS: ed :INS] , Yes/No. [DEL: It :DEL] [INS: In the item budget :INS] [DEL: displays :DEL] only items marked with the value Budget –Yes[INS: are displayed :INS] . It serves to reduce[INS: the number of :INS] items [DEL: of the :DEL] [INS: displayed displayed in :INS] item[DEL: s :DEL] budgete[DEL: d :DEL] . [DEL: Return :DEL] [INS: Sales :INS] account Automatically [DEL: supplemented :DEL] [INS: entered :INS] from [INS: General posting setup :INS] [DEL: Adjustment of general invoicing :DEL] , Sales account. Account of costs on goods sold [INS: Automatically entered from General posting setup :INS] [DEL: Automatically supplemented from Adjustment of general invoicing :DEL] , [INS: Costs of goods sold a :INS] [DEL: A :DEL] ccount of [DEL: costs on goods sold :DEL] Purchase account [INS: Automatically entered from General posting setup :INS] [DEL: Automatically supplemented from Adjustment of general invoicing :DEL] , Purchase account Unit prices In order to generate financial budgets corresponding to items budgets in [DEL: pieces :DEL] [INS: units :INS] , unit prices for the items budgeted must be entered. Unit prices are entered in[DEL: to :DEL] the budget line. A[DEL: n :DEL] [INS: financial budget :INS] [DEL: item :DEL] [INS: amount :INS] [DEL: of financial budget is :DEL] [INS: equals :INS] unit price x quantity. · Purchase price - purchase · [DEL: Selling :DEL] [INS: Sales :INS] price - sales Unit prices may be [DEL: adjusted :DEL] [INS: set up :INS] by the batch Update [DEL: of :DEL] unit prices. This batch uses current [DEL: adjustment :DEL] [INS: setup :INS] from the Item[DEL: s :DEL] card. Purchase price = Acquisition price Selling price = Unit price. FINANCIAL BUDGET [INS: The :INS] [DEL: I :DEL] [INS: i :INS] tem[DEL: s :DEL] budget will automatically generate the respective financial budget for purchase account, sales account and [INS: costs of goods sold :INS] account[DEL: of costs on goods sold :DEL] . Financial budget is displayed in a separate sheet. The financial budget is [DEL: displayed :DEL] [INS: created :INS] together with the items budget line when the [DEL: amount :DEL] [INS: quantity :INS] in [INS: the :INS] item[DEL: s :DEL] budget is entered, the names of budgets are identical. In [DEL: the :DEL] case of changes in [DEL: items budget :DEL] [INS: units :INS] in the Ite[DEL: m :DEL] s budget sheet, a connection between the item[DEL: s :DEL] budget and [DEL: a :DEL] [INS: the :INS] particular financial budget is ensured. A change in the items budget will change automatically the respective financial budget. A change in the financial budget associated with the item[DEL: s :DEL] budget [DEL: does :DEL] [INS: will :INS] not change the item[DEL: s :DEL] budget. In [DEL: the :DEL] case of [INS: an attempt to :INS] change[DEL: s :DEL] [DEL: in a :DEL] [INS: the amount of a :INS] financial account associated with the item[DEL: s :DEL] budget, the user will be notified about the existing item[DEL: s :DEL] budget. The particular [INS: G/L :INS] account number is [DEL: found :DEL] [INS: used :INS] according to [INS: the :INS] [DEL: combined :DEL] [INS: combination :INS] [DEL: adjustment :DEL] of the [DEL: g :DEL] [INS: G :INS] eneral [INS: product :INS] post[INS: ing :INS] group [DEL: of items :DEL] and the [INS: General business posting :INS] [DEL: general comm. post :DEL] group; the [INS: General product posting group :INS] [DEL: general post group of items :DEL] is [DEL: selected :DEL] [INS: taken :INS] from [DEL: the card for :DEL] the respective budget[INS: ed :INS] item[DEL: s :DEL] [INS: card :INS] , the [INS: General business posting :INS] [DEL: general comm. post :DEL] group is entered [DEL: in the :DEL] in the Item[DEL: s :DEL] budget sheet. The [INS: particular combination of business posting group and product posting group :INS] [INS: :INS] [INS: in the general posting setup table will give the :INS] [DEL: items :DEL] Purchase[INS: s :INS] account, Sales account and [DEL: Balance of c :DEL] [INS: C :INS] ost[DEL: s :DEL] o[DEL: n :DEL] [INS: f :INS] goods sold [INS: account :INS] [DEL: are adjusted in the option for general invoicing for a combination of the general post group of items and the general comm. post group :DEL] . When the item[DEL: s :DEL] budget [DEL: item :DEL] [INS: for :INS] Purchase[INS: s :INS] is entered, the financial budget of the Purchase[INS: s :INS] account (Debit) will be [DEL: generated :DEL] [INS: created :INS] . When the item[DEL: s :DEL] budget [DEL: item :DEL] [INS: for :INS] Sales is entered, the financial budgets [DEL: of :DEL] [INS: for the Sales :INS] account[DEL: s :DEL] [DEL: Sales account :DEL] (Credit) and [INS: for :INS] the [DEL: Account of :DEL] [INS: C :INS] [DEL: c :DEL] ost[DEL: s :DEL] o[DEL: n :DEL] [INS: f :INS] goods sold [INS: account :INS] ([INS: Debit :INS] [DEL: MD :DEL] ) will be [DEL: generated :DEL] [INS: created :INS] . [INS: :INS] Statistics · Item budget/Items · Balance/General ledger account Item[DEL: s :DEL] budget/Items Statistics of [DEL: the :DEL] evaluation of Item[DEL: s :DEL] budget (in [DEL: pieces :DEL] [INS: units :INS] ) /Movement of items in [DEL: pieces :DEL] [INS: units :INS] ([DEL: goods items :DEL] [INS: item ledger entries :INS] ) for individual [DEL: part :DEL] [INS: types :INS] of the budget (Balance, Purchase[INS: s :INS] , Sales). Balance/[DEL: Financial :DEL] [INS: General ledger :INS] account Statistics of evaluation of Item[DEL: s :DEL] budget (amount)/[DEL: Financial :DEL] [INS: General ledger :INS] account (amount) for individual types of the budget. Data export [INS: The i :INS] [DEL: I :DEL] tem[DEL: s :DEL] budget can be exported into a[INS: n :INS] [INS: Excel :INS] file[DEL: with the Excel format :DEL] . Export of budget [DEL: items :DEL] [INS: entries :INS] . Data import Item[DEL: s :DEL] budget (budget [DEL: items :DEL] [INS: entries :INS] ) can be imported into the system from [INS: an Excel :INS] [DEL: a :DEL] file[DEL: with the Excel format :DEL] . [DEL: :DEL] Import of budget [DEL: items :DEL] [INS: entries :INS] . Dimension[INS: s :INS] Item[DEL: s :DEL] budgets can be analysed by using the function Analyses by Dimensions; the functions for tracing items movements in [DEL: pieces :DEL] [INS: units :INS] are similar to those for financial amounts. 5.3 Purchase and Logistics 5.3.1 Dynamic Purchase Orders Uniform Solution: For dynamic purchase orders the history of past item movements as well as current purchase and sales requests for items have to be evaluated. The report Update purchases will assess the following values: Sum: all units sold per accounting period (12 months) Qty/month: average quantity sold per month Total Amount: total amount of units on all stocks Total Amount excl.Car: total amount of units minus amount in Car stocks Purch.Ord.Amount: amount on Purchase Orders Sale.Ord.Amount: amount on Sale Orders Serv.Ord.Amount: amount on Service Orders Lot Size: Item Card, information about amount of units which must be installed during repair at the same time (for ex.: 3 pcs.) Qty. for Purch.: recommended quantity for ordering · Plus - recommended quantity for purchase · Minus - too many units on stock Main Stock: current amount of units on Main Stock Reorder Point: current setting on Item Card, Reorder Point field Three options are suggested for the batch: · Report · Generate a Requisition Worksheet to replenish the warehouse; · Form for suggested setup change: Item Card, Reorder Point – To change the setup of the Reorder Point field use the form for suggested change (Item, Current Reorder Point, New Reorder Point, Modify). The batch Update Purchase will fill in the lines on the form, after checking and confirmation the batch will change the setup on the Item Card. 5.3.2 ELC interface Uniform Solution: The ELC interface is used to transfer purchase orders and invoices electronically between the [DEL: XXX Minolta :DEL] [INS: KMBS :INS] and its [DEL: MEV supplier :DEL] [INS: vendor :INS] . The [DEL: XXX Minolta :DEL] [INS: KMBS :INS] creates a standard purchase order of a particular kind in the NA (Normal (typical)/ Spare Parts (till the next day)/ Special). By using a particular function on the Purchase Order card or with the help of the Journal a data file for the MEV is created and transferred in a required manner. The [DEL: XXX Minolta :DEL] [INS: KMBS :INS] then receives a data file from the MEV which confirms that the order has been transferred. If the [DEL: XXX Minolta :DEL] [INS: KMBS :INS] receives this confirmation by the NA system, it will only be informative. In the case of [DEL: goods :DEL] [INS: itemss :INS] delivery, it will also be informed about [DEL: goods :DEL] [INS: items :INS] delivery (informative) and receives invoices. The MEV Invoice-type [DEL: voucher :DEL] [INS: document :INS] is used to set the confirmed quantity of the particular purchase order prior to posting. More than one [DEL: supplier :DEL] [INS: vendor :INS] invoice [DEL: (MEV) :DEL] may be associated with one particular purchase order. The [DEL: XXX Minolta :DEL] [INS: KMBS :INS] posts the [DEL: voucher :DEL] [INS: document :INS] s selected for a particular order through a list of delivered [DEL: voucher :DEL] [INS: document :INS] s (invoices). In the case of communication failure, the standard NA post is maintained. Interface graphics and functionality are based on the current [DEL: MEU and MCM designs :DEL] [INS: KMBS :INS] . [DEL: Configuration of :DEL] [INS: Setting up :INS] communication [DEL: Configuration of :DEL] [INS: Setting up :INS] communication between [DEL: the MEV and the :DEL] [DEL: XXX Minolta :DEL] [INS: vendor and :INS] [INS: KMBS :INS] has to be performed in the Purchase and [DEL: Liabilites :DEL] [INS: Payables :INS] [INS: setup :INS] menu, using the HQ [INS: tab. :INS] [DEL: option :DEL] . For successful import and export of a purchase order it is necessary to fill in two introductory fields [INS: :INS] [INS: · :INS] [DEL: – :DEL] [DEL: the :DEL] HQ [DEL: identification number :DEL] [DEL: and :DEL] [INS: Identification No. :INS] [INS: :INS] [INS: · :INS] [DEL: the :DEL] HQ [DEL: supplier number. :DEL] [INS: Vendor No. :INS] [INS: :INS] [INS: :INS] [DEL: The :DEL] HQ [INS: I :INS] [DEL: i :DEL] dentification [DEL: number :DEL] [DEL: :DEL] [INS: No. :INS] [INS: :INS] is a number assigned to the [DEL: XXX Minolta :DEL] [INS: KMBS :INS] within the [INS: vendor :INS] [DEL: MEV :DEL] . This number appears in the headers of communication files and unambiguously identifies both the [DEL: MCM :DEL] [INS: KMBS :INS] sender and addressee for HQ. [INS: :INS] [DEL: The :DEL] HQ [DEL: supplier number :DEL] [INS: Vendor No. :INS] is a local number of a [DEL: MEV supplier :DEL] [INS: vendor :INS] introduced in the [DEL: supplier :DEL] [INS: KMBS :INS] database. Orders from this particular [INS: vendor :INS] [DEL: supplier :DEL] can only be exported and subsequently received. [INS: · :INS] [DEL: The numbers of :DEL] HQ orders [INS: No. :INS] are used in the case that order confirmation received is not associated with any of the orders already prepared. In this case a new order is created and assigned a particular number from this[DEL: numerical sequence :DEL] [INS: number series :INS] . This feature applies to a confirmation only. The path of both export and import files can be defined in other fields in the HQ [INS: tab :INS] [DEL: bookmark :DEL] in the Purchase and [DEL: Liabilities :DEL] [INS: Payables :INS] [INS: setup menu :INS] [DEL: Configuration option :DEL] , the folder for transfer of received files can be defined in the same [DEL: manner :DEL] [INS: HQ :INS] [INS: tab :INS] . Export of purchase orders Purchase orders prepared can be exported using two approaches: 1. from the Purchase Order card by using the Export of Purchase Order function in the Function menu – this allows to transfer a particular purchase order into a text file; 2. from the HQ Export Journal in the Purchase and [DEL: Liabilities :DEL] [INS: Payables :INS] menu, Minolta – this allows to export several orders in one batch (all defined as To order) or re-export orders which have been already exported. Each order is exported into a separate text file whose name consists of the order number and an extension defined in the configuration. Files exported in this manner are transferred to the [INS: vendor :INS] [DEL: MEV :DEL] . Selection of orders for export – Exported purchase orders, Functions, Export of marked orders. Import of purchase orders Import of purchase orders is carried out in three steps: 1. Order confirmation 2. Order delivery 3. Import of purchase invoice Each step has its own text file which [DEL: the :DEL] [DEL: XXX Minolta :DEL] [INS: KMBS :INS] must gradually receive. However, the file may contain [DEL: voucher :DEL] [INS: document :INS] s corresponding to different purchase orders in the system. Individual steps can be started: 1. from [DEL: the :DEL] [DEL: card of the particular :DEL] [INS: the :INS] purchase order [INS: card :INS] – information in this file will be filtered only by [DEL: the number of :DEL] this order[INS: number :INS] , other parameters will be ignored[DEL: ; :DEL] 2. from the HQ Import Journal– all information in the file will be processed, in the case of “unexpected“ order a new order will be created (it applies [DEL: a :DEL] to confirmation only). All information about import ([DEL: a :DEL] [DEL: kind of goods :DEL] [INS: items :INS] , quantity, date, [DEL: voucher :DEL] [INS: document :INS] number) is stored in [DEL: Goods Delivery Journal; :DEL] [INS: HQ Item Transport Register :INS] [INS: . :INS] [INS: E :INS] [DEL: e :DEL] rror[INS: messages :INS] and information text messages can be stored in the [DEL: Communication :DEL] [INS: HQ Transport :INS] Information table. Both sheets can be opened from the Purchase Order card (data filter for a particular order) or from the Import Journal option (data filter for the journal). Posting of purchase orders The following fields were added to the Purchase Order line: HQ Confirm Quantity, HQ Delivery Quantity and HQ Invoice Quantity. These are additions of respective lines from HQ [INS: Item Transport Register. :INS] [DEL: Goods Delivery Journal :DEL] . Through the Minolta sheet in the HQ [DEL: Supplier :DEL] [INS: Vendor :INS] Invoices function, [DEL: voucher :DEL] [INS: document :INS] s intended for posting can be selected and subsequently posted, or the test configuration of [DEL: voucher :DEL] [INS: document :INS] s can first be printed out. The [DEL: numbers of :DEL] [DEL: supplier :DEL] [INS: vendor :INS] invoice[DEL: s :DEL] [INS: numbers :INS] , which have been prepared but not yet posted, can be seen in the header (the Minolta [DEL: bookmark :DEL] [INS: tab :INS] ). [DEL: Supplier :DEL] [INS: Vendor :INS] invoices are processed step by step one after another. First, the quantity given in the current [DEL: supplier :DEL] [INS: vendor :INS] invoice is entered into the Qty. to Receive field and the Qty. to Invoice field on the line of the particular order. Then the standard post[INS: ing procedure :INS] is started. In the case that the maximum limit [DEL: introduced :DEL] [INS: entered :INS] in the [DEL: field :DEL] Quantity [INS: field :INS] is exceeded, an error message appears. The purchase order, which has been completely posted, will be removed from the system. In the case of communication failure, standard functions can be used at any time. Both the header and the lines can be edited (see [INS: s :INS] [DEL: S :DEL] tandard), the content of fields in the order line change during HQ posting only; they never change during import. Information The status of the HQ [INS: Purchase :INS] order (To [INS: be :INS] order[INS: ed :INS] , Ordered, Confirmed, Delivered, Invoiced, Partially posted) is displayed in the order header ([DEL: the :DEL] Minolta [DEL: bookmark :DEL] [INS: tab :INS] ) in the course of communication. Export parameters are defined by [DEL: a :DEL] [INS: the :INS] particular [DEL: kind :DEL] [INS: type :INS] of the HQ order – Normal ([INS: t :INS] [DEL: T :DEL] ypical)/ Spare Parts ([DEL: till :DEL] [INS: by :INS] the next day)/ Special – for [DEL: individual kinds :DEL] [INS: each type :INS] of [DEL: one :DEL] order only [DEL: goods :DEL] [INS: relevant items :INS] can be entered into the line. 5.3.3 Branch stores and direct deliveries into [DEL: auto-stores :DEL] [INS: car-stock :INS] Uniform Solution: Each [DEL: store :DEL] [INS: warehouse :INS] within the system marked as a location has its own set-up and [DEL: store :DEL] [INS: stock :INS] supply management. The set-up of individual parameters for additional orders of each [DEL: kind of goods :DEL] [INS: item[DEL: s :DEL] :INS] for each [DEL: store :DEL] [INS: warehouse :INS] allows to create a flexible system of supplies in individual [DEL: stores :DEL] [INS: warehouses :INS] . Supply requirements in the system are processed using the function [DEL: Book of Requirement :DEL] [INS: Requisition Works :INS] [INS: he :INS] [INS: et :INS] s, the batch [DEL: Additional Supply of Goods :DEL] [INS: Calculate Plan :INS] . The batch generates lines of purchase requirements depending on parameters adjusted for additional orders and [DEL: store :DEL] [INS: stock :INS] supplies. Items card · [DEL: Supply System :DEL] [INS: Replenishment System :INS] (Purchase, Prod[DEL: u :DEL] [INS: . :INS] [DEL: ction :DEL] order) The [DEL: Supply System :DEL] [INS: Replenishment System :INS] set-up of defines which part of the system will ensure the required supply. Purchase will always be used as default. This ensures that goods will be ensured exclusively by purchase. · [DEL: Method of additional ordering :DEL] [DEL: ( :DEL] [DEL: Fixed add. ordered quantity :DEL] [DEL: , :DEL] [DEL: Maximum quantity, :DEL] [DEL: :DEL] [DEL: Order, Batch-for-Batch :DEL] [INS: · :INS] [INS: Reordering Policy (Fixed Reoder Qty., Maximum Qty., :INS] [INS: Order, Lot-for-Lot) :INS] [INS: :INS] In combination with quantity parameters in the Planning [DEL: option :DEL] [INS: tab :INS] , this option ensures additional orders for the particular [DEL: kind of goods :DEL] [INS: items :INS] in quantity required to supply the [DEL: store :DEL] [INS: stock :INS] .[INS: :INS] [DEL: The Fixed Add. Ordered Quant. or Order set-up will be used :DEL] .[INS: :INS] [INS: :INS] [INS: The Fixed Reorder Qty. or Order :INS] [INS: option :INS] [INS: will be used :INS] [INS: . :INS] The Transfer option in the Items card cannot be used as [INS: a :INS] [DEL: supply system :DEL] [INS: Replenishment System :INS] . This option is possible only with the use of [DEL: store unit :DEL] [INS: stockkeping unit :INS] s. A [DEL: store unit :DEL] [INS: stockkeping unit :INS] can be created for each [DEL: kind of goods :DEL] [INS: item[DEL: s :DEL] :INS] and each [DEL: store :DEL] [INS: warehouse :INS] . Since [INS: a :INS] large number of [DEL: stores :DEL] [INS: warehouses :INS] and [INS: a :INS] large [DEL: quantity :DEL] [INS: number :INS] of [DEL: goods :DEL] [INS: items :INS] are expected, features are provided supporting automatic generation of [DEL: store unit :DEL] [INS: stockkeping unit :INS] s. These parameters are used by the report Create [DEL: store unit :DEL] [INS: stockkeping unit :INS] [DEL: . :DEL] to generate [DEL: store unit :DEL] [INS: stockkeping unit :INS] s. Location The Location card allows to set up initial parameters for [DEL: store unit :DEL] [INS: stockkeping unit :INS] s: · [DEL: Supply system :DEL] [INS: Replenishment System :INS] (Purchase, Production Order, Transfer) [DEL: · :DEL] [DEL: Methods of additional orders (Fixed add. ordered amount, Maximum amount, Order, Batch-for-Batch :DEL] [INS: · :INS] [INS: Reordering Policy (Fixed Reoder Qty., Maximum Qty., Order, Lot-for-Lot) :INS] · [DEL: Transfer of z-code :DEL] [INS: Transfer-from Code :INS] [DEL: Store unit :DEL] [INS: Stockke :INS] [INS: e :INS] [INS: ping unit :INS] · [DEL: Supply system :DEL] [INS: Replenishment System :INS] (Purchase, Production Order, Transfer) [DEL: · :DEL] [DEL: Methods of additional orders (Fixed add. ordered quant., Maximum quant, Order, Batch-for-Batch :DEL] [INS: · :INS] [INS: Reordering Policy (Fixed Reoder Qty., Maximum Qty., Order, Lot-for-Lot) :INS] [INS: [DEL: · :DEL] :INS] [INS: [DEL: :DEL] :INS] · [DEL: Transfer of z-code :DEL] [INS: Transfer-from Code :INS] The adjustment of the above parameters of locations ensures generation of a [DEL: store unit :DEL] [INS: stockkeping unit :INS] for the particular [DEL: store :DEL] [INS: stock :INS] and goods with initial set-up of the [DEL: supply system :DEL] [INS: Replenishment System :INS] and a [DEL: method of additional ordering :DEL] [INS: Reordering Policy :INS] . In order to generate [DEL: store unit :DEL] [INS: stockkeping unit :INS] s with the [DEL: Supply System :DEL] [INS: Replenishment System :INS] – Transfer configuration, Transfer [INS: Routes :INS] [DEL: directions :DEL] must be pre-defined. In the [DEL: Transfer of z-code :DEL] [INS: Transfer-from Code :INS] field the [DEL: store :DEL] [INS: stock :INS] , from which supplies will be transferred, is then configured. Simultaneously, in the location [DEL: Transfer of z-code :DEL] [INS: Transfer-from Code :INS] is set up for [DEL: Supply System :DEL] [INS: Replenishment System :INS] – Purchase, purchase orders will be generated for this location in the case of a shortage of a particular [DEL: kind of goods :DEL] [INS: items :INS] in the [DEL: store :DEL] [INS: stock :INS] . The [DEL: Supply System :DEL] [INS: Replenishment System :INS] configuration is crucial in respect to a method of [DEL: store :DEL] [INS: stock :INS] supply. [DEL: Supply system :DEL] [INS: Replenishment System :INS] - Purchase Purchase orders will be used as an initial method of supply. The Purchase option will be used to supply central locations. [DEL: Supply system :DEL] [INS: Replenishment System :INS] – Transfer Transfer orders from a particular location configured in [DEL: Transfer z-code :DEL] [INS: Transfer-from Code :INS] will be used as an initial method of supply. The Transfer option will be used to supply locations. Minimum [DEL: supply :DEL] [INS: Inventory :INS] Methods of additional ordering. The option affects the state of supplies in a location. It allows to maintain minimum supplies in [DEL: a :DEL] [DEL: store :DEL] [INS: stock :INS] . · [DEL: Methods of additional orders :DEL] [INS: Reordering Policy :INS] o [DEL: Fixed add. ordered quant. :DEL] [INS: Fixed Reorder Qty. :INS] – [DEL: Point of additional order :DEL] [INS: Reorder Point :INS] – minimum value of the state of goods supply in a particular location o Order – it generates individual purchase requirement for each requirement of consumption (sale, service) Purchase, [DEL: Book of requirement :DEL] [INS: Requisition Workset :INS] s The [DEL: Book of requirement :DEL] [INS: Requisition Workset :INS] s in the area of Purchase is a central [DEL: spot :DEL] [INS: point :INS] in purchase planning. It contains all requirements regarding [DEL: store :DEL] [INS: stock :INS] supplies. Requirements concerning purchase can be inserted in the [DEL: Book :DEL] [INS: Requisition Worksheet :INS] manually or automatically using the function [DEL: Order :DEL] [INS: Calculate Plan . :INS] [DEL: additional goods. :DEL] · [DEL: Order additional goods :DEL] [INS: Calculate Plan :INS] By configuration of the [DEL: Supply System :DEL] [INS: Replenishment System :INS] parameters and by using methods of additional orders in the Items card or in the [DEL: store unit :DEL] [INS: stockk :INS] [INS: e :INS] [INS: eping unit :INS] , initial adjustments of the batch [DEL: Order Additional Goods :DEL] [INS: Calculate Plan :INS] in the [DEL: Book of Requirement :DEL] [INS: Requisition Workset :INS] s are defined. The batch generates required quantity of goods to be supplied in individual [DEL: store :DEL] [INS: stock :INS] s in the [DEL: Book of requirement :DEL] [INS: Requisition Workset :INS] s. The batch suggests to supply [DEL: goods :DEL] [INS: items :INS] not only in the case of a shortage of [DEL: goods :DEL] [INS: items :INS] , but also in the case of minimum supplies. It also suggests the lines of transfers for [DEL: store :DEL] [INS: stock :INS] s supplied by means of [DEL: goods :DEL] [INS: items :INS] transfer from a different [DEL: store :DEL] [INS: stock :INS] . · [DEL: Perform reported actions :DEL] [INS: Carry Out :INS] [INS: Action Message :INS] The function [INS: Carry Out Action Message :INS] [DEL: Perform reported actions :DEL] ensures the transfer of the lines in the [DEL: book of requirement :DEL] [INS: Requisition Workset :INS] s into purchase orders or transfer orders. Purchase, Order By using the function [INS: Carry Out Action Message :INS] [DEL: Perform reported actions :DEL] , purchase orders to supply [DEL: store :DEL] [INS: stock :INS] s (as required) are modified or created. Simultaneously, purchase orders to supply [DEL: store :DEL] [INS: stock :INS] s in [DEL: supply system :DEL] [INS: Replenishment System :INS] transfer are generated or filled in. The function [DEL: Tracing :DEL] Order[INS: Tracking :INS] maintains connection with the source requirement [DEL: voucher :DEL] [INS: document :INS] . This allows to display a system requirement [DEL: voucher :DEL] [INS: document :INS] for each line of a particular purchase order. Transfer Order By using the function Perform reported actions, transfer orders for required [DEL: store :DEL] [INS: stock :INS] supply are modified or generated. supplied with the Transfer system. If there is a shortage of goods in the [DEL: store :DEL] [INS: stock :INS] for transfer, a purchase order is simultaneously generated to supply [DEL: store :DEL] [INS: stock :INS] s for transfer. Direct [DEL: supplies :DEL] [INS: shipments :INS] into [DEL: auto-store :DEL] [INS: car-stock :INS] s In order to generate individual [DEL: store unit :DEL] [INS: stockkeping unit :INS] s, individual location of the [DEL: auto-store :DEL] [INS: car-stock :INS] must be defined. For direct [DEL: goods supplie :DEL] [INS: shipment :INS] s in[INS: to :INS] [DEL: auto-store :DEL] [INS: car-stock :INS] s, [DEL: store unit :DEL] [INS: stockkeping unit :INS] s must be generated with the [DEL: supply system :DEL] [INS: Replenishment System :INS] and a [DEL: method of additional ordering :DEL] [INS: Reordering Policy :INS] , both being individually adjusted. Adjustment of a [DEL: store unit :DEL] [INS: stockkeping unit :INS] for direct [DEL: supplies :DEL] [INS: shipment :INS] into the [DEL: auto-store :DEL] [INS: car-stock :INS] by means of purchase: · [DEL: Supply system :DEL] [INS: Replenishment System :INS] – Purchase · [DEL: Method of additional ordering :DEL] [INS: Reordering Policy :INS] – Fixed add. ordered quant. · [INS: Reorder :INS] Point [DEL: of additional ordering :DEL] – minimum supplies required · [INS: Vend :INS] [INS: or No. :INS] [DEL: Supplier Number :DEL] · [INS: Vendor Item no. :INS] [DEL: Supplier Items Number :DEL] Adjustment of a [DEL: store unit :DEL] [INS: stockkeping unit :INS] for direct [DEL: supplies :DEL] [INS: shipment :INS] into the [DEL: store :DEL] [INS: stock :INS] by transfer: · [DEL: Supply system :DEL] [INS: Replenishment System :INS] – Transfer · [DEL: Method of additional ordering :DEL] [INS: Reordering Policy :INS] – Fixed add. ordered quant. · [INS: Reorder :INS] Point [DEL: of additional ordering :DEL] – minimum supplies required · [DEL: Supplier Number :DEL] [INS: Vendor No. :INS] · [DEL: Supplier Items Number :DEL] [INS: Vendor Item No. :INS] 5.3.4 Centralized Item numbering Uniform Solution: 1. Item On the item cards it is possible to find Number (No.) and [INS: n :INS] [DEL: N :DEL] umber 2 (No. 2). · [DEL: Number :DEL] [INS: No. :INS] – the internal number of the item in the system. The item number is either joint (central, subsidiary to central, independent [DEL: numerical :DEL] [INS: number :INS] series) or internal (independent numbering for internal item in each system, independent [DEL: numerical :DEL] [INS: number :INS] series). A[INS: n :INS] item card in the system is usually established by importing the list of item from central. The item number in this case will be central, without the possibility for change. For internal item, i.e. item recorded only locally, the item number will be established according to the internal regulations of the company by an independent [DEL: numerical :DEL] [INS: number :INS] series. · [DEL: Number 2 :DEL] [INS: No. 2 :INS] – the second internal item number. This enables recording a second internal numbering of item. Possibility to preserve the original item numbers during migration to new records. [DEL: Number 2 :DEL] [INS: No. 2 :INS] then facilitates finding item cards according to the original item numbers. For use, it is necessary to change the key in the [DEL: item overview :DEL] [INS: Item List :INS] . Consistent joint records ensure a centrally established product hierarchy and a centrally established list of item[INS: s :INS] . The [DEL: report on the :DEL] product hierarchy[INS: management :INS] is resolved by [DEL: independent :DEL] [INS: a separate :INS] [DEL: batch :DEL] file import[INS: batch :INS] . [DEL: A i :DEL] [INS: I :INS] tem [DEL: report :DEL] [INS: management :INS] is resolved by a[DEL: n :DEL] [INS: separate :INS] [DEL: independent :DEL] item[INS: register :INS] [INS: import :INS] batch [DEL: records import :DEL] . 2. Product hierarchy For creating[INS: a :INS] consistent item [DEL: records :DEL] [INS: register :INS] and consistent [DEL: settings for accounting :DEL] [INS: posting setup :INS] , a product hierarchy (PH) is used in the [DEL: records :DEL] system. The product hierarchy is a centrally established code for classifying[INS: an :INS] item. The product hierarchy is recorded in the system in an independent table. It is possible to import the product hierarchy. The centrally established fields Product Group, Material Group, Material Category, Article Group, Material Model, Product Name [DEL: may :DEL] [INS: will :INS] be imported. Other fields of the product hierarchy must be added to each system according to internal rules. The import batch for the product hierarchy may be run in the test regime with possibilities of creating a file for error messages. Product Group HQ import file Material Group HQ import file Material Category HQ import file Article Group HQ import file Material Model HQ import file Product Name HQ import file Gen. Prod. Posting Group Option Set by accounting Item Type Option Spare part, Consumable, Machine model, Accessory Inventory Posting Group Option Set by accounting Service Item Group Option Service Item Group code list Product Group Code Option Product Group Code list VAT Prod. Posting Group Option Set by VAT accounting Unit of Measure Option Basic currency unit Costing Method Option Costing method Vendor No. Option Vendor number Tariff No. Option Tariff number Product Hierarchy Code System Product Hierarchy Code Item Disc. Group Option Item Discount Group Option 3. Import item [DEL: :DEL] The centrally established list of item[INS: s :INS] is submitted in a .csv file. The import file contains at least the Item Number, the Name of Item, and the Product Hierarchy Code. When importing[INS: an :INS] item, a corresponding line in the Product Hierarchy Table is found in a line of the import file according to the Product Hierarchy Code. When creating a new item card, the other fields for corresponding lines of the product hierarchy are used as initial settings for the item card. 5.3.5 Consignation stocks Uniform Solution: 1. Description For recording the movement of [DEL: goods :DEL] [INS: items :INS] prior to [DEL: entering the acceptance :DEL] [INS: posting a receipt :INS] of [DEL: goods :DEL] [INS: items :INS] into stock, the module [INS: Item :INS] [DEL: Good :DEL] Transfer has been added. The module is an independent auxiliary record of [DEL: goods :DEL] [INS: item[DEL: s :DEL] :INS] movement. Movement [DEL: items :DEL] [INS: entries :INS] are recorded independently during [DEL: goods :DEL] [INS: item[DEL: s :DEL] :INS] transport and [DEL: items :DEL] [INS: entries :INS] at the end of transport. [DEL: The amount of :DEL] [DEL: goods :DEL] [INS: [DEL: i :DEL] :INS] [INS: I :INS] [INS: tem :INS] [INS: quantities :INS] [INS: :INS] [DEL: during :DEL] [INS: in :INS] transport [DEL: is :DEL] [INS: are :INS] displayed on the item[DEL: s :DEL] card. [DEL: The amount of :DEL] [DEL: goods :DEL] [INS: [DEL: i :DEL] :INS] [INS: I :INS] [INS: tem :INS] [INS: quantities :INS] in transport [DEL: is :DEL] [INS: are :INS] included in the [INS: calculation of :INS] [INS: Item :INS] [DEL: A :DEL] [INS: a :INS] vailab[DEL: le :DEL] [INS: ility :INS] [DEL: Amount :DEL] [DEL: calculation :DEL] . After the completion of transport, purchasing continues with the general [DEL: acceptance :DEL] [INS: receipt :INS] of [DEL: goods :DEL] [INS: items :INS] into stock. [DEL: At the same time :DEL] [INS: Similarly :INS] , the Amount in Transport field is supplemented on the Stock[INS: keeping :INS] [DEL: :DEL] Unit Card. 2. Transport records a. Transport [DEL: item :DEL] [INS: entry :INS] A transport [INS: entry :INS] [DEL: item :DEL] serves for record[DEL: s :DEL] [INS: ing items currently :INS] [DEL: as the current goods :DEL] in transport. The[DEL: se :DEL] [INS: following :INS] values are recorded: · Purchase Order No. · Date · Item No. · Quantity · Transport-to Location · Direct Unit Cost · Total Value · Total Value (LCY) · Total Tax % b. [INS: Posted :INS] [DEL: Entered :DEL] transport [INS: entry :INS] [DEL: items :DEL] [DEL: With the end of :DEL] [INS: By finishing an :INS] [DEL: goods :DEL] [INS: item[DEL: ss :DEL] :INS] transport, the transport [DEL: item :DEL] [INS: entry :INS] is entered into the [DEL: records of entered transport goods item :DEL] [INS: posted :INS] [INS: item :INS] [INS: transport entries :INS] . The [INS: posted :INS] [DEL: entered :DEL] transport [DEL: item :DEL] [INS: entry :INS] serves in the record of [DEL: final :DEL] [INS: finished :INS] [DEL: goods :DEL] [INS: item[DEL: s :DEL] :INS] transport and is used for documenting [DEL: the end of :DEL] [INS: finished :INS] [DEL: goods :DEL] [INS: item[DEL: s :DEL] :INS] transport. 3. Solution 5.3.6 Limited display of acquisition and stock prices. Description of current status: Currently, the fields containing [INS: the latest :INS] purchase[INS: price :INS] and [DEL: stock prices :DEL] [INS: item cost :INS] are visible as standard. After each import of new forms, it is necessary to manually hide these fields for restricted users. Uniform Solution: In the entire application, visibility of fields containing [INS: the latest purchase price and item cost :INS] [DEL: acquisition and stock prices :DEL] will be set at No as the default[DEL: , in such a way :DEL] [INS: so :INS] that they are automatically hidden. Users who need to display the given field must manually open it themselves. Users who may not have access to these fields [DEL: may :DEL] [INS: will :INS] not have [DEL: the permission tool :DEL] [DEL: Lupa :DEL] [INS: Zoom :INS] [INS: enabled :INS] [INS: :INS] [DEL: (Magnifier) :DEL] and [DEL: may :DEL] [INS: will :INS] not [DEL: be permitted :DEL] [INS: have permission :INS] to display the field in the forms. [DEL: :DEL] After importing [DEL: possible :DEL] [INS: newly :INS] modified objects, it [DEL: is :DEL] [INS: will be :INS] necessary to [DEL: again :DEL] display the field[INS: again :INS] . [DEL: Hiding :DEL] [DEL: these[INS: Hidden :INS] fields in reports is not included in this :DEL] [INS: This :INS] module[INS: does not include the solution which would hide the fields in reports :INS] . 5.3.7 Special transfer prices Uniform Solution: [INS: Item :INS] [DEL: Goods :DEL] transfer may be realised in the system using a dual method. 1. [DEL: Transfer log :DEL] [INS: Item Reclass. Journal :INS] 2. [DEL: Order transfer :DEL] [INS: Transfer Orders :INS] The [DEL: transfer log :DEL] [INS: Item Reclass. Journal :INS] does not enable a change in the price of goods during transfer. Two mutually comparable [DEL: goods items :DEL] [INS: item entries :INS] are automatically created. For a change in the price of [DEL: goods :DEL] [INS: item :INS] during the [DEL: goods :DEL] [INS: item :INS] transfer process between stocks, it is necessary to use the [INS: Transfer O :INS] [DEL: o :DEL] rder [DEL: transfer :DEL] and simultaneously to use predefined [INS: Charge (Item) :INS] [DEL: fee :DEL] s for [INS: item :INS] [DEL: good :DEL] s. [INS: Transfer :INS] Order [DEL: transfer :DEL] - change in the price of [INS: item :INS] [DEL: good :DEL] s In order to change the price of [DEL: goods :DEL] [INS: items :INS] during transfer, the [DEL: goods :DEL] [INS: items :INS] must be [DEL: accepted :DEL] [INS: received :INS] [DEL: in :DEL] to stock. A purchasing document must exist as well as an [DEL: entered :DEL] [INS: posted :INS] receipt [DEL: card :DEL] to the purchasing document. For such an acceptance of [DEL: goods :DEL] [INS: items :INS] , the transfer of [DEL: goods :DEL] [INS: items :INS] between locations must be [DEL: accounted :DEL] [INS: posted :INS] for by an [INS: Transfer :INS] Order [DEL: Transfer :DEL] document. The [INS: Transfer :INS] Order [DEL: Transfer :DEL] must be completed, i.e. it must be [INS: posted :INS] [DEL: entered :DEL] into the document [DEL: Accounting :DEL] [INS: Posted :INS] Transfer Receipt [DEL: Card :DEL] at the target [DEL: stock :DEL] [INS: location :INS] . When [DEL: accounting :DEL] [INS: posting :INS] [DEL: for :DEL] the purchasing invoice, the purchase price of the [INS: received :INS] [DEL: accepted good :DEL] [INS: item :INS] s may be changed in such a prepared purchase document. A [INS: charge :INS] [DEL: fee :DEL] for the [INS: items :INS] [DEL: good :DEL] s will be used for the change in price. A [INS: charge :INS] [DEL: fee :DEL] for [INS: items :INS] [DEL: good :DEL] s line will be added to the invoice lines. With the help of the functions, Line, [INS: Item Charge Assingment :INS] [DEL: Transfer Fee for Goods :DEL] , the amount of the transfer [INS: charge :INS] [DEL: fee :DEL] for [INS: item :INS] [DEL: good :DEL] s may be entered first in the Accounting for [INS: Posted :INS] Transfer Receipt [DEL: Cards :DEL] line. A thus entered purchasing invoice will determine the accounting for the [INS: item :INS] [DEL: good :DEL] s [INS: charge :INS] [DEL: fee :DEL] for individual [DEL: goods :DEL] item[DEL: s :DEL] [INS: entries :INS] . A change in the price is supported by an assessment item of the type Transfer [DEL: Surcharge :DEL] [INS: Direct Cost :INS] on the transferred item of the relevant [INS: entries :INS] [DEL: goods :DEL] . 5.3.8 Bar code use Uniform Solution: If printing bar codes, it is possible to use the library that enables bar code printing in any report. It is necessary to properly modify this report and install this library at the workstation at which the printing will be conducted. At the same time, it is possible to print the following types of codes: Code39, Code128A, Code128B, Code128C, 2I5, Codabar, EAN8, EAN13, UPCA, UPCE. It is also possible to print other codes as well. Printing is conducted on the basis of data saved in the application in the form of a code. Multiple bar codes and various types may be used in one report. [DEL: In case of :DEL] [INS: For :INS] reading the bar code, there are several options: 1. Reading [DEL: with the help of :DEL] [INS: using :INS] a so-called keyboard [DEL: reader :DEL] [INS: scanner :INS] , which simulates keyboard [DEL: access :DEL] [INS: entries; :INS] 2. Reading [DEL: with the help of :DEL] [INS: using :INS] a programmable [DEL: reader :DEL] [INS: scanner :INS] In the case of 1 above, it is possible to use such [DEL: reader :DEL] [INS: scanner :INS] s immediately, without changes to the application. The application may only be modified so that with the help of a scanner, access is faster and easier as the order of the fields and their sequence will be modified and after reading the code, access focus will shift to the field that is to be subsequently completed without the necessity of manual shifting of the cursor. These [DEL: reader :DEL] [INS: scanner :INS] s are advantageous, for example, for sales and various links where mobility is not required. [DEL: Reader :DEL] [INS: S :INS] [INS: canner :INS] s could be built in (e.g. into the counter), or manually connected by wire or wireless to the station. If using a programmable [DEL: reader :DEL] [INS: scanner :INS] , it is necessary to modify the application so it would be possible to batch process data from these [DEL: reader :DEL] [INS: scanner :INS] s and to determine the programming for the given activity. A [DEL: reader :DEL] [INS: scanner :INS] must contain the program that directs how the data will be entered and stored internally. Subsequently, (for example, when inserting into the database), data are processed and exported in the given format into a file or they could be entered directly into the database. Then data processing must take place in the NA application. In this case, it is necessary here to specify which processes will be supported and to propose an interface for the given data in co-operation with the company delivering the [DEL: reader :DEL] [INS: scanner :INS] s. Special offer of Hand-Held Scanner: Hand-Held Scanner Datalogic: EUR 901651000 Gryphon D100 CCD-GUN ADVANCED FEATURES 361,- Accessories: 90G001010 CAB-321 CABLE WEDGE PS/2 MINI DIN 16,- 90ACC1770 SPC-Gryphon DESK- WALLHOLDER GRYPHON 18,- The prices in this offer are without V.A.T., which is 22% and transport and instalation cost. Delivery time: approximately 2 – 4 weeks Datasheets are in apendicies. 5.3.9 Report on Slow Moving Items Uniform Solution: The report will provide a list of item movements according to type (Item Ledger Entry, Ledger Entry Type: Purchase, Sale, Receipt, Dispatch). The report will enable to set a maximum percentage range allowed . Period range is optional. An option will exist to display items without movement or items with movement outside a defined percentage range. 5.4 Sales 5.4.1 Extended pricing with customer oriented discounts Uniform Solution: Price lists. Sales prices are used in the system for creating [INS: items :INS] [DEL: goods :DEL] price lists. Price lists are created according to the type of sales prices and the price list validity conditions. Type of sales prices: · Customer · Customer price group · All customers · Campaign Customer sales price A price is associated for each [DEL: good :DEL] [INS: item :INS] for every customer. It is also possible to set an independent price list for each customer. Sales price for a customer price group Associated with each customer card is one customer price group in which the [DEL: goods :DEL] [INS: items :INS] sales price is defined for each [DEL: good :DEL] [INS: item :INS] . The [DEL: goods :DEL] [INS: items :INS] price list for each customer group is thus set. Sale price for all customers A sales price for the All Customers type is used for setting [DEL: goods :DEL] [INS: items :INS] sales prices for all customers. Campaign sales price The Campaign Sales Price is used for setting price lists of individual campaigns. The individual [DEL: goods :DEL] [INS: items :INS] price list in each price list is defined by: · [DEL: Initial :DEL] [INS: Starting :INS] date · End[INS: ing :INS] date · Currency[INS: Code :INS] · Minimal amount · [INS: Unit of Measure Code :INS] [DEL: Currency unit code :DEL] · Variant code · Type of sales price or a combination of all five factors. Event price, event price lists. A Price [DEL: Event :DEL] [INS: Action :INS] code has been provided for managing price events. Each Sales Price (price list) may be combined with a Price [DEL: Event :DEL] [INS: Action :INS] code into the event price list. The [DEL: Initial :DEL] [INS: Starting :INS] Date and the End[INS: ing :INS] Date determine the validity of the event price list. [DEL: Item :DEL] [INS: Set :INS] Price List[DEL: . :DEL] [INS: (BOM) :INS] The Customer Price Group code is used for setting the [DEL: item :DEL] price list[INS: of set :INS] . The code for the initial [DEL: item :DEL] price list [INS: of set :INS] is set in Sales and Orders settings. Each Customer Price Group may be marked with a code for the [INS: Set :INS] [DEL: Items :DEL] Price Group. During item sales, the code for the Customer Price Group is set using the [INS: Set :INS] [DEL: Item :DEL] Price Group. The [INS: Set :INS] [DEL: Item :DEL] Price is established by: · The initial [DEL: item :DEL] [INS: set :INS] price list – when the Customer Price Group does not have a code for the [DEL: Item :DEL] [INS: set :INS] Price Group · The [DEL: Item :DEL] [INS: set :INS] Price Group – when the Customer Price Group is marked by the [DEL: Item :DEL] [INS: set :INS] Price Group Code Sales prices prepared in advance for imports in .xls format have been supplemented by a batch for price list imports. Discounts. Each sales price list may be combined with discounts. It is possible to select Invoice Discount, Line Discount or both discounts simultaneously for each price list. 5.4.2 Configurator Uniform Solution: For creating dynamic sets and configurations, the tool „Configurator“ is used. This tool creates individual templates for configuration formation directly in NA. These template areas are then used in sales orders for creating specific configurations or for proposals of dynamic set in sales orders. If goods are inserted into a sales order with a valid template, it is possible to call up the configurator and to select individual components that will be part of the configuration. The configurator allows creation of only consistent configurations on the basis of rules defined in the template. The template contains the following data: · Template code · Basic goods (goods number for which the template was created) · Template name · Template description (for B2C etc.) · Whether the template is valid · Date from which the template is valid · Lifetime · Recommended load · Warranty information · Template types (dynamic set, configuration) In addition to these main data, each template also contains one or more lines, which hold information about individual components and groups of components in the configurations. These individual lines create nodes in the configuration tree, where the roots of the tree are the main goods entered into the template. Each node (line) contains information about the component or group and conditions under which it may be selected. Information in the node includes the following: · Level in the component tree (line number and level for jointly indicating the position on the component tree) · Whether a node for specific components or only the group · Minimum and maximum number of nodes in the lower levels that must be selected in order for the node to fulfil conditions · Number and type of components for specific goods (goods, resources) · Node description · Whether the node is visible in the configurator · Whether the component (or group) has to be selected in default · Whether it is possible to change the selection of component · Option does not contain components in the price (will be zero price) · Amounts and unit of components for one unit configuration · Node code (marking which is used in conditions) · Conditions for component selection The condition for component selection is the logical expression module from the operators AND, OR, NOT, () and the node codes. If this expression is true, it is possible to select a component; if not, the component selection is not fulfilled. It is possible to import the template to an external file and to import it back. Marking templates as valid is conditioned by satisfying all required characteristics (accuracy of expressions etc.). Differences between configuration and dynamic set: · The dynamic set has all components obligatory; during proposal for sales orders, components are sold for prices in special set price lists, which are selected according to the customer price group. If the component does not exist in this price list, it is not possible to create a set. · The configuration has optional components, components are proposed for the standard price list price (or they are not included in the price). The configurator will not be used for creating static sets. Static sets will be created with the help of broad standard piece list (BOM). 5.4.3 External CRM and mobile salesman Uniform Solution: For using NA by salesman without direct connection to NA server must be other software used. NA has no possibility of replication. There must be interface defined for external software to get data from NA and insert new data into NA. For reading data from NA can external application use direct connection to NA tables through MS SQL server (if SQL option is used) or through C/ODBC (if native option is used). If external application is able use Automations or OCX libraries, C/Front can be used (C/Front is communication library for NA which can be used in other programming languages). C/Front can be used from Visual Basic, C++, Borland Delphi etc. Through C/Front can application read and write data from/to database. For writing data into database is needed to create new tables for this data, and to run batch in NA which transfer those data into “sharp” tables (with necessary checks). External software can send (or replicate) only data needed by the salesman into salesman’s computer. Salesman has data about all items and all configuration templates ready for use. Though configurator created in external software based on configurator template from NA is sales man able to create configuration for customer. Salesman prepare contract or sales order on his computer. When this computer is connected to external software database, data will be transferred into NA special tables. From this tables are data converted into sales order document or into service contract. NA must find out if all necessary cards are in NA existing (customer card, shipping address etc.). If all is ok, documents are created in NA. If some problem is found, someone must correct data or must decide what to do. Without special interface is possible only reading data from NA. To prepare some interface for entering data into NA must be decided, what will be entered from sales mans into NA. 5.4.4 Direct connection to service (configurations sold). Uniform Solution: Purchase order The configuration prepared is used to create purchase order of configuration. The purchase order created ensures that the configuration parameters required are automatically introduced into the Supply and Planning system. Missing components can be supplied via the purchasing system according to parameters defined in the [INS: item :INS] [DEL: Goods :DEL] card. Create a subject of service During the posting of configuration purchase, the subject of service is automatically created. The configuration-type subject of service is created from the sale [DEL: voucher :DEL] [INS: document :INS] posted. The function creates the subject of service including service components; it is similar to the function used to make subjects of service in the sales of other [DEL: kinds of goods :DEL] [INS: items :INS] . Subject of service The configuration-type subject of service is created from the line of sale [DEL: voucher :DEL] [INS: document :INS] marked as Configuration-Yes. Components of the subject of service are created from the lines of the sale [DEL: voucher :DEL] [INS: document :INS] marked as Configuration-No. Service orders and service contracts can be made for a particular configuration-type subject of service created. 5.4.5 e-Business The problem of e-business can be divided into two areas. B2C (Business to Customer) ensures Internet commerce for end customers or dealers, when business takes place directly on the Internet pages of the seller. Information provided on such pages is directly linked to the ERP system and resulting documents (inquiries, orders) are loaded directly into the ERP system and further processed. B2B (Business to Business) ensures a complex exchange of documents between partner firms, both from the side of vendors as well as from the side of customers. In part or completely, this solution replaces the paper agenda. Documents (orders, delivery notes, invoices etc.) are automatically loaded for the relevant partners and appear in its information system. 5.4.5.1 B2C Description of current status: Currently, with the exception of BCZ, individual KMBS-LS do not use any B2C type solutions. BCZ uses the independent solution of an external vendor, which is a replication method linked to the ERP system, data are then transferred off-line and batch processed. Individual solutions: In the B2C area, we propose two possible solutions. 5.4.5.1.1 Independent system A B2C solution is possible to provide by a sub-contracted specialised company for Internet solutions, for example the vendor BCZ. This sub-contract should be common for all KMBS-LS, so that common extension to Navision would be provided. If the solution is provided individually in individual countries, then here is a proposal for a standardised interface, which this solution must respect. 5.4.5.1.2 Commerce Portal Commerce portal is a B2C solution directly integrated with the complex business solution Navision and uses its commercial logic. This means that maintaining actual information on web portals and processing orders and other information does not require any additional administration. Commerce Portal improves the effectiveness of business communication using web commerce, Internet self-service and other forms of electronic cooperation. Commercial partners cooperate with the company by means of a personalised web portal, which precisely satisfies the demands for their particular rolls. Each partner has its own internal personalised base, through which it can communicate and trade with companies. Thanks to real time integration and the use of the Navision business logic, Commerce Portal offers a direct and simple method of commerce with partners in commercial chains. Direct link between the Navision solution and Commerce Portal facilitates a decrease in costs for more effective customer service. The system also eliminates the risk of human error, because orders are entered into the system only once. Commerce Portal is 100% integrated with the back-office solution. Automation of transaction processes decreases costs for these transactions and the firm has the possibility to process a greater volume of transactions. The system enters all vendor and customer documents automatically and immediately, including orders or offers into Navision. When a change is conducted in Navision, this appears immediately in the customer portal. The content of the entire solution is administered directly in Navision, which improves the effectiveness of implementation of important information without the necessity of special vendor work. An internal graphic solution on an ASP (Active Server Pages) base is maintained independently with the help of relevant specialists; changes do not occur here often. It is possible to distinguish the so-called roles for dealer and end customer access in the solution. With the aid of roles, it is also possible to enable work in the Commerce Portal for sales employees during their business trips. The following technical equipment is necessary to provide Commerce Portal: Server equipment: · Microsoft Business Solutions–Navision 3.70 · Microsoft Business Solutions–Navision Application Server 3.70 · Microsoft Windows 2000 Server · Microsoft SQL Server 2000, SP3 (to use Commerce Server) · Microsoft Commerce Server 2000/2002 · Microsoft XML Parser 3.0, SP2 · .NET Framework (only for Commerce Server 2002) Client equipment: · Microsoft Business Solutions–Navision 3.70 · Operational systems - Microsoft Windows 98 SE, Microsoft Windows NT 4.0 (SP6a) Workstation or Server, Microsoft Windows 2000, Microsoft Windows XP · Microsoft Internet Explorer 5.5, SP2 and newer We introduce here a brief overview of the functionality of individual components. Product Purpose Microsoft Windows 2000 Server Provides a scalable and reliable operating system. Windows 2000 Server includes the Internet Information Server and Message Queue. Microsoft Internet Information Server (IIS) Provides a reliable and scalable HTTP portal through which Web sites and Web applications communicate with the outside world. IIS 5.0 provides an environment and services that application developers need to quickly create sophisticated Web-enabled applications. One of the most significant development technologies included in IIS 5.0 is Active Server Pages, which are described below. Active Server Pages Provides a server-side scripting environment for creating and running dynamic, interactive Web-server pages and applications. With Active Server Pages, you can combine HTML pages, script commands, and COM components to create interactive Web pages or Web-based applications with access to databases, which are easy to develop and modify. Microsoft Message Queue Server Manages the messaging API between the storefront pages and the Navision Application Server for the transfer of business logic and data between the two. Microsoft Commerce Server 2002 Provides the e-commerce infrastructure needed to build an effective online business. User profiling and management, product and service management, transaction processing, and targeted marketing and merchandising are all integrated to create a comprehensive system customizable to a company’s specific needs. Functionality is combined to manage product and client information, and to streamline and refine online business processes. The Profile, Targeting, Product Catalog and Business Process Pipelines systems work together to enhance the user experience by delivering one-to-one marketing capabilities. Microsoft SQL Server Provides the database for storing temporary session data extracted from the Navision Database Server, and session-specific activity and state data for each storefront user. Prices for SW licences are in Appendix 1. 5.4.5.2 B2B Description of current status: Currently, only a small segment of communication is utilised. This involves communication with central in Langenhagen, where only orders and delivery notes are preloaded. The communication format is entirely specific and does not issue from any standard. Integrated solution: In the context of an integrated solution, a module is proposed for communication with European central according to the standards of Konica Minolta called ELC interface, which is described in chapter 5.3.2. 5.4.6 Royalties (Fee to Author's organization) Uniform Solution: For copyright fees records, the functional field Resources is used. Copyright fees may be requested independently or in connection with the sale of goods. For automated requests of copyright fees, the model Linked Items is used. 1. Copyright fee a. Setting Defined on the resources card are the characteristics of the copyright fee such as prices and the accounting method for resources. Resources may be combined into groups of resources. The resources card can be closed and protected against unauthorised use. The resources card is used for setting copyright fees. Sales price and costs related to copyright fees are set independently. Prices and costs could be set for individual copyright fee cards or for a group of copyright fees. To set the accounting for a copyright, the General Accounting goods group and the VAT account for a goods group are used. b. Use The copyright fee is used in the sales document. On a line in the document, select Resources Type and Number from a prepared list of copyright fees. The copyright fee is entered independently and is part of the total price of the sales document. 2. Linked items The Linked Items module may be used for automation of requesting copyright fees during the sale of goods. The module enables defining the linked items for the goods on the goods card. When requesting goods with a setting with associated items, a line in the document will be automatically completed for each linked item. It is possible to set other goods than resources as linked items. It is possible to set more linked items for each item of goods. 3. Printing documents with copyright fees The copyright fee line is recorded in accounting as an independent line for the entered sales document. In order to enable printing of the sales document without the copyright fee line, reports for entered sales documents are possible at the marker Print Selection Options for Copyright Fees – Yes/No to select or block printing of the copyright fee line. The initial setting is No, to not print the copyright fee line. The selection does not affect the document price. 5.4.7 Static sets Uniform Solution: Because it is unnecessary to use any functionality of the Configurator for static sets, the standard function Navision - [DEL: Piece List :DEL] [INS: Bill of Materials (BOM) :INS] is used for recording static sets. The functionality of the [DEL: piece list :DEL] [INS: BOM :INS] is expanded below: · [DEL: Piece list :DEL] [INS: BOM :INS] variants Added in the component definition of the [DEL: piece list :DEL] [INS: BOM :INS] are the following: monitoring the code for [DEL: piece list :DEL] [INS: BOM :INS] variants, the Parent Item Variant Code field has the main key table for the component Parent Item No., Parent Item Variant Code, Line No., modification of which enables setting the list of [DEL: piece list :DEL] [INS: BOM :INS] components with regard to the [DEL: piece list :DEL] [INS: BOM :INS] variant code. · [DEL: Piece List :DEL] [INS: BOM :INS] Type[DEL: s :DEL] The [DEL: Piece List :DEL] [INS: BOM :INS] Type field supplements the items card. This field enables monitoring of the origin of the [DEL: piece list :DEL] [INS: BOM :INS] definition (Internal, MEV). · [DEL: Piece List :DEL] [INS: BOM :INS] Statistics The [DEL: Piece List :DEL] [INS: Bom :INS] may be sold as a whole or as a list of [INS: BOM :INS] components. In order for the determined possibility to monitor the movement of components during sales of the [DEL: piece list :DEL] [INS: BOM :INS] by component, the goods item is expanded by a [DEL: Piece List Goods :DEL] [INS: BOM :INS] [INS: Item :INS] Number. The number contains the original [DEL: piece list :DEL] [INS: BOM number :INS] used during the function [DEL: Expand Piece List :DEL] [INS: Explode BOM :INS] . Information is transferred to the [DEL: goods :DEL] item [INS: ledger entries :INS] during the [DEL: entry :DEL] [INS: posting :INS] of sales documents. · Printing the [DEL: Piece List :DEL] [INS: BOM :INS] Sales documents [DEL: Delivery Note :DEL] [INS: :INS] [INS: Shipment :INS] and Invoice enable selected printing of a line in the [DEL: piece list :DEL] [INS: BOM :INS] or a list of [DEL: piece list :DEL] [INS: BOM :INS] components. 5.4.8 Controls in sales orders Uniform Solution: Control of the accuracy of sales orders from customers in consumer material or paper according to contract conditions. Control is accessible in the Sales Order document and in the [DEL: dispatching :DEL] [INS: Dispatch Board in :INS] [DEL: s :DEL] [INS: S :INS] ervice[INS: Management :INS] . The functions of the service contract express customer requirements originating from the service contract. The [INS: Items :INS] [DEL: Goods :DEL] function types are used for monitoring the consumption of material. [DEL: Requirement type function item :DEL] [INS: Function entry type Request :INS] : The amount for delivery is set according to the setting for the given function. The customer requirement is expressed for fulfilment of the given function (services,[DEL: goods :DEL] [INS: items :INS] ) according to contract. [INS: Function entry type :INS] Delivery[DEL: type function item :DEL] : This is the delivered amount of the given function. The proposal for the delivery function is resolved by batch. The batch is carried out by a calculation of the required amount function according to the delivery calendar and a delivery log is proposed with the required amounts. The actual consumption function is recorded with an entry in the delivery log. By mutual comparison of the function item of the [DEL: Requirement :DEL] [INS: Request :INS] and Delivery functions, it is possible to monitor fulfilment of requirements from the contract. During order acceptance, a form is displayed for contract fulfilment with numerical functions at which the contract functions have been overdrawn (Delivery > [DEL: Requirement :DEL] [INS: Request :INS] ). 5.4.9 Control of sales price Uniform Solution: Function of sales line. The sales price may not be lower than the [DEL: acquisition price :DEL] [INS: unit cost :INS] . The function is set optionally in the [DEL: Setting :DEL] Sales and [INS: Receivables Setup. :INS] [DEL: Credit. :DEL] The function differs by the adjusted [DEL: acquisition price :DEL] [INS: unit cost :INS] and the non-adjusted [DEL: acquisition price :DEL] [INS: unit cost :INS] . The result of the function is an error message and a termination of the action. [INS: Unit cost :INS] [DEL: Acquisition price :DEL] resources. · [DEL: Goods monitoring :DEL] [INS: Item Tracking :INS] code During the sale of [DEL: goods :DEL] [INS: items :INS] with the [DEL: Goods Monitoring :DEL] [INS: Item Tracking :INS] Code settings (serial number, batch number), the [DEL: acquisition price :DEL] [INS: unit cost :INS] of the corresponding [DEL: goods :DEL] item [INS: ledger entry :INS] will be controlled according to the code for the Serial Number or the Batch Number. Otherwise by a control of standard sales. · [DEL: Comparing goods items :DEL] [INS: Ledger entries application :INS] When setting [INS: Entry No. :INS] [DEL: numbers :DEL] for [DEL: goods :DEL] item[DEL: s :DEL] [INS: ledger entry :INS] for [INS: application :INS] [DEL: comparison :DEL] in the [DEL: Compare Item Number :DEL] [INS: Appl.-to Item Entry :INS] field in the sales line, the [DEL: acquisition :DEL] [INS: unit cost :INS] [DEL: price :DEL] will be controlled from the setting for [DEL: compared goods items :DEL] [INS: applied item ledger entry :INS] . Otherwise by a control of standard sales. · Standard sales During standard sales without a [DEL: goods monitoring code :DEL] [INS: Item Tracking Code :INS] or [DEL: when comparing goods items :DEL] [INS: Application :INS] , the [DEL: acquisition price :DEL] [INS: unit price :INS] will be controlled by the oldest [DEL: goods item :DEL] [INS: Item Ledger Entry :INS] . 5.4.10 Cancelling reservations Description of current status: In the standard Navision system, there is no limit to the possibility for cancelling reservations conducted from the sales line. Uniform Solution: For restricting unauthorised sales of bindingly reserved goods, a selective cancellation of reservations is proposed. This solution simultaneously provides automated cancellation of reservations after their expiration. The module expands the functionality of reserving goods from a sales document in such a way that the person who conducted the reservation and/or an authorised person may release reserved amounts. Control will be used only functionally after the validity period of the reservation. Functionality will be implemented in all standard sales documents. When a reservation occurs, the ID of the user who performed the reservation (either automatically or manually) is recorded. A user control ID and the validity date of the reservation are added to the standard Cancel Reservation option in the reservation offer. This control can be bypassed only for previously defined groups of users in the sales settings. It will be possible for the system administrator to supplement the user group settings for those authorised to cancel reservations they themselves have not performed. For bulk cancellation of already expired reservations, a batch will be added to the periodic activities enabling bulk cancellation by the selected date. 5.4.11 Information on items in the sales line. Uniform Solution: A form with the numerical status of stock for any entered items in other locations in case of an insufficiency of items at the required location. The form displays only the location with a non-zero status of stock for the entered items. Display of the form is optional and it can be set globally in the Sales [INS: and Receivables :INS] [DEL: Settings :DEL] [INS: Setup. :INS] [DEL: area. :DEL] The function for displaying the form is added in the sales line, the [DEL: Amount :DEL] [INS: Quantity :INS] field. Functionality has also been added in the [DEL: Spare Items :DEL] [INS: Item Substitution :INS] form, the Function button, so that it is possible to display the form after the automatic selection of a [DEL: spare items :DEL] [INS: item substitutions :INS] overview. 5.5 Service Basic part of the Uniform Solution in service area is the conversion of the common functionality from the Minolta Service Module to the actual Navision version. Service area ill be allso extended with here described functionality. 5.5.1 Centralised Dispatch Board Uniform Solution: The central dispatch board will have the currently used Dispatch Board form; the General[DEL: Form :DEL] tab shows the basic view of the service orders list. It is used to set up default ranges and filters over an overview of orders. Other tabs may be used on the Dispatch Board form. Each Dispatch Board form tab shows ledger entries or details of a defined service area related to the service order selected in the General tab. Details of individual service areas will always be displayed as a list or a card on the corresponding tab. Tabs will provide options to run a particular service order functionality using a Command Button, which will enable using the mouse. For the functionalities defined on form tabs, it will also be possible to use hot keys. · Technicians (Resources) o Allocated Resources o Resource Allocation functionality o Resource statistics · Spare Parts o List of recommended spare parts o Components Recalculation functionality · Service Order o Service Item Line § Resource Allocation § Service Ledger Entries § Service Item Log o Service Ledger Entry o Service Invoice Line · Contract o Function Setup o Function Distribution Setup o Contract Invoice Calendar o Material Distribution functionality o Counters functionality · Documents o Posted Service Item Line o Sales Invoice Line o Sales Credit Memo Line · History o Posted Service Invoice Line 5.5.2 Counter readings over internet. Description of current status: The status of the counter for individual machines is currently determined in the following manner: · Direct deduction by technician during service visit · Deduction during delivery of consumer material · Telephone submission of deduction counters by independent customer on the basis of a summons All deductions outside of those conducted by technicians could lead to incorrect rates; deductions by technicians are costly since they must visit the customer directly. Uniform solution: Maximum effectiveness of the transfer status of counters for individual machines will be achieved with possibilities for direct submission of counters by end users via the Internet. In connection with the schedule in the service agreement, functionality will be prepared to ensure automatic dispatch of a summons to customers via e-mail so they may carry out deductions of counters and enter them into the appropriate place in the portal. Part of the e-mail will also be a URL reference for the appropriate pages. Data about submission of counter status via the Internet (date, time ...) will be recorded on the customer card, where it will be used for providing additional discounts, serving as motivation for individual customers toward this type of submission. The technical solution is very closely connected with point 5.4.5.1 B2C, and therefore two variants are proposed here. 5.5.2.1 Expansion of B2C If some variant of B2C is installed in the uniform solution, it will be expanded for the purposes of deduction of counters. Links to the service area will be added here and the functionality described for deduction of counters. For direct access to end users, a special role will be created ensuring the corresponding procedure. After applying, the user will see an overview of its machines and the corresponding agreements. After selecting a machine, the actual status of the counter will be displayed and it will be possible to add to the status of the required counters. If the machine also contains a virtual counter, this will be automatically calculated. After submitting the values, a control will be conducted directly in the portal of the advisability of the submitted data as well as validation against the contract. After confirmation of the submission, the data will be transferred into the system and simultaneously an automatic e-mail will be generated for the customer confirming the submission of the values. The functionality of the deduction of counters may be expanded in this solution for ordering consumer material or submitting requirements for service calls. 5.5.2.2 Solution on the basis of application server If no B2C solution variant is implemented, it is possible to deduct counter via Internet to resolve different methods. The expectation is, of course, the existence of a company WWW server. In the context of a 3-level architecture of Navision, for submitting information an application server will operate enabling defined user access. For access by users, a special ASP application will be created on the web server enabling communication with the application server. After applying, the user will see here an overview of their machines. After selecting a machine, the actual status of the counter will be displayed and it will be possible to add to the status of the required counters. If the machine contains a virtual counter, this will be automatically calculated. After submitting the values, a control of the advisability of the submitted data as well as validation against the contract will be performed at the level of the application server. After confirmation of the submission, the data will be transferred into the system and simultaneously an e-mail will be automatically generated for the customer confirming the submitted values. In the context of this solution, it is also necessary to create part of the verification and registration for users of the customer who have access to the submission of counters. This solution may not be expanded by additional areas. 5.5.3 Mobile servicemen The problem of mobile technicians – electronic order agenda, not bound to the momentary location of technicians, will be resolved by delivery from an external firm provided directly to the customer. In connection with the solution option, an interface will be prepared with Navision in such a way that the system is able to select and distribute the necessary data. The solution principle is displayed in the figure. The acceptance of a requirement in dispatching is always by a response stimulus. After assessing customer requirements and selecting the relevant technology according to defined criteria, the order will be assigned to the relevant technicians who receive an SMS report with this information. After receiving the information, the technician will connect to the system via mobile equipment and determine the necessary data about the assigned order. During the performance of the service call, the technician will again connect to the system where he/she can access important information about the preceding orders at the given machine and about the contract, etc. After completion of the order, the technician completes the task performed and the material used and allows the customer to confirm the acceptance of the order via mobile equipment. By return, the system sends a work performance confirmation to the customer’s FAX or e-mail, as well as a copy of the protocol or issued invoice. The technician can be connected technologically On-Line during the implementation of the order, or process data locally in the Off-Line regime and subsequently perform replication after again connecting to the system. Data will always be available on mobile technology about the orders assigned to the technician and the machines related to them as well as the status of the technicians stock. From his/her mobile equipment, the technician will generate requirements for supplementing auto-stock or for additional required spare parts. All operations from the mobile equipment will be relayed to Navision, where connection to the relevant documents (service orders, service object, location of auto-stock, issued invoices, etc.) will be determined. An analysis of the interface will be specified after the completion of the selection procedure of the vendor to the customer. After the analysis, the financial demand of the solution will be specified. 5.5.4 Calendars in SM contracts Uniform Solution: Two invoice calendars are used: 1. Invoice Calendar – an invoicing plan for contract functions concerning services, i.e. Source (copy, rent, charges etc). It allows to define the rules for invoicing services on the basis of service contract, and create an invoice for a particular customer. 2. Delivery Calendar – an invoicing plan for contract functions concerning goods (toner, paper and other material used). It allows to define the rules for invoicing material consumption on the basis of service contract, and create an invoice for a particular customer. Both calendars defined in the service contract are a basis for invoices created according to the contract. They allow to adjust invoicing and invoice management, and monitor the status of contract invoicing. The invoicing of the contract functions according to a calendar may result in credit notes. 5.5.5 Functions Uniform Solution: In invoice calculation fon any contract counter rules and counters are used.On the basis of these data and other options (minimum amount, etc.), an invoice is proposed for a contract. Amounts are invoiced either directly to defined accounts, or to selected sources. These accounts and sources are established for the entire contract. Unified solution: Functions are created to calculate invoices. Functions form a group of attributes and invoicing rules associated with a particular contract service item. Functions can also be associated with a particular meter for a particular service item. One meter can be associated with several functions. A particular function can be only once in a contract. In general, the function is a meter which performs back payment according to the number of clicks and respective rules, and for which the amount and price pre-paid can be adjusted. Individual units for a function may increase items due to the movement of the meter to which the function is connected, or by using other events (material supply, etc.). The meter can also generate “requirements” which can become a basis for material delivery. For example, a requirement can be generated after every 100 clicks of the meter. Subsequent supplies of material are automatically compared with the requirements generated and are invoiced according to invoicing rules, e.g. supplies, which were not delivered on the basis of the requirement. Both pre-paid and back-paid rules are defined for each function. In the case of pre-paid rules, it is possible to insert at least one line (if pre-payment is not used, no line is inserted) to define how the sum in a particular invoice will be calculated (if the number of units per function does not exceed the defined limit). Back-paid rules define a method of price calculation, if the number of units per function does not exceed the pre-paid amount. One example: Pre-paid rules: Too Many Prepaid Inv. Units Prepaid Units Included Unit Amount Prepaid Amount Not Deduct 12000 1.15 13800 Credit 3000 1.15 3450 Back-paid rules: Too Few Prepaid Inv. Units Units Unit Amount Invoice 0 0.98 Invoice 10000 0.96 These rules say: clicks in period what to do 0..11999 Not deduct, is pre-paid 12000..14999 Credit remaining units with Unit price 1.15 15000..24999 Invoice with unit amount 0.98 * 25000.. Invoice with unit amount 0.96 * · - unit price depends on back-paid price type (average or per unit) In this example 15 000 for the sum of 17250 units are pre-paid. If the number of units is within this limit during the period, prepaid rules are used. These rules are also used to generate pre-paid invoices. If the movement on the meter is posted, the movement on all associated functions for the particular meter is posted automatically. Contract invoicing also generates function items. These items are mutually equilibrated, providing an overview of how many units have been pre-paid and used, and how many units have to be back-paid. Each function has a defined source through which it is invoiced. Delivery functions are special functions. They contain information about the type and quantity of goods to be delivered to a particular customer. These functions can be controlled by a meter, or they only register the number of deliveries and allow subsequent multiple invoicing or delivery pre-payment. If these functions are connected with a meter, it is necessary to define lifetime functions. The lifetime function defines the number of clicks after which a requirement for material delivery will be created. These deliveries are then planned according to these requirements, or they can be delivered without any requirement and invoiced according to rules. Delivery functions are invoiced by special invoices, which have a particular invoicing calendar. 5.5.6 Technician groups by competence Uniform Solution: Source, Qualification Code Registration of qualifications is supplemented with the [DEL: Qualification :DEL] [INS: Competence :INS] Group numerical list. The [DEL: Source Qualification :DEL] [INS: Resource Skill :INS] table contains the [DEL: Qualification :DEL] [INS: Competence :INS] Group field. Each code in the [DEL: Qualification :DEL] [INS: Competence :INS] Group may be associated with several [DEL: Competence Source :DEL] [INS: Resource Skill :INS] codes. Each [INS: Re :INS] source may be marked by several Competence Group codes. Each [DEL: subject of service :DEL] [INS: Service Item :INS] may be marked by several Competence Group codes. 5.5.7 Pre-configuration planning Uniform Solution: Configurator A configurator, which defines an initial configuration of the [DEL: device :DEL] [INS: machines :INS] , is used for planning of pre-configuration. Purchase order The configuration prepared is used to create a sale order of configuration. The sale order is made for the location required. On creation of the sale order, the required components of configuration are automatically included into the Supply and Planning system. Missing components can be supplied via the purchasing system according to the parameters adjusted in the [DEL: Goods :DEL] [INS: Item :INS] card. Create a subject of service A configuration-type subject of service will be created from the sale [DEL: voucher :DEL] [INS: document :INS] prepared. The subject of service will be created by using the new function for the sale order: Create [DEL: subject of service :DEL] [INS: Service Item :INS] . The function makes a [DEL: subject of service :DEL] [INS: Service Item :INS] including service [INS: item :INS] components; it is similar to the function used to make [DEL: subjects of service :DEL] [INS: Service Item :INS] in the sales of [DEL: goods :DEL] [INS: items :INS] , but without sales posting. Subject of service The configuration-type [DEL: subject of service :DEL] [INS: service item :INS] is made from the line of the particular sale [DEL: voucher :DEL] [INS: document :INS] marked as Configuration – Yes. The components of [DEL: the subject of service :DEL] [INS: service item :INS] are made from the lines of the sale [DEL: voucher :DEL] [INS: document :INS] marked as Configuration – No. Service orders and service contracts can be created for the [DEL: subject of :DEL] [INS: service item of :INS] configuration[DEL: service :DEL] . 5.5.8 Service Pricelists Uniform Solution: Items In this area of the Service module, items pricelists are used as defined in Sales & Receivables, Sales Prices. Resources When resources are used, the pricelist to be used will be the one defined in Resource Price table. The resource pricelist will have additional fields Sales Type, Starting Date, Closing Date, Price Action, similar to pricelist functionality in the Sales & Receivables module. A resource pricelist import batch will enable to import pricelists into a table Sales Prices in an Excel format. 5.5.9 Absence registration for technicians Uniform Solution: Source Capacity The [DEL: Source :DEL] [INS: Resource :INS] Capacity [INS: Entries :INS] table allows to register the [DEL: items :DEL] [INS: entries :INS] of Absence-type [INS: re :INS] source capacity. [DEL: Source :DEL] [INS: Resource :INS] Absence [DEL: items :DEL] [INS: entries :INS] decrease the overall capacity of the [INS: re :INS] source in the Capacity field on the [DEL: Source :DEL] [INS: Resource :INS] card. The Absence [DEL: items :DEL] [INS: entries :INS] can be marked by an origin code. Registration of absence The Absence [DEL: items :DEL] [INS: entrie :INS] are entered in the [DEL: Source :DEL] [INS: Resource :INS] Capacity [DEL: sheet :DEL] [INS: form :INS] manually or using the multiple [DEL: Source :DEL] [INS: Resource :INS] Capacity [DEL: Configuration :DEL] [INS: Setting :INS] batch. The [DEL: Source :DEL] [INS: Resource :INS] Capacity [DEL: Configuration :DEL] [INS: Setting :INS] batch allows to enter both [DEL: initial :DEL] [INS: starting :INS] and [DEL: final :DEL] [INS: ending :INS] dates of a modification of [DEL: Source :DEL] [INS: Resource :INS] Capacity[INS: Entries :INS] , the number of units of capacity modifications on particular days during a week, or according to the pattern of working hours. Furthermore, the batch also allows to enter the required code for the origin of absence. The [DEL: Source :DEL] [INS: Resource :INS] Capacity [DEL: sheet :DEL] [INS: form :INS] allows to adjust Capacity [DEL: Item :DEL] [INS: Entr :INS] [INS: i :INS] [INS: es Type :INS] Filter and Absence Origin Filter to display the values of [DEL: Source :DEL] [INS: Resource :INS] Absence and [INS: Resource :INS] Absence Statistics according to an origin. Source Capacity Control In the area of service, the function of [INS: re :INS] source assignment is extended by an automatic control of the [INS: re :INS] source capacity. This control prevents an assignment of a source with insufficient capacity to a service order. The control calculates [INS: re :INS] source capacity including selected items of absence-type [INS: re :INS] source capacity. 5.5.10 Extension of service order Uniform Solution: The spare parts and other material recommended can be filled in [DEL: in :DEL] a service order. The list of recommended components is displayed in a separate [DEL: sheet :DEL] [INS: form :INS] ; a technician marks the individual items to select them for a particular service order. The items selected from the list of recommended spare parts are copied into to the particular lines of the service order. These lines of the service order enter the Purchase and [DEL: Supply system :DEL] [INS: Replenishment System :INS] . Spare parts recommended The list of recommended spare parts is registered for a particular [DEL: kind of goods :DEL] [INS: item :INS] from the table service item components list or from the item card BOM list attached to the service item card of the service order. The list of recommended spare parts is processed manually. Batch to find spare parts used An auxiliary batch for processing the history of completed service orders allows to make a list of recommended spare parts. The batch may update or fill in the item BOM list. The batch will also enable to update components of all service items having the same item number. The batch will prepare a table of recommended spare parts. 5.6 Statistics 5.6.1 Standard reports to HQ Uniform Solution: List of standard reports included in uniform solution. US – Uniform solution workshop Request – KM’ additionally request No. Report name Source 1 Accounts Payable – Fixed assets US 2 Accounts Payable – Other US 3 Accounts Receivable US 4 Accounts Receivable – Fixed Assets US 5 Accounts Receivable – Other US 6 Accounts Receivable–Chargeable US 7 Accrued Interest US 8 Advances paid US 9 Advances Received US 10 Age Composition Value/Qty request 11 Analysis I BEO US 12 Analysis I Camera US 13 Analysis II BEO US 14 Analysis II Camera US 15 Bad Debt US 16 Balance of Borrowings US 17 Balance Sheet US 18 Balance Sheet - Assets US 19 Balance Sheet - Liabilities US 20 Borrowings – cash and deposits US 21 Capital US 22 Cash Flow US 23 Cost of Sales US 24 Current Portion of Long-term L. US 25 Depreciation US 26 Details – Expenses US 27 Different technicians request 28 Dividends Payable US 29 Fixed Assets - intangible US 30 Fixed Assets - tangible US 31 Income Statement US 32 Interest Paid US 33 Interest Receivable US 34 Interest Received US 35 Inventories ( finished goods ) US 36 Inventory Amount of MFP US 37 Inventory Format BEO US 38 Inventory Format Camera US 39 Investments in Capital US 40 Last counter request 41 Logistic – stock report US 42 Logistic report request 43 Machines out of warranty request 44 Machines without contract request 45 Monthly Inventory US 46 Monthly P&L – Corporate US 47 Monthly P&L – MFP US 48 Monthly P&L – Photo US 49 Monthly P&L – Printer US 50 Monthly P&L – Radiometric US 51 Monthly P&L – Total US 52 Monthly Receivable US 53 Mostly used spareparts and consumables by technicians request 54 Net Sales US 55 Net Sales Dir.Sales by product group US 56 Net Sales tot. by product group US 57 Not visited machines request 58 Notes Payable – Fixed Assets US 59 Notes Receivable US 60 Other Accrued Expenses US 61 Other Accrued Revenue US 62 Other Current Assets US 63 Other Current Liabilities US 64 Other Prepaid Expenses US 65 P&L BEO US 66 P&L by Business Segments US 67 P&L Camera US 68 P&L lines US 69 P&L major account US 70 P&L Total US 71 Page Volume&Connectivity US 72 Prepaid Interest US 73 Purchases ( merchandises) US 74 PW new request 75 Sales and Copy Volume US 76 Sales Report request 77 Sales report Copiers US 78 Sales report Printers US 79 Service Cons Parts List request 80 Service Sinput request 81 Service original request 82 Service Report US 83 SGA expenses US 84 Shelf Warmer request 85 Short-term Loans Payable US 86 Short-term Loans Receivable US 87 Schedule of Purchases US 88 Sold-Disposed Fixed Assets US 89 SR2k4 data request 90 Statistical Items US 91 Warranties, Bonuses US 92 Working day of a technician request 93 Wrong counters request 94 Yellow Green Book US Requested reports details: 1. Mostly used spareparts and consumables by technicians Report about the mostly used (sold) spare parts and consumables by technicians Possible filters: Period Technician’s car stock First 1….99 consumables First 1.....99 spare parts This report helps to optimize the technician’s car stocks. 2. Different technicians A report about those machines, which serviced by different technician instead of who responsible for the report create a list of work reports which was done by different technician instead of who responsible for (defined on Service Contract card). Possible filters: Period >…% Serviced by different technician This report helps to distribute the machine fleet between technicians. 3. Working day of a technician Report about a working day of a technician. Report helps to control the everyday work of technicians. The report create a list by technician, by date about: Work report (Configuration Number, Contract Croup + Customer name&Code) Spent time by work report Travel time by work report Total used time by day Possible filters: Period Technician 4. Wrong counters The report calculates the monthly average of page volume based on counters which are registered previously and if the last counter stand is double higher than average the report make a list about it. The report helps to filter out the wrong counters. 5. Not visited machines The report creates a list about those machines, which are not visited by technicians since 3 or 6 months. The report helps to plan the preventive maintenance cycle for machines. The report should also show and filter customer, type of contract (example: not visited SM clients) Possible filters: Technician Number of months since when we didn’t create a work order, for a certain machine. 6. Machines without contract The report creates a list about those machines, which haven’t service contract one month after the selling date. 7. Machines out of warranty The report creates a list about those machines, which will run out from the one year warranty period and they haven’t valid service contact. 8. Last counter The report shows the last print counter (FA4P) and the last total counter (A4) by machine and by machine type. 9. SR2k4 data The report gives the data of SR2k4, appendixes. 10. Age Composition Value/Qty To combine the Item Age Composition Value (prev.report 5808) and Item Age Composition Qty (prev.report 5807). It must be seen the quantities and values in the same report, appendixes. 11. Service Cons Parts List Service report, XLS format, appendixes. 12. Service original Service report, XLS format, appendixes 13. Service Sinput Service report, Sheet MATRIX-MASTER-30, XLS format, appendixes 14. PW new SALES REPORT Page Volume & Connectivity per moth, XLS format, appendixes 15. Logistic report Logistic report which should show value of stock by Inventory posting Group and by General Product Posting Group for ex. Copier analog, Copier digital, Copier Color, Copier consumables, Printer Consumables, Copier Accessories, Printer Accessories and also ranges 16. Shelf Warmer Shelf warmer Report 17. Sales report Sales report for Copiers, Fax and Printers - This report should: - give us the data of purchased and sold pcs by each model machines. Sale should be divided on Direct and Resell (dealer,distributor,reseller..) - give us the data of pcs on stock at the end of the month my each machine model. - give us the data of purchase amount of analog copiers, digital copiers, Color copiers, printers, consumables- copiers,consumables- fax, consumables- printer, accessories- copiers, accessories-fax, accessories -printers, spare parts - give us the data of sale amount for the same categories divided to direct and resell ( dealers, distributors, resellers) 5.6.2 Manager screen Uniform Solution: A dynamic menu will be used for creating a manager screen. This menu can be modified without the use of the Designer tool. A description of options and linked operational objects will be controlled with the help of tables designed for this purpose. Settings can be exported and imported in such a way that it would be possible to target the same settings in all countries. The option content menu will be only at MNCC. It will be possible to run any selected object (forms and reports) from the menu. Rapid reaction to the needs of managers will thus be provided without the necessity of conducting modifications in the application. 5.6.3 SCA analysis Uniform Solution: Report to be run with the following filters and options: · PostingDate: date filter specified by user · Item Number, Symptom Code, Fault Area Code, Resolution Code, Branch, Preferred Resource · Option: Print details (Yes/No) Report sum fields in table Posted Service Invoice Line · Number of Visits · Working Time Hours where Working Time Hours - number of hours for Working Time (Work Type Code marked as Work) Report create totals and subtotals: · Item Number · Symptom Code · Fault Area Code · Resolution Code · Branch · Preferred Resource Option Print Detail: Print details – No · Total field name · Number of Visits · Working Time Hours Print details-Yes Detailed list sorted by Service Item No., Posting Date. Detailed list fields: · Service Item No. · Serial Number · Customer No. · Customer name · Service Order No. · Posting Date · Counter Code · Entered Units 5.7 Common Tasks 5.7.1 National language layer Uniform Solution: To translate the application, cooperation with individual countries is necessary. A file containing individual items designated for translation will be sent to each country. The file will contain the text identification code, text in English and space for the translation into the local language. In this file, individual countries will perform a translation from English into the local language and send the modified file back to FE. In case of a modification, only the different file will be sent, containing just the text that has not yet been translated or that which has been modified. In this case, the original English text prior to the change and the original translation prior to the change will be included in the file. FE will not conduct a control of the translation. 5.8 Data conversion Change to Uniform Solution in all KMBS-LS will be done as a “New start”.[INS: NE :INS] History of machines without accounting information will be transferred to special tables. From actual Navision following tables will be converted: · [DEL: Supplier :DEL] [INS: Vendor :INS] table · Customer table · Item table · [INS: Fixed :INS] Assets table · Service item table · Service contract table · Pricelists · Chart of accounts · Start stocktaking · Entry state of accounts · Entry state of assets · [DEL: Supplier :DEL] [INS: Vendor :INS] saldo · Customer saldo 6 Time Schedule of the Delivery 6.1 Target Solution Draft Delivered by supplier by: 19.2.2004 Reviewed by customer by: 18.3.2004 Accepted by customer and supplier by: 6. - 7.4.2004 6.2 Licence NAVISION: Delivered by supplier by: 6.3 Implementation[INS: neodpovida tomu co jsme podepsali v kap4.2. smlouvy. :INS] Screen prototypes : Screen prototyping delivery to server by: 14.4.2004 Reviewed by customer by: 28.4.2004 Functional prtotypes I: Functional prototyping delivery to server by: 2.6.2004 Reviewed by customer by: 23.6.2004 Functional prtotypes II: Functional prototyping delivery to server by: 7.7.2004 Reviewed by customer by: 21.7.2004 Training :[INS: viz 4.2.8. smlouvy :INS] Hannover of training methodology by suplier by: 28.8.2004 Start of training by: 6.9.2004 Completion of training by: 30.9.2004 [INS: Nevidim jak bude splnen bod 4.2.5. a 4.2.9. smlouvy :INS] 6.4 Akcceptation Start by: 25.8.2004 Termination by: 20.10.2204 6.5 Productive run Start by: 1.11.2004 7 Project Risks · The version of Navision used in KMBS-LS except BCZ is not the current updated version which was released for distribution and Minolta Service Functionality is implemented in contradictiction to standard Service Module Arrangement: Within the delivery of a Uniform Solution the supplier will provide an upgrade to a higher version of NAVISION in those modules which have been or will be purchased and whose status will enable this. Implementation of Uniform Solution will therefore need a new start of the system in all KMBS-LS. · In somme KMBS-LS local changes are used that can be in conflict with the Uniform Solution. Arrangement: Uniform Solution is a master set of objects. Local changes will be merged by LMBSP under survey of FE. 8 Conclusion The handover of the target solution draft and takeover by the customer means the termination of data gathering and analysis. After the process of all feedback, possibly including further suggestions by customer employees, the Target Solution Draft is then agreed upon by both contracting parties. The final project will be assessed based on comparison with the Target Solution Draft. 9 Appendices 9.1 Appendix 1 Target Solution Draft - Price Offer Uniform Solution 9.2 Appendix 2 Customer supplied documents 9.3 Appendix 3 Datasheets for barcode [DEL: reader :DEL] [INS: scanner :INS]