Good Evening, Welcome to dcs (Diazone Computer Services)
dcs chosen to be one of only a select few, newly formed, Sage Customer Development Centres
Sage Customer Development Centres (CDCs) are Accredited Business Partners who are recognised by Sage to be experts in the migration of suitable prospects from Sage 50 to Sage 200, by demonstrating their expertise in product education, solution experience, implementation, and on-going support of Sage 200.
Sage Customer Development Centres work closely with Sage on each opportunity, to ensure customers migrating from Sage 50 to Sage 200 receive the correct messaging, software solution and delivery.
Key reasons why people migrate:
Limitations in existing functionality
Management Reporting
Advanced Foreign Currency
Control over Financial Periods
Storing stock in multiple warehouses
True stock costing
Batch / Serial processing
SOP / POP Cycle
Customisation / tweaking processes
Vertical specialism
Scale
Not enough users / Not enough history
Sage 50 corrupts or stops working / Product is too slow
The issues and some common responses:
The issue - Period Control
Sage 50 operates in an open period accounting basis only. If a month end is performed on January recurring postings are delivered into the system.
Therefore, a user could post a January invoice into the system changing all of the management reports for that month as transactions can be entered with any date and accepted by the system
What they say...
"I can't start processing February transactions until January is closed"
"I must process this invoice with January's date but don't want to alter the closed off figures"
"I'm always behind when it comes to the start of a month"
"We spend so much time at the start of the month catching up again!"
"I want to limit the amount of mistakes people make with dates i.e. don't want to see a 3008 date by mistake"
The solution
Sage 200 supports both Open and Closed period accounting
Sales, Purchase, Nominal, Stock, Cash book can be controlled individually
If January is closed for Purchase Postings and a late purchase invoice is processed with a January date would affect February's accounts
Periods can be re opened if needed
Validation rules allows you to specify an acceptable range of dates within the system
Transactions outside of the current financial year can be stopped / allowed
Rules are tailored by the company themselves
The issue - Management Reporting
Sage 50 has a list of nominal codes to choose from when raising Sales Invoices and this becomes restrictive when trying to report on factors other than 'type of sale / purchase'
The Departments within Sage 50 are an error prone method of trying to get extra analysis out from the system and the chart of accounts in Sage 50 does not allow items to be grouped 'out of sequence'
What they say...
"I can't see the profitability of the van and a driver"
"I can't see how Manchester is performing against Liverpool"
"When code 4000 (Kitchen Sales is selected) I need to stop people from selecting the department number 1"
"I can't put a Total Retail sales on the P&L because the codes are not grouped together"
The solution
Three tier Reporting
Sage 200 supports cost centres and departments. What the cost centre / department is entirely depends on the company. Examples include Sales / Purchase Regions, Sales People, Vans, Drivers, Types of Products, Projects etc.
Budgets
Cost centres and departments can be budgeted against, meaning that you can report sales against target for company, region and sales person.
Report Categories
These indicate how the P&L / Balance sheet will group. The account numbers can be out of sequence as it is the category that ultimately determines the grouping.
Furthermore, unlimited quantities of P&L / Balance sheet layouts can be established facilitating the option for variable views of your company (e.g. Operational, Stakeholder, Summary, etc.)
The issue - Stock Control
Sage 50 does not allow the recording of batch / serial numbers for products that require it.
As a result, users require a method of seeing that one particular item has been brought in by a supplier and sold to a specific customer so that returns can be handled
This becomes difficult for anyone dealing with high value / dangerous items
Customers work around this by storing this information within spreadsheets / other systems
What they say...
"I need to recall a particular serial number - which customer has it?"
"My spreadsheet and Sage system are always out of sync"
"How can I track that this product is past its sell by date?"
The solution
Serial number and batch number entry
Sage 200 allows individual stock items to be serial / batch tracked
This alters the goods received process to ask you for serial numbers
When stock is despatched to a customer the system will seek confirmation of the serial / batch numbers sent
Tracking
Can access history to show where a particular serial number was bought from and sold to
Deal easily with product recalls
Use by / Selly by Dates
Can be recorded against specific items
Able to report on this
Warning if you are about to sell 'out of date' stock
The issue - Scalability
Sage 50 uses a proprietary database (Sage created the database)
The intention was for the database to handle a small business’ transaction throughput
Sage 50 system has an upper transaction limit of approx 100K transactions
Customers have to ‘clear audit trail’ (wipe history) at regular intervals
The more transactions within Sage 50 the performance will decrease
What they say…
“ Sage 50 is getting increasingly slow at specific tasks”
“Why do I have to always clear my history from the system”
“Trying to selling / buying trends for more than one year is impossible”
“I need to analyse this year verses last year and prior years”
“I don’t need loads of history in purchases just in sales”
The solution
Database Management System
Sage 200 uses Microsoft SQL Server
This database is designed to deal with a high volume of transactions
The same database is used on our Sage 1000 product where customers may process massive amounts of transactions
A database for Sage 200 has been seen at the 6GB level (hundreds of times larger than the largest Sage 50 database
The majority of Sage 200 customers have historical data going back a number of years
SQL Server allows data to be spread over multiple servers e.g. stock on server 1, SOP on server 2 etc
History Control
Each Customer / Supplier / Nominal account can control how much history that particular account stores
When a transaction is ‘old’ it is moved to a historical data file and can still be viewed on the system
The issue - Scalability
Sage 50 is recommended for a maximum of 6 concurrent users
Limits exist because of the database that Sage 50 uses
Many customers have much more users attempting to use Sage 50 than that
The method that Sage 50 uses to ‘lock’ restricts other people from doing similar activities at the same time
What they say…
“Sage 50 is stopping me from doing my job”
“Not everyone can be in the system that needs to be”
“John can’t enter an order when Sally is despatching”
“The system was fine 1 - 2 years ago”
The solution
Database Management System
Sage 200 uses Microsoft SQL Server
This database with Sage 200 has been tested with 50 concurrent users using the system at the same time
A site in the 8 – 20 user bracket is very normal for Sage 200
Locking
The system locks on a 'flash' locking basis, meaning that it only requires exclusive use of the data that needs to perform the action it requires
Simply put this means that someone can raise an order and despatch another order at the same time
Growth
The company might have seen substantial growth in the last 1-2 years
