Regarding Goods Reversal & Goods Issue Process for PO

Question

Hi Experts,
           Could you any one tel me what is Goods Reversal and Goods Issue process for PO...
How to create the FM & detailed Procedure Pls?....
Please any one tel me.......
Thanks & Reagards
HB

Answer 1

Hi Hans,
SOURCE : HELP.SAP
Purpose
Inventory Management uses this process in such a way that the goods issue posting is divided into two parts that run in separate systems. Posting the GI document in the supplying plant results in a message to the receiving plant. The receiving plant then performs a complementary posting. The physical goods receipt takes place as usual.
Prerequisites
When using batch processing, the following prerequisites must be fulfilled:
Both the original and target systems have the same batch definition level.
The batch definition level is either the material or the client.
An ALE scenario exists for materials and classes (characteristics).
Unique batch numbers exist cross-system.
Batches can only be changed in their original system when they are not decoupled. From an organizational point of view, this must also lead to the batch status being changeable in a local SAP R/3 system. For example, this is impossible when transfer posting to a new batch and results in further actions, for example, relabeling containers, palettes and so on.
Characteristics
As for the purchase order in a one-system situation, the system should automatically post the material into the stock in transit at the receiving profit center and the corresponding Profit Center Accounting using intra-CC transfer prices at goods issue for the purchase order and the unchecked delivery. This requirement is valid for one-system situations as well as for two-system situations where there is an ALE interface. No internal billing document should be created.
In a two-system case, the receiving profit center should be derived at goods issue from the unchecked delivery. Profit Center Accounting then takes place with
Stock change transfer price to stock
Internal expense to internal sales
Internal clearing account to stock change transfer price.
Account determination in a purchase order for an intra-company-code transaction must be different from account determination in external transactions. Automatic GR/IR account clearing is required in both one-system and two-system situations.
The stock in transit must be visible in the receiving profit center.
The system must send a shipping notification at goods issue in one-system and two-system situations.
You need to create an invoice document for the internal and external trading statistics for cross-boundary deliveries as well as for customs purposes.
GR/GI slips are created.
Process Flow
Goods Issue Posting for Stock Transfers
The delivery triggers the goods issue in the issuing system.
The call contains the stock transport order data known in the delivery, including the PO item and the logical system of the recipient.
The transaction (quantity and value updates) is selected using the movement type:
Movement Type     
Function
641     
Goods issue with UB logic (Creation of stock in transit at recipient, immediate value posting).
647     
As 641, however the goods receipt line (movement type 101) is added automatically, so that the goods receipt is posted at the same time as the goods issue (one-step procedure).
You determine the movement type according to the schedule line category in Sales and Distribution. The goods issue for a cross-system stock transfer must be different from the integrated transaction. This is achieved by adding a new movement type.
You post quantities and values at goods issue in the same way as a goods issue for a sales order. That is to say, the quantity is posted in the supplying plant and the value is adjusted to that of the stock account. The offsetting posting is made to a clearing account. The known data from the delivery is copied to Accounting to balance the account where necessary.
The system creates a message to the appropriate receiving system for all items with reference to a cross-system purchase order. The system does not perform any validity checks on the recipient’s data before posting begins. Incorrect Customizing results in the update being terminated.
If a goods issue has receiving plants in different logical systems, an IDoc is sent for each system.
In order that the goods receipt is able to use the values on the receiver side, you must add the values used to post the goods movement, in particular the transfer prices, to the IDoc.
The logic for recognizing the profit center switch functions as follows: At goods issue, the system recognizes that the profit center of the issuing plant is different from the profit center of the receiving plant. The system derives the profit center node from the relevant profit center.
Data Transfer
The IDocs sent by the issuing plant trigger the goods issue postings in the receiving plant.
Background Posting in the Receiving System
The goods receipt is posted in the receiving system using the IDoc. The interface receives the data from the goods issue in the supplying plant. The following processes now run at the recipient:
The system finds the update control for the GR part of the posting.
The goods movement is posted with the new movement type.
During valuation of the goods receipt, the system might, where necessary (UB logic), refer to the values (legal value and the value from the parallel valuation type, if you are using the transfer price function) from the IDoc.
The PO history is updated. The PO history is updated with the material document number from the second part of the GI posting. The GI document number is not stored in the supplying plant, because there is no way to display this document.
In two-step procedures the goods receipt is posted to the stock in transit.
Reversal
You can only reverse this goods issue for the PO using the cancellation transaction in SD. You cannot reverse the GI in Inventory Management.
The material document that is automatically created in the receiving system cannot be canceled. This reversal is triggered by the sending system (the actual reversal of the GI document takes place there) and transmits the data, including the reversal movement type, to the receiving system. No actual reversal is posted in the receiving system, because the material document number of the original document does not exist in this system. This scenario is applicable for cases where you use the two-step procedure (with stock in transit).
Distribution of Batch Master Data and Characteristics
The batch information is transported using the message category BATMAS.
When you create a cross-system goods issue, the system creates the corresponding IDoc using the message category BATMAS.
When the delivery arrives in the target system, the batch and all the information is already present in the system.
Changes to the batch data are also distributed using the message category BATMAS.
The batch can be decoupled in the receiving SAP R/3 system. This means that the batch can have a different status in the receiving system than in the original system. By setting an indicator at material level, you decide whether the batch can be decoupled or whether the batch and all its attributes are copied from the original system. "Decoupled" i.e. "locally independent" batches are no longer distributed from its own system.
The batch data does not need to be available before the physical goods receipt takes place. The goods receipt into the stock in transit does not usually refer to the batch unless you are working with batches with assigned active ingredient values.
If the GI cannot be posted for organizational reasons, for example because the goods cannot be loaded onto a truck until 10pm, then you can post the goods into the GR blocked stock. This stock is also non-batch-specific.
In cases where the GI IDoc arrives before the batch IDoc, then the GI IDoc can be subsequently posted by a periodically scheduled report (transaction BD87). A program like this exists in the SAP standard system. In Customizing for MM Inventory Management (activity Copy, Change Movement Types), you should make settings to define that manual creation of batches at goods receipt is not allowed.
Shipping Notification
The shipping notification is required in the receiving system due to its relevance for MRP. In this way, for example, a change in delivery date determined at goods issue is sent to the receiving system using the shipping notification. The shipping notification can also be used when posting the GR batches.
Reward if found helpfull,
Cheers,
Chaitanya.