BLENDTECH, A division of PT Industrial Electric Co.

Author: Josh Edelman

Liquid fuels or other fluid component marketing across territorial borders in the western hemisphere require a transaction record called a Bill of Lading or BOL. The generation of the Bill of Lading for transport usually begins with transactional data generated by a vehicle operator or loader manually entering this information at a Toptech RCU or Multiload. There is also a screen in the TMS system where manual transaction data can be entered. This transaction data includes information about the loader, the vehicle being filled and the company that owns the vessel transporting the product. This also includes information about the business nature of the transaction including the supplier of the product, the customer purchasing the product as well as the accounting and destination information needed to physically route the customer’s purchase.

In addition to the information about the transaction, the product information must also be displayed on the BOL. This includes product type/ description and the amount of the product loaded as well temperature and density information relevant for government regulated volume correction. If a blended product is loaded, the recipe may need to be displayed as well as the location of the tanks and/ or meters where the product was blended depending on local law.

As well, any regulatory text, hazard messages, or other safety messages will need to be displayed on the BOL per the local legal requirements.

These are the steps for generating load rack transactions for use in Bill of Lading generation

• Load Bay Transaction Information validation – This occurs at the Toptech RCU/ Multiload, also known as ‘bay’ or ‘rack,’ or in the Manual Transaction screen in TMS.
• Loaded product information generation – This occurs at the loading position, also known as load arm or ‘preset.’ This is typically a pipe or hose that connects to the vessel being loaded and is driven by pumps and valves that are controlled by automated dispensing devices also known as ‘presets.’
•  Formatting/ Regulatory text generation – This occurs after the transaction and product information are collected from the load rack devices described above. That data is then sent to the TMS system which attaches regulatory text data and provides format for hard copy.
• BOL Print – This is the physical output of all the previous data onto hard copy for use by the transporter of the product.
• BOL Data Transmission – This is the electronic output of the BOL data into different databases, file formats, and reporting modules as pre-determined by the companies involved in the transaction. 

Transaction Header/ Load Bay information

The beginning of BOL generation is also the beginning of the load rack process for the driver/ loader of the vehicle used. Typically, the customer purchasing the product from the supplier will have pre-arranged a loading agreement including purchase orders or quotas for transporting products over a period from the supplier or distributer to the purchaser’s destination. 

When the operator of the vehicle used to transport the product drives the vehicle to be loaded up to the Multiload or RCU used to fill the vehicle, that person will insert a card containing a driver ID, or manually enter the driver ID using the keypad into the Toptech RCU or Multiload. He will then enter the vehicle and carrier info as well as the supplier and customer data pre-arranged for the transaction. Purchase order data as well as shipping information may also be requested. Time and date info will also be recorded.

Once all of the transaction-relevant information has been entered by the driver, it is then validated by the TMS software and confirmed at the RCU by the driver or loader. The loader can then move to the preset to enter the product information.

Transaction Product/ Transaction Component/ Loaded Product information

Once the driver has all of his transaction info validated by the TMS system via the RCU, he can then move to the loading positons and enter the product and quantity. The devices that automate the load positions are typically called presets as this is the location where the loader pre-set the amount of product to be dispensed before it is loaded. Legacy loading methods required loaders to stop product flow at exactly the right time to meet the agreed upon amount, which sometimes resulted in overruns. These presets are usually Acculoads or Brooks Petrocounts. A multiload will simulate the existence of a preset device on screen by allowing the loader to select multiple ‘arms’ or virtual preset devices.

These preset devices, or virtual presets in Multiload, collect the load data including product information, density, temperature, flow rates, volumes, recipes of blended or additized products, meter and tank data, as well as load start and stop times.

Once the load is completed, the driver can then exit the preset and RCU/ Multiload systems. The Product load data is automatically collected by the bay and preset programs in TMS and sent to the BOL generating programs for processing.

Transaction Format/ Regulatory Text information

Once the load is complete, the product information is combined with the transaction header information by the bay program, bay_rcu and written to a local c-tree database on the TMS system called the transaction log or trlog.dat. Each transaction is given a trlog reference number. This allows the loader to chose multiple transactions at a time, or combine transactions at different bays using the same transaction log number.

After the load data is stored in the trlog, it is used by the BOL programs to generate the BOL print image, inserted into MySQL database for accounting and reporting, and may also be sent via EDI to any third parties like email recipients or enterprise data feeds such as TDS, DTN TABS, or a proprietary SAP system.

There are three bol programs that collect and manipulate data before passing it on to each other in the following order:

• /tms6/bin/tmsbolc – Performs API calculations on load rack data
• /tms6/bin/tmsbolp – Places info into flat text files and database tables.
• tmsbolf – Formats BOL data into printable hard copy format. Sometimes replaced by an equivalent BOL formatting program

The first BOL program to use the trlog data is the tmsbolc or BOL calculation program. This performs any gross to net API calculations based on temperature and density info collected from the preset’s load data. This program then passes the original gross and calculated net data along with the header data to another BOL program.

The second BOL program, tmsbolp then takes calculated data from the tmsbolc program and performs two tasks:

• BOL transaction header and product information is written to local text files
• BOL transaction header and product information is assigned a Transaction Reference Number and is written to MySQL tables

Transaction data is placed into text files organised by daily folio number to be used in TMS reporting. Identical data is also placed into the following database tables for use in automated inventory management, reporting, and load rack control. The Transaction reference number is the key to the relationship between all transaction tables.

• TransHeader – All transaction information including Supplier, Customer, Account, Driver, Vehicle, and load times.
• TransProduct – All saleable product information including total gross & net volumes, temperature, density, product name
• TransComponent -All product recipe information including gross & net volumes of component products, individual temperatures & densities
• TransComments – Any alphanumeric data added to the comments section of manual transaction entry screen
• TransEDI – Any electronic data interexchange (EDI) information attached to the transaction after processing by the bay_rcu program. EDI data is used to route transactions to third party recipients.
• TransOutQueue – Transaction reference number as well as EDI information are added to this table for use in sending transaction data to remote clients by Toptech rpc or tcpip data transmission programs

The tmsbolp program then passes the BOL data to the third BOL program tmsbolf for formatting into PDF or text file that can be processed for printing. There are other programs developed by Toptech Systems that can be used in place of tmsbolf simply by assigning the name tmsbolf using the n= literal. These programs are:

• /tms6/bin/bolsrv – A binary program that uses x,y coordinates to place tags which make calls to MySQL table data
• /tms6/bin/TransEngine – Java based transaction formatting program that uses imported java report files
• /tms6/bin/DocEngine – Java based transaction formatting that uses native SQL tables to format data and issue MySQL queries.

BOL Print

Once the tmsbolf program has produced a PDF or text file, the file information is then passed to /tms6/bin/tmsprintserver. This program assigns font sizes to text BOLs and underlying .eps image files to BOL PDF images. The tmsprintserver program is also responsible for determining if a printer is to receive raw serial data, in the case of dot-matrix printers, or PDF image data in the case of most laser printers. All of this information is kept in the TmsPrinter table in MySQL database.

Once the additional print information is processed by tmsprintserver, it is directed to a printer via Route Code data in the RouteControl table. Route codes are how TMS organises transaction data traffic. Each route code is tied to a printer name assigned to a printer by the C Unix Printing System or CUPS.

The Print job info is received by cups, all of the components of which are locate in /etc/cups directory. The printer details to which print jobs are routed are kept in a printers.conf file also in /etc/cups. CUPS printer service logs are kept in /var/log/cups directory for troubleshooting. There are two logs located here, access log for messages relating to CUPS attempting to access a particular printer by serial or IP address, and an error log for any error messages finding, processing, or sending print job to the printer in printers.conf specified by the Route Code in MySQL table RouteControl.

BOL Data Transmission

The information placed in the TransOutQueue by tmsbolp is read by RPC (Remote Procedure Call) or TCPIP (Transmission Control Protocol) programs developed by Toptech Systems. The TransOutQueue data read by these programs contains Electronic Data Interchange (EDI) routing information attached to the transaction by the bay_rcu program before being passed to the BOL Programs. This EDI data is kept in the Terminal, Supplier, Customer, or Account EDI tables which the bay_rcu program reads on transaction authorisation.

After reading the TransOutQueue and collecting the Transaction table data related to the TransOutQueue entries, these data transmission  RPC or TCPIP programs then create customisable flat text files which are subsequently transmitted via FTP/ SFTP/ SCP to a remote system for processing by third parties. The connection information for these transmissions can be kept in either a flat text file in the /tms6/scripts directory, or in the CommunicationConfig table in MySQL database. See specific data transmission method documentation for details about flat file configuration, location and connection information configuration.