b' : Goed punt Marco. Als dat niet in de helptekst staat, zetten we dat erbij.

We maken het wel zo dat dit (ergens) een vast te leggen keuze wordt.

Tja, zelfde verhaal, zelfde prijs denk ik. Alhoewel, de Bedrijfsparameter zal toch wel dezelfde kunnen zijn ?
2 uur dan maar, en hangend aan de Bedrijfsparameter hiervan : Re: Kolom toevoegen aan Verkooporders raadplegen (LOVORA).

Sorry dat ik er even tussenkom, maar Pascal, ben je niet bang dat als je daar een print van maakt, dat zo'n gozert die print meeneemt, en op z'n dooie gemak gaat lopen uitpluizen wie er wat allemaal mag, om jou vervolgens haarfijn te vertellen dat dat (betreffende situaties) onjuist is ?

Daarnaast, het lijkt me dat zo'n print een 150 bladzijden groot is.
Ehh, per gebruiker.

Nee, op zo'n manier niet. Maar dat wist ik natuurlijk ook niet.

2 x 0,5 uur voor die Layout Variabelen (waarvan ik maar even aanneem dat ze nog niet bestaan).

Geeft voor de zekerheid nog even aan welke wijze van Faktureren jij in deze toepast.

Maar begrijp ik het dan goed :

... dat het weliswaar 1 Faktuur wordt, maar dat als er gemiddeld 20 regels per Verkooporder zijn, en het betreft 5 Verkooporders per (onderliggende) Debiteur bij 15 (onderliggende) Debiteuren dat er 20 x 5 x 15 = 1500 regels op de Faktuur staan ?

En zo dit juist is, wat voor'n sortering hebben jullie in gedachten ?
Kan per Debiteur, per Verkoopordernummer, desnoods per Artikelnummer ...

Ik zeg nog niet dat dit helemaal vrijblijvend is (die sortering) want het ene zou wel eens veel moeilijker kunnen zijn dan het andere.

Houd nog even in de gaten dat er restrikties bestaan voor het "verzamelen" op 1 Faktuur, zoals de Betalingskondities die gelijk moeten zijn (en meer zaken zoals Landkode waar je denkelijk niets mee van doen hebt).

?

Tjongejongejonge ... verwijs je eerst naar een kb artikel van 2001 en of we even een SP willen installeren (zal wel 1 moeten zijn). Ik dacht al dat je misschien Vista bedoelde, maar ik begrijp dat je net over bent van W2K ...

Vervolgens komt er een eureka pakketje op de proppen uit 2003. Ja, werkt misschien wel.

... Wat jij alleen niet door had (hoe kon je het ook weten) is dat als wij verwijzen naar "Text Search" dan bedoelen wij TS.EXE uit naar grove schatting 1980. Hahaha. Die staat in c:\heart\tools, tenzij je dat hebt weggegooid. Werkt prima, vindt alles, kan alles.


Maar als je je echt wilt vermaken met text search achtige zaken, moet je toch op Vista zijn.
Als je het een beetje doorhebt, dan het vriendelijke verzoek om er ook even een handleiding van te maken, zodat we er allemaal profijt van hebben.

Enig idee waar je het over hebt ?

Dat (het niet als een bug heoft te worden gezien) zit 'm denk ik in het deel wat je niet door hebt :


Dat is waar en zal zich ook zo uiten. Echter, als je een keer denkt "huh ? weinig marge" dan is er niets expliciets wat je kan kontroleren. Althans, niet zonder weer additionele aanpasingen dáárvoor. Dus, op je Verkooporderregel staat gewoon 10 euro, en aan niets kan je zien dat dat 9 euro is geworden a.g.v. een algemene korting. Desnoods kan je nog een statistiek uitdraaien die e.e.a. per regel toont (dat aannemend, maar dat betwijfel ik al), maar als je het gaat kontroleren met de VORegel, zie je daar nog steeds 10 euro, en geen korting. Je moet dus maar AANNEMEN dat het a.g.v. raamkorting is gebeurd, en je moet maar AANNEMEN dat onze programmatuur e.e.a. juist heeft opgehoest (met zo'n print voor je die je niet begrijpt).

Je kan wel meer bedenken in de hoek van "dit is wel/geen" bug. Neem het voorbeeld van de Kredietbeperking maar weer. Had jij bedacht dat het zo hoort te werken als ik in mijn eerste post beschreef ? nee heh. Wie wel ? ga eens rondvragen ?
Niemand ...
En toch hoort het eigenlijk zo. Maar toen we dit ontwikkelden was het geen bug. Wel was het voor iemand die het wilde doen zoals het hoort. Dat was - en is nog steeds de enige. Die enige heeft wel gelijk ... maar jij vindt het geen bug.

Dinand,

Jouw vertrouwen kon wel eens te groot zijn deze keer.
Ik denk dat je er gelijk in hebt het zo te willen, maar zo zit het niet in elkaar, wellicht onterecht.

Het enige wat erin zit wat op de door jou gewenste wijze het werk goed doet is het aanbrengen van Kredietbeperking op een speciale wijze. Dus, als je je raamkorting weet om te zetten naar Kredietbeperking werkt het wel. Maar dan krijg je 1 op 1 per normale Faktuur ook een Credit Faktuur, die je hooguit - net als altijd bij Kredietbeperking- niet opstuurt.
Dat je daarnaast niet altijd de Kredietbeperking hoeft toe te passen (men betaalt niet op tijd) levert je dan nog geld op ook.

N.b.: Omdat het mechanisme *dus* in de basis erin zit, is het wel te maken, maar dat doen we dan toch voor een 6 uur vrees ik (ik schat dat het een uur of 10 werk zal zijn).
Overigens zou dit dan voor al dit soort kortingen moeten gelden, die zich denk ik juist als opslag gedragen (Minimale Order Hoeveelheid e.d. <- niet 100% terecht omdat dit administratieve overhead zou moeten dekken).
Dit zal dan exclusief het benodigde inzicht zijn, wat eventueel wel nodig is om de cijfers te kunnen interperteren. Ik bedoel (en dit is maar een voorbeeld om het "probleem" aan te geven !!) als jij de ene klant wel raamkorting geeft, en de ander niet of een keer kinder, dan zie je dat later nergens meer aan. De marge verschilt, maar uitzoeken / kontroleren kan je het eigenlijk niet. Voor een boekhoudert is het dan nog beter om die raamkorting op een aparte rekening aan te treffen, zodat aansluitingen er wel zijn ...

PS: Je bent wel de eerste die hiermee komt (en het is op zich dus terecht) ...

Maar dan zou ik toch denken dat die kontroles in de omgekeerde volgorde moeten worden uitgevoerd !

Misschien dat er alhier lieden zijn die wel weten waarover je het hebt, maar het lijkt wel alsof je tegen de verkeerde leverancier praat ...

Voor de goede orde (Peter, dan weet je het zelf ook), het wordt dus zo :

Printje (naar Excel) wat de "omzet" van de ingebrachte Kontrakten van een opgeveven periode ophoest, met daarbij de "Rechtstreekse Verkooporders", ofwel die Verkooporders die niet uit een Kontrakt zijn gekomen (geen afroep). Alles (alleen) op Regel niveau.

De Excel regels zullen in deze zijn onderscheiden naar "K" en "V" regels.
Welke representatief zijn voor welke zien we nog wel .

Ach, dan moeten we weer werken. Bah.
Goed, 3,5 uur. Doen maar ?

Kijk ... je realiseert het je misschien niet, maar nu heb je wèl een goed verhaal/voorbeeld. En voor dit geval zal het ook echt helpen. Sterker nog, als je zo te werk gaat (het nieuwe ID lijkt heel erg op het oude) dan lok je het domweg uit.
Snap je nu dat dit 180 graden anders is als dit willen omwille van het voorkomen van typefouten (wat je overigens niet eens zelf hebt gezegd, maar wel werd gesuggereerd zonder tegenreaktie). Dus, typefouten -> kans is 0 dat je zo'n debiteur raakt die is geblokkeerd. En andere eigenaar en naam hetzelfde -> kans is meer dan 50% dat je de verkeerde neemt. Meer, omdat mensen de oude in hun hoofd kunnen hebben.

Veldje bij de Debiteur Geblokkeerd voor Retour Emballage + aanpassen betreffende programmatuur (en het wordt geen waarschuwing maar een foutmelding !) : 4 uur.