Graag veld erbij in koppeling artikel/leverancier (LOLA)

[mdekraa]

In het blokje met artikelnummer leverancier en omschrijving leverancier wil ik ook het reach registratienummer van de leverancier vast kunnen leggen

format is:
xx-xxxxxxxxxx-xx-xxxx    (21 posities)

hoeveel kost dit?

mvg

MK

[Peter Stordiau]

Voordat ik 1,m,5 uur zeg ... wet je wel zeker dat dit lekker werkt ? Ik bedoel, zodirekt word je (iemand, iedereen) nog *verplicht* om of een Artikelnummer of een Omschrijving (redundant dus) op te nemen !

Test het zelf even als je wilt.

[mdekraa]

verklaar je nader
voorlopig vraag ik of ik naast hetr arttikelnummer en omschrijving leverancier nog een identifier ernaast mag hebben

wat zie je als probleem?

[Peter Stordiau]

Ik heb geen probleem. Als jij dat niet wilt testen of het niet wilt begrijpen, beginnen we met een Bedrijfsparameter ad 4 uur. En dan 1,5 uur of zo voor dat veldje.

Ok ?

[Peter Stordiau]

PS : Ik las "wat is je probleem ?"; Aannemend dat je dat niet zojuist hebt veranderd is mijn antwoord niet helemaal juist (plus dat ik verkeerd heb gelezen). Maar het probleem wat er kan zijn betreft dus het verplicht worden om Artikelnummer Leverancier en/of Omschrijving in te vullen, waar dat voor jou dan wel op gaat, maar niet voor iedereen ... (dat is, als het verplicht is).
En dus behoeft het een Bedrijfsparameter in dat geval.

[mdekraa]

Waarom zou artikelnummer en omschrijving leverancier verplicht worden?
Ik vraag het toch aan als een "info" veld en niet als een primaire zoeksleutel?

Het veld artikel Id leverancier is immers toch ook alleen een "info" veld.
Daar kan ik ook "nix" invullen.

dus graag even toelichten waar je aan denkt.

[Peter Stordiau]

Het heeft toch niets te maken met wat jij vraagt ? wel met hoe het is.

LOLAOP gaat over prijzen, en staat toevallig gekombineerd toe een Artikelnummer/Omschrijving Leverancier op te nemen die daar inderdaad optioneel zijn. Maar voorlopig gaat er wel een prijs gelden op basis van zo'n record. Kan jij 100 keer geen primaire sleutel vinden daar, dit is niet genormaliseerd op deze manier. Mensen (jij ook) worden dus verplicht om een prijs op te nemen, en zo niet dan zal de prijs 0 zijn bij deze leverancier.
Vergelijk maar eens met de verkoopzijde ...

Aldus, in LOLA kan het niet. In een nieuwe entiteit wel ($$).

[Peter Stordiau]

Nog even additioneel :

Ik heb intussen zitten denken - want het lijkt behoorlijk belachelijk dat dit niet in die entiteit kan, terwijl een nieuwe $$ impliceert. Maar ik denk echt dat het niet goed anders wil. Ik bedoel, theoretisch bestaat de mogelijkheid om een soort vinkje te hebben in LOLAOP wat zegt "niet zien als prijzen die zijn ingevuld" (o.i.d.), alleen, volgens mij moet het halve pakket worden onderzocht op waar de betreffende kontrole op te nemen. Je bent misschien niet duurder uit, maar het zal erg in de buurt komen. En, het klopt gewoon niet.

Als er nou (grrr) al een andere entiteit zou zijn waar dit in kan worden ondergebracht ... maar ik ken 'm niet.

Een gore truc zou nog kunnen zijn om op basis van voornoemd vinkje onder water die nieuwe entiteit aan te maken, om vervolgens de Raadpleegfunktie op LOLA daarop te laten anticiperen ("kijk ook daar"), en om daarna LOLAWY en WG er ook op aan te passen. Maar volgens mij wordt dat net zo duur als een nieuwe RA funktie (als we het al aan het werk krijgen) ... wat me brengt op gewoon een nieuwe RA funktie op die onder water aangemaakte entiteit. Je zou dan gewoon LOLAOP/WY blijven gebruiken voor het aanpassen ...

Nee. Te krom.

Goed, wat denk je van 11 uur totaal voor die nieuwe entiteit op een normale manier. Dus gewoon TV/WY/VW/RA wat normaal 22 uur kost.
En daarna kan je van alles erbij gaan verzinnen. (Nog meer) REACH gerelateerd, of anders. Gewoon, Artikel-Leverancier gegevens, die er nu dus eigenlijk helemaal niet zijn (nogmaals, vergelijk de verkoopzijde).

Is dat wat voor jou ?