Configuring FactoryPMI Order Matching Without Soundex

FactoryPMI receives an order name over TCP/IP after operators have already planned similar orders in its FIFO queue. The number that matters is the count of unique planned records remaining after normalization: one permits automatic binding, zero requires reconciliation, and more than one is an identity collision. This is string identity, not phonetic similarity; the matching path must preserve the difference between Main 3 and Main 30 while removing the formatting difference between MAIN_3, Main 3, and MAIN 03.

Wrong fixes and their failure modes

Several common fixes address only part of the problem. Raw string equality rejects equivalent names because letter case, separators, and zero padding differ. Soundex removes spelling detail to compare how words sound, but order names are structured identifiers containing meaningful digits. A phonetic code can discard distinctions needed to keep order 3 separate from order 30.

A broad fuzzy-string search has the opposite problem: it can always return the nearest candidate even when no valid match exists. With names such as Main 3 and Main 30, a small edit distance does not prove shared identity. Automatic selection based only on the highest score turns an uncertain comparison into a potentially wrong production record.

Enforcing a naming convention only in FactoryPMI also leaves half of the interface uncontrolled. Drop-down lists can make locally entered names consistent, but they cannot change text arriving from the machine GUI. Asking operators to remember punctuation, capitalization, and padding rules has the same boundary problem and adds language-dependent data entry.

Order identity and comparison boundaries

The order name is display data, while ndx is the stable record key. Use the name only to discover the intended planned record. After a match, associate subsequent processing with ndx; otherwise, a later spelling change could break or redirect the relationship.

Normalization must remove presentation differences without removing identity. For the stated cases, the canonical representation needs three behaviors: compare letters without case, treat underscores and spaces as equivalent token separators, and compare a numeric token by its value so 03 and 3 are equal. It must retain every digit and token boundary needed to reject 30 as a match for 3.

Preserve token order. A formatter may remove repeated separators, trim leading and trailing whitespace, and normalize case, but it should not sort words or delete digits. Those transformations can make unrelated identifiers collapse onto the same key.

Symptoms and root causes

Quantity can support an operator’s decision, but it is not automatically part of name identity. Two legitimate orders may share a name or quantity. Add it to the automatic key only when the production data model explicitly defines that combination as unique.

Canonicalization rules

Build one canonicalization routine and apply it to the incoming machine name and every candidate FactoryPMI name. Two independently implemented routines tend to drift. The output should be a sequence of text and numeric tokens rather than a pronunciation code.

1. Retain the original OrderName exactly as received for display, audit, and manual review.
2. Trim outer whitespace and fold letter case for comparison.
3. Treat a space and underscore as equivalent separators. Collapse adjacent separators so formatting does not create empty tokens.
4. Split alphabetic content from numeric runs. Convert each complete numeric token to its numeric value for comparison, making 03 equal to 3.
5. Preserve token sequence and all remaining text. Compare the resulting token arrays for exact equality.
6. Record the normalization result with the reconciliation transaction so a rejected or accepted match can be reproduced.

The boundary between letters and digits needs an explicit local rule. The supplied examples contain a separator, so they establish equivalence for MAIN_3 and MAIN 03, not for an unseparated form. Route a new pattern to review until its intended identity is defined and added to the test set.

Deterministic reconciliation procedure

1. Receive and retain the machine’s basic order fields over TCP/IP, including OrderName and Quantity. Give the incoming transaction its own state so a failed lookup does not discard it.
2. Read the eligible planned orders from the FactoryPMI FIFO queue. Limit the candidate set by real workflow state, such as orders still awaiting machine association, rather than searching historical and completed records.
3. Canonicalize the incoming name and each candidate with the same routine.
4. Require exact equality of canonical token sequences. Soundex or a fuzzy score may rank choices shown to an operator, but neither should authorize an automatic record association.
5. Count the exact canonical matches. When the count is one, bind the machine transaction to that record’s ndx.
6. When several records share the key, apply FIFO only if they are intentionally interchangeable occurrences of the same order identity. Otherwise, show the matching records for selection.
7. When the count is zero, retain the data in an unmatched queue. Present the raw machine name, canonical form, planned names, and relevant fields such as Quantity to an operator for later selection.
8. After manual reconciliation, store the selected ndx. An approved alias can accelerate later comparisons, but it still needs collision checking against the current eligible queue.

This separates recognition from scheduling. Name normalization determines which records represent the same order identity; FIFO determines which eligible occurrence runs first. Reversing those decisions allows the first vaguely similar name to win.

Operator interface and exception handling

Use controlled selections wherever FactoryPMI owns data entry. A set of drop-down lists such as Site, Device_Type, and Device_ID can generate the local display format Site\Device_Type\Device_ID without requiring operators to memorize punctuation. The machine-side name still passes through reconciliation because that entry remains outside FactoryPMI control.

The exception screen should expose the decision, not only a proposed result. Show the incoming raw name, its canonical tokens, each candidate’s raw name, candidate ndx, queue position, and contextual fields already present in the order data. Mark exact canonical matches separately from approximate suggestions.

Keep unresolved transactions available after the machine message completes. Operators can then select the correct planned order without re-entering or losing the machine data. Log automatic matches, manual selections, rejected suggestions, and collisions; these records reveal which normalization rule or controlled list would remove the most recurring exceptions.

Verification and release criteria

Test the comparison routine before connecting it to automatic production association. The acceptance matrix must contain both positive and negative pairs; testing only names that should match hides over-normalization.

1. Run every pair in both directions to prove that the comparison is symmetric.
2. Insert two eligible records that normalize to the same key and verify that the system detects the collision rather than silently selecting one.
3. Send a name with no exact canonical match and verify that the transaction remains available for manual reconciliation.
4. Complete a manual match and confirm that subsequent processing references ndx, while both original display names remain intact.
5. Change capitalization, spaces, underscores, and numeric padding independently. Confirm that only the approved transformations affect the result.
6. Test the FIFO rule separately with repeated valid identities so queue order never compensates for a failed identity comparison.

Release automatic matching only when every positive pair produces one candidate and every negative pair produces zero. Any input producing multiple candidates belongs in the exception workflow until the underlying identity rule is made explicit.

FAQ