SAP

Protecting the Core Without Constraining the Warehouse

Publish Date: June 16, 2026

A clean-core approach to shelf-life batch management in SAP EWM.

In any high-volume distribution center, an operator will occasionally scan a pallet into a storage bin only to have the system reject the placement. In most cases, the system is correct. Occasionally, it is doing precisely what it was configured to do, and that is the situation worth examining.

This was the case at one of the largest craft brewers in the United States. The operation moves thousands of pallets of finished goods each month through embedded EWM in SAP Cloud ERP, and a single production characteristic was quietly undermining its storage model: every batch brewed within a given calendar month carries the same Shelf-Life Expiration Date (SLED). From a freshness perspective, this is an unusually clean situation. From a putaway perspective, standard EWM logic treated it as a constraint.

Why has the standard configuration reached its limit

The natural starting point is the storage type control settings — Storage Behavior, Putaway Rule, and the Mixed Storage indicator. The brewer’s bulk storage type was configured as expected: Storage Behavior 2 (bulk) and Putaway Rule 2 (addition to existing stock / empty bin). The decisive factor was the mixed-storage indicator, and this is precisely where the standard configuration reaches its limit.

Consider what that indicator can express. It can permit mixed storage without restriction; it can allow several non-mixed HUs of the same product and same batch; it can allow several HUs carrying different batches of the same product; or it can prohibit mixing altogether — one product, one batch, one quant per bin. Every option is governed by product and batch. None is governed by the expiration date.

That left the business with two unattractive options and no clean one. Restricting the indicator to a single batch per bin would guarantee shelf-life integrity, but at the cost of dispersing a single month’s production across far more bins than necessary — underutilized bins, fragmented pallets, and more putaway and replenishment movements than the labor plan could absorb. Permitting different batches of the same product would recover density, but it would also authorize EWM to commingle batches expiring in different months. In a regulated beverage operation, that is not a configuration preference; it is an FEFO and compliance exposure.

The rule the business required was narrow and precise: allow free mixing across batches that share an SLED, and prevent it across batches that do not. No standard control indicator expresses this. The expiration date is the true discriminator, and standard mixed-storage logic does not evaluate it.

Where the decision is actually made

The appropriate response was neither to force the storage type customizing into a shape it was never designed to hold, nor to modify standard logic. It was to address the decision at its source, the bin determination, and introduce a single, targeted check.

EWM putaway logic builds a list of candidate bins for each inbound Handling Unit and then filters and sorts them. This part of the system is deliberately well-instrumented because SAP anticipates precisely this kind of business-specific nuance and provides released enhancement points to accommodate it.

Two of those points were used. On the automated path, a released filter-and-sort BAdI evaluates the candidate bins: it reads the SLED on the inbound HU’s batch, examines the resident quants already held in each candidate bin, and excludes any bin whose existing stock carries a different expiration date. Bins already holding the same SLED remain eligible, so different batches of identically dated product consolidate as intended. On the manual path — where an operator overrides the proposed bin on an RF device — a released destination-bin verification BAdI performs the same comparison and prevents placement until the warehouse task is created. The rule is enforced on both paths: the system’s proposal and the operator’s override.

That is the entire intervention. There is no modification to the standard putaway strategy, no access key, and no modification adjustment to manage at the next upgrade. It is a single, well-placed validation delivered through released, supported extension points — the form of extension that ABAP Cloud and SAP’s clean-core model are designed to keep upgrade-stable.

The operational outcome

The results followed the design. Identical-SLED batches now consolidate into shared bins, increasing storage density and reducing the pallet fragmentation that had been consuming capacity. Fewer destination bins per production run translated into fewer putaway movements and less downstream replenishment activity, freeing up labor for the operation. And because the cross-SLED restriction is enforced at the point of placement rather than detected later during a cycle count, shelf-life compliance was strengthened rather than relaxed, even as utilization improved. Freshness and efficiency ceased to work against each other.

The broader lesson

It would be easy to read this as a narrow technical fix. The more valuable interpretation is architectural. The brewer did not have a system defect; it had a legitimate business characteristic that the standard configuration could not express. The discipline that mattered was distinguishing clearly among three things that are too often treated as one: configuration, clean extension, and modification.

Configuration would have meant forcing the mixed-storage indicator to approximate the rule while never quite satisfying it. Modification would have meant rewriting core bin-determination logic to serve one company’s batching policy and paying for that decision at every feature pack for the life of the system. A clean extension means placing the single piece of genuinely proprietary logic exactly where SAP intends it to reside: at the edge, in a released BAdI, decoupled from the core, governed, and visible.

This is the same decision every organization will face as warehouses consolidate onto embedded EWM and modernize toward SAP Business Suite. Standard functionality will prove correct far more often than many expect. The competence that matters is identifying the one or two areas where an operation is genuinely distinct and extending precisely there. So the core remains clean, upgrades remain low-risk, and differentiation resides where the business can defend it.

The brewer’s bins are fuller, its movements fewer, and its expiration controls tighter. Standard EWM behaved correctly throughout. It was simply not built for this particular business, so we built the small part that was and left the standard intact.

YASH Technologies’ SAP EWM practice helps beverage, food, and life sciences organizations modernize warehouse execution across embedded EWM and SAP Cloud ERP using a disciplined, clean-core extensibility approach. To discuss your shelf-life, batch, or putaway strategy, contact a YASH SAP expert at info@yash.com or visit www.yash.com.