Binnen Profit bestaat er een Kenmerkrun die gewijzigde Kenmerken op Artikelniveau kan doorkopiëren naar de openstaande orders en voorraad. Verderop in dit topic nog even wat mitsen en maren over de Kenmerkrun an sich, daar gaat dit topic nu niet over. Dit topic concentreert zich even enkel op de performance van die run.
Als we gebruik maken van de Kenmerkrun, dan zal het gewijzigde Kenmerk moeten worden gewijzigd op diverse plekken in de database. Hierbij is ooit de keuze gemaakt dat dit enkel in "openstaande" regels gebeurd; terecht? Geen idee, daar gaan we nu niet over, zie het stuk verderop.
In de ene tabel die gewijzigd moet worden (bijvoorbeeld Voorraaditems) kunnen we snel alle Voorraaditems van het te wijzigen Artikel doorlopen om deze aan te passen kwa Kenmerkwaarden. Er zijn echter ook tabellen waarbij dit minder snel kan. Een van die situaties betreft het aanpassen van de Kenmerken in Faktuurregels. Daarbij werden alle Openstaande Fakturen doorlopen om te kontroleren of het betreffende Artikel daar op voorkwam.
Voor de ADS versie van Profit geldt m.i.v. deze Releasnote dat voor het bepalen van de wel/niet aan te passen Faktuurregels één SQL Query wordt aangeboden aan de ADS Server. Deze geeft nu terug welke Faktuurregels er aangepast moeten worden, en op basis van dat resultaat past Profit de Kenmerken in die Faktuurregels aan (met logfile, en met Transakties als die aan de orde zijn).
Ofwel, funktioneel is er niets gewijzigd aan de Kenmerkrun, maar technisch gebeurd e.e.a. op een slimmere manier waarmee een gigantische performancewinst wordt behaald. In een specifiek praktijk voorbeeld is de benodigde tijd om 1 Artikel aan te passen gereduceerd van 20 minuten tot enkele seconden.
Merk echter op dat de aanpassing hier enkel een 'performance' aanpassing betreft, en zich niet uitlaat over de werking van de Kenmerkrun (waar vele haken en ogen aan zitten)!
In Profit kunnen Artikelen van Kenmerken worden voorzien. Kenmerken zijn niet verplicht (in welk geval een behoefte enkel op Artikel en Verschijningsvorm ligt) maar kunnen worden opgenomen om een behoefte verder uniek te maken.
Een paar voorbeelden van Kenmerken zijn:
* Lengte / Breedte / Dikte (bijv. 2,600 M1)
* Merk / Leverancier (bijv. Campina / Zuivelhoeve)
* Klant voor wie iets is ingekocht (Lidl / Aldi)
* Kleur v/h Artikel (Rood/Groen/Blauw/RAL9010)
* Profieltype (verwijzing naar ander Artikel, AL01.003)
* Klasse (70-90 / 80-100 / 90-110)
* Maat (36-37-38-39-40 etc).
Kenmerken maken de behoefte registratie aan een Artikel verder uniek; Kenmerken maken daarmee dus feitelijk het Artikel uniek! Als we als Artikel een Aluminium buis hebben, die als Verschijningsvorm "Bruut, ofwel niet gecoat" heeft, dan kunnen we dat Artikel op voorraad hebben in lengtes van 4,0 meter maar ook 2,6 meter, en eigenlijk is gewoon iedere lengte mogelijk. We kunnen volstaan met één Artikel, waarbij "de Lengte" als Kenmerk is opgenomen.
Omdat Kenmerken een Artikel uniek maken, geldt er een hoofdregel die zegt dat de Kenmerken van een Artikelniet gewijzigd mogen worden. Bedenk wat er gebeurd als we allemaal orders hebben ingevoerd voor een produkt die als eerste Kenmerk "Lengte" heeft, en wij gaan dát Kenmerk nu wijzigen naar "Kleur". Houdt dat nu in dat onze buis ineens 2,6 Meter Kleur bevat? Onzin. Dat kan niet.
Toch komt het voor dat er gebruiker zijn die een bepaald Artikel, welke vroeger geen Kenmerken had, nu wél van Kenmerken wil voorzien. We zouden bij onze buis met enkel Kenmerk "Lengte" ook een tweede Kenmerk willen opnemen die aangeeft in welke kleur deze is gecoat, en een 3e Kenmerk die aangeeft hoeveel micron laagdikte die coating is aangebracht. Het produkt wordt nu anders, en, we hebben inmiddels overal 'behoeftes' in het pakket staan die enkel op 'lengte' staan en die de overige Kenmerken niet zal herkennen. Als Kenmerken niet overeenkomen, kunnen behoeftes niet gedekt worden.
Zo is ooit een zgn. Kenmerkrun ontstaan die het de Gebruiker nu toestaat om een "blokkade" dat Kenmerken niet gewijzigd mogen worden enkel als "waarschuwing" te laten gelden, mits de Gebruiker daarna met een Kenmerkrun de gewijzigde Kenmerken doorkopieert naar de rest van het pakket.
Let op: Hoewel deze Kenmerkrun door velen naar tevredenheid wordt gebruikt, zitten hier m.i. veel te veel haken en ogen aan, die ervoor zorgen dat het best voor bepaalde situaties werkbaar kan zijn, maar evengoed voor nog meer niet! De Kenmerkrun zoals die is, is dus 'te eenvoudig' en zou, afhankelijk van de situatie, ongetwijfeld om veel meer informatie moeten vragen. Ook hoeft niet voor iedere situatie waarmee een Kenmerk wordt gewijzigd, "alles" hoeven te worden doorgekopieerd.
Stel dat we bij een Artikel een kleur registeren, en we zouden bij het Artikel een defaultkleur 'rood' hebben ingesteld en deze wijzigen naar 'groen', dan zal F1 ervoor zorgen dat alle behoeftes aan dit produkt alsmede de voorraad, worden omgezet naar behoeftes in 'groen'. Het mag duidelijk zijn dat dat niet wenselijk is.
Zouden we bij een buis op Artikelniveau een lengte van 2,600 hebben geregistreerd en levert de Leverancier die lengte niet meer, en willen we dat om die reden wijzigen naar 4,000, dan wijzigt alles naar 4,000 meter. Ook op voorraad wordt de buis langer.
Een ander groot bezwaar tegen de Kenmerkrun is dat deze zodanig is ontwikkeld dat deze alleen 'lopende orders' aanpast. Dus, bij een bestaand Artikel zonder Kenmerken, gaan we lengte en breedte opnemen, nemen op Artikelniveau een formele op die zegt dat de eenheid M2 is en berekend kan worden uit lengte x breedte, en alleen de openstaande orders worden voorzien van kenmerken. Alles wat al geleverd is blijft onaangetast (met als gevolg dat als er ergens moet worden omgerekend naar M2, dit niet mogelijk is omdat er geen kenmerken bij de reeds geleverde regels is opgenomen).
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOVAKGF1 | Omschrijving (nog) niet bekend | 06-03-2018 | 08-03-2018 |
