Introduction for Technical Users      

Goods Receiving processing is split into four areas.

POPIMS provides the means to process goods receipts from suppliers and returns from customers on-line. These can then be processed through to placement in bin locations, or scrapped. (1).

Daily reports of goods receipts are produced along with requested reports of outstanding goods receipts and/or a valuation of goods receipts. (2).

There is a variety of information maintained for the use of goods receiving processing. This includes such items as routing information for goods inwards, parameters for reporting performance against expectations and some part/supplier relationships. (3).

Special part returns processing allows the user to control the authorised return of stock from the customer to the warehouse. (4).

The actual process for goods receipt consists of three stages.

There is a facility which gives the user a means to process goods receipts from suppliers and returns from customers. (1.1).

These details can then be processed through to the placement in bin locations, or scrapping. (1.2).

There is then a facility to record goods receipts from suppliers in a body rather than having to record individual receipts for each part. This facility is available for receipts based on firm supplier orders or based on an interface file from the supplier. (1.3).

PR01 is used to record the initial receipt of goods from a supplier. Details are entered for a specific part and supplier at the sign-on warehouse. If the receipt is against a supplier order known to the system, then the order number should also be specified.

Routing details are taken from either PR50 (for the part), PR51 (for the supplier) or PR62 (for the warehouse).

Once any warning messages have been accepted (e.g. early/late or over/under delivery) a goods receipt number is allocated based on the range on PR63. The goods are then put into the first location on the routing, unless the delivery is early, over, or not against a supplier order. In these cases the goods are placed in 'Referral', from where they can be accepted or rejected.

An enquiry facility enables the user to look at the receipt of goods from a supplier for a specified goods receipt number.

PR02 allows the user to record the return of goods from a customer at the sign-on warehouse. Details are entered for a specific part and customer, if the customer is from a different marketing unit to the sign-on, the marketing unit should also be specified.

Routing details are taken from PR62 for the sign-on warehouse.

If a warehouse and advice note number are specified, the associated invoice will be used to price/discount the credit which will be raised automatically when the goods are finally put into a warehouse location or are scrapped.

Goods receipt/return notes can then be printed along with pre-pack labels. (1.1.1).

Program PR1B, once initiated by either transactions PR01 or PR02, will produce a goods receipt/return note for the specified goods receipt number.

PRF1 will print any goods receipt/return notes for a requested warehouse which were not printed during the on-line session.

Each goods receipt note contains the standard goods receiving, part and supplier order details along with any goods receiving special instructions and inspection details. Order pegging details such as the customer order number and line number (or call-off date and delivery address for a schedule order)are also included if this goods receipt is a pegged receipt. Static picking location and zone are included for the part if this is not a pegged receipt. If the receipt is for requisitioners own use then the requisition number, name, cost centre and project code will be printed.

The goods return note contains the same information but with the customer order details, return code and description for the return. It also includes the DFS supplier number for a DFS goods return. The order pegging and requisition details are not shown on a goods return note.

Program PRF2 prints pre-pack labels for a requested warehouse. These labels can be used to identify receipts which require pre-packing. The number of labels printed for each receipt depends on the part’s smallest unit of issue.

Pre-pack labels are only used for parts received against firm supplier orders using binning list processing.

PR20 is used to confirm movement of goods received from the initial receiving location at the sign-on warehouse for a specified goods receipt number.

Once confirmed the 'From' and 'To' locations will be automatically set-up based on the goods receipt number and the routing displayed on PR01.

When moving a customer return into its final location, if the reason code entered on PR02 has a 'Return to Stock' value of 'No', the 'To' location will be set to 'Scrap', although this can be overridden with an actual warehouse location.

An enquiry facility enables the user to look at any outstanding goods receipts for a part. If the goods receipt number is specified only, that goods receipt is shown along with any other receipts in progress for the same part as for the entered receipt.

There are other transactions designed to progress goods further along the possible goods receiving route, based on the location from which the goods are being moved. Use:

PR21 to move goods from inspection locations PR22 to move goods from transit to pre-pack locations PR23 to move goods from pre-pack locations PR24 to move goods from referral locations PR29 to move stock from any stage to another.

Whenever goods are either moved between two receipt stages within the warehouse or rejected from a goods receipt, the user has the option of printing out a movement label or rejection letter. (1.2.).

When the stock is finally moved into the warehouse, back order release is automatically triggered by the system.

PR1D produces movement labels. Each movement label shows the part, quantity to be moved, to and from locations, inspection details where relevant together with any goods receiving special instructions.

This label can then travel with the goods and identifies the quantity to move and where to move it.

PR1F produces rejection letters. Each rejection letter shows the rejected part, quantity, supplier order details (or customer order details for a goods return), reason code, rejection text and reinstatement message if specified.

This rejection letter can then be used to inform the supplier (or customer in the case of a goods return) which goods the user is rejecting, how many are being rejected and why.

Binning list processing is broken down into two stages.

Firstly the binning lists are created based on the extracted firm supplier order details, from inventory management, and any details passed through a supplier interface. These details are then printed. (1.3.1).

Once the goods have been received at the warehouse the details can be altered if necessary. When details are complete and the binning list can be confirmed (1.3.2).

PRB1 is used to determine the locations to be used for stock being received via a binning list.

If the details used are from the supplier interface and use unknown part numbers, then a report is produced showing the use of a substitution code, or the failure to identify the part. The substitution would be based on the input part code being identified as a supplier synonym.

PRB2 creates the goods receipt details for the binning list with each list comprising a maximum of 12 lines and is automatically given a number based on the ranges in PR63.

For each line on the binning list a goods receipt is created with the next available number, for the outstanding quantity on the supplier order call-off or for the quantity on the supplier’s interface file. The corresponding supplier order is updated with the receipt details. A report is produced showing warnings for early/late, over/under supply or outstanding backorders and the next location on the routing for each part.

If any lines are generated on the binning lists for parts that have no supplier price or have a zero price, they are reported on the Unpriced or Zero Priced Parts Received on a Binning List report.

PRB3 prints the binning list details. It produces a report page for each binning list with up to 12 lines on each binning list.

PRB4 produces a report of anomalies in control numbers supplied via the supplier interface file. It details control numbers which have been specified for parts that are not controlled or where the wrong number of control numbers have been specified for parts which are controlled.

PR70 is used to review binning list details prior to confirmation. When the goods for a binning list are actually received at the warehouse, the user may change some of the details generated on a binning list by using this transaction with a specified list number for the signed-on warehouse.

If the binned quantity is altered, an extra goods receipt is generated for the difference in quantity, so that the total is still available.

PR71 is used to complete a binning list, once any changes have been made, for a specified list number for the sign-on warehouse.

PRC1 processes the completed binning lists. It moves the lines on the list from the initial receipt location to the one shown on the binning list (or the one the user changed it to when using transaction PR70).

PRD1 produces the goods receiving extract for all receipts/returns and rejections processed that day (either on-line or through all binning lists).

PRD2 produces a report from the extracted details in goods receipt number sequence.

PRD4 produces a report from the same extracted details but analysed for each buyer.

Each report breaks down receipts into categories. The are classified by when they were delivered (early/late/on time using tolerances on PR63) and how much was delivered (over supply/under supply/correct amount).

PRD3 produces a list of outstanding goods receipts based on a parameter specifying the number of days, held on transaction PR63.

PRE1 produces a receipts in progress valuation report by location type and then totalled for each warehouse.

PR50 is used to maintain goods receipt details for a part at a warehouse. The routing codes must be pre-defined using transaction PR61.

PR51 is used to maintain routing information to be used for receipts from a specific supplier. The routing codes must be pre-defined using transaction PR61.

Inspection codes, rejection codes and receipt routing codes are each maintained by language code. If a language code, other than the base one, has been entered when adding details and the description does not already exist in the base language, the entered description is recorded against the base language as well as the selected one. (3.1).

All goods receipts are costed automatically. However, the user can modify the cost of details held against a particular receipt of a specified part when signed-on to the required warehouse using transaction PR15.

PR60 maintains inspection codes and associated text by language code. The instructions are shown on Goods Receipt and movement labels for parts that use that inspection number.

PM40 maintains the link between a part and an inspection code.

PR64 maintains rejection codes and their descriptions. These codes are used for the explanation of a rejected goods receipt or returns (PR20).

PR61 maintains receipt routing codes and their descriptions by language code.

An enquiry facility enables the user to look at the existing inspection codes, rejection codes and routing codes and their descriptions respectively. The base language description will be displayed against any code which does not have a description set-up in the selected language.

PR63 maintains the goods receiving parameters.

PR62 maintains the default receipt routings for the signed-on warehouse. These must be pre-defined using transaction PR61.

Special part return (SPR) processing can be split into four areas.

Entry of agreed SPR quantities, prices and financial terms - similar to on-line customer order entry. (4.1).

Authorisation of SPRs including expiry date entry and optional production of tickets to send to the customer as a turnaround document. A SPR report and interface file can also be produced, optionally, to send to the customer. (4.2).

Once SPRs have been agreed between the customer and marketing unit, the goods can then be returned to the warehouse (4.3).

On-line SPR enquiries and reports to help the user process outstanding special part returns (4.4)

PR30 enables the user to enter a new special part return for a specified customer. The SPR number is generated from transaction PR63 and holds the status of ‘Created’.

PR31 is used to enter the financial terms agreed by the customer and customer’s marketing unit for the specified SPR. These details are initially copied from the customer’s standard terms (as set up using transactions PC20 and PC21). Once vetted they are used to price the SPR lines, however, if they have been altered POPIMS automatically reprices any non-fixed price lines on the SPR using the new terms.

PR32 allows the user to enter the details of the stock to be returned on a specified SPR number. Up to six part lines can be entered at a time, along with both the requested and authorised quantities and a reason code, if not entered on transaction PR30.

There is also the facility to change the POPIMS calculated price and/or discount on an SPR line for a specified SPR number, part number and reason code.

The reason codes entered must exist on transaction PM77 and for ‘Part Only’ as exchange units are not allowed.

PRG1 is used to produce special part returns automatically, based on details in an interface file sent by the customer. The customer interface file contains sufficient information to set up SPRs in the same way that a dealer enters SPRs using the DCS screens PD50 and PD51.

A customer SPR creation interface exception report is also produced which highlights any errors in the interface file information. If there is an error in the SPR header information, then all of its SPR detail lines are rejected as well.

PR33 enables the user to authorise the SPR. At the same time, it is possible to request creation of an interface file to send to the customer containing the agreed SPR. A print of SPR tickets can be requested and also a report of the SPR.

The transaction can also be used to cancel an SPR where agreement cannot be reached between the customer and the marketing unit.

PRG2 extract details from the SPR file to produce the customer interface. This can be requested at authorisation in PR33 or at any other time using PR30 PRG2 also extracts file which are passed to the SPR reporting programs.

PRG4 prints SPR return tickets. These are sent to the customer for returning with the goods in order to identify the SPR on which the return was agreed.

PRG3 prints a report of SPR details. It includes details for all SPRs requested in PR33 at authorisation. The report can also be requested in PR30 at any other time.

Once an SPR has been authorised by the customers marketing unit, control of the SPR passes to the warehouse to which the goods are due for return. The warehouse staff may first need to know exactly what is due for return.

PR37 can be used to request a complete list of everything outstanding on the SPR. This triggers PR3A which prints outstanding details only for the SPR.

SPR return can be performed in one of two manners. The size of the SPR and percentage to be returned will largely determine the method used each time.

PR35 is used to record receipts of single SPR lines.

PR36 is used to record exceptions for SPRs which are due for return in their entirety. Any lines for which no exception is recorded will be assumed to have been fully returned. Once all exceptions have been recorded in PR36, transaction PR37 is used to complete return processing for the entire SPR.

Both PR35 and PR37 trigger background task PR3B which creates a goods return note for each SPR line. These are progressed through the system in the same manner as normal customer returns but are credited using the prices agreed on the SPR.

Program PR34 displays details of all outstanding SPR lines for a particular part/warehouse combination. This is particularly useful when a part has become difficult to obtain from suppliers but a customer is holding unwanted stock in a state apparently suitable for reuse.

Program PR38 displays details of all SPRs on the system. The display can be limited by status and optionally customer as well.

Back

Home