SAP EWM<\/strong><\/a> was live. ATTP was integrated. The compliance team had signed off. The go-live was celebrated.<\/p>\nThen three months in things started breaking quietly.<\/p>\n
Goods movements began freezing mid-process. Warehouse staff scanning serialised cartons would hit confirm and just wait. The system hung. Transfer orders piled up. Supervisors started printing manual workaround sheets. What was supposed to be a smart, automated warehouse was running partially on paper again.<\/p>\n
Nobody panicked immediately. Everyone assumed it was a small configuration issue something the internal IT team could fix over a weekend.<\/p>\n
That weekend became six months.<\/strong><\/p>\nWhat the business was actually losing during those six months \u2014<\/p>\n
Over \u20ac45,000 monthly (as reported by the client) in delayed shipments, emergency courier rerouting and penalty clauses from hospital and pharmacy clients
\nThree formal regulatory warnings due to serialisation status mismatches between EWM and ATTP
\nDelivery SLA dropping from 98.4% to below 81% \u2014 clients were noticing and escalating
\nWarehouse teams logging 2 to 3 hours of daily manual intervention just to keep shipments moving
\nStock ledger inconsistencies building up silently \u2014 inbound confirmed in EWM but ATTP still showing open serialisation status
\nTwo senior warehouse coordinators resigned citing operational frustration<\/p>\n
This was not a minor system glitch anymore. This was a business bleeding quietly \u2014 every single day.<\/p>\n
The Call to SCM Champs<\/strong><\/h2>\nBy the time the distribution center’s operations director reached out to SCM Champs, the exhaustion in her message was visible. She wrote \u2014<\/p>\n
“We have tried everything internally. Our SI partner has escalated three times. Nothing is working. Our warehouse is running on workarounds and our compliance team is nervous. We need someone who has actually seen this before.”<\/p>\n
SCM Champs had seen it before. Many times.<\/p>\n
The team was on a call within 24 hours. No lengthy proposals. No generic discovery templates. Just direct, focused questions from people who understood exactly where to look.<\/p>\n
What SCM Champs Actually Found<\/h2>\n
This is where it gets technical \u2014 but stay with it, because every finding below was directly costing this business money.<\/p>\n
Finding 1 \u2014 Synchronous calls were choking the entire flow
\nEvery single goods movement was triggering a synchronous RFC call to ATTP \u2014 meaning EWM would stop completely and wait for ATTP to validate every serial number before allowing the posting to continue. In a warehouse processing hundreds of serialised units per hour, this created a queue of waiting processes that progressively slowed the entire system down to near standstill.<\/p>\n
Finding 2 \u2014 RFC destination and gateway settings were never optimised
\nThe RFC connections between EWM and ATTP were running on default configuration \u2014 never tuned for the actual transaction volume this warehouse was generating. Gateway parameters were throttling the connection during peak morning dispatch hours precisely when the warehouse needed maximum throughput.<\/p>\n
Finding 3 \u2014 No PPF framework was in place
\nATTP serialisation checks were embedded directly inside core execution transactions. There was no Post Processing Framework action set up to handle ATTP communication separately \u2014 which meant any ATTP delay immediately became an EWM delay with zero buffer.<\/p>\n
Finding 4 \u2014 Number range buffering was inactive
\nDuring high-volume periods multiple warehouse lines were simultaneously requesting serial number validations against massive ATTP database tables \u2014 with no buffering active. Every request was hitting the database cold, creating locks and compounding the latency.<\/p>\n
Finding 5 \u2014 No local serial number processing was being leveraged
\nThe distribution center was on S\/4HANA 2022 \u2014 which supports reduced real-time ATTP dependency within EWM itself \u2014 but this capability was completely unused. Every scan was pinging ATTP directly, even for actions that did not require it at that moment.<\/p>\n
What SCM Champs Delivered \u2014 Step by Step<\/strong><\/h2>\nStep 1 \u2014 Switched from Synchronous to Asynchronous RFC Processing<\/strong>
\nThe team reconfigured serialisation checks to run asynchronously using aRFC (asynchronous Remote Function Calls) \u2014 removing the hard dependency that forced EWM to wait for every ATTP response before continuing. For scenarios requiring guaranteed processing sequence, qRFC (queued RFC) was additionally configured via transaction SMQR \u2014 ensuring background queue processing without locking the warehouse interface or delivery document. Queue health was monitored through SMQS and SM58 to ensure no stuck entries during go-live stabilisation.<\/p>\nStep 2 \u2014 Built the Post Processing Framework Actions<\/strong>
\nPPF actions were configured within EWM to trigger ATTP serialisation checks after warehouse task confirmation or goods issue posting \u2014 not during. A Goods Movement Block was implemented on the delivery \u2014 the official SAP EWM mechanism tied directly to ATTP document status \u2014 which releases automatically once the asynchronous PPF action receives a successful ATTP confirmation callback. This completely removed ATTP communication from the critical execution path.<\/p>\nStep 3 \u2014 Optimised RFC Destinations and Gateway Parameters<\/strong>
\nRFC server group assignments were reviewed and corrected via transaction RZ12 for proper load balancing across dialog work processes. Instance profile parameters were then adjusted through RZ10 to allocate sufficient work processes for peak RFC load. Gateway parameters \u2014 specifically gw\/max_conn and gw\/max_overflow_size \u2014 were tuned based on the client’s S\/4HANA 2022 kernel version to handle high-volume serialisation spikes during peak dispatch windows without connection throttling.<\/p>\nStep 4 \u2014 Number Range Configuration and Database Performance Review<\/strong>
\nNumber range buffering for ATTP serial number processing was reviewed and configured per SAP standard guidelines \u2014 preventing database locks when multiple warehouse lines simultaneously validate serial numbers during peak operations. Additionally, database performance analysis was conducted on high-volume ATTP tables and optimisation recommendations were raised through proper SAP support channels \u2014 ensuring query response improvements without direct index manipulation outside of SAP-compliant procedures.<\/p>\nStep 5 \u2014 Reduced Real-Time ATTP Dependency in S\/4HANA EWM<\/strong>
\nSince the client was on S\/4HANA 2022, SCM Champs configured EWM to leverage SAP’s recommended integration model for reducing synchronous ATTP load in high-volume environments. Serial number processing was restructured so that EWM handles execution-level actions locally \u2014 synchronising with ATTP as the system of record only at defined milestones such as goods issue or delivery confirmation. This approach significantly reduced real-time ATTP dependency without compromising pharma serialisation compliance or ATTP’s role as the central validation authority. The result was a reduction of over 60% in unnecessary real-time ATTP calls during a normal warehouse shift (as reported by the client).<\/p>\nStep 6 \u2014 End-to-End Validation Before Go-Live<\/strong>
\nBefore anything went live, SCM Champs ran a full parallel testing cycle \u2014 covering inbound deliveries, outbound dispatch, stock transfers and returns. Every scenario. Every edge case. Queue monitoring via SMQR and SM58 was kept live throughout. Nothing was pushed to production until the team was fully satisfied that the flow was clean, compliant and stable.<\/p>\n