JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

July 24, 2026 · 12 min read

SAP EWM Communication Point

The Communication Point master data record is the middle tier of SAP EWM’s Material Flow System (MFS) hierarchy. Where the PLC master record registers the physical automation controller and its network endpoint, the Communication Point defines one logical telegram channel over that connection — grouping the specific message type, direction, and processing queue used for one category of MFS traffic (for example, inbound pick-confirmation telegrams versus outbound routing commands). One or more Communication Points are created under each PLC, and one or more Conveyor Segments are then linked underneath each Communication Point, completing the three-tier chain that drives automated material flow control. This article maps what the Communication Point represents, how it varies by telegram direction, where it sits in the MFS data hierarchy, and the fields an EWM consultant configures on it.

Part 1: Communication Point — Core Concepts (All Modules)#

1.1 What Is the Communication Point?#

A Communication Point is the object that scopes and names one logical exchange channel between EWM’s MFS kernel and a PLC. It does not open a new physical network connection — that connection already exists at the PLC level — but it isolates one telegram type and direction so that EWM can process, queue, buffer, and troubleshoot that traffic independently of any other channel running over the same physical controller.

1.2 Communication Point Direction Types#

EWM does not assign named business types to Communication Points the way it does for, say, Storage Types. The meaningful dimension is telegram direction, because direction determines whether the Communication Point receives status updates from the PLC, sends control instructions to it, or both — and this in turn shapes how the channel’s queue and error handling must be configured.

Design principle: Splitting Inbound and Outbound traffic onto separate Communication Points is the standard, recommended approach for anything beyond the simplest setup — it keeps queue processing, buffer sizing, and error recovery independent per direction, so a stalled outbound channel does not block inbound confirmations (or vice versa).

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Warehouse Number (e.g., WH01)
   │
   └── PLC "PLC-CONV-A"  (/SCWM/MFS_PLC — Siemens S7-1500, Conveyor West Wing)
          │   Scope: Warehouse Number
          │   Key: Warehouse Number + PLC Name
          │
          ├── Communication Point "CP-IN-01"  (/SCWM/MFS_CP)
          │      │   Scope: PLC "PLC-CONV-A"
          │      │   Direction: Inbound — pick/putaway confirmation telegrams
          │      │   Key: PLC Name + CP Name
          │      │
          │      └── Conveyor Segment "SEG-A-01"  (/SCWM/MFS_CS)
          │             Scope: Communication Point "CP-IN-01"
          │             Key: CP Name + Segment Name
          │
          └── Communication Point "CP-OUT-01"  (/SCWM/MFS_CP)
                 │   Scope: PLC "PLC-CONV-A"
                 │   Direction: Outbound — routing/divert command telegrams
                 │   Key: PLC Name + CP Name
                 │
                 └── Conveyor Segment "SEG-A-02"  (/SCWM/MFS_CS)
                        Scope: Communication Point "CP-OUT-01"
                        Key: CP Name + Segment Name

Key design decision: One Communication Point per direction-and-telegram-category combination is standard practice. Do not collapse Inbound and Outbound traffic onto a single Bidirectional Communication Point purely to reduce the number of master records — the resulting loss of independent queue monitoring and error isolation outweighs the setup convenience, except in the lowest-volume scenarios.

1.4 Integration with Other Master Data Objects#

The Communication Point does not stand alone. It sits in the middle of the three-tier MFS master data chain, inheriting its network connection from the PLC above it and passing its direction and telegram type down to the Conveyor Segments below it.

Part 2: EWM-Specific Field Details#

2.0 Scope of EWM Ownership#

Legend: ◎ = Owner / Critical, ○ = Direct involvement

2.1 Identification#

The Identification section is the administrative header of the Communication Point master record. Because the CP Name becomes the foreign key on every Conveyor Segment created underneath it, these fields should be agreed with the project team before setup begins.

2.2 Telegram Configuration#

Telegram Configuration defines the message contract for this channel — which telegram type flows over it, in which direction, and which ABAP structure EWM uses to parse or build the telegram bytes.

2.3 Queue and Buffer Settings#

Queue and Buffer Settings control how EWM’s background processing handles telegram volume on this specific channel, independent of the queue settings on any other Communication Point sharing the same PLC.

2.4 Confirmation and Error Handling#

This section defines what EWM does with a telegram once it arrives on this channel, and how the channel behaves when processing fails — settings that can be tuned per Communication Point independently of the retry/timeout behavior configured at the parent PLC.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction