Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
sap_pp13
Active Contributor

  This is in continuation of the document ‘Serial Numbers with specific reference to Production & Goods Movements - Part 1’ shared earlier in the documents section of the same community forum. This continuing part is aimed at explaining all goods movements that happen w.r.to serialized materials based on MMSL, the mother of all Serializing procedures.

The document covers Goods Movement of Serialized materials with

A. Picking transactions (CO27/MB26) and related COGI errors seen with MB26,

B. Production Order Confirmations (CO11N),

C. Material Master related impacts,

D. MIGO errors for Serialised components and

E. Serialized Components in Subcontracting.

A. With Picking Transactions:

Some Companies use picking activities via CO27/MB26 and make the components available before commencing actual production where as some do not have the necessity for picking before commencing the production. As it is known CO27 will not generate any post-processing error records and MB26 will.

We will have a look at the system behavior whilst using CO27/MB26 Picking transactions while dealing with Serial numbers and the subsequent COGI error records for the below two scenarios while using MB26 tcode with the different config permutations/combinations possible.

Scenario 1:

  1. Material:SNZ003 with Z003 serial profile

OIS2 MMSL for Z003 profile is 03 (Obligatory)

No Exception Config in place.

I. Using CO27 transaction:

Profile: 000002

Under Selection at header level

Material: SNZ005 (which is the parent of material SNZ003)

Plant: 0150

When MMSL in OIS2 is set as 03 Mandatory for a profile, CO27 does not show any components having that profile as relevant for picking.

Note: a. In CO27, the standard pick profile 000002 does not show the field Serial No. Profile. The KOMM transaction (Customizing Pick list config) has been modified accordingly to display the field in the demo as above.

         b. Z006/Z007 profiles are with MMSL 01 and hence the relevant components are displayed in addition to a non-serialised component in screen shot as above.

II. MB26 transaction:

Under Selection from Reservations tab: For the input criteria, Material as SNZ003 and Plant as 0150 and Additional Selection criteria left unchecked,

On executing,

On Saving, We get a popup as below:

Clicking on Yes,

Highlighting the line item and clicking on Display Error, We get to see the message:

Maintain serial numbers for total quantity

Message no. M7175

There is no provision in MB26 to enter the serial numbers anyway and we need to post this component only using MIGO or MB1A.

We repeat the above process and in the popup if we say NO,

Goods movements posted: 0, Incorrect: 0

If we check in COGI we do not see any error records either.

We repeat the above procedure and at the very first instance of choosing between Yes or No in the dialog box we click on NO.

The status bar shows the message ‘Goods movements posted: 0, Incorrect: 1’.

Inspite of this message that Incorrect:1, an error record is not written and cannot be seen in COGI and when we execute MB26 again the same record appears again.

What we observe is when we try to correct the error and when we cannot when we try to return back clicking on NO option we end up seeing the status bar message with Incorrect:0

And when we try to exit immediately with a No option in the first instance we get a status bar message showing Incorrect:1

In either cases above we do not see the COGI error record written over.

In the SAP standard, the system does not write an error record for a serialised component with this configuration setting in MB26. (This behaviour is Confirmed in SAP Note 630888).

Do It Yourself (DIY):

  1. Try the various input selection criteria under ‘Selection from Reservations’ like Reservation number/MRP controller for instance and check the results.
  2. Under ‘Selection of Orders’ try the various selection criteria and identify the system behaviour. See if results are similar to the ‘Selection from Reservations’ or not.

III. MB26 transaction: For the input criteria, Material as SNZ003 and Plant as 0150 and Additional Selection criteria Checked ON,

There is a provision to select with out serialised components in MB26 transaction and the selection does not return any results.

Scenario 2:

  1. Material:SNZ003 with Z003 serial profile

OIS2 MMSL for Z003 profile is 02 (Optional)

(Compared to previous scenario, the Exception config setting becomes Mandatory and the OIS2 setting becomes Optional).

Then in the subsequent Serialisation attributes Config under Flow type groups, We maintain the SerUsage as 03 for Z003 profile.

CO27 transaction:

Profile: 000002

Under Selection at header level

Material: SNZ005 (which is the parent for SNZ003)

Plant: 0150

We can see the Z003 profile component displayed in the picking list.

Try to pick the component.

Clicking on Post, We get a popup message,

And the message is

'Serial number obligatory material SNZ003 cannot be updated'

Message no. IO262

On clicking enter as above we are returned to the initial screen with the status bar message displaying ‘1 goods movements were deleted’.

MB26 transaction:

Material-SNZ003, Plant-0150 and the Without Serialised materials indicator = Blank.

Clicking on Save,

Selecting Yes, we get to see the error message

Maintain serial numbers for total quantity

Message no. M7175

Click on Back icon now.

If we click on No, we end up in the initial screen with no status bar message.

Repeating the process as above, and when we say No to correcting the errors, we get the message as

Goods movements posted: 0, Incorrect: 0

In spite of Incorrect:0, We now end up seeing the error record in COGI with the M7/175 message.

Details are as follows:

Again the record cannot be update from COGI and lies there permanently unless we manually delete it. It should be noted that the Requirement quantity is 1 EA in our case and we can see that the Quantity withdrawn is zero.

Do It Yourself (DIY): 1. Again for a case like Incorrect:1 which we land when we click on No option at the very first instance in MB26 transaction check if it also yields same results.

        2. Try to think and ascertain on the error message saying Incorrect:0 but still the error records sent to COGI.

Message is we cannot do a GI with the serial number config setting maintained.

Normally when we try to a do a GI for this component using MIGO we can post it successfully.

If we want to trap the post processing error records and be identified by MIGO, we need to set the OMCQ transaction message M7/398 as W/E.

By default the Cat field is blank for this message and we set it as E.

We try to do a GI using MIGO now.

Error message prevents us from doing the issue.

Double clicking on the status bar message we get to see

Diagnosis

You are posting a goods issue for an order.

The system has noticed that there are already post-processing records for this order. These might have come from picking using transaction MB26.

We revert back to the default status of OMCQ M7/398 as blank and proceed further.

     We maintain the serial number for the component during GI and the check shows that everything is OK.

We click on Post now.

The GI is successful and the material document is successfully posted.

Check whether the COGI records has been cleared.

Error record still exists and has not been cleared.

Details of the record now shows that the requirement qty and the withdrawn qty are equal after the MIGO posting.

The message is that the M7/175 entry cannot be cleared after a successful posting.

Now click on save icon in COGI. We get the message,

0 goods movements have been successfully executed

The error record still exists but the error message has now been updated as M7/362 (RE Reserved quant. exceeded by 1.000 EA : SNZ003 0150 MAIN).

The same has to be cleared manually by deleting the same in COGI.

All results w.r.to Picking transactions can be documented in the below format:

MMSL procedure OIS2 setting

Exceptions Configuration

CO27

Is Component  proposed and Can we have a GI posting?

MB26

(Serialised indicator NOT ON)

MB26

(with serialised indicator ON)

01

NO

Yes & Yes

Yes and Yes

Yes and Yes

02

NO

Yes & Yes

Yes and Yes

Yes and Yes

03

NO

NO and hence NO

  1. GI posting does not go through when we choose Yes with a M7 175 error. If No, no error is created and just returns to initial status.

NO and hence NO

02

Yes with 261 mvt type – SN03 -03(Mandatory)

Yes proposed.GI fails with IO262 message

  1. GI on Save 1.No-COGI error. 2. Yes .Then No again also COGI error.

03

Yes with 261 mvt type – SN03 -03(Mandatory)

NO and hence NO

  1. GI on Save 1.No-No COGI error. 2. Yes .Then No again also No COGI error

NO and hence NO

Repeat for other combinations also and document your results

Learnings:

  1. In the Parameters for OPK4 transaction (OPK4), Under Goods Movements, Check the All Components indicator ON. During confirmation check for the impact - Whethersystem picks up Serialised components or not?

B. CO11N impacts: (With specific reference to GR)

Only operation of the Production order has a control key supporting Auto-GR.

OIS2 MMSL setting for the profile of I/H item SNZ005:03/Mandatory

In CO11N:

Even though the Auto GR is set, as the Header material SNZ005 is serialised, it has been filtered out and a blank Goods Movement overview screen is

displayed.

MIGO transaction: Shows that GR can happen successfully.

Change: OIS2 MMSL setting for the profile of I/H item is changed now to either 01/None or 02/Optional

In CO11N, the material/assembly gets displayed.

And the GR happens successfully as it is optional and/or None.

Myth/Incomplete Statement: A Serialised material cannot have auto goods receipt associated to it.

Truth/Complete Statement: A Serialised material cannot have auto goods receipt associated to it as long as the Serial number usage is mandatory in the serialised profile or in the exception configuration, as the case may be.

Or any Serialised material with Serial number usage as None or Optional can still have auto goods receipt associated with it.

C. Material Master Impacts during deletion/change of Serial Number Profile:

As long as we DO NOT have any stock available in a serialised form for the material we can delete the Serial number profile in the material master. And if we have any stock left we will not be able to delete the profile in the master.

In case if we try to change the serial number profile from XXXX to YYYY say, then system gives a warning message but allows us to change the same. The reason is standard reports are made available to correct the stock inconsistencies and hence the change is allowed.

Delete the serial number profile in MM02:

Message number is M3418.

Change the Serial number profile from one to another:

We get the same message number M3418 but as a warning. Double clicking the status message, We get to see the recommendation to use the standard report - Copying of the Changed Stock Check Flag ‘RISERNR9’.

Also try setting up a Serial profile for a currently Non serialised material having stock already and look for the messages/results.

D. MIGO Error related to posting with Serial numbers:

An error can occur w.r.to Serial numbers while doing the GI via MIGO transaction with the message as:

IO 308 "Difference in object list header data: &1 previously / &2 new"

This happens only for Serialised components in MIGO transaction alone and does not allow any of the serialised components to be posted further in MIGO. However we can do the posting through MB31 for instance for these components.

Reason (Note: One of the reason and not the only reason) for the error being a component was initially with a Serialised profile and an obligatory serial number usage for MMSL procedure and later on the profile had been removed. Later while doing a GI for the component the error comes up.

Trouble shooting:

An entry of the table SER03 exists with MBLNR = $ instead of an actual material document number. We must first change this temporary material document number in the field SER03-MBLNR (that is $) to the actual material document number.

The SER03 table has the Time and Date captured for the material movements. Pick up the date/time from this table and go to MKPF table and for this date/time we should be able to pick up the material document and then manually update the SER03 table.

After the manual correction is done, SAP recommends us to apply Note 1602965 to prevent future errors of this sort.

E. Serialised Materials in Subcontracting:

MMSL value could be set as 01 through 04 until ERP 6.0 (with out any Enhancement package) in a Serial profile and hopefully since 601 the value of 04 is not possible. (This statement needs to be confirmed).

There are SCN messages with users asking others to set MMSL value as 04 and with replies like 04 cannot be set etc etc., Information is with the continuous changes, the SAP release concerned has to be taken into account for any design/ trouble shooting.

There is a SAP note 1029482 that explains the system behaviour when GI happens for subcon components. The explanation here is an extension of the details explained in the SAP note.

It is not possible to do a GI for a Subcon component that has a Serialised profile using ME2O txn.

OIS2 MMSL value -03/Mandatory

We end up with a ME 346 error message.

Diagnosis

Materials requiring a serial number cannot currently be posted in the background because the serial number must be specified.

Procedure

Use the dialog transaction to post the goods issue.

In case you have the Business function LOG_MM_SERNO activated the Subcontracting Cockpit transaction ME2ON is also made available and the same error is displayed here also.

MMSL-02 0r 01

On pressing Enter,

The M7/175 message comes up and display is same in ME2ON also.

Message is the moment a Serialised material has a MMSL serial profile associated (irrespective of any value-01/02/03) it cannot be posted using ME2O/ME2ON.

We will have to use the dialog transaction, either MB1A or MIGO, to complete the same.

Again with the Exception Config we have the 541 movement type available for flexibility.

(SNSC is with SerUsage value 03).

Proceeding with MIGO we can successfully issue the component to the vendor.

After assigning the serial numbers, the GI gets posted.

Stock Overview:

ME2O:

Once we receive the Subcon assembly against a Purchase order we can again use the 543/O movement type with the Exception config to control the movement accordingly.

Current setting:

MMSL-03/Mandatory

No Exception config in place for 543/O movement type.

MMSL-03/Mandatory

Exception config in place for 543/O movement type.

MIGO:

   Please do point out any errors that you may notice either in content or screen mismatch etc., and the same would be corrected on notice.

As a continuation, at a later date, we wish to touch upon challenges faced w.r.to serial numbers in a complex set up that already had SAP live with a part of business and the current part of business having conflicting requirements to the earlier one. Basically this was like looking for an ‘exception in the exception config’ that we had seen in the documents shared and to see if we can add up a movement type indicator for a specific movement type such as 261.

  Also we can touch upon the flow of the movements across streams like Quality management (QMSL), Handling unit management (HUSL) and delivery related procedures in a MTO and also a Stock Transfer scenario.

6 Comments
Labels in this area