Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Too many recipients found for message type SHPMNT in the ALE model

wernervm
Participant
0 Kudos

Hi;

We are trying to send message type SHPMNT to 2 external systems.

We’ve defined filter in BD56 & BD95 for shipment type (VTTK-SHTYP).

When using only one external system with filter on SHTYP, iDOC is created.

When adding the 2nd message type (within same “sub” distribution model) and using filter on SHTYP, SAP issues the following error:

Message no. B1130

In the ALE distribution customer model several recipient systems for

IDOCs with message type SHPMNT and filter object type 'LIFNR' with value

'1156203' have been modeled from this system, but only one recipient

system is allowed.

Why and what tells SAP to look at LIFNR, as my filter is on SHTYP?

Thanks in advance.

1 ACCEPTED SOLUTION

jack_graus2
Active Contributor
0 Kudos

Hi, in (shipment) output determination there is only 1 IDOC message type + partner possible for 1 (shipment) output possible.

This can be solved by sending the (shipment) message to your own logical system by ALE.

Then when the IDOC is received in your own system it can be distributed to the final destination logical system('s) by ALE.

To create a shipment IDOC message that is to be send to your own logical system make a copy of the shipment outbound process message (SHPM, ....) and change the ALE processing flag to 'Processing with inbound trigger'. When you now create a shipment IDOC it will be distributed to your own logical system.

Then in the partner profile for your own logical system in inbound processing choose the inbound process code ED08 (Forward IDOC). Now when you receive the IDOC it will be distributed (by the ED08 process code) to the logical system('s) as defined in the distribution model for this shipment message.

Regards Jack

7 REPLIES 7

jack_graus2
Active Contributor
0 Kudos

Hi, in (shipment) output determination there is only 1 IDOC message type + partner possible for 1 (shipment) output possible.

This can be solved by sending the (shipment) message to your own logical system by ALE.

Then when the IDOC is received in your own system it can be distributed to the final destination logical system('s) by ALE.

To create a shipment IDOC message that is to be send to your own logical system make a copy of the shipment outbound process message (SHPM, ....) and change the ALE processing flag to 'Processing with inbound trigger'. When you now create a shipment IDOC it will be distributed to your own logical system.

Then in the partner profile for your own logical system in inbound processing choose the inbound process code ED08 (Forward IDOC). Now when you receive the IDOC it will be distributed (by the ED08 process code) to the logical system('s) as defined in the distribution model for this shipment message.

Regards Jack

0 Kudos

Hi Jack

Thanks for your valuable feedback!

We’ve tested your proposal, but with same result.

Please review steps that were executed in SAP.

We changed the scenario from Shipments (SHPMNT – SHPMNT06) to Deliveries (DESADV – DELVRY03)

(I’m sure your proposal can be applied to both scenarios)

  1. 1) Create copy of Process code DELV in tcode WE41 (we copied all dependent requirements) and changed radio button to “Processing w. trigger (inbound)”. New process code created: ZDELV
  2. 2) Add message type “DESADV” with process code “ED08” to Inbound parameters for the current active SAP logical system using WE20. Let’s call it SAP_QAS
  3. 3) We added the 2 new external systems in Distribution model (BD64) and then generated partner profiles. Let’s call them:
    1. MES_DEL1
    2. MES_DEL2
  4. 4) We then changed Message control for 2x external logical system in WE20 (Outbound parameters):
    1. MES_DEL1 / E1 / ZMES / ZDELV
    2. MES_DEL2 / V2 / ZMES / ZDELV

I’m sure the setup in tcode NACE is correct since we’ve tested both [Inbound (E1) and outbound deliveries (V2)] successfully with only one external system in Distribution model.

Best regards

W

0 Kudos

Hello, as far as I can see you receive the error message in outbound processing of the IDOC.

We use this scenario for several different messages in different applications.

We do use transmission medium '6' (EDI) in the output type with the EDI_PROCESSING form routine.

But as partner in the partner agreement and also in the output master data a logical system (the logical system for the SAP client) is used.

You could first test by creating an output message manual in your delivery with partner role LS and logical system.

Best regards Jack

0 Kudos

Hi Jack

We’re using transmission medium ALE and not EDI. My understanding is that EDI does not work for partner type LS, but do work for KU and LI (but I’m uninformed on this subject).

I’ve changed output control in tcode NACE to use EDI with RSNASTED / EDI_PROCESSING.

We are now faced with a different error during delivery output:

Maintain outgoing EDI-connection data for partner CMESWBDO

Message no. VN032

Diagnosis

The system could not locate the EDI partner agreements (outbound) for

partner CMESWBDO.

System Response

You cannot use transmission medium 'EDI' with this partner.

Procedure

Maintain the EDI partner agreements for partner CMESWBDO. Make sure to

create entries for output control as well as for outbound parameters.

Partner CMESWBDO is defined in WE20 as type LS and all other settings (e.g. message control) are correct. Not sure if EDI requires additional settings when compared to ALE.

Also, when using EDI, the Delivery output in VL32N does not default. We have to manually add the Output type (and we have maintained the condition records in NACE).

The only other solution is to create a new Z message type for each Logical system and link relevant Basic types to them. But this seems a bit extreme as I’m sure there must me a standard SAP solution for our required Distribution model.

Regards

Werner

0 Kudos

Hello

as we run into same problem using output type 'A' (ALE) we do use output type '6' (EDI). But still your EDI partner can be a logical system with EDI partner role LS. And if you choose so the logical system (CMESWBDO), IDOC message and output type must be maintained in the partner profile.

The logical system with partner role LS can be maintained as fixed partner in your output message master data. MN25 for inbound delivery output.

The error message you mention above looks like missing (or incorrect) partner profile. That will also prevent message determination in VL32N. Be aware that the partner in partner profile is logical system (CMESWBDO) with partner type LS (Logical system). But because you are using EDI next to partner type also partner role LS should be used.

Regards Jack 

0 Kudos

Thanks for your feedback.

I didn't use Partner role LS during my tests (only partner type LS and MN25 was done correctly), but have since moved on to find another solution (creating new message types using same basic types).

I’ve also created a log with SAP OSS. Herewith their feedback:

Too many recipients found for message type SHPMNT in the ALE model
Message no. B1130
The message you are receiving explicitly states that this message
type cannot be sent to multiple recipients.
Please change the ALE distribution customer model so that it allows only one recipient system for the message from this system.
Please note, that not all messages have this restriction.  This
restriction is specified by the business scenario.
In case of master data you can send the same data to
different receivers. It's the case if each receiver has to hold the
same master data.
From the process it's as following: An application
creates a master idoc and will call the ALE layer. In that layer we
will check the distribution model (tx BD64)
and we'll send the data as idoc to each receicer which was found.
(from ABAP technique fm MASTER_IDOC_DISTRIBUTE or ALE_IDOCS_CREATE is
called).

For all scenarios which use message control we have just 2 ways to
create idocs. There are the mediums EDI (6) or ALE (A). The
result is the same you get just one idoc. The way to find the
receiver is different.

Using medium EDI the receiver is the partner
which was found already via message control and which was saved
within the partner profile (TX WE20). The distribution model (tx BD64)
is not used in that case.

Using medium ALE it doesn't matter which receiver was determined
via message control. We look via the distributen model for a unique
receiver for the message type in question.
Either we've just one pair of sending and receiving system or the
pairs have different filters (LIFNR as example).
From the technique the application (tx VA01 as example ) creates
a message record (entry table NAST) with the information about the
used medium. If you use the collect mode report RSNAST00 will call
the reports behind the mediums. These are edi_processing or
ale_processing you can find within program NASTEDF0.

If you wish to create more than one idocs despite there is just one
message record I can't suggest a standard way.
One way is to create just one idoc it doesn't matter using medium
EDI or ALE. This idocs can be posted to a port ABAP/PSS.
check tx WE21. In such port you can double such idocs to further
receicers.

The other option is to use own reports similar edi_processing or
ale_processing which you can use to process message records.
In table TNAPR you find all called reports for each application.
To maintain you own reports you've to use tx NACE, I think.
In these reports you could call fm MASTER_IDOC_DISTRIBUTE as example
and you could create more than one idoc per call.

I’m confident this thread will assist others with similar issue.

Regards

0 Kudos

Hi

OK this works for your situation.

We are using the scenario with inbound distribution where we have a lot of receivers, up to 50, and don't want to create different message for each receiver.

It is good to see the OSS confirmation that there is no standard solution for this. But on the other hand the creation of an inbound distribution process code is just a very small configuration without the need of a customer development.

Regards Jack