How to Plan an ITS Integration Project

At a pharmaceutical manufacturer, an ITS integration is won or lost while the scope is being set, not on the day the line stops. Operations does not want to ask which pack sits in which notification. IT does not want the same serial number to tell one story on the line and another in the enterprise record. This article is for the operations lead and the IT lead. It explains how the project is scoped and run. We are not describing the inner layout of the software. We are talking about where an identity is born, when a notification is legitimate, and how the floor recovers when a notification is rejected.

We described how notifications are queued in software in our article on ITS notification processes. Here are the decisions that have to be on the table before that work starts. The names below come from the ITS page on its.gov.tr and from the ITS operating guide. We do not invent notification codes. Which notification is mandatory for your stakeholder type is always confirmed against the current guide.

Who sits down, and what question opens the project

Operations and IT sit at the same table in the first meeting. Operations knows when a batch left the line and when a case was closed. IT knows where the work order came from and whether data survives a network drop. Scope is the place where those two facts meet in one sentence.

The opening question is this: from the moment a carton's serial number is verified until the notification is accepted, which system and which manual step does it pass through? Starting to write the integration before that map exists means guessing at the missing link. The missing link is usually one of these: the line result arrives late, aggregation closes after shipping has started, or a rejection sits in a file and shows up on shipping day.

We keep the scope narrow. We do not rebuild the whole supply chain. We bind the manufacturer's obligation to the enterprise record without tearing out the existing line software. A pharmacy's sale to a patient is not this project's work.

What ITS is, and who must notify

ITS (İlaç Takip Sistemi) is the central system that makes each medicinal product for human use uniquely identifiable through its 2D code and follows its movements through stakeholder notifications. The operating guide names the parties that notify: manufacturers, importers, pharmaceutical wholesalers, pharmacies and hospital pharmacies. The production notification and the import notification are made by the license or permit holder. A wholesaler's notification and a pharmacy's notification belong to those parties.

For a manufacturer the consequence is practical. A product that will enter the supply chain is introduced to the system first. A product that was never introduced gets stuck when the next party tries to receive it, and the problem comes back at shipping or as a return. The project does not start from "the line has the data". It starts from "is this data the input of the right notification?"

softhan does not own this system. We do not declare acceptance. Acceptance is the response the system returns. The boundary of the service is written on the pharma serialization and ITS page.

The pack hierarchy, and when each identity is born

The hierarchy is discussed in four levels. Each level's identity is born at a different moment. Printing a label before the identity exists gives an official identity to a unit that is still wrong.

Unit. The saleable carton. A serial number is allocated, the 2D code is printed, and the carton does not enter a notification list until verification says it is good. We describe how GTIN, serial, batch and expiry sit together in our serialization article.
Bundle. The intermediate level of several units. The child units are read, the count and the batch agree, and only then is the parent identity given. Putting an unread carton into the bundle is the first step of late aggregation.
Case. The identity is born after the contents have been verified. If the label is printed before the pack list is closed, a faulty case receives an official identity. A missing unit, an extra unit or a unit from another batch is caught at the label.
Pallet. The identity is born while the pallet is built. A pallet can be built on the line or in the warehouse. Where it is built decides which system the record is written to first. The pallet label is not printed while the list is unreconciled.

We describe how the station builds this relationship in our aggregation article. What the scope has to settle is whether the relationship is closed before the shipping document.

Serialization, aggregation and the notification are not the same job

On the floor these three words are often used for each other. In the scope they are separate lines.

Serialization gives the saleable unit a unique identity. The result is the list of good serials and the list of rejected ones. A rejected carton does not enter the production notification.

Aggregation links those units to bundles, cases and pallets. The result is the parent-child tree. The tree is not the notification. The two need separate approval.

The notification is the act of sending specific units to ITS as a defined movement. The production notification means the carton exists in the system. The sale notification means it leaves for the next stakeholder. Neither replaces the aggregation record. Carrying the hierarchy as a file does not mean the notification has been made either. We cover that distinction in our notification article.

The notifications a manufacturer should name correctly

ITS has many operations. The ones a manufacturer needs to name correctly in the project scope are the headings on its.gov.tr and in the operating guide. There is no separate notification type called "shipment". The dispatch that operations calls a shipment is, for the manufacturer, a sale notification.

Production notification. The license holder introduces a product it has manufactured. its.gov.tr treats this notification as mandatory for a product that will enter the supply chain. It has to be made before the product is the subject of a sale. The input is the list of serials verified on the line. A rejected carton is not on that list.
Import notification. This introduces an imported product. It is out of scope for a site that only manufactures. Where a company both manufactures and imports, the two flows run on separate work orders.
Sale notification. This is the product leaving for a wholesaler, a pharmacy, a hospital or another next party the regulation allows. its.gov.tr also treats it as a verification. Expiry is checked. An expired product is not accepted. Each dispatch is its own notification.
Export notification. This takes a product that already has a production notification out of the country. Manufacturers, wholesalers and export warehouses can use it. Export is not written in place of a domestic sale. Sale or export is decided on the work order.
Deactivation notification. This closes the record of a product that can no longer be used. The example on its.gov.tr is destruction. The operating guide names removal from the system, production scrap, destruction after a recall and destruction because of expiry. The current service guide also lists revision and consumption. Scrap requires that the product had no movement other than production. A product that was never notified cannot be deactivated. The guide does not describe this as an ordinary cancellation.
Return. its.gov.tr describes the goods-return notification for products that are sent back: the product leaves one stock and passes to the other party's record. The operating guide says that when a manufacturer or a wholesaler takes back a product it sold, it makes a sale-return notification. At the start of the project we fix, from the guide, which name applies to your stakeholder type. A return is not a deactivation. The carton that comes back still carries an identity and is still traced.

Correcting a wrong production or import record is done, according to the guide, by removing a product that has had no further movement from the notification. A product that has already moved is not deleted the same way. The software is not designed as "open the record and edit the inside". Removal and adding again are two traceable steps.

What the line software must hand to the enterprise system

What the enterprise system expects from the line software is not a screenshot. It is the reconciled list of a closed work order. At least these fields have to arrive together, under the same identity:

Work order, product, GTIN, batch and expiry
Serial numbers found good, and the moment they were verified
Rejected serials, the reject reason, and confirmation that the reject actually left the line
Units removed from the list as samples or rework
For each bundle, case and pallet: the parent identity, the child list, and the moment that identity was born
Which dispatch is a sale, which is an export, and which is a candidate for return or deactivation

If the line count and the enterprise count do not agree when the work order closes, the notification does not start. A difference left open comes back the next day as a duplicate serial or a missing notification. A list that stays on the line screen and never reaches the enterprise system does not yet exist for the notification.

Three failures, and how operations recovers

A duplicate serial is the same serial number arriving twice for the same GTIN. We stop before the notification. The usual sources are a number pool given to two lines, a reprinted carton entering the good list with the old serial, or the same file sent twice. The operating guide says only one copy of repeating data is accepted. Recovery is not sending the second copy again. The valid record is chosen from the work order and the line result, the other leaves the list, and only the missing units go.

Late aggregation is a case or pallet that reached shipping before its child list was closed. The sale notification waits. Operations scans the parent label and completes the child list. If a carton is missing, the relationship is undone, the right contents are built, and only then is the label treated as final. The hierarchy file and the sale notification are separate steps. The truck is not loaded while one of them is still open. The station finishes the count check before the label.

A rejected notification is the system sending back data that does not fit. Operations sees the reason per product. Frequent causes: a sale with no production notification, a sale of an expired product, a wrong correction of a product that has already moved, and scrap that does not qualify for deactivation. The whole batch is not sent again. Rejected units are split out, the data is corrected, and only those units go. Accepted units stay. Every attempt is kept with who made it and what the result was.

How the scope document is closed

A short document is enough when discovery ends. These lines have to be filled in:

Stakeholder type and the notification list. Only the notifications you make. A pharmacy's sale to a patient is outside.
Hierarchy. Are there units, bundles, cases and pallets? Is the pallet built on the line or in the warehouse? How is a case that is not full marked?
The moment the goods change hands. Which warehouse movement do sale, export and return follow? Does the notification go before the dispatch note?
Reconciliation. If the closure shows a difference, does the notification stop?
Rejection. Who watches the screen, which rejection stops a shipment, and where is the record kept?
Go-live. One line or one product group first. The result is compared with the current method, then the scope grows. Operations takes the screen. IT takes the record.

Testing happens before any real notification. A duplicate serial, a missing field, a case that closes late, a rejection and a network drop are run with test data. A live batch is not the first rehearsal.

Where softhan stands

We are the integration layer. We bring the good list and the reject list from the line software, the aggregation relationship and the enterprise work order into the same record. We keep the sending of a notification, the response and the retry on a trail operations can see. We do not replace ITS. The party that accepts the notification is the system on its.gov.tr. We complete the missing link without dismantling your existing serialization setup.

We do not recommend a single programming language. The measure is that line data is not lost, the reject reason is visible and the record can be read later. The technology is written in discovery, for the plant's infrastructure and for an option the team can keep running.

Frequently Asked Questions

Can a shipment go out without a production notification?

No. its.gov.tr requires a production or import notification for a product that will enter the supply chain. A sale notification is not made while the product is not in the system. The shipping plan waits for that order.

Are the carton serial and the case identity born at the same moment?

No. The unit's identity is born when the 2D code is verified. The case identity is born when the units inside have been read, the count agrees and the label is printed after that. The pallet identity is born while the pallet is built.

If a notification is rejected, must the whole batch be sent again?

No. Accepted units stay where they are. Only the rejected units are sent again, after the cause has been removed. Every attempt stays on the record.

Does softhan replace ITS?

No. softhan is the integration layer between the line and the enterprise record. Acceptance of a notification is the response returned by İlaç Takip Sistemi.

Facing a similar challenge? Tell us about your project and we will get back to you within one business day.

System and product names belong to their respective owners. softhan is not an authorized representative or partner of the authority that operates İlaç Takip Sistemi.