APPENDIX 3 -Data Interchange with other systems.
(Covers: Summary of Data required, Consignment Title, Container Details, Items in the consignment, Missing Data and the Itembase, Technical details, Results output to other systems, Previous Linkfile Formats, Cylindrical Items).
This section of the manual discusses how complete sets of consignment data could be input into CARGOMANAGER from other system. If you require information on how (just) a product / item database can be created from other systems (to enable data entry of consignments via point and click), then this is described in Section 10.
CARGOMANAGER users can not only input consignment data quickly and easily into the system using the powerful inbuilt screen based data entry features but can also feed data directly from other applications into the system. This can be accomplished in a number of ways. For example some users already generate fixed format data files from within their own applications, the format of these files exactly matching the internal formats used by CARGOMANAGER.
However a far easier and more flexible input mechanism is available using free format comma separated (flat) data files which can be generated from virtually any database / spreadsheet application including applications such as Microsoft Excel and Access, as well as from far more sophisticated systems. This appendix describes the type of data required, and describes the default values which CARGOMANAGER will provide in the event that some data is not available from the selected data source. Included in this description is detail on how CARGOMANAGER can retrieve some missing file data (e.g. product dimensions) from the Item Database which is an integral part of the software.
Datafiles created to this specification will normally be given a .CSV file extension and will be input into CARGOMANAGER using the 'Input a .CSV file Linkfile' menu option on the opening screen. It is also valid to give such files a .DAT extension (an extension normally used for consignment files generated by keyboard entry into CARGOMANAGER screens), and in this case files will be input using the 'Recall a .DAT Datafile' - accessed once again from the opening screen.
Summary of the Data Required.
CARGOMANAGER requires the following information on each consignment:
A consignment title / description or code for identification purposes;
Details of the container / trailer size to be used (where available);
Information on the items which are to form the consignment.
Item 2. above may or may not be available. Indeed the object of the exercise may be to determine which container / trailer size should be used for a given cargo set. CARGOMANAGER enables the user to select a specific container size or perform a comparison between any or all of the container sizes held in the CARGOMANAGER container database, and there is no requirement for a container size as part of the input data.
Whilst information on the products in a consignment (Item 3) are naturally required, it may be that some of the characteristics of individual entries (e.g. weight, stacking characteristics etc) may not be available via the external source. Once again CARGOMANAGER is designed to deal with any limitations in the data, whilst allowing user modification of any of the values prior to performing load planning.
The following sections of this appendix describe what information is required by CARGOMANAGER, and how it deals with missing data.
Before doing so we have illustrated below a typical spreadsheet containing the complete set of data used to tackle a specific problem - that used as an illustration of data input in Section 3 of the manual. To provide greater clarity extra headings have been added (in red) in Row 1, Columns B to J, to reflect the meaning of the consignment data of Rows 3 to 6. As will be illustrated below, the information requested exactly mirrors in both order and type the information input into the data input screen of CARGOMANAGER.
The headings in the spreadsheet could in fact be left in place in any spreadsheet used as excess data on any line of the input file is ignored. In Excel a valid datafile could be created by simply saving the above datasheet (a copy of spreadsheet.xls will be found in the installation folder) using a .CSV format - a standard option (a copy of spreadsheet.csv will also be found in the installation folder).
IMPORTANT: Note that the number fields do NOT contain any commas (i.e. a value of 2300 is shown as 2300 and NOT 2,300. It is essential that NO commas exist in the numeric fields - Excel allows you to decide the way numeric fields are displayed.
The file itself which would then be input into CARGOMANAGER might look something like:
Example - Manual Section 3,Length?,Vert?,Width,Vert?,Height?,Wt?,Heavy?,Fragile?,Layers?,Qty?,Priority?
5867,2330,2197,20000,Container Description,,,,,,,
Product 1 - Pallets,1100,L,750,N,1550,500,Y,N,99,3,1
Product 2 - Promotion,1120.6,Y,690,Y,720,20,N,Y,99,9,1
Product 3 - Bulk Packs,500,Y,420,Y,280,45,N,N,999,49,1
Product 4 - Catering,590,Y,460,Y,535,40.5,N,N,99,82,1
A3.1 Consignment title / description.
The first line of any file provided to CARGOMANAGER provides a textual description describing the consignment.
Consignment title / description | The first 40 characters of this field will be used as a descriptor on printed / emailed reports. |
The only restriction on the contents of this line is that it MUST NOT begin with a " quotation mark. Any occurrences of " or ' elsewhere within the line will be replaced by blanks.
Any extra entries on the line will be ignored (thus in the above example the extra entries Length? etc on the first line would be ignored).
A3.2 Container size / Description.
The second line of the input file contains dimensional information on the container together with a textual description. This line must always exist in the file, however if the details are not available (and as described below just a set of ,,,, are provided) then a default container size will be selected. The end-user can always change the container size or make a selection of any container in the inbuilt container database as the file is being input into CARGOMANAGER (or thereafter).
Container length (mm.) | An integer value (no decimal point) up to 32000. |
Container Width (mm.) | An integer value (no decimal point) up to 32000. |
Container height (mm.) | An integer value (no decimal point) up to 32000. |
Container weight limit (kg). | A real (decimal point) or integer value up to 99999.0. |
Container description. | A textual string - the first 25 characters will be used. |
Thus valid lines might include:
5896, 2350, 2385, 27000, Maersk 20 ft Std
5896, 2350, 2385, 27000.0, Maersk 20 ft Std or
, , , , or ,,,, (4 [or more] commas with or without spaces before/between).
In the latter 2 cases CARGOMANAGER will initially set the container size / weight limit and description to be a 20' standard Maersk container, but the user is prompted to change this when the file is input.
Once again any extra entries on the line will be ignored.
A3.3 Items in the consignment.
A typical shipment will consist of one or more lines of data, with each line detailing information about a specific product type in the consignment - description, dimensions, the quantity to be shipped etc. A shipment can comprise of tens of thousands of individual items of up to 600 product types (i.e. up to 600 lines of data).
[CARGOMANAGER will perform packing operations such that any individual container may contain up to 20,000 items, with up to 998 containers loads being planned in a single step.]
The information required for each product type in the consignment reflects the data requested on the CARGOMANAGER data input screen. An example of this screen (as used in an earlier section) is shown below:
In this instance the first 'Case' type being loaded is actually a loaded pallet. This is one of 4 item types being loaded in the example detailed in Section 3 of the manual. The datafile entry for this product will look something like:
Product 1 - Pallets,1100,N,750,N,1550,500.0,Y,N,1,3,1
which follows in sequence the responses which a user would provide in completing the above screen. If some of the data is not available in your external data source then the missing blank values will be substituted as detailed below.
Note that the above line of data has 12 items separated by 11 commas, and any line of consignment data must contain (at least) 11 commas with data as available. A entry such as:
Product 1 - Pallets,1100,,750,,1550,500.0,Y,N,1,3,1
is valid, with the 3rd and 5th blank entries being replaced by default values as described below.
Case code & description | Text describing the item type - just the first 40 characters (if there are that many) are used by CARGOMANAGER. |
Case Length | An integer value (no decimal point) up to 32000. See Note 1. |
Can Length be placed vertical? | N or Y or L (alternatively 0 or 1 or 2) - if no entry then N assumed. (see Note 2 at foot of table) |
Case Width | An integer value (no decimal point) up to 32000. See Note 1. |
Can Width be placed vertical? | N or Y or L (alternatively 0 or 1 or 2) - if no entry then N assumed. (see Note 2 at foot of table) |
Case Height | An integer value (no decimal point) up to 32000. See Note 1. |
Case Weight | A real (decimal point) or integer value up to 9999.9. (Default 0.0) |
Is the item heavy (must be floor based) | N or Y (alternatively 0 or 1) - if no entry then N assumed. |
Is the item fragile (nothing else on top) | N or Y (alternatively 0 or 1) - if no entry then N assumed. |
Max Number in a stack | An integer value 1-99 (no decimal point) - if no entry then 99 assumed. |
Number to be packed | An integer value 0 - 20000 (no decimal point) - if no entry then 0 assumed. |
Packing priority | Normally an integer value 1-99 (no decimal point) - limit of 32000 possible. if no entry is made then 1 is assumed. |
Note 1: CARGOMANAGER works in mm. units and data for the case dimensions are required as integers with no decimal point. As an extension, data on Case Length / Width and Height may be input here with a decimal point and in such instances the decimal part will be ignored. (e.g. 23.1 becomes 23). | |
Note 2: As seen on the above input screen it is possible to specify that length or width of the item (here a pallet) must be placed lengthwise in the container (to cater for, for example, a 2 way entry pallet). A value L or 2 as defined in the above table may be used to indicate this for one of these entries. |
Thus a simple line in this file representing the data in the above sample screen might look like:
Product 1 - Pallets,1100,N,750,N,1550,500.0,Y,N,1,3,1
Alternative valid formats would include:
Product 1 - Pallets,1100,0,750,0,1550,500.0,1,0,1,3,1 (0/1 used for N/Y)
Product 1 - Pallets,1100,,750,,1550,500.0,Y,,1,3,1 (default No values will be inserted for missing values)
Product 1 - Pallets,1100.1,N,750.45,N,1550.27,500.0,Y,N,1,3,1 (decimal parts of case length / width / height will be ignored)
Essential elements in each line of consignment data are:
(1) That there are the correct number of comma delimiters on each line (11), though excess commas / data after these on each line do not matter. For example the following would be valid:
Product 1 - Pallets,1100,N,750,N,1550,500.0,Y,N,1,3,1,,,,,
If there are insufficient commas on any line then generally the line will be ignored.
(2) Where a value is not available then either 2 successive commas or two commas with one or more blanks between them are provided.
(3) The file should have a file extension .DAT. The user will then be able to select to load the file from within the normal CARGOMANAGER data input process.
The above descriptions of the datafile requirements included information on the defaults which are applied when specific input data fields are blank.
One additional feature of CARGOMANAGER is the ability to automatically insert information on products which are already held in the inbuilt ITEMBASE (the database of Case Codes / Descripitions and dimensions) into an input datafile which lacks certain information. How this is done is described below.
If any item in the consignment file has a Case Code / Description, but has dimensions (L/W/H) all set = zero, then on reading this data CARGOMANAGER will scan through the ITEMBASE to see whether the Case Code / Description matches one already held in the database. If it does then the ITEMBASE details will be retrieved (Length, Width, Height, Orientation and Layer constraints) and inserted to replace all the fields in the consignment file with the exception of the quantity to be shipped and the priority. Thus for a product held in the Itembase the input file need only contain a description, quantity and priority with all the other fields being set to blank.
A3.5 Technical / Support Issues.
In situations where a .DAT/.CSV file is successfully created according to the above format then the detail provided in this section is likely to be irrelevant. However if problems are experienced when reading such a file into CARGOMANAGER then the following information will be of assistance.
When CARGOMANAGER attempts to read a .DAT/.CSV file then one of 2 input procedures may be called.
If the first character in the .DAT file is a " then the file is assumed to be a fixed format file using the standard CARGOMANAGER data format. This is unchanged from previous releases and is not covered in this Appendix.
If the first character is NOT a " then a free format file conforming to the above data description is assumed and this file is then read in and automatically converted to the internal formats used within CARGOMANAGER.
For the benefit of those experiencing problems is generating a suitable file this process is described in detail below.
Step 1: The input file is first read (but is never changed), and a file FREEOUT1 is created. During this process a logfile is created in the installation folder called FREEFORM.LOG to which comments and errors in the read process are output. During creation of the FREEOUT1 file the focus is on checking the input file format and creating the intermediate file FREEOUT1. If an invalid line is encountered in the input file then a warning message will be posted to the logfile, and where possible a repair (of FREEOUT1 - not the input file) using default values will be carried out. If a repair is not possible then the record in the input file will be ignored and a warning message posted to the logfile.
Step 2: The second stage of the process takes the file FREEOUT1 and converts this to the final CARGOMANAGER format file FREEOUT2 - this is the file which is then (automatically) processed by CARGOMANAGER. During this stage the validity of the values supplied is checked and appropriate defaults inserted where necessary.
The content of all the files referenced immediately above will be of no interest even to the user or their technical support staff, except in the case of problems reading files created from other applications. Any of the files can be examined using a standard text read program (Wordpad, Notepad etc), and the files referenced above will not be deleted until the next input file is read.
In addition to providing a highly flexible system for input of load data CARGOMANAGER also outputs information on loads created to file for input to other systems. Given that in most instances some graphical representation of the load plan will be required then in most instances, after a cargo set has been loaded, users will wish to proceed with the inbuilt display of the 2D/3D load plans and print these (or save in Adobe PDF format).
However, when the only requirement is to produce a list of the items to packed into each container then a file MCONTENT.OUT will be of assistance. This file, which will be found in the installation folder, contains details of the items loaded. Whether the load is packed into a single container (BestCont / PackCalc) or multiple containers (MultiCont) this same file will provide information on items packed.
An extract from a typical file MCONTENT.OUT is given below, in which the codes F2000.. are the end user product codes:
Load Description Date: 10/05/04 : Suppl
Trailer
Container: 1- Items Packed: 46
1, F2000011002259> C1 Q>240 , 1300, 1100, 495, 1
1, F2000011002260> C1 Q>30 , 1300, 1100, 495, 6
1, F2000011002261> C1 Q>15 , 1300, 1100, 495, 4
1, F2000011002263> C1 Q>240 , 1300, 1100, 495, 1
1, F2000011002264> C1 Q>300 , 1300, 1100, 495, 1
1, F2000011002265> C1 Q>600 , 1300, 1100, 495, 1
1, F2000011002267> C1 Q>1200, 1300, 1100, 495, 1
1, F2000011002269> C1 Q>120 , 1300, 1100, 495, 1
1, F2000011002270> C1 Q>120 , 1300, 1100, 495, 2
1, F2000011002281>SPEC 11 Q>30 , 2000, 1100, 1200, 5
1, F2000011002282>SPEC 11 Q>25 , 2000, 1100, 1200, 4
1, F2000011002292>SPEC 11 Q>25 , 2000, 1100, 1200, 6
1, F2000011002293>SPEC 11 Q>30 , 2000, 1100, 1200, 3
1, F2000011002307>SPEC 10 Q>15 , 1650, 1100, 1180, 4
1, F2000011002308>SPEC 10 Q>15 , 1650, 1100, 1180, 6
Container: 2- Items Packed: 64
2, F2000011002266> C4 Q>60 , 1300, 1100, 1180, 4
2, F2000011002271> C1 Q>120 , 1300, 1100, 495, 2
2, F2000011002272> C1 Q>60 , 1300, 1100, 495, 1
2, F2000011002273> C4 Q>60 , 1300, 1100, 1180, 4
etc etc etc.
Each line comprises - Container Number, Product Code, Dimensions, and Quantity Loaded.
For a specific application it would clearly be possible for alternate files / formats to be generated. Please contact Miralis Data for further information.
In previous versions of CARGOMANAGER we utilised a comma separated user generated file named CMLINK.FIL to provide the link to other systems. This format was far more difficult to generate than the format now used. In this release:
Since this chapter was first produced we have introduced the facility for each item in a consignment for it to be denoted as a cylinder / drum.
All such entries are assumed to be placed in the container with the circular base at the bottom. This obviously means that the length and width of the cargo item (drum) must be equal and that neither the length or width can be placed vertically. If these factors are not met then the drum indicator (a tick box) will not be available in manual data entry.
It is possible to flag up cylindrical items in the Linkfile. This simply requires that a '1' (drum) or '0' be placed at the end of the input line of data.
Thus in the earlier description a unit might be entered as:
Product 5 - ,750,N,750,N,1550,500.0,Y,N,1,3,1
would now be entered as:
Product 5 - Drum,750,N,750,N,1550,500.0,Y,N,1,3,1,1
If no entry is found then the non-cylindrical item will be assumed. Thus previous format linkfiles will work as expected without change.