Zodra e.e.a. aktief is zullen we het hier melden.

Neu, dat loggen hadden we nog niet aktief (/ gemaakt). Gaan we nu maar eens doen ...

Wat mij betreft OK.

OK, na een telefoontje denk ik het begrepen te hebben :

De gele regels die we in de schermprints zien zijn de tekstregels. Die hangen op zich aan een normale regel (zie de kolom met de "r" erin in de RA funktie).
De gele regels zijn representatief voor een bedrag en dit bedrag zien we per regel ook letterlijk in de Offerte terug. Eigenlijk zoals getoond (zie eerdere post(s)). Maar omdat het tekst is, telt niets die bedragen bij elkaar en klopt het Offertebedrag onderop niet omdat daar immers alleen de regels uit de RA funktie bij elkaar worden geteld (Variabele Layout). Er zou dus iets moeten komen wat "de ontbrekende 700" (besloten in de gele (tekst)regels) in de Layout Variabele voor het totaal kan schuiven (erbij kan tellen). Dit kan dan met een dummy regel mits die in zijn geheel niet wordt getoond en het kan middels e.o.a. veldje ergens dat je per Offerte kan invullen en wat de Layout Variabele expliciet oppikt.
Ik weet eigenlijk niet wat makkelijker is voor ons (en goedkoper) maar neig naar het meer duidelijk zijn van de dummy regel die niet wordt getoond. Immers, nu kan je ook meerdere van die blokken tekst hebben terwijl je anders de representanten qua bedrag bij elkaar moet tellen in het ene ervoor beschikbare veld. Mijn voorstel aldus :

J/N Weergeven erbij in de Offerteregel.
Variabele Layout aanpassen opdat alle herhalende (Regel-)variabelen niet worden afgedrukt bij Weergeven N terwijl de optellingen allemaal wel blijven plaatsvinden in Totaal-variabelen.
Als dit laatste te lastig is, dan toch maar het aparte veldje met het "ontbrekende" bedrag.

Als Pascal een voorkeur heeft dan meldt hij dat wel, en Richard mag eveneens zijn voorkeur uitspreken.

Gaat lekker zo. Zou je mijn voorbeeld nog eens kunnen bekijken ?

---

1x Blaaskaak BBBNr 0124 : 27,50
2x BowHorn BBBnr 1788 : 40,00

Totaal : 767,50

---

Waar komt die 700 "te veel" vandaan ? volgens mij van jouw dummy artikel, wat je dus nergens ziet.
Bovenstaande staat dus letterlijk op de offerte. En graag niet een nieuw voorbeeld maken zoals in je voorgaande post, maar zeggen wat ik hier verkeerd doe, OF begrijpen dat dit zo niet kan.
N.b.: Die offerte hoef je mij niet te sturen, want die ga ik niet begrijpen. Er staat nl. voor 700 onverklaard spul op.

Voor de zekerheid nog even wat in je Offerte Regels staat :

---

1x Blaaskaak BBBNr 0124 : 27,50
2x BowHorn BBBnr 1788 : 40,00
1x RoepToeter (Groot en Dummy) : 700

Totaal : 767,50

---

Hmm ... Dus :


Dus je wilt wel een Offerte-regel, je wilt neem ik aan wel een prijs voor die regel opnemen (zeg net zoals ik het deed), deze prijs moet wel worden meegenomen in een totaal-variabele, maar de regel zelf mag niet zichtbaar zijn ?? Bijvoorbeeld :

---

1x Blaaskaak BBBNr 0124 : 27,50
2x BowHorn BBBnr 1788 : 40,00

Totaal : 767,50

---

Nee, ik snap het niet.

Onderstaande is te simpel ?
N.b.: Deze heb ik gedefineerd als Kostenartikel. Eenmalig dus voor materiaal (5101) en voor "dienst" (5100).
Nix "prijzen per" natuurlijk, maar de aanbieding kan je wel doen (heb er geen Offerte van gemaakt, maar dat werkt van ook wel).

N.b.: Bij een tweede opname van zo'n Kostenartikel zit er een foutje in het opnemen van de Omschrijving (blijft default). Die dus om te testen even aanpassen via Wijzigen. Dit foutje kunnen we uiteraard eruit halen.

Ik heb er al 15 jaar niet meer van gehoord, maar ik kan intussen wel een oorzaak bedenken ...
Locktabel te klein.
Nou ja, zoiets en dan nog redelijk ver gezocht (ook al omdat dit volgens mij een Novell aangelegenheid was). Dus eerst moet iemand maar eens achterhalen of het fenomeen voor een Windows server nog bestaat.

Goed. Het valt op dat dit altijd bij precies dezelfde Boekingsregel in de Journalisering fout gaat. Dit is 100% zeker geen toeval. Ook valt het op dat het zo te zien nooit ergens anders dan bij Omvormen fout gaat (@Pascal ?). Verder is het klip en klaar dat als anderen vrijgeven het Omvormen verder kan. Dit wijst wat mij betreft (best wel 100% zeker) op een algemene pool die vol is (vandaar het "Locktabel" idee).
Een ander datapoint is dat het onmogelijk is dat iets bij vdBosch "te groot" is in het algemeen en dan doelend op "zo veel gebruikers heeft vdBosch nou ook weer niet". Moraal hiervan : het moet iets zijn wat bij vdBosch anders is ingericht qua server, of eventueel qua installatie van VFP lokaal. Of zelfs dat VFP niet lokaal is geïnstalleerd terwijl dit wel moet. Of (bijna het meest voor de hand liggend) dat de caching op een andere manier werkt omdat er ergens aan "client" tussen zit die de boel vernaggelt. Ik denk aan de vroegere Novell client - iets wat het tegenwoordige Citrix ook zou kunnen (fout) doen. En let wel, het is feitelijk een netwerk probleem wat voor VFP alles met caching van doen heeft en wat met name lokaal (PC of WTS) gebeurt (veel minder aan de server zijde dus).

Buiten het Locktabel verhaal (wat, ik vrees, niet meer bestaat) kan je m.i. het beste flink achterover gaan zitten en
a. achterhalen sinds wanneer dit probleem bestaat;
b. kijken in alles log etc. wat er sindsdien is veranderd aan server en iedere PC. N.b.: Ik denk niet dat je naar het netwerk zelf hoeft te kijken (dus ook geen switches en zo).

Ad b.
Als je nergens Windows 10 hebt, ben je van dat af als mogelijke oorzaak. Maar let op : waar ik normaliter gemakkelijk W10 van alles de schuld zou geven, denk ik dat dit in dit geval niet opgaat omdat er intussen te veel andere klanten en gebruikers aldaar met W10 werken (en ook met WS2016).

Wij zouden nog een log kunnen inbouwen van de uitgevoerde commands in deze Journalisering bij Omvormen (alleen daar dus) en als het euvel wederom optreedt kunnen wij op dat moment kijken waar de boel stokt. Mochten wij daarvoor niet beschikbaar zijn op het betreffende moment, dan zullen we het achteraf ook wel kunnen vinden, als jullie aangeven wanneer (datum/tijd) het was en dan kijken wij wel naar de tijd die als het goed is ten tijde van het euvel "stil stond". Of dit ons echt helpt hangt een beetje af van de intelligentie van de log, waarbij ik alvast aangeef dat het NIET om Locken gaat, maar juist om zaken waar dit in de programmatuur niet gebeurt en VFP zelf iets doet (er zijn onvoldoende resources). Denk aan Append Blank. Wellicht is een log die ik bedoel niet eens goed mogelijk (tenzij we "Q" installeren maar dat vind ik wat ver gaan).
Overigens zou de aandacht nog kunnen gaan naar grootboekrekening 70000.0 of wat het ook is wat ik daar zie. En verder ... zie ik het goed ? wordt daar record 1 weergegeven ? Ik zou het toch denken ... En als dat zo is zijn we al 10x verder met theoretisch zoeken. Of, met het inbouwen van log entries (immers, de manipulatie met record 1 bevindt zich in een beperkt aantal SY programma's).

Verder nog iets ?

Ik geloof er niets van. Maar we gaan het binnenkort zien.

De Algemene Verordering Gegevensbescherming (AVG) noopt tot een uitspraak aangaande wat Heart Informatisering B.V. doet met uw persoonsgegevens. Dit betreft feitelijk alleen Email adres en telefoonnummer (dit kan tevens het1 privé nummer bettreffen). Wat doen wij met deze gegevens ? -> Niets.

Algemeen - onze zijde

Deze gegevens worden opgeslagen in onze database en is benodigd om te communiceren met u - dit is soms voor de gezelligheid en meestal zakelijk - ten behoeve van ondersteuning van de (ERP) software.
Overigens worden deze gegevens opgeslagen tezamen met uw naam en voorletters, opdat we weten wie we bellen of emailen.

Zoals u weet zenden wij u nimmer ongevraagde (kommmerciële) emails - de selektiemiddelen hebben wij hiervoor niet, ook al beschikken wij wel over ERP software die deze mogelijkheden biedt; wij gebruiken deze software zelf niet en genoemde database bevindt zich niet binnen het ERP systeem.
N.b.: Ooit in een ver verleden (25+ jaar) hebben wij enkele keren ongevraagd post verzonden.

Bedoelde gegevens zijn - en worden niet overgenomen (opgenomen) in derden systemen. N.b.: Ook niet in de systemen van vervoerders aangezien wij daarvan geen gebruik maken (Heart levert geen fysiek produkt) en ook niet in een systeem als PayPal aangezien dit geen betaalmiddel is voor Heart.

De door u verstrekte NAW en ook naam gegevens worden uiteraard gebruikt om fakturen of andere zakelijke dokumenten naar te verzenden. Wij gaan er niet van uit dat dit uw expliciete goedkeuring behoeft. N.b.: De Verordening geeft dit wel aan ("optin"), maar de kaders waarbinnen dit moet gebeuren zijn vooralsnog (te) vaag en gaan ook te ver en gaan in tegen alles wat natuurlijk is. Waarvan akte.

Het ERP systeem - uw zijde

Het ERP systeem (Heart-Profit) bevat diverse schier ontuitputtelijke mogelijkheden om de gegevens van relaties - waaronder personen - op te slaan, te selekteren, te groeperen en geadresseerd te printen of te emailen. Of u als klant / van Heart-Profit hiervan gebruik maakt weten wij niet - dit is aan u. Het is tevens aan u om hierover een statement te maken in algemene zin zoals deze (hiermee niet zeggend dat dit een ultiem - of zelfs goed voorbeeld is), maar het (stringente) advies is om dit wèl te doen.

U gebruikt de adresgegevens (NAW, Email) uiteraard om fakturen te sturen, offertes aan te vragen, inkopen te doen en alles wat zakelijk gezien nodig is - daarvoor is een ERP systeem bedoeld. U zult niet altijd fakturen enzovoort naar consumenten sturen, maar u dient zich te realiseren dat de faktuur enzovoort veelal wel degelijk gericht zal zijn aan een persoon als zodanig, waarmee u alsnog persoonsgegevens opslaat èn gebruikt. Dit gebruik is uiteraard voor het doel waarvoor het door de geadresseerde in het leven is geroepen (die wil graag een faktuur ontvangen ;-) maar de AVG zit zo in elkaar dat u feitelijk moet vragen aan de persoon of hij fakturen wenst te ontvangen (via bijvoorbeeld email). Dit klinkt nog "logisch". Echter, wanneer u goederen moet verzenden naar een adres, zou u wederom moeten vragen of het goed is als het door de klant gegeven adres mag worden gebruikt om goederen naar te verzenden. Dit klinkt niét logish, maar het is goed om zulks kenbaar te maken (op bijvoorbeeld uw website - "wij gaan er van uit dat u het goed vindt dat wij goederen sturen naar de adressen die u daarvoor zelf heeft aangereikt").

U dient u er goed van te gewissen dat de Verordening feitelijk onuitvoerbaar wordt indien u gebruik maakt van services van derden met als meest eenvoudige en te begrijpen voorbeeld : UPS (United Parcel Services); deze vervoerder zal de door u ingegeven (doorgegeven) gegevens in haar database hebben opgeslagen, betreft net zo goed persoonsgegevens maar UPS is Amerikaans en doet niet mee aan de GDPR (niet uitgezocht, maar gaan we voor dit voorbeeld van uit). UPS kan nu alsnog doen wat ze wil met deze gegevens, echter, u bent er verantwoordelijk voor. Dus als later blijkt dat UPS deze gegevens gebruikt (misbruikt) voor een algemene kommerciële - of anders) email, dan betreft het door u aangeleverde gegevens die u veelal zelf heeft ingevoerd en krijgt u de boete. N.b.: Als het niet duidelijk is wie de schuldige is, krijgen alle partijen die schuldig zouden kunnen zijn, de boete. Later kunt u onderling uitvechten (rechtzaken) wie de werkelijke schuldige is.

---

Natuurlijk is deze Verordening onuitvoerbaar.

Toch is het goed om zo duidelijk als mogelijk standpunten in te nemen en deze uit te dragen opdat u in elk geval toont dat u uw beste been heeft voort gezet in deze terwijl u tegelijk zult zien dat alleen al het opstellen van een stukje zoals voorliggend, u aan dingen doet denken in de zin van "maar wacht eens even ! ...". De persoonsgegevens bevinden zich overal en de verspreiding gaat als een virus. In de meeste (goedbedoelende gevallen) kunt u daar niets aan - of tegen doen. Het is een noodzaak. Maak zulks kenbaar !

Best wel goed bedacht. Ik zou nog niet kunnen bedenken hoe dit dan loopt, maar hoe een koe een haas vangt heb ik ook nooit begrepen.
Misschien kan je eens kijken of the Kostprijs van het betreffende Voorraad Item inderdaad 0 is ? (en ik denk dat je misschien vanzelf tegen iets vreemds aanloopt als je hier naar gaat kijken).

Misschien kan je ook even "Kostprijs" i.p.v. Prijs in de topic titel zetten (heb ik voor deze post ook gedaan).

Dat is wel zo en dat is wel goed, maar nooit behoort dit de "Record not available" te impliceren. OK, kan denkelijk ergens wel gebeuren in een voor ons onverwachte situatie (die we niet eens kennen) maar het uitvaardigen van "iedereen snel terug naar het hoofdmenu !" is overdreven.
Eeuwig in wijzigen Produktieorder (of 1000 anderen) blijven zitten moet je niet doen want dan krijg de rest "De gegevens zijn geallokeerd door een andere gebruiker". Maar naar die situatie zijn we helemaal niet op zoek ...

Probeer (eerst) eens TBC ?

Eh ... kijk eens in je email op 20-02 ergens na 15:00 ...

OK ?

Komt wel goed, denk ik.
We ondernemen een poging voor Shift-F9 en Shift-F10 (Shift-F10 zou een probleem kunnen geven, maar we zien wel).