Laserlõikuse nimekiri Monitor ERP-st

G4 tabelid olid rootsikeelsete lühenditega: tootmistellimus oli torder_huvud, detail artikel, müügitellimuse rida korderrad. G5-s on need ManufacturingOrder, Part ja CustomerOrderRow, ja sama lugu on väljadega. Mõni vana tabel jagunes uues süsteemis kaheks, näiteks aadressid, ja mõni seos, mis oli varem eraldi vaates, on nüüd hoopis üks väli rea küljes.

Käisin raportid läbi ükshaaval, lihtsamast keerulisemani. Iga tabeli ja välja vaste panin kirja ühte kaardistusdokumenti koos sellega, kas see on kinnitatud päris andmete peal või alles oletus. Nii ei pidanud järgmise raporti juures sama asja uuesti välja uurima.

Mis ei töötanud: nime järgi arvamine. Tarnete nimekirjas tundus vana „päise detailinumbri” loogiline vaste olevat väli nimega PartConfigurationId, aga sellist välja detailitabelis polnudki ja päring kukkus. Õige vaste leidus alles siis, kui vaatasin müügitellimuse rea kõik 141 välja päris andmetega läbi. Sealt tuli välja ka see, et tootmistellimuse number, mis G4-s tuli eraldi vaatest, on G5-s otse rea küljes.

Üks asi jäi õnneks samaks. Joonise PDF-faili tee leitakse vanade failitabelite kaudu ja need on G5-s alles ning töötavad muutmata. Samuti ei vajanud muutmist ükski VBA abifunktsioon (pildi otsimine, PDF-i lisamine, filtrite koostamine), sest need ei puutu andmebaasi. Nii piirdus töö päringutega ja nimekirja kuju, mida laserlõikus kasutab, jäi samaks.

Mis ei töötanud: esimene kandidaat oli prioriteediplaani „Include” linnuke, sest see paistis ekraanil just õigete ridade juures. Otsisin andmebaasist kõik väljad, mille nimes on „include”. Neid oli üle viiekümne, puudumiskoodidest käibemaksumääradeni, aga ükski ei kuulunud tootmistellimustele. Monitori juhend kinnitas põhjuse: see linnuke on ainult ajutine valik, millega planeerija märgib read nupuvajutuse jaoks (näiteks ümberplaneerimine), ja andmebaasi seda ei salvestata. Ainus sarnane väli, „kas operatsioon on prioriteediplaanis”, oli kõigil 7 470 aktiivsel operatsioonil sama väärtusega, nii et see ei eraldanud midagi.

Mis lõpuks töötas: õige vihje tuli tellija poolt. Monitori API-s on tootmisoperatsioonil väli BundleId, mida API kirjeldus nimetab lihtsalt „operatsioonide kogumi ühiseks tunnuseks”. Kui planeerija kaasab read planeeringusse, saavad need ühise BundleId. Tavalistel ridadel on väli tühi.

Ka see polnud kuskil üheselt kirjas ja vale filter oleks vaikselt vajalikke detaile nimekirjast välja jätnud. Seega võrdlesin enne kasutamist Monitori ekraanil värviliselt märgitud ja tavalisi ridu andmebaasi kirjetega mitme töökäsu ja operatsiooni peal. Kõigil värvilistel ridadel oli BundleId olemas, tavalistel mitte ühelgi. Alles siis lisasin päringusse filtri BundleId IS NULL. Nüüd jõuavad nimekirja ainult need detailid, mida pole veel kellegi planeeringusse kaasatud.

Monitoris tähendab „R”, et operatsiooniks on materjali vaja, aga seda pole veel välja antud, ja „C”, et materjal on välja antud. Andmebaasis leidsin operatsiooni juurest välja, millel oli ainult kaks väärtust, 0 ja 1. Loogiline oletus oli, et 1 tähendab „materjal puudub”.

Mis ei töötanud: oletus oli täpselt tagurpidi. Kui võrdlesin tulemust Monitori ekraaniga, olid kõik „R” read nimekirjas „C”. Kogu andmebaasis oli 0-ga ridu umbes 921 000 ja 1-ga umbes 206 000, aga ainult arvude põhjal polnud võimalik öelda, kumb tähendus on õige. Seda näitas alles ekraan.

Teine lõks oli ridade kokkutõmbamine. Üks detail võib olla mitmel operatsioonil, millest ühe materjal on välja antud ja teise oma mitte. Kui sellised read kokku tõmmata, valib andmebaas nende seast suvalise ja märge on vahel õige, vahel vale. Nüüd on iga operatsioon eraldi real koos tellimuse numbriga, nii et märge kuulub alati õigele reale.

Nimekirjas peab detailikood olema sama kujuga nagu joonisefailide nimedes: detailinumber, punkt ja versioon, näiteks .r1 või .p0. Andmebaasis on see info kahes kohas. Osal detailidel on versioon juba numbri sees, teistel tuleb see tellimuse juurest eraldi versioonitabelist.

Lihtne otsi-ja-asenda siin ei aidanud, sest iga uus reegel tõi välja järgmise erijuhu. REV.1 tuleb teha .r1, aga PRE.0 tuleb teha .p0, mitte .r0. Kui versioon on juba numbri sees, ei tohi seda teist korda lisada, muidu tekib lõpp .r0.r0. Numbri sees võib versioon olla suure tähega (.R3, .P1) ja siis tuleb see teha väikseks, et nimekiri poleks kirju. Kui versiooni pole üldse, saab detail lõpu .p0.

Kirjutasin loogika, mis leiab versiooninumbri üles ükskõik millisest kujust, ja kontrollisin seda kõigi 107 variandi peal. Iga detail saab nüüd õige lõpu.

Versiooninumbri lisamine tõi kaasa veel ühe vea: andmebaasi ühendus (ODBC) katkestas päringu teatega „Invalid string or buffer length”. Otsisin põhjuse samm-sammult. Põhipäring töötas, ka versioonitabeli liitmine töötas, viga tekkis alles siis, kui versiooni tekst detailikoodi külge liideti. Lahendus oli teisendada tekstiväljad enne liitmist kindla pikkusega tekstiks, millega ühendus toime tuleb.

Makro kontrollis ainult neid ridu, mis olid parajasti nähtaval. Kui detail oli korra planeeritud ja seetõttu peidetud, ei vaadatud seda enam kunagi üle, isegi kui see planeeringust hiljem eemaldati. Ühe käivitusega seda ei märganud, sest peidetud ridu kogunes aeglaselt, päevade jooksul. Nüüd tehakse enne igat filtreerimist kõik read uuesti nähtavaks ja kontrollitakse üle.

Lisaks lõikas vana kopeerimine nimekirja 2000 rea juures ära, kuigi ridu oli üle 4600. Nüüd leitakse andmete suurus automaatselt.

Monitor salvestab kellaajad UTC järgi. Operatsioon, mis algab 11. märtsil Eesti aja järgi, on andmebaasis kirjas kui 10. märts kell 22.00. Vana päring võttis sellest lihtsalt kuupäeva ja detail sai päev varasema alguse. Lõppkuupäev tundus õige, sest see on salvestatud kella 21.59 peale ja jääb UTC järgi samale päevale. Nüüd teisendatakse aeg enne kuupäeva võtmist Eesti aega.

Monitor näitab kuupäevi kujul aasta, nädal ja päev: 26113 on 2026. aasta 11. nädala kolmas päev. Nimekiri näitab neid nüüd samas kujus, et keegi ei peaks peast ümber arvutama. Seadsin ka veerud samasse järjekorda nagu tootmistarkvaras. Lisandus ka tellimuse numbri veerg: nii on näha, kui sama detail on kahel eri töökäsul ja ainult üks neist on planeeritud.

Fail uuendab andmeid avamisel ja siis iga kahe minuti järel. Viimase uuenduse kellaaeg on alati näha ja kui ühendus katkeb, muutub see punaseks.

Osa vigu tuli Excelist endast. Andmeühenduse uuendamisel võib Excel veergude asukohti muuta ja OneDrive’i automaatne salvestamine võib käivituda keset makro tööd. Lisasin veakäsitluse ja kaitse automaatsalvestuse vastu, nii et pooleli jäänud töö ei jäta Excelit käsitsi arvutamise režiimi ega salvesta poolikut vahetulemust.

Mõõtsin enne, kui midagi muutsin. Kõik 199 päringut võtsid kokku vaid umbes 2,8 sekundit. Päris pidur oli Excel ise, kuhu andmeid kirjutati üks rida korraga. Kui kirjutada kõik korraga ühe massiivina, läks Exceli osa umbes 20 korda kiiremaks: 9,7 sekundilt 0,5 sekundile.

Valem ise on lihtne: uue lõppkuupäeva ja planeeritud lõppkuupäeva vahe tööpäevades, samas aasta-nädal-päev kujus, mida Monitor kasutab. Raske oli leida uut lõppkuupäeva ennast.

Mis ei töötanud: esimene valem andis õige vastuse (−2) just sellel tellimusel, mille peal seda proovisin. Järgmisel tellimusel, kus ekraan näitas 0, andis sama valem −9. Sealt edasi kontrollisin iga kandidaati mitme tellimuse peal korraga: tellimuse, sõlme ja operatsiooni kuupäevad, operatsiooni planeeritud päevade tabel ja prioriteediplaani ettepanekute tabelid. Mõni variant andis osale tellimustest õige vastuse, aga ükski ei andnud õiget vastust kõigile.

Kõige selgem oli üks tellimus, kus ekraan näitas −8 tööpäeva. Uus lõppkuupäev oli märtsi lõpus, aga selle tellimuse iga kuupäev andmebaasis oli aprillis. Otsitavat kuupäeva polnud seal lihtsalt olemas. Proovisin selle ka ise välja arvutada Monitori juhendis kirjeldatud järelejäänud tööaja valemiga, aga selle operatsiooni järelejäänud töö oli umbes kolm minutit. Sellega ei saa seletada ligi kahenädalast nihet.

Lõpuks andis vastuse juhend: uus lõppkuupäev arvutatakse iga kord uuesti hetke kellaajast, kõigi prioriteediplaanis eespool olevate operatsioonide järelejäänud ajast ja töökeskuste võimsusest. See on väike planeerimismootor Monitori programmi sees. Tulemust ei salvestata andmebaasi ja seda ei anna välja ka API. Andmebaasis on küll väli NewFinishDate, aga see oli tühi kõigil umbes 1,16 miljonil real.

Lihtsustatud asendus, ehk päevad tänasest planeeritud lõpuni, andis samal tellimusel −30, mitte −8. Selle asemel, et panna nimekirja number, mis on vahel õige ja vahel vale, jätsin selle veeru välja ja kirjutasin põhjuse üles. Vale hilinemise number on hullem kui number, mida pole.