Acceptum and Support Services
1) Support for Acceptum Business Software
After installing Acceptum Business Software, users may request a consultant to visit and discuss the software and its implementation. Please use the Contact page to request a visit.
Users of Acceptum Business Software may send emails to RCL with their questions concerning the use of the Software.
Answers to the most 'frequently asked questions' are posted on our web site. This service is provided free of charge to all users of the software. Users are advised to review these questions and answers before obtaining any other form of support from RCL.
Telephone support of the software may be purchased:
- on a per issue basis (see our web site for current prices), or
- an annual support contract with version upgrades (payable in advance) priced at 20% (+VAT) of the software module cost.
Unfortunately, no guarantee or warranty can be given that your specific issue will be satisfactorily resolved. Although, RCL will do its utmost, to obtain a mutually satisfactory resolution.
No charge is made if the issue results from a major bug in the software.
Telephone support is provided during the hours of 9:00am to 6:00pm Monday to Friday.
2) Training for Acceptum Business Software
Introductory training courses are held on a frequent basis (see web site for prices).
Please use the Contact page to request further details.
3) Next Steps
Having downloaded Acceptum Business Software, we suggest the following course of action to help you in deciding if the software is appropriate for your business needs:
Understand the software
• install on a server for network use or on a PC for single user
• examine the example Set Up and TestCo transaction data
• enter your own transaction data into TestCo and study the effects on reports etc.
• study the standard source data - Sales Orders, Purchase Orders, Time Logs, Fixed Assets
• study the standard ledger transaction data, views and reports
If your want a consultant to demo the software please use Contact page to request a visit.
Start customizing
• add your own companies
• enter your own Set Up data and use it in transactions
• raise some dummy sales orders/invoices and purchase orders
• enter your own accounts, customers, suppliers, products, analysis codes (cost centres), fixed assets etc.
• establish any web site linkage using COM, XML, E-mail and FTP
• perform workstation installation of software on user PC's
• reset the Start Menu, Acceptum Target property to point to the central server
Decision time
• establish how many concurrent users you need at peak times
• establish that the software meets your business requirements
• establish if any changes are required to your current business processes
• if not 100% happy, review if bespoke software changes are required to meet your business processes
• obtain a quote for any bespoke software changes
• complete the software order form and send to RCL with full payment to obtain a full license
After ordering
• amend standard reports to your own requirements
• cut over opening balances in company ledgers (including stock levels)
• cut over open customer and supplier invoices/balances
• cut over Budgets, Fixed Assets, Purchase Orders, Sales Orders etc.
• start using the software on a daily/regular basis
4) Web Integration
Acceptum Business Software is an Enterprise Resource Planning (ERP) system that can be integrated with a web site (hosted or otherwise), enabling even the smallest of companies to have dynamic web page content. Examples being:-
• customer ordering;
• customer order tracking
• customer account enquiries and management
• customer address change management
• remote worker time-sheet and expenses entry
• remote worker management reporting
Acceptum Business Software provides a 2 way FTP transfer process between itself; on a local server; and the FTP address of a web site.
The Down Path reads XML update or query files created by web pages, processes them, whilst removing them from the web folder.
The Up Path passes the XML query result files created by the download path back to the web server for inclusion into web pages.
Result - producing dynamic page content for web users.
5) What is a Backoffice system
Backoffice systems are the normal E.R.P. computer systems used to record Sales Orders, Purchase Orders, Financial data etc, that help management run a business.
They are termed 'backoffice' as they run 'behind the scenes' and are not normally seen by customers or suppliers.
Customers or suppliers normally only see the printed output from such systems - invoices, order documents, delivery notes etc.
For security purposes, they are not normally enabled for direct access to or from the web.
However, for todays modern business some form of limited automated connection between the web and a backoffice aystem is desireable in order to speed up customer order processing. It can also provide order and account tracking for 'high value' customers and suppliers.
Many of the older backoffice systems cannot easily provide this level of automation requiring data to be manually entered twice.
Typical requirements are:
Online web site taking Customer Orders?
Wanted - automated update of your E.R.P./Backoffice system!
Remote workers needing to enter timesheets, expenses, purchase orders, etc?
Wanted - automated update of your E.R.P./Backoffice system!
Remote workers/customers/suppliers needing to query your E.R.P./Backoffice system?
Wanted - as automated query and result feedback system?
Well, we can help, with our backoffice/E.R.P. system - Acceptum Business Software.
6) Resellers required for Acceptum Business Software
If you have experience of installing financial and ERP systems for UK SME's, then RCL would like to here from you.
As RCL is currently appointing resellers for the application.
Registration is a simple process and will cost you nothing, so see our web site for full details of reseller terms and conditions.
ERP Reporting - ability to create/modify reports
All ERP systems come with plenty of standard reports, some useful for your circumstances, some not. But no matter how many reports there are, there always seems to be a few reports missing or reports not quite as required.
The reporting shortfall can be broken down into two main categories:
a) basic layout changes required, or the addition/removal of a small number of fields from existing reports
b) completely new reports required, some from a single data table, some requiring quite complex data structuring across two or more data tables.
To overcome these problems, ERP systems normally provide some form of report development tool. SAP for instances has its User Report Generator and ABAP programming language.
The development tool may be useable by end users with little or no IT experience, or it may require a person of considerable skill and experience. If the latter, then the running and installation costs of the software will be increased and in some circumstances even doubled (or worse).
Most systems claim to be useable by end users. This claim should be tested at some point – hopefully before committing money to the software. As not all claims are justified - I had better leave it at that.
One approach to filling the reporting gap is to use generic reporting tools like Crystal Reports or even the good old spreadsheet. These too come at a cost, they may not be of high monitory value, but the cost could well be hidden in things like data accuracy, completeness, timeliness and overall reliance on an external system to perform tasks that should be performed by the ERP system itself. Remember, that is probably one of the reasons you bought the system in the first place.
What should be avoided is using expensive IT developers or the system developer/reseller to remedy basic layout changes. Nowadays, this task should be within the scope and capability of system users and the ERP system should be capable of supporting this requirement. For example, under SAP the Report Generator is for users to create new reports. To change an existing standard report, will normally require knowledge of ABAP. Many ERP systems are sold that do not allow for standard reports to be changed by anyone! They are ‘locked’ by the system and require specialist knowledge or software to effect changes.
So when investigating an ERP system for use in your organisation, check its reporting abilities and the ability to change standard reports for category a) type changes.
Check the claims that it is user friendly.
Check on what experience and knowledge an IT person requires to create category b) type reports. Then determine the cost of that knowledge in the job market.
The answers to these questions will help you select the correct system for your SME.
Transport/Delivery Restrictions and ERP Business Software
In to-days world of delivery lorry/van restrictions, that can be on - access times, vehicle weight/size, congestion charge zones, etc. How does a supplier organisation keep up to date, or even retain the necessary data on these restrictions, as imposed on individual customer delivery points?
The majority of older ERP/business systems struggle to hold such data in a manner or format convenient to the supplier and able to be seen and set by multiple departments that need or have access to such data.
A good ERP/business system will provide for this data to be held, accessible and changeable by each of the departments involved in the delivery process.
Part of the sales forces task in to-days environment should be to collect and enter the initial assessment of such restrictions into the business system when taking an order. Either, at an individual sales order level, or better still at the customer delivery point level. Then later on in the Sales Order completion process, the warehouse/delivery department can use this information to pack the product in such a manner as to meet weight/size restrictions and schedule a delivery time within the allowable time window.
This data should also be available for update by the Transport/Delivery department when a driver reports back that the data needs to be changed for some reason.
The complexity of this delivery restriction data at its simplest level need only be a text memo attribute held at the sales order or delivery address level. For other organisation more complex data structures may be required holding such details as lorry size, maximum cargo weight and size dimensions, etc.
If delivery forms a problem for an organisation at the moment then this problem will only grow in the years to come as more restrictions and congestion charge zones are imposed, making it all the more important that such data is held in the main business system.
Installing an ERP system
Many companies defer installing an ERP computer system because of the disruption and risk involved in the installation process. These risks and disruptions can be minimised with good planning and preparation.
The extent of the work involved will depend on the size of the organisation involved and on its volume of clients, customers, suppliers, products, open transactions, etc. at the point of cut-over. But whatever the extent, the principles to be applied remain the same, whether the data is Master or Transactional.
These principles are to:
a) identify each entity; customer, supplier, product, account code, open sales/purchase/production orders, account balance, etc.; required to be set up in the new system.
b) identify the means of transporting data for each entity from existing systems into the new system. This normally means exporting data to an Excel spreadsheet or a data extract file useable by the new system.
c) identify the data manipulations required to change old format into new system format.
d) identify any missing data that the new system requires and determine how to acquire this data.
e) identify data used in existing systems that is 'dropped' by the new system; and decide how important this data is to the organisation and how any functional gap caused by this loss, is to be covered. This should have occurred when the new system was selected. But it should be re-examined now that more information on the new system will have been obtained in the interim period.
This is the point of greatest risk, for if some 'must have' business function appears not to be covered by the new system, it can become a 'show stopper'. Or at best, delay the implementation timeframe, whilst alternatives are investigated and assessed.
f) identify all actions that need to be performed on existing systems before the data is transferred across to the new system. Examples of this would include:- data clean-up, removal of old records, payment of all open items to suppliers, fulfilment of as many customer/production orders as possible.
g) whenever possible, coincide the switch to the new system with a financial year end, as it is always much easier. When this is possible, always import closing balance into the old year on the new system and do a 'year end roll' into the new year so that monthly/period movement reports are not compromised by cutover data.
h) identify new hardware and software requirements of the new system and the acquisition path and any delivery/installation delays.
i) collate the work required from the above points and assign to individuals along with developing a timeframe for each task. Critical points and data constrictions need to be identified so that timeframes are not delayed and additional resources can be focused in the right place when tasks are actually performed.
For a small organisation these tasks may only take a day or two to complete and not require significant testing prior to doing it for real. In larger organisations, test runs will be required to gain insights into exact data requirements and loading sequences. Whatever the size of an organisation, planning the installation process and preparing data in advance, goes a long way to making an easy and smooth systems installation.
ERP Business Systems and Inter-Departmental Communications
Telesales takes an order and the customer specifies that they wish the ordered items to be packed and delivered in a special one-off manner. The customer is important to your business, so you decide to accept the conditions and make a small charge.
Now the problem begins - How does the telesales person communicate these instructions to the warehouse manager and delivery manager in a timely and consistent manner?
What happens when accommodating such customer requests forms or becomes a distinguishing factor of your business, to the extent that they form a substantial part of your business.
The use of inter-departmental e-mail is one way to solve this communication problem. But its major disadvantage is that the instructions are not held in or connected with the original sales order in the business system. And when the number of orders requiring special treatment grows to a level beyond a few, the chances of these special instructions being missed when an individual order is picked/packed/despatched is increased. To a level that is an embarrassment to the company when things go wrong.
The only effective alternative is to have an ERP Business System that provides for telesales to record such instructions in records relating to the sales order and to have such records available to and changeable by, any other department. Only in this way are the notes directly linked with the sales order and thereby visible at all times to every department that needs to see them. What is more the use of an external system is eliminated making the secure backup of such notes part of the normal backup routine of the main ERP Business System.
One major advantage of a ‘General Notes’ facility as described above, is that it can be used for lots of other inter-departmental communications, like - telesales to credit control/accounts; sales to purchasing department.
A business system that provides for General Notes to be held for each of the primary business transaction documents (Sales Orders, Purchase Orders, Time Recordings, Job Costings, Production Orders, etc.) will be much more flexible, responsive and useable than a system that does not provide such facility.
