The Conceptual, Logical, and Physical design documents are the central components of the project. The target audience for the documents are:

Conceptual: People who require an overview of the requirements and a summary of the solution. This would probably include people who aren’t directly involved with the implementation, but need an understanding of what the solution will entail for them and their department.

Logical: An intermediate look at the solution. For those who require details of the interfaces and components being used. Developers will also find the document useful for understanding to a reasonable level the other pieces of architecture they are plugging their solution into.

Physical: The actual design specification for the solution. Developers and reviewers of the solution need to go to this level. Functions, Structures, and Application Interfaces are fully modelled in this document.

The goal of the Conceptual design is to identify the business needs and to understand what the users do and what they require. It does not cover in any great detail the approach taken or the technologies used to build the solution. This is covered in the Logical and Physical design documents. This document should be written in non-technical language that both customer and supplier could understand. This document corresponds very closely to a traditional requirements specification document.

The Logical design’s aim is to organise the details of the application that the team will build to fulfil the business needs and user requirements. The Logical design will layout the structure of the solution and the communication paths among elements. This document does not contain the detailed blueprint for the solution, but should provide the methodology for doing so.

The goal of the Physical design is specify which logical pieces fit into specific physical pieces of the architecture. It also addresses any outstanding technology issues or constraints. The physical design corresponds to a contractor’s blueprints for a building. The contractor’s plans add detail to the architect’s plans and reflect real-world circumstances. This document is written in technical language that requires technical and possibly programming knowledge to fully understand the plans. This documents corresponds very closely to a traditional design specification document.The goal of the conceptual design is to identify the business needs and to understand what the users do and what they require. It does not cover in any great detail the approach taken or the technologies usedr to build the solution. This is covered in the Logical and Physical design documents. This document should be written in a non-technical language that both customer and supplier could understand. The Conceptual, Logical, and Physical methodology is based upon Microsoft’s Framework Component Design Model.

The basic requirements is to deliver a Sales Reporting tool which addresses the following:

• Produce sales reports of very high High presentation quality
• Allow High configuration of data selection, presentation, and formatting options
• Eliminate the need for manual transcription of data from the ERP system
• Allow the tool to work on generic data for any mainstream Sage UK product
• Work off an intermediate storage (a "superset" data warehouse) for the production of reports.
• Ensure the tool can be used in the future as a foundation for a product wide reporting tool
• Ensure that the tool can be used by people whop are not technically literate (i.e. do not understand database technology).
• Via an "Excel" grid like mechanism people should be able to build as simple or as powerful reports as they wish without getting swamped by too much detail
• Integration with other packages like Word and Excel is essential.
• The configuration of reports must be dynamic in that it should be possible to specify additional categories from the accountancy system.
• There should be an ability to make adjustment to grid cells to correct anomalies
• Preserve any formatting changes which have been applied to the Report output

• SES Report Writer
• SME Report Designer
• Business Objects
• Cognos
• FRx
• Crystal Reports
• Timeline
• Office XP (particularly Excel) / 2003
• Winforecast
• Excel Pivot Tables
• SQL Server
• SQL Analysis Services

• John O’Connor (Newcastle Reporting Team)
• Guy Letts (SME Director)
• David Karlin (CTO)
• Central Projects
• Mark Gamble (L50 Development Manager)
• Mark Spencelayh (L100 Development Manager)
• Stuart Lynn (Newcastle Development Manager)
• Paul Dayan (Newcastle Reporting Manager)
• Alistair Ledbetter (Winforecast)
• Andy French (L100 Product Manager)
• Yash Sarnaik (L50 Product Manager)
• Justin Healey (SES Development Manager)
• Graham Cardwell (SES Product Development Manager)
• Nick Voller (SES Technical Product Development)
• Suzanne Corcoran (Sage Ireland Development Manager)
• Brian McIntyre (Sage Ireland Technical)
• Kathryne Jobling (Payroll Development Manager)
• Jim Walker (Manchester Development Manager)
• Tony Thomas (TAS Development Manager)
• Darren Liddell (Developer Support Manager)
• Klaus Michael Vogelburg (Chief Architect – Sage Group)
• Lori Maloof (Best Software – Sage US)

• Gartner (discounted re: Guy Letts conversation 23/1/2003)
• Financial Planning using Spreadsheets (Sue Nugus)
• OLAP with Analysis Services (Gunderloy Sneath)
• Sage User Group (SME market space)
• ISTUG (independent Sage User Group)
• Input from Accountancy body
• SAS Institute
• Sage Resellers
• Accountants in Practice (Baker-Tilley)
• ICAW IT

can be converted. Thus a great deal of time is required to re-enter (manually or automatically) the same data that was available before. Most conversion processes when moving product with only cover the static master tables such as Customers, Suppliers, Stock, and Nominal Ledger codes.

With the proposed solution customers must be confident that virtually all-important data will be brought across, and the costs (in terms of time and money) of the data migration will be minimal.

Currently, Sage products are protected from use by an existing registration system that requires users to enter a serial number and activation key. The serial number allows installations to be tracked while the activation key determines the configuration for the product – the number of concurrent users, companies, etc. In addition SES licences each individual company with a SOP generated password as present (although this is planned for change to match the rest of the group).

The current system uses fixed activation keys for each recognised product installation. Therefore, not only can activation keys be exchanged between users, they are also widely known outside Sage allowing users to obtain a product and run it without registration.

This registration model and the practices of those that circumvent it is are believed to be costing Sage a significant amount of lost revenue.

The data used in the reports she be sourced from anywhere in the Accountancy system. The ability to specify "dimensions" is crucial. The report order, groupings, and rationalisation is are important.

The layout of the report has to be fully configurable. The aim would be to get it to Excel or Word standards.

Once configured the ability to extract information from the finance system, and produce the report should be automatic. No, and require no manual intervention should be required in order to produce the report.

The concept of a generic Data Dictionary would be employed for this project. What this actually means is that a superset data model is used to pipe in data from any Sage UK source. For example the Generic customer is capable of holding all the information defined in a Line 50, 100, or 200 Customer data record. By doing this reports can be generated based on the Generic model, thus reducing the time spent writing reports across the group’s products.

As part of the method for implementing a generic data dictionary we require a central storage area (or Data Warehouse). The Data Warehouse comprises a Database such as SQL Server which Server, which sucks in data from the required data sources and makes the information available in a structured fashion. The data is periodically synchronised from the data sources (such as Line 50 / 100) to ensure the reporting data is fresh up to date enough for its purpose.

Although it won’t be the case that this tool can be used for any reporting purpose across the anan Accountancy product, a number of the components need to be available for this future task. This means delivering the functionality in a modular and structured framework.

One of the key problems with all existing reporting products is that it requires really good technical skills to produce reports. This is because the person creating the report often has to do the work to get the data in the correct state so it can be reported on. This includes setting up the "dimensions" of the report.

This reporting tool has to be "simple" enough so that Salesmen (with no technical IT skills of note) can have to be able to get the information they require from out of the system. Although it may be agreed the most powerful reports will still need IT literate people who understand the data, it should not prevent basic users from extracting the information they require.

A grid like mechanism will be made available for report configuration and configuration and report viewing. Very much like a standard spreadsheet style mechanism (such as Excel), in its basic form it will be simple and easy to use. More advanced and powerful features will be hidden from the casual user.

Excel is the base tool used to run virtually all companies. It is probably the most widely used piece of computer software in the business arena. Although an average Excel user may not know how to use the advanced features like creating Pivot tables, using, using the product would not be an issue to the vast majority of users.

This being the case it should be possible to use a suitable technology (OLE) to input / output to and from Excel and even Word.

Besides the main and obvious categories (ie. Region/Salesmen/Product etc), it should be possible to specify additional categories, providing the information is available and it can be linked to the Sales information.

Obviously with additional "free-to-use" columns throughout the accountancy packages it is possible for users to use them to store additional information. It should be possible to users to stipulate these extra fields as categories in their reports. This will enable as flexible and as powerful of reporting as possible.

Basic financial data

Static data

Outstanding transaction data

Transaction history

Advanced financial data

Manufacturing data

With all systems there will be invalid data that has slipped through. For example if a typoe on an Invoice was meant for £1,000, but was entered as a million, or records were posted into the wrong financial ledger. This being the case it should be possible to define rules, or manually adjust these figures in order that the report produces sensible information.

It is critical that the changes made are recorded and listed at the end of the report. This will ensure that financial mis-accounting does not take place.

The solution should have the ability to retain any formatting that has been applied to the report output. For example if the report is output vehicle is Excel, there should be a mechanism that any cosmetic formatting applied will not be lost when the report data is refreshed.

As part of securing up licensing of the products, the solution can also provide a valuable CRM function. With accurate CRM information customers can be targeted with the right sales campaign. It also saves time, money, and embarrassment by ensuring the wrong marketing drives do not end up with the wrong customer (ie. A Line 100 upgrade campaign for someone running Line 500)

PA part of a latter phase should include automatic licensing should be included.. However for this first phase, the only two methods of solution delivery will be via phone (help/support desk), and web (hosted sage.com website).

Functionality, Usability, Reliability, Performance, Supportability.

Functional requirements may include:

Key to name abbreviations:

CP: Central Projects

DJS: Dave Stokes,

GL: Guy Letts,

DK David Karlin.

LM: Lori Maloof (Best Software)

AL: Alistair Leadbetter

The resource estimates at this stage are based on experience and gut feeling. The value is based on the time to design, code, test, and implement the item. The estimates will be revised as the Logical and Physical design work is completed. As a guide resource estimates are as follows:

Low: 1 day

Medium: 5 days

High: 20 days

V High: 50 days

Throughout 2003 Central Projects resource available is estimated at 70 days / month for the project.

Must allow upgrade between all possible Sage UK products

• To work with either Line 50, Line 100, Line 200, or Line 500.
• An OLAP cube will be required to satisfy the speed and flexibility of the solution
• Data must be able to be selected and viewed via:
• Ranges
• Wildcards
• Different column order
• Multiple tables
• Ignoring NULL or small (< .01p) values
• Manipulation of extracted data must include
• Ability to add columns
• Use calculations to populate new and existing fields##
• To be able to dynamically interpret data. I.e change value "001" to "Fixed Assets". This could also involve wild-card substitutions.
• To flag exceptions in the report. Ie. Where data has not been attributed into a "bucket" Must bring across static data, balances, transactions, and historic data with the minimum of fuss.
• Users can process, cleanse, and rationalise their data to remove anomalies
• Should allow conversion on a company by company basis
• Counts of rows in each "bucket" and sub-totals / totals
• To publish the reports so that it only needs running once to be made available to others, and also to have it in web and hard copy form.
• Automatically email / publish reports once complete.
• It would also be nice to have the facility where key data is published in a form of "ticker-tape" presentation of people’s desktops.To adjust reports to be viewed optimally on paper or on screen.Support the import of 30 line records (ie. 1 row which contains an array of 30 lines – such as Journal Ledger), into 3 records, each of arrays of 10. This is required for the SES ANSI conversion. Basically the routines needs to support 1-to-many and visa versa.
• Errors should be able to be viewed as the utility is running
• Users should be able to break out and stop the utility at any point during the import.
• Products like SES have multiple extension tables for one master table (ie. Sales Customers is made up of about 20 tables). Views could automatically or manually be available to make the product more seamless and import definitions more understandable.
• Allow a SQL style "where" clauses when importing data from tables. Ie. All records after a set date.
• The solution must cope with generic tables (ie. Sales Customer and Sales Customer archive have the same structure and rules, but have different filenames).
• Rules to cope with standard "system key" data into the new system. Eg. NL coding structure
• Standard base rules controlled by the Data Dictionary (ie. Totals, SQL statements, Reporting mechanisms)
• Standard base rules controlled by the Data Dictionary (ie. Totals, SQL statements, Reporting mechanisms)
• VBS (Visual Basic Script) has built in parsing for error checking
• Handles reserved Database column names
• Standard rule to cover duplicate records (ie. Deleted 2^nd and subsequent)
• Standard operations carried out by pre-defined functions (Microsoft refer to these as Functoids), which are under-pinned by Visual Basic Script (vbs).
• Advanced free format VBS with embedded SQL statements being supported.
• Renaming of columns should be supported (required for SES ANSI conversion)
• All rules, and changes could be optionally stored, so conversions can be re-run on the same data set.
• It should be possible to run the validation/rationalisation part of the utility in isolation, so existing Sage customers could use it to validate their existing data before, for example year end.
• Strict control of what products can be migrated to what (licensing?)
• Identify and target external products to migrate from. Ie. SAP to Line 500. (Phase II)
• It must be able to identify when users have added extra columns to their tables.
• The product should be able to "guess" at the disk space required for the conversion
• It will internally handle MSDE Database creation etc.
• For users to be able to Preview the data changes in either a cosmetic (Order Status is classed as ‘On Hold’, and a column name is Cuscode) or raw view (Order Status is a "0" and a column name is Customer Code).
• As a phase II deliverable the product should ship with the standard reports that accountants run to validate their data (ie. NL TB etc). The reports should be capable of being run on both the old and new system. This would enable a like for like comparison of the data before and after the conversion. The initial delivery might be Excel style pivot table reports.
• Allow Find/Replace functionality within the previewing area of the data
• The reports will work the same regardless of what product it is running for
• Reports will be written once, and will work with all the products. The details on the reports may vary depending on the complexity of the product concerned.
• Reports should be able to be scheduled.
• To integrate input and output via OLE objects to Excel and Word
• Reports will be made up of two axis
• Date/time
• Financial / physical periods
• Categories
• Product, locations etc
• Adjustments
• It will be possible to temporarily modify date being view in the reports. This will be audited at the end of the report.
• The basic engine this project produces, must be re-usable for the larger Sage Reporting tool project.
• Handling of different sized chunks
• It should be possible to group sales into ranges of different sizes. Eg.
• £100,000+
• £75,000-£100,000
• <£75,000
• Must be able to store and use Logins/passwords/data sources/company etc in order to access the required data.
• The system must be able to use static "lookup" tables and get currency spot rates
• A key feature is to drill in and out of data.
• The system must be able to view along side previous years data.
• General Analysis including:
• Trend identification and analysis for standard deviation from budgets and forecast.
• Regressive analysis
• Support multiple moving averages, and weighted moving averages.
• Adaptive filtering
• Analysis of time series and expected values.
• Variance from mean
• Forecast probabilities
• Deterministic planning.
• What if and risk analysis
• Ability to refresh reports without looking formatting if it is stored in Excel or WordLine 500 will require attention as to who can access what data. Salesmen targets, budgets, and payroll information is particularly vulnerable.
• On the other end of the spectrum, Line 50 will need little or no protection. Not covered in Phase 1 deliverable

Usability requirements may include such subcategories as:

• Human factors
• Simple to use interface, which hides all complexity to the standard users
• Ensure that any of the following users can and create and run reports:
• Sage report designers
• Resellers
• PC literate Salesman, Sales manager or Finance Director
• IT specialists
• Non technically literate users
• Aesthetics
• Reports will consist of either
• A printed, page numbered document
• Made up of :of:
• A Fframing document (page sequence, headers, footers etc)
• Report worksheets (a spreadsheet containing cells of the data)
• Report rows / columns which make up the report worksheet
• A series of Web pages connected with hyperlinks
• It is made up of:
• Framing document (home, and other web pages)
• Excel style worksheet
• Report rows / columns (collapsible)
• Hyperlink facility Drill in facility
• The user interface for creating "dimensions" needs" needs to rival that of Excel pivot table functionality.
• Date formatting needs to be possible.
• Ship with standard forms, templates, and graphs Graphical editing of the Data Dictionary mappings etc.
• Consistency in the user interface
• Refer to the Sage UI guidelines
• Online and context-sensitive help
• Yes. Level of complexity to be decided
• Wizards and agents
• Create report wizard will be required
• User documentation
• Users guide will be supplied
• Training materials
• Outside the scope of development.

Reliability requirements to be considered are:

• Frequency and severity of failure
• Frequency of failure must be very low
• Recoverability
• Base data is left untouched, so "rolling" back will not be an issue
• The user MUST ensure a backup is taken before the conversion takes place (ie. For example both the source and destination products use SQL Server, or the machine running out of disk space causing the operating system to crash)
• Predictability
• NA
• Accuracy
• Consistency of data paramount
• Mean time between failure (MTBF)
• NA

A performance requirement imposes conditions on functional requirements. For example, for a given action, it may specify performance parameters for:

• Speed
• Synchronisation of data generally would take place overnight.
• Reports should take seconds->minutes. No report should take longer than an hour.
• The Reseller Impress have stated that if the report is run locally it should either not tie the PC up, or if it does the report finishes inside 5 mins. If it does not tie the machine up, or it can be scheduled then speed is not that great an issue. Small sites: Several hours
• Medium sites: Overnight
• Larger sites: Weekend
• Efficiency
• NA, providing Speed is adequate
• Availability
• NA
• Accuracy
• Performance accuracy will be measure in the utility. Speeds are expected to be consistent.
• Throughput
• Data sets up to 50GB expected.
• Response time
• NA
• Recovery time
• NA
• Resource usage
• Complete use of all the Server machine’s resources are expected.

Supportability requirements may include:

• Testability
• All possible product/project/module combinations will need testing
• Extensibility
• New products can be "plugged" in once mappings exist
• Adaptability
• As above
• Maintainability
• Critical to the product is the maintaining of an accurate data and object model for the data.
• Compatibility
• A common denominator of an embedded Database Engine (such as Microsoft Access or MSDE, the shrunk SQL Server) would provide a low cost solution, which has sufficient power to carry out all the required Database style operations.
• Any storage mechanism that supports ODBC can be used
• . CSV (Comma Separated Variables) via ODBC also
• Install the ODBC drivers on the execution machine – Otherwise the utility could only run on the machine where the old and new products reside.
• Configurability
• Allow updates of other tables / rows when importing a different file. Ie. Update the Customer Year to Date figure while importing the Sales transactions. This means record updates should be possible, not just inserts.
• Utility should be run in silent and interactive mode
• Overwrite existing records in destination database.
• Delete import file/table after successful import
• Clear down error log when complete

• Transaction integrity ie. Import single rows at a time or batch together operations in an atomic fashion.
• Delete import table before migration
• Create empty blank new tables
• Timings for each table so an estimate for the final live conversion is possible
• Serviceability
• Critical to the product is the maintaining of an accurate data and object model for the data.
• Installability
• Not expected, although data integrity is essential
• Localisability (Internationalisation)
• Not applicable in phase 1

4.4.1 Can we rely upon a Data Warehouse or is there an immediate requirement to work off the live data?

4.4.2 For the initial release can we use Excel as the output / formatting engine?

4.4.3 Does the solutions have to work with Microsoft Access?

All projects are bounded by the triple constraints of time, budget, and quality. It is important to identify their order of importance, along with noting any trade-offs that would need to take place between them. The constraints are rated as follows:

Driver: Driving force of the project. This must be achieved at all cost or the project is a failure.
Middle Constraint: Second in order of importance.
Weak Constraint: The constraint we will take from first to help the driver if/when it gets into trouble.

The two dynamic components that using poling (one way or the other) are the Scheduler and Synchronisation parts. The Synchronisation part ensures that the data is kept up to date in accordance with how fresh or stale the customer wants their data to be requirement is. The scheduler is responsible for kicking off reports at the desired time.

Data preparation is done in several stages. Firstly the Transformation components sucks the data from the desired accountancy system and transforms the data into a generic superset structure which can house the format of the data being send to it. From the Generic database data is pulled out (pending the security checks to ensure only the right people have access to the data) into the "OLAP cube". This is the engine that organises the data into the right "buckets" of the same data (ie. Sales of red widgets in the UK during August) basically like a postal sorting office. It ensures all the data items are placed in the correct "pigeon hole" when the report actually needs the data. The primary reason for doing this is speed.

When the scheduler kicks off a report the Report Generator engine will produce the raw report based on the data required. It will pull all the information it requires from the "OLAP cube" (calculated financial information etc), and the Generic database (static and simple data).

The raw report can then have the required styling applied to it to produce the end report. The end report is then made available to be printed, or exposed made available for publishing on the web.

The solution is a two-tier solution, which treats the end-user’s PC systems as a single tier (whether they have separate clients and servers or not) with a central licence-processing tier working in Sage’s environment.

The Enforced Registration Service system is responsible for generating Enabling Keys and managing interaction with users over the automated channel. Sage Internal Systems (IS) are responsible for managing the manual interfaces, licence details and any supporting applications and databases. Access to Sage IS’ applications or data from the Licensing Application will be through a "CRM Application" using an interactive messaging protocol, and vice versa. No file transfer processes will be used.

Licensee installation (can be at an agent’s site) comprises at least one server and zero or more client PCs. For many smaller customers, the server and client is the same computer and the software will manage this appropriately.

Upon invocation, the utility will have access to the product Data Dictionary that outlines what products he can converted from and to, and also which tables and columns it can deal with.

Kicking off a new "Project Creation wizard", the user will select which product, tables they wish to convert. Next the location of the old data will be prompted for. This will be in the form of using an ODBC driver entry. A standard or bespoke set of build rules can be applied at this point that will rationalise the data when required to do so.

All the above information will be saved to a "project" file, so that configuration and cleansing operations are stored to re-runs of the conversions etc.

Once the "OK" button is pressed the data will be extracted from the old system and pulled into an intermediate database (ie. Microsoft Access Engine). The rules selected will be applied to that data, either modifying and correcting the data or just in read-only mode highlighting the potential errors.

The user at this point they can either apply more rules, modify the data manually, or reject it all together.

Once they are satisfied with the data it can be exported via a different ODBC entry to the new system. The rules and changes applied are stored so that subsequent conversions can also use the previously defined modifications.

The Data Dictionary definitions, which contains the data description and rules, is critical to the quality of the conversions. As part of Data Dictionary project schemas and editing tools will be available for maintaining the mappings and the rules.

5.3 Components

The information is generated using a new program supplied by the registration solution, or the program is embedded in the application (ie. A function API library or DLL) that the user is trying to register. This program grabs machine specific information (ie. Hard Disk, Network card etc), and then creates a registration key (ie. 4324-4532-5432-6432-6535-5435).

The registration key and customer ID can now be supplied to the helpdesk or web site. The customer will then be supplied with an enabling or activation key, which is in a similar format to the key they supplied. This key can then be used to register the product.

At any time the local Sage application can check whether the system is correctly licensed by again calling from the supplied ER functions. These functions return the licence details supplied and also validate that the licence is actually for the machine the product is running on. For items such as max concurrent users, the functions will only return what the product is licensed for. It will be up to the local Sage program to compare to the currently active users, and take appropriate actions.

If the hardware changes enough, the licence expires, or anything underhand goes on, the licence will become null and void, so forcing the end user to register the product again.

The above work will need to be carried out by the ER system and the local Sage product.

The role of the sage.com hosting pages is to accept the users details (customer id and client’s registration key), validate them via the CRM system, request additional CRM information, ask the Licensing Registration application for a enabling key, and then return it to the client, storing the information as it does so.

The sage.com system is the central component of the solution. It will access and update the CRM data via the SalesLogix APIs. The role of Sage Enterprise may be redundant.

Sage.com will call the licensing functions of the ER system by an agreed web ASP/API interface.

The role of the helpdesk, just adds an extra layer of communication to the process. The registration process will still come through the sage.com registration pages (be itn via Internet or Intranet).

The work will need carrying out by IS (Web, IT services, Support etc)

The ER system will take the client registration information, the customer ID, and the CRM information (ie. Max-concurrent users, modules etc), and then create an encoded enabling key. This can then be stored by the CRM system before returning to the customer.

It is important for the CRM system to store this data for future reference, validation, and marketing purposes.

The actual encryption methods employed by the solution are deliberately not documented here for security reasons. The Physical design document will cover the process involved in the encryption and key exchange.

Software and Hardware testing combinations is found in the Logical Design

• Functionality
• Compatibility
• Will it work with Line 50, 100, 200
• General
• Will creating the report for one product work for another (excluding the output format)
• How easy is it to set a report up for a non-technical person
• Foreign Currencies
• Performance
• Will all reports finish in a reasonable amount of time
• Selection and Transformation of data
• Can we select ranges of records
• Wildcard searches of records
• Does the data come out in the order we want it
• Can it support reporting from multiple tables
• Can small values (< .01) be ignored
• Is it possible to build up calculation columns
• Can string values be dynamically interpreted
• Does it have the ability to display negative numbers in red
• Report Sections
• Report Headers / Footers
• Page Header / Footers
• Detail sections
• Multiple Group by sections
• Constants and pre-calculated fields
• Calendar values (Day, Months etc)
• Financial dates (Period, Quarters etc)
• Budget, Actual, Variance
• This year / previous year
• Working days
• Reporting name, author, description etc
• Currency conversion
• Description lookups
• Sales Groupings
• Product
• Code
• Group
• Volume
• Price
• Price Band
• Customer
• Orders
• Salesmen
• Post Code
• Region
• Type
• Account Manager
• Other
• Cost Centre
• Department
• Account Code
• Currency
• Business Intelligence
• Forecasting, What If, Risk Analysis etc
• Joins
• Inner, Outer, Cartesian
• Errors
• Anomaly identification
• Anomaly correction
• Formatting
• Alignment
• Fonts, Colours, Italics
• Boxes
• Bitmaps
• Output
• Drill downs
• Excel integration
• Email publication
• HTML web support
• Print output
• Print preview ability
• Print areas
• Paper fit and formatting
• Scheduling of reports
• Access restriction to certain reports
• Synchronisation of the data
• Run in silent mode
• Usability
• Human Factors
• Simple to use Interface
• Usable by
• Sage Report Designers
• Resellers
• PC literate Salesmen
• Sales Manager
• Finance Director
• IT Specialists
• Non Technical Salesmen
• Aesthetics
• Printed Report
• Does it have a framing document (sequence / headers / footers)
• Report Worksheets
• Report rows and columns
• Web Output
• Does it have framing document (Home page)
• Excel Style worksheet
• Collapsible rows and columns
• Hyperlink facilities
• Is the interface for created user "Dimensions" easy to use
• Is the User Interface consistent
• Is the help supplied relevant
• Wizards and Agents to create reports etc – Are they beneficial?
• Reliability
• Frequency and severity of failure
• Does it recover if there are problems
• Are the result consistent
• Are the results accurate
• Performance
• Speed
• Response time
• Supportability
• Administration Overhead
• How will it support new versions of product
• How does it reside with existing products
• Does the install work on all platforms
• Sample Reports
• Line 500 Libro Giornale
• VAT Register
• Remittance Advices
• SL Aged Debtors
• Internal BACS
• Fulfil SES Sales Reporting requirements

Upgrading from Instant accounting to Tas Books [actor:customer: customer]

• Julie types in the details on their Sage.com Registration Intranet site, and also takes some additional CRM information (ie. His company turnover, products of interest etc)

• The sage.com calls the SalesLogix CRM system with all of Julies Information

• SalesLogix validates the customer ID, and then updates the newly supplied additional CRM information.
• It then returns the customers product details (ie. What he has paid for – a 1 user Sage Line 50 package).

• The Enabling key is stored by SalesLogix, plus details of date etc.

• Ian has purchased Line 50 from the Sage Reseller Hunter Supplies.
• He was supplied with a customer ID when he purchased the software.
• He installs his software.
• At the end of the installation it asks him to run the Registration program. He clicks OK, and it generates a registration key, 0000-1111-2222-3333-44444.
• The then goes to the Sage.com page for his product. He types his customer ID, and registration key.

• The sage.com system requests additional CRM information from Ian
• The sage.com calls the SalesLogix CRM system with all of Ian’s Information

• SalesLogix validates the customer ID, and then updates the newly supplied additional CRM information.
• It then returns the customers product details (ie. What he has paid for – a 1 user Sage Line 50 package).

• The Enabling key is stored by SalesLogix, plus details of date etc.

• At present no conversion mappings exist for Line 200 or 500 to the Generic Data Model. In order for the Reporting Utility to work with any other products (excluding Line 50/100) the mappings have to exist. This is presently (25/1/2003) the responsibility of Graham Cardwell at SES.
• An intermediate "super set" data warehouse is required for the solution. This may be dynamic, or require physically storing on the data. Reporting directly on each product’s database would be problematic:
• They all don’t support a full ODBC query set. Ie. Outer joins
• Reports / Queries would need to be written for each product.
• Performance
• Only Sales Reporting is covered by this project. A future product is intended to cover all the Sage package’s requirements with regard to printing.
• The source system not necessarily needs to support ODBC and in turn the SQL language., but we can assume that the system is capable of exporting to Excel, Access format. The migration utility will assume the input and output interfaces as being ODBC complaint, and in turn the
• The minimum performance level of the system has to be defined.
• Maximum number of rows, and total data set size needs to be established. Converting from SAP to Line 500 could see 5M row tables and 50GB+ data sets.
• If MSDE is used as the intermediate engine, the limitations are:
• A maximum database size of 2GB (this would only be an issue for Line 500)
• Max 5 concurrent users (not an issue)
• The line 50 ODBC is read-only. Therefore data can’t be plugged into that product via ODBC at present.
• The migration utility is wholly dependant upon a functional ODBC driver
• We can assume that the people creating and using the reports understand the following accountancy concepts:
• A Customer and their characteristics
• Sales invoices and its details
• What a Sales order is, that has been placed, but not yet fulfilled
• A financial year and its periods
• Sales groups such as product, customer, geography etc
• If Microsoft Access is used as the intermediate storage medium the ability of its SQL and Join functionality is unknown.
• Resource required for other projects (Enforced Registration, Data Migration etc).
• If Microsoft Excel is used at the output tool, it is presently limited to 65,000 rows per worksheet.
• The quality of the printer output (Print Preview, Margins, Print Area, Paper Size, Windows Drivers) is wholly reliant upon the print services and classes offered by Microsoft Visual Studio .NET.
• The aim is to implement ER eventually in all existing and new Sage UK companies.
• The new ER mechanism must be able to co-exist with existing licensing

The system will cope with staggered, or same-time (ie. April Payroll) licensing. Avoiding licence issues around Payroll year-end would be welcomed

The licensing of individual product companies (ie. SES’s companies) will not be covered by this solution. Ie. The ER system licensing each instance of the product on a machine. Andy Birch and Gavin May have devised a licensing model that no longer means the individual licensing of each company.

Time expiry will only be supported in phase I through the ER system

The Start and end date for licences are stored (in month granularity)

There will be no "back doors" to the solution.

The system must cope with all present licensing and be future-proof to a sensible level.

The customer code will be an 8 digit number (giving 100M customer IDs)

The maximum licence expiry would presently be 20 years.

Solution is Sage UK only (geographically UK & Ireland) in phase I (ie. we assume that both the Client and Sage.com are running with the same date)

The solution must cope with the software licence model. This includes:

Yearly licences for products that can no longer be used (except for reporting purposes) unless they are renewed.

Click-charges where the product performs a dedicated single task (such as £x per P11d produced). This would be done via the local app. via extended licensing information being passed.

Compulsory purchase of SageCover. Solution as above.

• W98/Me, and NT/W2K/XP are the only supported SW combinations. Also Windows 9x, NT, 2000, XP will be supported during phase 1 (SES Unix is being investigated). DOS products will not be supported.
• The license will be tied to the hardware (but could be ignored if required by the Sage UK product).
• Local UK products must be able to support WIN32 API function calls (ie. C or VB)
• The Web site will support .NET styled applications (ie. C#) Supporting W95 would mean the solution is unable to be coded in the .NET Framework.
• Intel Windows platforms only. No Unix support. The solution does have to support Databases running on Unix systems (via ODBC etc)

• Also Only Windows 9x, NT, 2000, XP will be supported during phase 1 (SES Unix is being investigated by is not a phase I mandatory item). DOS products will not be supported.
• The licence will be tied to the hardware (but could be ignored if required by anythe Sage UK product).

• Does Line 50/100 ODBC allow writes and updates?

Local UK products will must be able to support WIN32 / COM API function calls (ie. C or VB)

Frequency of the licensing checking calls is down to the calling app. Therefore the ER system is only as strong as how the local application actually enforces the solution when its told that the licence is no longer valid.

The local application could choose itself to invalidate the licence based on other criteria (keystrokes, transactions etc).

The machine where the product is installed on must be available to ensure all other client machines can access the product. This is required in order to prevent copying to other machines. Client machines will need to know the name/location of the main machine. The solution requires the "owner" PC to access periodically to validate the licence. More than one instance of the same product is allowed on a system, but it can’t be installed in the same directory.

Demonstration systems (ie. A free 30 day CD on Computer-Shopper), may or may not use the ER system. The choice will be down to the Sage UK product, and also whether the licences are one off or can be used again (if going through the ER system, the CRM have validate this)

A full test harness, software SDK, and training will be provided to Sage UK companies to aid with implementation.

The system does not cater for the SES licensing model of licensing each company. That will continue as it currently does where SOP will supply each company licence, until the new SES licensing becomes operational. The ER of the site though will still be mandatory.

• A phase II solution could enable a customer to see what valid licences were available to him so he could "call-them-off" Microsoft MSDN style.
• Phase I does not need to cater for new on-line purchases of product
• For bureau licences, it is a legal requirement that each company’s name to be obtained and stored.
• The Web site will support must handle .NET styled applications (ie. C#)
• The frequencies of re-registration / machine-moving etc by customers will need to be monitored and decided upon by the Sage.com / CRM solution.
• Allowing a user to move from one machine to another will be allowed (to a reasonable degree)
• The CRM system needs to store supplied enabling key for security and refreshing purposes.
• The additional required CRM for each product must be decided upon
• A disaster recovery plan must be in place so that the licensing system continues to run with the minimum of down time.
• Sage.com must cater with both SalesLogix and Sovereign until November
• The system must cope with a new customer who has no customer ID number (ie. They have just purchased their product from PC World) and need one allocating to them.

• The enabling / registration key can be no longer than 48 characters (probably alpha-numeric like Microsoft). This will take about a minute to enter.
• The system is not 100%, but would require multiple areas of the product to be hacked, or the full source code to be made available.

• Infringement of Timeline patents has been investigated and it is viewed that the proposed solution would not infringe of their existing patents. Ramifications of obtaining customer HW information
• Check the contracts cover installation is restricted to a single instance
• A generic cross group licence, rather one per product/company

• A full-blown Sage UK wide generic Reporting solution based on the technology and work developed in this product. Get 3^rd party add-ons mapping into the standard Data Dictionary tables. Accreditation process required for this? Automatic licensing
• Other methods of licensing (ie. Fax)
• Online purchasing etc