Outbound Scenarios - Erp SCM - SCN Wiki

1/17/2018 OUTBOUND SCENARIOS - ERP SCM - SCN Wiki
Getting Started Store
Community WIKI SAP Community Welcome, Guest Login Register Search the Community
ERP SCM / … / Service Parts Management
OUTBOUND SCENARIOS
Created by Dia Nainika Nair, last modified on Nov 19, 2017
RETURNS PROCESS:
Consider that a product has been shipped to a customer but due to some reason - defects in the product, the received quantity being more than required, the product being wrong - they had to return it. A
returns process thus involves an inbound process with the stock being returned to the company.
The process begins with the creation of a returns order using the transaction code VA01 and using the order type "RE".
Once this returns order is created, the returns delivery can be directly created from the order by clicking on the button "Sales Document" in the Menu and then on "Deliver". This triggers the transaction
VL01N and the delivery creation screen is displayed.
Returns deliveries will have the delivery type LR. The customizing for it can be seen by following the path:
Transaction SPRO - Display IMG > Logistics Execution > Shipping > Deliveries > Define Delivery types.
The returns delivery is an inbound process but on the ERP side it is viewed as an outbound process and hence the outbound delivery transactions are used.
The distribution of the delivery to the EWM system is done based on the customization maintained for the delivery type.
The transaction SLG1 can be used to view the log of messages that have been communicated to the EWM system. So far, for this delivery, only the delivery creation message has been sent to the EWM
system - FM /SCWM/OUTB_DLV_SAVEREPLICA.
In the EWM system, the transaction used to view a returns delivery is /SCWM/PRDI as it is considered an inbound delivery on the EWM side.
Enter the correct warehouse number, select ERP document and enter the delivery number.
Create and confirm a warehouse task for this delivery. The Goods receipt and the put-away statuses will be completed.
https://wiki.scn.sap.com/wiki/display/ERPSCM/OUTBOUND+SCENARIOS 1/26
On checking the SLG1 log in the ERP system again, there will be two more queues - one for the GR that has been posted in the EWM system and the other for the closing indicator. Both call the FM
BAPI_OUTB_DELIVERY_CONFIRM_DEC.
Now, assume the goods have reached the plant but haven't been put into the storage bins.
In this case, in the EWM system, only the goods receipt is posted. This will send a confirmation message to the ERP system regarding the posted goods receipt. The delivery will have the Goods
Movement status set to C but the delivery completion indicator will be blank.
On creating and confirming a warehouse task for the full quantity in the EWM system, the closing indicator will be sent to the ERP system.
To perform the billing, use the transaction VF01 and enter the returns delivery number.
This creates a credit memo for the customer.
The billing can only be started once the completion indicator has been set for the delivery because the quantity can still change before it is set.
QUANTITY DIFFERENCE:
Create a Returns order and a delivery from it in the ERP system and distribute it to the EWM system.
Find the delivery in the EWM system and post the Goods Receipt. During the put-away, change the quantity to a lesser value. This can be done by going into the change mode and switching to form view.
Click on "Confirm in Foreground". Enter the difference in the quantity in the field "Dest. Diff. Qty.", the exception code as "DIFD" (to have the changes reflect in the inbound delivery) and click on confirm.
Viewing the Returns Delivery in the ERP system shows the reduced quantity. The document flow will show a new material document - the reversal of the posting for the difference quantity.
STORAGE LOCATION CHANGE:
Create a Returns order and a delivery in the ERP system and distribute it. The storage location can be ROD (Receive On Dock) and AFS (Available For Sale) - ROD stock is not available for sending to
customers. The stock in ROD can be posted as goods received and it can be reserved for further processing.
The EWM system doesn't have plants and Storage locations within these plants. Instead, it has stock types and a form of mapping between these stock types and plants and storage locations. For a
delivery with the storage location ROD, the stock type in the EWM system will be a restricted one (for instance F1). Post the GR in the EWM system and view the delivery in the ERP system - GM status
will be C and delivery completion indicator will not be set as the put-away hasn't been done yet.
In the EWM system, on confirming the warehouse task, in the line item's document flow, an additional entry for a posting change can be seen. On displaying this warehouse task in detail, the source and
destination storage types can be seen and a posting has taken place from the restricted to the unrestricted stock type.
The ERP system will show the completion indicator set for the returns delivery and the document flow at the item level will show a posting change in the ERP system as well - the first Goods Receipt was
into the ROD storage location and now there is a transfer posting from ROD into AFS.
The FM responsible for the Posting change is /SPE/GOODSMVT_CREATE.
The queue container, of the posting change queue, in the application log (using transaction SLG1), shows no changes made to the delivery. Its main purpose is to create the material document. It contains
information about the source and receiving storage locations for the line item.
PARTIAL GOODS RECEIPT:
Again, create a returns order and a delivery from it in the ERP system and distribute it. In the EWM system, view the delivery using /SCWM/PRDI. In order to post partial goods receipt, packing must be
done - for this, go to the menu and follow the path: Inbound delivery > Follow on functions > Pack. Create the required number of HUs and drag and drop the materials into the corresponding HUs and
save.
Now, the inbound delivery will show the created handling units under the HU tab. Select one among these HUs and post the GR.
In the ERP system, the GM status will be 'B' - Partially completed.
On posting all the HUs pending GR, the GM status will become 'C' and the individual GR postings can be found in the document flow.
An inspection is generally done for any goods returned in order to check the quality/damage done to them. Quality inspections are set up at a material level and so, in order to view the inspection, create
another returns order using a material for which the quality inspection has been set up.
Create and distribute the returns delivery to the EWM system. On viewing it in the EWM system, the document flow shows no inspection document. Perform the Goods Receipt and now the quality
inspection document will be generated. To view it, select the row and click on "Display additional data". Switch to form view.
The follow-up action can be selected among - Put-away, stock transfer and scrapping. The decision code can be selected among - OK, Partially OK, Not OK and Returns. After selecting these, click on the
pushbutton "Decide" and save the inspection document.
In the ERP system, two queues - one (/SPE/INSP_MAINTAIN_MULTIPLE) for the communication of the inspection document and the other (/SPE/GOODSMVT_CREATE) to update the stock on the ERP
side by creating a material document based on the follow-up action selected.
Complete the processing in the EWM system by creating and confirming a warehouse task and a final confirmation will be communicated to the ERP system.
CRM LANDSCAPE:
Using the transaction CRMD_ORDER, select an existing transaction as a template, copy it and change the status to "released" from "open" after making the required changes. Creating a transaction has
the same idea as replicating to the ERP - In the ERP system find the delivery number in the table LIPS using the transaction number created previously as the field LIPS-VGBEL (reference document).
View this delivery using transaction code VL03N. It is similar to the returns delivery created directly from a returns order except that there is another tab "Overview of Returns" before the Item overview tab.
As part of the CRM-ERP interface, the program involved is LV50R_CREAF36. The program for analysis and reprocessing of the communication between the CRM and the ERP system is
/SPE/OBDLV_LOGFILE_ANALYSE. Enter the predecessor document number and execute - this shows the information that came from the CRM system to the ERP system.
Clicking on "Reprocess Data" leads to the creation of a new delivery with returns category - Return to own warehouse - and it is distributed to the EWM system.
In the EWM system, use the transaction /N/SCWM/PRDI to view this delivery. It is an inactive inbound delivery notification. Posting the goods receipt leads to the creation of the inspection document.
Switching to form view during the creation of the warehouse task shows that put-away, stock transfer, and scrapping can no longer be selected as the follow-on functions. This inspection document is
communicated to the ERP system which in turn forwards the information to the CRM system.
OUTBOUND PROCESS:
A simple outbound process would be one without a reference document. To create an outbound delivery without reference, use the transaction VL01NO. Fill in the required data - the delivery type must be
LO (delivery without sales order).
Enter the Ship-to-party, planned GI and the item details. The Storage Location is AFS (ROD is not relevant for sales). Save and distribute the delivery to the EWM system.
To check whether a warehouse in the ERP system has an EWM system linked to it, follow the customization path:
SPRO > SAP Reference IMG > Logistics Execution > Service Parts Management > Integrate SPM with other components > Maintain Extended WM-Specific Parameters:
Here, search for the warehouse number, the field "Ext. WM" will show whether a warehouse is EWM managed. The field "Comm. WM" gives the mode of communication between the ERP and the EWM
system and the field "Dist. Mode" shows whether the distribution is stopped or done automatically at document creation.
The assignment of the plant and storage location to the warehouse number is found under the following path:
SPRO > Display IMG > Enterprise Structure > Assignment > Logistics Execution > Assign warehouse number to plant/storage location:
Here, you can search for the plant and storage location and the assignment of the warehouse to it can be found. This can be seen in the delivery as the field "Warehouse No." under the picking tab in
VL03N as well.
The transaction SLG1 can be used to view the application log of messages passed between the ERP and the EWM system. But this must be activated by recording both success and error messages
under the following path:
SPRO > Display IMG > Logistics Execution > Service Parts Management > Integrate SPM with other components > Log Sent and Received Messages
It can also be customized to view only error messages or disable logging any messages.
In order to view the actions performed on the EWM side in the ERP system, deregister the queues in transaction SMQR in the ERP system.
In the EWM system, the outbound delivery can be found and maintained in the transaction /N/SCWM/PRDO.
The outbound delivery request is the first document created once the outbound delivery is distributed to the EWM system. The outbound delivery order is what we find in the system now and the outbound
delivery is the document created after the GM is posted.
The header data shows the statuses and the item details are found in the tabs below it.
Picking of the goods is done by clicking on Outbound delivery order in the menu > Follow-on Functions > Warehouse task. Create and confirm the warehouse task. Posting Goods Issue is done by
clicking on the Goods Issue button after selecting the delivery row in the header.
This Goods Issue queue can be found in the ERP system using the transaction SMQ2. The FM responsible is BAPI_OUTB_DELIVERY_CONFIRM_DEC.
Executing this queue will change the delivery status from A to C if the full quantity was posted in the EWM system. The document flow will show the material documents created and the movement types
used.
The goods movement reversal will not be possible once the invoice document has been generated. In the STO scenario, once the subsequent inbound delivery has been created, the GM reversal can be
only be done depending on the status of the inbound delivery.
At this stage of the simple outbound process, it is possible to reverse the GI and this must be triggered in the EWM system.
In order to reverse the GI, switch to the outbound delivery by clicking on the button "Outbound Delivery". Here another option - Reverse Goods Issue is available. Clicking on it changes the Goods Issue
status to "Not started" from "Completed".
This will trigger a new RFC to be sent to the ERP system for this change. The FM responsible for it is BAPI_OUTB_DELIVERY_CHANGE. The HEADER_CONTROL_SPL contains the sender method
which indicates what change has been performed. In this case, it would be an RVRS - Reversal of Confirmation. Processing this queue will cause the Goods Movement status of the delivery to go back to
'A'.
There is no partial Goods Issue posting. All the quantity must be posted at once.
In case only some of the items in the outbound delivery are available in the EWM system, a splitting of the original delivery is possible - this is called a delivery split.
In this case, select the items that are available and create and confirm the warehouse task for just those items.
If only the first item needs to be delivered, select the line item and click on the "outbound delivery" pushbutton in the item overview area and save.
This will be communicated to the ERP system by sending an outbound delivery split message and the FM responsible for this is BAPI_OUTB_DELIVERY_SPLIT_DEC.
The EWM system will show two reference documents: ERP Original Document is the outbound delivery that has been created in the ERP system and the next document, the ERP document is the number
of the delivery that has been split. The queue container will show the split delivery's number under "DELIVERYNEW".
In the ERP system, on viewing the original delivery using transaction code VL03N - the first item (the item in the split delivery) will show a reduced quantity.
The link between the split delivery and the original delivery can be found in the table LEDSPD_FLOW by entering the original delivery's number.
Another queue that will be sent to the ERP system along with the BAPI_OUTB_DELIVERY_SPLIT_DEC is the BAPI_OUTB_DELIVERY_CONFIRM_DEC.
In the EWM system, it is now possible to post the Goods Issue for the split outbound delivery thus created or to delete it, in case the GI needs to be done together. On deleting, three queues will be sent to
the ERP system - BAPI_OUTB_DELIVERY_CHANGE, BAPI_OUTB_DELIVERY_SPLIT_DEC, and BAPI_OUTB_DELIVERY_CONFIRM_DEC.
The message from BAPI_OUTB_DELIVERY_SPLIT_DEC will be a reversal of the delivery split which can be seen in the queue container where the DELIVERY tab shows the split delivery number and
the DELIVERYNEW tab shows the original delivery number.
On executing these LUWs, the split delivery quantity will reduce to 0 while the original delivery quantity increases by the same amount. The last queue - BAPI_OUTB_DELIVERY_CONFIRM_DEC - will
change the GM status of the split delivery from A to C.
NOTE: The queues are always found with respect to the original delivery number.
It is also possible to split the outbound delivery at the item level by selecting the item, clicking on "Create Subitem for Outbound Delivery Split" and entering the number of subitems and then clicking on
"Outbound delivery" under Item Overview. This will send the split message and the confirmation message to the ERP system.
To complete the process in the EWM system, pick the remaining items by creating and confirming a warehouse task. Post the Goods Issue, this will create another outbound delivery thus sending 1 split
delivery message and 2 confirmation messages to the ERP system. On executing these LUWs, there will be 2 new split deliveries while the quantities in the original delivery are reduced to 0.
BATCH SPLIT MATERIALS:
Using VL01NO, create an outbound delivery without reference to a sales order and use a batch managed material. Save and distribute this delivery to the EWM system. In the EWM system, the item must
be split into batches. This can be done by selecting the item and switching to form view and then entering the value for the field "Batch" or by selecting the line item and clicking on "Subitem" and then on
"create batch subitem".
In order to know the specific batches maintained in the system, click on create the warehouse task, then delete the request and switch to the tab titled "Stk Can Be Removed". This shows, in detail, the
storage types, bins, and batches. Here, the user can edit the "SrceTgtQty" as the quantity of that batch that is required, select the items and then click on "Adopt Quantity". This will incorporate the
proposed quantities into the warehouse task. Now, the Warehouse task tab will show two new warehouse requests. Confirm and save these. The system will have one line pertaining to each item - the
batch main item and the batch split items.
These batch split items must be communicated to the ERP system as well. They are given Reference Item numbers in the EWM system (Select the item and view the Reference Documents tab). Based
on the customizing, messages will be sent to the ERP system. In this case, posting the Goods Issue of this delivery will send the confirmation message to the ERP system as the customization is set that
way. Before processing this queue, the delivery will have just one line item. Processing the queue generates the batch split indicator, which by clicking, will show the batch split items. The GM status will
also be C.
The material document will contain two lines - one per batch split item.
Customizing in the EWM system for the ERP versions linked to it:
This enables us to view the communication process between the ERP and the EWM system.
For instance, under Batch Control, Communication of batch split of Inbound Delivery Item, we can customize it to send the messages of batch split immediately on saving the delivery or only on posting
Goods Issue.
On setting it to "Immediately communicate on saving the delivery", a delivery change message will be sent to the ERP system on saving the delivery after splitting the batches in the EWM system. The
ITEM_DATA tab will display the details of the batches.
Create a sales order - VA01
The order type is OR - Standard Order.
Enter the required data and click on Sales Document > Deliver. Save the delivery and distribute it. The sales order document number can be seen in the EWM system under the reference documents for
this distributed delivery.
If the delivery has been distributed but the quantity in the sales order is changed, on saving the sales order, a pop up stating "System is attempting to adjust the delivery quantity" appears. This message
has the message number /SPE/VL400.
Note All messages beginning with "/SPE/" belong to the SPM component.
The document in the EWM system will have the updated quantity on viewing again. This causes a change message to be sent back to the ERP system to change the delivery quantity there.
Note
Detailed information in notes: 821101 (SPM), 860427 (SPM) and 1423321 (LE-IEW).
PICK DENIAL:
This happens if the system cannot pick the goods due to some reason (for instance when the bin is empty). Consider the number of the bin entered for a particular batch, when creating a warehouse task,
is incorrect or doesn't contain that batch. In this case, a pick denial will occur by clicking on "Create" the warehouse task and the Pick Denial tab will show the action for pick denial.
This pick denial action will be sent to the warehouse supervisor and he can view it in the SAP Office inbox. He can then decide to execute the item or look for a replacement locally for this request.
Executing the item would mean that the delivery quantity will get automatically adjusted to the actual picked quantity. A BAPI_OUTB_DELIVERY_CHANGE message will be sent to the ERP system. The
queue container will show the PICK_DENIAL flag has been set and on executing this LUW, the original delivery will be updated.
HANDLING UNITS:
Create an outbound delivery without reference to a sales order, save it and distribute it. In the EWM system, after picking the goods, packing can be done. The Packing material needs to be specified and
the Handling Units/Storage bins need to be created. To pack the entire amount, we can drag and drop the item into the created HU. For partial quantities, the quantity can be entered after the item is
double-clicked on. Once this is done, click on save.
For each of the HUs, we can create an outbound delivery and post the GI separately. Once this is communicated to the ERP system, the HUs can be viewed in the ERP system where the history of action
can also be seen under the History tab.
STO PROCESSING:
Create a Stock Transport Order (STO) in ME23N and ensure the Confirmation Control is "Inbound delivery", otherwise the subsequent inbound delivery cannot be created. Since Automatic Delivery
creation has been switched off, on viewing this STO in ME23N, no Purchase Order History tab will be seen. In order to manually create a delivery for it, use transaction VL10B and enter the STO number
and execute. This will display the list of Purchase Orders yet to be delivered. To create the delivery, select the row corresponding to the STO and click on the pushbutton "Background". This will create a
delivery in the background and once created, a second row will appear containing the delivery number under "Document".
This delivery can have the settings "Stop distribution" or "distribute at the time of creation". The customizing settings used to determine this is found in the following path:
On double clicking on the delivery type, its features are displayed, where the following settings for the distribution mode can be seen:
The distribution can be controlled based on the delivery type or the warehouse number.
If the distribution of the delivery is stopped, the distribution needs to be done in the transaction VL06D, where the delivery number is entered and executed. The corresponding row is selected from the list
and the button "Distribute" is clicked.
Selection of "Distribution Control By Warehouse Number" would mean that the settings would need to be maintained at the warehouse level under the following customization path:
Position at the required warehouse number and select the distribution mode as follows:
Process this Replenishment delivery, once distributed, in the EWM system using the transaction /SCWM/PRDO and Post Goods Issue. This will appear as a material document in the document flow of the
delivery in VL33N in the ERP system. Movement type will be 641 which posts the stock in transit at plant level.
The transaction MMBE will show the stock location given the plant and stock type. It can be seen at the plant level as well as at the storage location level.
In VL33N, view the output type by clicking on Extras > Delivery Output > Header. If the status of the output flag is a yellow warning symbol, it implies that an output type exists for this delivery but hasn't
been processed. In order to process it, use the transaction VL71 - Output from Deliveries - which is meant to process the output types for Outbound Deliveries. Enter the delivery number, select the row
and click on execute. If any errors are encountered during the processing, they would be listed in the log. The inbound delivery thus created can be found in the document flow of the Replenishment
delivery and in the "Confirmations" tab of the STO.
This inbound delivery will be automatically distributed and can be maintained in the EWM system using the transaction /SCWM/PRDI.
If you navigate to the header of the inbound delivery and move to the Administration tab, the Replenishment delivery number can be seen under the "External ID" field.
The output determination procedure can be seen in the customizing settings for the Delivery Type:
The output type SPED is meant to generate the inbound delivery from the outbound delivery automatically. The program that will be run is /SPE/STO_ID_PROCESSING and the form routine that will be
called is STO_ID_CREATION.
Once the output types are defined, the procedures are created for them. Each procedure will contain a list of output types depending on the requirements.
For the output type SPED, the dispatch time can be maintained as any of the following:
1. Send with periodically scheduled job.
2. Send with job with additional time specification.
3. Send with application own transaction.
4. Send immediately (when saving the application).
On setting the dispatching time of the output type as option 4, the posting of Goods Issue will result in the program being called to create an Inbound delivery (SPED is processed).
Rejecting the Inbound delivery:
In the EWM system, it is possible to reject an inbound delivery created in the ERP system as a result of the output type SPED being processed.
Note 1119073 shows the FAQs for the automatic inbound delivery creation for Stock transfers.
To customize the automatic delivery creation settings, follow the path:
Look for the corresponding document type and supplying plant. There are two options for the automatic delivery creation:
1. Auto delivery creation active, change value of KZTLF to B

2. Auto delivery creation active, no change of KZTLF
Apart from above, the activation of automatic delivery creation for PO Type and Shipping point must also be done:
The corresponding shipping point can be found in the Shipping tab at the item level on viewing the STO/PO in ME23N.
A customizing can be done to determine which stock type is used to ship the goods under "Activate Source Stock type determination".
In the STO or PO, the stock type denotes the destination Stock type - at the receiving end.
The above customizing allows activation of the stock type for the source as well. Tick the checkbox active on executing the above and the source stock type is determined in all cases.
In order to reverse the Goods issue of the Replenishment delivery in the EWM system, the subsequent Inbound delivery must be deleted. For this, the GR - if done - must be reversed in the ERP system
using TCODE VL09. Once done, the inbound delivery must be deleted.
DIRECT OUTBOUND DELIVERIES:
The process involves the creation of outbound deliveries directly in the EWM system. For instance when a customer comes directly to the warehouse and the goods are provided immediately, the data is
logged directly in the EWM system and this sends a message to create a delivery in the ERP system.
The simplest DOD is a delivery created for a customer which is similar to a normal outbound delivery created without reference in the ERP system.
To create a DOD, in the EWM system, using transaction /SCWM/PRDO, click on the create button:
For the basic DOD, use document type ODSH - ODO Direct Outbound Delivery.
This creates the header for the Outbound Delivery. To add the items, click on the create button at the item level. To fill in the item data -x` the material, quantity, etc., click on "switch to form view" and enter
the details.
In order to enter the data regarding who picked the stock up, click on the "Partner" tab. To enter the partner data manually, change the determination indicator to 'M'. This makes the field "Business
Partner" editable.
If stopping the queue for this DOD is required in the ERP system, obtain the Delivery number from the tab "Reference Documents" and deregister the queue pertaining to the queue name: *
<delivery_number>.
Saving the DOD in the EWM system will send a /SPE/OUTB_DELIVERY_SAVEREPLICA message to the ERP system, which can be found in the ERP system using the transaction code SMQ2.
To determine the delivery type corresponding to the delivery type in the EWM system, there is a customization in transaction SPRO in the ERP system:
This will show the delivery type in the ERP system corresponding to the delivery type in the EWM system.
Once the queue is processed in SMQ2, the created DOD can be viewed using transaction code VL03N. It will have the distribution status as 'B' and this delivery can only be changed now in the EWM
system.
To differentiate between a delivery created in the ERP system and the EWM system, check the LIKP table in the ERP system for the field SPE_LE_SCENARIO. If this field has the value 'W', it is a DOD
created in the EWM system. If it is blank, it a normal Outbound delivery.
The rest of the process is similar, where the Picking and GI are posted in the EWM system and this is communicated to the ERP system.
DELETING A DOD IN THE EWM SYSTEM:
Repeat the process by creating a new DOD in the EWM system and processing the queue in SMQ2 in the ERP system.
To delete the delivery in the EWM system, select the delivery header and click on the trash can icon and save. In the ERP system, a change message will be received. The HEADER_DATA will contain the
DLV_DEL flag set. On processing this LUW, the delivery will be deleted in the ERP system and it will not be found in transaction VL03N.
VL22N (Change logs) will show the changes made to the delivery including its deletion.
DIRECT DELIVERY WITH STOs:
Create a DOD in the EWM system in transaction /N/SCWM/PRDO. Ensure the partner is from another warehouse for this to be an STO process.
On processing the corresponding queue in the ERP system, another internal queue beginning with DLVI will be generated on refreshing SMQ2. The FM for this queue is
"/SPE/CREATE_STO_FOR_DIRDLV". It was designed to have the two queues - one sent from EWM and one internal - to enable errors occurring due to either to be identified. On executing this queue, a
new queue gets generated with the same queue name beginning with DLVI. This queue calls the FM "/SPE/DELIVERY_CREATE_FROM_STO". Thus the first queue is to create an STO and the second to
create the replenishment delivery from it. The second queue gives the STO number under "Ref Document".
This STO cannot be used to create more outbound deliveries from it in the ERP system. On trying to do so in VL10B, an error occurs stating that this STO belongs to a third party delivery.
Also, for this scenario, the field LIKP-LE_SPE_SCENARIO = 'V' (Direct Delivery to Another Plant).
For the same delivery, assume only some of the goods were issued. In the EWM system, this can be shown by using Process Codes - With quantity adjustment, No quantity adjustment and Adjust
delivery quantity. Select With quantity adjustment and enter the quantity.
The system will update the actual quantity. Nothing is communicated to the ERP system until the warehouse task is completed. Create and confirm a warehouse task for the actual quantity and post the
Goods Issue. This should reduce the quantity in the Delivery and in the STO. Thus, an internal queue is generated by executing the CONFIRM_DEC message. The first queue confirms the delivery with
the reduced quantity and the GM status as 'C'. The second queue will update the quantity in the STO. In the queue container, under the table parameter "IT_PROCESS_STEPS", the flag
POST_PROCESSING_STO will be set to X as there are changes to be made to the STO.
If the quantity change is a decrease from the actual quantity, the delivery must be updated first and then the STO. If on the other hand, the quantity is increased from the actual quantity, the STO is
updated first and then the delivery is updated - the order of the internal queues is reversed.
It is also possible to add items to the delivery. To do this, create a DOD in the EWM system with one line item and enter its details. Once the delivery is created in the ERP system, in the EWM system add
another item to this delivery - say a packaging material (Item type: OPAC). On saving its details, a DELIVERY_CHANGE queue is sent to the ERP system. If an STO is involved, the STO is updated with
the new quantity first via an internal queue and then the DOD is updated.
The item can be deleted in the EWM system too. This will send another DELIVERY_CHANGE message to the ERP system. On executing it, two internal queues will be generated - the first deletes the line
item in the delivery and the second deletes the item in the STO. On viewing the STO, the line item is still visible but with a trash can icon beside it.
It is possible to add items in the EWM system for a delivery created and communicated from the ERP system. But this will change the value of LIKP-SPE_LE_SCENARIO from ' ' to 'U' - Replenishment
delivery with additional items.
BILLING LINKED WITH IEW:
Consider a simple scenario, in a stand-alone system, starting with the creation of a sales order in VA01. Enter the pricing details and create a delivery by clicking on Sales Document > Deliver.
Once the delivery is created, manual picking for the quantity can be done after which the Goods Issue is posted.
To generate the billing document, go to transaction VF01 and enter the delivery number which needs to be invoiced and click on save.
On viewing the delivery in VL03N now, the document flow will show the accounting document as well.
It is possible to cancel everything and this is done in the reverse order.
First, the invoice must be canceled. To do this, go to transaction VF02, enter the invoice, click on Billing Document > Cancel and then Save.
This will be reflected in the document flow of the delivery - VL03N.
To reverse the Goods Issue, use transaction VL09, enter the delivery number and execute it. Select the row and click on "Reverse".
The document flow will show the cancellation as well:
1. Invoice
2. Goods Issue
3. Goods Issue reversal
4. Invoice Cancellation
IBGI - INVOICE BEFORE GOODS ISSUE:
Billing can be done at two times:
1. Direct Billing
2. Using wait for billing request.
Direct Billing generates a Billing document for one outbound delivery in the EWM system before the GI is posted.
Create a Sales Order in the ERP system using VA01. Generate the delivery for this SO and distribute it to the EWM system. In the EWM system, find the ODO with this ERP number and create and
confirm the warehouse task for this delivery. Select the required line items and click on "Outbound delivery" to create the outbound delivery from this ODO. Click on Save. Note, that the Goods Issue was
not posted.
In the ERP system, view the delivery in VL03N and click on Extras > Delivery Output > Header:
The output type REA0 will be seen. To manually process the output type, use transaction VL71 to process it. The output type RD0A is responsible for the printing of the billing document.
Create an outbound delivery without reference to a sales order - VL01NO - and distribute it to the EWM system.
Deregister the queue in the ERP system if you want to view the queues sent by the EWM system in SMQ2.
In the EWM system, view the outbound delivery using /SCWM/PRDO. Do the picking by creating and confirming a warehouse task. Generate the outbound delivery.
Now, post the Goods Issue.
View the queues corresponding to the delivery in the ERP system.
There will be 2 queues - the first for the IBGI and the second for the Goods Issue.
The first queue's container will show, under the HEADER_CONTROL_SPL parameter, that the field "Direct Billing" is set to 1. Also, the Print profile is "IGBI".
In the HEADER_CONTROL parameter, the Post Goods Movement indicator is not checked.
On processing the first queue, the document flow of the delivery will show that the invoice document has been created.
The second queue will post the Goods Issue.
Now, in the EWM system, reverse the Goods Issue and delete the outbound delivery.
This will generate two queues - first to reverse the GI and the second will cancel the invoice.
Customization in the ERP system: In the transaction OLML, follow the path:
At the beginning of the IBGI process, an outbound delivery has to be created which has the IBGI indicator in the delivery header set: LIKP-SPE_INV_BFR_GI.
These are set depending on the two fields VKORG and AUART in the sales document.
The output type REA0 needs to be set up correctly in transaction NACE under which the application V2 (Shipping) is used. The program is /SPE/DLV_IBGI_PROCESSING.
Define the print profile under the following path:
The assignment of an output type to a printer profile is done under the following IMG activity:
Most IBGI customizing are done under the classic shipping customizing itself.
CUSTOMIZING IN THE EWM:
Setting control parameters for ERP version control: Here, one can set if the IBGI is even allowed or not.
Defining Print Profiles for Delivery Processing and Print Profile Determination for Goods Issue Process:
It is important that the Printer Profile name should be the same in the ERP system and the EWM system. Otherwise, the invoice will not be printed correctly.
Defining document types for the outbound delivery process: Here, set the Billing request type to "A Billing Document Immediately". And do the same for the item types.
TECHNICAL DETAILS:
Within the BAPI BAPI_OUTB_CONFIRM_DEC, the flag DIRECT_BILLING in the parameter HEADER_CONTROL_SPL is set and a printer profile is given from HEADER_CONTROL_SPL
PRINTER_PROFILE. The printer profile and the direct billing flag are stored in outbound delivery header fields (LIKP-PRINTER_PROFILE and LIKP-SPE_BILLING_IND.
Coding Places:
Include: /SPE/V50SF01 - FORM SPE_OUTB_UPDATE_HEADER; PROGRAM - SAPLV50S
Function /SPE/CREATE_NEW_BILLING_CALL is called from the processing program of output type REA0 (i.e. report /SPE/DLV_IBGI_PROCESSING) with parameter IV_VERSION_CHECKED = 'X' and
IT_BILLING_REQUEST without any item detail. Hence, all relevant delivery items (whether they've been sent to EWM or not) are billed.
In case the output REA0 is set up for immediate processing in the delivery, the system processes the output in a separate background process see /SPE/CALL_PROC_IN_NEW_LUW. Note 1238590.
Requirement routine 417 is linked to REA0.
Source code of LV61B417 - Form KOBED_417 - PROGRAM=SAPLV61B
BILLING WAIT:
Enables to generate, with one request, the billing document for multiple outbound deliveries before the goods issue - mainly when handling Transportation Units where multiple outbound deliveries must
be combined in the billing process. It is in the EWM system that this functionality is called.
The prerequisite is to check if the routing allows group billing in transaction /SCWM/IBGI.
Create two outbound deliveries in the ERP system that can be put together in the billing document, and distribute them.
In the EWM system, create a TU (Transportation Unit) in transaction /SCWM/TU by clicking on the "Create" button. Fill in the required data and hit enter.
Click on "Assign Delivery Immediately" and enter the ERP document numbers of the outbound deliveries to be put together in this TU and then click on execute:
This will assign these deliveries to the previously created TU.
Click on the "Activate" button to activate this TU.
Now create and confirm the warehouse tasks and post the GI individually for these deliveries in /SCWM/PRDO. Create an Outbound Delivery for the items of each delivery and save.
Viewing the TU again will show the two outbound deliveries as two rows under the "Assigned Deliveries" tab.
To generate the invoice document, click on the "Request Invoice" pushbutton and this functionality should create the invoice in the ERP system.
When requesting the invoice, EWM FM /SCWM/SR_INVOICE_CREATE is called in the background from the method SEND_INVOICE_CREATE_MESSAGE of class /SCWM/CL_SR_IBGI.
The invoice will show the items from both the outbound deliveries.
If queues are deregistered in the ERP system, use the "S&R activity number: TU" field in the TU header to search for the queue.
AUTOMATIC BILLING CANCELLATION ON REVERSING THE GOODS ISSUE:
This is a special feature included which can be customized under the following path:
Position based on the Billing type and the Sales Organization, and tick the checkbox based on whether the cancellation of the Invoice must be done with the reversal of the Goods Issue.
Create an outbound delivery without reference to a Sales Order in the ERP system and distribute it to the EWM system.
Deregister the queue in the ERP system.
In the EWM system, create and confirm the warehouse task and Post the Goods Issue for the distributed delivery.
On viewing the delivery in the ERP system, the document flow will show that the GI has been done for the delivery and the invoice has been generated.
On reversing the GI in the EWM system, a DELIVERY_CHANGE message will be sent to the ERP system and on processing this queue, the document flow will be updated with a cancellation of Invoice
document and a Goods Issue reversal document.
When the BAPI_OUTB_DELIVERY_CHANGE queue corresponding to the reversal of the GI is processed, the customizing for the automatic cancellation of billing document on the reversal of GI is
checked in the following code:
* Not billed yet. -> Nothing to do
RETURN.
ELSE.
SELECT SINGLE spe_inv_gi_rvrs FROM /spe/gi_rvrs_inv INTO ls_inv_gi_rvrs
WHERE fkart = ls_delivery_data-head-fkarv
AND vkorg = ls_delivery_data-head-vkorg.
As a result, the FM /SPE/CANCEL_BILLING_DOCUMENT, which will call BAPI_BILLINGDOC_CANCEL1, is processed.
TRANSPORTATION CROSS DOCKING:
Transportation cross-docking is mainly used to fulfill two business requirements:
— Consolidate shipments from different source locations into common shipments in a certain warehouse
— Route export shipments through a warehouse which is specialized to process the necessary export procedures
In the ERP system, create a Sales Order - VA01 and create an outbound delivery from it and distribute it to the EWM system.
In the EWM system, perform the picking and Goods Issue.
The TCD process is triggered by the route determination - Whenever goods are shipped, the route that they take must be determined.
In this example, consider the manual route determination by clicking on the Route pushbutton on viewing the outbound delivery in the EWM system in /SCWM/PRDO.
It is possible to re-determine the route automatically or to assign it.
If the route is assigned, an additional line is generated in the Partner tab as an intermediate step involving another Ship-to-party has been included.
Create the warehouse task and confirm it.
In order to carry out the TCD process, it is necessary to pack the items. For this, select the ODO, click on Outbound Delivery Order in the Menu > Follow-On Functions > Pack.
Create an HU, drag and drop the material in it and save. Post the Goods Issue.
In case of a TCD, the GI message queue - CONFIRM_DEC will show the GEOROUTE field filled with the entry in the HEADER_DATA_SPL parameter.
Also, the flag MOVE_CD_PLANT_FLG will be set to 'X'.
The documentation for the customizing settings for TCD can be found by following the path:
It is important to notice that the goods remain assigned to the inventory of the source warehouse until the final goods issue at the cross-docking warehouse. This implies that no borders can be crossed
during shipment to a cross-docking warehouse; border-crossing is only possible after final goods issue.
The relationship between cross docking plants and storage locations can be customized with the following:
Before the processing of the CONFIRM_DEC queue, view the partners in the delivery in the ERP system - VL03N by navigating to Goto > Header > Partners.
The different partners with different roles can be seen.
But the queue container will show a new partner role - Parameter HEADER_PARTNER, field PARTN_ROLE.
Also, the movement type for an outbound delivery is 601 which will be the default movement type in the delivery.
On processing the queue, the movement type changes to 313. It is the first step of the two-step posting between storage locations - removal from storage.
Normally, the process should involve the creation of an inbound delivery into the cross-docking warehouse and another outbound delivery from the CD Warehouse to the customer as per the figure:
In the Administration tab of the header details of the outbound delivery, an additional field known as the CD Process can be seen. It is the Cross-Docking Process Number
To link all deliveries in such a chain of inbound and outbound deliveries, a cross-docking process number is determined and assigned to these deliveries.
Under the Shipment tab, the Georoute which was changed in the EWM system can be seen.
The inbound and outbound deliveries into and from the CD warehouse are created as a result of the output types - CDOD and LD00.
CDOD is similar to SPED but unlike SPED, it does not have to create just one inbound delivery from the outbound delivery.
The transaction /SPE/CDMON allows the user to track all deliveries that are involved in TCD processes in the ERP system.
The CD Process number is to be entered as the value for field TCD Process under the Delivery Data tab.
On clicking on execute, the left side shows the list of deliveries associated with this TCD chain.
It is possible to process the output types in the transaction VL71 or by clicking on the "Process Output" button in this monitor:
On executing the Output type CDOD, two deliveries will be generated which can be seen on the left side of the CD Monitor.
The inbound delivery thus created will have movement type 315 which corresponds to the second step of the two-step posting between storage locations - the placement in the storage.
The new outbound delivery created will have the movement type 601.
It is possible to create one warehouse task and one goods movement, to move the goods directly from the GR area to the GI area, for both the deliveries rather than posting individual Goods Movements
and picking processes for each.
Now, the deliveries require processing in the EWM system. For the inbound delivery, ensure the warehouse is the correct receiving warehouse number. Post the GR.
To create and confirm a warehouse task, it must be done for the HUs. Hence, switch to the HU tab and click on create, check the checkbox for immediate confirmation and then save. The system will
create two tasks - one CD task and one Unloading task.
For the outbound delivery, the warehouse task is open and needs confirmation. Thus, click on the additional details button at the item level of the outbound delivery, select the row of the warehouse task,
move to the confirmation view and confirm and save.
In the inbound delivery, on refreshing, the Putaway status which was "Not Started" is now "Completed".
Post the GI for the outbound delivery and the TCD process will be complete once the ERP system is updated of the GM and Warehouse tasks created in the EWM system.
TCD IN A STOCK TRANSPORT ORDER SCENARIO:
Create an STO and a replenishment delivery in the ERP system and distribute it to the EWM system. As done before, assign the route manually and perform the picking (product level and not HU). Pack
the materials by creating an HU and post the GI.
The delivery in the ERP system is updated with the completed GI status. The output type CDOD is processed through transaction VL71. The inbound delivery and the outbound delivery are generated. For
the final delivery, as it a replenishment delivery, the movement type is 641.
In the EWM system, for the inbound delivery created, post the GR and perform the warehouse task for the HU. Again, two will be created - one for unloading and one for CD.
Post the GI for the outbound delivery in the EWM system.
In the TCD Monitor, another inbound delivery can be seen - the delivery generated as a result of the output type SPED from the replenishment delivery.
For the new inbound delivery, in the EWM system, post the GR and create and confirm a warehouse task.
The Purchase Order History in the STO will show the replenishment delivery and the inbound delivery with movement type 641 - which is the inbound delivery at the CD warehouse.
All the deliveries created as a result of the CD process are linked in the table /SPE/CD_DOCFLOW where the entries can be selected using the CD Process number.
The details from this table are used to populate the CD Monitor.
OUTBOUND SCENARIO WITH CRM:
The process begins with the creation of the sales order in the CRM system.
The main transaction used is CRMD_ORDER.
The pushbuttons appearing on the screen can be customized by clicking on Settings.
The most used pushbutton would be ZSPM which is a sales order type.
Click on the ZSPM button and under the General tab, enter the Sold-to-party, Ship-to-party and item details. On hitting enter, a pop up with options regarding the Sales Organization will appear. Select the
Sales Organization and this will immediately lead to a check in the APO system for stock availability. In the APO system, select the stock and click on "Copy All" in the menu.
This pop up appears because under user parameters in System > User Profile > Own Data: the Parameter APO_ATP_PARA is set to value 5.
Save the order.
The sales order will appear - if still in the change mode, switch to the display mode.
In the corresponding ERP system, using transaction VL10UC, convert the unchecked deliveries to checked deliveries.
At the bottom, under the Unchecked Deliveries tab, enter the value for the Reference Document as the Sales Order number from the CRM system.
On executing, an Unchecked delivery will be seen. Select the row and click on "Check and Combine" and now if the UC delivery is looked for in VL03N, it will not be found. It has been replaced by a new
Checked delivery.
Back in the CRM system, on opening the SO, the document flow icon on the top right will be active.
In the ERP system, the program /SPE/OBDLV_LOGFILE_ANALYSE will show the logs of the BDOCs sent and received from the CRM system. The program documentation can be found as a small 'I'
Information icon in the menu.
In order to view the logs, the user parameter must be written under: System > User Profile > Own Data:
The parameter /SPE/IF_OUTB_LOGFILE must be maintained and must have the value "XAB".
On executing the report, fields for selection of the logs are seen. The "Predecessor document number" is the Sales Order number created in the CRM system.
Application Number can be "XA" or "XB". XA is the communication received from the CRM system. Click on execute.
The REQUEST data is the most important as it provides the Ship-to-party and Sold-to-party and other relevant information.
The log details contain a "Reprocess Data" button which is used in case of an error.
On executing the Program with the Application Number XB, the actions performed in the ERP system can be seen. On viewing the details, internal tables that have been updated can be seen.
The tables will show the UC and checked delivery.
In the CRM system, using transaction SMW01, the BDOC messages can be displayed.
In order to process the Checked outbound delivery thus created, the EWM system is needed.
In transaction /SCWM/PRDO, find the outbound delivery and create and confirm the warehouse task (the warehouse task cannot be confirmed directly, hence save it first and then confirm it in the menu -
Warehouse Task > Confirm and then click on "Confirm + Save").
Post the Goods Issue.
This will be reflected in the VL03N in the ERP system.
In the CRM system, view the Sales Order using CRMD_ORDER and click on "Document flow" which shows the Outbound delivery and the material document.
Create a new Sales Order in the CRM system.
A copy button enables creating a similar Sales Order from the one just created.
In the ERP system, enter transaction VL10UC, enter the two Sales Order numbers as reference documents and execute.
Select both the entries - one corresponding to each of the Sales Orders, and click on "Check and Combine".
The two sales orders can be combined as they have the same Sold-to-party.
Check the delivery in the EWM system. The reference documents will be different for each line item. Create and Confirm the Warehouse task and post the GI.
This will be communicated to the ERP system and the Sales order in the CRM system will be updated as well.
BATCH MANAGED MATERIALS:
Create a Sales Order with a batch managed material in the CRM system.
In the ERP system, create a checked delivery with VL10UC.
In the EWM system, find the outbound delivery and create the required batch sub-items. Save the delivery. This should be communicated to the ERP system but not to the CRM system.
In the EWM system, create and confirm a warehouse task and post the Goods Issue.
QUANTITY CHANGES IN THE CRM SYSTEM:
Create a sales order in the CRM system and view the unchecked delivery for this sales order in the ERP system using transaction VL10UC.
If the customer now requests for a change in quantity - switch to change mode in the CRM system, change the quantity and save.
Since the checked delivery hasn't been created or its processing started yet, in VL10UC in the ERP system, the quantity will be updated in a new unchecked delivery.
Create a checked delivery in the ERP system and distribute it to the EWM system.
Now, if the customer changes the quantity again in the CRM system, the sales order cannot be changed as the status of the sales order is already "Completed".
The changing of quantity can be done now only by resetting the status from "Completed" to "In Process".
This must be done at the item level too. Thus select the item to change and at the item level (bottom of the screen), under the Status tab, set the User Status to In Process.
Now the quantity can be changed. Click on save.
In the ERP and the EWM system, the quantity will have changed.
In the SLG1 logs, the messages can be seen.
The FM /SCWM/OBLDV_CHNG_QUAN_MUL is responsible for the quantity change in the EWM system, which is sent from the ERP system.
And the EWM replies to the ERP system with the BAPI_OUTB_DELIVERY_CHANGE queue which updates the quantity in the ERP system. The queue container for this shows under the
HEADER_CONTROL_SPL the field "Initiator" is filled with the value "CRM".
Finally, the CRM system is notified that the quantity has been changed to the new value in both the systems and this can be seen in the Document Flow tab of the item at the item level in transaction
CRMD_ORDER.
In the EWM system, the warehouse task can be created and confirmed.
If the customer needs to further change the order quantity, the process is changed at the header and item level and the quantity is changed.
No quantity update took place in either of the systems.
The EWM system will send a BAPI_OUTB_DELIVERY_REJECT message to the ERP system as a reply to the /SCWM/OBLDV_CHNG_QUAN_MUL message sent from the ERP to EWM system as the
warehouse task has already begun.
A queue might be hanging in the CRM system - SMQ2 - Search with the Sales Order number, if the Sales Order was not switched from the Change mode to the Display mode after modification.
An error message will now appear in the Sales Order in the CRM system top right. This error will show that the quantity change was rejected.
Now the customer must change the status and the sales order quantity to the previous quantity.
The LIPS table stores all the deliveries created for one Sales Order - search with VGBEL field as the Sales Order number.
In the EWM system, if a delivery split is done (after the warehouse task, click on Subitem > Create Subitem for Outbound Delivery Split), an outbound delivery is created for the split item and the Goods
Issue is posted for both the deliveries, the delivery will be created in the ERP system and can be seen in LIPS-VBELN for the Sales Order number in LIPS-VGBEL.
In the CRM system, run the transaction CRMD_ORDER and enter the Sales Order number and navigate to the Document Flow tab. The split delivery will be present.
Note: Batch split items are not updated in the CRM system but a delivery split is updated.
Customizing in the ERP system is maintained by following the path below:
Here the number range can be maintained for the UC deliveries and a flag called "Reuse" which if ticked, the delivery number of the UC delivery that has been deleted can be reused.
No labels
Contact Us SAP Help Portal

Privacy Terms of Use Legal Disclosure Copyright Follow SCN

Outbound Scenarios - Erp SCM - SCN Wiki

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Outbound Scenarios - Erp SCM - SCN Wiki

Hochgeladen von

Copyright:

Verfügbare Formate

1/17/2018 OUTBOUND SCENARIOS - ERP SCM - SCN Wiki

Getting Started Store

ERP SCM / … / Service Parts Management

This creates a credit memo for the customer.

STORAGE LOCATION CHANGE:

The FM responsible for the Posting change is /SPE/GOODSMVT_CREATE.

PARTIAL GOODS RECEIPT:

In the ERP system, the GM status will be 'B' - Partially completed.

BATCH SPLIT MATERIALS:

Create a sales order - VA01

The order type is OR - Standard Order.

Rejecting the Inbound delivery:

To customize the automatic delivery creation settings, follow the path:

1. Auto delivery creation active, change value of KZTLF to B

DIRECT OUTBOUND DELIVERIES:

DELETING A DOD IN THE EWM SYSTEM:

DIRECT DELIVERY WITH STOs:

BILLING LINKED WITH IEW:

It is possible to cancel everything and this is done in the reverse order.

This will be reflected in the document flow of the delivery - VL03N.

IBGI - INVOICE BEFORE GOODS ISSUE:

Billing can be done at two times:

Now, post the Goods Issue.

View the queues corresponding to the delivery in the ERP system.

The second queue will post the Goods Issue.

Define the print profile under the following path:

CUSTOMIZING IN THE EWM:

Include: /SPE/V50SF01 - FORM SPE_OUTB_UPDATE_HEADER; PROGRAM - SAPLV50S

Requirement routine 417 is linked to REA0.

Source code of LV61B417 - Form KOBED_417 - PROGRAM=SAPLV61B

This will assign these deliveries to the previously created TU.

Click on the "Activate" button to activate this TU.

AUTOMATIC BILLING CANCELLATION ON REVERSING THE GOODS ISSUE:

Deregister the queue in the ERP system.

* Not billed yet. -> Nothing to do

SELECT SINGLE spe_inv_gi_rvrs FROM /spe/gi_rvrs_inv INTO ls_inv_gi_rvrs

WHERE fkart = ls_delivery_data-head-fkarv

AND vkorg = ls_delivery_data-head-vkorg.

As a result, the FM /SPE/CANCEL_BILLING_DOCUMENT, which will call BAPI_BILLINGDOC_CANCEL1, is processed.

TRANSPORTATION CROSS DOCKING:

Transportation cross-docking is mainly used to fulfill two business requirements:

In the EWM system, perform the picking and Goods Issue.

It is possible to re-determine the route automatically or to assign it.

Create the warehouse task and confirm it.

Also, the flag MOVE_CD_PLANT_FLG will be set to 'X'.

The different partners with different roles can be seen.

TCD IN A STOCK TRANSPORT ORDER SCENARIO:

Post the GI for the outbound delivery in the EWM system.

OUTBOUND SCENARIO WITH CRM:

The main transaction used is CRMD_ORDER.

The pushbuttons appearing on the screen can be customized by clicking on Settings.

Save the order.

The tables will show the UC and checked delivery.

Post the Goods Issue.

Create a new Sales Order in the CRM system.

BATCH MANAGED MATERIALS:

In the ERP system, create a checked delivery with VL10UC.

QUANTITY CHANGES IN THE CRM SYSTEM:

Now the quantity can be changed. Click on save.

In the SLG1 logs, the messages can be seen.

No quantity update took place in either of the systems.

Contact Us SAP Help Portal

Das könnte Ihnen auch gefallen