CRM Toevoegen Bezoekrapport: extra veld Kontaktpersoon en datum wijzigbaar?

[pascal]

Ok, het is niet anders... laat alleen deze aanpassing maar prefereren boven evt andere aanpassingen van ons. Hoe sneller het klaar is hoe liever

[Peter Stordiau]

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).

[Wouter Rijnbende]

En hoe pas het meenemen van het verslag daar dan verder in?

De hele inhoud van het Verslag meenemen kost niets meer. De rest blijft dus gelden.

Bedoel je met "kost niets meer" dat dit vanzelf ook werkt, of dat pascal er niets extra's voor hoeft te betalen?
Zo het eerste, hoe? Het (html) verslag staat niet in één veld.

Daarnaast: Pascal wil dit voor "bezoekverslagen" en niet voor alle soorten verslagen (Akties) die kunnen worden toegevoegd.
Bij een Funktietrigger "bezoekverslag" opnemen klopt dus feitelijk niet; het is eerder een "Kontaktverslag" waarvan een "bezoekverslag" maar één soort is.

[Peter Stordiau]

Nog even oppassen : Als ik zeg "alles", dan bedoel ik alles met gelijkwaardige data. Dus, bij de "enkele uren" ging ik er al vanuit dat je één soort Verslag gebruikt, en dat dit geen Word betreft (dit, terwijl er in theorie 4 technische soorten bestaan).
Ook ging ik er niet vanuit dat bij zo'n Verslag Bijlagen kunnen zitten, die je wilt mee-emailen (had ik gewoon niet aan gedacht (jij vast ook niet) en daar werd ik daarstraks door e.o.a. nerd op gewezen.

Al met al moet ik met dit soort dingen erg oppassen wat ik zeg

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

Wat wel weer kan is dat op de e.o.a. manier een soort standaard inhoud wordt gepresenteerd die je mag vergelijken met wat de Mailing Selekties ophoesten. Maar dan doe ik er eerst minimaal 12 uur bij

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.

[Wouter Rijnbende]

(tenzij ondoenlijk)

Ik verwacht niet dat het erg eenvoudig is. Omdat je in algemene koding zit, maar vnl. omdat je in die algemene koding in het deel na de F1 zit.  Hoop dat ik daarin geen gelijk krijg.

Het laatste waar ik op zit te wachten is dat het een 'Variabel Layout' mechanisme gaat worden met honderden variabelen die we beschikbaar moeten stellen. Dat gaat zeker niet werken na de F1.

Ik zal wel eens kijken of ik er wat van kan bakken.

[Wouter Rijnbende]

Mijn collega's zitten te springen om deze aanpassing in gebruik te nemen.
Enig inzicht in wanneer het klaar is? Dan kan ik gelijk de benodigde update gaan inplannen hier.

Klaar. Zie http://ha1.heartprofit.nl/profit/index.php?topic=21657.0