Pending reason codes

TMSDS/PEND-DSC has a “Check if No Delivery” flag, by pending reason code. Each reason code must be flagged to determine whether the order still pends if it has been processed and no stock is to be delivered. If this flag is set to Y the order pends. Regardless of this flag, the order always pend when stock is being released.

If “Check if No Delivery” flag is ‘N’ and the pending reason code is a header code (eg AC=Credit Limit) and the total delivery quantity for the order is zero, the order does not pend.

If the “Check if No Delivery” flag is ‘N’ and the pending reason code is a detail code (e.g. BP=Price override) and the delivery quantity for this line is zero, the order does not pend.

If the “Check if No Delivery” flag is ‘N’ and the pending reason code is a detail code (e.g. BP=Price override) and the item on this line is a non-stock item, the order does not pend.

TMSDS/PEND-DSC has an “Allow Approval” flag by pending reason code. If the “Allow Approval” flag is ‘Y’, then the order can be approved without any further maintenance.

The parameters for not pending based on the Type of Order/Claim are set in TMSDS/PEND-EXO. Type of Order is classified by the use of the following. 

• Document Type (DT) with valid codes in TMSDS/TR-DT.
• Document Sub-type (DST) with valid codes in TMSDS/TR-DST.
• Picking method (PCKM) with valid codes in TMSDS/TR-PCKM.
• Warehouse (W/H) with valid logical warehouse codes.
•  Source of Transaction (SRCT) with valid codes in TMSDS/TR-SRCT.
• Type of Sale (TOS) with valid codes in TMSDS/TR-TOS.
• Payment Terms Code (PYTC) with valid codes in TMSDS/CM-PAYT.
• In PEND-EXO, the pending reason code is listed and for each of these reason codes, the types of order/claim codes that are not to pend for that reason, are listed.

A definition can be set up in Pending masterfiles and TMSDS/PEND-DIL to create a definition of small orders that should or should not pend. This definition is then applied to all order lines if the pending code and the department match the control file. This is used for a pending code at order header level. For a pending code at line detail level, the existing department definition applies. See Pending Small Orders by Buying Group under User defined sales order pending reasons for setup requirements.

If a customer order value exceeds the available credit for that customer, the order is pended.  Different levels of credit limits can be defined (for example 90+%, 95+%, 100+%) requiring approval by different departments.  If this facility is activated a customer’s credit limit is checked for each order and if the order value exceeds a given credit limit % it is pended for approval.  A specific credit limit % can be nominated which causes the order entry program to give a warning only but does not pend the order. 

The parameters are set in TMSDS/PEND-CON. 

Pending considerations to include in reducing an account balance, affect how the system determines whether the credit limit has been exceeded or the balance is overdue.  The user can decide whether Outstanding Claims (claims raised not necessarily approved), Drafts and/or Letters of Credit should reduce the account balance when comparing it to the credit limit on the Customer masterfile. 

Conditions:

• is the billing number valid on the Customer masterfile and
• is the document an invoice (Document Type A)
• the outstanding balance is greater than the credit limit of the billing account. 

TMSDS/DSO040 determines whether to add order or invoice amounts to the total when running a pending check.

Checks for potential errors in the shipping address. An order will pend if any address line is matched to a defined list of words. Multiple rules against each address line can be defined with an option to match to a string for Equal, Not Equal, Like and Not Like. TMSDS/PEND-DAD defines the parameters for delivery address line checking. 

If the Sales Order Header screen fields for Payment terms code and/or Actual due date are changed by the operator when entering an order, the order pends. 

Conditions:

• Customer must be valid (may be a transfer or adjustment that do not require a customer)
• Document must be an invoice (Document type = A)
• Payment terms code on the order must differ from the payment terms code on the Customer masterfile or the payment terms on the order is blank.

Checks for possible fraudulent customers based on the entered name and address, using the Customer Validation Address file (DSCVA00P).

If the value of the order or invoice does not match the value of the cash received, as entered by the sales operator, the order pends  The authorised department can then maintain the order if applicable or leave the difference on the account or write off the difference. This type of order is identified by customer. 

Conditions:

• customer to be valid (may be a transfer or adjustment that do not require a customer)
• document to be an invoice (Document type = A)
• Source of Order to be Cash Sale/Payment with order
• Payment is not to be by credit card
• Payment must not equal Order Total.

AH – Credit Card Failed

If the credit card information is invalid or the difference between the authorised payment amount and order amount exceeds pre-set limit the order will pend with pending code ‘AH – Credit Card Failed’

Credit cards can be pre authorised on pending or pick release depending on the setup in TMSDS/OM-PAUTH.

In Order Processing, the promotion package identification is entered on the first screen along with the customer account number.

The “Check if no delivery” flag on the control file TMSDS/PEND-DSC should be ‘Y’, as pending is to verify whether this order satisfy minimum requirement of the promotion package.  Note that this reason is for both header and detail and validates the promotion package as per DSE230, if the package is active.  Reasons for pending could be:

• Mandatory item not ordered
• Minimum number of items not reached
• Minimum number of units not reached
• Minimum quantity per item not reached.

Above reasons for pending is only applicable for non manual orders.  Manually entered orders have to meet the minimum requirements of the promotion package before the order can be confirmed.  The order pending check program checks if an allowance code is entered on an order line and pends this order line for approval.

Pend reason department needs to be set up in order to use this facility (both header and detail).

An order can be processed for the next month by changing the date at Order entry time.  The order can be packed and delivered during the current month but the invoice is produced in the next month and the sale reflects in the next month. 

Condition is if the transaction period of the order header is greater than the period in TMSDS/PERIOD.

TMSDS/PEND-ODD specifies the payment terms to be used (TMSDS/CM-PAYT), overdue period, overdue percentage and number of days grace before an order pends. The total dollar amount in the overdue buckets (which are the periods equal to and in excess of the overdue period) is compared, as a percentage, to the total amount outstanding.  If this percentage exceeds the percentage defined in this control file, the order pends. The number of days grace are also taken into account when determining if an amount has become overdue.

An entry of 100% indicates no tolerance.

In TMSDS/PEND-ODD a blank payment terms code will bypass or overrule the specific payment terms code requirements.

Conditions:

• the customer must be valid (may be a transfer or adjustment that do not require a customer)
• the document must be an invoice (Document type = A)
• if the outstanding balance is greater than zero (0) calculated as follows – if overdue balance divided by the outstanding balance is greater than TMSDS/PEND-ODD.

Orders pend for a user who has been listed in TMSDS/PEND-EUL.

Conditions:

• orders pend if the customer is a duty free customer (C1DFCF = ‘Y’)
• customer must be valid (may be a transfer or adjustment that do not require a customer).
• warehouse type is free or not valid – uses transaction warehouse and branch to check the Warehouse masterfile for the warehouse type.

On TMSDS/PEND-VAL a minimum value, in whole dollars, by company can be established and any orders below this minimum value pend. 

Conditions:

• customer must be valid (may be a transfer or adjustment that do not require a customer)
• the document must be an invoice (Document type = A)
• if the total delivery quantity on order is not greater than or less than zero (0), the order pends
• if the total base invoice value + total base tax is less than the value in TMSDS/PEND-VAL, the order pends.

Orders pend if the warehouse in order processing is not the same as the warehouse on the Customer masterfile.

Conditions:

• the customer must be valid (may be a transfer or adjustment that do not require a customer).

Orders pend if the customer account has a status of stopped or suspended. 

Conditions:

• the customer must be valid
• the billing or customer account must have a status of ‘S’ or ‘C’.

The system first checks that the customer is valid, (or the transaction is a transfer or adjustment that does not require a customer) and that the document is an Invoice. 

Then the invoice/order must be prepaid by credit card.  If all these conditions are met, the system checks TMSDS/PEND-FLL for the credit card payment type and ensures the invoice/order total including tax is greater than the floor limit.

The parameters for Purchase applicability are set in TMSDS/PEND-APL.  This is only used if the Customer and/or Item masterfile applicability facility is not in use. Customers can be excluded from buying specific products.  If a customer has placed an order for a product that is not available to them, the order pends to check on whether the customer actually ordered this product or whether it was a keying error. Reason codes can be flagged to be applicable only if stock is allocated.

Conditions:

• the item cannot be a component of a pack (C) or a system (D)
• the item must be a stock item which means the Stock flag (I1STKF) must be Yes.
• the customer must be valid (may be a transfer or adjustment that does not require a customer, these check the Customer Sales applicability file).

BB – Potential Lost Order

This pending reason captures any orders with lines that are not being supplied or backordered. This will allow for maintenance of the order or customer contact prior to losing that order.

This function can only know of order lines that stock availability and supply rules have determined will be lost at the pending stage, and cannot account for orders that were to be supplied, but were lost due to short picking in the warehouse stages.

BC – Zero Cost

The customers order will pend if any of the line items have a zero cost in the transaction.  This uses the Distribution transaction file. (DSTRB00P)

If the default discount is overridden when the sales order is entered, the order pends.

This applies if the discount per line item and/or the Sales Order header panel Discount Override are changed.

Conditions:

• the item must not be a component of a pack or a system.
• the item must be a stock item (Stock flag (I1STKF) = Yes).
• actual discount is greater/less than the normal discount.

The order will not pend if the percentage range is within the specified limits setup in TMSDS/PEND-PRC.  This control file determines for pending code D and P and the Item level 1 (I1CLS), the range of percentage and whether to check all the prices, or below the percentage or above the percentage.

BE – Titles Sold below ‘List Price less Max Discount’

This pending check will check that products belonging to a specified Item Classification are not being sold lower than list price (entered or overridden) with a set maximum discount.

TMSDS/PEND-DIC specifies the Item class code to check for with the ‘BE’ pend code.

Items can be flagged as being available for sale to a specific customer or group of customers.  If an order goes through for an item, which is not supposed to be sold to that customer, the order pends for management approval or rejection.  Item Applicability can either be picked up in Pending using TMSDS/PEND-APL or setup for each item in the Item masterfile. 

Conditions:

• the item should not be a component of a pack or a system
• the item should be a STOCK item (Stock flag (I1STKF) Yes)
• the Item Applicability file (DSIMC00P) is checked.

Conditions:

• if the item is a stock item (stock flag (I1STKF) Yes)
• if the unit allowance amount is not zero, then pend.

The parameters are set in control file TMSDS/OE-STKA.

To calculate stock availability including Forward Orders (FO) and Purchase Orders (PO), the flag on the control file must equal 1 for ’Yes’. The number of months into the future to take FO and PO quantities into consideration is another parameter on the control file.  If the delivery quantity (calculated) is less than the order quantity then the order pends.

Pend forward orders if there is a PO available to fulfil the order.

In Order Processing, the promotion package Identification is entered on the first screen along with the customer account number.

The “Check if no delivery” flag on the Control File should be ‘Y’, as pending is to verify whether this order satisfy minimum requirement of the promotion package. Note that this reason is for both header and detail and validates the Promotion Package as per DSE230 if the package is active. Reasons for pending could be:

• Mandatory Item not ordered
• Minimum number of Items not reached
• Minimum number of Units not reached
• Minimum quantity per Item not reached

The order pending check program checks if an allowance code is entered on an order line and pends this order line for approval.

Pend reason department needs to be set up in order to use this facility (both header and detail).

A Minimum Margin can be set per Company and/or Warehouse on TMSDS/PEND-MGN.  For each company and optionally warehouse, specify the minimum profit margin required.  Any order with a line below this margin pends.  This margin overrides the margin specified on the Price Simulation module. The Pending program checks the warehouse code on the customer order.  If this warehouse has been defined as a minimum margin warehouse, its margin is part of the pending check.  If the warehouse has not been defined on the control file, the minimum margin on the Price Simulation Module is used during the pending check.

Conditions:

• item must be a STOCK item (stock flag (I1STKF) equal to Y)
• customer must be valid (may be a transfer or adjustment that do not require a customer)
• document must be an invoice (Document type = A)
• item must not be a component of a pack or a system
• if the total base invoice less the total cost divided by the total base invoice is less than the minimum margin on TMSDS/PEND-MGN, the order pends
• the total trade invoice must be greater/less than zero (0)

This Reason could be used as a safeguard against incorrect pricing being used.  The Database setup has an effect on this pending check.

TMSDS/SEQ-MMR is used by the Pending and PSM systems. This holds the sequence in which a minimum margin percentage is retrieved. If no matching minimum margin percentage is found using this file’s sequence, then the value is taken from TMSDS/PEND-MGN.

The Type of sale flag is used in the calculation to ignore or include when looking up minimum margin rules.

Establish TMSDS/PEND-PRZ – Level of Price Error, to determine the level of price error.

The order will check for the following.

• 0 = no check
• 1 = no price defined
• 2 = zero price.

Prices default according to the Price code on the Customer masterfile. If a price on any detail line is changed the order pends at order entry time.

Conditions:

• item must not be a component of a pack or a system
• item must not be a STOCK item (stock flag (I1STKF) equal to Y)
• actual unit price is not the same as the normal unit price

The order will not pend if the percentage range is within the specified limits setup in TMSDS/PEND-PRC.  This control file determines for pending code D and P and the Item level 1 (I1CLS), the range of percentage and whether to check all the prices, or below the percentage or above the percentage.

A predefined limit is established on TMSDS/PEND-QCC for each CC-Type and IC-Type combination, with a flag to indicate whether to check against the Ordered quantity or the Delivered quantity.  This is used to catch orders where the quantity entered is out of range, which means there was probably a keying error.

If the quantity type = 2 for delivery quantity, and the delivery quantity is greater than or equal to the quantity limit established in the control file, pend the order.

Delivery quantity is greater or equal to quantity limits.

If the Quantity type is = 1 for order quantity and the order quantity is greater than or equal to the quantity limit established on the control file, pend the order.

Pend code BQ is also used to check quantity limits by item hierarchy “Item hierarchy quantity limit exceeded”.  Orders will pend if line item is within defined hierarchy in TMSDS/PEND-QIL and quantity exceeds the limit.

Orders pend if the item is an Assortment as setup on TMSDS/IM-ASSI.

Orders pend if the Item has a status of Stopped or Suspended.

Conditions:

• The item must be valid
• The Item must have a status of ‘S’ or ‘C’. 

Conditions are if

TMSDS/PEND-ODD =< (A3PERD-A3AGEP)

        OVERDUE BAL = A3BAL (O/S BAL)

                                    + A3CLMA (CLAIMS) – if flagged on TMSDS/PEND-CON

                                     – A3DRTA (DRAFTS)   “                    “”           “           “

                                     -A3LCDA (L/C’s)           “       “         “             “

accumulated across all ARAGE00P records where

TABN = A3BN

And A3PERD = TMSAR/PERIOD

OR

If the balance for a month is negative, include in Overdue balance

E.g. Current $100

       Curr-1   $500-

       Curr-2   $500

TMSDS/PEND-ODD = 2

Therefore, we would normally only include Curr-2 as overdue.  But because Curr-1 is a negative figure, it is added in as well, so the total overdue is zero. 

If all orders for a customer are to be reviewed and manually released, a user defined pending reason can be established to ensure all these orders are not immediately released.

Current Outstanding balance = ARAGE00P/A3BAL where TABN = A3BN

                                                                                        TMSAR/PERIOD = A3PERD

                    (CLAIMS)                    + A3CLMA – DEPENDING ON TMSDS/PEND-CON

                    (DRAFTS)                   – A3DRTA      “                      “              “

                    (L/C’s)                         – A3LCDA       “                       “              “

ARDM00P   (IN-UPDATE)              +D1UPDB

                    (NEXT MONTH)          +D1NXTB 

If a Debtors transaction (ARTRA00P) record is found by Distribution TBRPN

or

An existing order in pending (DSTRJ00P) record by Distribution TBPN.

Checks payment type (T6PAYT) against TMSAR/BK-PAYT.

Catering for small order by buying groups. In the Pending masterfiles, set up the following.

• Add a new department for small orders
• In the definition option, enter the range ‘from’ and ‘to’ for the Item Levels, Item Classification, Company, Branch, Customer Classification, type of sale and source of transaction.
• In the reason option enter the codes, for orders to pend.
• In the User option enter the users who will approve these orders.

TMSDS/PEND-DIL holds the department and pending reasons. For the Department enter the hierarchy levels to be used, these should match the item levels defined in the Pending masterfiles.

This definition can then be applied to all order lines rather than just one line if the pending code and the department match with this control file. This is only for a pending code at order header level. For a pending code at line detail level, the existing department definition will apply.