How to close the REOPEN container number in SAP ME5.1

[former_member323997]

Hi,

I found a issue maybe it is a bug for the 5.1, for the Pack/Unpack activity, when we unpack a container number which has already been closed status, and remove all their SFCs from this container number, and then this container number is changed to REOPEN status, but at this moment, I found this reopen container number has never been able to add any SFCs, and we are also not able to close this container number.

In our system we have a lot of those kinds of REOPEN container number, but if there are any container contained the REOPEN container numbers, we couldn't change any information in the container maintenance, this is our problem, we want to find a solution how to fix this. Any idea of this kind of issue?

Thanks a lot and best regards,

Leon Lu

[alexander_teslyuk]

Hello Leon,

According to SAP Note #1266247 you may pack into REOPEN container only those SFCs, which were unpacked from it.

Regards,

Alex.

[former_member323997]

Thanks for your reply, Alex.

What our purpose is to change the container configurations in Container Maintenance, but we found as long as there are OPEN/REOPN status container numbers against this container, it is not allowed to change any configurations(I found in ME5.2, no limation like this).

In our database, we have thousands of REOPEN status container numbers, we don't know where to find those original SFCs which had been packed and unpacked, so this solution seems not working for us. And also, I don't understand what the business scenario you designed like this way. If the container number is REOPEN status, from my opinion, it should be repacked by any of other SFCs, otherwise, why we need REOPEN the container number.

Thanks a lot and best regards,

Leon Lu

[sergiy_katerinich]

Hi Leon,

I would agree that the design is not perfect, though your idea about changing definition of the existing container does not look good to me. The reason is that all information about containers can be formally divided into 3 parts: (1) container definition, (2) actual containers created at the beginning of Packing to pack specific SFCs, and (3) actual content (SFCs) of specific containers. Although there is no parent-child relation in CRUD tables for these objects, they are connected by the logic of application. Thus it is not good to change part #1 if you have already created objects of part #2 and #3. Moreover, after such changes you will not be able to restore the original configuration of the object of part #1 that is likely to cause data inconsistency between objects of part #1 and objects of part #2/3.

So, I would rather create new container definitions if any changes need to be introduced to the current configuration.

Regards,

Sergiy

[former_member323997]

Hi Sergiy,

I also would agree the container shouldn't be changed from the logic perspective if it has the OPEN/REOPEN container number, but here are the scenario why we want to change them:

1. We use this pack/unpack function more than 4 years, we define the containers nearly without any limitations, because we select the pack level as Item, but put the pack value as * as well as shop order as *, which means, as long as users select this container, any available SFCs are able to be packed into this container. Recently we investigated out a few more powerful functionalities with your pack/unpack function, like, we can define the specific item numbers, so now users want to use this functionalities;

2. Because in the container maintenance, we need configure the documents which will be used by this container for label printing, but our customers request to change the label templates, we create a new document but we found it is not possible to modify in the container maintenance.

Creating a new container is a choice for us, but the problem is, the old one is still open, we can't delete/disable/hold (actually this is our purpose) this container because there are a lot of REOPEN container numbers, thus users are still able to select this container (actually it is invalid) and pack SFCs into this container.

As far as I identified, the ME5.2 doesn't have this limitation, I am curious that what the purpose you changed this logic in the new product, and how did you handle the logic what you have described:-)

Thanks a lot and best regards,

Leon Lu

[sergiy_katerinich]

Leon,

My reason was provided from the perspective of the end user rather than from the perspective of the design. The current design does not require such limitations throughout all fuctions of ME, e.g. you can freely change any item in Item Maintenance, without any limitation, though I would not say this is always good in a real production.

If the way how ME 5.2 works satisfies your needs, you'd submit a ticket to let Product Mgmt review the issue - maybe they agree on this change to 5.1.

Regards,

Sergiy

[former_member442433]

Hi,

I found a similar issue in 5.2 and it also exists in 6.0:

Pack / Unpack

Here is the scenario I ran u2013

1. Created Container ID CN43 for Container Tray

2. Added SFC xxx70 to Container ID CN43

3. Closed Continuer ID CN43

4. Selected Container ID CN43 and selected u2018Unpacku2019

5. Selected SFC xxx70 and selected u2018Unpacku2019

6. Entered SFC xxx71 into SFC field and on u2018tabbingu2019, received the following error: Input value "SFC" is invalid ("xxx71") (Message 12901)

It seems that you cannot add a new SFC to a Container with a status of REOPEN. I have logged a CSS Message for my customer on this and have asked for it to be fixed in 6.x also

With regards to being unable to change Container definition information for Container IDs with the above status - this has to do with database integrity but may in some cases be a little too restrictive. To allow a little more flexibility, a custom solution would have to be implemented; as implemented by another customer