Kingston Developments Members banner

User Group

Logistics and Accounting Solutions UK

Posted in this section are minutes from the user group meetings. Click on the links below to view the minutes from the meetings.

User Group Meeting 11 May 2006

User Group Meeting (CRM) at Torex on 15 December 2004

User Group Meeting (Accounts) 20 October 2004

User Group Meeting 19 September 2004

Notes from KBS User Group Meeting on 11 May 2006 at Holiday Inn Express, Markyate

Companies represented:

Diamond Electronics

Torex Semiconductor

Willow Technologies

Foremost Components

Recent Developments

The meeting began with Colin White giving a presentation on items that had been recently developed for the system as added enhancements. All of these are detailed below and are chargeable additions integrated into the rest of KBS. They are also all available now for general release.

ROHS Compliance

Colin White explained that a new module to ensure ROHS compliance had been developed over the last year. The main design criterion was to reduce input from users. Product could be classified as compliant or otherwise at batch level. Customers could be identified as ROHS compliant – a big benefit as KBS allocations routines have been enhanced to ensure that customers have stock allocated according to their preferences.

KBS provides four status options for each batch of stock (‘Exempt’, ‘Yes’, ’No’ or ‘Unknown’). Compliance of stock is monitored at all stages of stock life from booking in – for example checking that stock ROHS classification agrees with the Purchase Order requirement – to Despatch where labels allow ROHS status to be printed.

Purchase Order Management (POM)

Kingston provided a description of a significant new module.

POM effectively manages the business of buying stock from identifying the need for new stock to raising purchase orders, monitoring the links between sales commitments and outstanding PO’s and providing the means easily to reschedule or cancel under the user’s control. The main screen of POM is similar in content to the PO Forecast report, but the difference is that users can use options on the screen to manipulate the Purchase Order Book by raising orders, amending orders or cancelling orders.

Naturally a history of all changes made to the Order book is maintained by KBS.

In response to a question, Colin White explained that POM had been designed so that, in addition to using base stock pricing for PO’s, KBS allowed for Price agreements to be set up at part and supplier level.. Torex indicated that price agreements may need to be set up for customers. Diamond have had similar scenarios but can work around them. Kingston would contact both companies to identify their exact requirements.

Contract Management

Colin White explained that this new module allowed companies to more clearly define the nature of long term commitments to customers. Currently many customers set up orders with delivery dates way into the future. However this tends to distort the allocations routines and can lead to problems with stock being held for the wrong reasons. The CM module allows companies to set up contract details in line with the customer agreements.

Useful features include

  • the ability to create buffers
  • large contracts don’t show up on the Bookings figures for that month giving a more accurate figure when the goods are sold
  • simple drawdown to create and process the Sales Order

Importantly, the module enables companies to monitor contract performance and renewal status.

Production Control

Colin provided an overview of the KBS Production Control Module. Effectively it enables a company to provide Kitting, Assembly and Manufacturing services in a controlled and efficient manner. Significant features include:


Production Orders as opposed to Sales Orders by recognised in stock and allocation software

PO’s can be generated from Sales orders or ‘Build for Stock’

Third Party Monitoring

Control over stock is maintained

Additional costs accounted for

Analysis reporting

All stock movements traceable at batch level.

Enquiry( Non franchised) Processing

Essentially this KBS module automates the job function of seeking best prices for individual or groups of parts. The system can automatically create and despatch RFQ’s (Requests for Quote). Responses may be recorded against the individual part and history created.

The user may select best price and easily generate Quotations, Sales and Purchase Orders as necessary.

The software also provides facilities for bulk import of parts lists requirements and RFQ responses.

Future Developments

Anna then provided an overview of the situation regarding future developments.

CRM Customer Relations Management

A basic prototype had been completed. Currently being used by Kingston to record customer calls and monitor software development.

A discussion followed on the requirements of the new module. These included:

-Recording customer relationships and activities

-Controlling set up and developments of projects

-Sharing information through the company

-Providing improved customer service

Kingston expect to have a prototype within two months and will convene a meeting to receive customer feedback.

Electronic Ordering

KBS currently provide facilities for sending XML documents. Many suppliers now accept orders in XML format, but need (Torex) to be able to provide the correct format for these XML files.

The feature could be taken further, with the whole sales order side automated. The user would import an XML file sent by their customer and KBS would then continue to process the order and send out the relevant documentation.

Web Interface

This was something most companies wanted but as it would be such a major project, Kingston would like to collaborate with thosae interested in developing and taking the final product. There were a variety of ideas mentioned and some of the features required were:

Check stock levels through the Users website

Taking orders

Customers to check orders books

Customers to upload orders

(Torex wanted as a matter of priority to put order books on a web site)

This issue also raised a lot of other questions of how far Kingston would be involved in the development, would they interface to existing websites or design their own for the users to adapt? Users to think about the issues and respond if interested.

Credit Card Functionality

There was no real interest in this.

Box Labels

This issue was specifically requested by Torex as they use barcodes to check items from outer box. Torex explained that customers have different requirements for labelling. Would also like to be able to relate a reel size to a location (This functionality was in KATS!). System needs also to be aware of size of bins.

Note: Kingston will create a new table to show how many reels/packs may be held in a bin.

Torex thought that KBS should be able to recognise individual suppliers’ label types. (This was seen as important and Kingston should address).


The question was asked, if a customer finds a software problem and has it fixed, was the software released to other users? The answer was no, mainly for reasons of confidentiality. It was agreed that the Kingston help desk would make the ‘software change’ spreadsheet on the web site, but edited to ensure no sensitive information is inadvertently made available.

Kully from Torex asked if the help system files could be held on the web-site. Kingston will give consideration to this request, but there are major privacy issues involved. Kingston are to respond.

Diamond asked if a diary could be provided on the main menu, making follow-ups more prominent. Follow-ups are shown only for the day – need to be able to see a month to view.

Top of the page

User Group Meeting (CRM) at Torex on 15 December 2004

Minutes of the meeting


Darren Spencer (Diamond)

Simon Hilson (DIP)

Gareth Henson(Torex)

Colin White ( Kingston)

Bob Howe ( Kingston)

Tim Armstrong from Hero sent his apologies.

RH had prepared a basic agenda as an outline for discussion, but it quickly became clear that customers were more interested in replicating the features of commercial contact management software such as Act, Goldmine within KBS.

DS led the discussion with a demonstration of ACT and an explanation of how it was used within Diamond.

The prime features of Act, as used by Diamond, are summarised as follows for the record:

One record per contact individual

Access by all employees at Diamond, except for Stores personnel

All contacts with customer (and suppliers?) is recorded as free-format notes

Fields are customisable (at what level?)

User definable fields

Contacts can be assigned special product category interest e.g. Interested in LCD’s, recorded as marketing information

Reporting (was very good)


Synchronisation features enable salesmen to down load contact information from the host site and to update the main database with data recorded locally.

Newly synched data would be highlighted.

Contact records were grouped by ‘Project’, sales staff were encouraged to look for opportunities. Each opportunity, for example, would spawn a new project.

Links with MS Word



More expensive contact managers, such as Goldmine, allowed individual contacts to be grouped within companies.

Diamond did not use KBS for quotations. These were developed in the context of the contact management system.

Key features of a project (Sales Opportunity) are as follows:

Product (categories need to be user definable)

Type of project

Forecast date



Unit price


Close Date


Associate with group

Competitor(s) and competitor details

Details (free format text)

Contact history:

Date and time

Type, e.g. note, text, meeting

When the order is won, the project is closed. If lost, then the reason is entered.

Reporting included:

Open Opportunities

Closed Opportunities

Lost sales

Documents such as emails, quotations need to be attached to projects. The system need to be able to output to Word and Excel documents. MS Outlook was the preferred method for generating emails.

In discussion, Gareth suggested that projects should have milestone records and status indicators. Projects could be exported to, say, customers who could then provide feedback to enable the milestones to be updated.

With ACT each project finishes when a sale is lost or won. KBS could add additional fields to record e.g. quote number, order number, despatch date.

RH explained that the next stage would involve Kingston preparing an Outline System Description of the new functionality to be added to Kingston KBS. It was agreed that while CRM would be built as a new distinct module, there would be extensive links to other modules as appropriate.

Top of the page

KBS User Group Meeting (Accounts) - 20 October 2004.

Minutes of the meeting


Sandra Williams Diamond Electronics

Peter Nehammer Diamond Electronics

Tim Armstrong Hero Electronics

Helen Mitchell Electronics Excellence

Jo-Anne Olivier Willow Technologies

Linda Henson Torex Semiconductor

Colin White Kingston Developments

Neil Ward Kingston Developments

Purpose of meeting

The meeting was called following discussion at the KBS User Group meeting on 14th September. It was thought that a meeting specifically represented by users of the accounts modules of KBS would enable specific problems to be discussed and documented. Also, the meeting will enable Kingston to record a list of enhancements which the KBS users feel are beneficial and possibly essential to be made.

Nominal Ledger


When areas of a grid are highlighted e.g. foreign currency on the transaction listing, then this can have an impact on printing. The process is very slow because the printer takes a long time to produce the output (raised by Hero).

Journal tab page – there is a Cancel button on the main display and also a Cancel button on the display of previous journals. They have different actions and are very confusing.

Bank Payments – have to type the full account number and department (raised by Diamond). The reference field is too short, can it be expanded?

There is a redundant field ‘Vat report’ on the journal posting tab page.

VAT report – Jo-Anne reported that the detail report was duplicating. No one else seemed to have this problem. Colin asked if she could send an example and further details. It is not clear how to drill down to the detail from any section of the summary report.

Transaction listing does not have a title which includes the account name and number.

Income Statement (Profit & Loss) does not have a gross profit total.


Option to ‘freeze’ nominal. This is to prevent postings into the frozen period, but the period can be unfrozen if required. Linda advised that on another system she has used, employees could be set as accounts administrators. Only these employees could post into frozen periods.

It was agreed that the GRN number is a more useful reference than the PO number on GO stock nominal postings.

The Detailed Trial Balance is difficult to use in reconciliation (raised by Linda). In general discussion it was pointed out that the report balance is in GBP where the details are in the original currency. In order for the report to be most useful, the GBP equivalent needs to be shown for each transaction.

Journal entry, Bank Payments & Receipts.

Once an entry is saved it cannot be amended before posting. Tim pointed out that the Unix system had this facility. All agreed that this is irritating.

The journal number generated by KBS is not available when looking at the nominal postings. The general consensus was that this is more useful than the reference.

The date, reference and notes should be header fields since it is unusual to change them on a line by line basis.

The default VAT code is 5, the user has to alter this for the transaction to appear on the VAT report. Some users had a problem where they had not changed the code and asked whether the validation when saving the entry could warn if the VAT amount was greater than zero and the VAT code was 5.

Transaction list – This report would be more useful if it could be printed with a running balance in the original currency (e.g. USD bank account). The reconciliation currency could be used. The report would need to handle transactions in other currencies. Generally agreed.

VAT report – The detail section needs clearer headings for each section (see the Unix VAT report as an example). Generally agreed.

Sales Ledger


Aging of transactions is incorrect when terms period is monthly. E.g. 60-M. KBS interprets this as end of current month plus 60 days. This should be end of current month then plus two months e.g. a transaction dated 20th October is due 31st December.

Statements – all agreed that statements must have payment terms printed.

Aged report – takes a long time to run. Raised by Tim and Linda. Up to 20 minutes as a runtime was mentioned.

On some accounts with a long transaction history the display when selecting the All option in allocations takes a long time. The order displayed is oldest first, more useful is newest first. Can the search be suppressed to, say, the current financial year?


Bank Charges – When entering a remittance in currency the bank charges (if any) are usually known (e.g. when we have a GBP bank account and the customer has paid in USD). At present these have to be posted through a separate journal. It would be useful if these charges could be entered as part of the remittance detail and KBS handle the postings. Some users said they had seen this in other accounting systems.

More help would be useful for the VAT code field. Currently there is hint text, but maybe text against each value on the dropdown list would be useful. From general discussion it seems most, if not all, users had made errors here.

Previous/Next Buttons – Generally agreed that these would be useful on the Transaction, Allocations and Maintenance pages. Easily step through list of customers. This comment also applies to the Purchase Ledger.

The recent release changed the tab key sequence on the Transaction page so that fields were accessed in strict order of appearance on the screen. This has proved to make transaction entry more difficult. It was suggested by Colin that the way tabbing sequences are maintained should continue, but the order of the fields altered. The sequence of entry (as discussed) would be

Transaction type

Date (calculates due date)


VAT code



Currency & Rate


RMA link. This was raised by Tim but other users agreed would be very useful in credit control. The allocations screen would highlight any invoices which have an RMA (Customer returns) against them. Colin remarked that if Kingston provides this facility then it would include a drilldown to view the RMA details (and reprint the document).

Additional information for credit control. Raised by Tim, added to by Linda.

The ideal situation for the credit controller is to view all information required in the allocations screen. Currently the maintenance screen has to be used to view some detail, and in some instances, non- accounts modules. The additional information required is.

Payment terms.

Credit limit and held flag.

Telephone number.

Ability to expand a credit note (includes original invoice number).

Ability to reprint invoice or credit note (includes fax/email options).

Reversed remittance – Currently KBS marks the original transaction as reversed (cancelled) and posts reversing nominal transactions. Tim raised this issue and there was total agreement that a preferred method would be to post a new transaction marking the reversal. The nominal transactions posted will be effective the date of reversal. Colin raised the question about the time difference between the original and reversal transactions effecting the bank account. It is ok that the bank account shows credit followed by a later debit.

Updating due dates – Raised by Tim. If payment terms are renegotiated after posting an invoice the due date cannot currently be altered. This may only be done if the invoice is unallocated. This allows for the situation where an invoice may be disputed then agreed to be paid.

Journal tab page – Diamond have asked for the initial display to be suppressed, supported by other users. It displays all transactions from the start of the financial year and is unlikely to be the report required.

Default bank accounts for each currency/ledger would be very useful to assist in preventing user errors when posting remittances. Agreed by all present.

Purchase Ledger


Credits and Debits are ‘wrong way around’ on the PL.


The ability to only use Debit Notes as documents and not post to accounts would be useful. In many cases the supplier returns a credit note which if posted results in the debit note having to be reversed by posting a JD transaction.

The Unix version of KBS had options for a remittance address and ‘Cheque payable to’ field, for each supplier. These were used on the remittance document and printed cheques.



All users remarked that they are still having problems with differences between reports due to inconsistent rounding of calculations. The recent release resolved many of these problems. The two areas outlined were TB vs Transaction list (particularly bank accounts) and VAT summary vs VAT detail.

A general comment on the recent release was that Kingston failed to advise users of new features. Neil pointed out that the release media included revised documentation and a spreadsheet containing all recent program changes. The users would have liked a single document highlighting any new features (distinct from problem fixes).

Linda raised the point that sometimes Kingston release software which fixes one problem, but causes another. Colin said that Kingston had recognised this and are always looking at methods to improve the QA aspect of their work. Automated QA software is being evaluated and put to use. This allows a script to be recorded from a sequence of events using the KBS software. The scripts will be replayed against software before it is released. This will be a ‘rubber stamp’ method of testing and does not replace existing programmer and QA staff responsibilities.


Accounts integrity – Jo-Anne pointed out that they have three stock nominal accounts. This means that the accounts integrity produces an error each time it is run. Colin advised that Kingston will discuss because this is unique to Willow’s design of stock nominal posting. An option would be to have a ‘Stock’ nominal sub group.

Document archiving – This issue was raised by Peter (Diamond) and added to by Tim. They have been involved in recent legal proceedings. If they could have reproduced documents exactly as they were originally sent to the customer/supplier then this would have aided them significantly. Colin pointed out that (at present) KBS removes document files after printing. Emailed documents are created as Acrobat (PDF) documents. This would be the preferred format for archive.

Jo-Anne asked if there was a facility for booking on cheques in batch mode. CW answered that there was not. Further discussion established that there was not a requirement for this.

Non- Accounts


Raised by Jo-Anne – despatch notes only need the delivery address printed. Currently prints delivery, invoice and contact address which can confuse the stores staff (Tim said that his stores had also had problems with this).

Raised by Jo-Anne - bookings report does not show added drops.


These minutes will be distributed to all KBS users, not just the attendees. Kingston will hold an internal evaluation meeting to inform the users of action proposed to be taken, together with delivery dates for any software changes.

Top of the page


User Group Meeting - 14 September 2004

The first meeting of the KBS Windows User Group was held on 14 September at the Holiday Inn Express just off junction 9 M1. The meeting was to establish the User Group and to gauge interest in moving forward in developing the system.

Minutes from User Group Meeting 14/09/2004


Jay White of BF Components

Brian Barber of BF Components

Darren Spencer of Diamond Electronics

Tim Armstrong of Hero Electronics

Gareth Henson of Torex Semiconductor

David Greenfield of DIP International

Jo Anne Olivier of Willow Technologies

Kingston Staff:

Bob Howe (RH)

Colin White (CW)

Anna Howe (AH)

Neil Ward (NW)

Mark Hoffmann (MH)

Welcome and Introduction

RH welcomed all attendees to the inaugural KBS Windows User Group meeting and set the agenda. He also pointed out the fire and safety regulations.

Presentation of recent developments

CW ran through a presentation of features recently introduced into the system and whether or not they were available on the CD release.

These developments included:

  • User Defined Colours
  • New Reporting module
  • New look Main Screen
  • Production Control – some interest was shown in this module and handouts were distributed accordingly.
  • Serialisation
  • Purchase Order Management – again some interest was shown in this option. Some members wished also to be involved in the development of this module.

Presentation of Future Developments

RH firstly presented the introduction of the specification of a CRM module into the package. Comments were made by the Users that they would also like to be involved in this and participate in the design of the specification as most would find it useful to their business.

CW then presented the upgrade of the DBISAM database to version 4. All advantages were made clear and the group seemed positive about the change as it will help increase the speed of the system as a whole.

Coffee Break

User Group

AH made a short presentation about the Website and the User Group. It was noted that the Website will be enhanced to include member interaction and give them a lot more access to documentation and release notes. It was decided that it would be a good idea to have a bulletin board made available so that all Users can post up comments or queries and answers can then be made available for all to see. There was a general consensus that the Users should be involved in the development of the package more and that the Website is a good medium for this to be done.

When asked what elements they would like to see in the Member Area, it was decided that there should be a User Group page, an FAQ page, online documentation with any added updates for each release of software. Another major area to be developed is another secure area which will have the ability to have new releases and the corresponding documentation downloaded from it. Issues of security would be key here.

In regards to the User Group, it was decided that there will be another meeting but to initially be held at Kingston offices and then moving out to the independent Users. It was noted that a meeting for issues with the Accounts side and changes in law is necessary and should be set up as soon as possible.

The rough Wish List that NW has been collating was distributed and Users asked to comment at their leisure. The idea of the Wish List is something that will be further discussed at the next meeting.


A general discussion decided that the first priority was to have a meeting for the Accounts side of the package.

A CD release was given to each User that included the latest bug fixes and upgrades to change the main screen, include User defined colours and the new reporting module.


  • RH to circulate copies of specification of CRM to all Users for comment and feedback with the aim of involving them more in the development of the package
  • AH to arrange a meeting for the Accounts side to discuss any issues as soon as possible
  • To enhance the website as follows:
    • AH to add minutes of the meeting to the User Area
    • AH to distribute Username and Password for User Area to each User
    • AH and NW to further develop the website User Area to include a bulletin board for User comments and feedback. Then inform the Users it is there and how to use it. AH to set the procedure for review within Kingston
    • AH to set up FAQ’s page in User Area
    • AH to set up and add online documentation to the User Area
    • AH and CW to investigate the possibility of the set up of a second secure area for the download of software releases

Top of the page