Requirement to Display Two Sales Org Addresses on MSDS

[rohan_somji]

Dear All,

We have a requirement to display two Sales Org addresses on the MSDS. Currently, using the standard symbol EHS_SNNAM*, we are only able to display one address—the one configured in the Sales Org settings.

I’d like to know if there is any way to include both addresses.

Please note:
We would prefer not to manage this at the specification instance level, as it would require maintaining addresses for each individual specification, which would be highly cumbersome for the business.

Appreciate your insights on possible alternatives or custom solutions.

Regards,

Rohan

[christoph_bergemann]

Hello

the SAP SD process is using exactly one sales organisation. Therefore: This triggers then the EHS part. The "handshake" of data is using one sales organisation code only. I have no clue how you would like to make the link to a second sales org.. but as you have stated: any how a customer driven solution. And yes you can go on like that.

But in a nutshll: if you have a clear blue print concept for the link of the both sales org: you can enhance your logic for chaper 1. This is done by many companies.

But there is a risk: Currently you have one released WWI report. This report contains (for SDS) only the parameter symbols. Only these will be expanded in report shipment,

Therefore: you can only change the parameter symbol to collect data to be pinted. As soon as you would need new symbols. i am sorry. ANY SDS must be regenerated (at least in a minor version)

Your idea to use the property tree will have the same effect.

What i can share to you are discussions like: we have one sales organisations but many distribution channels. Can i have different chapter 1 addresses by channel? 

Using 3E WWI template: Answer is no. Using own chapter 1 logic: answer is yes (but you need to do something (refer above regarding the risks)

Can you explain high level your planned logic: if we have sales org X we shold print data as well for Y. How are you planning this link? The solution must be stable if the company framework is changing (e.g. new sales org; generated; or sales orgs are merged etc.)

Wish you the best

C.B:

PS: if you have used up to now the SAP standard WWI symbol (for address print): it would be a "modification" from SAP point of view (this might be a risk) to use a different function module to collect and show the data. But from my point of view this is possible or at least you check this option

PPS: Chapter 1 is discussed in many projects i know. The topic is coming up very often. To avoid risks: stick to standard: only if there is a "good / big business value": you should change the logic

Only if you have a "on scratch EHS implementation": you should think about customer solution. To change in a running system this is a risk.

[rohan_somji]

Hello @christoph_bergemann ,

Thank you for your expert advice. In the last few days I was working on gathering more information on this topic.

We have encountered a unique situation in our organization. SDS shipping and report generation currently function as expected based on two different Sales Organizations. However, we also operate a web portal that displays SDS documents, which is built on custom logic and is not connected to the Sales Organization structure.

To display a Sales Org address, we rely on a custom table that maintains a 1:1 Country-to-Sales Org mapping. This has worked well so far, as each country typically has a centralized headquarters whose address can be displayed as the primary one.

However, Chile poses an exception. There is no centralized HQ; instead, smaller countries like Chile operate via distributed centers. Using the address of CL1 when the shipment originates from CL2 has already led to customer complaints due to inaccurate SDS address information.

To address this, the business has agreed that in such cases, we should display two addresses when the exact Sales Org address cannot be determined. At the same time, they would prefer not to create a new template version, as that would require re-releasing all existing SDSs for Chile.

Proposed Solution

Given that no standard solution exists, we are considering the following options:

1. Phrase-Based Approach or Hardcoded Conditional Output
   Implement logic in the WWI template to conditionally output both Sales Org addresses based on the country, using either phrases or hardcoding. This is quick to implement but may become harder to maintain in the future.

2. Custom Report Symbols with Functional Module or Exit
   Create a custom symbol to dynamically pull all relevant Sales Orgs for a given country code. This is a clean and scalable solution but requires development effort.

3. Leverage the “Text SDS Sender” Field
   Use the existing "Text SDS Sender" field in the Sales Org, maintained via transaction SO10.

   The disadvantages I see here are: The existing semantics for the field are extended with a new use case. This could lead to problems in the future if the content doesn't satisfy both use cases. What's disadvantageous, especially for the planned address output, are the limited layout options.

Template Change and Business Workaround

While a WWI template update is ultimately unavoidable, we can propose a workaround to minimize business impact:

• After the template changes are implemented, we can temporarily set the generation variant for Chile to status "Released".

• Then, using mass generation via CG02, all SDSs will be created directly with the "Released" status.

Once the process is complete, we can revert the status of the Chile variant to its original setting.

Please let me know your thoughts or if further clarification is needed.

Best regards,

Rohan Somji