MATMAS E1MEANM Segment Missing via Change Pointers

[Former Member]

We are having an issue with two possible causes, but one that seems the most common.

Environment: ECC 5.0 interfacing MATMAS data to a staging database via BizTalk through the BizTalk SAP Adapter. Change pointers are turned on globally and for MATMAS. There are no filters or views in the partner profile for MATMAS.

We did an initial push of materials to our staging database with great success. After that, we turned on change pointers to pick up any new materials created or changes to existing materials. Here is where the issue lies: we do not get all information from the material when the change pointers are processed.

The specific segment that we seem to miss when a material is created is the E1MEANM segment. Our staging database provides our legacy applications with UPC/EAN/GTIN data out of that segment. This is used by external ordering applications such as our E-Commerce solution.

My first suspicion was that BizTalk was deleting our mean table when an idoc showed up without a MEAN segment for the specific material. We have proven this to not be the case.

The second and mostly likely problem is that when a new material is created, the MEAN segment is not getting populated in the IDOC. This is a problem as the systems external to R/3 use UPC/EAN to interface orders to R/3. Without the data, the order process from those systems fails.

Has anyone seen this before? If so, what was the cause? Is there a way to force R/3 to send a full MATMAS IDOC from a change pointer rather than just the effected segments/fields?

Thanks,

Kevin Moran

[christian_wohlfahrt]

Hi Kevin!

I was using ARTMAS-Idoc sometimes, I think this should be similar to MATMAS-Idoc.

When you are missing a segment during initial sending, one of the first checks should be indeed, if the master data of the article was already created. There can be hundreds of views still missing.

If you can't handle a material without EAN, then it should be possible to make the EAN-field mandatory.

If mandatory field isn't an option, then you need to filter the Idocs until EAN was filled.

In earlier releases these Idocs where sent completely (with all segments) all the time and some customers complained: "we don't need all the data, we only want to have the changes". Then SAP changed behavior, now other customers run into problems.

In both periods we needed a flag / attribut / whatever to change the behavior - I don't know any (standard) help.

But it's not so complicated to change the behavior in a user exit (did this for POS-download once):

in an exit, which was in the area of the change analysis (maybe to make some own filters) you can add artifical change pointers for all segments -> later segment filling should be triggered for every segment.

In ECC 5.0 implicit exits should be available -> you should be able to find a place to change the behavior. Maybe there is a structure or a table later, which holds the 'has changed' information. If you can enhance this, then it might be even easier to get complete Idocs.

Regards,

Christian

[Former Member]

Hi Christian,

We haven't solved the issue, yet, but we have a work around. Since UPC is always in MARA and we can't get a material into R/3 or staging db without MARA, we have changed our database view definition to pull MEAN when it exists (mostly for non-unit UOM codes such as GTINs) and MARA if it doesn't.

This will give our legacy group the ability to have the data we need until we put something in to make sure all segment are sent. As we have just gone live with our R/3 system, they are holding off on any development in R/3 unless proven absolutely necessary.

Thanks for the answer. Although it is not what I wanted to hear, I'm sure it will help.

Kevin