Hahaha, dat kun je nu wel willen, maar zo werkt het niet. De Prijs is immers 0 geworden, kijk maar goed.

Je hoort mij verder niet zeggen dat dit iets is wat je ooit zou willen (indien kleiner dan 0, dan maar 0), maar ik wil toch meegeven dat dit het principe is van alle Prijsbepalingen, die óók werken in "elementen" (alle stukjes definitie van een produkt dragen bij aan de prijs). In zo'n geval is het meer reëel dat de prijs negatief kan worden (trouwens, wie geeft er nu een standaard korting van 77,50, dus waarom is niet juist dit voorbeeld reëel), en dat gaan we niet veranderen.


Edit : Ik snap zelf het begin van bovenstaand stukje niet meer. Samenvatting : alles klopt en er wordt niets aangepast.

Goed, we kunnen het zonder jou ook wel hoor. Moet de rekening naar jou persoonlijk ?

Zonder gekheid, er klopt hier (in Profit) zo veel niet dat het nauwelijks is uit te leggen.

Met de opmerking dat je de Verschijningsvorm mag weglaten bij het koppelen, is het de belangrijkste opmerking dat als je dat *niet* doet, het wel (aardig) werkt. Ofwel, een programmafout zorgt ervoor dat als je de VVormen wel koppelt, het niet meer is te volgen.

Houd verder in de gaten dat LOKARA Raadplegen Kliënt-Artikelomschrijving heet, en dat dat op zich redelijk juist is.
Zelfs de omschrijving van LOAKRA - Raadplegen Artikelen voor Kliënt benadert de waarheid aardig, mits je "voor" maar als "beschikbaar voor" leest, en ook met de wetenschap dat je een Artikel rustig twee keer kunt (proberen te) koppelen zonder dat ze dubbel wordt opgenomen. Ofwel, alleen dan is de funktie omschrijving gerechtvaardigd.

Alles bij elkaar klopt er maar weinig van, en we zullen dit wel verbeteren.

... wat m.i. inhoudt dat iedereen die een Kontrakt zou kunnen hebben ergens met een Leverancier, niet geautoriseerd zou moeten zijn voor deze funktie ... maar wat niet kan (want het betreft de "normale" LOIRTV), en dus moet dit procedureel zijn ondervangen.

Ja, dat snappen we wel;
In SAP moet je dat een jaar minus 1 dag aankondigen van tevoren. Waarom heb ik trouwens nooit begrepen.


Er zijn wel meer van die dingen, en die gaan wel komen ...

Marco, ik snap ALWEER niet waar je het over hebt. Kun je niet eens proberen duidelijker te zijn ? Dat scheelt mij weer vragen wat je bedoelt. Hoef jij er ook geen antwoord op te geven.


Dat zie ik helemaal niet. Ik zie Artikelen (Artikelnummers).
Mocht het je helpen, het Kliënt-Artikelnummer (met Debiteur) is hier de sleutel, en het Artikelnummer van jou (ADP) alsmede Verschijningsvorm zijn hier attributen (en bijjjjjjna nog niet eens vreemde sleutels, maar goed).


En omdat het voorgaande wat je zegt (zie quote) onjuist is, snap ik dit dus ook niet.


Ik snap echt geen BAL van wat je hier probeert te zeggen. Gewoon die zin dus. Laat staan de context met de rest (die onjuist is).



PS: Het kan ook zijn dat je er maar weinig van begrijpt. Maar ja, dat ga ik jou niet in de schoenen schuiven totdat het tegendeel is bewezen. Hahahaha, tot zo !

PPS: Op voorhand excuses als het aan mij ligt. Dat gebeurt wel eens ...

Wat bedoel je nou ? bij handmatic maken (Credit) Faktuur ? Nee. DKK's worden daar gewoon niet onderkend.

Aanbrengen Code Pages ... echt geen idee hoor.
Als het geen virusscanner is (je zegt wel heel makkelijk Nee trouwens) dan zal je misschien iets hebben in je netwerk met hele grote packets of zo. Maar dat moet je ook altijd wel merken dan.

Als je Vrijgeven doet, en daarna na Raadplegen Verkooporders, hoe lang duurt het dan voordat alle puntjes (bovenin) voorbij zijn gekomen ?


Dokumentatie Cross Reference is een ander verhaal. Daar kijken we naar.

Snap ik niet. Waar ? en wat zou de melding moeten zijn volgens jou ?

Dus, zie Keuring op Potency werkt ook Potency bij als Artikel er niet formeel mee werkt

Er zijn hier wel een aantal dingen aan de hand, denk ik, vandaar dit toch even in een apart topic geplaatst;

Zoals Menno ook al aangaf : Niets weerhoudt je ervan om het aantal dagen THT bij Artikel op 0 te laten staan, om vervolgens toch immer en altijd te "Keuren" op THT (zowel bij Goederen Ontvangst als bij Gereedmelden Produktie overigens).
Een produkt werkt dus met THT bij de gratie van het hèbben van een THT, en dat is pas meetbaar op de Voorraad (en niet omdat bij het Artikel geen 0 zou staan).
Konklusie : de aanpassing die door genoemde Release Note is gerealiseerd, werkt niet.

Voor Potency geldt een soortgelijk verhaal, doch dit werkt technisch wat direkter :
Als een produkt geen Potency heeft (bij het Artikel ingevuld), dan heeft het een Potency van 100%. Dus alsnog een Ponetncy ...
Ook hiervoor geldt dat dit middels "Keuren" kan overruled, dus of het nu indirekt 100% heeft, of 80%, in alle gevallen kun je bij het Keuren de waarde veranderen. Desnoods naar 100%.

In alle gevallen kun je het ook zo bekijken dat je het betreffende Voorraad-Item zou kunnen wijzigen (of dat werkelijk kan in deze weet ik niet, maar is ook niet van belang), en nadat dat is gebeurd, is het betreffende ook onmiddellijk werkzaam.

Zoals wij het noemen, is de funktionaliteit "Keuren" (en dan middels de betreffende Keuringsvoorschiften) generiek voor het verkrijgen van betreffende waarden op de voorraad. De default die daarvoor gebruikt wordt is de ingevulde waarde bij het Artikel;
Worden deze defaults niet overruled middels Keuren (want zo gebeurt het : de default overruelen), dan zal een Artikel met een default THT van 0 geen THT kennen, en zal een artikel met een niet ingevulde Potentcy een Potency van 100% hebben. Beiden komen dus als zodanig op Voorraad als ze niet worden overruled met Keuren.

Niets weerhoudt (by design) iemand ervan om tijdens het Keuren de defaults van "is niet aanwezig" te overrulen.

De aanpassing per genoemde Releasenote is dus onjuist.

Je doets niet fout. Hooguit wil je te "te veel". Of meer dan reëlerwijs mogelijk is om te ontwikkelen;

Als je buiten de Verkooporder om een (Credit) Faktuur maakt, is er van alles niet bekend, wat bij de Verkooporder wel bekend is, en waarop de DKK's zich (kunnen) baseren.
Een andere (meer technische) reden is, dat in de database alles rond DKK's zoals die optreden, zijn gekoppeld aan de Verkooporder. Maar let wel, feitelijk ook nog aan de Faktuur (denk aan Nagekalkuleerde DKK's).

Oplossing (denk ik) : Credit Verkooporder maken, en er voor zorgen (??) dat er geen goederen terug gaan komen.

Johan,

Plaats dit svp in een apart topic ...
Tijdens het typen daarvan kom je wellicht meteen zelf op het antwoord ?

... te laat. Split van Keuring op Potency werkt ook Potency bij als Artikel er niet formeel mee werkt

Mocht de boel in een loop zitten (cpu op 100%, of 50% bij dual core), dan mag je verwachten dat "de" index stuk is.
Welke dat dan kunnen zijn (t.b.v. reorganiseren) moeten we uitzoeken.

Yvonne is er niet.

Hier zit wel iets in ja. En is ook een stuk gemakkelijker te regelen.
Als je niet oppast werkt dit nu zelfs al (een typisch bugje wat we mogen verwachten gezien de manier waarop wij werken).

Heeeel interessant ja. Alleen, het bestaat niet.
Een klein jaartje terug was ik de mening toegedaan dat we dat voor iemand moesten maken, alleen die iemand hebben we nooit meer kunnen vinden (ehh, als er nog iemand op zit te wachten ...  ).

Er staat me bij dat jij (Dirk-Jan) er ergens ook mee te maken had.
Niet belangrijk verder hoor.