Je bedoelt dat we een faktuur mogen sturren ?
Of geld mogen rekenen voor het opnieuw maken ?
 

Waarvoor denk jij eigenlijk dat die draaibol is ? om stoned van te worden ?

Je kunt maar beter je email in de gaten houden.

Twee strafdagen.

We hebben ze allebei weggehaald.
Staat al op je systeem.
 

Nee nu niet.
Of bedoel je dat je niet gelooft dat wij hetgeen zoals beschreven onder #3 voor elkaar krijgen ?

Zeker vrijdagmiddag ... 

Jaja gebruikert, u is lekker duidelijk. 
Wil je -gezien bovenstaande quotes- nou soms zeggen dat je de sneltoets vanuit het Artikelmenu hebt gebruikt ?
Wil je soms zeggen dat het pas fout gaat na xxxx maal, je dit eigenlijk geheim wilde houden en ons maar laat knoeien totdat we het minimaal 1.000 keer hebben geprobeerd ?

Misschien dat jij een raamambtenaar bent, maar wij niet !
 

Nou, daar hebben we wat aan. 
Kun je dan ook aangeven hoe het beschreven probleem wèl wordt opgelost ? immers, als het goed is bestaat het probleem niet.
Of ?

Daarnaast ben ik het vast niet met je eens. Bladlengte = Bladlengte, en die zal er -als alles goed is- voor zorgen dat er na 72 regels ook een nieuw blad ontstaat.
Zeg het maar ...

Ja, en wij moeten raden wat jij hebt gedaan.

Kun je het nog eens proberen na te doen en dan precies aangeven hoe en wat ?
Wij kunnen dit hier niet nadoen ...

Marco,


Zeg dat dan meteen. 

Als je dit werkelijk wilt, zit er niets anders op dan het aan te passen zoals je wilt, met de garantie dat je een keer die Kosten niet faktureert (zie eerder betoog van mijn kant) of het wordt onbetaalbaar. Merk svp op dat wij er niets aan kunnen doen dat je iets wilt wat feitelijk onmogelijk is, eraan denkend dat er geen "logistiek" bestaat rond het optreden van die kosten, als je eìgenlijk geen koppeling met de produkten wenst (en het ook automatisch wilt laten werken).
Denkelijk bestaan nu de volgende opties :

1.
Letterlijk doen wat je wilt, c.q. waarvan je denkt dat je ermee uit de voeten kunt;
De "Leverdatum" van de Kostenregel zal dan worden gerespekteerd bij de Fakturering, waarbij je vooral in de gaten moet houden dat als je faktureert maar niets levert, die Kostenregel dùs wordt gefaktureerd. En ook :
Als je te vroeg levert, zal de Kostenregel niet worden gefaktureerd.
Hierbij hoort een Bedrijfsparameter, aangezien het niet mogelijk is om iedereen met deze werkwijze te konfronteren, een werkwijze die fishy is.
De garantie dat de werking rond de Fakturering consistent blijft krijg je niet; wel willen wij net zo lang als dat het moet op basis van regie blijven vervolmaken. N.b.: Ik doel hier op zaken als het te vroeg leveren, en bij een latere Faktuurrun (de Datum voldoet nu) de Faktuur voor de Kosten toch niet wordt gegenereerd, omdat de Status al F is, of , de Faktuur er toch wel uit komt maar de Status geen F wordt, enz. enz. enz.
Kosten 5 uur.

2.
Idem als 1, maar nu inklusief de voorziening dat het Kostenartikel wordt gerelateerd aan de Artikelregels die erboven staan.
Geen degelijke methode (voor de gebruiker), aangezien je binnen dat deel wat erboven staat weer Deelleveringen zou kunnen doen, en je eigenlijk maar moet afwachten of wat er gebeurt je aanstaat. Beter : er zijn hier best wat mogelijkheden, die wij even niet voor je uitwerken, en ook als je het zelf doet zullen we langer bezig zijn met dáár weer op te schieten, dat het het werk zelf te boven gaat (goed, mag normaal zijn in dit land).
16 uur extra.

3.
Het ontwikkelen van een DKK die werkt per Levering.
Ook deze methode stinkt, omdat je normaliter (*) op deze manier niet op voorhand de "Kostenregel" op de juiste plaats weet te positioneren, feitelijk omdat je -letterlijk genomen- niet op voorhand weet wat je levert (zie weer Deellevering binnen de Deellevering).
* Alles kan, en reken daarvoor 12 uur extra.
Een nieuwe DKK kost 44 uur.

4.
Een hele andere methode, die met als trigger de Levering, de Kosten aan de Verkooporder toevoegt (onderaan), die aldus meteen zullen worden meegenomen bij de (eerstvolgende) Fakturering.
Dit lijkt nog de beste methode, met wèl als nadeel dat je e.e.a. (Orderevestiging) formeel niet op voorhand aan de klant kunt duidelijk maken.
Merk wel op dat een methode als deze, op zichzelf zo "degelijk" is, dat ieder blikje wat je levert, vanzelf gepaard zal gaan met zo'n Kostenregel voor jouw vaste bedrag. Wel zul je een als overbodig geachte Kostenregel kunnen Verwijderen, dan wel de Verkoopprijs daarvan kunnen aanpassen.
9 uur (uitgaande van een vaste prijs voor iedereen (!)).


Wat je wilt is best logisch, maar ja ...

Peter

Het zal toch zeker wel zo zijn dat je onderstaande 72 niet op 999 hebt gezet > 

De fysieke lengte van de print op het scherm zal hiermee heus 999 regels zijn (dus, 999 regels verderop krijg je ==Einde Overzicht==), maar  daar gaat het je toch niet om ? of juist wel ?


Die marge ontstaat omdat het een print is en blijft. Kijk overigens eens naar de kop van de print, of die toch niet stiekem meer naar links staat dan de rest (volgens mij is dat namelijk standaard werkwijze). Zo niet :

Probeer de marge te beinvloeden door een negatieve kantlijn op te geven.
Niet dat je dat gaat lukken, want je hebt nu te maken met schermdrivers, en dáár heeft echt niemand meer de boekjes van zoals die in 1980 bestonden ... (maar als je weet hoe het moet, moet het kunnen; wij weten dit overigens niét).

Oh ...
Ehh, Marco, als dat voor jou zou voldoen kan je je aanbieding ook wel weer weggooien.

?

Ook welkom Frank ! 

Nou is dat wel leuk van mij bedacht, maar zonder ook maar 1 seconde tijd te hebben besteed aan wat research, denk ik dat je van deze processors niet de "cores" kunt samentrekken opdat je bij elkaar 4,8GHz hebt (wat met Hyperthreading wel kan).

Ook de 4GB is een mooi verhaal, maar werkt natuurlijk alleen met XP/Vista 64bit (anders limiet tot 2GB).

Zo'n processor is in elk geval wèl mooi voor Batchprocessor taken (en dan zware taken), wetend dat de Batchprocessor "multithreaded" (en parallel) haar taken afhandelt. Nou ja, binnenkort dan.

Ik snap eigenlijk niet hoe je dit logistiek verder regelt dan.
"Niet" is natuurlijk ook een antwoord. 

Voor mezelf uitleggend wat je bedoelt :

Je hebt twee Debiteuren die op elkaar lijken kwa ID, de eerste is geblokkeerd voor Levering, en vervolgens brengt de tweede z'n pallets retour, maar boek je die per ongeluk op de eerste, en in plaats van dat je die klant niet levert, krijgt hij nou nog geld terug ook.

Hmm ...

Ik wil/mag me niet bemoeien met de werkwijze, maar ik weet niet of het wel terecht is dat je zo handelt. Immers, als ik geen geld meer heb om eem breezer te kopen bij de AH, dan mag ik toch hoop ik nog wel m'n krat bier (zonder bier) inleveren, om daar vervolgens statiegeld voor terug te ontvangen. En, daarna kan ik m'n breezer ook weer kopen ...

Moraal : ik vermoed dat je wettelijk wel eens fout zou kunnen zitten als je het niet toestaat emballage terug te nemen en daarvoor geld terug te geven.

Nou zie ik je al denken : maar daar gaat het niet over !
Nee ... dat begrijp ik, maar voorlopig hanteer je een middel wat in de basis al niet juist is. Immers, als die geblokkeerde klant wel degelijk zelf z'n emballage terug komt brengen, zou je het eveneens niet kunnen accepteren ...

Je weet het, wij (het pakket) gaan hier over de werkelijkheid en jouw idee hoort daar niet in thuis.
Dat je het opgelost wilt(/moet) hebben is duidelijk, maar probeer eens een verhaal te bedenken wat de werkelijkheid geen geweld aan doet.

 

Ik denk zelf dat het uiteindelijk anders zou moeten werken, althans, wil je kunnen voldoen aan wat Dirk-Jan doet/wenst;

Hij schuift de nog niet geleverde pallet enz. op een "meer normale" Voorraadlokatie, alwaar de handel blijft staan totdat de klant z'n spulletjes (eindelijk) komt ophalen. Dus, fysiek zal het al niet werken als je alles op die ene administratieve Lokatie zet. En daarnaast zul je inderdaad meerdere hallen met verschillende eisen hebben.

Of we dit gemakkelijk zo kunnen aanpassen dat alles Wachtlokatie mag zijn (want dat wil je feitelijk) weet ik zo snel niet ...