Zoho ... jij hebt wel erg veel tijd nodig om weer bij te komen !
Veel plezier gewenst vanuit Kjippedarp (wellicht iets verkeerd gespeld).

Ook al was het voorheen onjuist, iedereen moet nu toch even opletten of het resultaat voor Orderbevestiging/Faktuur niet anders is !
Ik kan me namelijk niet voorstellen dat dit niet wordt gebruikt her en der ...

Sterker nog, het mag gewoon in een email body nu, volgens mij.
Wel knap dat ze jou gebeld hebben op vrijdag, dezelfde dag dat het op het nieuws was. Of zou die ambenaar gewoon naar het nieuws hebben geluisterd, en onmiddellijk jou hebben gebeld ?
Of zou jij zelf voor het nieuws hebben gezorgd misschien ? hahaha


Oh joh, daar weet ik niets van. Wie hier heeft dat nou weer verzuimd te melden ??

Maar goed, als jij dat zegt geloof ik dat (lees : ga ik verder niet uitzoeken) en dan gaan we dat doen.

Voor de duidelijkheid, wat jij dus wilt is alleen printen naar de PDF printer. Let wel, printen = printen naar de printer.
En voordat je allemaal opties begint te bedenken die zich in de kombinatie bevinden (zoals printen naar het scherm, emailen) :
a. die heb je vast niet uitgezocht
b. die kosten extra geld.

Maar van mij mag alles.
Houd het op het printen naar de printer, inklusief dat vinkje bij de Debiteur op 12 uur inklusief een Bedrijfsparameter die aangeeft welke PDF Printer je gebruikt (noodzakelijk om de juiste parameter sturing te onderkennen, en wat hard zal worden ingebouwd ... en eventueel met een extra Bedrijfsparameter die je van ons krijgt voor de lokatie van de printer (software).

De button zo laten werken nadat het voorgaande is geïmplemeneerd krijg je gratis (omdat je bij het voorgaande vast wel voor anderen aan het betalen bent, en ik het lovenswaardig vind dat er eindelijk eens iemand is die dit doorzet).
De eerstvolgende met een andere printer mag wat mij betreft nog extra veel voor die button betalen ook. Hihi.

N.b.: Als de software in demo versie niet alles kan doen wat wel nodig is mogen wij vast wel tijdelijk een kopietje van jou gebruiken.
Oh ja, dat kost 6,75 aan verzendkosten en het pakketje kost 15 euri zei je. Nou laat dat ook maar dan. Dan kopen wij het wel.


Niet vergeten Marco : als het toch niet blijkt te werken ben je het geld kwijt, dan wel kan het je extra kosten omdat we iets voor elkaar moeten zien te boxen wat slecht kan (geen idee natuurlijk, maar zo gaat dat met automatiseren). Vergeet niet : een converter werkt ALTIJD, maar zo wil je het even niet.
Gewoon een eerlijke waarschuwing waarschuwing waarschuwing.
Plus een dislaimer : het maakt me niet eens uit met wie je dat van Heart hebt uitgezocht. Ik wil dus niet dat je daaraan rechten ontleent.

Nou, jij bent lekker zeg. Had die module dan aangeschaft voordat de mensen die nieuwe Relaties aanmaakten ...

Eigenlijk moet ik Nee zeggen, domweg omdat het niet is te overzien wat er dan gebeurt. Ook technisch is dat niet te overzien, alhoewel ik wel zeker weet dat er overal in deze relatief complexe programmatuur aanpassingen zullen moeten komen. Immers, bij jouw wens kan alles al bestaan, en niets gaat daar van uit. De enige kontrole die erin zit is die op de hoofdentiteit (= LORE) wat natuurlijk in de normale situatie ook voldoende is.

Al typend weet ik eigenlijk het antwoord al wel : dit gaat fout.
De programmatuur is immers niet intelligent, in die zin dat ze weet waar meer records mogen voorkomen, en waar slechts één. Bijvoorbeeld, aan de ene kant heb je bijvoorbeeld LORD waar duidelijk maar 1 record mag bestaan (en dan mag je ook nog kiezen of de oude of nieuwe overschreven moet worden (antwoord hoef ik trouwens niet), en iets als Verkooporders wat er duidelijk meerdere mogen zijn. Nu kan ik nog wel overzien dat een "sleutel" hiervoor bepalend is (de sleutel van de Verkooporder zal nooit al bestaan, terwijl de sleutel van LORD wel al zal bestaan, en dus "niets doen" (of altijd overschijven, maar in elk geval niet nogmaals opnemen), maar ik denk dat er fuzzy situaties zijn waar het eigenlijk twee kanten op kan zonder dat dit technisch zichtbaar is. En in dat geval gaat het vanzelf fout.
Merk nog op dat je rariteiten kan krijgen met als voorbeeld de Kontaktpersonen. Ook al betreft dat niet de Relatie zelf, ook hier kan je bedenken dat de nieuwe Kontaktpersoon de oude moet vervangen of andersom, terwijl je nu óók nog de situatie hebt dat twee dezelfde mensen een ander ID hebben, en er dus twee keer in komen te staan. Geen ramp in dit geval, maar dat is ... dit geval.
In een gevalletje Afleveradressen komen we er zonder specifieke intelligentie al niet meer uit, omdat je in beide gevallen zal zijn begonnen met met de nummering vanaf 1, maar uiteraard 1, 2, 3 enz. niet voor dezelfde adressen zullen staan. In zo'n geval de set van de ene maar achter de andere plaatsen met additionele nummers ?

Na voor mezelf zo'n geval gezien te hebben, moet ik helaas afhaken. Immers, dit betreft een oplossing die moet zegen IF AfleverAdres en ook al kan dat, er zijn er zo nog vast honderden, en die ken je pas als het is foutgegaan. En dat weet je in 90% van de gevallen als het te laat is (namelijk, als je niet meer terugwilt naar de backup).

Nee dus.

Ik denk hier niets over zolang je niet (hebt uitgezocht en) aangeeft welke PDF printer moet worden gebruikt.

Niet te makkelijk doen, want als je er een neemt die technisch niet blijkt te voldoen voor ons, kost het je wel geld (van onze werkzaamheden in elk geval) maar heb je helemaal niets.

Ik zal deze tekst maar eens bewaren, dan kan het het over 7 weken (dat lijkt me ongeveer de frequentie) er zo weer in pasten. Hahaha

Op deze doelde *ik* in elk geval, en hiermee toon je wat mij betreft aan dat a. je dit weet/begrijpt en b. je kennelijk ook niets raars wilt (en uiteraard zit ik zo in elkaar dat ik het rare wat je eerst wilde (andere topic) kombineer met wat je hier wilt).

Ok, niets raars kennelijk, excuses !

Maar dan zou het toch zo moeten zijn dat de Opdrachtbevestiging het fout doet ...
Daar hadden we nog niet aan gedacht ... gewoon FOUT. En ik kan ook al wel raden waarom ... De klant waarvoor veel van dit werk is gemaakt (en waardoor het zo complex is geworden) gebruikt de print van de Verkooporder als orderbevestiging. Dus dié doet het wel goed ...

Ditto.

Iets met e.o.a. Bedrijfsparameter toch ? (eerste letter o.i.d.)

En anders maar niet, dan maak je er dus een indikatortje bij.

Ten eerste ... vergeet het dat we dit gaan aanpassen. Je zult het nooit geloven, maar het is te ingewikkeld.

Ten tweede, het "meer" wat jij wilt t.o.v. de rest tot heden, is dat je je eigen gegevens ook wilt noemen. Dat mag je natuurlijk willen, maar wij hebben "bepaald" dat dat niet nodig is. De klant ziet gewoon altijd gegevens die hij herkent. Ofwel die van hemzelf, dan wel die van jou omdat hij geen gegevens van hemzelf heeft.

Pas op, want dit vergaal zal zijn oorsprong hebben in die andere post met die 5 Verschijningen waarvan één "bulk", en wat je daar impliceert ruikt wat mij betreft al naar onraad.

Overigens vind ik hiermee voldoende gezegd te hebben, en deze keer gaan we eens niet 35 posts voltypen met iets waar niets uit *kan* komen.

Neenee, inderdaad. Maar de "scan userids" zijn ook al speciaal (aangegeven). Dus dat zou dan net zo kunnen naar mijn idee.

Zo werkt het weer eens niet ...

Er zijn variabelen die expliciet (bijvoorbeeld) de Artikel-Kliënt Omschrijving bevatten (en die zal jij aan het gebruiken zijn) en er zijn variabelen die "de Omschrijving" afdrukken. Welke dat zijn weet ik helaas niet.

Het gaat er in elk geval om dat die hiërarchie door het systeem dient te worden bepaald, juist omdat je er anders niet uit komt.

Richard, welke variabele heet Johan in dit geval nodig ? (met een gerede kans dat Richard dat ook niet weet trouwens)

Hahaha, tja Demis, kwestie van a. de vraag net niet voldoende duidelijk stellen en b. ikke even niet naar het forum kijken, en je krijgt zo maar een antwoord wat je niet wilt.

Demis had telefonisch al even voorgelegd wat hij wilde, en dat komt er wat mij betreft op neer dat de orderpikkers (die *geen* scanner hebben in dit geval !) als User in het systeem bekend moeten zijn, en die op het betreffende TS als keuze (zoals bijv. Emballage) worden gepresenteerd, en waarbij een verantwoordelijke (die het TS bedient, dat doen die pikkers niet) aangeeft wie de pikker was voor de betreffende order.

Ik stel dan voor dat dit een Geberuiker (User) dient te zijn (ook al logt deze nooit in) omdat het dan precies overeenkomt met een orderpikker die scant, en die eveneens een Gebruiker is, en waarvan onderwater dus bekend is wat deze wanneer (hoe lang) doet. Het moet daarmee dus overeenkomen.

Nu mag Wouter inderdaad zeggen hoe duur dat is (zonder verdere rapportages).

Zal wel kunnen. Maar zou je eerst even "het" scenario willen schetsen ? of beter : "alle" scenario's die jij voor je ziet c.q. die kennelijk optreden waar je dit nodig hebt ?

Ik vraag dit omdat het natuurlijk ingepast moet worden in hoe je zodirekt werkt. En wie weet kan het dan al gewoon.

Als het vG betreft (of af en toe) mag je dat ook zeggen bij de betreffende scenario's (had je misschien niet aan gedacht, maar waarom niet ?).

Als dat helpt ...

Wij zullen er intussen naar kijken.
Merk op dat er nog meer verschillen zijn bij aanroep via de Userbutton (zo snel even te zien dan).

Ik hoop wel dat je dit waardeert; Is speciaal voor jou gemaakt hoor !