Ik begrijp het niet (goh wat heb ik dat vaak) ... als je het al eerder hebt gevraagd, waarom vraag je het dan nogmaals ?

Antwoorden zijn hetzelfde trouwens.

Overigens mag je heus ontevreden zijn met het antwoord, maar om er nou een nieuw topic voor te openen ...

Ohh ... dan zit er gelukkig nog niets in !

Jaja, laat maar. Hier zal het wel om "regelrecht" gaan, wat niets doet.

Toch graag het verzoek om wat duidelijker te schrijven (dan zal ik het ook proberen, hahaha).

Maar goed, kun je ook niet-regelrecht aan het buitenland leveren ? (en voor de belasting opdraaien)

De logika ontgaat mij hier. Niet dat ik een discussie met de wetgever wil aangaan , maar wel dat ik me afvraag waar je dit vandaan hebt (ik weet het, ik moet misschien de wettekst opnieuw lezen). Maar ook hier : ik weet niet beter alsof alles heeft niets met jouw leveringen aan het buitenland te maken. De gevraagde (letterlijke) DKK heb je dus ook niet nodig, tenzij je daarmee het ondrscheid tussen binnen- en buitenland wuilt aangeven.

Ik heb het er niet weer op nagelezen, heb destijds misschien net een oudere versie gelezen, maar ik weet niet beter of tot 15000Kg is vrijgesteld. Dus ik weet niet of je hierboven nu letterlijk zegt wat je bedoelt (zit 'm met name in het het woordje "ook").

Ja hoor dat kan wel, maar dan wordt het een uurtje meer.

Over uurtjes meer ... toch even over de PDF printer :
In de 20 uur zit *niet* eventueel uitzoekwerk aangaande een PDF printer die alles doet op een wijze die jij wilt, en dit ook versus wat wij ervan verwachten. Dus, je hebt mooiere en minder mooiere (kwa "afdruk" kwaliteit), je hebt beter en minder comprimerende (als je niet oppast neemt een A4 1 MB in beslag), en je hebt degelijke en gammele PDF printers. Met het laatste doel ik op printers die achter je rug om de boel verzieken, zoals het veranderen van de "Startlokatie" (zie Desktop Icons) waardoor Profit vastloopt.
Flexibiliteit is ook belangrijk, bijvoorbeeld denkend aan het moeten kunnen aangeven waar de PDF moet worden weggeschreven, opdat wij het kunnen oppikken van een lokatie die *wij* aangeven.

Als je het laatste even als voorbeeld neemt, dan snap je wel dat we het ook zo kunnen maken dat *jij* aangeeft aan Profit waar het ding te vinden zal zijn, alleen, niet voor die 20 uur. Moraal : er kan van alles aan de hand zijn met de door jou aangeschafte PDF printer, waardoor wij moeite moeten gaan doen om het allemaal goed te laten werken. Anders gezegd : hiervoor is 0 uur gereserveerd.
Ga er gerust vanuit dat hoe duurder de door jou aan te schaffen software is, hoe degelelijker / mooier / flexibeler ze is.

Helaas hebben wij zelf niet de ervaring met een juiste keuze in deze, maar misschien dat anderen dat wel weten ?


PS: Die PDF995 vind ik persoonlijk een typisch voorbeeld van "niet mooi". Wellicht is het daarmee toch mooi te krijgen, maar houd er rekening mee dat je dat 2 dagen "leren" kan kosten, en of je het nu zelf doet of wij, die 2 dagen kunnen weggegooid blijken op het moment dat het gewoon niet beter kàn.

Demis, als je nog een minuutje hebt ... zou je ook een goed-werkende versie kunnen laten zien hier ? Is denk ik voor anderen ook wel leuk om te zien, en anders ben ik zelf wel benieuwd ...

Overigens neem ik aan dat je met het muis-verhaal bedoelt dat je de raapkant kon veranderen (want zichtbaar is het toch altijd ?).

Ja.



De minimum afname is er niet voor niets.
Nee dus.

Voor ieder's gedachte bij de uitwerking naar kostprijzen, verwacht vs. gebruikt enz., en wat dit voor een gevolg heeft :
Vraag je s.v.p. af of je geen redenen kunt hebben expliciet 0,000 te boeken. Immers, wat ik ervan begrijp kan dit nu niet meer.

Johan, na wat onderzoek, komen wij met het volgende op de proppen. Althans, twee hoofdredenen. De eerste (engelse tekst hieronder) kan wat mij betreft op jullie van toepassing zijn, ook al vind ik het vergezocht. Echter, de reden waarom ik toch meen dat het kan, is omdat je ongeveer de enige bent die het heeft (volgens mij was er nog ergens iemand, maar die kan ik niet meer vinden).
Heb je inderdaad TTS aan staan, zet het dan eens uit; wij gebruiken dat niet.


Reden 1 :

---

SYMPTOMS
A FoxPro application running in a multiuser environment occasionally displays a message box containing this scrolling message:
Record not available ... Please Wait
This message may scroll for a few minutes or for as long as an hour or more.

CAUSE
FoxPro is receiving a busy signal when requesting a process from the server. There are two possible causes for the busy signal:

• Novell's Transaction Tracking Services (TTS) is active.

-or-
• There is a contention problem on the network server due to:

• Several users actively adding or updating records to a database where the CDX contains a large number of Tags or several very complex Tags.

-or-
• A large number of users are actively adding or updating records in a less than optimal network environment.

-or-
• Various combinations of the above.
 
The scrolling message results from FoxPro requesting a process from the network server and receiving a busy signal. This is not an error message, but rather an informational message from FoxPro. It is in essence saying "I have completed your transactions and handed off the update to the file server, but the file server is still working on completing some other updates to this file. Would you please wait?"

RESOLUTION
A workstation that gets this message will eventually be able to complete the pending process, although this could take a considerable amount of time.

If TTS is running, try turning it off. FoxPro does not provide direct support for Novell TTS. However, Novell provides a library (Nwtts.dll) that works with the FoxPro Library Construction Kit (LCK) to accomplish transactional processing.

Support for transactions has been implemented in Visual FoxPro. For more information, search for 'Transactions' in the Visual FoxPro Online Help. If TTS is not running, the problem is most likely a contention problem on the server. This means that the server is receiving more requests for processing transactions than it can deal with so they're backing up in the server's process queue. Eventually the server will catch up, the queue will be emptied out, and things will be back to normal.

Avoiding This Network Storm
It's important to note that because there is no error condition, there is no error to trap. Once this message appears, the network is already experiencing a network storm and the only resolution is to have all users stop what they're doing and wait for it to clear. The preferred approach is to take steps to avoid the storm in the first place.

Two known approaches involve upgrading to a more powerful network or moderating the flow of process requests to the network server. While upgrading the network may be prohibitive, it is often relatively easy to moderate the flow of process requests to the server.

---

Merk nog op dat je met enige sjoege van de materie wel moet kunnen zien of de server het druk heeft op het betreffende moment.


Reden 2 :

Deze is lastiger te herkennen, maar kan wat mij betreft heel goed aan de orde zijn. Hooguit geldt ook hier : waarom heeft niemand er last van en jullie wel;
N.b.: Waar bovenstaand engelse verhaal van Microsoft zelf is, (onder)kent MS kennelijk niet het navolgende.

Het blijkt -en wij hebben dat ook zojuist pas gevonden- dat er in Visual FoxPro een bug zit, dan wel dat er in het OS een bug zit (dit kan niet worden bepaald).

Kort door de bocht samengevat komt het erop neer dat waar je op de ene PC één record locked, je op de andere PC('s ?) meerdere gelockte records aantreft (dit is op zich de bug) en wat zich op die andere PC's uit middels de scrollende melding (normaal is de mededeling van het OS anders, en deze scrollende melding is het gevolg van niet afgevangen situaties (door het OS), op zich logisch waar de oorzaak een bug is (lees ook het engelse verhaal hierboven, want dan wordt dit wat duidelijker).
Overigens resulteert ook het draaien van een backup in de server (let op "in") in hetzelfde, wat dermate "hard" gebeurt dat van buitenaf gezien de server inderdaad "busy" is (zie weer engelse verhaal).

Gezien de aard van de bug (welke technische uitleg ik je verder zal besparen) mag worden verwacht dat dit bij grotere bestanden eerder optreedt. Laten we maar zeggen dat jullie Voorraadmutaties (LOVM) van 1,1GB "groter" is. Let wel, dit zegt niet alles, want anderen werken met bestanden tot aan de 2GB en hebben geen probleem.

Er zijn veel variaties die het probleem wat mij betreft beïnvloeden, zoals ook het netwerk OS. Dus het is maar vast gezegd : waar jullie Novell gebruiken (toch ?) hebben de meesten dat niet meer; op zich dus een reden om de bug niet tegen te komen.
Denkelijk nog belangrijker is de netwerk client, doch deze is veelal verbonden aan het netwerk OS. Dit hoeft op zich niet, want iedereen kan de MS client gebruiken, doch voor de hand ligt dit niet. Gebruiken jullie de Novell Client (waar op zich meerdere versies van bestaan) dan heb je dus weer een reden om de bug tegen te komen, waar anderen hem niet hebben.

Als de bug zich eenmaal gestand doet (en let wel, dat lijkt op zich standaard ( ?)) dan hangt het vervolgens erg van de record lengte af. Zie het maar zo, dat als de recordlengte 100 is, er 1 record teveel wordt gelocked, is de lengte 101 worden er twee records teveel gelocked, bij 103 3 enzovoort, tot 200 dan is alles weer goed. Bij 201 weer 1 te veel enzovoort.
Gewoon een verzonnen verhaal, maar het principe dat de lengte er toe doet is wel van belang. Immers, die lengte verandert door de upgrades heen.


Johan, als je niet herkent dat het engelse verhaal aan de orde is, resteert het kleiner maken van LOVM als een poging om het op te lossen. Dit dus, gebaseerd op het (vermeende) gegeven dat de bestandsgrootte er toe doet (dit kan ik zelf niet bevestigen en de logika ontgaat mij ook).  Helpt het dan helpt het, helpt het niet dan zitten we goed in de penarie, want ik zou niet weten wat er aan te doen.
Hooguit heb ik de hoop dat het onzin zou moeten zijn dat "we" die bug tegenkomen, want het zou voor het eerst in 20 jaar zijn. Maar goed, formeel bestaat ze ...

Houd voor jezelf, en het kleiner maken van LOVM in de gaten dat er ook nog iets is als een 1GB limiet waar de bug zich (in mijn theorie) manifesteert. Dus als je LOVM kleiner maakt, doe het dan zo dat je voorlopig de 1GB niet bereikt.

---

Als laatste de wellicht belangrijkste tip :
Ik heb redenen om aan te nemen dat het door elkaar gebruiken van VFP7 en VFP8 in deze uitmaakt. Verder durf ik er wel op te gokken dat jullie dat ook doen. Eigenlijk zou ik dan ook als eerste er voor zorgen dat alles onder VFP8 draait, gevolgd door het reorganiseren van alles (het laatste is zeer van belang).
Voor zover kritisch : houdt er rekening mee dat als je onder VFP8 reorganiseert, de indexen ongeveer twee keer zo groot worden ... opdat er niet ineens een disk ergens vol is.

Peter

Het is slecht te overzien, maar houd het maar op 6 uur werk om ervoor te zorgen dat

• je een (maximale) Over Hoeveelheid mag opgeven bij het Kontrakt;
  
  
• als de normale Kontrakt Hoeveelheid bereikt is een volgende Orderregel niet meer dat Kontrakt zal voorstellen (is "afgedaan"), ook een zelfde Orderregel niet verder mag gaan dan de normale Kontrakt Hoeveelheid, maar er wel meer mag worden geleverd tot aan de Normale Hoeveelheid + Over Hoeveelheid;
  N.b.: De momentele situatie dat je de vraag krijgt om de Kontrakt Hoeveelheid op te hogen zal niet meer leiden tot het alsnog kunnen opnemen van de Hoeveelheid bij die zelfde Verkooporderregel als de vraag met Nee wordt beantwoord (wordt beschouwd als een bug);
  
  
• het voorgaande punt ook op juiste wijze wordt verwerkt in betreffende overzichten / gegevens;
  
  
• als bedoelde vraag in eervorig punt met Ja (Ophogen) wordt beantwoord zal *niet* de Over Hoeveelheid navenant worden aangepast.
  
  
• de Over Hoeveelheid niet negatief mag worden ingevuld (terwijl hier best toepassingen voor zijn te bedenken).
  
  
• het boeken van de Levering ook daadwerkelijk tot niet meer kan leiden dan het betreffende Kontrakt zegt (foutmelding).
  
  

Let op : Er zit denkelijk nog een adder onder het gras waar je te veel levert en je dus feitelijk de bestaande Verkooporder wilt uitbreiden met nog een Regel, dit ten eerste waarschijnlijk niet meer op de bestaande Verkooporder kan om diverse (Status) redenen, of in elk geval moet worden aangenomen dat dit niet zal kunnen, terwijl je dit ten tweede ook niet màg doen, omdat je jezelf er dan van weerhoudt om dat andere Kontrakt (met andere voorwaarden) te "zien". Aldus :
Als er meer is geleverd dan de Kontrakthoeveelheid (inkl. Over Hoeveelheid) moet het extra op een nieuwe Verkooporder worden geplaatst.

Dat laatste mag op zich, maar houd ze dan svp ook voor dat als de vrachtwagen terugkomt met 2 ton meer geleverd, je eerst inderdaad even een nieuwe Verkooporder moet maken (dat het niet alleen een nieuwe Regel betreft had ik in eerste instantie niet door; jij wel ).

Hoe het in dat geval met (getekende) Pakbonnen/Vrachtbrieven loopt moet je mij niet vragen !

En als je nou een (over) marge toestaat op een kontrakt ?
Dus, kontrakt voor 20 ton, maar je mag er 10% overheen gaan. Kom je bij de klant voor de laatste 2 ton, maar je blijkt 4 ton kwijt te kunnen (da's dus 2 ton onverwachts). Dan put je dus voor 2 ton extra uit dat kontrakt (sowieso niets mis mee volgens mijn stelling), maar je hoeft nu vooral die 2 ton niet uit het volgende kontrakt te putten.
Kwestie van afspraken met de klant.

?

Dit blijkt een verre van gemakkelijk verhaal, en wat zich bevindt rond het letterlijke fenomeen "Leveren". Zelf zag ik dit in het begin niet eens zo, maar Richard kwam daarmee, en nu heb ik mijn antwoord(en) wel ...

Als eerste zou ik zeggen : wat raar, als een leverancier een kontrakt met jou aangaat, dan zal het hem erom gaan dat hij weet dat hij i elk geval betreffende hoeveelheid zal gaan leveren (binnen de betreffende periode), en ook al wordt het meer bij een prijs die lager is dan standaard, die leverancier vindt dat vast niet erg. Mooi, en sec gezien heb ik daarin vast ook wel gelijk.
Alleen het is niet "sec" te zien ...

In jouw geval, wellicht wat specialer, heb je twee kontrakten, en wel één met 10 euro, en de ander met 11 euro. De standaard prijs is 12 euro ... En tja, als het eerste kontrakt op is, en het tweede er vast niet voor niets is, is het natuurlijk niet de bedoeling dat je voor 10 euro blijft afnemen, waar het intussen 11 zou moeten zijn "geworden". Kortom, ook dit is juist, waarmee het voorgaande juist niet meer goed is ... Ehh ... tenzij je maar één kontrakt hebt.

Nu stip je eigenlijk een heel ander onderwerp aan, wat op zich niet veel met jouw situatie te maken heeft, maar wat er wel voor zal zorgen dat je overzichten niet juist zijn (en jij bent de eerste die dat uitvlooit) ...;
Als je toestaat (zoals het systeem het toestaat) om op basis van Leveringen door te gaan op een Kontrakt (en volgens mij is dat nog formeel zo gemaakt ook), dan pas je feitelijk je Kontrakt aan, en wil je dat ook terugzien in de Verkooporderregels die er uiteindelijk tegenover zullen staan. Wel, dat gebeurt vast niet als je e.e.a. alleen maar op basis van Leveren bewerkstelligt. Eigenlijk werkt dit ook vanzelf (niet goed) omdat het denk ik zo is dat je alleen aan de Prijs kunt zien dat dat eigenlijk al opgesoupeerde Kontrakt wordt gebruikt. Mjah, wat is dat ? gewoon, de Prijs van dezelfde VORegel blijven hanteren. Wat nou Kontrakt ? het kan gewoon niet anders, en zou ook gebeuren als je 30 levert op 20 gevraagd (VORegel) zonder Kontrakt.

Het wordt nog wat raarder als je ziet dat er situaties zijn (hangen terecht of onterecht van Bulk J/N af), die je vragen om een meer-gevraagde Hoeveelheid BIJ HET KONTRAKT ERBIJ TE ZETTEN (dus, Kontrakt wordt impliciet opgehoogd), en als je daarop Nee zegt gebeurt dat inderdaad niet, maar heb je nog wel de situatie waar jij feitelijk mee komt : de Prijs van de VORegel wordt gewoon gehanteerd en dus lijkt het alsof alsnog het Kontrakt wortd gehanteerd (terwijl je Nee zei).

Het erge is ... hier kom je niet uit. Althans, niet voor iedereen tegelijk. Zou je het niet toestaan, dan kun je niet Leveren, tenzij je eerst een nieuwe VORegel aanmaakt, die vanzelf uit het volgende Kontrakt gaat snoepen. Maar ja, als je helemaal geen Kontrakt hebt, hoef je toch ook niet eerst een nieuwe VORegel aan te maken als je meer levert.

Konklusie : wat je wilt is in jouw situatie terecht, maar dat houdt nog niet in dat het gemakkelijk kan worden aangevat. Het zal echt duurder zijn dan je denkt (of wilt) om dit goed te krijgen. Dit hangt dan ook nog af van de mate van vriendelijkheid, met als voorbeeld het door het systeem automatisch aanmaken van een nieuwe VORegel op basis van een Raaplijst die toevallig met meer wordt ingevuld dan de eigenlijke VORegel vraagt, en dat alleen in de situaties dat dit ook nuttig is (denkelijk : twee Kontrakten aktief).
Denk sowieso aan een stapeltje Bedrijfsparameters, omdat zeker niet iedereen dat zo zou willen, of wij in elk geval dat soort procedures niet mogen aantasten van anderen (die dus NIET mekkeren hierover).

Prettig weekend dan maar !

Dat moet met 3 uur wel kunnen worden gerealiseerd.
Je dient daartoe wel zelf in de Kenmerk Domeinen de optredende kombinatie mogelijkheden (zoals die zijn toegestaan) op te nemen (als daar niets is ingevuld, mag alles; zodra er wat is ingevuld mag alleen dat).

E.e.a. zoals het ook mogelijk is bij Toevoegen Verkooporderregels.

Trouwens, heb je het over de Receptregels, of de Recept Header ? (de 3 uur gaat over één van de twee, maar beiden mag ook (6 uur)).