We have expanded our customer management capability to include additional status assignments

• We have added new status options in our "Your Customers" page:
• - 'Customer Inactive' = Customer is not active and is not able to transact in any way on the platform; no orders can be created (manual or via forecasting service) and the customer is not active or presented in any view.
• - 'Customer Active' = Customer is active and is able to transact fully with the supplier or carrier.
• - 'Credit Hold' = Customer is on credit hold until the setting is changed; no orders (created via forecasting service, manual or call-in, or from the customer portal or mobile app) can be created once this setting has been applied. This is different from the current credit hold web service that is used to integrate with a 3rd party ERP credit management module to approve individual delivery/order requests.

We have made changes to our forecasting setup process

• Users now have the option to separate individual tank profiles from the initial (or “static”) usage distribution profile.
  
• Users are also able to apply usage templates to both locations and individual tanks – this allows a customer to create different consumption profiles for every tank at a location or site.
  

We have added a new super admin (CA) role to allow users to move across multiple accounts

• TrueFill can enable an existing user to be a CSA; if a user is a CSA, s/he will have the privileges and permissions of all user roles.
• CA users will be able to switch between assigned accounts once logged into TFX.
• A dropdown is provided to the CSA in the header allow the user to toggle between accounts that have been assigned to the user.
• A CA will also be able to impersonate a user in and perform functions in TFX.

We have updated our carrier performance reporting

• TFX provides carrier performance reports to supplier and carrier customers looking to better understand how carriers assigned orders and/or locations to manage actually perform based on customer instruction.
  
• We have increased the standard frequency for delivery confirmation report - this will be sent daily at 6 AM EST and include 30 day rolling data.
  
• - New columns have been added: Site / BU# and Load to DDT Time (time between the truck/trailer being loaded and delivery details rec'd by TFX)
• - We have reformatted date columns
• We have also made enhancements to our LFV (lift file validation
  - process used by customers to reconcile vendor lift files with actual deliveries) Dashboard and Accrual Report enhancements:
  
• - More columns have been added: Drop End Date, Created Date, Site/BU#, Location Address, Load to Drop Time, Load to DDT Time
• - It is now possible to multi-select for 'export' feature

There is a new set up process for our Dispatch and Logistics Management product

• Consistent with our service redesign, we have de-coupled the service set up for each product from others.
  
• Users can create and setup regions, drivers, shifts, and trailers from the dispatch tile
  

New workflow enabled that requires user-provided reason code reason codes when order/delivery requests are deleted

• Customers can enable a new optional workflow that requires dispatchers and other users to select a reason code when deleting an order/delivery request.
  
• Reason codes are customizable.
  
• FX maintains order/delivery request deletion history (date/time stamp) that will now include reason codes.
  

There is also a new process for enabling FX forecasting and inventory management service

• This new process is how customers can enable the forecasting engine and complete the setup process.
  
• This is where the user is able to set trailer proxies, shift proxies, and provide other details required for the product.
  
• Users will also be able to create multiple forecasting profiles (usage distribution or demand curve) and apply them in bulk to tanks and locations.
  

Shift proxies have been added to forecasting and inventory management service

• Shift proxies are used in forecasting to determine when to create "should go" and "must go" order/delivery requests - the definition of a "should go" order = the tank will run out if the order qty. is not delivered in the next shift, a "must go" order = the tank will run out if the order qty. is not delivered in the current shift. The forecasting engine uses forecasted consumption rate to determine that time window.
  
• If a customer is using TFXs dispatch and logistics management product, the forecasting engine will use the actual shifts created for dispatch instead of the proxies.
  

We have enhanced our 3rd party carrier integration functionality to better support load planning

• Dispatchers now have the ability to select the carrier service region when assigning a load to a carrier when the carrier region count is > 1.
• A carrier is an optional PO/contract-level setting and when this is selected the assignment is automatic.

We have added a draft and published states to delivery/order requests that are assigned to 3rd party or common carriers

• TX has always made this paradigm available for loads assigned to internal drivers, and carrier loads were automatically published when assigned.
  
• Users will now be able to create a load plan for a carrier in draft state and then publish when ready.
  

We have expanded options for delivery/order request automation in our universal dispatch service

• TX has long included functionality that bundles delivery/order requests created for the same customer location and product - this was done largely for retail customers and to mitigate against unintended duplicate orders.
  
• Users can now change this behavior at any customer location - allowing the bundling to happen or to have delivery/order requests remain separate and discreet.
  
• If a customer chooses the latter, each individual order is available in the dispatch workbench to schedule into loads. This option also applies to delivery/order requests sent to 3rd party or common carriers.
  

We have added a new ATG inventory service to the TFX suite of tank data service provider integrations

• TFX now supports TMW inventory data capture.
  
• We leverage TMW CmpID and TMW TankID to ingest inventory data and fold into our forecasting and dispatch and logistics management services.
  
• We are able to pull inventory data every 30 minutes via this integration.
  

Other Enhancements

• We have added two more data parameters - Delivery PO# and Vendor ID (Terminal Supplier) - to our daily delivery details reports.
  
• We have also standardized our TFX filters in the global Ul.
  

We have developed a new exception management rule that allows a company to "hold" deliveries completed by specific driver(s)

• We have customers that would like to be able to create a "review period" for new or specific drivers - to make sure the delivery details provided by the driver(s) are complete and accurate.
• A company can select specific drivers and all deliveries completed by those drivers will be held for review in the EMS dashboard. Those details may be edited if needed and then submitted to the reconciliation service and/or back office.
• This rule is optional and can be enabled in the EMS service.

We have started making changes to the TX customer portal

• TX includes a customer portal that is automatically populated for every customer (our customer's customer) - this includes complete delivery history, in-flight status, inventory, etc. is presented real-time. The user is also able to create or request orders that are then immediately presented in our customer's dispatch workbench (if they are using TFX universal dispatch and once they clear credit check).
  
• We have started a general refresh that will see us slipstream changes over the next few quarters.
  

TX has is now integrated with Titan Cloud's inventory data service

• We have added Titan Cloud as an option for our customers to use for inventory data capture.
  
• The integration is enabled at the location-level during set up and once configured is ready to go.
  

We have modified the default sorting logic for delivery & order requests

• When delivery/order requests are created and pushed into the dispatch workbench (DSB), there are several options tor how a user can view or sort/tilter these
• We have added an option to sort by date and delivery window (time).

Enhancements have been made to our credit check work flow for customers that use SAP back office

• There is an SAP transaction ID that is created when a deliver/order request is created in TX and passed to SAP credit module for approval; we now include this SAP value in the presentation (UI) when a request comes back with status = "failed" and is added to the "on hold queue".
  
• When a user selects "retry" for a request that is on hold without the SAP ID, TFX will push that request back to SAP to fetch the value.
  

We have updated our logic for delivery/order requests created using our TFX forecasting service

• We are in the process of a significant upgrade to our existing forecasting service which uses tank consumption rate (sales or usage) history to forecast both order and load creation. These changes are being deployed across several sprints.
  
• This new logic is now available in production for customers that enable automatic forecasting. We made changes to the location set up in an earlier release to allow users to provide better historic consumption (usage) history and smaller distribution periods - this new set up serves as the basis for the forecasting service.
  
• Forecasting for a product + location combination is re-run every time a new inventory input is rec'd by TX; these include:
  
• - Manual inventory update (dip test or other inventory update provided by a user).
  
• - Changes made to forecasting set up.
  
• - Inventory data capture per frequency setting (i.e. how often do we call the inventory service or tanks?)
  

We have added the delivery window to the main dispatch workbench (delivery schedule builder)to allow quick view sorting by date/time committed needed

• This same display covers both manually-created order/delivery requests as well as those that are automatically created by the software.
• Full transport (FTL) and LTL/short-truck are also both supported.

A new web service (API) has been published to provide quick and ready comparisons between what was requested vs what was actually delivered

• This web service allows a user to see any differences between delivery instructions sent to a carrier (product, qty., delivery window, load code/contract) and what the carrier actually executed.
  
• This same API can be used for internal, owned-and-operated deliveries as well.
  

We have published a web service to allow the easy import of driver credentials, licenses, and badges

• We are often asked “how to get driver details that have already been created in a 3rd partyHR module or ERP system” into TFX – now they can! Simple API to consume and these details can be pushed directly into TFX to update the driver profiles that are used in dispatch and logistics planning.
  
• API also supports updates made in 3rd party software -> TFX.
  

Another web service has also been published to import driver schedules into TFX

• This API allows drivers’ schedules, time off, and holidays to be imported into TFX from a 3rd party service.
  
• The real-time load status is visible to the supplier and customer in TFX.
  

Expanded service support for customers that dispatch only to common carriers

• In our dispatch workbench, the columns are typically assignable to drivers or trucks/trailers – this can be done automatically based on a driver or asset schedule.
  
• With this enhancement, customers that only use common carriers for deliveries can have these carrier names automatically assigned to these same columns – allowing a user to see which loads have been assigned to which carriers.
  
• If a supplier has a con-mingled business model (e.g. uses both in-house drivers and common carriers), s/he is able to toggle back and forth to see both types of loads being dispatched.
  

We have added optional data fields for TFX -> PDI web service

• Users can now include time in/out data in the delivery details JSON object we send back to PDIE.
  

We have added support to capture real-time, customer-provided POD (proof of delivery) details

• Users will be able to see the customer POD details on invoices and digital delivery tickets (DDTs).
• Ability for users to enter POD details when creating a manual deliveries and order/delivery requests (including load creation).
• Drivers are also able to add POD details they receive from customers post-delivery (onsite) for both FTL and LTL deliveries; this is optional and can be restricted/enabled in settings.
• Customer POD details can be provided in the mobile driver app when dropping multiple products (different POD details for each product).

TFX now supports internal inventory transfers in our Dispatch & Logistics Mgt and Invoicing & reconciliation services

• If a trailer is assigned to a shift, every order added to a load will decrement the trailer’s available capacity (this is already available in the load – but now it is presented in the workbench).
  
• Optional validation helps ensure the user does not overload a trailer or truck.
  

We now support service requests that are commonly scheduled in dispatch: First up, pump outs!

• We have modified the ship-to object to include a parameter to mark the location as a "company owned site" – the same modification is present in the dispatch workbench (DSB).
  
• This allows alignment when the lift point is a company-owned bulk plant; this allows inventory to transfer but remain “inside” as a transfer. Several supply-side companies leverage virtual inventory mgt and this change makes it easier to support.
  

We have expanded our common carrier support functionality to include the creation of carrier regions (Phase 1)

• Suppliers can create carrier regions to better support dispatching to larger common carriers.
  
• These regions include optional attributes that can be used to load balance capacity (e.g. number of dispatchers assigned, contact details, trailer capacity, asset count, etc.).
  
• In future phases, carriers will also be able to create/modify these same regions that can then flow into supplier accounts where hauling/freight contracts have been created – keeping data in-sync.
  

A new technical design has been implemented to improve performance to our much-utilized invoice and DDT summary pages

• A few sprints ago we released web services that allow users to fetch larger runs of delivery data – now that we have customers using this service, we have modified page default settings and limited the look-back window for this page.
  
• Newly-added region support allows for more surgical and relevant queries.
  
• Historically, we have provided several customizable columns included in the grid/table view – while most of these were seldom used, they were still loaded into the browser and this created drag. In response to one of our super-duper-users (a wrecking ball, really, when it comes to heavy data queries – we’ll pretend his name is “not Scott”…), we have modified the default set to what is most commonly being used.
  

We have added a PO/contract-level setting that will pre-populate net/gross/dropped quantity in our mobile driver app

• This is in response to higher rates of driver error in certain customer regions – especially when we have a contract that calls for specific values to be used for back-office invoicing.
  
• All fields are presented as “active edit” and are subject to eBOL over-write where supported.
  
• This is an optional setting.
  

We have released our first significant change to our forecasting service!

• We have refined our initial sales/usage distribution set up for enabling forecasting; this allows a user to define distribution over day-of-week and within the user-defined time bands (striping) during the day.
  
• This set up is the basis for enabling training data to begin feeding our machine-learning algos (fancy, schmancy AI).
  
• As we collect more actual usage data, the backstop or initial distribution is replaced and refined.
  
• Our bulk upload feature for historical data has been updated to align with our new model.
  

We have updated our driver scheduling feature to make it easier to create schedules for drivers and assign these to regions and trucks/trailers.

• Users are now able to use a multi-select option when creating driver schedules or moving drivers between regions.
• Users are now able to select and assign multiple trucks/trailers to a driver(s).
• User are also able to create driver schedules in the future – with or without an end date.
• We have also created an option to add a driver to a shift “on-the-fly” in the dispatch schedule builder (workbench):
• - Applies only if the user has enabled the columns = driver names on the workbench
• - If one or more driver(s) is not scheduled to work on that day, a dispatcher can assign one of these drivers (without scheduling him/her first) to a newly added column

Users are now able to add the terminal supplier or vendor when creating a delivery/order request

• In addition to adding a load code to an order, a dispatcher can now specify a terminal supplier for the lift. This is an optional field.
  
• A terminal supplier assigned to an order will be passed to the driver (via driver app) along with the delivery schedule details.
  
• If a location has been assigned to a carrier, the order TFX automatically sends to the carrier can include the terminal supplier as well.
  

TFX also supports an optional terminal supplier parameter in delivery details capture

• Although we can programmatically extract terminal supplier values from eBOLs, we have extended our delivery details capture to include support for terminal supplier or vendor values; these supplier names can be translated by using the self-serve value-mapping available to users.
  
• Optional data parameter is included in the TPD (3rd party delivery) API, bulk file upload, and manual delivery creation.
  

We have expanded our “Carrier Light” functionality to include delivery status

• Smaller carriers (or those that are unable to easily use TFX) can leverage functionality we deployed awhile back that we call “carrier light” – this allows real-time access to inventory and sales data for customer locations, orders created in TFX and sent to the carrier for fulfillment, and the ability for the carrier to go back into the simple (and one-page) order summary and provide delivery details (BOL#, net/gross/delivered qty., timestamps, load codes, etc.) – takes about 15 – 30 seconds and delivery details are back to the supplier!
  
• Now the carrier can use this same interface to provide delivery status updates – what we sometimes call the “pizza tracker” part of our dispatch service. “Where is my driver now, has he left the terminal, is he arriving soon?”
  
• The real-time load status is visible to the supplier and customer in TFX.
  

Expanded service support for customers that dispatch only to common carriers

• In our dispatch workbench, the columns are typically assignable to drivers or trucks/trailers – this can be done automatically based on a driver or asset schedule.
  
• With this enhancement, customers that only use common carriers for deliveries can have these carrier names automatically assigned to these same columns – allowing a user to see which loads have been assigned to which carriers.
  
• If a supplier has a con-mingled business model (e.g. uses both in-house drivers and common carriers), s/he is able to toggle back and forth to see both types of loads being dispatched.
  

We have added functionality to our “Carrier Light” feature that allows common carriers to receive inventory data and orders

• As an option for smaller carriers, TFX will send a link to a carrier which, when bookmarked, can be refreshed anytime to present the latest, real-time inventory details and any orders that have been sent to the carrier (orders can be created by the supplier or the end customer).
• The carrier will now be able to go to this bookmarked page, see their orders, and provide delivery details (e.g. BOL#, net/gross, time stamps, loading codes) – which has the same effect as if the driver had used our driver app or the carrier provided the delivery details via the web services (APIs).
• Updated delivery details are made available to the supplier and customer and are processed through the exception management and reconciliation services – and are sent to the back office. This process begins within seconds of delivery detail submission.

We have added a “counter” for trailer capacity to the dispatch workbench

• If a trailer is assigned to a shift, every order added to a load will decrement the trailer’s available capacity (this is already available in the load – but now it is presented in the workbench).
  
• Optional validation helps ensure the user does not overload a trailer or truck.
  

We now support service requests that are commonly scheduled in dispatch: First up, pump outs!

• We have added service requests to our universal dispatch service – and pump outs are the first service that can be scheduled into a load.
  
• A pump out request can be created in the dispatch workbench (for suppliers/carriers) or via the customer portal.
  
• Pump out options include a.) Simple product removal, b.) Remove and replace (same product), or c.) Remove and replace with a different product. Any product that is removed includes the option to price – and disposal for cross-drops to ensure “bad mix” is not brought back into inventory; if a cross drop creates a new, sale-able product (e.g. dyed diesel is dropped into a tank of clear diesel & dyed diesel is now in the tank) TFX accounts for the product in inventory and dispatcher is able to schedule delivery or create a preload.
  
• When created, service requests are added to a separate queue that is available to the dispatcher on the workbench.
  
• The mobile driver app has also been updated to handle pump outs – and all scenarios.
  
• Optional service fees can be added to the pump out activity.
  
• A balance invoice can also be created and pushed into the back office.
  

We have added a new start page for all suppliers and supplier/carriers

• New start page reflects the services that we actually provide vs. a more “monolithic” presentation – which, admittedly, given the very broad range of functionality can be a bit overwhelming to new users.
• Includes existing services (e.g. inventory management and forecasting, dispatch and logistics) as well as a nod to some soon-to-be-released services (supply management).
  
• In more enhancements and changes coming as we version other supporting services to add more “starting your day” value to these pages.
• The old dashboard/portal page may still be accessed from the preference settings page for users that want to use it.

We have added functionality to support smaller carriers that provide freight services for our customers

• We already have an option that allows a carrier to receive a link to a webpage that includes inventory data for all locations (and products at these locations) to which they have been assigned; all the user needs to do is bookmark the webpage and refresh anytime she wants to see the latest inventory details. If the location is reassigned to a different carrier (or pulled in-house to manage) that location will no longer be available to the carrier. The carrier will then use whatever process or technology she likes to create the loads, dispatch, and deliver product to our customer.
• We have added a tab to display all delivery/order requests that have been sent to the carrier – this includes any delivery/order request that is manually created by a dispatcher, created by a customer (if the location is assigned to be fully managed by the carrier), and automatically created by TFX.
  
• Delivery/order requests can include product, delivery window, and loading codes. For some types of deliveries (e.g. a branded c-store) the delivery window is likely enough; but for commercial customers or retail locations that require more nuanced load planning, this provides the carrier with better replenishment guidance.
• Carriers will be able to take action to indicate acceptance of assigned delivery/order requests. These actions will be reflected in the supplier dispatch system as well as the customer portal.
• Stay tuned for upcoming functionality – ability for these same, smaller carriers to provide delivery and BOL details directly into this webpage is coming soon!

We have added terminal suppliers/vendors to our master data mapping tables

• We allow customers, carriers, and customers to create value mappings for terminals and locations, products, and common carriers – these values are used to translate data being passed from various parties relating to a single transaction.
• Terminal supplier and vendor is now included in that feature. These can be set for any terminal or bulk plant location.
  

We have added the ability to include the terminal supplier/vendor when creating a manual delivery

• When creating a delivery manually, a user is now able to add a terminal supplier to each BOL or lift ticket (for bulk plants or other non-terminal lift points).

Lite Version of TPO form

• The new lite version of the supplier’s order creation form has been introduced. The four-page form is now shrinked to a single page form, with sections made collapsible.
• The default values will be fetched as per the admin set values, which can be modified on the form if and when required.
  
• The default values can be set at the company menu → Order Defaults.

Lift file record validation check for LoadDate format

• TFX will now validate the format of the lift file record parameter “LoadDate”.
• The passed value should be of 8 char only in the date format of MMddYYYY.
  
• If the parameter passed is not in the correct format, then the entire file push will be failed with a failure message in response to the API request.

Flag at order level to allow consolidation of the deliveries

• An order-level flag has been introduced for users to allow the consolidation of the deliveries of different fuels that are dropped at the same customer location.
• The changes have been made to process the delivery details through API as well. If the request contains delivery details for more than one fuel, but the order doesn't allow consolidation, then the system will give a validation error.
  

DR Changes / Cancellation Alerts to Carriers

• When the Supplier recalls a DR from the Carrier, we have added the email alert being sent to the Carrier.
• We have added the functionality of allowing the Supplier to 'Edit' or 'Delete' a DR which has been assigned to a Carrier without requiring the Supplier to recall the DR. These actions would be possible so long as the DR has not been scheduled by the Carrier.
• We have allowed the Supplier to recall/edit/delete the DR that the Carrier has published for a future date (i.e., next day onward).
• Email notification would go to the Carrier for any of the 3 actions that are taken by the Supplier.

Supplier Admin || Ability to edit or delete the Bulk Plants

• The supplier admin users will now be able to edit or delete the bulk plant(s) created by the company users.
• The system will not allow the deletion of the bulk plant if there exists any delivery in-flight that has the selected bulk plant assigned as pick-up location.

Load Optimization Phase 1

• Trailers will have now an optimized value which can't exceed the overall trailer capacity.
• Dispatch users need to enable this functionality from the settings page, and make sure trailers will leave for the location with 100 percent capacity.
• The moment trailers are not used with their full capacity, TFX will pop up an Alert message to correct the capacity and then publish (No hard restrictions here).
  
• Non optimized load reports will be sent to the selected internal users of the company.

Delivery Time Estimate for Loads

• Now, while building a load for a driver, a dispatcher will be able to make certain that a driver isn’t driving/working too many hours - there are regulations that govern this.
• A user will be able to know how much time each delivery will take when building the load adding manual inputs to serve as a time proxy.

Ability to Stop ATG polling for Tanks and edit Inventory manually

• Now, users will be able to stop the ATG polling for tanks when the device installed on tanks may be hampered or turned faulty.
• Also he/she would be able to edit the inventory reading manually if ATG devices have fetched incorrect readings.