Andries,

Aannemend dat je begrijpt waarmee je bezig bent, is dit dermate ver van ons bed dat het antwoord domweg Nee moet zijn.

Zo werkt het gewoon allemaal niet ...
Ik begrijp al niet eens hoe je erop komt om handmatig een faktuur te gaan maken voor iets waar al automatisch een faktuur uitkomt ...

Zoals wel vaker kan ik me wel enigszins inleven bij wat wij krommiteiten zouden noemen bij die beton heren. Komt w.s. omdat ik zelf ook wat krom ben. Dus :

Ik denk niet dat we eraan hoeven twijfelen (of voorbeelden nodig hebben) dat wat Pascal zegt aan de orde is.
Ook denk ik niet dat dit ook maar enigszins met dat maatwerk te maken heeft. Het is in elk geval geen argument, en alleen wij kunnen zulk soort argumenten verzinnen (over rechtlijnig gesproken ). MAAR :

Waar Pascal nu aan voorbij gaat is (misschien niet als enige) de gesplitste regels, en wat dat voor de toekomst (na opschuiveen Kontrakt) inhoudt ...
Dus, wat Wouter ver weg zegt (of misschien dichterbij dan je denkt, maar dat moet je als betonboer ook maar weer doorhebben), is dat in voorkomende gevall zit met allemaal gesplitste regels, die een eigen leven gaan leiden, terwijl je dat helemaal niet meer wilt. Dus, het Kontrakt is opgeschoven, de 30 regels zijn eerder gesplitst in 60 (of misschien wel veel meer, denkend aan afroep-behoeftes), en nadat de handel is opgeschoven geldt dat (om redenen) helemaal niet meer. En daar gaat je zure tijd ...
Immers, je moet nu in de toekomst alles tigdubbel doen.

Dus wat je wilt - en wel sinds dat maatwerk- is dat alles ook weer kan worden samengevoegd.
Leuk heh ?

Maar Dinand ... Dit laatste kunnen wij nu niet meer volgen hoor. Jij weet natuurlijk precies wat je relatief aan elkaar aan het doen bent, maar wij niet. Dus, wil je op het laatste een goed antwoord krijgen, dan zal je toch stuk voor stuk je instellingen (en ik denk ook journaliseringen) moeten noemen.

Ok ?

Het lijkt me niet juist dat een Job die door de Kalender is gegenereerd In Behandeling is. Althans, voor zover jij dat bedoelt als "ziet er anders uit als een andere Job die nog op z'n starttijd staat te wachten -> beiden moeten er hetzelfde uit zien).

Dat JVR de volgende Job start (via het Kalender principe) is wèl juist. Immers, de Batchprocessor is slechts een middel om jouw taak over te nemen, en nadat dat is gebeurt "ben jij het gewoon". Vandaar ook mijn verwijzing naar de Print Queues e.d. die voor jou geëmuleerd moeten kunnen worden op de Batchprocessor, omdat dat een fysiek iets is wat wij kwa software niet in de hand hebben. Net zoals dat je "printen naar het scherm" gewoon niet voor elkaar kàn krijgen (ook a.g.v. fysieke beperking).

Dat is nou net het punt ... daar zijn anderen weer niet blij mee.

Ik verbaasde me er zelf al over dat ik bij die "enkele uren" - waar ze het eerst worden genoemd - refereer aan een user-id, waarvan ik overigens op dit moment niet eens zou weten hoe dat te doen. Bovenstaande tekst toont denkelijk hoe ik het bedoelde (en ook in mijn hoofd had). Hoe dan ook, je mag er gelijk in hebben dat zowel de 30 uur (betaald 10) als de enkele uren meer niet de verschillende vormen van verslagen dekken. Laat staan die uit verschillende entiteiten.

Wat we wel moeten zien te volgen, is dat ik met de bovenstaande uitwerking tracht alles aan te kunnen, ook al noem ik ergens


gewoon omdat ik denk dat dat voor die 30 uur kan.

Alles samengevat mogen we voor 30 uur plus enkele uren (betaald 10 uur plus enkele uren) hetgeen maken wat ik zojuist heb beschreven, mag er tekst worden "afgedrukt" die met de Dos-Editor is gemaakt, maar mag dit ook HTML tekst zijn (want dat werkt wel in een email), maar weet ik niét hoe je op een transparante wijze aan de "soorten" tekst komt die toevallig bij PKKO spelen. En dat weet de gebruiker natuurlijk ook niet, terwijl de trigger aan PKKOTV zal hangen.
En dan kan ik alleen nog maar bedenken dat Pascal aangeeft welke "soort" tekst hij afgedrukt wil hebben waar het om PKKOTV gaat, omdat alles wat dit dynamisch maakt misschien al te moeilijk is om te bedenken. Merk op dat mèt dat de gekozen tekst voor PKKOTV (wat mij betreft ook PKKOWY) als bijzonderheid wordt behandeld voor deze 2 funkties, de rest natuurlijk gewoon kan werken (in Dos-tekst of HTML waar aan de orde). En dit komt omdat ik wil dat zowel Dos-tekst als HTML wordt onderkend, ik ook graag wil dat "alles" kan (tenzij ondoenlijk), en ik ook wel wil dat Pascal kan doen wat hij vraagt.

Wat ik niet wil is dat we 180 uur bezig zijn voor iets wat 10 oplevert. Zo, dan weet iedereen dat ook weer.

Aangezien we bij de aanvang van dit maatwerk zelf nauwelijks meer begrijpen wat die hotemetoot van een PeterS heeft opgeschreven, dit alhier maar eens wat nader uitgewerkt.

Het belangrijkste is de formattering, c.q. dat het beter leesbaar wordt waar e.e.a. vandaan komt en/of wat er is gebeurd. N.b.: Dit betreft feitelijk de betreffende sleutelgegevens. Even een voorbeeldje aangehaald van Pascal :

Bezoekrapport toegevoegd - PKKO - BBB-BETONREKRAA     REKRAA2009010611:35

N.b.: Het eerste deel "Bezoekrapport toegevoegd" zal uit de betreffende Workflow zelf komen, en is dus (al) vrij instelbaar.

PKKO betreft de naam van de tabel waarin is toegevoegd, en de rest betreft de sleutel die is gehanteerd voor de toevoeging (in PKKO in dit geval).

De sleutel bestaat uit een willekeurig aantal velden, wat er in dit geval 3 zijn. Het systeem weet welke velden dit zijn (op het moment dat de Workflow deze mail gaat sturen), en dus kan dit tegen een andere tabel worden gehouden met wat er moet worden "afgedrukt" indien het veld aan de orde is. Bijvoorbeeld, het deel uit de sleutel "BBB-BETON" betreft het Bedrijfs-id van de administratie, en wat we nu willen is dat als dit Bedrijfs-id optreedt in de sleutel, we iets afdrukken als

Bedrijf : BBB-BETON

Om te bereiken wat we willen, moeten we eerst zelf herkennen wat de veldnamen zijn, voor in dit geval PKKO. Met wat ervaring komen we erachten dat dit XXSU_SID moet zijn en dus moeten we een koppeling kunnen aanbrengen tussen PKKO, XXSU_SID en "Bedrijf :".
Anders gezegd : als de email gaat over tabel PKKO, dan moet op het moment dat de inhoud van XXSU_SID wordt afgedrukt, eerst "Bedrijf :" worden afgedrukt, en daarna die inhoud.

Komen we bij het "REKRAA" deel, dan weet het systeem dat dit een Relatie-id betreft, maar alvorens we er iets mee kunnen, moeten we eerst zelf weer achterhalen welk veld dit in PKKO betreft. We komen dan op PKKO_KID . Gelijk aan eerder kunnen we nu "Relatie-id :"koppelen aan PKKO_KID in PKKO, opdat het kan worden afgedukt als

Relatie-id : REKRAA

Nu willen we niet het ID afdrukken, maar liever de naam. De naam (zelf te achterhalen) staat in tabel LORE en veld Naam en wat we nu kunnen zeggen is dat voort PKKO en PKKO_KID moet worden weergegeven de inhoud van LORE en Naam en waarbij het geheel is gekoppeld aan "Relatie :". Nu kunnen we afdrukken

Relatie : Reko Grondverzet- en Wegenbouwbedrijf

Op gelijke wijze kunnen we ook wel het Telefoonnummer van de Relatie afdrukken, waarbij in bovenstaande tekst "Naam" moeten worden vervangen door "Telefoon", en verder "Relatie :" door "Telefoon :" en we kunnen afdruken

Telefoon : 0572-351962

Het afdrukken van de inhoud van het Verslag is niet veel anders als het voorbeeld van Naam of Telefoon, en daarvoor moeten we naar tabel PKKX en veld Txtline, wat verder wel een speciale behandeling zal behoeven in de Profit programmatuur, maar wat ook gemakkelijk kan.

---

Als we alles relatief simpel houden en niet veel verder gaan dan voorgaand voorbeeld (c.q. wens van Pascal) dan is een definitie zoals uiteengezet in enkele minuten te maken;
Omdat dit feitelijk zo gebeurd is, zou ik ervoor willen pleiten om zo'n definitie aan de Workflow trigger te hangen. Dus, het setje zoals hierboven geschetst geldt dan voor het Toevoegen van een Kontakt en kan niet worden gebruikt voor het Toevoegen van een Relatie.
Merk op dat dit laatste ook juist is, omdat je bij een Relatie niet te maken kan hebben met PKKO, en als de definities "algemeen" zouden zijn c.q. over alle triggers heen werken, werkt de helft niet, of pas je iets aan wat daarna elders niet meer werkt.
E.e.a. definiëren per Trigger (of hoe het ook precies heet daar) is dus duidelijker, mooier (alles kan je anders maken), en eigenlijk niet redundant.

Hiermee kan dus veel meer worden gedaan dan wat Pascal eigenlijk vraagt, maar het geeft toch geen recht op "alles kan". Ik bedoel, als je bovenstaande doorneemt moet je er de hele database mee aankunnen, en waar dit in principe ook zo zal zijn, spelen technische aspekten vaak de rol van tegenhouders. Dus, wie weet kan het meer, wie weet kan het heel veel, en wie weet kan het alleen wat Pascal vraagt (maar het laatste is zeker niet ons doel).

Poeh ... Ik denk zelf dat dit best verklaarbaar is, maar omdat je je (inderdaad) mag afvragen wat hier nu het effekt van is (in eenzelfde context als dit hele topic), alvast een kleine bemoeiienis van mijn kant (om over na te denken zeg maar, want ik zal het allemaal helemaal fout kunnen hebben).

Als je Goederen Ontvangst doet, zal je dit best met terugwerkende kracht kunnen doen. Immers, het wàs nu eenmaal zo (dat aannemend). Dus, goederen komen binnen, geen zin, geen tijd, produkt is in het systeem toch niet nodig, en na een verfrissend dauwtrappen (morgen) gaan we er wel eens naar kijken.

Aldus, spulltjes waren vorige week al binnengekomen (fysiek, en dus realtiteit), en vrijdag boeken we ze pas in het systeem.
Hiervan kan je denk ik weinig anders zeggen dan dat het er eigenlijk vorige week al was, en zoiets zie je hier dus.
Maar ja, feitelijk doe je hier net zo iets "raars" als onderhavig aan dit onderwerp/topic, ook al is het meeste daarvan niet expliciet uitgesproken (maar hier intern hebben we het er uitgebreid over gehad).

Ik vermoed dat dit geen kwaad kan, maar hooguit heb je ook hier zaken die je later niet begrijpt. Denk maar eens aan FIFO afboeken, waarbij je achteraf heel makkelijk kan wijzen op een onjuist gehanteerde volgorde (immers, A die ouder is is niet gebruikt omdat het nog niet in het systeem stond, en in plaats daarvan is B gebruikt die er al wel was (maar ouder is), en als he achteraf kijkt zie je dat niet meer. Je kàn het dus wel zien (zie jouw schermprints), maar je kan er vergif op innemen dat wij dit als laatste redmiddel na een week zoeken pas zien.

Tja ...

1)
Helaas, dat kunnen wij niet hiervandaan (nou ja, niet na eenhoop gepruts).
Maar als het goed is, is de kleur van de desktop van die gebruiker wit. Is dat niet zo dan ?
En zo niet, staat er een plaatje (wallpaper) op de desktop ? (niet dat ik ooit heb gehoord dat dat uitmaakt)

Misschien dat je niet eerder antwoord kreeg omdat niemand er iets van begreep, maar zelf kan ik er nu wel iets mee (behalve je printen, LOSU enz. "probleem" wat je hier gewoon niet bij moet betrekken (en verder beter maar opvolgt zoals geadviseerd (zo ongeveer eens per jaar trouwens))).

De Startdatum/Tijd die je opgeeft bij het Submitten van de job betreft de Datum/Tijd dat de job zal starten. Tenminste, als alles werkt naar behoren.
De Kalender zorgt er slechts voor dat wanneer de job klaar is, er volgens de Kalender weer een nieuwe job wordt klaargezet. Dat gebeurt dus onmiddellijk na gereedkomen van de eerdere job, en ziet er verder net zo uit als dat je zelf de job hebt gesubmit met een Startdatum/Tijd die later is dan "nu".

Overigens zou het nog kunnen dat je het draaien van de eerste job hebt gemist, en denkt dat je naar de eerste kijkt (die fout gaat) terwijl het intussen de tweede is (door de Kalender geïnitieerd). Dit (dat je het niet ziet) komt dan omdat je niets print (anders zag je het wel aan het printje op de printer). Als dat zo is moet dat natuurlijk wel in de gedraaide jobs zijn terug te vinden.

Hoe - en of het in jouw situatie goed werkt met de Kalenders zelf is een ander verhaal (geen verstand van).

Hallo Cathelijn,

1)
De kleur in de kop wordt overgenomen van de desktop;
Ik kan me voorstellen dat dit hier en daar niet lekker uitpakt. Kwestie van de kleur van de desktop aanpassen dus (helaas is het niet anders).

2)
Wat is een "attentieveld" ? (vast iets wat jullie intern zo noemen).
Hoe dan ook, hier kijken we wel even naar via het "modem".

3)
Ja, dat kan ik me voorstellen. Helaas is dit een puntje wat eeuwig is blijven liggen, en via de F1 schermen kan dit (nog ??) niet.
Zelf doe ik stiekem even F5, daar kan het wel (in het algemeen dan, en waar Wijzigen aan de orde is uiteraard).

Peter

Zodra je weet hoe dat moet kwa HTML, net zoals mijn bold voorbeeld (<b>). Let wel, mits er voldoende ruimte zou zijn (en dat zal wel niet).
Voor de rest heeft BKienhuis gelijk naar mijn idee.

Dit is mijn voorbeeld, en ik zou niet weten waarom dit niet werkt. Geprobeerd heb ik het echter ook niet.
... en een voorbeeld van wat jij wilt heb ik nog niet gezien ...

Houd wel in de gaten dat je CSS hier dwars doorheen speelt. Die doet dus ook iets voor die titels, en wie weet maakt dat hetgeen wat je wilt ongedaan.

Als je het niet kan uitleggen met een voorbeeld, blijf ik het kennelijk niet begrijpen.
N.b.: Dat "afbreken" ging dit dacht ik even niet over. Of toch wel ??

Voor dat ik het ga begrijpen moet je misschien een voorbeeld geven van wat je erin zou willen zetten - en wat kennelijk nu niet kan.
Ik heb beide door jou gegeven paden gevolgd, en ik vat 'm nog niet.

Misschien snap ik niet wat je bedoelt, maar je kan toch gewoon HTML tekst in zo'n titel zetten (mits voldoende ruimte) ?

<b>5. Brandbestrijdingsmaatregelen</b>