2998e35ddf
Machine data arrives as a Maximo asset export (validated against the WINC site) that must update existing machines in place, not create canonical per-table rows, so it does not fit the ShopDB-native/Azure/Thor CSV adapter path. Bulk edits to live machines also need an escape hatch, so the whole commit is journaled and can be undone as one batch. Add a dedicated dry-run analyzer, approval packet, resolver/suggest helpers, and a reversible writer/undo backed by a new importbatches/importjournalentries schema (with migration). Expose preview/commit/batches/undo settings routes and a matching frontend source card and panel, and surface the batch/journal contract through shopdb.api for plugins.
68 lines
3.0 KiB
Python
68 lines
3.0 KiB
Python
"""Alias and normalization tables for the WINC machine adoption dry-run.
|
|
|
|
This file is DATA, not logic. It is the single place a human edits when the
|
|
analyzer reports an unresolved value. Keep it boring: plain dicts, one entry per
|
|
line, lowercase keys. The analyzer lowercases and strips before it looks a value
|
|
up here, so keys here must be lowercase and already stripped.
|
|
|
|
Two independent problems get solved here:
|
|
|
|
1. eq1 -> business unit. The May export's eq1 column is a free-text value-stream
|
|
label (LG PARTS, SM SPOOLS, Large Spoo, HPTCR ...). It is dirty: truncated at
|
|
ten characters, inconsistently cased, and it does NOT match anything in the
|
|
live businessunits table (that table is a list of offices auto-created by an
|
|
earlier printer import). So every eq1 value must be mapped by hand to the
|
|
canonical business-unit name we want on the asset. A canonical name that does
|
|
not yet exist in the database is reported by the analyzer as "would need to
|
|
be created" - the analyzer never invents one and never writes one.
|
|
|
|
2. location code overrides. Most WM-<bay> codes resolve by simply dropping the
|
|
WM- prefix and matching a location by name (WM-J3 -> J3). A handful do not,
|
|
because the bay code carries a slash, a note in parentheses, or a room name
|
|
the location table spells differently. Those exceptions - and only those -
|
|
live here, mapping the RAW export location string to the exact locationname
|
|
already in the database.
|
|
"""
|
|
|
|
# eq1 (lowercased, stripped) -> canonical business unit name.
|
|
# The value on the right is what we intend to store; the analyzer checks whether
|
|
# it already exists in businessunits and flags the ones that do not.
|
|
EQ1_TO_BUSINESSUNIT = {
|
|
'lg parts': 'Large Parts',
|
|
'lg part': 'Large Parts',
|
|
'large part': 'Large Parts',
|
|
'sm spools': 'Small Spools',
|
|
'sm spool': 'Small Spools',
|
|
'large spoo': 'Large Spools',
|
|
'lg spools': 'Large Spools',
|
|
'lg spool': 'Large Spools',
|
|
'hptcr': 'HPT Rotor',
|
|
'bliskcr': 'Blisk Rotor',
|
|
'blisk': 'Blisk Rotor',
|
|
'leap x': 'LEAP-X',
|
|
}
|
|
|
|
# Raw export location string (lowercased, stripped) -> exact locationname in DB.
|
|
# Only for codes that do NOT resolve by dropping the WM- prefix. Leave a value
|
|
# as None to say "known to be unmappable, do not touch location for this row".
|
|
#
|
|
# The entries below the two None rows were promoted from the dry-run's
|
|
# high-confidence suggestions and verified to exist in the locations table. A
|
|
# slash-joined bay code (T6/U6) names two adjacent bays, but an asset carries a
|
|
# single locationid, so each maps to the FIRST (primary) bay - the deterministic
|
|
# choice a human confirmed. LD7W and LD6W are intentionally absent: they had no
|
|
# existing match and need a location created before they can be aliased.
|
|
LOCATION_OVERRIDES = {
|
|
'wm': None,
|
|
'wm-toolroom': None,
|
|
'wm-t6/u6': 'T6',
|
|
'wm-t9/10': 'T9',
|
|
'wm-u9/10': 'U9',
|
|
'wm-t4/u4': 'T4',
|
|
'wm-ld9w(ge90)': 'LD9W',
|
|
'wm-m6.3': 'M6',
|
|
'wm-l1-4': 'L1',
|
|
'wm-ld7w': None,
|
|
'wm-ld6w': None,
|
|
}
|