PD4Logo

Running a business on PipeDream.

Foreword

As you will gather from this as you read it, we have here quite a considerable system which will take a significant time to explain. So it won't get finished for a long time!

It will also quite clearly become a long document, filling several pages.

As is unique to the internet, this page can expand as readers show an interest in a particular area. So the bones which are here will get fleshed out slowly and in a manner which reflects the interest of you, the readers. For contact information, see the end of this set of pages.

Introduction

4QD run our business on PipeDream, with surprisingly little help from other programs.

PipeDream is a program which evolved from a word processor, a spreadsheet and a database which were first released to run on the old BBC microprocessor. These three were View (the WP), Viewsheet (the spreadsheet) and ViewStore (the database).

Eventually a fourth program was released, View Professional - which combined some of the attributes of al three. It was however rather large and unwieldy for the existing hardware!

However, when the Sinclair XL was released, its main program was called PipeDream - an enhanced version of View Professional.

At around this time, Acorn released the first 32 bit Archimedes, and PipeDream was released for the Archimedes. This was on the late 1980s. Pipedream was visionary - a program well ahead of anything else available on any similar computer.

In due course, PipeDream was upgraded and enhanced, PipeDream 2, PipeDream 3 then PipeDream 4. It now stands at 4.5 - and hasn't needed to change much for many years.

This page is an explanation of how 4QD use PipeDream, and by explaining this we shall give you an idea of the sort of things PipeDream can do.

4QD is a manufacturing business - but we also sell our products world wide to users both small and large scale. So we not only require the paperwork and systems of a volume electronics manufacturer, but we also need the point-of-sale systems of an exporting mail order retail business.

PipeDream does the lot!

As I use PipeDream so extensively for the business, it will come as little surprise that I also use it a lot for other private uses, and I will finish this treatise with some notes on how useful it can be for other things.

Mostly, I shall try and make this page interesting to people who know nothing of the program concerned, so there will be screen shots of PipeDream in action. However, for those who have PipeDream there will also be some example files.

Contents


Examples

Since this is a real description of a real business, I have supplied examples cut down from our real data.

Don't bother with these unless you use RISC OS and have a copy of PipeDream - you cannot run them on a standard Micro$oft Windows PC!

This link should cause your browser to display the contents of the examples directory.

In this text, names of example files will be coloured red

Manufacturing

Parts Database

Any manufacturing industry has to keep careful track of its manufacturing components. This involves a parts database giving sourcing and pricing information, and parts lists giving item by item parts inventory for every sub assembly. The main parts database is in PipeDream of course. It is in spreadsheet format, one component to a line as the following screen shot shows.

 

It has fifteen columns:
  1. Part No
    This could be any format, but we use xx-yy. The third character being a dash - is sometimes used to identify that the part number is from this database. This form of part number can contain mixed alpha-numeric characters and as there are 26 letters and 10 digits, gives us 36x36 possible categories (the xx part) and 362 parts in each category. 1296 categories with 1296 parts in each category should suit most systems, but there's nothing to stop 3 or more digit parts (or categories or that matter). A category consists of similar parts so resistors are in one category, capacitors in another.
  2. Stock
    The number of items in stock. A negative number means we have kits in production with shortages, or we have over-sold and are manufacturing to meet sales.
  3. Description
    can be anything at all.
  4. Each
    Price last paid, each.
  5. Qty
    Standard order quantity, this item.
  6. Supplier
    Short name for supplier. Full details held in suppliers database
  7. Suppliers part No
    This code is quoted in the order.
  8. Manufact
    Manufacturer
  9. Ref / last list
    This field changes: for a bough in part, it is the manufacturer's part number and for an assembly, the date last produced
  10. Last purch
    Date of last order.
  11. O/No
    Order number of last purchase. This is quoted on our internal order form at each ordering, thus establishing a chain linking all previous orders, so we can do a purchase trail to help place scheduled orders for the future.
  12. On Order
    Quantity currently on order. Order number will have been set in column10.
  13. Stock Value
    Value oc stock of this item. Column 2 x column 4. When this goes negative, these parts have already been allocated to a kit, so are costed there, or have already been sold, so costing is through to the invoice.
  14. Daily
    This is a column used by the sales system.
  15. Markup
    If we sell a component, without doing any assembly work on it, we need to make some profit on the sale. This is an uncommon type of sale, but we need to be able to charge a sensible price for parts from this list, e.g. when sold for spares. This markup value facilitates the process.

Parts Listing

The screen shot shows a typical parts list.

80-21
Cell A3
contains the part number of the list. We use categories below 80 for bought in parts, 80 and above for manufactured assemblies and sub assemblies. This is convenient because the re-stocking procedure is different for the two types of item.
Cell E3
Simply picks up the description from the database.
Cell G3
Here we enter the quantity of kits, for raising a kitting list.
Cell D40
The assembly's part number.
Cell E40
The assembly's description.
Cell G40
This cell writes back to the database the summed cost of all the components in a single assembly, so that piece part cost changes 'ripple through' the system automatically.
Cell G41
Picks up the 'markup' from the database.
Cell G42
Cost times markup: the price the system would automatically charge for this part.

The file names of these lists are:

  1. Qty
    Quantity of this item per assembly.
  2. Issue
    A calculation used in kitting: to make 100 of these enter 100 in cell G3 and this shows 100 timed column A.
  3. Stock
    A lookup. Shows current stock. If this is less that column B - we have a problem.
  4. Pt No
    The item's part number.
  5. Description
    A lookup in the database.
  6. Each
    A lookup in the database.
  7. Total
    A calculation used. Column F times column A.
  8. Comments
    used as required!

Kitting


Parts Inventory and stock control

Purchasing

Faxing orders

Letters

Goods inwards

Stock control and stock write-back

Part deliveries and scheduled orders.

Incoming purchase invoices and parts cost write-back


Point of sales

Order sheet

Standard Orders

Credit card sales

Cash sales

Credit sales

Stores muster note and customer paperwork

Receipt/Invoice/Credit note/Delivery notes

Labels

Sales despatch reconciliation


Invoices


Statements


Correspondence

Enquiries

Labels

Any mail order business uses lots of labels but there is a problem: order muster information, with customer paperwork and label is normally raised singly, one set per order. Printing labels singly can be a problem as labels come on sheets, so many labels to an A4 sheet.

Our solution to this problem is to use 4 label sheets (one A4 sheet has 4 labels) and to cut the sheets in half to give A6 sheets, 2 labels to a sheet. An A5 sheet is easily handled by a laser printer, can be printed twice by the same software simply selecting the half sheet to be printed by inserting the A5 sheet with the 'live' label in first, so the software doesn't know whether the second half of the sheet is used or not.

Some people will be concerned about cutting a sheet on half: it has to be done reasonably carefully or odd whiskers if cur label can come unglued during printing and can wrap themselves round the laser drum. How much attention you have to pay to that depends on the design of the laser and on how good you are at cleaning the drum. We feed lots of labels through and do not have many problems.

The picture shows the label on screen: The heading is actually an inserted drawfile and the text is looked up on a work-sheet. The yellow bits are protected slots, writen by the work-sheet.

Labl

Several variations on this theme occur: one for the current sale, one for service returns, one for general correspondence. Then we have a similar system for printing an address straigh onto a white A5 envelope.

Envelopes

Manuals


Pricelist: quantity

Accounting

We use two programs - PipeDream and Prophet. Doing essentially the same work in two different programs may seem like its adding a lot of extra work. Indeed, it clearly does involve some extra work. However each program has its plusses and is better for different aspects, so the dual program system does give more flexibility. Data transfer from one to the other is quite simple so the extra work involved is not a lot.

Where the dual entry system does save a lot of time is in checking the data. I'll not go into too lengthy an explanation now, but one instance is that in PD, we keep a log of bank transactions as they are initiated. When the statement arrives, I manually re-sort these into statement order, so reconciling PD against the bank statement is very simple.

We also enter bank transactions into Prophet. But it's a pain sorting into bank statement order in Prophet, so we simply mark as reconciled, and re-date any un-presented payments so they will 'date sort' to after the statement date.

In Prophet, we enter a blank 'bank ledger' entry at the statement date. That way each statement in Prophet should tie up exactly with the PD statemented date entry, but the dated log of the bank is in PD.

It seems like a lot of duplication, but it greatly speeds the finding of any discrepancies! Aa always, keeping two records as a double check is very helpful.

More information on this will follow in due course.

Bank Statement

Reconciliation

Credit card transactions

Prophet


Design and development

Other Databases

Fungi

Videos

Genealogy


This page's URL: http://www.4qd.co.uk/ro/pd4/bus/01.html

For queries and conversation on PipeDream the program used to run this system join and then write to the PipeDream mailing list.


© 4QD 2000
Designed by Richard Torrens using RISC OS hardware and HTML³
Last updated 19th June, 2000.