Purchase order statuses: from created to received

Purchase order statuses: from created to received

A purchase order is not a piece of paper you fill in, file away and forget. Between the moment the company needs goods and the moment those goods enter the warehouse, the document follows a controlled path: it is created, approved, sent to the supplier, received against what was ordered and, at the end, kept as a historical record. In Kardex Tauro that path is managed through the purchase order statuses, which are the topic of this article: the cycle inside the program, its five statuses, what each one allows you to do, how partial receiving works and why rules exist such as not being able to delete an order that already received goods.

A status is not a label: it controls the document

In Kardex Tauro the status of a purchase order is not one more piece of information in the list. It is the mechanism the program uses to decide what can be done with the document at any moment. If the order is approved, the receive-goods button becomes active; if it is still created or in draft, that button cannot be used. In the same way, printing the order to send it to the supplier is possible only when the order is approved, and deleting it is possible only while nothing has been received. This prevents common process mistakes: receiving goods from an order that was never approved, printing drafts as if they were valid documents, or accidentally deleting an order that already moved inventory.

The Purchase Order List window is the control point of the whole purchasing cycle: it shows the status of every document, starts the approval and receiving operations, and the list can be filtered by status to answer questions such as "which orders are still approved and unreceived?". The following table summarizes the five statuses the program manages and the operations each one allows:

It helps to read this table as a map of restrictions rather than a simple classification. An order in fully received status cannot be edited or deleted: it is closed and only allows viewing, because it already produced effects on inventory and on the Kardex. A deleted order does not disappear from the system: it becomes a historical record, available for auditing. And a created or draft order is the only stage in which the document is still flexible, since it does not yet formally commit the company.

The normal path: from created to received

The normal cycle of an order in the program follows five steps:

1. Create the order with the New Purchase button. The system assigns the next consecutive number and the user chooses supplier, products, quantities and values. The document is saved in created or draft status.
2. Approve the order. Moving from created to approved requires the Approve Purchases permission; the program validates that the order has all its data complete and, once approved, generates the formal purchase commitment.
3. Send the order to the supplier. Printing is available only for approved orders, because only approved ones are valid documents to send. The rule prevents unauthorized documents from going out.
4. Receive the goods against the order with the Receive Purchase button, which is only enabled when the order is approved and which also requires the Receive Purchases permission.
5. Confirm the receipt. On confirmation, the program updates stock, records the movement in the Kardex and changes the order status to received, fully or partially depending on what arrived.

The two critical transitions of the cycle are protected by different permissions: from created to approved only with Approve Purchases, and from approved to received only with Receive Purchases. The separation is deliberate: the person who authorizes a purchase is not necessarily the person who receives the goods.

The following table summarizes those transitions and their effect on the system:

Receiving the goods against the order

When an approved order is ready to be received, the Receive Purchase button opens a receiving pop-up window. The program shows the products of the order with their requested quantities, and the user decides line by line: receive fully, confirming the requested quantity; receive partially, typing a smaller quantity; or not receive, leaving the quantity at zero when that product did not arrive. If the products use serial numbers, the serial capture window opens at that moment, because it is at receiving time that the serials of the physical goods become known.

On confirmation, the program does three things in a single operation: it updates inventory stock, records the movement in the Kardex and changes the status of the purchase order. Each receipt generates a Kardex movement of the Purchase or Purchase Order Receipt type, with date, time, user, supplier, quantities and values, so the Kardex lets you trace the origin of every unit back to the original order.

A worked example: partial receiving with numbers

Suppose an approved purchase order for 100 units of a product that currently has 250 units in stock. The supplier ships 60 units first and the remaining 40 a few days later. The table shows the effect of each receipt:

With the first receipt the order moves to partially received and stays pending for the 40-unit balance. With the second receipt the balance reaches zero and the order moves to fully received. The Kardex now holds two receipt movements, one of 60 and another of 40, both linked to the same order; stock reflects the 100 units that entered and nobody needs to correct anything by hand.

Why partial receiving matters: staggered deliveries

Not every supplier delivers everything at once. Large orders often arrive in several shipments, or part of the goods is delayed by transport or production. Partial receiving exists for exactly that: the program lets you receive only part of what was ordered, the order stays pending for the unreceived balance, and you can make multiple partial receipts until the total is complete.

Once an order is in partially received status, the only operations the program offers on it are viewing it and receiving the outstanding balance: it is not printed again as an open document and it cannot be deleted, because goods have already been received under its name. The system keeps track of requested versus received, so the list always distinguishes an order that was fully received from one that still has a balance to arrive. In addition, stock is updated with what actually arrived, and the account with the supplier is supported by real receipts rather than delivery promises.

Why you cannot delete an order that was already received

The Delete button in the window has clear restrictions: you cannot delete an order that was already received, fully or partially, nor one that was already deleted before. Only orders in created, draft or approved status can be deleted, meaning orders that have not yet received goods. The reason is traceability: a received order already generated movements in inventory and in the Kardex, and if the document disappeared, the origin of that merchandise would be lost and accounting consistency would break.

Deletion always asks for confirmation: you select the order, click Delete, the system asks for confirmation and, if confirmed, the order moves to deleted status. From that moment it stops appearing in the active lists, but it stays in the history for audit purposes. If someone made a mistake with an order that was already received, the way out is not to delete it but to make adjustments through the Kardex or with complementary documents.

Converting a purchase order into another document

Another operation in the life cycle of the document is conversion. Convert Document transforms the selected purchase order into another type of document while keeping the information: supplier or customer, products, quantities and values. The system creates a new document with that data, the original stays intact, and the program keeps the traceability link between the original and the converted document. The available destinations are:

• Supplier quotation, to formally request prices before committing to the purchase.
• Customer quotation, when the purchased products will be offered to customers; in that case the supplier is transformed into a customer.
• Sales invoice, to record the sale of the products directly in special cases.
• Purchase order, to duplicate the order for the same supplier or for another one.
• Warehouse consumption, when the products will be used internally instead of being sold.

Conversion saves time because it avoids typing all the information again and keeps products, quantities and values consistent. It has a restriction tied to the status cycle: it is available only for orders that have not been received. A received order is a historical document that can no longer be transformed.

Separate permissions: internal control over the cycle

The two permissions that govern the cycle are the basis of internal control in purchasing. Approve Purchases is an authorization permission: it allows approving purchase orders. Receive Purchases is an operation permission: it allows receiving goods against purchase orders. If the same person held both, they could approve a purchase and receive it with nobody else involved. The classic internal control recommendation applies directly: whoever requests does not approve, whoever approves does not receive, and whoever receives does not pay. The program supports that separation with granular per-user permissions.

Good practices with statuses

• Approve promptly and with reviewed data: approving generates a formal commitment, so do not pile up orders waiting for approval.
• Receive as soon as the goods arrive: timely receiving keeps stock and the Kardex up to date.
• Respect the statuses: do not try to delete received orders or print unapproved orders; follow the natural flow of the document.
• Use partial receiving when the supplier does not deliver everything: receive what is available and leave the balance pending.
• Monitor approved orders that have not been received: they are pending purchase commitments worth reviewing periodically.
• Reconcile orders and their receipts with supplier invoices to detect differences early.

Understanding the purchase order statuses is not a technical detail: it is how the program guarantees that no goods enter the warehouse without authorization, that no document disappears without a trace and that the Kardex always tells the complete story of what was purchased.