Inleiding
Profit beschikt over een module
Profit-Kenmerk waarmee we een Artikel verder uniek kunnen maken naar een set van maximaal 3 Kenmerken. Kenmerken staan ons toe om meerdere vergelijkbare uitvoeringen van eenzelfde produkt te kunnen registreren en logistiek te kunnen manipuleren, zonder dat we daarvoor een nieuw Artikel hoeven aan te maken.
Voorbeeld:De kracht van zo'n Kenmerk leggen we uit aan de hand van een voorbeeld met een Kenmerk (L) Lengte.
Stel, we hebben een PVC HWA (hemelwaterafvoer) buis met een doorsnede van 100 mm, welke we inkopen op een lengte van 6 meter. De omschrijving van ons Artikel wordt ""PVC HWA buis 100mm Lengte 6,000 M1".
We zagen 2 meter van deze buis af, en houden daarna eenzelfde PVC HWA buis over (diameter 100 mm), maar nu in 2 lengtes: 2 meter en 4 meter.
Zijn dit nu nieuwe Artikelnummers geworden?
Als we de lengte elimineren uit de omschrijving, en deze Lengte als
Kenmerk opnemen bij het Artikel, krijgen we feitelijk 1 Artikelnummer met als omschrijving "PVC HWA buis 100mm" en we hebben een separaat veld waarin we de lengte definiëren (L) 6,000 M1. Zagen we nu 2 meter van deze buis af, dan blijft het Artikelnummer gelijk, maar resulteert dit op voorraad in:
1x "PVC HWA buis 100mm" (L) 2,000
1x "PVC HWA buis 100mm" (L) 4,000
en, vanzelfsprekend kunnen we dan ook nog diezelfde buis op voorraad hebben met een lengte van 6 meter:
1x "PVC HWA buis 100mm" (L) 6,000
In de omschrijving van ons Artikel treffen we ook een diameter aan: 100 mm. We zouden er dus ook voor kunnen kiezen om ons Artikel met 2 Kenmerken uit te rusten:
(L) Lengte
(D) Diameter
Het Artikel zelf zou dan niet veel meer hoeven te bevatten als "PVC HWA buis", en in de Kenmerken registreren we (L) 6,000 (D) 0,100.
Met 1 artikelnummer kunnen we dan iedere hemelwaterafvoerbuis, ongeacht Lengte en Diameter registreren op voorraad.
En, indien gewenst hebben we dan nóg een Kenmerk over. Zo zouden we bijv. ook "een kleur" (grijs of wit) kunnen opnemen in een Kenmerk.
Hoewel al snel geldt "we kunnen wel alles in een Kenmerk proppen", is dat toch niet de bedoeling. Het uitrusten van een Artikel met Kenmerken is een complexe zaak welke vooraf uitzoekwerk en vnl. testwerk vereist, waarbij rekening dient te worden gehouden met het hele logistieke proces. Bedenk dat als bijv. een witte PVC buis duurder is dan een grijze, en deze met een opslagtarief werkt t.o.v. die grijze, we een dergelijke prijsopslag misschien wel niet aankunnen, wat er voor kan zorgen dat we dus zo'n kleur maar niet als Kenmerk moeten definiëren. Daarmee zeggen we niet dat we geen kleur in een Kenmerk kwijt kunnen, in tegendeel zelfs... we hebben klanten die RAL kleuren in Kenmerken stoppen, "Kleurgroepen", juist omwille van de prijs etc.
Naast Lengte x Breedte x Dikte worden kenmerken ook gebruikt voor:
* Omwikkelde maat
* Kleur
* Kleurgroep
* Merk
* Etiket
* Aantal pakketten per Bundel
etc.
en kunnen formules worden gebruikt om een aantal Voorraadeenheden te berekenen m.b.v. de Kenmerken. Zo geldt bijv dat het aantal M2 kan worden berekend door een vermenigvuldiging van de Kenmerken (L) Lengte x (B) Breedte. Het gaat zelfs nog zo ver zoals in onderstaand voorbeeld, waarbij een standaard Profiel is uitgerust met een Kenmerk (L) Lengte, een Profieltype (P), en een Kleur (K). Alle Profieltypes (zoals TTE56) zijn weer als Artikel gedefiniëerd en hebben ook weer Kenmerken, zoals een Omwikkelde Maat. Het aantal M2 van het standaard profiel wordt nu via een formule berekend door de Lengte (Kenmerk van dit Artikel zelf) te vermenigvuldigen met de waarde van het Kenmerk (O) Omwikkelde Maat, welke is opgeslagen bij het artikel waarvan het Artikelnummer als Kenmerkwaarde wordt ingevuld bij Kenmerk (P) Profieltype.
Per Artikel kunnen we instellen wat de Behoefteregistratiewijze is; hiermee kunnen we aangeven of Profit om de Kenmerken moet vragen als we een order invullen, of niet? Daarnaast kan ook worden aangegeven of bepaalde Kenmerkwaarden 'vast' bij een Artikel horen òf dat ze mogen worden aangepast.
Als we een Artikel hebben toegevoegd (met zijn Kenmerken) kunnen we vervolgens per Artikel-/Verschijning de waarden van de Kenmerken nog overrulen. In een gegeven voorbeeld kiezen we er tóch voor om een Verschijningsvorm óók een lengte te laten bevatten; een Artikel heeft bijvoorbeeld de volgende Verschijningsvormen:
PL2.600 = Pakket met lengtes van 2,600 meter
PL4.000 = Pakket met lengtes van 4,000 meter
Omdat het Artikel in principe op iedere Lengte op voorraad terecht kan komen, en we op Artikelniveau niet kunnen afdwingen hoe 'lang' het Artikel is, zullen we het Artikel altijd op een lengte van 1,000 moeten definiëren. Bij bovenstaande twee Verschijningsvormen kunnen we vervolgens lengtes opnemen van respektievelijk (L) 2,600 en (L) 4,000. Verkopen we nu ons produkt in een PL4.000, dan weet Profit meteen dat de lengte die daarbij hoort (L) 4.000 moet zijn.
Achteraf aanbrengen van Kenmerken?
Zoals gezegd maken Kenmerken een Artikel verder uniek. Als we deze Kenmerken van scrap af aan hebben opgenomen bij het Toevoegen van ons Artikel, is er op zich niets aan de hand. Maar, wat nu als we achteraf bedenken dat we ons Artikel met Kenmerken willen laten werken? Het achteraf wijzigen van de Kenmerken van een Artikel is jarenlang dichtgespijkerd geweest. Zodra we dit proberen resulteerde dat in een melding dat het wijzigen van Kenmerken niet was toegestaan, omdat dit het hele logistieke proces kan verstoren. Maar ja... is het niet handig dat we bij een bestaand Artikel geen Kenmerken kunnen opnemen. Klanten vragen soms om die mogelijkheid, en, er zijn situaties waarin dit op zich ook best mogelijk is (maar even goed in andere situaties niet!).
Zoals ook nu konkreet het geval is: voor een bepaalde klant welke verf produceert (Mengrecepturen) zijn we nu bezig met een opzet om zelfs Kenmerken toe te staan bij Mengrecepturen (iets wat voorheen niet mogelijk was). Een Artikelnummer betreft een verf produkt, in een bepaalde kwaliteit en kleur. Het (nieuw) op te nemen Kenmerk wordt een Kenmerk waarin we een Emballagset-id gaan registreren. Het forum topic waarin deze funktionaliteit wordt uitgelegd is er t.t.v. dit schijven nog niet (opdat het opnemen van de daartoe benodigde Kenmerken éérst ontwikkeld moet zijn), maar, de achterliggende gedacht is in het kort als volgt:
Een zusterbedrijf in Italië verkoopt verf aan een schip. We verkopen "het artikel" in een Verschijningsvorm "blik 20 liter". Maar... de klant in Italië heeft specifieke Emballage wensen omtrent dit blik. Laten we maar eens stellen dat deze klant de verf graag ontvangt in een "rood blik, met een geel deksel". In het nieuwe maatwerk wordt dit opgelost met een Kenmerk "Emballageset-id". Italië kan voor deze klant een Klant-/specifieke Emballageset aanmaken en daarin vastleggen dat het 20 liter blik een rood blik en een geel deksel moet bevatten. Aan deze klantspecifieke Emballageset wordt een Id toegekend, en dit Id wordt via een Kenmerk (E) = Emballageset-id toegevoegd aan de bestelling op de Verkooporder. Dit produkt wordt vervolgens ingekocht bij de moedermaatschappij in Nederland, en dus daar een blik verf ingekocht met eveneens een Kenmerk (E) én het bijbehorende Id welke een verwijzing naar het "rode blik met gele deksel" bevat. Op die manier ontstaat er (Intercompany) in de moedermaatschappij ook een order voor dat produkt met dat Kenmerk, en weet de moedermaatschappij dat ze die behoefte moet dekken d.m.v. een Produktieorder. De Produktieorder herkent het Kenmerk Emballageset, en toont de Gebruiker die gaat afvullen welke hoeveelheid er in 20 liter blikken met een rood blik en geel deksel moet worden afgevuld.
Bedenk vervolgens dat ons Artikelbestand misschien wel 20.000 verschillende Artikelen bevat, welke we nu allen feitelijk willen kunnen uitrusten met een extra kenmerk: (E) Emballageset-id, en dat zoiets eigenlijk 'geblokkeerd' is... Dat is niet handig... En derhalve is destijds het idee voor een Kenmerkrun geboren...
Kenmerkrun
Zoals gezegd maakt een Kenmerk een Artikel logistiek verder uniek. Zonder een nieuw Artikel te hoeven registreren levert een andere Kenmerkwaarde feitelijk wel een nieuw 'artikel' op. Wat we hiermee bedoelen is dat als we een Verkooporder hebben gemaakt met daarop onze PVC HWA buis op een lengte 6,000 meter, we *dus* ook een buis met een lengte van 6 meter zullen moeten leveren, en niet een buis van 2 meter of 4 meter (laat staan beide, omdat dat ook 6 meter is :-). De Kenmerken van het Voorraaditem welke we gaan leveren, moeten dus overeenkomen met de Kenmerken die op de order behoeftig zijn.
Stel nu dat we (achteraf) bij een bestaand Artikel een Kenmerk gaan opnemen, dan
moet dit Kenmerk in de hele database worden aangebracht. Immers, als het Artikel met een Kenmerk (L) gaan uitbreiden, dan moet feitelijk het hele pakket worden aangepast, omdat overal in het pakket waar dit Artikel gebruikt is, zal het Kenmerk (L) moeten worden opgenomen. Dat is feitelijk de taak van de Kenmerkrun...
De Kenmerkrun is een run die ooit bedacht is om dit probleem op te lossen, maar, welke nog steeds allerlei beperkingen heeft, en wij niet op voorhand kunnen garanderen dat ze ook in uw omgeving gebruikt kan worden. Middels aanvullend maatwerk kunnen we uitzonderingen ondervangen, kunnen we nieuwe tabellen afvangen, maar, het doet niets af aan alle mogelijke kombinaties die kunnen optreden. De Kenmerkrun is daarmee een erg gevaarlijke run, die voor iedere omgeving goed getest moet worden (in de testbestanden) alvorens ze in de Produktieomgeving wordt gebruikt. Wij pretenderen overigens niet dat de run
iedere situatie aan kan; in tegenstelling juist... en juist daarom zijn wij al erg huiverig bij iedere aanpassing die aan deze run wordt aangebracht: terecht!
Als we eens simpel beginnen, bijvoorbeeld met de situatie die we nu konkreet aan de orde hebben... We willen bij een bestaand Artikel, welke helemaal nog geen Kenmerken heeft, een Kenmerk (E) Emballageset opnemen. Omdat we op Artikelniveau niet kunnen afdwingen om welke Emballageset-id het gaat, vullen we bij het Artikel geen defaultwaarde in. Het Kenmerk op Artikelniveau bevat dus feitelijk de waarde "XE ". Wel, deze situatie is een piece of cake. We moeten in iedere tabel waarin er gegevens 'open' staan inzake dit Artikel alle records waarin aan dit Artikel wordt gerefereerd uitbreiden met een Kenmerk "XE ". We hoeven ons geen zorgen te maken om welke waarde er in lopende orders opgenomen wordt, immers, dat kan het systeem toch niet bepalen. Wel geldt dat overal het Kenmerk "XX " moet worden gewijzigd in "XE ". Stelt niets voor... Maar toch...
De Kenmerkrun vinden we vanuit Hoofdmenu-1-1-1-2-5. Het eerste waar we tegenaanlopen is dat deze funktie alléén toegankelijk is indien de Gebruiker expliciet is geautoriseerd voor deze funktionaliteit. Daarbij beschrijft de foutmelding expliciet niet voor welke Funktie die autorisatie nodig is, puur vanwege het feit dat we willen voorkomen dat dit oneigenlijk gebruikt wordt; je kunt er de data mee verknallen... Als we deze Kenmerkrun opstarten, is het eerste wat opvalt, dat we voor allerlei tabellen middels een J/N rubriek kunnen aangeven of de Kenmerken naar die Tabel moeten worden doorgekopieerd of niet. Nou... top... en dit zal ongetwijfeld met bepaalde bedoelingen zo zijn geïntroduceerd, maar, het is tevens de eerste mogelijkheid om er een flinke puinhoop van te maken. Immers, als we ons Kenmerk wél aanbrengen in de Verkooporderregels maar
niet in de Voorraad, kunnen we onze voorraad nooit meer leveren. Sterker nog, als een funktie als een 'Handmatige Voorraadmutatie' zou kontroleren op de Kenmerken, heb je maar zo kans dat we een Voorraaditem niet eens meer kunnen verwijderen omdat de Kenmerkgegevens niet kloppen...
Alvorens wat dieper op de redenen hiervoor in te gaan, eerst nog een andere Bedrijfsparameter:
Bij "Parameters Artikelen" hebben we de mogelijkheid om met een J/N rubriek aan te geven dat een Wijziging van Kenmerkgegevens bij het Artikel ook direkt door moet worden gekopieerd naar de 'overige' bestanden:
Als deze rubriek met "Ja" wordt gevuld, zal "Wijzigen Artikelen" onder water de Kenmerkrun opstarten, waarbij alle J/N rubrieken uit de vorige schermprint dan met "Ja" worden gevuld.
Voor diverse situaties zal er hier iets ontwikkeld zijn, maar, daarbij is het niet gezegd dat iedere situatie klakkeloos kan worden uitgevoerd, en ik denk dat we mogen stellen dat het al helemaal niet duidelijk is voor een Gebruiker hoe ze dit scherm nu precies wel of niet moet invullen. Juist vanwege het feit dat hier teveel funktionaliteit 'klantspecifiek' is ingebouwd, ontbreekt een goede duidelijke beschrijving, waarmee in dit topic een verandering in tracht te worden gemaakt. Het liefst willen we daarbij naar 1 algemene situatie, die voor iedereen wenselijk / bruikbaar is. Hierin probeer ik verschillende situatie te onderkennen:
1. Een Artikel wordt voorzien van een Kenmerk òf we verwijderen een Kenmerk bij een ArtikelWe hebben het hier over de situatie dat we van "XX " naar "XE " gaan, of andersom.
In 100% van alle gevallen mogen we nu (nee,
moeten we nu !) alle data door om dit Artikel te voorzien van een Kenmerk.
Een keuze om een tabel m.b.t. een J/N veld al dan niet te verwerken slaat nergens op; de database zal hoe dan ook moeten worden aangepast.
2. Een Artikel hééft al een Kenmerk, maar we wijzigen de defaultwaarde.Tsja... dit is er dus zo een waarvan we ons moeten afvragen of dat wel verstandig is om te doen...
Neem maar eens ons voorbeeld van de PVC HWA buis van 6 meter. Stel dat we tóch bij het Artikel (L) 6,000 M1 hebben ingevuld, en we wijzigen deze default naar (L) 4,000, dan zou "doorkopiëren naar voorraad en orders" feitelijk impliceren dat iedere buis die op voorraad ligt, ineens geen 6 meter lang meer is, maar 4 meter lang. Dat willen we dus niet, dus, dit moeten ze zéker niet doorkopiëren! En, bij de gratie dat dit doorkopiëren standaard gebeurd als de Bedrijfsparameter 'Wijziging Kenmerken ook in overige Bestanden J/N' dit standaard doet, loopt dit hopeloos fout!
Zo zijn er ook klanten die het Artikel (informatief) voorzien van een extra Kenmerk (M) Merk. Nu stappen we over op een andere Leverancier, en willen we feitelijk 'het merk' wijzigen. Houdt dat dan in dit dit daarna overal op voorraad en in de lopende orders gewijzigd moet worden? Nee. Natuurlijk niet. In theorie zal zoiets ervoor kunnen hebben gezorgd dat we met allerlei J/N rubrieken kunnen aangeven wat er wel/niet gewijzigd moet worden. Met al die J/N rubrieken zouden we immers kunnen aangeven dat de bestaande voorraad gewoon van het oude merk voorzien moet blijven, maar, dat we in de lopende Inkooporders het produkt willen voorzien van het nieuwe merk, opdat de nieuwe items met een nieuw merk worden ingekocht.
Ook deze situatie kan
juist de keuze zijn geweest waarom we géén historie konverteren (zie verderop), immers, het zou er voor zorgen dat alle orders waarop we in het verleden merk X hebben ingekocht en verkocht, nu ineens worden aangepast naar merk Y, terwijl dat niet de werkelijkheid is; we raken dus informatie kwijt als we de Kenmerkrun opstarten!
Eigenlijk volgt hier als regel uit:
we mogen nooit en te nimmer de defaultwaarde van een Kenmerk wijzigen !Maar ja... Nu registreren we welk soort etiketsticker er op ons produkt zit. We produceren voor diverse supermarkten een zgn. paprika stoplicht; een zakje met een rode, een groene en een gele paprika. Alleen, we kunnen hier verschillende stickers op plakken; een met een logo van de Albert Heijn, een met een logo van de Coop, van Dirk v/d Broek, de Lidl, de Aldi, noem maar op... Dan kunnen we dit produkt ook nog gewoon in een zakje verkopen, zónder dat er een sticker op zit met een logo van een van deze specifieke klanten. We kiezen ervoor om op Artikelniveau duidelijk te maken dat het Artikel standaard 'etiketloos' is, en registeren als default Kenmerkwaarde "GEEN". Uit voorbeeld #1 volgt dat het toevoegen van een Kenmerk aan een Artikel welke nog geen Kenmerk had zou moeten kunnen. Alleen één probleem... we maken een typefout... In plaats van dat we "GEEN" intypten, typen we "GENE" in. Dit Kenmerk 'etiketsticker' wordt nu in de hele database aangebracht, en overal komt die defaultwaarde "GENE" te staan. Oops. Hele database verziekt (voor dat Artikel). Tsja... op dat moment ontstaat vanzelf weer de behoefte om een defaultwaarde bij het Artikel te kunnen wijzigen (van GENE naar GEEN) en dit door te kopiëren naar alle tabellen! Maar ja... dit werkt dan feitelijk alleen "omdat er nog geen data staat in al die tabellen", immers, zou die er wel zijn, dan is alles wat we in het verleden verkocht hebben met Kenmerkwaarden "ALDI", "LIDL", "AH", "DEKA", "DIRK" gewijzigd in "GEEN".
Moraal blijft hier eigenlijk:
we mogen nooit en te nimmer de defaultwaarde van een Kenmerk wijzigen !Tot vandaag werden de Kenmerken in 'de database' aangepast zodra òf de Kenmerkletter wijzigde (de XX wordt XE) òf indien een van de Kenmerkwaarden v/h Artikel werd gewijzigd. Vandaag is gebleken dat ook dát hopeloos fout kan gaan... nl. in de situatie dat we bij een bestaand Artikel met Kenmerken nóg een Kenmerk opnemen. En dat is typisch de situatie die nu ook in een praktijk voorbeeld voor ogen ligt, en aanleiding is voor dit topic.
We willen nú nl. alle Artikelen voorzien van een Kenmerk (E) Emballageset-Id. Als dat maatwerk eenmaal klaar is, staat er al een volgende aanpassing op de agenda, nl. dat we ieder Voorraaditem (en behoefte) óók uniek willen gaan maken naar een definitie van de Labels (L) die op het blik zitten. Bij die Labels is het idee dat ook deze een Identifikatie gaan krijgen waaraan vervolgens (1:n) meerdere Labels kunnen worden gehangen. Denk hierbij aan het feit dat er een groot of een klein label op moet (afhankelijk van de grootte v/h blik), dat er een Label op moet die het produkt identificeert, en dat er een label op moet met Gevarenetiketten, in de taalkodes die gesproken worden in het land van bestemming. M.a.w., als we iets aan China leveren, zal er een ander Label op moeten dan als we het produkt in Europa leveren. Het feit dát we nu een tweede Kenmerk opnemen, houdt in dat de Kenmerkrun moet worden opgestart (als dat al niet automatisch gebeurd o.b.v. de bedrijfsparameter), maar áls die Kenmerkrun werd opgestart, werden ALLE Kenmerken opnieuw opgenomen in de lopende orders en voorraad; ofwel, waar we misschien net met veel pijn en moeite een hele database hadden opgebouwd met behoeftes voor specifieke Emballagset-id's zouden die allen weer worden gereset naar hun defaultwaarde! Dit loopt in de versie vóór augustus 2019 dus fout!
Ondanks dat we heel huiverig zijn met aanpassingen in deze Kenmerkrun, is er nu toch een aanpassing aangebracht in de basis opzet van de Kenmerken run.
1. Alle J/N veldjes m.b.t. 'in welke tabellen moet de data worden aangepast' worden genegeerd zodra een Artikel van nieuw Kenmerk (de letter zelf) wordt voorzien. Ofwel, als we "XX" wijzigen in "XE" of "XM", dan
moet dat Kenmerk in de database worden gewijzigd. Dus, zélfs als u zegt 'pas de voorraad maar niet aan' zal deze tóch worden aangepast, immers, de database moet nu eenmaal voorzien zijn van dezelfde Kenmerkletters van het Artikel.
2. Als de Bedrijfsparameter 'Wijzigen Kenmerken in Overige Bestanden J/N' met 'Ja' is gevuld, zullen alle 'Ja' tjes per heden standaard worden gewijzigd in "Nee" tjes. Immers, regel #1 zorgt ervoor dat als het écht nodig is, de Kenmerken sowieso worden aangebracht in alle tabellen, dus J/N bij een specifieke Tabel op Ja of Nee zetten doet eigenlijk niets. Wél kunnen we deze J/N setting per Tabel nu gebruiken voor de situaties waarin we een Kenmerk-
waarde op Artikel of Artikel-/Verschijningsvorm hebben gewijzigd, om vervolgens alleen in dié situatie die data door te kopiëren naar de tabellen waarvan de gebruiker vindt dat dit doorgekopieerd moet worden.
Let ook hier op: als we klakkeloos alle Tabellen op "Ja" zetten, en de Artikelselektie op # t/m ZZ laten staan, zal alsnog de op dat moment gelden Kenmerkwaarde van iedere Artikel-/Verschijning die aan die selektie voldoet, worden doorgekopieerd naar de tabellen waarvan U heeft aangegeven dat er gekopieerd moet worden. Dit zal dan (dus) alsnog alle eerdere orders voor een Merk "ALDI", "COOP", "DEKA" etc. terugzetten naar de default van het Artikel. Kortom, dit blijft niet wenselijk, behoudens misschien voor de situatie dat we bij het opzetten van het Artikel een typefout hebben gemaakt in de default Kenmerkwaarde (GEEN was ingevuld als GENE). Resumerend; globaal mag worden gesteld:
- Een Kenmerk opnemen bij een Artikel welke nog geen Kenmerk heeft, is toegestaan
- Een Kenmerk verwijderen bij een Artikel welke al wel een Kenmerk heeft, is toegestaan
- Een (default) Kenmerkwaarde wijzigen op Artikelniveau is eigenlijk verboden!
Tip:Stel dát we te maken hebben met een Artikel waarbij we een nieuw Kenmerk (S) GEEN zouden willen opnemen, maar waarbij we abusievelijk (S) GENE hebben ingetypt, en we allerlei voorraad en orders hebben voor (S) GENE omdat dit bij het opnemen van het Kenmerk is doorgekopieerd naar de lopende orders, kan kunnen zo'n fout beter herstellen door dit Kenmerk éérst formeel weer te verwijderen (we veranderen het Kenmerk "XS" weer terug naar "XX"' dit zal 'de database ook weer aanpassen naar "XX") en daarna nemen we opnieuw het Kenmerk (S) GEEN op. Het is dan voor iedereen duidelijk dat "alle data" gewijzigd mag worden, waarbij Profit nooit voor rare keuzes zal komen te staan met 'mag het hier wel of niet'.
V.w.b. de Kenmerkrun, de funktie met alle J/N velden, laat deze lekker allemaal op "Nee" staan om "veilig" te spelen; ondanks dat alles op "Nee" staat zal Profit toch de opname en verwijdering van Kenmerken afhandelen.
Tip 2:Zoals gezegd zijn er twee manieren om een bij een Artikel (nieuw) opgenomen Kenmerk door te kopiëren naar de rest van de database; de eerste methode is dat dit automatisch gebeurd op basis van de Bedrijfsparameter die zegt dat dit direkt moet gebeuren zodra we een Artikel wijzigen; de tweede manier is het expliciet opstarten van de Kenmerkrun (Hoofdmenu-1-1-1-2-5). Hoewel het in principe véél handiger is dat aanbrengen 'meteen' gebeurt, kan het ook handiger zijn om dit juist achteraf te doen met de Kenmerkrun. Die Kenmerkrun biedt in ieder geval een optie waarmee we kunnen aangeven dat we alle wijzigingen nog niet meteen moeten aanbrengen in de Database. Als rubriek "Wijzigingen uitvoeren J/N" op "Nee" blijft staan, kunnen we in een logfile terugvinden wát er allemaal in welke tabel zal worden aangepast. Op die manier kunnen we zónder daadwerkelijk te verwerken tóch visueel kontroleren of we niet 'teveel' aanpassen. Die optie is er niet als de Kenmerken automatisch worden doorkopiëerd vanuit het Wijzigen van het Artikel.
Geen historie
Om performance redenen is er ooit voor gekozen dat de Kenmerkrun alleen alle 'Openstaande Orders' aanpast op de nieuw opgenomen Kenmerken. Op zich voorkomt dit dat we een jarenlange historie record voor record moeten aanpassen op Kenmerkniveau, terwijl we die historie w.s. nooit zullen rapporteren op Kenmerkniveau. En, met dan afgesloten orders zijn "afgehandeld", hebben we het Kenmerk feitelijk ook niet meer nodig om "een Voorraaditem met de juiste Kenmerkwaarden" te kunnen leveren. In feite kreëren we hiermee dus bewust een inconsistente database, maar, tot op heden geen klachten van alle klanten die de Kenmerkrun gebruiken; geen klachten bij de gratie dat er geen funktionaliteit gebruikt wordt die de Kenmerken logistiek benodigd bij orders die zijn afgesloten.
Hoewel we ze niet kunnen verzinnen, zou het theoretisch zo kunnen zijn dat er rapportages zijn op Kenmerkniveau die niet juist (kunnen) werken als niet ook de historie is aangepast m.b.t. de geïntroduceerde Kenmerken.
LET OP:
Tsja... ook hier liggen weer wat beren op de weg... In hoeverre u ze tegenkomt, hangt af van hoe er met Profit wordt omgegaan...
Immers, we kunnen er wel mooi voor kiezen dat we sneller klaar zijn als we de hele historie niet hoeven aan te passen en ons te beperken tot 'stambestanden' en 'openstaande orders', maar, in praktijk biedt Profit op verschillende niveau's tools om gedane zaken te ontdoen. Zo kunnen we bijv. het Rapen van een Raaplijst terugdraaien. We doen dan net alsof er nooit geraapt is. Hetgeen geraapt was zal terug moeten worden gelegd op voorraad, en de order moet weer open worden gezet. Maar ja... die order wás afgesloten, en de nieuwe Kenmerken zijn daar niet in opgenomen. 'Terugdraaien Levering' weet van zichzelf niet dat de Kenmerkgegevens ineens gewijzigd zijn, en dus komt het produkt terug op voorraad zónder de nieuwe kenmerkgegevens. Zo ook zal de Verkooporderregel niet op de nieuwe kenmerken zijn aangepast. Eigenlijk zou nu opnieuw een Kenmerkrun moeten worden gedraaid...
Geen Artikelen met Formule Werkelijke-Inhoud
Ook handig om te weten is dat de Kenmerkrun alleen Artikelen verwerkt die met Kenmerken werken die
niet van invloed zijn op de bepaling van het aantal Voorraadeenheden. Met andere woorden, de Kenmerkrun wijzigt Kenmerken, maar past geen hoeveelheden aan! Artikelen die in rubriek 'Formule Werkelijke Inhoud' een formule bevatten (een andere waarde dan <leeg>, <1> of <1*1>) zullen derhalve niet worden verwerkt via de Kenmerkrun.
Niet in alle Tabellen 
Zoals in het begin uitgelegd, is de Kenmerkrun feitelijk ontstaan om tóch iets te kunnen verwezenlijken wat anders dichtgespijkerd was: het achteraf kunnen aanbrengen van Kenmerken bij een Artikel. Niet voor niets is daar de melding ingebouwd dat je daarmee het Logistieke proces kunt verstoren; Kenmerken zitten in het hele pakket verweven. De Kenmerkun is in eerste instantie opgezet om de nieuwe Kenmerken aan te kunnen brengen in een beperkt aantal Tabellen, welke in een later stadium nog eens zijn uitgebreid met een aantal andere tabellen. Tabellen welke overigens zijn opgenomen 'omdat de klant voor wie de Kenmerkrun ontwikkeld is' deze benodigde.
Nog steeds geldt dat we bij het achteraf opnemen of wijzigen van Kenmerken het logistieke proces kunnen verstoren; daaraan is niets veranderd. We moeten zélf dus dondersgoed weten waar we mee bezig zijn, en in welke situaties we wel/geen Kenmerkrun mogen gebruiken. Daarbij zullen we in de Testbestanden eerst goed moeten testen of wel
alle Tabellen, zoals die bij uw implementatie gebruikt worden, worden aangepast (als dat nodig is). Vanzelfsprekend is het daarbij eigenlijk ook een must om te weten welke Tabellen wel of niet aangepast worden, en voor welk deel. Hieronder volgt een opsomming:
Tabellen welke wél worden aangepast:LOAR - Artikelen
LOVA - Artikel-/Verschijningen
LOVR - Verkooporderregels, alleen v.w.b. de openstaande regels danwel het deel wat op een Raaplijst staat
LOLR - Raaplijstregels, alleen v.w.b. de openstaande regels
LOCL - Gereserveerde Charges, alleen v.w.b. de openstaande regels.
LOOP - Produktieorder Output, alleen v.w.b. de openstaande regels
LOPR - Produktieorder Input, alleen v.w.b. de openstaande regels
LORT - Receptheaders
LOAB - Receptregels
LOVI - Voorraaditems
LOKD - Kenmerkdomeinen
LOKA - Klient-/Artikelen
LOIR - Inkooporderregels, alleen v.w.b. de openstaande regels
LOSL - Stuklijsten
LOHI - HPP Items
LOLD - Routeplanning, alléén indien de Behoefteregistratiewijze géén 1, 2 of 3 bevat!!!
LOTL - Routeplanning, alléén indien de Behoefteregistratiewijze géén 1, 2 of 3 bevat!!!
LODA - Prijs-/kortingsafspraken verkoop
LOPL - Prijs-/kortingsafspraken inkoop
LOFR - Faktuurregels, alleen v.w.b. de openstaande Fakturen
Tabellen welke niet worden aangepast:Tsja... kortweg gewoon: 'de rest'. Maar... om enigzins een idee te geven van de omvang daarvan:
LO0K - Geprintte beschikbaarheid Klient-/Artikel
LO2L - Optimalisatie regels
LO2O - Optimalisatie voorstellen
LOAH - Historische Receptregels
LOAM - In P.O. Afgeboekte Materialen
LOAO - Aanvraag Onderdelen
LOAP - Artikel-/Produktielijn
LOAZ - Resultaat VTV Berekeningen
LOBD - Koppeling Bewerking-/Produktielijn
LOBH - Elementaire Behoeftebasis (wordt niet meer gebruikt)
LOBW - Bestelniveau's Artikel-/Verschijning
LOCD - Technische documenten Debiteur
LOCP - Charges-/Produktieorders
LODL - Document/Land
LODR - Werklijstregels
LODS - Staffels Prijs-/kortingsafspraken
LOEL - Emballage-/Leveringen
LOEM - Emballage Mutaties
LOET - Etiketten
LOFJ - Import Artikelen
LOGK - Klienten/Artikelgroep
LOHA - Historische Artikelen
LOHB - Automatische aanvullingen Raapvloeren
LOIH - Historie Individueel Materiaal
LOIL - Inkoop-/Leveringen
LOIW - Telersbonnen
LOJD - Te reserveren Art-/Vrs-/Kenmerken Debiteur
LOKN - Koppeling Produktielijn-/Norm
LOKO - Klachtorderregels
LOLW - Geleverde Werkorderregels
LOMI - Gegenereerde Voorraaditems
LOOA - Offerteregels
LOOK - Offerteregels
LOOM - Ontvangstmutaties
LOOO - Omvorm Opdrachten (oude versie)
LOOV - Externe Verplaatsopdrachten
LOPD - Prijzen-/Debiteuren
LOPK - Prijs-/Kortingsafspraken
LOPO - Produktieorders
LORN - Produktielijn-/Normen
LOSH - Historische Samengestelde Artikelen
LOSI - Stuklijsten individueel materiaal
LOSO - Staffels Ordergrootte
LOSV - Prijsafspraken Klient
LOTK - Verlengde Tekst Klient
LOVD - Inventarisaties
LOVJ - VVV Artikel-/Verschijningen
LOVM - Voorraadmutaties
LOVQ - Voorraadhoogte Bedrijven
LOVU - V-items Trefwoorden Charges
LOVZ - Zoeksleutels Voorraaditems
LOWR - Werkorderregels
LOYC - SSCC Charges
LOZU - Te reserveren Art-/Vrs-/Kenmerken
LOZV - VTV gegevens
Een hele waslijst dus... waarmee meteen al wordt aangetoond dat de Kenmerkrun feitelijk een inconsistente database kreëert. Is dat erg?
In theorie natuurlijk altijd, maar, in praktijk valt het misschien allemaal wel mee. Te meer als we in aanmerking nemen dat de Kenmerkrun al sinds 1995 bestaat en iedereen dié de run gebruikt, schijnbaar weet wat ze wel of niet mag doen...
In de lijst komen een aantal tabellen voor waarvan we ons zouden afvragen waarom die niet worden aangepast:
LOVM - Voorraadmutaties.
LOOM - Ontvangstmutaties
LOEM - Emballagemutaties
Zolang we de data in die tabellen alleen maar gebruiken om ergens weer te geven, en we de Kenmerken niet specifiek nodig hebben, dan kost het enkel tijd om dit soort bestanden aan te passen. Funktioneel missen we er op zich niets aan als het Kenmerk niet wordt toegevoegd, immers, voorheen hád het Artikel niet eens een Kenmerk, dus wat voor een kwaad kan het als deze mutatie dat ook gewoon aantonen?
In theorie geldt hetzelfde voor een tabel zoals
LOIL - Inkoop-/Leveringen. Feitelijk zijn dit ook gewoon de "Voorraadmutaties" van alles wat we op Inkooporders hebben ontvangen. Maar ja... Ook bij Ontvangsten van Inkooporders hebben we dan weer funktionaliteit waarmee we in staat zijn om een Ontvangst eruit te gooien. En nu? In LOIL zijn geen Kenmerken aangepast! Ah, dan moeten we die toch ook maar opnemen in de Kenmerkrun. Klinkt weer 'eenvoudig', maar bedenk nu dat bij Tabel LOIR (Inkooporderregel) alléén de Inkooporderregels zijn aangepast die nog open stonden! dus, vermoedelijk is de Inkooporderregel zélf ook niet aangepast (wat dan wel weer consistent zou zijn).
LOVD - Inventarisatie. Ook hier zo'n tabel waarvan je enerzijds kan zeggen 'hoe kan het werken als die niet ondervangen is', maar toch... er kan simpelweg als werkinstruktie worden gesteld dat als we een Artikel kwa Kenmerken gaan wijzigen, dat we dat niet moeten doen als er een Inventarisatie gaande is. Andersom... wilt u wél een Artikel van Kenmerken kunnen voorzien terwijl er een Inventarisatie gaande is, dan dient u dat kenbaar te maken, en zullen wij de Kenmerkrun (op nacalculatorische basis) moeten aanpassen zodat dit soort tabellen wél worden ondervangen.
LOHA c.q.
LOAH, voorbeelden van 'Historische tabellen'. En, die historie deden we niet. Ook hier geldt, dat dit helemaal niet fout hoeft te gaan, tot dat we misschien vanuit de Historie een oude versie van een entiteit gaan terugzetten; dat zal dan vast impliceren dat we opnieuw de Kenmerkrun moeten opstarten!
LOOA - Offerteregels... Als we weten dat we niets met Offertes doen, dan is dit vast geen probleem. Als we echter vóórdat we iets verkopen éérst een Offerte uitbrengen, en die Offerte uiteindelijk willen promoten naar een Verkooporder, tsja... dan moéten dit soort tabellen toch écht worden ondervangen in de Kenmerkrun.
LOET - Etiketten... één van de eerste Tabellen die binnen het huidige Scantrajekt intensief wordt gebruikt voor o.a. registratie van Subcharges. Ook een van de eerste tabellen die dus misschien wel moét worden aangepast. Aan de andere kant; één van onze klanten die deze run veelvuldig gebruikt, scant ook pallets, splits deze, kent nieuwe Subcharges toe bij splitsen, maar nimmer hebben we te horen gekregen dat er iets niet werkte. Misschien valt ook dit dus wel mee. Bedenk bijvoorbeeld dat een Barcode van een Voorraaditem bestaat uit o.a. EAN-Code en Chargenummer, en dat die EAN-code kan leidt tot een definitie van welke Artikel in welke Verschijningsvorm met welke Kenmerken.
Hoe dan ook, voldoende gewaarschuwd
Het zal ongetwijfeld allemaal best meevallen, maar, gebruik de omschrijvingen van deze tabellen om een indruk te krijgen welke funktionaliteit extra aandacht vergt.
Intercompany
Naast vertellen wat er allemaal niet kan, is de run m.i.v. heden ook nog met een mooie funktionaliteit uitgebreid.
Vanaf Augustus 2019 worden de Kenmerken ook doorgekopiëerd naar de Intercompany Bedrijfven! en om iets gedetailleerder te zijn: die (Intercompany Bedrijven) die onderdeel zijn van dezelfde Intercompany Definitie als het aktieve Bedrijf.
In ons praktijk voorbeeld hebben we te maken met een implementatie van Profit waarbij in totaal misschien wel 10 administraties (Bedrijven) worden geadministreerd. Drie van deze Bedrijven zijn tezamen in één Intercompany Definitie aan elkaar gekoppeld: "Nederland", "Italië" en "Turkije". Zoals we eerder al hebben uitgelegd was aanleiding voor dit topic de opname van een Kenmerk "(E) Emballageset-Id" waarbij Italië haar klantspecifieke Emballagewensen kon doorgeven bij haar bestelling bij "Nederland". Hieruit volgt al dat als we bij een bestaand Artikel (502AD0020) een Kenmerk (E) Emballageset-Id aan opnemen én we weten dat "Nederland", 'Italië" en "Turkije" bij elkaar kunnen inkopen, het zo
moet zijn dat hetzelfde Artikel in die andere Bedrijven óók van dit Kenmerk zullen moeten worden voorzien.
In de nieuwe versie kunnen we bijv. in onze Nederlandse administratie een Kenmerk (E) toevoegen aan het Artikel, waarna Profit automatisch ook dit Kenmerk zal opnemen bij hetzelfde Artikelnummer in de andere Intercompany Bedrijven. Op die manier hebben we Artikel altijd consistent ingericht binnen onze Intercompany Bedrijven.
