SAP-to-Manhattan integration in the Middle East: what to decide before you build

SAP-to-Manhattan integration works when SAP stays the system of record for orders, finance and stock value, Manhattan runs the warehouse and confirms what happened, and both sides agree before anything is built which system owns each piece of data and who owns each interface. The interfaces are standard; those decisions are what make or break the go-live. Supply Chain Junction is Manhattan Associates' GeoPartner for Africa and the Middle East, with over 90 implementations in the GCC and Africa and teams in South Africa, Saudi Arabia and the United Arab Emirates.

This article assumes the WMS decision is made. If you are still choosing between ActiveWarehouse™ and SAP EWM, start with our comparison; if you are on GROW with SAP, our EWM post explains what it includes. Here, the questions run in the order a project meets them.

Which system should own what?

The first design decision on an SAP-integrated Manhattan project is which system is the master for each piece of data. Get this wrong and the two systems spend the life of the warehouse disagreeing about what stock you have.

• Stock quantity and stock value. Manhattan knows where every unit is, by location, pallet and status. SAP holds the quantity per plant and storage location, and the value. SAP's warehouse stock should change only when Manhattan confirms a movement.
• Batches, expiry and serial numbers. Decide where a batch is created (on the purchase order in SAP, or at receipt in the warehouse) and how expiry dates travel between the two.
• Stock status. Quality hold, damaged, bonded: each status in Manhattan must map to a stock type or storage location in SAP, or the two systems will disagree on what is available to sell.
• Pallets and handling units. Usually Manhattan's alone. SAP needs only what the delivery and the customer need.
• Allocation and wave release. SAP decides what ships to whom; Manhattan decides how and when it is picked. If both try to allocate stock to locations, they fight.

Write one owner against each item before design ends. Every later argument comes back to that list.

What are the standard interfaces?

You will need most of these. The list looks much the same on every project; the decisions above are what differ.

How do SAP and Manhattan talk to each other?

ActiveWarehouse is API-first. Manhattan documents two ways in: REST APIs for direct calls, and queue-based asynchronous messaging, where messages are retried automatically and failed ones are held for correction and reposting. Manhattan recommends the queues where throughput matters and REST where an immediate answer is needed. On the SAP side, ECC usually exchanges IDocs, S/4HANA adds APIs, and many estates route both through SAP Integration Suite or SAP PI/PO. The right combination depends on your SAP release and the middleware you already run, not on preference.

On Supply Chain Junction projects, the SAP side and the middleware are the client's build, usually by the client's IT team or SAP partner. We supply the Manhattan message design, build and configure the Manhattan side, and review the client's side against it. That split is deliberate: you keep your own middleware and your own interface owner, and nothing in the integration depends on knowledge only the implementer holds.

Can we connect to ECC now and move to S/4HANA later?

Yes, if you plan for it. Many GCC estates are part-way through an SAP move. SAP ends mainstream maintenance for ECC 6.0 (enhancement packages 6 to 8) at the end of 2027, with optional extended maintenance to the end of 2030 and, for customers who move to SAP ERP, private edition, a transition option to 2033. A WMS that goes live now will probably outlive the ERP it first connects to.

So build the integration to survive the change: one integration layer, a written message contract for every flow, and no business logic hidden in the mappings. When S/4HANA arrives, the SAP end of each interface is re-pointed; the Manhattan end and the warehouse floor stay as they are.

What is different in the Middle East?

• Free zone, mainland and bonded stock. Map each to its own SAP plant or storage location and its own status in Manhattan, so customs status is held in the data, not in someone's head.
• Several legal entities in one building. Separate company codes in SAP, one warehouse in Manhattan: agree how ownership shows on every message.
• Arabic and English. Item descriptions and addresses in both, with the character set checked end to end, including labels and printers.
• SAP may be your client's ERP, not yours. For a 3PL, the SAP system is often the client's, and one warehouse may connect to several clients' SAP systems. A 3PL needs an interface pattern it can reuse client after client.
• VAT and e-invoicing stay in SAP. The WMS supplies complete, timely confirmations for the invoices to be built from; our 3PL guide sets out the UAE and Saudi e-invoicing timelines.

How should cut-over and stock reconciliation run?

This is where most go-live pain sits, and where our go-live gates are tightest. Agree the go-live criteria when the contract is signed, not in the final week. The client extracts the data; we audit, load and test it across rehearsal loads. Reconcile stock between SAP and Manhattan, within agreed tolerances, well before cut-over.

On the night: freeze stock movements, count, sign the inventory baseline, load it, check the control totals, then switch the interfaces on one at a time. Prove one transaction end to end, visible in both SAP and Manhattan, before the first real order. Take the final go or no-go decision on signed evidence, not on confidence. In the first week, reconcile the WMS against SAP every day, and close hypercare only when the agreed exit criteria are signed off. For what drives cost and duration, see our cost and timeline guide.

Who owns testing and the interfaces after go-live?

Run the end-to-end tests with the SAP team in the room, not with each side testing its own half. Give the error queue a named owner from the first test cycle. After go-live, name an owner for every interface: client IT, the SAP partner or the implementer.

ActiveWarehouse is versionless: Manhattan keeps it current in the cloud rather than you upgrading it. Keep a regression pack for your interfaces and run it against each Manhattan release, and whenever the SAP side changes too.

Finally, ask your implementer for a reference where Manhattan runs against SAP, and speak to the person who owns the interfaces there. Our implementation and support page sets out how we work, and the Global Shipping & Logistics story shows another UAE client on Manhattan WMS.

Frequently asked questions

Does Manhattan have a standard SAP connector?

Not as a packaged product. ActiveWarehouse™ integrates through Manhattan's documented REST APIs and asynchronous messaging, and the SAP side connects to those through SAP's own interfaces and the middleware you already run.

Which system should own inventory?

Both, for different things. Manhattan owns where stock is and its status; SAP owns the quantity per plant and storage location and its value, and changes it only when Manhattan confirms a movement.

Can we integrate with SAP ECC now and move to S/4HANA later?

Yes. Keep one integration layer and a written message contract for every flow, so the S/4HANA project re-points the SAP end of each interface without touching the warehouse.

Who builds the SAP side of the integration?

The client, usually through its IT team or SAP partner, on its own middleware. On Supply Chain Junction projects we supply the Manhattan message design, build the Manhattan side and review the client's side against it.

Who implements SAP-to-Manhattan integration in the Middle East?

Supply Chain Junction is Manhattan Associates' GeoPartner for Africa and the Middle East, with over 90 implementations in the GCC and Africa and teams in South Africa, Saudi Arabia and the United Arab Emirates. New ActiveWarehouse™ projects are delivered with Manhattan.

If you are planning a Manhattan project against SAP, book a short call.