Supplier Portal Software: Which PO Version Was Accepted?

Supplier portal software should show exactly which purchase-order version a supplier responded to, what changed, and whether the buyer completed the required confirmation. A reply saying accepted is incomplete evidence when purchasing has already sent a revised quantity or date. Keep the response tied to the document the supplier actually saw.

This guide is for purchasing teams and software buyers at small manufacturers. It provides an original fictional test of an order amendment, not a legal interpretation of contract acceptance or a claim about a ready-made Ploqy portal. For the broader acknowledgment-to-receipt process, see our supplier delivery tracking guide.

Separate the document, response and internal status

A purchase order is the buyer's issued instruction. A supplier response records what the supplier accepted, rejected or proposed changing. Internal confirmation records the outcome under the factory's configured review process. Software labels vary, so ask the implementer to show the meaning and transition rule for each status.

As one product example, Microsoft's vendor collaboration documentation distinguishes supplier acceptance from purchase-order confirmation, depending on configuration. It also describes new versions and confirmation history when orders change. Your demonstration should test the actual configured workflow rather than assuming every accepted response immediately updates the order.

Sent, opened and accepted are also different events. An email notification proves neither that the supplier reviewed the current document nor that the agreed internal confirmation completed. Missing replies need a visible owner and follow-up date, not an automatic accepted label.

Identify the version at line level

Give each issued version a stable identity. Record the purchase-order number, version, issue time, supplier account, line identifiers, item and specification references, quantities, units, receiving location and requested dates. Where a line has multiple delivery schedules, identify those separately.

For each response, retain its own reference, the version it answers, responding person, submission time, proposed changes, supporting note and processing result. A line-level change should not disappear behind an overall accepted header. Preserve the earlier issued document so purchasing and the supplier can explain what was available at the time.

The version number alone is insufficient if attachments can change underneath it. Associate approved drawing or specification revisions with the issued record. Restrict external attachments to material approved for that supplier; an internal comment or unrelated customer's drawing must not become visible simply because it sits on the same order.

Test a late reply to an old order

Hypothetical example: PO TEST-719 contains one line for brackets, counted in pieces. There are no receipts, dispatches, invoices or payments in this example. Dates below mean receipt at the buyer's Chicago facility by 4 p.m. America/Chicago local time, not supplier dispatch. The dates and quantities are demonstration data.

1. Version 1: purchasing sends an approved request for 100 pieces due October 26, 2026. No supplier response has yet been recorded.
2. Version 2: after an internal requirement change and approval, purchasing issues 80 pieces due October 28. The portal identifies V2 as the current request and retains V1 as superseded for response processing.
3. Late V1 reply: the supplier submits acceptance from an old browser tab or replies to the earlier message. The submission identifies V1, not just TEST-719.
4. Conflict handling: the system must not apply that response to V2. It either rejects the stale submission with a clear explanation or retains it as an old-version response requiring review, according to the agreed workflow.
5. Clarification: purchasing contacts the supplier if necessary, shows the changed quantity and date, and obtains a response to the current request. V2 remains awaiting a valid response until that occurs.

The test is not whether the system can change 100 to 80. It is whether a response to 100 due October 26 can accidentally make 80 due October 28 look confirmed. Check the version again when processing the response, not only when the page first loads.

Do not silently discard the old reply. Retain enough history to explain the mismatch and the follow-up. If the supplier's message does not identify a version, mark the reference unresolved and seek clarification instead of guessing from its arrival time.

Treat a changed schedule as a proposal

Continue the fictional case. In its V2 response, the supplier proposes 50 pieces on October 28 and 30 on October 30. The total is still 80, but the timing differs. Show both schedules and the exception rather than marking all 80 available on October 28.

Assume the factory needs 70 pieces on October 28 and has no other supply or usable stock in this simplified test. The proposal leaves 20 pieces uncovered that day: 70 required minus 50 proposed. That is a planning warning, not authorization to change production or accept the delay automatically.

The designated buyer reviews the impact with the responsible planner. If approved under the factory's process, purchasing issues V3 containing the agreed split schedule and obtains the required version-specific supplier response and internal confirmation. If rejected, the proposal and reason remain visible while another arrangement is sought. A supplier suggestion must not overwrite the approved schedule without the intended decision path.

This example deliberately uses explicit buyer review. Some products support automatic confirmation for defined cases; the demonstration should expose the configured rule and its failure behavior. Do not infer that software confirmation settles contractual obligations.

Verify that the confirmed result reached planning

After V3 is accepted and internally confirmed, the planning view should identify the agreed 50-piece and 30-piece schedules, their dates, and the source version. The historical 100-piece request must not appear as additional expected supply. Keep original and revised promises available for the separate supplier performance review.

Simulate an interrupted update in a test environment. A recorded supplier response may exist while the internal order update is still pending or failed. Show that distinction and assign recovery to an owner. Retrying the same response should not create another schedule or apply the same quantity change twice.

If the response queue feeds manufacturing dashboard software, include current request version, response version, processing status, last successful update and next action. A green accepted indicator without those distinctions can hide unfinished work.

Nothing in this sequence records a physical receipt or releases material. Expected supply remains separate from received and inspected stock. Our partial-delivery purchase-order example covers those later balances.

Limit who can read and respond

A supplier user should see only the permitted account, orders and externally released files, and perform only approved response actions. OWASP's authorization guidance recommends denying access by default and validating permission on every request. Hiding another supplier's link is not an access-control test.

Use two authorized test supplier accounts to check order pages, downloads and submissions. Test removal of a user's access under the agreed session policy. A supplier must not be able to change its account or order reference in a request and respond to another supplier's order. These acceptance checks do not replace a professional security review.

A read-only customer order-status portal has a different purpose. Adding supplier write access introduces approval, conflict and recovery decisions that should be explicitly scoped, not treated as a cosmetic change to a login page.

Use this demonstration checklist

• Issue V1, then V2; retain both documents and show the current request clearly.
• Submit a V1 response after V2 exists; confirm that V2 cannot become accepted accidentally.
• Submit the 50-plus-30 proposal; retain the original dates and show its effect on the 70-piece requirement.
• Approve or reject through the intended buyer role; retrieve the decision and the resulting version.
• Interrupt processing after the response is recorded; show pending work and retry without duplicate schedules.
• Verify supplier-account boundaries for both reading and writing, using only authorized test accounts.
• Export the version, response, approval and confirmation trail without inventing a receipt.

Start with one supplier and one material family. Record expected behavior, observed result and unresolved gaps, including which steps remain manual. These are proposed evaluation criteria, not claims that Ploqy or every named system already supplies the exact workflow.