I have an issue using generic materials with EBP:

For low cost materials such as library, we create one generic material master into R/3 and into the Requisite catalog we create a lot of material with non- generic descriptions related to this generic material.

The problem is that when the shopping cart arrives from the catalog to EBP the short description from the catalog is replaced by the short description from SAP (generic short description).

This is a big problem for us, because later when we are preparing the confirmation process or invoice verification, you see only the short description.

So, the question is:
Is it possible to avoid this short description replace of EBP?

    Requires Free Membership to View

    Login

Unfortunately, the result you're defining is standard design in SRM (EBP) materials purchase from the catalog.

My understanding is that the reason this is an issue for your organization is due to the lack of proper information at line-item level during confirmation and invoice processing.

I can suggest the following work-arounds via a fairly small development:

When a user selects an item from the catalog and the information is passed back to the shopping cart via "OCI", at this point take the short and long description of the item from the catalog and map it to the "Internal Text" field on the shopping cart. The standard-material description will be replaced in the shopping cart line item, but the internal note text will be available for reference when the users are performing a confirmation or invoice entry.

This development will probably take only a few minutes for your developers to code. But there is a training aspect for the users doing the confirmation or invoice -- they must now look into the internal note for appropriate line-item descriptions. If this does not work, then other options can be developed where a new field can be created to capture the catalog item description. That field can then in addition be created and displayed on the confirmation and invoice, so that the users don't have to drill down. But this would require a more complex development.

Anyhow, hope this gives you a starting point. Unfortunately, what you're experiencing currently is standard SRM design.

This was first published in January 2005

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top