Glossary of terms
The terms you meet in the warehouse, in pharmaceutical manufacturing, in public institutions and in custom software projects, explained in short.
Warehouse and logistics
WMS (Warehouse Management System)
Warehouse management system: the software that keeps stock by location, not just as a total, and records every movement of goods by scanning, from receiving to dispatch. It does not replace the invoicing software, it connects to it.
See it in practice →Stock location
The physical position where goods are kept, described in levels: warehouse, zone, rack, level, position. Every position has a barcode label, and its code (for example R01-T2-E1) also tells you where it is.
See it in practice →Goods receipt
The entry of goods into the warehouse, against the purchase order. In a WMS, the worker scans what arrived and shortages or surpluses are visible on the spot. A receipt can be partial or complete and records batch, serial number, expiry date and condition.
See it in practice →Picking
Order preparation: collecting the products from the shelves for an order. In a WMS, scanning verifies every product, and a product that is not on the order cannot end up in the parcel.
See it in practice →Route-based picking
Ordering the lines of an order by the route through the warehouse (aisle, section, level) instead of the order on the invoice, so the picker does not cross the hall several times.
See it in practice →FIFO / FEFO
Stock allocation rules. FIFO (first in, first out): the batch that came in first goes out first. FEFO (first expired, first out): the batch with the nearest expiry date goes out first, the right rule for products with a shelf life.
See it in practice →Cycle counting
Counting stock in parts, shelf by shelf, during normal activity, instead of a full day with the warehouse shut down. You scan the shelf, see what should be on it and correct the differences with a reason.
See it in practice →Physical, available and reserved stock
Physical stock is what physically exists. Reserved stock is allocated to confirmed orders (for example after an advance payment). Available stock is what you can sell: physical minus reserved, minus damaged or quarantined goods.
See it in practice →Serial number
The unique identifier of one piece (inverter, panel, device). It is recorded at receipt, allocated to the order and shown in the warranty report, so you know exactly which serial each customer received.
See it in practice →Batch
A quantity of product manufactured or received together, with the same date and the same characteristics. The batch is tracked from receipt to the customer and is the basic unit for traceability and recalls.
See it in practice →Traceability
The ability to reconstruct a product's history in both directions: from a serial number or batch you get to the order and the customer, and from a product you see all its movements.
See it in practice →Barcode (EAN, Code128, QR, DataMatrix)
The codes printed on products, shelves and labels, read with the phone camera or a scanner terminal. EAN-13 is the code on retail packaging, Code128 is used on internal labels, and QR and DataMatrix fit more data in a small area.
See it in practice →Mobile scanner terminal
An industrial device with a built-in scanner, tougher and faster than a phone. It is not mandatory for a modern WMS: the app can also run on ordinary Android phones, using the camera.
See it in practice →Goods in custody
Customers' goods kept in your warehouse without being your stock, for example a tyre hotel. They are kept separately, per numbered contract and position, so they do not mix with your own stock.
See it in practice →Pharmaceutical manufacturing and quality
GMP (Good Manufacturing Practice)
Good manufacturing practice: the rules under which medicines, cosmetics and supplements are produced so that every batch is manufactured and controlled the same way. In the European Union they are described in the EU GMP guide.
See it in practice →Batch record (BMR)
The document that proves how a batch was manufactured: materials, quantities, steps performed, parameters, checks, signatures. It is the document every inspection asks for and the basis for the batch release decision.
See it in practice →EBR (Electronic Batch Record)
The electronic batch record: the batch record filled in directly in the system, on a tablet, as each step is performed, with material scanning, automatic limit checks and electronic signature. It replaces the printed, hand-filled record.
See it in practice →Annex 11 (EU GMP)
The chapter of the EU GMP guide dedicated to computerised systems. It requires validation on the user's processes, an audit trail, access control, electronic signatures linked to the record, backups and periodic review.
See it in practice →21 CFR Part 11
The FDA regulation for electronic records and signatures, required for the US market. It calls for two-component signatures, re-entered at every signing, with name, date, time and meaning, plus a system-generated audit trail.
See it in practice →ALCOA+
The data integrity principles inspectors look for: attributable, legible, contemporaneous, original, accurate, plus complete, consistent, enduring and available. Any GMP system should be able to demonstrate them.
See it in practice →Audit trail
The log in which the system records any creation, modification or deletion of data: old value, new value, author, time and reason. It cannot be edited or switched off, not even by an administrator.
See it in practice →Electronic signature (GMP)
The confirmation of a step or document in the system, with password re-entry and a meaning: performed, verified, approved, released, witnessed. It stays bound to the signed data; if the data changes, the signature shows as outdated.
See it in practice →Validation (IQ, OQ, PQ)
The documented proof that a system does what it should, at the user's site: installation qualification (IQ), operational qualification (OQ) and performance qualification on real processes (PQ), based on requirements and a traceability matrix. Software is not certified, it is validated.
See it in practice →GAMP 5
The good practice guide for computerised systems in the pharmaceutical industry. It classifies software by how much it is configured or developed; a configured and custom-developed system falls into category 5.
See it in practice →URS (User Requirements Specification)
The user requirements: the list of what the system must do, written before configuration. Every requirement is linked to a test in the traceability matrix.
See it in practice →Deviation
Any departure from the approved procedure or parameters: a weighing outside tolerance, uncalibrated equipment, an unexpected result. It is reported, risk-assessed, investigated and linked to the affected batch.
See it in practice →CAPA
Corrective and preventive actions: what you do so a deviation does not happen again, with an owner, a deadline and effectiveness verification. They stay linked to the deviation they came from.
See it in practice →OOS / OOT
OOS (out of specification): a laboratory result outside the limits, which opens an investigation and blocks batch release. OOT (out of trend): a result still within limits but unusual compared with the history, flagged before it becomes a non-conformity.
See it in practice →Quarantine
The status of raw materials or received products until the quality decision. Quarantined stock physically exists, but cannot be used in production and cannot be delivered.
See it in practice →Batch release
The decision by which the qualified person confirms that the batch was manufactured and controlled according to the requirements and can be delivered. It is based on the batch record, laboratory results and the review of deviations.
See it in practice →Reconciliation
The material balance at the end of a batch: how much the department received, consumed, returned to the warehouse and lost, compared with accepted loss thresholds per item.
See it in practice →Serialisation (FMD)
The unique code on every pack of prescription medicine, required by the Falsified Medicines Directive. The system keeps records per batch and blocks the sale if serialisation is incomplete.
See it in practice →Stability study
Testing a product over time, under defined conditions (for example ICH), to establish its shelf life and retest date. Time points and deadlines are tracked in the system.
See it in practice →Public sector
ALOP
The four phases of budget execution in a Romanian public institution: commitment, verification, authorisation and payment of expenses. Each phase has its own documents, approvals and signatures.
See it in practice →Purchase request
The document by which a department describes the goods or services it needs, the estimated value and the funding source. The approved request starts the procurement and the justification.
See it in practice →Justification document
The document with section A (the requesting department) and section B (commitment control, with credit reservation), followed by the authorising officer's decision. It is exported in the Ministry of Finance format.
See it in practice →Budget and legal commitment
The budget commitment reserves the credits for an expense; the legal commitment is the act (contract, order) that binds the institution to pay. They are generated from the approved justification and numbered per year.
See it in practice →Payment authorisation
The document by which the authorising officer orders the payment of an expense, based on the supporting documents and goods receipts. It is pre-filled from the justification and exported as XML and an official PDF.
See it in practice →SEAP
Romania's electronic public procurement system, through which institutions buy goods, services and software. A product listed in SEAP can be purchased directly by institutions.
See it in practice →CPV code
The Common Procurement Vocabulary: the European code that classifies what is being purchased. Procurement documentation has a main CPV code and, optionally, secondary codes.
See it in practice →Software and platform
Custom software
An application developed around one organisation's process, not an off-the-shelf product. It makes sense when the process is specific or data comes from several places; on an existing platform, only what is truly different gets written.
See it in practice →Platform (DataFlows Core)
The shared base all solutions run on: users and roles, forms, approval workflows, document generation, audit log, API. A new application starts with all of these already in place.
See it in practice →Dedicated instance
The application and its database run separately for each client, in the cloud or on their own server. Data does not mix with other clients' data, and backups and updates are done on that instance.
See it in practice →Cloud vs. on-premise
In the cloud, the application runs on the vendor's servers or in a public cloud, accessible from anywhere. On-premise, it runs on your own server, in the company network, including without internet access. Both can have a dedicated instance.
See it in practice →API
The interface through which two programs exchange data automatically, without files sent by hand. A documented API, with access keys limited by permission and with an expiry date, allows connection to the ERP, the website or any other application.
See it in practice →EDI
The electronic exchange of commercial documents (orders, delivery notes, invoices) in standard formats, used mainly with retailers and large partners that do not work over API.
See it in practice →Integration
The connection between two applications so that data flows without retyping: over API, straight from the database, through Excel or CSV files or through EDI. A good WMS connects to the existing invoicing software instead of replacing it.
See it in practice →Approval workflow
The path a document follows until approval: sequential or parallel steps, mandatory and optional signatories, minimum number of signatures, notifications. Every step stays in the log.
See it in practice →Document template
The model from which a document is generated: fixed text, variables filled from data, tables from lists and sections that appear only in certain cases. It is made once, and the documents come out the same every time.
See it in practice →Audit log
The record of important actions in the application: who, what, when. Entries are only ever added, with no editing or deletion, so you can always reconstruct what happened.
See it in practice →Two-step authentication (2FA)
A password plus a second factor: a code by SMS or e-mail, an authenticator app or a security key. It blocks access with a stolen password.
See it in practice →Roles and permissions
Who sees what and who can do what in the application: by department, unit, document type or customer. Sales, the warehouse and finance see only what they need.
See it in practice →Let’s talk about your process
Choose from many ready-to-run solutions or tell us about your specific scenario