Tja ehhm ... je zou mij nog een zakje sturen, maar ik vrees dat je ze zelf hebt opgesnoept.

Vind je niet erg heh, dat ik weer eens in opperste verbazing achterover val wegens zware afkickverschijnselen dan wel anderszins. 

Zou over 15 minuten klaar moeten staan.

En nu kunnen we jouw mobieltje eindelijk ook ergens legaal kwijt.

Niet mee eens ... 

Ik wil niet geleefd worden door berichten die komen wanneer ze komen, en ik wil niet dat jullie geleefd worden daardoor.
Over wat klanten willen in deze ga ik natuurlijk niet, maar in dit geval kijk ik eerst naar ons zelf.

Pas maar op dat ik bij jou dat ding er niet af kom slopen ! 

Overigens hebben we het hier in het verleden al eerder over gehad, en toen al kon ik jou wijzen op de vele nadelen die jou toevallig niet storen.

Nou ... einde gevecht ... wij hebben verloren. 
 

... maar ik wil een browser opstarten, en niet dat geneuzel. 

 

 

tovi,

Allereerst zou ik graag nog eens duidelijk willen maken dat ik juist NIET voorsta om Kenmerken te gebruiken bij jullie. Althans, niet meer, aangezien er intussen te veel is geregeld om het zonder te kunnen doen. Denk aan je Artikelbestand en ook alles wart je eromheen zult hebben kwa kalkulatie (Excel) aanbiedingen naar klanten enz. enz. "Dat moet je nu niet meer willen". En dus wil "ik" het ook niet. Simpel.

Nou is het natuurlijk wel zo dat de beslissing om het zonder te doen ver voor jouw tijd ligt, en, omdat ik eigenlijk weiger jou om te praten krijg je intussen ook de argumenten niet meer te horen. Bij deze dan maar een kleine poging om alsnog een context te kreëren, gewoon omdat je het vraagt (en niet om het te gaan veranderen, al was het maar omdat genoemde "zachte logistiek" bij jullie dan weer op z'n kop moet).

Het verhaal begint bij Omvormen. Zoals het fenomeen het beschrijft (zie Trefwoord), betreft dit het omvormen naar een andere vorm (hehe) wat over de Verschijningsvorm mag gebeuren, en wat tevens over de Kenmerken mag gebeuren (en over de Inhoud uiteraard). Wat je waarin onderbrengt is veelal zacht, doch met een dagje beredeneren kom je altijd wel tot niet-arbitraire oplossingen (en dat dagje beredeneren heb ik hier even de gelegenheid niet voor, dus we houden het bij algemene voorbeelden).

Een lichtgekleurde tomaat die gekleurd wordt, zou kunnen worden ondergebracht in de Verschijningsvorm, ware het niet dat je die ergens anders voor wenst te gebruiken : de verpakking. Ook zou je met de Inhoud weinig kunnen, tenzij je weet te bedenken dat een lichtgekleurde tomaat een andere Inhoud heeft dan een gekleurde (mij lukt dat niet).
Omdat het hetzelfde produkt betreft (dat staat onomstotelijk vast VOOR ONS ... niet voor jou, omdat je er een ander artikelnummer voor hebt  ) kom je er automatisch op dat die andere kleuring in een Kenmerk MOET. Let wel, moet.
Omvormen mag over de Kenmerken, dus die is simpel ... Kenmerkwaarde veranderen, klaar.

Van belang is nu de wetenschap dat je hiermee het produkt net zo hebt veranderd als dat je doet middels het veranderen van de dimensie "Artikelnummer", wetend dat alle dimensies onderdeel zijn van de logische sleutel, en het produkt dus een samenstelling is van al die dimensies. Niet alleen het Artikelnummer dus.
Hieruit volgt dat ook bewezen is dat waar je het Artikelnummer zou veranderen om er een ander produkt van te maken, je dit ook middels het veranderen van een Kenmerkwaarde mag doen. Maakt werkelijk niet uit, en het hele pakket anticipeert hierop (ok, behoudens Verkoopkontrakten zoals we sinds kort weten ).

Een essentieel verschil met het veranderen van het Artikelnummer, is dat er niets behoeft te worden gedaan om Kostprijs enz. enz. consistent te houden, immers, het fysieke produkt is onveranderd, behoudens de vorm. Denk aan een plank die je doormidden zaagt, dan houd je twee helften over, en de Kostprijs van het totaal is "onnagedacht" hetzelfde, en in het pakket hoeft daarvoor ook niets (meer) te gebeuren, omdat het de basis van het principe Omvormen is (uiteraard kunnen er zaagkosten optreden, waardoor beide helften navenant in Kostprijs stijgen).

Een voorbeeld van de zachte logistiek betreft het niet zonder meer werken kunnen weken met de Klasse-hiërarchie, aangezien deze nu op Artikelniveau haar werk moet doen, terwijl ze op het niveau van de Verschijningsvorm (klopt niet met jouw voorbeeld) er standaard in zit (want, dat is "logisch", sinds ooit iemand dat wilde hebben). In de zachte logistiek is niets logisch, al was het maar omdat het al logisch is dat je het hard doet (hard is feitelijk : via de database en haar formele logika).

Bij de bepaling wat waar moet, dien je in jouw geval te kijken naar wat het Artikelnummer bepaalt. Dat is *niet* de tomaat-alleen, maar wat mij betreft de tomaat + intrinsieke kwaliteit. Volgens jouw voorbeeld hoort het land van herkomst daar zeker bij, maar als ik het zou mogen bepalen, wil ik zelfs de farm erbij betrekken (en dan mag land van herkomst weer weg).
De maat hoort er zeker ook bij, maar de kleur niet. Immers, de kleur onstaat door "omvorming".
Ook de klasse hoort er niet bij, mits je de farm (dan wel land van herkomst) maar bepalend laat zijn voor de basis daarvoor. De klasse die je vervolgens nog mag toepassen is die van de ouderdom om andere invloeden (heeft te lang warm gelegen enz.).

De Kenmerken zijn niet gekoppeld aan het Artikelnummer, ook niet aan de Verschijningsvorm, maar zijn domweg onderdeel van het geheel. Dus, een paprika in klasse B zit op zich heus wel in een Verschijningsvorm, en heeft ook heus wel een Artikelnummer; de dimensies bestaan eigenlijk los van elkaar, maar worden gekoppeld in het produkt.

Het voordeel wat je als eerste mee hebt, is dat je op ieder niveau in de dimensies de Voorraad kunt bekijken. Dus, hoeveel heb ik totaal van de Paprika-FarmX ? hoeveel daarvan in een pepdoos-Y, hoeveel van klasse B ? hoeveel daarvan in klasse B groen/geel gekleurd ? (laatste alleen als een paprika net zoals een tomaat verkleurt).
In de Statistieken zie je alles precies hetzelfde terug, waar je daar nu domweg geen mogelijkheid voor hebt.
Dit brengt mij ook op het derde Kenmerk wat nog vrij is in mijn voorbeeld, en het toepassen daarvan als Statisch Kenmerk met als inhoud ... jullie sticker. Althans, de Raapvloer die daarop is genoemd. Hierover verder uitwijden zal ik hier niet, maar *jij* begrijpt wel wat je daarmee kunt doen in de statistieken ... "wat heb ik ingekocht voor Raaplvoer X, maar hoeveel heb ik geleverd aan ..." snap je ?

Eigenlijk komt het erop neer dat als je de dimensies niet gebruikt waarvoor ze in jouw werkelijkheid zijn bedoeld, je de helft van de kracht c.q. intrinsieke overwaarde van het pakket weggooit.

Merk op dat dit geheel wat mij betreft niets te maken heeft met jouw langer gewenste ID van de Verschijningsvorm, behoudens dat je nu in dat ID zaken kwijt MOET (direkt = zichtbaar of indirekt = onduidelijk), omdat je met de Kenmerken erbij 30 posities meer zou hebben. Je hebt dus domweg (maar theoretisch hoor) 30 posities minder voor je "produktnummer" dan zou kunnen.
Let wel, ik acht dit onbelangrijk, aangezien wat jij (eventueel) kwijt wilt in een ID, in de Omschrijving thuishoort. En natuurlijk, hoe minder logisch de ID in elkaar zit, hoe meer je niet "direkt" kunt typen en in plaats daarvan moet zoeken.
Dit laatste kan denkelijk worden opgelost door op betreffende plaatsen via de Omschrijving te selekteren (en vervolgens typ je je een ongeluk ).

Beste Dirk-Jan,


Ik begrijp offline dat je er toch maar liever vanaf ziet. Jouw argumentatie is denkelijk nuttig voor de rest.
En ik wil het niet op mijn geweten hebben het hier te plaatsen ... 

Theoretisch :

Er staat mij bij dat voor een Weekfaktuur (e.d.) uiteindelijk ook de individuele Fakturen als dummy worden gemaakt (moet haast ook wel, anders zouden de DKK's het niet doen). Ik kan me iets voorstellen van het nu op voorhand maken van deze dummy Fakturen, waarbij de Weekfaktuur (e.d.) dit deel later juist moet overslaan, c.q. zich moet/mag baseren op deze reeds aanwezige dummy Fakturen. Denkelijk ben je dan iets goedkoper uit. Er vanuitgaande (let op) dat het legitiem is om het zo op te zetten, orde grootte 3-4 dagen.

Als je om welke reden ook de Artikel/Verschijning behoeftig weet te maken (bijvoorbeeld, het wàs al zo, of je voegt een Produktieorder handmatig toe voor die Artikel/Verschijning) dan wordt gewoon de rest getriggererd. Dit is intentional. Merk op dat het ooit zo was dat e.e.a. alléén werkte bij Toevoegen Verkooporderregel (niet toestaan van niet-Aktief Artikel) wat volgens het ontwerp ook waterdicht is. Niet natuurlijk als je langs een omweg het Artikel behoeftig maakt. N.b.: Intussen wordt het langzaamaan op steeds meer plaatsen ingebouwd a.g.v. de werkwijze van mensen (die bijvoorbeeld als onderdeel van de procedure nu eenmaal handmatig Produktieorders maken, en het vervolgens ook daar moet kunnen worden geblokkeerd).

Nou weet ik alleen niet wat precies jouw situatie is. Zie ook de titel van het topic, wat "Verschijning" noemt, en niet "Artikel/Verschijning".

Kun je een scenariotje schetsen ?

  Ja, dat was een slimme van mij heh ? niet.
Tja, nu snap ik ook jouw "vrij snel" wel, want je kunt dus een week verder zijn en nog niet hebben gefaktureerd.


Bijna. De juiste waarden (en ook DKK's zelf dacht ik, voor betreffende soorten) worden bij de Verkooporder opgenomen bij het Faktureren.


Het is wel de goedkoopste oplossing.

Dit komt niet goed ...

De DKK's zoals je die met Edwin hebt doorgenomen, bevonden zich dus op de Gefaktureerde Verkoopoverzichten;
Gezien het principe daarvan, en dan moet je maar denken aan met name het fenomeen "nakalkulatie" waarin de DKK's hun bijdrage kunnen hebben, vergt het onbehoorlijk veel werk om hetgeen je wilt te realiseren nog voordat er is gefaktureerd.

Om in termen van kroppen sla te praten moet je denken aan een stuk of 12.000 (dit is geen definitief aanbod), waarbij ik ook nu weer jouw baas wil adviseren om dat om te zetten naar de MARGE op kroppen sla, en je wellicht toch op een stuk of 120.000 uitkomt. 

Tip : sneller faktureren, of beter : voor een paar honderd euri het Faktureren door ons laten koppelen aan de Levering. 

Nou ... niet veel goeds. 
We hebben hier een zeer uitzonderlijke situatie gevonden, waar het gaat om de consistentie in het pakket. Maar, ik snap ook wel hoe het is ontstaan;

Ten eerste betreft het dus een deeltje (Verkoopkontrakten) in het pakket dat niet van Kenmerken is voorzien. Hoort niet, klopt niet. Je weet wellicht nog wel hoe ongelovig ik was dat het zo zou zijn toen je het telefonisch meldde ...
Wat blijkt nu ?

Ooit, in 1992 o.i.d. is het maatwerk wat we ooit hadden gemaakt voor een klant verworden tot het pakket Heart-Profit. Dit is samengegaan met het onderbrengen van Kenmerken in het pakket c.q. de ondersteuning voor met name de discrete omgeving. Dit klopt ook, want de eerste keer werd het pakket met discrete werking (vs. process) geïnstalleerd bij een discrete klant. Echter, in de praktijk ging het net andersom : wij hebben in maatwerk de software die we toen hadden, voor die klant de discrete zaken ondergebracht. De Verkoopkontrakten bestonden toen al, maar die klant hanteerde geen Verkoopkontrakten ... Dat hoefde dus ook niet te worden aangepast ...
Nadat genoemd maatwerk klaar was werd het pakket het pakket (werd ook na verkrijging van de licentie bij de ooit eerste klant weer teruggezet als pakket), en werkelijk al die tijd heeft niemand gemerkt dat in het deel Verkoopkontrakten geen Kenmerken zaten. Althans, niet dat wij hebben vernomen. Dat is dus 15 jaar lang, met echt wel voldoende klanten met de Kenmerk module, en zeker ook klanten die Verkoopkontrakten gebruiken.

N.b.: Dinand die we hier sinds enkele dagen ook zien rondzwerven hoort bij de laatst genoemde groep, al is alles voor zijn tijd ingericht, en worden de Kenmerken tegenwoordig bij hem niet dynamisch meer gebruikt (zijn nu vaste waardes per Atikelnummer). Wie weet dat hij snapt hoe je dan toch met Verkoopkontrakten kunt (kon) werken ... Ik snap dat niet zo snel.

Al met al leidt het er toe dat dit anno vandaag niet kan, en het formeel maatwerk is om het te maken. Wij beschouwen dit niét als een "bug", hoezeer je er ook zo tegenaan zou kunnen kijken. Het is destijds expliciet niet gemaakt, en dat gold destijds voor de klanten van destijds, en geldt nu nog steeds, maar dan voor de klanten van nu.
We schatten in dat het 2,5 dag kost om e.e.a. te realiseren, waarbij ik wel vind dat 50% korting op zijn plaats is, gewoon omdat ik er toch zelf erg verbaasd over was dat het er "zo inconsistent" niet in zit. Dit zou ons nu ook niet meer overkomen, waarmee ik bedoel : we zouden nu nooit meer maatwerk aanbieden dat voor het geheel in consistentie niet alles zou dekken.

 

Allereerst ontstaat het probleem doordat je niet alle Dimensies gebruikt die er zijn. Uiteraard doel ik dan op de Kenmerken.
N.b.: Waarmee ik slechts aangeef dat jullie probleem niet maatgevend is voor een willekeurige ander, terwijl je wel bewust de Kenmerken niet gebruikt, wat dùs toch een "mogelijke inrichting" betreft. In dit licht kan hat dan iedereen weer aangaan, namelijk iedereen die net zo bewust als jullie hiervoor kiezen. 

Achtergrond info om de context te bepalen :
Het betreft hier vershandel, waar de logistiek in volledige consistentie binnen Heart-Profit op "zachte" wijze is opgezet. Dit betekent onder meer dat er een ander produkt kan worden geleverd dan gevraagd op de Raaplijst, dat produkt op de Voorraad kan worden veranderd (m.n. a.g.v. veranderende kwaliteitsklassen), dat bij Goederen Ontvangst een ander produkt op Voorraad kan komen dan de Inkooporderregel zegt, enz., waarbij alles toch automatisch wordt behandeld (denk met name aan (kost)prijzen.
"Logistiek" werkt hier volledig anders als gebruikelijk, doch is consistent over alle processen heen.

Terug naar de probleemstelling, lok je hiermee uit dat er problemen ontstaan waarop niet is geanticipeerd in het verleden, namelijk toen het pakket alleen nog "hard" kon werken, en het hanteren van aspekten als Kenmerken domweg nodig waren om e.e.a. op logistiek juiste wijze te realiseren (denk aan de kwaliteitsklasse die in een Kenmerk is ondergebracht).
N.b.: Het door mij gehanteerde voorbeeld is niet 100% juist, omdat e.e.a. zich nu uit op Artikel(omschrijving) niveau, waar het hier om de Verschijningsvorm gaat.

Voor de techneuten onder ons : Heart-Profit werkt niet met zogenaamde GUIDs, ofwel, ze werkt met werkelijke sleutels omdat
a. wij de GUID methode niet aanhangen
b. het onderhoud bij het werken met GUIDs zo ongeveer ondoenlijk wordt (let wel, in de consistente situatie zoals wij zelf werken i.v.m. met name het Releasebeleid).

N.b.: Een GUID is een werldwijd uniek (gegenereerd) nummer voor alles wat je op deze aardbol kunt aantreffen. De logische sleutel bestaat dan alleen nog virtueel, en is eigenlijk ondergebracht als -gemakkelijk veranderbaar- attribuut.

Sleutels die als zodanig zijn opgenomen in de database, zijn enorm moeilijk te veranderen, aangezien het ingrijpt op ieder programma dat van die Sleutel gebruik maakt, en wat bij de Verschijningsvorm toevallig wel heel erg veel is ...

Het langer maken van de Verschijningsvorm zou vele weken vergen met navenante kosten, alleen al voor het langer maken zelf en de databasecommands (m.n. rond de Indexen) die ermee werken. Echter :
Het inpassen in alle prints (en ook wel schermen) is een klus die je eerder op maanden moet inschatten, met vooral het probleem dat zaken niet meer passen, waar ze nu gemaakt zijn op "past nèt". Dus, hier 3 posities erbij betekent daar 3 posisties eraf.

Ik neig er veel meer naar om de Omschrijving te misbruiken, of desnoods een nieuw Omschrijvingsveld, om e.e.a. vervolgens toe te passen op cruciale plaatsen, door een Bedrijfsparameter (wellicht Systeemparameter) gestuurd. En, aangezien de Omschrijving 1 op 1 uniek behoort te zijn met de ID, is van werkelijk misbruik geen sprake.

De eerste vraag is dan wel welke funktionaliteiten (indien algemeen te omschrijven) jullie als relevant zien voor deze benadering. Dit, om in eerste aanleg enigszins de hoeveelheid werk te kunnen bepalen. Je zou bijvoorbeeld kunnen zeggen : alles voor het Magazijn en Produktie personeel ... (daar gok en hoop ik op).

 

Maar sinds deze Releasenote niet meer ...