GR (MIGO) for Inbound Dely Containing HU

Hi
I am trying to create GR for Inbound Dely containing the HU through MIGO and not VL32n , it is throwing the error
Packing can only be updated via inbound delivery dialog
Message no. VLA311
We are into ECC 6.0 and it seems that SAP NOte 1384533 has already been implemented , but still I dont see the VLA 311 message in System Messages under the Logistic Execution path of SPRO.
I have been reading the SAP Note 199703, but when I set the GR Assignment field of the Conf Control to blank and remove the movt type for Dely Item Cat ELN , it doesnt allow me to create HU in the Inb Dely, although it allows me to create a GR for the Inbound Dely through MIGO .
Can you please help me in overcoming the prob.
REgards,
Binayak

Hello Diwakar,
I checked the settings as you suggested.
1. Goods Receipt for Inbound delivery is active with mvt type 101 in the Enjoy transaction config
2. For ELN Delivery item category, the 'No Batch Check' check box is flagged. This I think is right because the batch will not exist at the time of inbound delivery creation. Hence we have to set this flag. This is as per the standard SAP documentation for this flag
ID: No batch check
Controls whether the system checks that the batch entered in the delivery exists.
Procedure
If you do not want the system to check the batch, select the field.
Use
It makes sense not to carry out a check if the batch entered does not (or does not yet) exist in the system. This happens, for example, when you create an inbound delivery. The same applies if you use work with the R/2-R/3 link and the batch only exists in the local system.
I have created an OSS message and will wait for SAP to answer this. Meanwhile thanks a lot for all your help and guidance.
regards
Venkat

Similar Messages

SAP System inconsistency for Inbound delivery / MIGO and a "sap note"

Hello Friends ,
After following SAP instruction on how to remove the inconsistency between posting GR through MIGO (Inv. mang.) and the reflection of the goods movement status in the inbound delivery document - done that using sap note 570991
the problem is that the system start behaving in a weird way throwing unjustified Error messages for any suggested goods receipt using MIGO with reference to inbound
for example after creating an inbound delivery document and trying to post it via migo , an error will pop up
- Inbound delivery storage location cannot be changed to here Message no. VLA316
the thing is i didn't even maintain any storage location entry up to that point and yet i cannot post any stock !!
also another error like
- Inbound delivery batch cannot be changed to *** here
which doesn't make any sense because there is not batches in the inbound document !!
i think this behavior is coming from the "Document Flow Update for Stock Postings" inbound indicator at the shipping parameter at client level customization
i need help on how to overcome this annoying SAP Bug/Problem specially i am in a post go live critical situation

Hi,
The messages you mentioned were introduced to avoid inconsistency between inbound delivery and IM, through the note: 1050944 - GR for inbound delivery using inventory mgmt as of ECC 6.00
If the messages are issued incorrectly, then you may check for SAP notes (I couldnt find anything relevant) or raise an OSS ticket to SAP.
Regards,
AKPT

Error while posting MIGO for HU-Inbound Delivery

Hi All
When am trying to post the MIGO for HU Inbound Delivery Creation, am getting an error saying "Required parameters missing when calling up module MARV_SINGLE_READ".
Following areas I have verifed:
The posting periods in MMRV shows current period.
The Number range for HU ID and Delivery type HID is maintained.
Now am looking for your expert opinion to resolve this issue.
Regards
K. Viswanathan

Are you getting the same error in transaction MB1C to create the delivery.Try in MB1C

Goods Receipt for Inbound Delivery through MIGO

Hi All,
Can anyone pl. explain me in steps the process of GR for Inbound Delivery from MIGO transaction.
Also I need the process of reversing this goods receipt done.
For certain inbound deliveries a dump occurs in the program SAPLIE01 in 'EQUIPMENT_ADAPT_BUSVIEWS' fn module.
I need to analyse the reason for the dump. Here is the extract from the dump
<b>IF WA_EQUI IS INITIAL
keine Equidaten vorhanden => EXCEPTION
---> RAISE ERR_ADAPT_BUSVIEWS . ENDIF. </b>
Advance Thanks

Hi Sanjay and Srikanth,
Thank you for the correction. I was just wondering over this number.
Sanjay, regd the release level, it is 0017 for SAP_APPL.
In brief, when GR is done for an inbound delivery, a fn moudle equipment_adapt_busviews is called, in which if the equipment data of the material (wa_equi) is initial, it gives dump.
1. This fn module is called 3 or 4 times while the posting is done through MIGO
2. In the 4th call, the parameter wa_equi is initial - which gives the dump.
3. While debugging, when I reach this point,if I restart the debugging, I find that the posting is completed !!!! (so something happening after posting of GR gives the dump)
4. I have to reverse this GR for replicating the same again.
Any further clues !!
Regards
Aadarsh

No MIGO for PO

Hi Gurus,
I have created a PO and released it.. now when i am doing MIGO.... the systems says the PO has no items...
plz guide me whats the reason for this...
cheers

Hi,
Check in the PO Confirmations tab. If it is set as Inbound delivery, create Inbound delivery and make GR for Inbound delivery.
Also check in MIGO screen for default Mvt type for Goods Reciept-- PO/ Inbound Delivery. It should be 101.
Umakanth R
Edited by: Umakanth R on Dec 9, 2010 2:24 PM

Confirmation control key check for inbound delivery creation

Hi,
Currently, in the Client's company, the process of receiving goods from purchase orders looks like that (SAP-wise):
- create a purchase order,
- receive goods using MIGO and automatically create an inbound delivery,
- pack the delivery and post goods receipt.
Recently, some patches have been installed, including one described by note 1602047 (which basically enforces checking confirmation control keys if goods receipt assignment and goods receipt relevance are activated for inbound deliveries). Note says that it only affects two-step stock transfer and creation of automatic inbound deliveries using SPED output but it seems it also affects other basic processes like PO receipt in MIGO.
Now, when using the old control key (that had MRP-Relevant and GR-Relevant fields checked), the system is unable to automatically create an inbound delivery after the goods receipt is posted with MIGO (with message VL148 - Not possible to create an inbound delivery). I learned that this is because the "GR Assignment" field must be checked in the confirmation control key so it's possible to automatically create aninbound delivery after receiving a purchase order in MIGO.
After changing the confirmation control key to have the missing field checked it's not possible anymore to receive goods from PO in MIGO as the PO requires shipping notification in order to be processed in MIGO thus requiring of manual creation of an inbound delivery.
Is there any way to skip this check so the process would remain the same (this model has been working fine for few years in the Client's system) and the inbound delievery would be created automatically after posting the receipt in MIGO?
Thanks in advance,
Piotr

Hi,
don't know if you found a solution, but we received the following message from SAP:
The advent of the new version requires some attention to the users. It
was necessary to avoid inconsistencies which in the past version the
system was susceptible.
Main Program SAPMM07M
Source code of MM07MLVS
sy-msgid VL sy-msgty E sy-msgno 148
I have checked the process and through debugged I could confirm the
following information SAP is providing to all similar incidents reportedfor us:
Error message VL 148 is issued if in the confirmation control key used
in the purchase order, the fields for MRP-relevance (T163G-KZDIS),
GR relevance (T163G-WEREL) and GR assignment indicator (T163G-WEZUO)
are not set.
The correction of note 1602047 was necessary to avoid inconsistencies
(table EKES) in the purchase order. Without having the GR assignment
(T163G-WEZUO) set, there is no unique reference created between the
purchase order history (table EKBE) and the inbound delivery
confirmation (table EKES) at goods receipt which leads to a problem if
several inbound deliveries exist for the same purchase order.
If you set T163G-WEZUO to 'X', this assures that, for an inbound
delivery, the confirmation record (EKES) belonging to this inbound
delivery (EKES-VBELN) is also accurately updated at goods receipt.
How to solve the issue?
Use a confirmation control key with the GR assignment indicator set
and then create the inbound delivery with VL31N. If you want to be able
to create the inbound delivery with reference to a certain line item in
the PO, use transaction VL34.
If you still want to use transaction MIGO, there is the following
workaround:
- Create a purchase order without any confirmation control key
- Create a goods receipt (GR) in transaction MIGO with reference to this PO and post the GR to a non-HU-managed storage location
- Create a transfer posting with MIGO using movement type 311 to
transfer the goods from the non-HU-managed storage location to the
HU-managed storage location.
As the transfer posting is an additional step for the user, the whole
process could be automated using a partner storage location
(T001l-PARLG) for the GR which then triggers (through a modification)
the BAPI 'BAPI_GOODSMVT_CREATE' to create the transfer posting without
user interaction.
I hope to have satisfied you on the reason why it is now happening and
also I believe you can explain to business that it is a new behavior
necessary done from SAP side to avoid worse situations, we are aware of
potential dissatisfaction it might cause. SAP Support is always
available to clarify any issue.
Sorry for not having a more positive answer.
I hope it helps!
Leentje

Goods Receipt is allowed through MIGO for PO's though they hav the confirm

Goods Receipt is allowed through MIGO for PO's though they hav the confirmation control key. where as its should allow based on ASN(inbound Delivery).
Not sure if any system changes has to be made or anything else. please suggest.
Thanks

Hi Dear <
You can also recived the goods with reference to inbound Delevery,
1 Select In Confirmation Tab Con con key while in Creating PO
2 Create a Inbound delevry from T.code: VL31n
3 Once you create the Inbound delevery wth reference to PO, The inbound delevery no will be propulated in Confirmation Tab of PO
4 you can Do the mIGO with reference to that Inbound delevery

Post Goods Receipt for Inbound Delivery using WHSCON IDoc

Dear All
Currently I am working on a big project dealing with EDI connections to our logistics partner for the Export business. The entire message flow between Lindt and our partner should be via EDI. Our SAP release is (still) 4.6c.
We will create two kinds of despatch advice messages, one for inbound deliveries and one for outbound deliveries for customers.
I would appreciate your support in the following problem that I am facing with the inbound delivery scenario:
We create stock transport orders (purchase orders, POs) for the goods intended to be delivered into the plant at our partner
We create a delivery (type NL = replenishment delivery) for this POs
As soon as we post the goods issue we send the despatch advice (as EANCOM D96A DESADV message) to our partner.
At this point the delivery is basically completed, i.e. packing status (PS) and goods movement status (GM / GS) are equal to 'C' (= completed).
Our logistics partner uses the same EDI message to send us the goods receipts data, e.g.:
We dispatched 50 units of a product => QTY:50:12
The partner received indeed 50 units => QVR:50:66
Please note that we do not use the QVR segment for the quantity difference (between despatched and received quantity) but it contains the received units. This way we avoid negative values in the QVR segment.
When the logistics partner sends back the DESADV message containing the received quantities (QVR segment) we want to make
the goods receipts for the products in the original stock transport order and
upate the message flow in the delivery
My idea was to transform the incoming DESADV message into a WHSCON.DELVRY03 IDoc based on the documentation in: [Delivery Interface|http://help.sap.com/saphelp_crm40/helpdata/en/e2/654b15a9f411d184ec0000e81ddea0/content.htm]
In the delivery header control E1EDL18 I used QUALF = 'PGI' (Post goods issue).
I prepared an inbound WHSCON IDoc according to the documentation mentioned below. I managed to get some feedback from the Idoc processing implying that the system tried to do the goods receipt in the PO but failed.
To make a long story short here are my questions:
Can an inbound WHSCON IDoc used for doing both the goods receipt in the PO and the update of the message flow in the delivery?
Does anybody have an example on how to fill the WHSCON IDoc?
Or is my approach a cul-de-sac ?
Kind Regards
Uwe
PS: A related question can be found here: Goods Receipt in PO AND Message Flow Update in Inb. Delivery using WMMBXY

Hi Uwe,
Can an inbound WHSCON IDoc used for doing both the goods receipt in the PO and the update of the message flow in the delivery?
The binary answer would be no. You should use WMMBXY or MBGMCR instead.
But if we are doing goods receipt against Inbound delivery then answer is YES with additionally E1EDL18-QUALF = 'PIC' populated. But please remember no partial receipt is possible against Inbound Delivery.
We should populate E1EDL20-VBELN with our Inbound delivery number and line item info should go to E1EDL24.
I have done a similar interface recently where we are doing receipt against Inbound delivery. But our case was a bit complex because we had to support against Inbound delivery. So we had to go for a custom solution on top of IDOC_INPUT_DELVRY.
Hope this helps. Let me know if you have more questions.
Regards,
Rudra

Idoc DELVRY03/DESADV for Inbound delivery with serial number

Hi,
We have set up am EDI process between our vendors ERP system and our SAP. We will send purchase order Idocs to our vendor, once our vendor has shipped the goods (to our customer) he send an DESADV/DELVRY03 Idoc back to our system. This Idoc will create a statistical inbound delivery and a statistical goods receipt will be automatically created in our SAP system.
This process runs fine as long as we use materials without serial numbers. Unfortunately we have some materials which need to have a serial number assigned by our vendor and we want to keep track of this information in our SAP system.
The only place where I found a serial number field in the Idoc is in the 'E1EDL46 : Serial Numbers HU' segment in the DELVRY03 Idoc, but unfortunately we don't have handling units activated in our SAP system. So if we fill this information the Idoc processing fails.
Is there any other way to create an inbound delivery containing serial number information without activating handling units?
Thanks for your help,
Frank

Hi,
is there anyone who has experience with EDI inbound delivery postings containing serial number information?
Thank you,
Frank

Step-by step procedure for INBOUND IDOC (VENDOR CREATE / CHANGE)

Hi ,
Can any body provide me the step-by-step procedure for Inbound IDOCS.
As i'm new to this i need the the clarification between Inbound & outbound idocs.
How can we differentiate both?
where to define outbound & where to define Inbound?
( If possible Please explain me the procedure for Vendor Create through INBOUND IDOCS )
Thanks in advance..

Hi,
Ale Technology is SAPu2019s technology to support distributed yet integrated processes across several SAP systems.
Outbound Process:
ALE Outbound Process in SAP sends data to one or more SAP Systems. It involves four steps.
1. Identify the need of IDoc: This step starts upon creating a application document, can relate to a change to a master data object.
2. Generate the Master IDoc: The document or master data to be sent is read from the database and formatted into an IDoc format. This IDoc is called as a Master IDoc.
3. Generate the Communication IDoc: The ALE Service layer generates a separate IDoc from the Master IDoc for each recipient who is interested in the data. Separate IDocs are generated because each recipient might demand a different version or a subset of the Master IDoc. These recipient-specific IDocs are called Communication IDocs and are stored in the database.
4. Deliver the Communication IDoc: The IDoc is delivered to the recipients using an asynchronous communication method. This allows the sending system to continue its processing without having to wait for the destination system to receiver or process the IDoc.
Inbound Process:
The inbound process receives an IDoc and creates a document in the system.
1. Store the IDoc in the database: The IDoc is received from the sending system and stored in the database. Then the IDoc goes through a basic integrity check and syntax check.
2. Invoke the Posting Module: The control information in the IDoc and configuration tables are read to determine the posting program. The IDoc is then transferred to its posting program.
3. Create the Document: The posting program reads the IDoc data and then creates a document in the system. The results are logged in the IDoc.
Over view of IDocs:
IDoc is a container that is used to exchange data between any two processes. The document represented in an IDoc is independent of the complex structure SAP uses to store application data. This type of flexibility enables SAP to rearrange its internal structure without affecting the existing interface.
IDoc interface represents an IDoc Type or IDoc data. IDoc Type represents IDocu2019s definition and IDoc Data is an instance of the IDoc Type.
IDoc Types:
IDoc type structure can consist of several segments, and each segment can consist of several data fields. The IDoc structure defines the syntax of the data by specifying a list of permitted segments and arrangement of the segments. Segments define a set of fields and their format.
An IDoc is an instance of an IDoc Type and consists of three types of records.
i. One Control record: each IDoc has only one control record. The control record contains all the control information about an IDoc, including the IDoc number, the sender and recipient information, and information such as the message type it represents and IDoc type. The control record structure is same for all IDocs.
ii. One or Many Data records: An IDoc can have multiple data records, as defined by the IDoc structure. Segments translate into data records, which store application data, such as purchase order header information and purchase order detail lines.
iii. One or Many Status records: An IDoc can have multiple status records. Status record helps to determine whether an IDoc has any error.
Message in IDoc Type:
A Message represents a specific type of document transmitted between two partners.
Outbound Process in IDocs:
Outbound process used the following components to generate an IDoc. A customer model, and IDoc structure, selection programs, filter objects, conversion rules, a port definition, an RFC destination, a partner profile, service programs, and configuration tables.
The Customer Model:
A customer model is used to model a distribution scenario. In a customer model, you identify the systems involved in a distribution scenario and the message exchanged between the systems.
Message control:
Message control is a cross application technology used in pricing, account determination, material determination, and output determination. The output determination technique of Message control triggers the ALE for a business document. Message control separates the logic of generating IDocs from the application logic.
Change Pointers:
The change pointers technique is based on the change document technique, which tracks changes made to key documents in SAP, such as the material master, customer master and sales order.
Changes made to a document are recorded in the change document header table CDHDR, and additional change pointers are written in the BDCP table for the changes relevant to ALE.
IDoc Structure:
A message is defined for data that is exchanged between two systems. The message type is based on one or more IDoc structures.
Selection Program:
Is typically implemented as function modules, are designed to extract application data and create a master IDoc. A selection program exists for each message type. A selection programu2019s design depends on the triggering mechanism used in the process.
Filter Objects;
Filter Objects remove unwanted data for each recipient of the data basing on the recipients requirement.
Port Definition:
A port is used in an outbound process to define the medium in which documents are transferred to the destination system. ALE used a Transactional RFC port, which transfers data in memory buffers.
RFC Destination:
The RFC destination is a logical name used to define the characteristics of a communication link to a remote system on which a function needs to be executed.
Partner Profile:
A partner profile specifies the components used in an outbound process(logical name of the remote SAP system, IDoc Type, message type, TRFC port), an IDocu2019s packet size, the mode in which the process sends an IDoc (batch versus immediate), and the person to be notified in case of error.
Service Programs and Configuration Tables:
The outbound process, being asynchronous, is essentially a sequence of several processes that work together. SAP provides service programs and configuration tables to link these programs and provide customizing options for an outbound process.
Process flow for Distributing Transactional Data:
Transactional data is distributed using two techniques: with Message control and without message control.
Process flow for Distributing Master Data:
Master data between SAP systems is distributed using two techniques: Stand alone Programs and Change Pointers.
Triggering the Outbound Process via Stand-Alone Programs:
Stand-Alone programs are started explicitly by a user to transmit data from one SAP system to another. Standard Programs for several master data objects exist in SAP. Ex. The material master data can be transferred using the RBDSEMAT program or transaction BD10.
The stand-alone programs provide a selection screen to specify the objects to be transferred and the receiving system. After the stand-alone program is executed, it calls the IDoc selection program with the specified parameters.
Triggering the Outbound Process via Change Pointers:
The change pointer technique is used to initiate the outbound process automatically when master data is created or changed.
A standard program, RBDMIDOC, is scheduled to run on a periodic basis to evaluate the change pointers for a message type and start the ALE process for distributing the master data to the appropriate destination. The RBDMIDOC program reads the table TBDME to determine the IDoc selection program for a message type.
Processing in the Application Layer:
The customer distribution model is consulted to make sure that a receiver has been defined for the message to be transmitted. If not, processing ends. If at least one receiver exists, the IDoc selection program reads the master data object from the database and creates a master IDoc from it. The master IDoc is stored in memory. The program then calls the ALE service layer by using the function module MASTER_IDOC_DISTRIBUTE, passing the master IDoc and the receiver information.
Processing in the ALE Interface Layer:
Processing in the ALE Layer consists of the following steps:
u2022 Receiver Determination: The determination of the receiver is done through Customer Distribution Model.
u2022 IDoc Filtering: if an IDoc filter is specified in the distribution model for a receiver, values in the filter are compared against the values in the IDoc data records. If a data record does not meet the filter criteria, it is dropped.
u2022 Segment Filtering: For each sender and receiver combination, a set of segments that are not required can be filtered out.
u2022 Field conversion: Field values in data records are converted by using the conversion rules specified for the segment.
u2022 Version change for segments: Segments are version-controlled. A new version of a segment always contains fields from the preceding version and fields added for the new version. Release in IDoc type field of the partner profile to determine the version of the segment to be generated.
u2022 Version change for IDocs: IDocs are also version controlled. The version is determined from the Basic Type field of the partner profile.
u2022 Communication IDocs generated: The final IDoc generated for a receiver after all the conversions and filtering operations is the communication IDoc. One master IDoc can have multiple communication IDocs depending on the number of receivers identified and the filter operations performed. IDoc gets the status record with a status code of 01 (IDoc Created).
u2022 Syntax check performed: IDoc goes through a syntax check and data integrity validation. If errors found the IDoc get the status of 26 (error during syntax check of IDoc u2013 Outbound). If no errors found the IDoc gets the status 30 (IDoc ready for dispatch u2013 ALE Service).
u2022 IDoc dispatched to the communication Layer: In the ALE process, IDocs are dispatched using the asynchronous RFC method, which means that the sending system does not await for data to be received or processed on the destination system. After IDocs have been transferred to the communication layer, they get a status code 01 (Data Passed to Port OK).
Processing in the Communication Layer:
To dispatch an IDoc to a destination system, the system reads the port definition specified in the partner profile to determine the destination system, which is then used to read the RFC destination. The RFC destination contains communication settings to log o to the remote SAP system. The sending system calls the INBOUND_IDOC_PROCESS function module asynchronously on the destination system and passes the IDoc data via the memory buffers.
Inbound Process in IDocs:
An inbound process used IDoc structure, posting programs, filter objects, conversion rules, a partner profile, service programs, and configuration tables to post an application document from an IDoc.
Posting Program:
Posting programs, which are implemented as function modules, read data from an IDoc and create an application document from it. A posting program exists for each message. Each posting program is assigned a process code. A process code can point to a function module or a work flow. In the standard program process codes always point to a function module.
Ex. The posting program for message type MATMAS is IDOC_INPUT_MATMAS which has a process code MATM.
Workflow:
A workflow represents a sequence of customized steps to be carried out for a process. The workflow management system is used to model the sequence, identify information required to carry out the steps and identify the person responsible for the dialog steps.
Partner Profile;
A partner profile specifies the components used in an inbound process (partner number, message type, and process code), the mode in which IDocs are processed (batch versus immediate), and the person to be notified in case of errors.
Process flow for the Inbound process via a Function Module:
In this process, IDocs are received from another system and passed to the posting function module directly.
1. Processing in the communication Layer:
The IDOC_INBOUND_ASYCHRONOUS program, triggered as a result of an RFC from the sending system, acts as the entry point for all inbound ALE processes. The IDoc to be processed is passed as an input parameter. Control is transferred to the ALE/EDI layer.
2. Processing in the ALE/EDI Interface Layer:
u2022 Basic integrity check: A basic integrity check is performed on the control record.
u2022 Segment Filtering and conversion: Filtering out unwanted segments and carry out any required conversion of field values.
u2022 Creation of Application IDoc: The application IDoc is created and stored in the database and a syntax check is performed. If there are errors it gets status code of 60 (Error during Syntax check of IDoc u2013 Inbound). At this point a tangible IDoc, which can be monitored via one of the monitoring transactions, is created and the IDoc gets status code 50 (IDoc Added).
u2022 IDoc Marked ready for Dispatch: IDoc gets the status code 64 (IDoc ready to be passed to application).
u2022 IDoc is passed to the posting program: The partner profile table is read. If the value of the Processing field is set to Process Immediately, the IDoc is passed to the posting program immediately using the program RBDAPP01.
3. Processing in the Posting Module:
The process code in the partner profile points to a posting module for the specific message in the IDoc. The posting program implemented as a function module either calls a standard SAP transaction by using the Call Transaction command for posting the document or invokes a direct input function module.
The results of execution are passed back via the function moduleu2019s output parameters. If the posting is successful IDoc gets the status code 53 (Application Document Posted) or it gets status code 51 (Error: Application Document Not Posted).

BAPI for inbound delevery (VL31N)

Hi Gurus,
I want to create inbound delevery (VL31N). I am getting an inbound IDOC containing ASN details.
Is there any BAPI which can create inbound delevery?
Thanks in advance.
Srimanta

Hi,
Refer the link
BAPI for VL31N:Create Inbound Delivery
DATA: IS_INB_DELIVERY_HEADER LIKE BBP_INBD_L.
IS_INB_DELIVERY_HEADER-DELIV_EXT = 12121
IS_INB_DELIVERY_HEADER-DELIV_DATE = 08/16/2006
DATA: T_DETAIL LIKE LIKE BBP_INBD_D OCCURS 0 WITH HEADER LINE.
T_DETAIL-MATERIAL = 'xxx'.
T_DETAIL-DELIV_QTY = '10.000'.
T_DETAIL-UNIT = 'EA'.
T_DETAIL-PO_NUMBER = '45XXXXXX.
T_DETAIL-PO_ITEM = '000010'.
APPEND T_DETAIL.
DATA: T_RETURN LIKE BAPIRETURN OCCURS 0 WITH HEADER LINE.
DATA: V_VBELN TYPE VBELN_VL.
CALL FUNCTION 'BBP_INB_DELIVERY_CREATE'
EXPORTING
is_inb_delivery_header = is_inb_delivery_header
IMPORTING
EF_DELIVERY = V_VBELN
tables
it_inb_delivery_detail = T_DETAIL
return = T_RETURN
Hope it helps
Regards
Sumana

Issue to make mandatory field(SELD/BBD and Date of manufactor)in migo for particular Material type and material Number starting with'1' series.

Hi friend,
i have issue regarding mandatory self life field (SELD/BBD and Date of manufactor)in migo for Batch Tab for particular Material start with '1' Series and material type.
i want to make mandatory above field during GR from migo..any one let me know exit or badi for that to full fill this goal..
Regard's,
shaikh Khalid.

Hi Shaikh
First of all Thread is not closed seconldy as a good practice if you have resolved your issue kindly document it here so that it may help someone in future
Nabheet

Automatic TO Creation for Inbound Deliveries

I would like to have TO created automatically for Inbound delivery for PO.
1) I have set the Automatic TO = A in Mvmt Type 101 for my warehouse in transaction OMKZ.
2) I have set Immediate TO Creation and Mail Control = A for Mvmt Type 101, Mvmt Indicator =B, Mvmt Type 101, TR Create =X for my warehouse in transaction OMKX
3) I have assigned Routine #32 to Application E1 in transaction VOFM
4) I have created output conditon WMTA for delivery type EL with Medium =8 and Date/Time =4.
Tranfer order is not created when the delivery is created via transaction VL34. The output determination analysis indicates that WMTA was ignored because requirement 032 not fulfilled. What am I missing?
Thank you.

Hi Julie Simonds
I believe you are working with Inbound delivery with Item catagory as ELN.
Please check if Relevant for putaway is checked.
Path for your refernce :
SPRO > LE > Shipping > Deliveries > Define Item catagory for deliveries.
Thanks,
Mahesh

New Condition TAble for Inbound Delivery

Hello
i want to maintain a new Condition table for the Inbound delivery picking with the combination of _Delivery type/Plant
so that the Inbound created for the particular plant alone uses the particular output type.
Where in IMG can i configure the new Condition table for this combination for the Inbound delivery ?

Hi,
Go to SPRO > Logistics Execution > Shipping > Basic Shipping Functions > Output Control > Output Determination > Maintain Output Determination for Inbound Deliveries > Here perform following;
- Define Condition Table for Inbound Delivery
- Define Output Types for Inbound Delivery
- Define Access Sequence for Inbound Delivery
- Maintain Output Determination Procedure
- Assign Output Determination Procedures

Capture of excise invoice in MIGO for depot

Hi,
We have one depot plant as per regular process we do the GR with MB01 and then J1IG for capturing of excise duty which update the RG23D entry, now i want to know what is the difference if we do this in MIGO so that both this can be done in same transaction I try in development server by first selecting the check box for capture excise invocie in MIGO for the depot plant then made one entry in MIGO but found that the field SHIPFROM in table J_1IRG23D is coming blank when done with MIGO so is there any differecne in thos two J1IG and MIGO create RG23D entry aslo the vendor from which we are purchasing the material is also a trader who is passing the excise duties which they paid and the same amount we have to split in MIGO but I have not found the MRP indicator in excise ->misc. tab in MIGO.
regads,
zafar

Hi,
Can you help on this, I am not getting the MRP indicator in MIGO for the material, what settings are required for this the J1ID the vendor is selected as first stage dealer.
regards,
zafar

GR (MIGO) for Inbound Dely Containing HU

Similar Messages

Maybe you are looking for