.png)
SummaryMSV3 has two sides, and almost everything written about it covers only one. The buyer side is well documented: a pharmacy checks availability and places a digital order. The supplier side is the counterpart, the service that receives those calls and answers them. A manufacturer, importer or regional distributor that ships direct to German pharmacies and does not operate such an endpoint is simply not reachable on the route Germany orders through every day.
This guide covers the seller side: what the endpoint has to answer, which data it needs from your systems, which decisions belong before the technical work, and where the limits are. What MSV3 is in general, who maintains it and how the buyer side works is covered in the MSV3 interface explained, and a worked buyer-side integration is in MSV3 for Sage 100.
MSV3 describes an exchange between two systems. Which role you occupy determines what you have to build.
| Buyer side (client) | Supplier side (server) | |
|---|---|---|
| Who | Pharmacy, hospital pharmacy, hospital-supplying operation | Wholesaler, manufacturer, importer, regional distributor |
| Asks or answers | asks: is it available, on what terms | answers: available, quantity, delivery date |
| Solves what | several suppliers in one query instead of one at a time | being reachable for orders that are already happening |
| Cost of not having it | checking each supplier portal by hand | orders arrive by fax, email and telephone |
The roles are not interchangeable. An operation that both orders and supplies needs both sides, and that is more common than it sounds: an importer buys abroad and sells to pharmacies, a hospital-supplying operation buys from wholesale and supplies hospitals.
Not every business that dispenses medicines needs its own endpoint. The need follows from who orders from you, and how.
Manufacturers with direct supply. If you ship to pharmacies directly, bypassing wholesale, the question is how those orders arrive. Large companies usually already have an endpoint, often operated by a service provider. In the mid-market it is frequently the gap, and the orders arrive by fax and email accordingly.
Importers and regional distributors. They typically sit on both sides: they buy and they sell. For them the supplier side is often the reason a pharmacy sets them up as a supplier at all, because the effort of manual ordering otherwise counts against them.
Hospital-supplying operations. Order frequency is high and the article count is large. Manual routes do not scale here.
Who does not need it: businesses selling exclusively through full-line wholesale with no direct customers. There the order lands at the wholesaler, not with you.
An MSV3 order request is not a form. It is a structured call that expects a structured answer, and that answer has to settle four things.
One: do you know the article? The request arrives carrying the PZN, the German package identifier. Your system has to resolve it against your own inventory. That sounds trivial and is not, if your own article number is not the PZN, which for manufacturers is the norm rather than the exception.
Two: is it available, and how much? Not just yes or no. A partial quantity is a valid answer, and it is often the most honest one.
Three: when? A delivery date, or a statement about back-order. An answer without a date just moves the question to the telephone, which is the cost you were trying to remove.
Four: on what terms? This is where a widespread misconception sits, and it deserves its own section.
It persists that MSV3 does not carry prices. What is correct: MSV3 carries the terms agreed between the two parties, meaning what this customer actually pays you. What MSV3 does not carry is a market price or a comparison against other suppliers.
For the supplier side that has a direct consequence: your terms maintenance is part of the interface. If customer groups, volume tiers and promotions are modelled cleanly in your own system, the interface delivers them. If they are not, it delivers the list price, and the customer calls anyway, which means you have built an integration and kept the phone call.
Anyone who needs market prices or cross-supplier comparison is working with price data, not with an ordering interface. Those are two separate things; the pricing side is covered in how drug pricing works in Germany.
Before any technical work starts, it is worth looking at the data. Six fields have to be reliably present per article.
| Field | What the endpoint needs it for | Typical gap |
|---|---|---|
| PZN | Resolving the request to your article | own article number leads, PZN missing or stale |
| Available quantity | Answering the core question | stock is known but not retrievable in real time |
| Delivery or back-order date | Planning certainty for the buyer | held only in the planner's head |
| Customer terms | Answering with the right price | tiers and promotions maintained outside the system |
| Minimum order quantity and pack unit | Preventing invalid orders | stored as free text rather than as a field |
| Distribution status per article | No orders against delisted stock | delisting communicated only through sales |
The most common blocker is the first row. Companies running on their own material numbers need a dependable mapping to the PZN, and it needs maintaining, because articles change. The identifier layer behind that mapping is covered in the pharmaceutical article master explained and in how IFA assigns the PZN.
Operate it yourself or have it operated? Running your own service means a permanently reachable interface with an availability commitment, certificate maintenance and a named contact when something breaks. That pays off where an IT operations function already exists. For a company without one, operation by a service provider is the usual route: the endpoint is provided and connected to your system.
Which customers may ask? Not every pharmacy should see every set of terms. Mapping credentials to customer groups is a commercial decision rather than a technical one, and it belongs before the integration rather than after it.
Which assortment? Companies with a broad range often start with a subset, typically the articles with the highest query frequency. That keeps the initial data work small and still delivers the effect.
An ordering interface is not a project with an end date. It is a service with a runtime, and three things are permanent.
Reachability. The endpoint gets queried at times when nobody is in the building. German pharmacies order early and late. Maintenance in the middle of the morning is more expensive than it looks, because that is when the requests arrive.
Watching the answers. Knowing that the service is up is not enough. What matters is what it says. A sudden rise in shortfall responses points to a stock problem; a rise in "article unknown" points to a gap in the PZN mapping. Without monitoring, both surface only when customers call.
Maintenance on assortment changes. Every listing and every delisting has to land. An article that is delisted but still reported as available produces orders that have to be cancelled, and that costs more trust than an honest shortfall message.
Four patterns repeat.
Stock is not available in real time. Many systems know the stock level but release it only in a nightly run. An availability answer based on yesterday is worse than none, because it creates commitments that do not hold.
Terms live outside the system. Volume tiers in a spreadsheet, promotions in email, special prices in a field rep's head. The interface can only deliver what the system knows.
Nobody owns it when it breaks. An ordering interface is an operations topic. If the endpoint does not answer overnight, the customer orders somewhere else the next morning. The owner should be named before go-live.
Certificate expiry. Credentials expire, and they do it quietly. A calendar entry ahead of expiry costs nothing and prevents an outage that otherwise becomes visible only when orders stop arriving.
The question is normally "what does an MSV3 integration cost". The more useful question is what it costs today not to have one.
A manually received order goes through entry, a query where something is unclear, confirmation, and correction when something is wrong. That time is spent per order, every day. On top of it sits what never becomes visible: orders that never reach you at all, because the buyer picks the supplier who is already in the ordering screen.
On the cost side of an integration there are three items, distributed differently depending on the route: provision of the endpoint, connection to your own system, and ongoing operation. Having it operated shifts the third item to a service provider and leaves you the second.
The calculation only becomes meaningful when both sides are on the table. An estimate of today's manual handling time per order, multiplied by the order count, is the quickest way in.
MSV3 is not the only way orders arrive, and it does not fully replace the others. Placing it helps decide how much effort is justified.
| Route | Who uses it | What it does | What it does not do |
|---|---|---|---|
| MSV3 | Pharmacies, hospital-supplying operations | Availability check and ordering from inside the merchandise management system, no media break | applies to Germany, not across borders |
| Supplier portal | Buyers with few suppliers | Full control over presentation and assortment | a separate login per supplier, no comparison in one query |
| EDI | Industry and trade with each other | Established for cross-border and high-volume relationships | too heavy for an individual pharmacy |
| Fax, email, telephone | Everyone where nothing else is set up | Always works | manual entry, transcription errors, no availability answer up front |
In practice several routes run in parallel. The question is not whether the others get abolished, but what share of orders can move to the structured route. For companies with many small orders from many pharmacies that share is high; for a handful of large customers on framework agreements it is low.
Reachability is not demand. An endpoint makes you orderable for the buyers who already know you and have you set up as a supplier. It does not create new customers. Visibility with buyers who do not yet know you is a separate problem needing a separate route.
MSV3 is Germany-specific. It is not an international standard. Cross-border supply needs other routes for other markets, usually EDI procedures. Plan for that explicitly: an MSV3 integration solves the ordering route for the German business only.
The interface does not replace master data maintenance. It exposes how good your data is. Companies that clean up their PZN mapping and distribution status before the integration finish faster than those that do it afterwards.
pharmazie.com is the consolidated pharmaceutical data platform operated by DACON Datenbank Consulting GmbH, on the market since 1989, addressed exclusively to healthcare professionals. Two points are worth stating precisely, because the two sides of MSV3 are at different stages.
The MSV3 client interface, meaning the buyer side with availability checks and digital ordering out of your own system, is live and productive as a standard add-on module. The MSV3 server interface, meaning the supplier side described in this article, is in a pilot phase. Anyone evaluating the seller side should factor that in rather than plan against a finished product.
Independently of the interface, the data layer underneath is available today: the article master keyed on the PZN, with distribution status, prices and successor references, which is the layer your mapping problem actually lives in.
The supplier side of MSV3 answers four questions: do I know the article, is it available, when, and on what terms. It rests on six reliable fields per article, above all a maintained mapping to the PZN. The decisions about operation, customer scope and assortment come before the technology, not after it. And the honest cost comparison is not the price of the integration but the price of the manual handling it replaces.
If you want to check what your inventory data would support on a supplier endpoint, book a demo.
This content is addressed to healthcare professionals and does not constitute medical advice. Last reviewed: September 2026.
