Resolving Deny and Error Codes

Resolving PDXR Deny Codes

Deny 01 – Invalid Seller ID (S)

For an Authorization Request, indicates that the Seller ID does not exist within DTN TABS as received from the terminal. Either the terminal is sending the wrong Seller ID or the Seller has not been established in the DTN TABS database. DTN PetroDex Support can work with the terminal to correct the Seller ID within the Terminal Automation System (TAS) or set up the Seller ID in DTN TABS.

Deny 02 – Invalid Shipper ID (R)

There are two main reasons a Deny 02 occurs:

- The terminal has incorrect data in the Seller/Final Shipper position. DTN TABS Support will work with all parties to resolve it.
- The party in the Seller position has not properly configured an expected Third-Party rule. DTN TABS Support will assist in identifying what the expected rule should be and assist the parties in configuring the necessary information.

Deny 03 – Invalid Truck Number

This denial code does not appear in DTN TABS or logs currently. It is not in use.

Deny 04 – Invalid Seller/Terminal (R)

There are two main reasons a Deny 04 occurs:

- The terminal ID is being sent incorrectly. The terminal is sending the Seller ID as the owner code vs the actual owner code or a bad SPLC. To resolve this, DTN TABS support will reach out to the terminal to get the owner code or SPLC corrected.
- The terminal ID is being sent correctly but the terminal setup in DTN TABS is not correct. DTN TABS Support will correct this by verifying the expected ID and, with your permission, update the information for you.

NOTE: DTN TABS Support requests that if you are adding a new terminal to
your database, reach out to us for verification of the expected SPLC and
Owner code as this can help make certain that your side is correct.

Deny 05 – Invalid Customer ID (R)

There are three main reasons a Deny 05 occurs:

- The consignee being sent by the terminal is not set up within your DTN TABS database.

You can see this by running the Transaction Log Pro report and noting the Consignee Name field is not populated. If the consignee value is valid, add this number to your DTN TABS database and associate it with the terminal. If the number is not valid, additional work will need to be done with all parties involved to get this corrected.

- The consignee exists in your database but is not assigned to the terminal
  in question.

This can be diagnosed by using the Transaction Log Pro report and noting that there is a name in the Consignee Name column. If you click the hyperlink for the consignee number, you will then be sent to the Seller consignee Details page where you can see that the terminal (in this example Amarillo) is not in the assigned terminals list.

Assigning the terminal to the consignee then saving the record will resolve the issue.

The consignee exists, the terminal is assigned to the consignee in question and a deny is still occurring. This is caused by Carrier Authorization Check, an optional feature in DTN TABS. Look at the Admin > TABS Defaults page within DTN TABS to see if this option is turned on.

If this option is turned on, determine if the SCAC code is setup within TABS by going to Data Management > Carriers and using the search feature. Alternately, use the Carrier Report under Reports to verify what has been configured.

If the SCAC code is not setup, go to Data Management > Carriers and enter the Carrier Name and SCAC in the template. Save.

If these steps are completed, determine if the SCAC code being received on the authorization record is correctly associated with the consignee in question.

In this case, you can see that there are no carriers assigned to this consignee. The resolution would be to add an association or change the option from Restricted to Allowed in the Assign Carriers pane above.

Deny 06 – Deny – No Check

A Deny 06 only occurs if you have an authorization level that is set to Deny. The best way to diagnose the issue and find out where the Deny record is configured is to run the Allocations Report.

Remember the terminal and consignee receiving the deny in order to get the broadest view of what is impacting your customer. Once in the report, select the terminal/consignee and then click View Report. Scroll through the results to find a record that says Deny in the Auth Option column as shown below.

Note: The values in the Terminal/Terminal Group columns and the Consignee/Consignee Group columns will direct you to the options to select in the Allocation/Manage pages.

Deny 07 – No Credit Record (Legacy Credit Users Only)

For an Authorization Request, a Deny 07 indicates the Apply Credit Allocations option in the Allocations Setup page was selected, but no credit allocation was created and attached to the allocation record. The seller needs to go the Allocations Setup page and either unselect the Apply Credit Allocations option or create and attach a credit allocation to the allocation record.

Deny 08 – No Product Record

There are three causes for this denial:

- Authorization Option is set to Credit and/or Product with Apply Product selected or only Product selected, but there is no product allocation associated with the record.
- Product allocations attached to the authorization points set to Credit and/or Product or Product have records attached but all records are past their expired dates. No Unenforced or Active periods are available for DTN TABS to clear products for loading.
- Product allocations attached to the authorization points set to Credit and/or Product or Product have records attached but all records are set to Inactive (Flat allocation periods only) with no Active or Unenforced periods available for DTN TABS to clear products for loading.

The best way to diagnose the issue and find out what specific allocation is causing the denial is to use the Allocations Report.

Remember the terminal and consignee receiving the deny in order to get the broadest view of what is impacting your customer. Select the terminal/consignee, then click View Report. Scroll through the results to find a record that meets the criteria above.

Note: The values in the Terminal/Terminal Group columns and the Consignee/Consignee Group columns will direct you to the options to select in the Allocation/Product/Manage screens.

Deny 09 – Credit Limit Exceeded

This deny is caused by the credit allocation being exhausted.

Note the customer getting the denial and verify the credit allocation by going to Allocations/Credit/Manage.

If you are not certain what credit record to look at, run the Allocation Report with the Terminal/Consignee and look for a record that has Yes in the Credit Checked field. If Yes is selected, then the consignee group to use in the Allocation/Credit/Manage page displays, or in the case of legacy credit, the options to select in the Allocation/Product/Manage page.

Note: Legacy credit users will then be able to find the correct credit record to update in the Allocation/Credit/Manage screen.

Deny 10 – Product Allocation Exhausted

This denial is returned when product allocations are in place and DTN TABS has no products that are approved for lifting. This can be caused by a few different factors.

- Allocations are exhausted. This can be diagnosed by running an Allocations Report using the terminal and consignee receiving the deny in the Transaction Log Pro Report. Look for active product allocation(s) that show 0 (zero) or a negative value. Once these are determined, you can either edit the allocation(s) in question to adjust the records or issue a Global Product Override (GPO) in order to allow lifting to resume.
- In the Admin > TABS Defaults page, you have selected the option to Filter Products Authorized by Terminal Assigned Products:

Verify the products assigned to the terminal to make certain that the family or PIDX product code(s) in the product group(s) you are using for your allocations are associated correctly. This can be done by looking at the Allocation Report, determining the record(s) that are active, verifying the product(s) contained in the groups, and then verifying that product(s) from the applicable allocations exists on the Data Management >Terminals page for the location.

- Your partner, 3rd party or Rack Marketer, is not approving you for the products that you have cleared. Make sure all your allocations are correct and products are assigned to the terminal that apply before reaching out to your partners to verify allocations. DTN TABS Support can assist in determining where the issue lies if you cannot determine where the disconnect lies.

Deny 11 – Pre-Authorization Already Used

An Authorization Request indicates the consignee has used up a one-time, preapproved allocation. The consignee needs to contact the seller in order to update the allocation.

Deny 12 – Invalid Transaction

This denial can be caused by the Terminal Automation System (TAS) sending bad data.

Two main issues within your DTN TABS database commonly cause the resulting denies. Both of these can be diagnosed by running an Allocation Report for the terminal and consignee receiving the error. You will then get one of two responses:

- Sorry there are no allocations that meet your search criteria. The consignee does not have an allocation in place – even an OPEN record. If you add an allocation, even an OPEN record, the deny 12 will be resolved.
- There is (are) x allocation(s) that meet(s) your search criteria. In this case, you are looking for a record that is set to Credit and/or Product where the Apply Credit and Apply Product options are both set to No. This means you have told DTN TABS to look for a Credit or Product allocation but have not told the system which one to look at. TABS then returns a Deny 12 back to the terminal.

Deny 13 – Invalid Transaction Length (S)

Indicates that the transaction was not the correct length to meet DTN TABS standards. This typically occurs when the Terminal Automation System (TAS) programming encounters an error when building the DTN TABS transaction. DTN PetroDex Support will contact the terminal to resolve the programming issue.

Deny 14 – Invalid TCN

Indicates the TCN value stored in your Terminal Setup page for the terminal is incorrect or the terminal is sending an incorrect value. Please reach out to DTN TABS Support for assistance.

Deny 15 – Failed Planned Movement ID Match

Indicates the driver needs to enter DocumentIdentifier to get authorized.

Deny 80 – Retransmission Count Exceeded (S)

Indicates a programming error in the transmission from the Terminal Automation System (TAS). DTN PetroDex Support will contact the terminal to resolve the programming issue.

Deny 81 – Session Error Count Exceeded (S)

Indicates a programming error in the transmission from the Terminal Automation System (TAS). DTN PetroDex Support will contact the terminal to resolve the programming issue.

Deny 98 – System Temporarily Unavailable (S)

Indicates that DTN TABS is down. Contact DTN PetroDex Support for assistance.

Deny 99 – TABS System Error (S)

Contact DTN PetroDex Support for assistance.

Non-PDXR Error Codes

ERR:CONS – Invalid Consignee

Same as a Deny 05 – Invalid Customer ID (R), but is returned for Unauthorized BOLs. Use the same steps shown for the Deny 05 – Invalid Customer ID (R) to resolve the issue.

ERR:CRED – Invalid Credit Allocation

Indicates that the Credit Name or ID was incorrectly entered or that the Credit Name/ID as entered does not exist within your DTN TABS database. Make sure the Credit Name or ID used by the terminal matches that in your DTN TABS system.

ERR:SELL – Invalid Seller ID

Same as the Deny 02 – Invalid Shipper ID (R) but returned for Unauthorized BOLs. Use the same steps shown for the Deny 02 – Invalid Shipper ID (R) to resolve the issue.

ERR:TERM – Invalid Terminal ID

Same as the Deny 04 – Invalid Seller/Terminal (R) but returned for Unauthorized BOLs. Use the same steps shown for the Deny 04 – Invalid Seller/Terminal (R) to resolve the issue.

RNF:BOL – Record Not Found BOL

Indicates that DTN TABS was unable to match a CA or LA transaction with a BB or BL transaction within the Seller’s specified time frame. As such, the CA or LA record was dumped. When the BOL record finally came through, DTN TABS was unable to match it with the corresponding CA or LA transaction because it no longer existed. If you see numerous RNF: BOL error codes on your Transaction Log Report, you may wish to contact DTN TABS Support. We can work with the terminal to determine why the delays are happening.

Miscellaneous Issues

Why is my product allocation not decremented?

This can be due to the PIDX product code on the BOL not being in the Product Group being allocated. Look at the PIDX product code on the BOL, then go to the Product Group the allocation is on to see if the product code in question is in the assigned products column. If it is not, you will need to add it.

If you see the code in the Assigned Product Code column:

1. Someone has already edited the product group to add the code. Check with your team to see if anyone has already done this for you. If not, then you can verify the scenario below or reach out to DTN TABS Support for assistance.
2. The issue may be due to timing. Verify the start date/time for the allocation to make sure it is after the date/time on the BOL. If the BOL has a start date/time or end date/time after the start date/time of the allocation, then look at the Historical Allocation Report to see if the record was actually inserted into DTN TABS or modified in DTN TABS after the receipt of the BOLs.

Note: Changes to start date/times on allocations or creation of a record with a Start Date/Time will not cause TABS to review previously received
BOLs and adjust allocations.

My drivers cannot load but I see the Family or PIDX product code in the Products Authed column.

Here are some of the reasons this could occur:

- If the transaction type is a CA, please count the number of product families being returned. PDXRv1 protocol only allows DTN TABS to return the first 8 shown in the Products Authed column.

If your column reads A B C D E F G H I J, the terminal was not able to see I and J. Look in the Terminal Setup page to make sure that only valid products are assigned to the terminal. Look at the groups used for product allocations to see if there is anything that really is not needed for the customer.

Note: This is an opportunity for you to help the PIDX committee and yourself by asking the terminal partner if they can convert to PDXR 4.01 as it would allow for more granular allocations and more data for your back office.

- If the transaction type is LA, see if the product list has more than 99 codes being returned. If so, check to see if you have any families assigned to the terminal and remove them.

If families aren’t assigned to the Terminal Setup page in DTN TABS, verify the assigned PIDX product codes in order to clean up the list.

Note: There is no valid reason to have over 99 product codes assigned to a terminal.

- Has the terminal recently changed the recipe of the product? Ask them to verify you are configured with access in the TAS to that product.
- Has the terminal recently added the product to the menu of items your drivers can access? If so, the terminal may not have properly cleared the accounts. Ask the operator to verify this.
- Ask the operator to check inventory levels in the TAS including additives. Frequently the issue is an additive being out at the terminal.

I see a BOL with a ZZZ product code and no volume… What does this mean?

This means your driver did not load. This can be caused by several factors:

- Not approved for the product they wanted.
- Pulled into wrong bay.
- Pulled card due to grounding issue.
- Got called by dispatch and were advised not to lift.

Speak to the customer to find out if any of the above happened in order to direct your attention elsewhere.