EWM stock removal from automatic warehouse without MFS resource

[ales_knor01]

Hello, We are working on a project where we are implementing EWM MFS in a scenario where SAP does not control the AS/RS and conveyors directly via PLC, but only communicates via telegram with the technology vendor's MFS. So I have no info which crane will be putaway/removal. All putaway scenarios are via handover point to destination bin and can be done without resource. For picking, the scenario is reversed from the source bin to the handover point. For this scenario, picking with resource works fine until more than one WT is sent to the resource. The FM for sending a telegram checks if the resource has a task/telegram assigned to it. We need to be able to send more WTs to be picked up. Is it possible to do stock removal without MFS resource?
If the queue is without MFS resource the telegram is not sent. EWM MFS requires either CP or resource in the telegram.
The solution may be multiple resources assigned to the queue but this does not seem to me to be an optimal solution. Another option is to use no resource and change the telegram before sending.
Any ideas?

[Eckhard_Siefer]

Hi,

I do not really see the point in connecting an external MFS via EWM MFS and communicate via telegrams instead of connecting the external via the WCU interface and communicate WTs via ALE (idocs).
EWM MFS is designed to communicate directly to PLCs either via ABAP Push Channel TCP or RFC connectors like SAP PCo.

[ales_knor01]

Hi, WCU was the first choice, but,

the automation vendor can only telegram, change it is expensive and the lead time is over a year. Getting WCU to work on TCP/IP communication means developing customer logic in the Pco or directly in the customer application, not to mention maintaining and monitoring connections and interfaces. We are talking about SAP private cloud. Furthermore, it would be necessary to develop customer logic in idoc/rfc processing to handle exceptions and errors, moving from nok positions to id point, cancelling existing WTs, creating new ones, etc.. And all this in the required response time. MFS has all of this in its base. We are not talking about one simple warehouse.

[Eckhard_Siefer]

Hi Ales,

I understand. I am afraid EWM MFS was not designed for such a situation as by design it assumes to be directly communicating with a PLC and therefore also assumes that the number of resources capable of performing stock removal task is limited.
I would not have any better idea to use a larger number of resources with the queue to widen the bottleneck at this point. It is not an elegant solution. It would depend on the maximum throughput of the automated warehouse regarding stock removals. So the amount of resources just needs to be bit higher than that.

[ales_knor01 · Accepted solution]

The problem was solved by using a fake aisle storage location in the LOSC. HU is virtually moved to the stock location (CP) with WT immediately confirmed in badi. Then a telegram is sent to the real PLC(CP) to move the HU from the aisle to the destination storage location. This is only possible because the previous WMS/MFS systems only communicated at the aisle level and not at the bin level.

[rkarthik161092]

It seems like you try use EWM MFS standard functionality but doesn't align with physical activity. A crane/resource can process only one warehouse task/order at a time. But you would like to send/process multiple orders on the same resouce at the same time. It seems like you need create a custom FM based on some conditions storage type/activity area to be able to send the telegrams to 3rd party vendor system.

[dietrichneumann]

The problem at this point is not the multiple assignment of a resource, but that the EWM MFS standard currently does not provide for resources with multiple load handling devices.

We had the same problem with double cross-travel carriages or simply with AS/RS with two load handling devices.

At this point there is no other choice than to extend the MFS framework with a Z* framework:

• Each load handling devices (LHD) is addressed with an own position number
• Vehicle orders are LHD-specific (i.e. separate vehicle orders per LHD)
• Vehicle orders at pickup / drop off bins can physically be executed in parallel
• Error handling of each LHD