Previous Section Index Page Following Section

SECTION 13.

Case Rationalisation and System Utilities.

(Covers: Case rationalisation, Case database creation, Case database use, Other rationalisation issues, Store database and Intranet use )

This section of the manual deals with a number of other features which do not neatly fit elsewhere into the manual.

13.1 Case Rationalisation.

The rationalisation of case and shipper designs is of increasing importance in many companies, both from the viewpoint of cost reduction and in the light of new re-cycling regulations. 

Earlier, in Section 8, one possible route towards rationalisation was introduced in the form of the Cube Shipper database

This database helps answer the following question:

Which of our standard distribution shippers / pallet boxes / trays should we use for this product in order to maximise fill?

It examines automatically the efficiency with which a given product (perhaps a case) can be fitted within each of shipper and ranks these. In such solutions any or all of the valid case orientations may be used to maximise fill.

Whilst the above database can be very useful, it does not address the question of rationalisation at an earlier stage in the logistics function - the generation of case sizes:

Do we have a case which we use already for some product(s) which could also be used for this product?.

It may well be that your company has certain standard case designs which you would like to consider using, if appropriate, for a given product. PALLETMANAGER, using the Case Database described below, provides you with a facility to identify whether any existing case designs are similar in internal size to the case sizes generated by PALLETMANAGER in Collation / Tertiary mode.

13.2 Case Database Creation.

The first stage in implementing the Case Match database facility is the input into a datafile of existing standard case sizes. Details of up to 200 standard case sizes can be input as described below. 

To enter data into the database you select CaseBase from the opening PALLETMANAGER menu.

You are then presented with the Case Details Screen which provides you with the facility to input the internal dimensions of your standard case sizes.

The options shown allow you to enter / modify / delete the descriptions and sizes of up to 200 standard case sizes. These sizes and descriptions are held in a datafile in sorted order according to shipper description.

The Next and Previous buttons allow you to browse through the database. The ++ and -- perform a similar function initially but in a large database move more through the database several entries at a time. Entries can be added or deleted. Having completed changes End Edit will save the database updates (if any) to disk. If you need to abandon all changes a Quit option is available at the top left of the screen (as with all other PALLETMANAGER screens).

The simple database created (CASEBASE.DAT) is automatically utilised during a PALLETMANAGER Collation / Tertiary run.

13.3 Case Database Use.

Whenever PALLETMANAGER Collation / Tertiary is run, a check is made to see whether you have set up a Case database.

If so, then, as the Results Summary Screen (Screen 5) is displayed, each case size is checked against your datafile, and, where a results line utilises a case whose internal dimensions are 'similar' to those of an existing design in the datafile the line reference number will be preceded by a star (*) character. (or in some instances a ? character - see just below for an explanation)

The degree of 'similarity' is defined as follows:

If X, Y and Z are the internal dimensions of a case generated by PALLETMANAGER and Xd, Yd and Zd are the internal dimensions of a case on the database then the case generated will be 'flagged' as similar if the following is true.

If Xd lies between X and X plus 5% AND

Yd lies between Y and Y plus 5% AND

Zd lies between Z and Z plus 5%.

Thus when a * is shown the database case (internal size) is as big or slightly bigger than that generated by PALLETMANAGER as being required for the Collation..

If a case dimension (say X) of 300mm is generated, the database will be examined for values where Xd lies between 300mm and 315mm. The 'degree of tolerance' has a 5% default value, this being held on the first line of the file casebase.dat, together with the number of entries in the datafile. Users may modify this value using a text editor (e.g. Wordpad).

The screen and printed reports also provide you with information on the Case Description of the CaseBase entry which has been identified as being similar to the Case generated using Collation / Tertiary.

The above concept has recently been extended as a result of user feedback to include a coding where an existing case in the database is 'nearly big enough' by using a ? instead of a * . Examples flagged up using a ? are probably too small to be used, but this may depend upon the allowances made for inter-primary gaps, headspace etc within the collation case design.

If X, Y and Z are the internal dimensions of a case generated by PALLETMANAGER and Xd, Yd and Zd are the internal dimensions of a case on the database then the case generated will be 'flagged' as possibly usable (using a ?) if the following is true.

(a) At least one of Xd , Y and Zd is as big or bigger than X, Y or Z by up to 5%

(b) If Xd lies between X minus 5% and X plus 5% AND

Yd lies between Y minus 5% and Y plus 5% AND

Zd lies between Z minus 5% and Z plus 5%.

Thus those PALLETMANAGER entries marked with a ? may have a CASEBASE database entry which might just possibly be used, but only if changes were made to the packaging allowances made in the current collation calculations.

 

13.4 Other Rationalisation Issues.

Many companies find themselves in a position where they have hundreds or thousands of different case sizes which they would like to rationalise. Whilst each product can be tackled individually the question may still remain:

What cases sizes are the most efficient to use for my products?

Miralis Data have in-house expertise and software which may be able to assist in answering such a question - please contact us for further details.

13.5 The STORE Database.

As detailed in Section 9, the STORE module which retains details of specifications for subsequent re-printing or re-run, utilises a database file Storfile, together with an index file. 

The STORE process creates a compact numeric based database of each solution. The current release accommodates up to 5000 product entries. The display and printing actions from STORE can carried out on the same PC as originally used to solve the problem, or another (remote) PC using a 'stand-alone' STORE display configuration. A file with 5000 entries is unlikely to exceed 10Mb of disk space. The module can also be used (outside of PALLETMANAGER) to create a CD/ Intranet / Internet based resource for display of specifications.

For a number of technical reasons this process is not part of the PALLETMANAGER suite, and may require Miralis Data technical input to translate the Storfile to the necessary HTML and graphics formats. However the Webbase facility described in detail in Section 14 of this manual will normally cater for such requirements. Such files can then be held on a CD or Intranet and accessed by all users.

Please contact Miralis Data for further details.

 

Previous Section Top of Section Following Section