Ha die Thomas,

Op zich wel, behalve dat je met het genereren van de Prijs (uit de evt. aanwezige Prijsafspraken) het *juist* verkeerd kan doen, gezien de eengeden (??). Ik kan dit niet helemaal overzien.
Een optie is wellicht om het zo te maken zoals je voorstelt, en als het met de prijs verkeerd uitpakt, om dit dan later weer eruit te fietsen.

Maar als je intussen nog een beter idee hebt hierover ?
(en vergeet niet, beter een nog in te vullen 0-prijs dan een foute prijs, PLUS dat de prijs vanzelf goed zou moeten komen na invulling van de juiste hoeveelheden/eenheden ... wat dus geen expliciete aktie hoeft te zijn ... en dus zal dit wel een waardeloze opmerking zijn).

?

Ok, sorry. Ik kon (nog) even niemand bereiken (en ik kan gelukkig nergens bij )
Dan lossen we het dinsdag meteen op.

Hoe laat staat die chauffeur er ?

(hoe "oneerlijker" je te vroeg noemt, hoe minder kans je hebt, haha)

Het eerste deel : 3-6-6.

Het tweede deel : leuk idee wel. Maar ik denk dat dat zwaar gaat tegenvallen (aan onze zijde);
Eenheden zijn niet gelijk, dus hoeveelheden ook niet, zelfs Verschijningsvormen kunnen anders zijn ...

Als je nou voor je ziet dat er voor idere IORegel een VORegel wordt gegenereerd en de rest zo ongeveer nog leeg is (of in elk geval moet worden aangenomen dat het fout is) terwijl er tòch nog 12 uur aan onze kant is besteed ... wil je het dan nog hebben ?

Voor diegenen die het nog niet wisten of vergeten zijn : wij zijn op Goede Vrijdag altijd "gesloten".

Trouwens, als iemand hier (Wouter bijvoorbeeld) alsnog een mooie status (of modus) kan verzinnen dat mijn verhaal niet opgaat, is er dus niets aan de hand. *Ik* zie dat vooralsnog niet, en wat ik miste was de aandacht hiervoor. Wel, die is nu genoegzaam bekend, dus werk het op basis hiervan uit zoals je wilt.

Nog één ding :

Als het zo is dat je ook "heel vaak" een order die niet doorgaat toch weer wilt laten doorgaan, klopt er wat mij betreft nog iets anders niet. Zo'n order wil je (m.i.) niet laten vervallen, maar op hold zetten of zo. Dus, dit heeft ook een kommercieel aspekt, en daarmee moet je logistiek kunnen omgaan. Bijvoorbeeld, als je zegt dat een aannemer een order cancelt omdat het vriest, kan je verwachten dat hij later er mee verder wil (en als dat niet altijd zo is, denk dan maar alleen aan die gevallen waarbij dat wel zo is, haha). Dus, zo'n order gooi je er niet uit, en die cancel je ook niet. Misschien verander je wel de Leverdatum, of zet deze in een toekomst die je logistiek gezien iets zegt. Feit is (weer m.i.) dat je graag zo'n hangende order zal willen nabellen. Doe je dat niet dan is de klant wellicht weg, en zie je niet dat je dat moet doen (nabellen) en doe je het dus niet. De order laten vervallen om deze reden (het vriest) is dus niet de methode. Je wilt dat ding blijven zien, en je wilt 'm NIET op dezelfde manier zien als de orders die werkelijk zijn vervallen.

Je moet het allemaal zelf weten, maar je moet er op z'n minst goed over denken.

O, gelukkig. Nee, het gaat mij erom dat het o zo gemakkelijk is om iets wat niet lekker werkt te willen veranderen (zoals ik zei, de vraag is helemaal terecht), maar dat je wel de consequenties moet overzien. Dat jullie die niet overzien is normaal, maar juist daarom proberen wij dat zo goed mogelijk, en in elk geval ik zie alle buien al hangen. Dus bijvoorbeeld, waar het je zodirekt is toegestaan om orders die je niet hoeft te leveren, te laten staan, barst je zodirekt van die orders (want jaja, het gebeurt heel vaak), maar werken vervolgens al je eigen procedures en "technische middelen" (printjes) niet meer om te zien wat je (nog) moet doen, (nog) moet faktureren, enzovoort. Als je dit dan ook nog kombineert met orders toch weer willen gebruiken, dan wordt het domweg chaos.

Dit wordt dan met name uitgelokt door het niet ter beschikking hebben van andere statussen, en je dus de keuze hebt uit L of F. Desnoods een andere bestaande, maar allemaal doen ze niet wat je wilt. Dus, er zou een nieuwe moeten komen, en ik weet praktisch zeker dat als je dit tegen Wouter zegt dat hij zegt a. ik kan niet overzien hoe duur dat wordt en b. dat komt nooit goed. Dit komt op zich doordat er feitelijk te veel wordt opgehangen (in het pakket) aan "status overgangen". Dus, L wordt F. En indien F ongedaan wordt gemaakt, wordt het dùs L. Dit gaat niet meer op als we een nieuwe status introduceren, en het kan ten eerste dagen vergen om alles door te voeren wat we kunnen vinden, maar erger, hier is niet naar te zoeken (dus, we weten niet waar we moeten zijn, en het zal een gevalletje "door schade en schande wijze worden" worden.
Feitelijk komt het erop neer dat er geen nieuwe status kan komen, die je wèl nodig hebt, omdat je anders niet meer kan werken.

Als je je nou heel goed realiseert wat dit voor jullie gaat inhouden, kan je van mij -wat het ook is- best krijgen. Hiervoor moet je dus de organisatie rond gaan, en kijken wat er zoal gebeurt aan de hand van de statussen.
Wat blijft is dat het "fout" zal zijn, welke bestaande status je ook kiest. L betekent domweg geleverd (wat niet zo is in jullie geval), F betekent gefaktureerd (is ook niet waar) O betekent staat nog open (niet waar), en er zijn er vast nog wel een paar, die net zo vast onjuist zullen zijn.

Ik hoop dat het nu wat duidelijker is ?

Wacht even ... gaan we boos doen ?

Duidelijk ... duidelijk ??

Er is weer eens iets gaande met die stenenjongens wat in elk geval *ik* niet begrijp.

Historie bewaren ? Later toch nog leveren ? wat mis ik nu eigenlijk.


Het lijkt me goed dat we eens in het woordenboek kijken en beoordelen wat "verwijderen" en "laten vervallen" zoal betekent. Ik snap wel dat het allemaal per ongeluk verkeerd wordt opgeschreven, maar erg handig is het niet.
Maar goed, ik wil Wouter er even op wijzen dat hier gesproken wordt over het "later alsnog leveren". Wel, ten eerste komen jullie daar zelf niet uit, en ten tweede gaat dat echt niet in dezelfde 8 uur lukken. Het laatste heeft met het eerste te maken, want zoals Wouter die order (vast en zeker) gaat "afsluiten" geeft als resultaat dat jullie niet meer kunnen zien of deze order is geleverd of niet. Verder verwacht ik nog wel wat onduidelijkheid aangaande het "niet te" faktureren van deze order, die toch vast geen status F zal moeten krijgen, enz. enz. enz.

Is *dat* dan duidelijk ??

Volgens mij gaat dit weer zo'n eindeloos verhaal worden. En daarom maar voor de goede orde : de tijd loopt vanaf nu. Ok ?


PS: En ik zeg hiermee absoluut niet dat de wens onterecht is !

Ik vrees dat het niet anders kan, maar we zullen in elk geval even naar deze kijken.

Heb je het nog over 20100322005 ?
En is het dan juist dat je eerst 0 DKK regels zag, en na reorganiseren 4 ? En dat terwijl er 1 hoort te zijn ? (svp deze 3 zaken even explicit bevestigen).

Zou denk ik wel moeten ja (alleen vanaf het hoofdmenu). Maar toch is dat niet handig, omdat je dit ook behoort te gebruiken voor "ik loop even weg" om daarna gewoon weer in te loggen en verder te gaan waar je bent gebleven.

Verder, jij noemt dit nu wel omschakelen bedrijf, maar dat doe je daar niet mee, ook al kan dat denk ik wel "vanzelf" gebeuren, met een nieuw userid dat standaard thuishoort in een ander bedrijf (o.i.d., lamaar).

Maar zeg eens, wat was hier de reden van het gebruik van het "sleuteltje" ?

Volgens mij "werkt" er hier iets niet. En waar ik halfweg het topic al niet goed meer kon reageren omdat ik "iets" niet kon volgen, lijkt het nu wat duidelijker nu het topic wat meer is uitgebreid met voeding van beide kanten.

Zo, dat was een belangrijke tekst zeg ...


Als we een printje printen, dan printen we dat om het te bekijken; niet om het op te slaan. Als ik het zo proef dan lijkt het met deze geachte andersom gemaakt : We slaan een printje op omdat dat nu eenmaal kan, en als je 'm ook nog wil bekijken, tja ... dan had je er maar geen PDF van moeten maken ? haha
Ik heb het ook zo niet beschreven (wat mij betreft, lees : ik heb het er nu niet op nagekeken), en wat ik wèl heb beschreven gaat wat mij betreft uit van *altijd* tonen, met vervolgens de mogelijkheid om op te slaan. Echter, dit ging toen nog uit van een wat minder hebbelijke methode, en was zelfs nog voor Johan het had "goedgekeurd", en betrof het gebruik maken van de Save (de floppy button) funktionaliteit van de PDF viewer zelf. Dus, dan besluit je nadat je het ding hebt gezien om 'm op te slaan, en meer logisch kan ik 'm niet bedenken (maar zie zodirekt).

Terzijde : Bovenstaande geldt voor alles behalve Inkooporders, Fakturen enz., omdat als je die opslaat, je dit om geheel andere reden doet, en dat is (waarschijnlijk ... lees : dat weten we zelf niet eens) ook precies de reden waarom je die dingen in een "dossier" opslaat (Kontakten). Het is gewoon je administratie, c.q. een onderdeel daarvan (of : een andere wijze van kunnen terugvinden wat je aan wie hebt gestuurd). Hier is nog veel meer over te vertellen wat het alleen maar waziger maakt, maar het credo is : het hele "bekijken" verhaal gaat over alles behalve de "Variabele Layout Prints".

Goed. Als we dus iets naar een PDF printen, dan deden we dat in eerste aanleg om het te kunnen emailen, en niet om te kunnen opslaan. En, als we het emailen willen we het ALTIJD eerst bekijken. Immers, het is geen Faktuur of Inkooporder enz., nee, het is gewoon een printje die we naar iemand willen emailen.
En hieruit volgt dus al doodleuk dat we het ding MOETEN KUNNEN ZIEN ... als we gaan emailen ... Maar :

Toen hebben we bedacht dat het handig is om de PDFs (en uiteindelijk : of HTMLs) ook te kunnen opslaan. Hieruit kan je voor jezelf laten volgen dat je een Artikelbestand uitprint (iedere maand enz.) om dat vervolgens ongezien op te slaan, maar erg normaal vind ik dat niet, en voor die situaties die kunnen worden verzonnen waarbij zulks wel normaal is, wel, dan krijg je eerst maar de print eerst te zien. Toch ?

Aldus, ook uit het laatste volgt dat het helemaal normaal is (op een uitzondering na die echt geen pijn gaat doen) dat de PDF eerst op het scherm komt. Goedgekeurd ? opslaan die handel.

...

Ehh ... jahaa ... als je NIET aan wat Johan wil denkt. Immers, dan klik je op die floppy, en mag je vervolgens zelf uitzoeken waar het het ding opslaat (één van de grootste Windows ergernissen overigens omdat dit niet per applikatie wordt onthouden), en komt het allemaal wel goed op deze manier. Maar nu hebben we helaas wel gedaan wat Johan wil, en moet die floppy dus weten waar het dokument moet worden opgeslagen (en ga er maar vanuit dat dat niet kan (is niet waar, maar toch vanuit gaan)), en dat werkt dus niet. En, waar je hier eventueel nog over denkt om te gaan maken, doe je dat echt niet als je ziet dat het ook een HTML output kan zijn. Want tja, dat hadden we intussen ook verzonnen dat dat moest kunnen (stom natuurlijk, maar ja).


Nu het hopelijk duidelijk is wat het probleem eigenlijk is, zie je ook wel hoe het moet worden opgelost : na het bekijken besluiten om het op te slaan. Dus, niet op een mooie manier via de floppy, maar na wegkruisen en het beantwoorden van een vraag van Profit die er intussen staat (Opslaan J/N ?).

Hmm ... Nu ik ben uitgetypt lijkt dit me het probleem niet (voor ons).
Ziet iemand anders nog andere bezwaren ?

Mwah, ik vind het toch niet helemaal lekker dat bij een niet ingevulde EIND datum dit wordt beoordeeld als "is dus vandaag of gisteren enz.". Ongetwijfeld hoor je dit niet zo in te kunnen vullen, maar als dat dan eenmaal toch zo is, vind ik dat de datum in de oneindige toekomst ligt.

Ik kan even niet de helptekst vinden, maar als je een "Notitie Debiteur" maakt (zie toets bij Raadplegen Debiteuren), met als datum/tijd 01-01-1900 (of was het 1901 ?). Vervolgens komt deze Notitie naar voren bij het Toevoegen van de Verkooporder Header.
Misschien is er ergens ook nog een parameter waarmee je kan zeggen of je dat wel wilt (zien).

Dit is hopelijk even beter iets dan niets. Sorry ...