Verschijningsvormen bij een artikel

[BKienhuis]

In ons systeem worden altijd standaard alle verschijningsvormen gekoppeld aan een artikel wanneer er een artikel wordt aangemaakt. Dit schijnt makkelijker te zijn dan dat men eerst uitzoekt welke verschijningsvormen er daadwerkelijk bij het artikel horen. De vraag is nu: is deze manier van werken van invloed op de performance van het systeem, bijvoorbeeld bij het draaien van behoefteruns e.d.? Met andere woorden, zou het veel beter zijn om de verschijningsvormen op te schonen?

[Wouter Rijnbende]

Tsja... wat zijn "alle Verschijningsvormen"...

Voor een Behoefterun geldt dat alleen iets wat behoeftig is uitgewerkt moet worden. Daar zal het niet zoveel mee te maken hebben. Aan de andere kant toch wel, omdat als er bijv. een Behoefte ongeacht de Verschijningsvorm is, het systeem op zoek zal moeten gaan naar een Verschijningsvorm die het best passend is. Het zou in theorie zo zijn dat er verschijningsvormen 'doorlopen' moeten worden, om vervolgens te konstateren dat deze niet ingekocht kunnen worden (omdat er geen leverancier aan gekoppeld is).

Door kombinaties op te nemen die eigenlijk niet mogelijk zijn zul je i.i.g. diverse overzichten vervuilen, en om die reden is dat sowieso niet handig. Kwa performance denk ik dat je hier weinig last van zult hebben, hoewel er natuurlijk vast wel funkties te verzinnen zijn waar het wel van invloed is op een performance.

[BKienhuis]

Alle verschijningsvormen wil zeggen dat er ca. 25 verpakkingen voor een artikel worden geselecteerd, waarvan er in de praktijk meestal 3 of 4 worden gebruikt. Dat het een vervuiling van het systeem is begrijp ik, het is alleen door de jaren heen zo gegroeid. We vroegen ons af of het zin heeft om te gaan opschonen. Dit gaat natuurlijk heel veel tijd kosten en als het dan uiteindelijk niets oplevert dan is het de vraag of we die tijd er wel in moeten steken.

[Wouter Rijnbende]

Tsja... toch een beetje kip-/ei verhaal...

Wil je nl. écht kunnen bepalen of dit wat uitmaakt, moet je eerst diverse funktionaliteiten uitvoeren met een database waarin die overbodige zaken niet zitten.

Kortom, véél tijd besteden om te bepalen wat overbodig is, véél tijd besteden om dit uit het systeem te verwijderen, om er vervolgens achter te komen dat je database misschien wel een paar MB kleiner geworden is, maar de boel er niets sneller op geworden is (of toch wel?).

Ik zou het omdraaien... pas als je een performance probleem hebt, en je gaat onderzoeken waarom de boel traag is, en daaruit blijkt dat dit wordt veroorzaakt door de vele onnodige Artikel-/Verschijningen, tjsa, dan kun je bepalen dat je die eruit moet halen. In het andere geval misschien niet te moeilijk doen.

[Peter Stordiau]

Wèl moeilijk doen ...

Wij hebben uit overerving diverse klanten waarbij dit zo is ingericht, en hebben meerdere keren meegemaakt dat dit onhandig is. Let wel, om funktionele redenen die bij jullie kennelijk niet of nog niet gelden, domweg omdat je de funktionaliteit nog niet raakt / gebruikt.

Echte voorbeelden kan ik niet geven, omdat ze (kennelijk) in alle gevallen niet zullen aanspreken, en dus maar een verzonnen voorbeeld :

Als je 25 Verschijningsvormen hebt waarvan 3 werkelijk, zul je niet voor all VVormen dezelfde EOQ etc. etc. hebben. Dus, of je gebruikt dat nu niet (Behoefterun), of je gebruikt het systeem verkeerd, of je hebt al die waardes verkeerd ingesteld ... of .... je hebt er maar 3 met werkelijke waarden ingesteld.

Of het voorbeeld aanspreekt of niet, het is FOUT, en eens kom je dat tegen. Bepaalde printjes (statistieken) zijn ook zo maar 8 keer te lang, of geven niet weer wat je wilt weten omdat je ze anders moet gebruiken.