Nee, die meldingen zeggen niet echt iets (over traagheid).

Printen *en* mailen mag ook, maar dan kan ik nu even niet overzien wat daarbij komt kijken. Immers, je hebt dan of twee layouts nodig (waarbij wij er maar voor moeten zorgen dat beiden worden aangesproken), of je kan een layout hanteren die ook "printable" is. Het volgende wat ik dan weer niet kan overzien op dit moment is wat jij zoals a. kan en b. wilt uithalen om iets wat je emailt ook meteen printable te hebben. En, een normale Pakbon Layout zoals je die nu hanteert (of zou hanteren als je die gebruikt) is weinig "emaill-able". Ja, als attachment en .PRN maar dan moet je nog steeds een andere driver hebben. Met andere woorden :

Voordat je jezelf in allerlei bochten moet wringen omdat je hierop een aantal (??) uren wilde besparen, kan ik maar beter zeggen dat er voor iedere situatie een aparte layout moet worden ondersteund, en dan weet ik nòg niet hoe e.e.a. uitpakt als je voor het emailen bijvoorbeeld een bijlage met PDF wil maken;
Je weet wel denk ik, al die elementen zijn er, maar in kombinatie is het gewoon niet te overzien. Zo kan je ook wel een HTML layout van je email maken die op zich printable zal zijn. Maar of je ooit een layout weet te maken die op print ook doet wat je wilt is weer heel iets anders (denk met name aan de blad overgangen en totalen op een 1e blad en weet ik veel).

Advies : Vergeet voor nu die "beiden" maar houd in je achterhoofd dat je dit wel degelijk wilt, maar dat het misschien 8 uur kost om dat voor elkaar te krijgen terwijl wij pas weten hoe of wat als het werk is gedaan.
En misschien doe ik wel te moeilijk. Maar het is gewoon niet te overzien. Sorry ...

Jep, dat kan.


Lijkt me wel. Wat ik even niet weet in hoeverre dit precies zal werken (en of het op het juiste moment is) zoals jullie dit willen, maar met 1-2 uurtjes zal dat zijn goed te krijgen met als ergste geval weer een Bedrijfsparameter (4 uur) omdat het iets wat bestaat tegenwerkt (maar daar ga ik vooralsnog niet vanuit). Waar ik wel vanuit ga is dat je dit ophangt aan de funktionaliteit van mijn voorgaande post en dat dus alleen diegenen een email krijgen waarvan dit a. is aangegeven (Afleveradres), b. dit is toegstaan kwa emailen voor de Kontaktpersoon in kwestie (Kontaktpersonen) en c. kan ontstaan uit een Pakbon Printen J/N ? vraag (zo die nog komt, zie eerdere post) en dus weer van de persoon bekend moet zijn dat hij emails mag ontvangen in deze.

Niet dat ik het zelf kan volgen, maar ik hoop dat het duidelijk is.

Ja, da's duidelijk. Maar wat ik bedoelde is dat je dat zeker weten te duur vindt worden, dat dus vast niet de oplossing wordt, maar je intussen alleen de laatste persoon van wijzigen weet ... en wat moet je daar mee.

Dus, vind je dat dan toch nuttig ? Dan 0,75 uur (bij het weergeven zie je dan wanneer en door wie de Keuringseis het laatst is gewijzigd.

En even opletten svp : ik heb het idee dat dit bij jullie niet één entiteit en RA funktie zal betreffen. Kan je dit zelf even onderzoeken ? Ik bedoel, volgens mij hebben jullie op meerdere plaatsen die Keuringseisen aan de orde, soms ook nog idirekt (of impliciet). Charges bijvoorbeeld ?

Dat zou dan Afleveradres moeten worden denk ik.
Doe dit stukje alleen eens voor 2 uur.


Ik vraag me af of je dat niet ergens kan uitzetten. Maar goed, dat daargelaten :
Aannemend dat deze vraag altijd komt, zal het dus zo moeten worden dat indien bij een Afleveradres "Ja" staat, de vraag niet meer komt en de Pakbon automatisch wordt geprint, toch ?
Maar als er Nee (= default) staat bij het Afleveradres, zal de vraag blijven komen.

Als je het bovenstaande anders wilt c.q. in beide gevallen de vraag niet krijgt (en dus of automatisch de Pakbon wordt gesprint, of automatisch niets gebeurt) dan zal er een Bedrijfsparameter bij moeeten (4 uur). Daar ga ik niet van uit.

Volgens mij ben je er dan niet als je alleen van de laatste wijziging het Userid hebt, toch ?
(wat theoretisch bij de Recepten wel voor alle wijzigingen wordt bijgehouden, aannemend dat je een gewijzigd Recept historisch maakt).

1,5 uur.

Heart Intern : Hierbij is dan rekening gehouden met -indien de Artikelgroep is ingevuld- dat de Artikelgroep "leidend" wordt. Dus, niet per Artikel (0 t/m zz) kijken of het in die Artikelgroep voorkomt, maar van de in de Artikelgroep gekoppelde Artikelen kijken of ze in the opgegeven Artikelreeks vallen. Maar eigenlijk, bij het eerste Artikel uit de opgegeven reeks beginnen en bij het laatste Artikel einidigen bij het kijken in de opgegeven Artikelgroep.
Beetje krom om te maken "rond" het bestaande programma ...

Mag gewoon een normaal tekstveld zijn toch ? Of moet je nog iets speciaals met die datum kunnen doen ?

Niet helemaal denk ik. Naar mijn mening zou niemand fakturen de deur uit moeten doen die niet vooraf zijn bekeken. Dus, ergens onderliggend moét dit al een probleem zijn. Ofwel, als dat eenmaal herkenbaar is, heb je de rest meteen ook opgelost.
Neemt niet weg dat het misschien nog gemakkelijker is om de grootste berg ellende (die Johan's werkwijze natuurlijk uitlokt) voor te zijn. Maar dat is naar mijn mening dus nog niet voldoende ...

Mocht je hier n.a.v. Wouter's ideeën op verder willen gaan, open er dan een nieuw topic voor. Ok ?

Dus ... Misschien had Wouter het zo gezien dat jij met "Testrun" hetgeen bedoelt wat ervoor is gemaakt, en je daar dus al wel uitbent. Het originele topic zal ook ergens zijn, maar dit is een afgeleide :
Re: Wie kan mij helpen (PDF verhaal)

Dus eerst maar de vraag aan Johan of hij wetenschap heeft van deze ongeveer letterlijke "testrun", welke er in elk geval voor zorgt dat je e.e.a. op voorhand nog kan bekijken en aanpassen.


Dat doet die testrun dus wel, in die zin dat je domweg alle letterlijke emails te zien krijgt die echter nog niet zijn verstuurd. Dus, weet je dat dit bestaat ?
Of dit past binnen jouw PostNL gebeuren ... zal wel niet 100% ...

Ik wilde toch even laten weten dat ik het "belachelijk" vind dat je überhaubt met zo'n tekst komt. Ik zou bijna willen zeggen : waar bemoei je je mee ? Nou ja, valt wel mee misschien, als je maar niet eerst de eigenlijke vraag had overgeslagen ...
Ik bedoel, hier gaat het toch totaal niet om ?

Ik moet zelf even naar het antwoord zoeken ... of het bevalt zien we dan wel weer.

Meer geheugen waar ? In je PC bedoel je ? Ja, klopt. Of je dat nodig hebt is wat anders.
In de server ? klopt ook, alleen dat heeft niets met Profit te maken. En zo onderdaad "de server", welke dan ?

Kijk eerst maar eens of het Notepad verhaal een beetje wil. Anders zijn we onnodig aan het speculeren. Toch ?

Ik ben het op zich wel met je eens, maar ik zou dit toch niet onderschatten. "Wij" zijn dit domweg niet gewend, maar een jongere generatie echt wel. Hoe lang de tekst is maakt nauwelijks uit. Maar, juist in die hoek -de wijze van typen- gaat het denk ik fout. Dus, ik kan nu behoorlijk met m'n ogen dicht typen met een meer waardeloze verbinding (het komt wel een keer door, en als ik maar niet op het scherm kijk lukt het wel). Maar nu gebruiken we bijvoorbeeld T9 om die lappen tekst voor elkaar te krijgen op je mobiel. Nou ... ik zou al niet eens weten of dàt via RDC wel werkt. Maar als het werkt, dan vraag ik me nog af of het ook goed uitwerkt. En als het al goed uitwerkt, dan weet ik weer niet of je ooit kan lezen wat je hebt geschreven als dat ding enkele "characters" dus woorden (!) achterloopt. Snap je ?

En dan ga ik er gemakshalve maar even vanuit dat die verkoop-boys van die jongere generatie zijn. Al weer een onjuiste aanname - op z'n minst in veel gevallen.

Het kan wel werken, maar dan onder kondities, en die moeten we denk ik nog bepalen. Bijvoorbeeld, een iPad met 3G ... zal wel werken (maar dan denk ik dat e.o.a. Galaxy Tab beter is). Maar, "werkt" dat zo ? ik denk het weer niet want nou moeten we precies die dingen gaan aanschaffen; dat willen we al niet omdat we "ze" al hebben, maar dan in net andere vorm.

Tja ...