Applications Required

TRADE (A10)

Auto numbering will be set so existing numbers need to be taken into account when setting the start points for the numbers (Purchases, Sales, 3rdParty contracts, Internals)

Purchase contracts may be destined for stock or allocated to sales on a back to back basis.

Sale contracts may be fulfilled by stock or allocated to purchases on a back to back basis. 3rd party contracts will be entered and fulfilled by 3rd party stocks

Spot sales will exist for ‘owned’ and 3rd party stocks.

Haulage costs play a significant part of Molasses trading for valuation and invoicing. Haulage costs may be entered in the costs grid with a code that is set up in PHSYCODES as a ‘Freight’ Type. By entering the haulage rate in the Call-Off form the appropriate phys03 cost is created.

Contracted qualities will be entered and validated against those set up in PHYSCODES/Quality codes. Quality Targets which can be associated with Qualities may be maintained and used for quality adjustments at the invoicing stage. The standard Quality Targets will be Total Sugars and Dry Matters.

Call-offs from a contract can be created in TRADE on a contract by contract basis but it is more likely that EXPED  (A10 runmode 4) will be used to create the call-offs for a day.

Specific control flags used in TRADE

ctrl30_exped = ‘Y’ (allows expediting procedures)

ctrl30_fullquality = ‘A’ (qualities to come from cmy37)

ctrl30_haulageascost = ‘Y’ (entry of haulage rate in Call-off to create phys03)

ctrl50_pneumwtcode (used to establish weight code of pumped, loaded, final weights)

ctrl30_invloaded = ‘Y’ (allows marking of sales so invoice loaded weights and marking of sales to invoice quality adjustments)

EXPED (A10)

Expediting procedures can be run from TRADE or as a separate menu option. The Expediting facility enables reporting in addition to the creation of call-offs.

For standard call-offs a release number is generated, a contract split is created and marked as ‘C’alled off (shipping status with correct indicator in PHYSCODES). Some details default from the client/delivery client. The delivered product and price can be altered to one of those set up for the contract as a commodity option.

For 3rd Party sales the call off needs to be marked with 3rd party vessel and arrival date that are valid for the 3rd party. When 3rd party stocks are taken in the 3rd party, original vessel and arrival date are recorded. Any subsequent movements of 3rd party goods out of stock are recorded with the vessel from which they originated. This is done to keep a balance of each 3rd party’s stocks.

The call-off can be marked with the customer tank (allocation) – the format and basis come from PHYSCODES/Quality Codes. If the customer tank does not exist as a WIP account it can be created. 3rd party customer tanks are not created and the notation is used for reference only as no postings to the accounts will take place.

Pumped, Loaded, Final weights can be entered in EXPED on the Call-Off form (provided user is sufficiently privileged). Usually these will be updated in Loading/Pumping/Delivery procedures.

Call-Off information is stored on the phys09 table

 

WIP (K01)

WIP accounts are used to represent physical purchases, stock accounts, customer tanks, vessels.

For stock accounts the stock quantities and values are made up from stock transactions. The expense code determines whether the transaction is for ‘owned’ or 3rd party stock. As stock balances come from transactions it is wise to keep the number of transactions on the current tables to a minimum. An account can be marked as having its transactions archived at month end. This process coupled with the ‘STOCKS’ Monthly Balance Transfer keeps the number of current transactions to a minimum while retaining the tank make-up.

Board to Board will be used for trans-shipments although all transactions/contracts will remain on original wip. The transfer will therefore create internal sale an purchase with the purchase being assigned to the new wip.

ctrl02_showwipmolasses = ‘Y’ (molasses tab available showing ATH reference and latest tank quality)

ctrl06_3rdpstocktransfer (used to identify 3^rd party stocks)

ctrl06_3rdptankclean (used to identify tank cleaning transactions)

ctrl30_b2binternal = ‘Y’ (on board to board create internal contracts)

 

STOCKS (A40)

 

Movements

Intakes from a purchase.

Purchase is marked as sales invoiced; purchase is marked with stock tank and stock tank journal; if operating trace then purchase is marked with trace id; if unallocated purchase is marked as allocated to stock tank; if unassigned purchase is marked as assigned to stock tank. The posting is between the purchase wip account (pre update) and the stock tank. If the purchase was unassigned before the update then the wip account reference is constructed from the purchase number (tranche/header)

Other Intakes.

No purchase is involved so a nominal ledger account is required as being the origin account. Destination account is a single stock tank. Intake can be ‘owned’ or 3^rd party in which case the 3^rd party, vessel and arrival date are required.

3^rd Party intakes can create/update a 3^rd party balance record which identifies the 3^rd party, origin vessel and arrival date so usage of the 3^rd party stocks can be traced (thibal table). 3^rd party movements are record on the movements table (thimove) for ease of reporting in THIRDP.

Overpumpings.

These can be intra or inter terminal and owned, 3^rd party or both can be transferred. The posting is between the two (or more as one movement can be put in many tanks) stock entities.

Movements into Transit

Transit accounts will be customer tanks created in EXPED when a call off is generated. New transit accounts can be created with a selected reference or using the system generated account if the ctrl50_autotransbase is set up. Stocks can be moved into a transit account from a purchase, nominal ledger account or stock account

Stock can be moved into a transit account from shore tanks. The value and make-up of the transit account can be used to create a new purchase which may then be assigned to a vessel. This represents moving stocks on to a vessel to be allocated to a trade sale. The purchase is marked with a buyer and seller of the operating company, terms of ‘EXTANK’, payment terms of ‘N/A’ and price code of ‘PMT’. The purchase is marked as invoiced with a wip of the transit account. A journal is created between the stocks and the transit account.

If the purchase is moved on to a vessel a journal is created between the transit account and the vessel and the purchase is marked as being assigned to the vessel.

All stock movement records are marked with the ctrl06_stocktransfer expense code or ctrl06_3rdpstocktransfer depending on whether the movement is for ‘owned’ or 3^rd party stocks.

ctrl50_exchdiff

ctrl50_gainloss

ctrl50_adjustment – default accounts for postings

ctrl50_oneintakeposting = ‘Y’ (on intakes any associated costs are added to the main intake transaction leg)

ctrl50_autotransbase – presence of this means system generated transit accounts are required.

ctrl06_stocktransfer

ctrl06_3rdpstocktransfer

 

Parcel ID

Each stock parcel is given a system generated ID which can be maintained in STOCKS on the Parcel ID table (cmy08). On an intake the original purchase, transaction, destination tank are all marked with the new ID. If stocks already exist in the tank the new stock can inherit the ID or the old stocks can be moved in and out of the stock tank to adopt the new ID.

When stocks are moved from shore tanks to customer tanks the ID is transferred onto the customer tank and from there on to the delivery to provide a ‘start to end’ trace of the goods.

With the trace feature active it is not possible to have more than one product in a tank unless the other second product is water.

ctrl50_trace = ‘Y’ activates the trace facility

ctrl50_lasttraceid holds the most recently used parcel ID

 

By component

Stocks can be moved around by component or by summary tank product. When a purchase is put into stock the transaction inherits the purchase product which then becomes part of the make-up of the tank. Over time it is possible for a tank to contain a mixture of products and product grades. When goods are moved out of stock the movement can be represented by a single transaction leg for the tank product or a leg per product in the stock tank moved out in ratio of the product to the tank total quantity.

Presentation of the tank make-up is via one of the following methods.

1)     By component. The make-up is derived from the sum of the different products on all stock transactions involving the tank.

2)     Mix. The ‘mix’ transaction legs are exploded into the tank components that were in the tank at the time of the ‘mix’ movement. The ‘mix’ transactions are recognised by having the same product code as the tank.

ctrl50_stockbycomp = ‘Y’

 

Cleaning

When new products are to be put into a stock tank the tank will be emptied of its residue. The cleaning facility creates a movement and assigns the ctrl06_tankclean (or ctrl06_3rdptankclean)  expense code to the transaction for identification. The journal reference for the most recent tank clean can be seen in WIP on the stocks page.

 

Monthly Balance Transfer

This mode enables the selection of stock tanks for balance summary and transfer. A temporary adjustment transaction is created to move stocks (by component if required) from one month to the next creating a zero closing balance in the origin month. The make-up of the tank is not lost. If the tank is marked as having its transactions archived at month end and the origin month for the TA is the period being closed then all transactions up to the end of that month will be archived thus speeding up stock tank processing.

Reports (A45, A79)

Stock reporting is undertaken in STOCKSQ for position, reconciliation and parcel ID reporting and in DELREP for mstkr, clqual, srs reporting.

Most reports are accounting transaction based using expense codes and dhltype to put the transaction in the correct report section

PQIS, AUTOTERM, other Loading Procedures

 

Introduction

PQIS procedures are driven by terminal/depot as maintained on the gf_ctrl51 table. All terminals on the table for all companies are available so duplication of terminal names across companies must not occur. This should be a consideration when operating test companies as copies of live companies. All relevant tables within an operating company will record the terminal (pqis, pqist, targ, targt)

Tank Analysis (A75)

The tank analysis is manually entered in PQIS per date by tank and stored on cna52 table. Stock tanks without tank analyses will not be available for selection in pumping and loading procedures

Target Table (A75)

Qualities set up in PHSYCODES/Quality Codes can be used as qualities on the target table. The target qualities are maintained per terminal on the targ table. Tanks that should used on the target table are stored on the targt table per quality/terminal

PQIS (A75)

The PQIS table is created for all qualities for the selected terminal using the excel solver (maintained by the operating company). The spread sheet should reside in itas\pqis and be called pqis_itas2000.xls.

When activated, all the target qualities are sent to the solver along with all the stock tanks at the terminal and any parameters attached to the stock tanks in the target table. There is an issue that the excel solver can only populate 200 cells in a spread sheet. There is an additional issue that the current spread sheet was created for a terminal with a maximum of 5 tanks which is insufficient for SvG in Amsterdam.

Link to Autoterm

PQIS tables and tank analysis details need to be transmitted to the commpc to be available to the Autoterm system. The commpc is a networked server and the IP address of this server is stored in the ctrl50_commpc column.

In the ALOAD and APNEUM procedures the relevant files generated by Autoterm are retrieved from the commpc using ftp commands

ALOAD (A76)

This procedure processes a selected file retrieved from the commpc and updates the call-offs (phys09) created in EXPED with pumped amounts.  Phys10 rows are created to represent the tanks used in each loading. Once processed the file is transferred to the ‘old’ folder (itas\loadreport to itas\loadreport\old). Any records on the imported file that are invalid will be kept in the current folder in a new file using the same file name but with ‘_unmatched’ appended.

Currently there is no batch procedure and the retrieval and processing of files is manual.

APNEUM (A76)

This procedure processes a selected file retrieved from the commpc and updates the stock tanks (cna53) with pneumercator readings for tank levels

Once processed the file is transferred to the ‘old’ folder (itas\pneumercator to itas\pneumercator\old).

Currently there is no batch procedure and the retrieval and processing of files is manual.

EXPEDQ (A76)

This is the none-ATH mode of pumping and is generally used for 3^rd party movements. Unpumped Call-offs are available for selection and the tank, water and total amounts pumped are entered along with narrative, pumpman’s initials and brix reading. The entered tank must have a specific gravity reading else conversion from mackpacks to tonnes is not possible.

Pumped details are populated on the call-off (phys09,phys10) and the contract is marked as allocated to the generated blend reference. The wip account representing the blend will be created if the pumping is not 3^rd party.

There is a flag in PHYSCODES/Quality Codes used to indicate that a quality is to be used in EXPEDQ.

The full quality text description (PHYSCODES/Quality Codes/View Text) can be seen under the button on the EXPEDQ selection grid.

EXPEDR (A76)

Allows reversal of manual pumpings. May create reversal tank journal if the pumping has already been processed by TANKM.

DELE (A77)

Whether created through ALOAD or EXPEDQ the loaded, delivered and final weights will be entered in DELE. Feed invoicing is carried out on final weights and in DELE final weights will be defaulted from delivered weights unless the call-off is marked as being invoiced on loaded weights (phys01_invloaded) in which case the final weights will be defaulted from loaded + intruck weights.

The call-off is marked as delivered (shipping status with appropriate flag) if the delivery date is entered. The other weights are entered on the call-off (phys09) for each release. Supporting tank details are updated (phys10) if the loaded weight differs from the pumped weight.

Another aspect of DELE is the entry of actual ratios/values from analysis. This is normally a separate procedure to the entry of loaded/delivered weights and will be carried out by a different person. For this reason the entry of weights and actual ratios is controlled by privilege so the relevant user only sees what is relevant to the task being performed. Ratios are added to the delivered rcord (phys10) so that all details for a single call-off are kept together for ease of reporting.

TANKM (A76)

TANKM creates stock journals and can be run at any time. The idea is to run it every 2 hours (minimum frequency) so that the stock position is kept up to date.

Journals are created per stock tank detailing the movements for loaded but unprocessed call-offs (phys09_loadeddate <> 0, phys09_processed <> ‘Y’) between the tank and the customer tank.

3^rd Party journals are generated in the same operation but separately as the postings are different, standardisation has to be taken into account and third party balances are reduced (thibal).

DELREP (A79)

DELREP reports per terminal and therefore can be run from one company for all tables on the database. The delivery report within DELREP is the QCR which is based on the vms version and uses phys09, phys10 and PQIS tables.

 

THIRDP (A50)

The Delivery Report displays all 3^rd Party deliveries for the selected date range and 3^rd party by third party in grid format enabling drilling down to TRADE display

The Stock Summary shows the balances of 3^rd party stocks per 3^rd party/origin vessel/arrival date (thibal)

The usage statement shows usage of 3^rd party stocks by vessel with an option of including the standardisation quantity. There is an option to mark the deliveries reported in the usage statement as invoiced (phys01_invdate) to remove them from subsequent EXPED listings which exclude invoiced trades.

 

TRADEINV (J04)

 

General

Invoicing of Sales allocated to purchases

Contracts are grouped by counterparty and currency

Postings

Values brought back to sales contract P&L currency (euros) using currency journals

The client is debited in contract currency on the invoice

A journal is created in the sale P&L currency for cost of sales. The sales invoice amount in P&L currency will also appear on this journal if invoice currency differs from contract P&L currency

Any non P&L costs (sales commission, purchase value, commission and costs) will be posted between the FX account and P&L account in P&L currency and between the FX account and WIP account in actual currency

Where present contract and cost exchange rates are used. If not present spot rates are used.

 

ctrl30_vatfrom = ‘T’ (from trade)

ctrl30_postpl = 4 (goeg code + ‘S’+ 2^nd part of commodity code

ctrl30_postinv = ‘P’ (to P&L)

 

FEEDINV (J01)

 

Invoicing of Feed Sales is based on final weights which are expressed in ctrl50_pneumwtcode units to be consistent with pumped and loaded quantities

The retrieved deliveries are displayed and all those to be invoiced are selected in one go.

Invoicing creates the document, accounting postings, updates contracts with invoice marking, revenue, cost of sales and margin, reduces quantity in customer tank.

 

Grouping

Invoices are grouped by  counterparty, delivery account, invoice indicator (invoice delivery account, counterparty, head of family), invoice address indicator, delivery date, vehicle, currency, P&L currency, VAT code, contract terms and department.

Haulage

If the contract terms are defined as meaning that the haulage rate is added to the contract price for invoicing then the price is adjusted – PHYSCODES/Contract Terms

If a Haulage Account has been entered onto the contract the haulage is invoiced separately and can use a different invoice template if one is selected.

Any haulage is calculated (phys03 freight)

Quality Adjustments

An SI is created based on the contract details. A single cost can be added to the invoice. Quality adjustments are enabled if the phys01_invqualadjustment is set in TRADE. Quality adjustments are calculated basis the EXTANK price so haulage is removed.

Currency

The accounting invoice is expressed in the sale P&L currency (euros) although the document sent to the counterparty is in contract currency. Conversions are at spot rates.

VAT Code

VAT code is taken from the contract.

If not VAT code is present the VAT code is taken from the Counterparty profile

If it is still empty the VAT code is set to ‘N’

CN/DN

Credit Notes/Debit Notes are created by entering an adjustment to price or quantity. Cost of Sales is recorded for the difference in addition to P&L

 

Reports and Enquires

The main reports not already covered are ITOP for position keeping and MOLR for Molasses reporting.

Valuation databases can be maintained in TRADEV, STOCKSV, WIPV and reported in most enquires.