Is juist makkelijker. Toont in elk geval aan wat ik al denk, maar wat nog niet inhoudt dat het probleem zal zijn te vinden.

Er schiet me nu wel dit te binnen :
Ik weet niet of dit nog in Dos wil werken, maar zo ja ... probeer dat eens svp ?

Vraag dan maar geen upgrade aan. Dan weet je zeker dat we geen problemen krijgen.
Die je hebt worden ook niet opgelost, maar dat had je al gedacht.

Herhaling :

---

Indien er een Faktuur wordt gegenereerd voor een Groepsdebiteur uit onderliggende Debiteuren, en bij een betreffende onderliggende Debiteur is de Administratiekode ingevuld, zal de (zullen de) Layoutvariabelen worden gevuld met de gegevens van de onderliggende Debiteur en worden de gegevens van de Groepsdebiteur overruled.

---

Goed of fout ?

Nou, we gaan het maandag wel proberen uit te vissen. Maar dit wordt geen makkelijke denk ik ...

Dat is verre van onzin. Lees nog eens goed :


Als ik vraag wat jij vindt dat een aansluitnummer is, dan moge het helemaal heel erg 100% duidelijk zijn dat ik vraag hoe jij dat ziet. En niet hoe Wouter dat ziet of vindt of vertaalt uit jouw woorden die ik niet ken.


Zal best, maar ik heb nog nooit van een financiële groepsdebiteur gehoord. En dus :


... en dus geloof ik daar al niets van (dat het zo is, dan wel dat de inhoud overeenkomt met wat jij ZEGT). Althans, Wouter heeft ook nog nooit van een financiële groepsdebiteur gehoord.


En wie bepaalt dat ? jij ?? wat mij betreft is DIT pas onzin. Immers, het kan nergens over gaan want het bestaat niet (ja, in jouw hoofd).

---

... en zo komen we de vrijdag wel weer door 

---

Ter zake dan maar;
De door jou keurig gevonden Administratiekode is *eigenlijk* precies bedoeld voor wat jij wilt. Althans, ik weet waarvoor (voor wie) die is gemaakt, en dan mag het overeenkomen met wat jij nu wenst. Echter, zoals je zelf zegt :


Ik kan me op dit moment niet helemaal inbeelden waarom het werkt zoals het werkt (wat overigens inhoudt dat in alle geval alleen de "eigen" Administratiekode wordt gebruikt -> werkt ook bij de Groepsdebiteur zo), maar ik kan wel zien dat dit gemakkelijk is te veranderen :

Indien er een Faktuur wordt gegenereerd voor een Groepsdebiteur uit onderliggende Debiteuren, en bij een betreffende onderliggende Debiteur is de Administratiekode ingevuld, zal de (zullen de) Layoutvariabelen worden gevuld met de gegevens van de onderliggende Debiteur en worden de gegevens van de Groepsdebiteur overruled.

Op deze wijze mag het blijven werken voor diegenen die dit al gebruiken, en werkt het voor jou ook.


Dit heb je wel goed gezien. Hooguit moeten wij daarvoor zorgen.


Middels het inzetten van de Administratiecode suggereer je behoorlijk hard dat bovenstaande dan niet meer nodig zou zijn. Dus :


Dit meen je toch zeker niet ? Maar ik zal het nu te letterlijk lezen ?
En als je het wel meent snap ik het niet. Zie eervorige quote.

Lieve Johan ( )

Ik vind het persoonlijk toch wel aardig dat de organisatie die we hier in de wandelgangen aanduiden met KM er voor heeft gezorgd dat het Wijzigen van de Relatie de boel verziekte. Zie http://ha1.heartprofit.nl/profit/index.php?topic=20366.msg28782#msg28782.
Ja inderdaad, per april 2003. Natuurlijk, het zijn wij oenen die dat ook honoreerden, waarmee we allemaal misschien toch doorhebben waarom iemand als ik tegen zo ongeveer alles ingaat. Gebeurt dat niet, dan vraagt de gebruiker iets aan wat fout is, en 5 jaar later krijgen wij de schuld.


Knap gevonden. Petje af hoor !
pffff

en geef nu je kollega van destijds maar de schuld, dan heb je het zelf tenminste niet gedaan, hahaha

LET OP :

We hebben kunnen achterhalen dat bij Generen Afleveradressen 0, sinds september 2002 het betreffende op (zoals nu beoordeeld) foute wijze is aangepast; er is toen een vraag van een (onbekende) klant gehonoreerd die liever de Naam (mits korter dan 30 posities) in Afleveradres 0 had omdat anders de vervoerder niet kon vinden waar (of wie) het betreffende heen moest.
In April 2003 is het Wijzigen van de Relatie aangepast omdat e.e.a. niet consistent werkte met het (her)Genereren van de Afleveradressen 0.

N.b.: Waarom niet meteen Toevoegen Relatie hierop eveneens is aangepast verhaalt de historie niet (en die is dus ook juist blijven werken).

Waarom deze uitleg ?
Omdat op dit moment iedereen zijn Afleveradressen 0 onjuist zal hebben (is gevuld met Naam i.p.v. Postnaam) indien deze na genoemde datum zijn hergegenereerd. Vervolgens zullen deze Afleveradressen 0 dan ook nog "hier en daar" onjuist zijn, namelijk voor iedere Relatie die is gewijzigd na genoemde datum.

De oplossing : Upgrade aanvragen en opnieuw Genereren Afleveradressen 0.

Ok, een upgrade heb je niet gehad sindsdien;
Hebben wij sinds die tijd zaken overgestuurd ditaangaande, naar jij weet ?

Zo niet, dan moeten we het erop houden dat het een technische fout is die we vast niet snel gaan vinden.
Zo wel, dan heb ik betere hoop op snel vinden.

Sorry voor de vragen, maar kan je nog aangeven sinds wanneer dit is ? Ja, vast wel sinds vandaag. Daarom bedoel ik eigenlijk : kan je aantonen dat wat je hier doet (wat het ook precies is) eerder (en wanneer dan voor het laatst) wel werkte ? (Ja is voldoende, bewijs is niet nodig).

Ok. En hoe lang was het ding aan het rekenen voordat de fout optrad (ongeveer hoor) ?

... per de aangegeven Bladlengte (Printerdriver e.d.).

Hoeveel diskruimte heb je over ? (C:)

Yep.

Het blijkt nu dat de Pakbon geen rekening houdt met "Ik ben EDI en dus geen nieuw blad onderkennen". Waarom we dat nog van niemand hebben gehoord ? geen idee, maar als je (inderdaad) de bladlengte op 999 zet, kan je 999 fysieke regels vooruit (aantal Pakbon Regels zal dus minder zijn).

Het wordt nu meteen aangepast (en bij jullie erop gezet zodra klaar).

... wat je mag lezen als : op jouw manier van oplossen;

Laat ik beginnen met een poging je duidelijk te maken dat jouw voorstel voor oplossing in deze wat mij betreft nooit mag werken. Ok, het is zeer theoretisch, maar voorlopig hanteren wij deze theorieën :

Zoals Wouter al heef gezegd, het is maar net hoe wij het oplossen. Alleen, dat is niet arbitrair. Wij doen NIETS arbitrair, of in beter Nederlands : alles heeft nog niet eens z'n overweging, maar volgt uit simpele normalisatie. En, wil je echt weten wat ik bedoel, dan moet je vooral bij jullie zelf maar eens kijken wat er gebeurt rond de Verkooporder aangaande het Statisch maken. Als je meteen weet waarop ik doel, dan zie je ook hoe destijds precies DIE oplossing is gekozen, en wel voor jullie zelf. Dit even samengevat : als je met in principe dynamische gegevens werkt, werkt dit zeer tegen je aan de grens met allerlei Pro-forma zaken, die immers bij het overbrengen van het fysieke produkt nog wel een beetje (erg veel) overeen moeten komen ...

Nu er vanuitgaande dat je helemaal weet waarop ik doel (nogmaals, het is voor jullie ontwikkeld destijds), en je zou voor de lol een inventarisatie eraan wagen waarop dit allemaal betrekking heeft, dan a. schrik jij je dood en b. stop je met ingang van nu met jouw queries. Ze zouden voor geen (milli)meter werken ...
Moraal hiervan : jij komt nu toevallig op de Leverkondities, maar dat komt omdat je de tijd nog niet hebt gehad om de 200 andere zaken tegen te komen. En vandaar dat ik er stellig in ben : dan doen we die ene waar je nu toevallig wel mee komt dus ook maar niet.

Waar dit één kant van de zaak is, moet je vooral ook hier aan denken :

Weer verwijzend naar het niet-arbitraire karakter op basis waarvan dit soort zaken door ons worden bepaald, kan je er in theorie gevoeglijk vanuit gaan dat als we de zaken zo zouden maken zoals jij wilt, er iets anders niet meer werkt. Wat ? nou, het tegenovergstelde. Iets wat als dynamisch is bedoeld, is plots statisch geworden. Als we dan -achteraf !- dit soort zaken aanpassen omdat iemand dat graag wil (met Bedrijdsparameter of niet), weet ik 200% zeker dat in elk geval WIJ het pakket niet meer begrijpen. Immers, je haalt in één klap alle ooit bedacht logika (die wij intussen niet meer (hoeven te) kennen onderuit, en als jij als gebruiker dan nog een vraag hebt, kunnen wij die niet meer beantwoorden.

Om dan nog een beetje tegengas aan mezelf te geven :
E.e.a. neemt niet weg dat zaken ook *fout* kunnen zijn bedacht. Bijvoorbeeld, het zou wel eens zo kunnen zijn dat de Leverkondities uit jouw eigen voorbeeld, veranderen op een Duplikaat Faktuur. En tja, dàt is natuurlijk wel heel erg fout. De oplossing : die Leverkondities opnemen in de Faktuur (en we gaan er even niet over twisten of dat dat de Verkooporder zou moeten zijn). Dus, probleem opgelost, en jij mag een slimmere query maken.
Net zoals dat je nu al slimmere queries zou kunnen maken omdat je als eerste (idee bij jezelf) misschien juist wel van de Staitische gegevens gebruik zou moeten maken (tja, weet jij veel dat die bestaan).


Goed. Mocht je nog niet duizelig zijn, dan zal ik je nu duizelig maken :
Wat ik meer dan 20 jaar geleden in ontwerp (en ook uitgewerkt in werkende programmatuur) al eens heb gemaakt, is een database die je op moment in de tijd kunt raadplegen. Zie maar voor je dat iedere sleutel voortaan vooraf gaan door de datum/tijd van "geldig vanaf" en waarbij het volgende record de "tot" bepaalt. In zo'n database wordt niets meer verwijderd, en er wordt ook niets meer gewijzigd; er wordt alleen nog toegevoegd;

Als het aan mij ligt (en dat ligt het) heb je binnen een aantal maanden een database die op deze wijze in elkaar zit. Mooier bestaat niet, en alles kan. Jij zegt tegen Profit dat je alles wilt bekijken per 12 december 2006 15:02 en vervolgens zié je dat ook (ok, dit zal alleen voor de toekomstige records kunnen, dus 2006 is een niet werkelijk voorbeeld).
Wel even je queries aanpassen natuurlijk ...