N.b.: Ik heb dit topic toch maar naar hier verplaatst.

Voor ons is altijd van belang dat je ook zaken op een gemakkelijke manier kunt oversturen. Kan dat hiermee ook ?

Nee hoor, ik denk dat je het heeeeel belangrijk vindt ...

Het waarom ontgaat me echter.

Jij hebt echt niets beters te doen heh ? 

Voordat alles nogmaals is aangepast ja, dus dat zegt me niets meer.


Begrijp er niets van. Hierop kan ik alleen maar reageren met : "dan moet je de shift toets gebruiken". Sorry ... 

Ach als het interessant is. En het blijft toch wel over het onderwerp gaan ... geloof ik. 

Misschien toch even voor de goede orde : al dat leuke gebeuren zoals te zien op de schermkopietjes een stukje terug, is *niet* waarover we het hebben, bij de 4-5 dagen hoor. Ik heb ermee willen aangeven dat het gevraagde in dit topic, eigenlijk al bestaat, maar niet is te managen. Dus als jullie 65 door 40 beginnen te delen en zo (of wat je ook precies doet), dan gaat het alleen maar over "Gegevens geallokeerd door wie", en zou het kunnen dat daarmee vanzelf dezelfde funktionaliteit als van die schermkopieën weer onstaat". Maar als dat zo is, is het toeval. Hooguit wordt het uitgelokt, omdat je immers gegevens uit een andere PC moet zien te peuren, en wat je met COM (DCOM trouwens) ook kunt, maar 1000 keer ingewikkelerder is.

Gebruikersvereniging : Die komt er vast nooit meer. Is al veel te veel aan gedaan, en veel te veel mensen hebben beloofd het te regelen. Pascal, volgens mij "jullie" ook. Overigens behoort een gebruikersvereniging niet echt te worden bestierd door het lijdend voorwerp (Heart). Maar wat dat betreft kun je je beter afvragen wat het doel is wat je wilt bereiken. Wel, da's duidelijk : funktionaliteit kreëren die er anders nooit zou komen; ofwel omdat 1 klant het te duur vindt, dan wel wij er nooit aan toekomen.


Het is een heel klein beetje appels en peren (als je het zo mag zeggen in dit geval), omdat het ook nog kan dat we "het" domweg niet doen. Dus inderdaad, we krijgen er niet voor betaald, maar het gebeurt domweg ook niet. Die "gevraagde gegevens" is wel een mooi voorbeeld, want vanaf het begin (1987) kan dat al niet, terwijl ik zelf dat toch echt wel gewend was (mainframes en zo). Typisch iets wat erbij hoort, maar ook typisch iets wat gewoonweg niet kan in de "normale" PC-netwerk omgeving. Overigens worden deze problemen met een databaseserver nog veel groter (beter : grover), en zie je dat je (wij) dingen wilt die niet horen in zo'm amateuristische PC omgeving ... Jaja.

Wij werken met een research budget wat je mag stellen op zo'n 80% (min of meer noodgedwongen), juist omdàt we nu eenmaal dingen doen die eigenlijk niet horen. Effekt ? snelheid bijvoorbeeld. Moraal : eens houdt het op voor het geld wat je ervoor hebt. Ik hoop dat ik het zo mag zeggen.

Het zou dan ook wel degelijk zo zijn dat als iedereen relatief gering zou bijdragen aan dit soort ontwikkelingen, het daadwerkelijk zou worden ontwikkeld, maar dan met mensen die ervoor worden aangenomen of ingehuurd. Maar schrik niet, want als er hier 10 van dat soort mensen extra zitten, zijn ze nog allemaal enorm druk. Ofwel, dat COM verhaal is maar 1 voorbeeldje, waarvan we er nog enorm veel meer hebben. Als je het echt leuk wilt doen, moet je dus 65 delen door 10 jaarsalarissen, en dan kijken of je het nog leuk *vindt*. Prioriteiten stellen heeft geen zin, want ik denk dat alles wat wij hier bedenken of al hebben bedacht leuk wordt gevonden, en dat ene dingetje uitvoeren zet dan ook geen zoden aan de dijk.

Nou ja, bedenk maar dat wij op hoog niveau (lees : systeemniveau) *alles* kunnen maken wat meteen z'n invloed heeft op het hele systeem. Het is echter altijd complex, kost altijd relatief veel tijd, en kan nooit tussendoor. Een voor jullie meetbaar voorbeeld in deze zijn de Mailingselekties. Daar is gewoon voor betaald, zij het voor een fraktie van de totale kosten (tijd). Dit bevindt zich feitelijk op systeemniveau, en het kost werkelijk een jaar ademhalen en heel goed doordenken hoe je zoiets opzet. Dat, nadat we al meer dan een jaar erover hadden gedacht voordat iemand erom vroeg. Had niemand het gevraagd, dan was het er niet gekomen. Nu is er een dag of 5 aan betaald, bij een dag of 20 werk, en dat is exklusief al het voorafgaande denkwerk.

Demis hoef ik niets te vertellen over z'n Grafische Magazijnen ... 12 uur, tegen, ehh, meer dan 400 uur werk. Al had ik 40 uur gezegd, dan a. had Demis het niet meer genomen, en b. had het geen bal uitgemaakt voor ons (ok ok 28 uur).

Als er zo'n pot zou zijn, zou het wel degelijk uitmaken, maar met de natuurlijke verplichting dat er hier ook mensen (beschikbaar) zijn die alleen maar a. uit die pot werken, b. aan die pot werken.
Overigens zou dat alleen maar werken als iedereen, zeg maar, verplicht meedoet, en waarbij er ook alleen maar zaken worden ontwikkeld die ergens voor iedereen ook nut hebben. "Gegevens geallokeerd" is zo'n voorbeeld. Dat de één het dan wat minder nuttig zal vinden dan de ander, moet zijn verantwoording vinden in het relatief geringe bedrag wat je eraan betaalt. Voorbeeld : iets kost 65.000 euri om te ontwikkelen en iemand die daaraan 1000 heeft bijgedragen moet niet al te moeilijk doen als 'ie het niet helemaal leuk vindt. MAAR :

Het probleem ontstaat als die iemand liever iets anders had gehad, wat dan weer niet aan de beurt komt. En vandaar dus dat ik meteen grof praat, en het gerust over 10 mensen heb. Verhoudingsgewijs praat je dan over 10.000 bij te dragen euri, en de lol is ... voor dat bedrag wil je nog steeds die "Gegevens geallokeerd" wel goed behandeld hebben. *Ik* zou het er in elk geval wel voor over hebben, want ook hier moet zeer geregeld iedereen eruit. Maar niet vergeten : voor die 10.000 krijg je dan ook alle andere 9 punten die iedereen zo door elkaar (en tegelijk) wenst.

Mochten er nog mensen zijn die dit wel een lollig idee vinden : dit zal *nooit* kunnen gaan over de gangbare funktionaliteiten. Dat blijft sowieso zoals het is.

Peter
 

Vonden we een beetje raar in Windows. Zit er vanaf het begin (Windows) dus niet in.

Shift-Wat ?
Bovendien : wat doet jou denken dat dit met het topic te maken heeft ? 

Dit krijg je m.i. niet makkelijk goed. Althans, niet met "funktionaiteit".

Opmerking tussendoor : laat ik nou denken dat jullie het rapen voor dat soort produkten en leveringen altijd al uitstellen totdat je in één keer aan de gang kunt. Niet dus ...

Eigenlijk (gevaarlijk) denk ik te kunnen stellen dat je in deze zo anders bent gaan werken (van zeg maar, voordat je de melk leverde) dat wij hier niet meer kunnen raden hoe je werkt, hoe alles op elkaar ingrijpt, en dùs hoe we kunnen helpen met oplossingen in deze.

Voorbeeldje : als jij doet zoals je suggereert, ben je na iedere (soort !) aanlevering voor alle klanten aan het rapen. Tot 10 keer toe voor dezelfde klant, zeg maar.

Ik hoor je reaktie al : het gaat alleen om de melk c.q. wat THT produkten. Mag. Maar daar gaat het niet om. Het gaat om de onjuiste principes.

Als we letterlijk zouden doen waar je naar vraagt, puilt om te beginnen je voorraad uit ook de nieuwe behuizing, immers, die ga je ermee kleiner maken. En ja, ik weet het, met 20 uitzonderingsregels en prioriteiten komt het dan toch wel weer goed. Maar liever niet, want de basis stinkt.

Maar hij geldt ook andersom :
Als jij het rapen wilt uitstellen totdat alles er is, kom je 10 keer capaciteit tekort voor die paar uur die je nog hebt als eindelijk alles er is.

Hier zou ik het graag bij willen laten voor dit medium, want dat acht ik niet geschikt om zoiets als dit uit te werken. Werkt ook niet echt over de telefoon, omdat het vraagt om een grote tafel met veel betrokkenen, een whiteboard + een stapel paddo's.

Probeer s.v.p. als moraal mee te krijgen dat alles wat ik bedoel maar weinig met die THT te maken heeft, maar alles met wanneer je raaplijsten print en dus als "ga maar rapen" beschouwt.
Om een voorzetje te geven van de zeer andere richtingen waarin je kunt denken : het is misschien wel heel verfrissend om (zo ongeveer) rechtstreeks te rapen uit de aanleverende vrachtwagen. Dit komt natuurlijk best neer op wat je zo ongeveer al doet, maar de formele procedure zal anders zijn, en daarmee ook de (mogelijkheden voor de) ondersteunende funktionaliteit.

Als je e.e.a. even wilt uitstellen omdat je het wat drastisch vindt, zeg dan tegen de klant dat het in heel veel supermarkten ook zo werkt.

En als je er dan toch wakker van ligt (terecht trouwens), bedenk dàn dat het ook nog kan gebeuren dat een klant bij een latere levering een oudere THT kan krijgen. Niet omdat je niet netjes fysiek FIFO zou werken, maar omdat jouw leverancier het ook niet altijd op orde heeft.
Het laatste is wellicht te moeilijk doen (domweg omdat het onvoldoende vaak fout gaat in deze), maar denk maar aan je eigen produktie. Klant wil nog steeds alles van dezelfde THT, jij regelt die 100 KG netjes uit een nieuwere partij omdat de oude nu eenmaal nog slechts 10 Kg omvat, en de volgende dag wil die klant 5 Kg, en die 10 Kg staat er nog steeds (mer 14 dagen THT !! -> niets aan de hand dus, en daarmee lok je ook uit dat dit gebeurt).

Wie A zegt moet ook B zeggen.
Wie geen B wil/kan zeggen, kan beter helemaal niets zeggen.

 

Zowel de omschrijving hierboven, als de funktionaliteit zelf waar het hier over gaat zijn niet helemaal eenduidig (en het eerste volgt vanzelf uit het tweede);

Het betreft hier funktionaliteit die *eigenlijk* Subcharges genereert, en tegelijk daarvoor ook Etiketten afdrukt. Maar, funktioneel -d.w.z. voor de betreffende operator- betreft het hier "Etiketten afdrukken" (beter nog : "genereren").

Ietwat moeilijk uit te leggen, maar jij wilt die Etiketten gewoon nogmaals kunnen printen, en daaraan is niets veranderd.

Wat wel is veranderd, is dat het hergenereren van (Sub)Charges, alleen nog mogelijk is als er niet al output is opgeboekt, wat domweg om de reden is dat de Output in betreffende Charge al is opgeboekt, en je dan dus niet een onjuist Etiket erop moet kunnen plakken (lees : hergenereren Charges zou wèl de Chargerecords opnieuw aanmaken, maar zal geen Etiketten op zich reeds elders bevindende pallets kunnen plakken).

Uiteindelijk is de aanpassing ervoor bedoeld om een operator niet de fout te laten maken dat hij/zij Charges hergenereert, terwijl er alleen maar een Etiketje moet worden bijgemaakt (ehh, er een extra Subcharge is ontstaan, waar ook een Etiket bij moet).

 

Gebruikert ...

Als het kan werken zoals ik vermoed dat het kan werken (en dat is via Dot-Net), misschien 2 dagen. Daarna(ast) echter, moet er meteen een formele upgrade procedure komen vanuit deze ontwikkelomgeving, krijg je te maken met DLL's of OCXen of gewoon EXEs, het registreren ervan in de eerste twee gevallen en nog wel wat meer gehobby wat nu ook al wel gebeurt maar nauwelijks cruciaal is (denk aan de schermkopie funktie) en zal er alles bij elkaar een 4-5 dagen werk in kunnen zitten.

Overigens, met wat we tot nu toe hebben opgezet (maar dat is de COM methode) kunnen we zo ongeveer alles, waaronder ook het uitvragen van een variabele uit zelfs een taak op een andere PC (kan ik nog wel patent op aanvragen  ).

Als teaser  hieronder maar eens een schermprintje van een aantal tegelijk draaiende Profit taken.
Bij de tweede schermkopie zie je ook een "Kill" toets staan, zodat je niet alleen kunt achterhalen wie de bestanden nog open heeft, maar ze ook eruit kunt knikkeren.

Overigens zie je in de tweede kopie ook info schermen per taak (van uiteindelijk je hele netwerk dus), waarin zelf te definiëren zaken kunnen worden exposed. Op variabele niveau zeg maar.
De mogelijkheden zijn ongelimiteerd.


De node links bovenin zie je nu alleen "My computer", maar daar kan ook Network verschijnen, met alle PC's, en daaronder dan de taken per PC zoals hier getoond.

Tja ... Als er iemand nog een bosje ontwikkelaars overheeft ...

Rustig nou. Begin jij nou ook al te klagen over "gebruikers" ? Dat zijn ook maar mensen hoor. 

Overigens is misschien mijn boodachap niet helemaal overgekomen, of ik heb het niet goed verteld;
Ik bedoelde dat die gebruiker na TBC reorganiseren heus wel diezelfde fout weer krijgt, en de gebruiker wat dat betreft dus gelijk heeft. Alleen, jouw melding is (was) dat TBC niet helpt, en dàt kan niet juist zijn. Dus, het helpt wel, maar daarna doet die gebruiker (wederom) iets waardoor het opnieuw nodig is. En dus eigenlijk de vraag : wat veroorzaakt dat ?

Pascal, je verhaal moet haast onvolledig, bezijden de waarheid, dan wel uit de duim gezogen zijn. Nou ja, zoiets dan. 

Ik geloof niet dat je dit direkt na reorganiseren TBC weer hebt. Ofwel, er gebeurt iets heel anders -voorafgaand aan Raadplegen Artikelen (dan wel in een zijstap daarbinnen)- wat het betreffende bestand verknald.

Ik zou zeggen ga er zelf maar bij staan, doe TBC en bekijk wat er daarna gebeurt als je naar LOARRA gaat. Ik zeg : niets.

Fout. 

Heb je het zelf wel geprobeerd ? het lijkt er niet op ...

De eerste keer (binnenkomst scherm) bepaalt het systeem de Faktuurdatum en Vervaldatum op basis van Crediteur gegevens.
De tweede keer -dat is de keer dat je zelf de Faktuurdatum overschrijft- wijzigt de Vervaldatum mee (o.b.v. Crediteur gegevens).
De derde keer, wanneer je dus nògmaals de Faktuurdatum aanpast tijdens dezelfde Toevoeg aktie (op basis van een typefout ?), dàn wijzigt de Vervaldatum niet meer mee.

Edit : Zo fout ben je denk ik niet, als de "eerste keer" het systeem zelf maar niet is (is in mijn stukkie dus wel zo).

Wat essentieel is, is dat 'ie dat de eerste keer wel doet.

Wat dus verder essentieel is, is dat 'ie dat de volgende keren niet meer doet. Moeilijk heh ?

Jammer is dat we geen idee hebben waarom het zo werkt, maar het wel *met opzet* zo werkt. We kunnen dit aldus niet zo maar aanpassen, omdat iemand (de eerste, ooit) erom zal hebben gevraagd.