What is INVENTORY
This set of processes are the essential components for management of Cotton inventory. Inventory for a Cotton operation is handled differently to standard ITAS warehousing. The inventory records are usually created and updated by C2C processes i.e. operating companies will receive data files from external parties e.g. warehouses, government bodies. This files need to be translated to ITAS codes and vice-versa when exporting ITAS data to a third party system. The INVENTORY process does not communicate directly with the 3rd party systems but will import files that have been collected on the ITAS server and for export purposes the files will be secured on the ITAS server and other processes e.g. EDIfact will move the files to the target destinations.
For other inventory/warehouse commodities, the inventory data is maintained as a part of the TRADE record, whereas for cotton the inventory records are linked to their purchase TRADE and sale allocation independently. This results in a different database design whereby there are no physical TRADE allocations but only logical joins.
To facilitate multiple styles of import and export file definitions, the user (if suitably privileged) defines the data layouts (PARAMETERS) and dictates which layouts (IMPORT) to use with which files. There are several specific maintenance tasks and enquiries. There are processes for assigning bales (GROUP) to groups (shipping instructions), traffic/logistics (PLAN) instruction/execution and a sampling management (SAMPLE) subsystem.
Generally the sequence of operating processes follows:-
-
IMPORT; new inventory, warehouse receipts/updates, USDA classing data etc
-
REQUEST; request classing data from USDA
-
GROUP; create groups of Inventory records primarily for the purpose of shipment
-
PLAN; logistics planning. This produces the individual plans with update processes where hauler /warehouse comments can be appended. PLAN can be used to mark as fully executed, with completion dates and new warehouse details. The execution feature is not mandatory, especially if there are EWR imports confirming receipt. It is however very useful for status updating when INVENTORY has been delivered to a vessel/port, customer/mill.
Each of the different processes in INVENTORY are privileged controlled in CMP by their corresponding code, this allows the company managers to dictate which ITAS users can use which process(es).
The processes are:-
CODES, maintenance of supporting INVENTORY validation codes. ENQUIRY standard enquiry that handles user-defined summary with drill-downs to row-by-row bale record and a final drill-down to a detail BALE page presentation i.e. all the bale record (inv01) components EXPORT, Export routines for creation of files to be sent to 3rd Parties, except USDA Request for Classing data. There are additional CMP privileges for allowing production of specific export styles e.g. SEAM, LOAN MOVEMENT, REDEMPTION GROUP, group bale records for purpose of shipment, traffic movements or pre-allocation e.g. assign to the SEAM IMPORT, Import routines for EWR, USDA etc files as defined in PARAMETERS MAINTAIN, maintenance of bale records , row by row grid as defined in PARAMETERS MARKS, Maintain Marks Prefixes MKTP, Association Market Prices PARAMETERS defines the Import, Export and Maintenance screen layouts with the validation rules, translation criteria etc PLAN, logistics planning and execution REQUEST Export file creation for ‘Request Classing from USDA’ (fixed format) SWAP, Swap Classing Details VGROUP, view the existing Groups of bales as per the GROUP and the AGROUP processes.
AGROUP
This process is to allow amendment of existing groups. The selection screen allows filtering for presentation of a summary screen that allows drill-down to the detail GROP screen for the purpose of removing and/or adding INVENTORY items.
PARAMETERS – Import / Export Parameters
. This process is used to define the file layouts (both import and export) and it is also used to define the screen layout for the processes MAINTAIN (manual bale maintenance) when not running lot detail style. The key information is describing the records individual fields, especially their location and/or sequence. The target ITAS table e.g. inv01 determines the nature of the data i.e. numeric or alphanumeric character.
The help? on the PARAMETERS grid provides more detail as to the individual grid requirements. The most important entries are the validation criteria and the translation instructions. It is these entries that provide the link between different computer systems e.g. ITAS codes being shown in USDA style, dates being presented in different styles. Often ITAS will maintain an INVENTORY field with decimal precision e.g. Micronaire and the USDA /EWR format is whole numbers. It is PARAMETERS definitions that inform ITAS how to import/export.
IMPORT – Import Inventory Items.
This process is the primary entry of INVENTORY data, usually from EWR and USDA sources. The flexibility of IMPORT is that the import templates are maintained in the function PARAMETERS by the user body and it is their responsibility to define the field sizes, positions in the row, the validation rules and the translation rules. The import files are located in the specified ITAS directory and there are options to parse the file or to action an immediate import. The parse function will quickly locate any missing CLI codes and Purchase TRADEs and provide a simple report of codes that need to setup before successful import.
The import process will output a file of rows that fail full validation, in the same directory as the import file. If there are in excess of 100 rows in error the entire Import will be aborted with NO updating of the INVENTORY database. The reason for file rejection is that probably the Import template used does not agree with the content of the selected file being used for the import. The ERRORS file can be corrected and re-imported. The completion of the Import process will provide a full log of the successful entries and the file selected for import will be removed to the specified store directory. Other byproducts are a detailed report is secured in the OPRINT directory, accrual summary records are created and detail warehouse records are also created.
EXPORT
This process uses previously maintained PARAMETERS layouts, filter requests of the INVENTORY database and the specification of output file name in target directory. When the file has been created, the user will use other services (non ITAS) to physically transport that file to the recipient, usually EDI.
GROUP
The Grouping process is designed to create logical collections of INVENTORY data which can be assigned to Sale contracts, used for the bulk instruction/movement from warehouse to warehouse or simply to group for the purpose of pre-allocation e.g. the Seam. After selecting style of Group, name of the Group (Shipping Instruction), the user can modify the quality/specification grid which has been suggested from the contract or by manual entry of an appropriate code. Some elements of the specification grid contents can be selected for use in the filtering of the INVENTORY. There is also the user defined filtering screen which can complement the grid filters e.g. specific Gins, warehouses, US States. When the filtering has been entered, the proceed function will produce a summary grid of rows as per the user defined content (standard BENQ). The user then selects which rows they wish drill-down and the bale-by-bale grid is displayed whereby a selection of tools are available to select the specific items wanted for each group. The user can re-sequence the grid contents, can change what is shown on the grid and can provide additional filtering. When GROP is being used to create groups for Sales Assignment, the user can create multiple groups from the same filtered/ordered grid of bale items. An audit print can also be produced for each group with its’ unique Grouping reference. The existing Groupings can be viewed from VGRP. When a group has been picked for assignment to a Sales contract, there is a function available to analysis the group and compare the results with the target specification with regards Average and min/max contents.
PLAN
SAMPLE
MAINTAIN
This process enables privileged users to maintain any data element of the INVENTORY record, using the IMPA template ‘’. This is a backdoor procedure for correcting records without recourse to IMPO processes. It is expected that this process will have very infrequent use. The data elements that are available for inclusion in the ‘MAIN’ template are controlled by the IDD column (include in INVENTORY) on inv01 being ticked.
VGROUP
This process is enable viewing of existing groups. The selection screen allows filtering for presentation of a summary screen that allows drill-down to the detail GROP screen for the purpose of viewing/printing.
CODES
This process maintains all the supplementary codes/tables that are needed to validate the INVENTORY data that are considered non-core ITAS e.g. Cotton Color/Grade, micronaire values, bag conditions.. The name (type) of the code should be obvious as it will be used regularly in IMPA. See local help? for more detail. An important link code is the HBC code that provides a corporate summary coding for essential INVENTORY values e.g. micronaire, staple, grade.
REQUEST
The Request for Classing process will produce an export file in an ITAS directory/folder that needs to be transported to USDA systems by non-ITAS processes. The USDA request forms are fixed and the REQU process needs answers to several questions before filtering and bale selection can be completed.
ENQUIRY
This process is the enquiry into all INVENTORY that is deemed as active, i.e. record status is Open. The first screen is the standard filtering (determined by IDD). The next screen is a summary of the filtered items with the factory setting being group by Warehouse code. The summary values shown are No of bales, net, gross and tare weights. The user can modify the summary screen by standard Show/Hide/Refresh functionality and the grouping will be organized according to columns included in summary grid. The drill-down from a summary row will provide a bale-by-bale screen loading, with Show/Hide/Refresh functionality for personalized presentation. The drill-down from a bale row will show the full detail of the INVENTORY item. This can not be personalized. The contents are every data field maintained, each with their own help?. There is a summary screen of the accrual values for that INVENTORY item, a full list of all warehousing processes and a full list of all logistics movements.
CHECKIN
DOCUMENTS
LOTPRICE
MARKS
MKTP
PREGROUP
REDEEM
REPORTS
SUBTYPE
SWAP
TITLEDATE
UNREDEEM
Inventory interdependencies.
There are several data dependencies when maintaining inv01 information:-
a) Net weight, tare and gross weight are kept consistent. All 3 values are in the same weight units, determined by Company setting (S01).
b) The Purchase contract (TRADE) determines inv01_association and inv01_equity
c) The Gin and Type determine the growth code (inv01_growth)
d) The extraneous code (inv01_extraneouscode) is determined from State (inv01_state)
e) There are 3 x HBC fields that are table driven (cmy200) from Official Colour, Gov Micronaire and Gov Staple codes.
f) Warehouse accrual values for Receiving, Compression and Storage, if not imported from EWR are derived from CLI/Warehouse tariffs, and Storage is calculated to date.
g) Warehouse accrual value for Classing, if not imported from EWR are derived from centrally maintained (S01) rates, whereby the CLI/Warehouse static may indicate that the Classing fee is included in the receiving charge.
h) Warehouse accrual value for Delivery-out, if not imported from EWR are derived from CLI/Warehouse tariffs for inventory that has been marked as released from warehouse.