Syftet med att använda anpassningar är att styra om funktionaliteten i Balthzar på ett sätt som är företagsunikt, till skillnad från specialfunktioner, som är tänkta att användas av större mängd användare.
Anpassningar kan bestå av dels specialutvecklad funktionalitet och dels av att sätta specialfunktioner (härefter förkortat SF).
Exempelvis använder Vici Industrier en kombination av SF för att uppnå önskad funktion, enligt en "dammlucke-princip" som beskrivs nedan.
En maskin som konstant producerar artiklar stängs normalt sett inte av mellan orderbyten. Man vill dock att orderns antal ska hamna på rätt order för att uppföljningen ska bli rätt. Istället för att då stanna maskinen, stämpla ut ordern, starta en ny order och därefter starta maskinen, har en kombination av SF löst problemet.
De använda SF är följande : 25, 30, 31, 33.
Gör att ordrar som startas efter den första behandlas som om de startades samtidigt (De får samma startdatum.) Läs mer om SF 25 här .
Varnar operatören om att det är dags att byta order. Sker då producerat antal är lika med, eller större, än producerat antal. Effekten blir då att "dammlucke-funktionen" slår till. De transaktioner som från och med nu registreras, ska hamna på efterföljande order. För att få denna funktion att fungera bäst, krävs även en inställning i Balthzar Collector som gör att varje enskild cykel registreras direkt, istället för klumpvis, som är standard. Detta görs genom att sätta Direct qty save = yes i fliken Edit Machine:
Om inte denna flagga sätts, rapporteras en klump med cykler åt gången, vilket gör att Balthzar inte kan ge varningen/göra blockeringen i rätt tid.
Det kan tyckas att standardinställningen borde vara att registrera varje transaktion i samma ögonblick som de sker, men anledningen till att det inte görs är att det skulle orsaka en onödigt stor mängd transaktioner med tillhörande belastning på SQL-Servern som Balthzar använder sig av. Om Balthzar under exempelvis 30 sekunder mäter hur många cykler som sker, samt skickar 10 som ett värde i antalet cykler, blir det mer resurseffektivt än att skapa upp 10 separata databasposter. Skulle dessutom fler maskiner använda sig av samma funktionalitet blir problemet snabbt märkbart. Var gränsen går för hur många maskiner som kan ha denna inställning är främst beroende av vilken hårdvara som SQL-servern körs på.
Du kan läsa mer om SF 30 här.
Eftersom alla ordrar får samma starttid via SF 25, vill Vici att även alla ordrar som körs samtidigt får samma slutdatum. När en order avslutas, avslutas alla övriga ordrar samtidigt per automatik.
Du kan läsa mer om SF 31här.
Ny order som startas får samma startdatum som föregående orders slutdatum. Detta upplägg är ett krav för att anpassningen ska fungera. Eftersom den eventuella "överproduktion" som gjorts på den första ordern som startats måste hamna på någon order, matchas tiderna då dessa transaktioner skapas, till tiden på en viss order körts. För att kunna göra denna matchning måste alla ordrar som körs startas och avslutas "kant-i-kant" tidsmässigt, det vill säga att order1:s slutdatum blir order 2:s startdatum, även om detta inte motsvarar verkligheten.
Du kan läsa mer om SF 33 här.