If the receiving physical warehouse does not service the customer’s default logical warehouse the stock is credited to the first logical warehouse serviced by that physical warehouse. Upon authorisation of the Returns Authorisation (RA) the fact that the return is actually against the original business unit is recorded even though stock resides elsewhere and is owned by another business unit. This is achieved by the necessary transactions automatically being created and then picked up by the GL Interface.
Each RA quotes both the logical and physical warehouse. So if goods can be returned to a physical warehouse that would otherwise not service that logical warehouse, that relationship must be defined to allow the initial return.
Once stock is put away it is available for picking. The putaway function is independent of a claim completing to a credit. Reserved putaway is used to differentiate between the physical stock on hand and the accounting stock on hand (or stock on hand available).
Stock can be updated to inventory as it is scanned so that it can be available for immediate sale. This is achieved by adjusting the returned stock up temporarily and then once the credit is processed the system reverses this adjustment and updates stock with the credit. This way credits maintain a cost of goods returned ensuring the ability to track customer cost and profitability. The adjustment will have a cost as calculated at that time and a reason code which represents “pre-credit adjustment”. The stock will only be adjusted for returned saleable stock, this will be identified by the reason code. As returns can be maintained and quantities can be amended it will only allow for quantities to be reduced if stock is still in the scanned container/location. Control file TMSDS/RCT-ADJ has the default value for a returns adjustment transaction that makes returned stock available for immediate sale. Reason codes established in control file TMSAR/CL-REAS is flagged to initiate immediate update of stock on returns.
In assessing a customer’s returns % for pending return requests, the calculation is based on the following.
- Credits for the last 12 months
- Credits this month
- All authorised returns (status OW)
- All returns processed in the warehouse but not yet credited (status O and receipt quantity is not zero)
Divided by:
- Gross sales for the last 12 completed months, plus
- Gross sales this month, plus
- Orders in statuses P, K, D and I
Inclusion of the above new attributes in the calculation is determined by the setup in control file TMSAR/CL-RTNTH. This control file gives the option to include (1=Yes, 2=No) the calculation attributes when determining the returns threshold value for pending requests. They are setup by returns group policy code.
Goods can be registered in and assigned to a pallet. Once registered, administration can view and access the information entered helping to identify outstanding returns for credit checking.
Goods received can be matched against pre-authorised claims or an unexpected return can be created. Pre-authorised returns can be loaded into the receiving panel to minimise re-keying. Received goods can be kept open until the warehouse have completed the scanning or enty for each return received.
If Accounts Receivable daily transactions exist for the claim it will adjust balance and allocations. If the transaction does not exist it will write a new AR transaction.
Default instructions and locations are derived from a combination of classification and pre-authorised returns reason codes. For example Z – to be assigned and X – clearing. There are two methods of putting away stock.
- All stock received to be resold defaults to a clearing location for putaway, allowing received stock to be recorded into the system so goods can be put away at a more convenient time.
- Stock may also be put directly into pickable locations bypassing the putaway.
Invalid returns can be recorded and then sent back to the customer. This stock is put into a special location for returning to the customer. An invoice is generated to instruct picking and to accompany the goods for return. A freight charge may be added to this invoice at pick confirmation or may be generated through the existing freight charging facility.
The putaway process suggests a location for stock and requires confirmation of the stock being putaway. If no location exists for this item a “to be assigned” location is used, the stock in this location type is not pickable.
A Firm sale definition table determines the firm sale rules for sales and returns. For example certain special offers may be returned for firm sales.
Claims cannot be released until the warehouse has completed receiving.The Item Code Substitution program converts an alternative item, barcode or TUN into an Iptor IP1 item code. Entry of multiple TUN codes against an item is allowed, whereby the TUN in the Product Shipper file is accessed to retrieve the Iptor IP1 item.
The transaction can be updated with the following date and time stamp using data types.
- REG = Return In Warehouse (Header)
- RET = Return In Warehouse (Detail)
This program provides facility to return systems and explodes the system into components. This requires the container and location update process to reverse any stock put into the location file for the system. This facility only explodes the first system and does not handles system as a component.
This process is subject to User Access Restrictions.
It is possible to override pre-approved claim line reasons for certain receipt rules.
When a claim is allocated to an invoice that was closed (paid), the system will issue a warning that it will reopen the invoice group in Accounts Receivable. If the user confirms reopening the invoice group, then it will allocate the claim against the invoice.
Non-stockable items are ignored when calculating total expected return quantity as there will be no physical returns.
Contents
Return of firm sales
Certain special offers are allowed for sale or return on firm sales items. In Database Management the rules are established: effective time period, customer details, item details (including hierarchy and classification(s)) and certain order details are created to determine the firm sale flag. Order entry accesses this table to determine the firm sale flag for each order. The rules for backorder release must also be determined.
Firm sale is an item hierarchy driven table in control file TMSDS/RTC-FSR. The presence of any records in this control file activates the check for firm sale invoices.
Group RA to do RA for individual stores
Group RA should be used to define the RA for individual stores. When a RA number is entered for a billing account number the system finds the original group RA and copies the details for pricing and validation. Control file TMSDS/GRPRA-BN holds the billing accounts for which a group RA should be created.
Reopening an already completed RA
The Returns Registration and Loading program has a facility enabling an already completed RA (credited) to be reopened, allowing returns against that number. This creates a new number and a separate credit and checks returns against the original RA.
Reserved putaway
System has been changed to allow facility to release stock that had been reserved for put away when a container is closed rather than when it is put away to final location, thus increasing available stock. This is controlled by control file TMSWH/PTWY-RSV.
The following examples describes reserved putaway.
DSWH00P – Warehouse File
WHLOD00P – Location Item File
| Stock of 20 is returned | Then item is approved | Then container is putaway into a location |
|
DSWH00P: SOHQ = 0 and reserved putaway = 0 therefore SOHA = 0 (SOHQ – rsvd putwy) WHLOD00P SOHQ = 20 in the returns container. |
DSWH00P: SOHQ = 20 and reserved putaway = 20 therefore SOHA = 0 (stock has not been putaway). WHLOD00P: SOHQ = 20 in the returns container. |
DSWH00P: SOHQ = 20 and reserved putaway = 0 therefore SOHA = 20 (SOHQ – rsvd ptwy) WHLOD00P: SOHQ = 20 in the location. |
| Stock of 20 is returned |
Then container is putaway into a location |
Then item is approved |
|
DSWH00P: SOHQ = 0 and reserved putaway = 0 therefore SOHA = 0 (SOHQ – rsvd ptwy) WHLOD00P SOHQ = 20 in the returns container. |
Then container is putaway into a location DSWH00P: SOHQ = 0 and reserved putaway = 20 therefore SOHA = 0 (negative rsvd ptwy is ignored). WHLOD00P: SOHQ = 20 in the location. |
Then Item is approved DSWH00P: SOHQ = 20 and reserved putaway = 0 therefore SOHA = 20 WHLOD00P: SOHQ = 20 in the location.
|
Allocation sequence
The invoice allocation sequence for claims is based on TMSAR/SEQ-ALLC. The system defined specific search codes ‘C’,’B’,’L’ and ‘D’ in the control file indicates search by customer, billing group accounts, linked customer accounts and distribution centre accounts. If this control file is not defined then the fixed invoice allocation sequence that was used prior to this change will be used i.e. by customer, by distribution centre, by billing group account and by linked accounts.
This process determines if the Returns Receiving sub file should show the scanned quantity for items to be returned to customer (instead of showing a blank quantity).
| Note | The RTC quantity entered/scanned still does not affect the total received quantity and does not get written to the warehouse receipts file. The RTC quantity will still appear on the generated RTC transaction related to the claim/return. |
Overriding actions based on individual return line criteria
The labour time required to put away some stock may exceed the value of that stock. At the time of processing a return line (item and quantity), the system uses the combination of return action codes and stock quality to determine the destination of the stock. Additionally the system assesses the value of that stock and alters an instruction if required. TMSDS/RCT-ACTL includes the selection of Hierarchy level 1 and 2 with the Item action code to determine the line cost to waste.
Allocating a claim to an invoice that is closed
When a claim is allocated to an invoice that was closed (paid), the system will issue a warning that it will reopen the invoice group in Accounts Receivable. If the user confirms reopening the invoice group, then it will allocate the claim against the invoice.
Process flow
The following two scenarios are used when processing returns.
Raising a claim prior to receipts of goods
- Claims are created in the Claims Module using Claim entry/maintenance. (Status O1)
- Once the claim is released it goes through Pending (Claims Module).(Status O6)
- This appears in the Accounts Receivable module as a claim, either allocated to an invoice or unallocated.
- When approved from Pending system, a returns authorisation notification is printed and sent to the customer. (Status OW)
- The customer sends the goods back with the returns authorisation notification. This notification quotes the returns number for use by the warehouse when processing the returns into stock. (Status OW)
- If using RF scanning, a container must be opened before the goods can be returned. If the warehouse does not use RF this step is bypassed.
- The warehouse proceeds to record received stock in the Returns Receiving menu option and the credit note generates. (Status C)
Receipts of goods prior to raising a claim
- Stock is received into the warehouse without the returns authorisation notice. The warehouse is allowed to proceed with the return of the goods.
- The warehouse staff enters the items returned against the customer. (Status OW)
- This appears in the Accounts Receivable module as a claim either allocated to an invoice or unallocated.
- If the warehouse does not complete the entry of goods received, returns stay in the warehouse awaiting completion. (Status OW)
- If the warehouse completes the receiving, returns go to pending within the Claims Module. (Status O6)
- The returned quantity of the claim from the warehouse is accepted in the Claims module using Claim entry/maintenance. If changes are made, the claim goes through Pending again. (Status O6)
- A credit note is generated once approved from Pending. (Status C)
- Note: If the customer entered is a consignment customer as defined on TMSAR/CL-CONS, the claim is rejected. Returns for consignment customers are recorded using DSE185 Consignment Returns Registration.
