Hergenereren Afleveradressen 0 is een proces welke in principe altijd (en door iedereen) kan worden uitgevoerd. Afleveradres 0 betreft een Afleveradres die representatief is voor het Vestigingsadres. Dit Afleveradres wordt door het systeem gegenereerd zodra een Relatie als Debiteur wordt opgenomen. Worden de gegevens van een Relatie gewijzigd, dan zullen ook de gegevens van het Afleveradres 0 worden bijgewerkt. Omdat e.e.a. echter 'generiek' is, moeten deze adressen opnieuw gegenereerd kunnen worden. Dit kan middels de run "Genereren Afleveradressen 0" (Hoofdmenu,2,2,7,5).
Alvorens de Afleveradres 0 gegevens opnieuw te genereren, wordt eerst onderzocht of er toevallig Afleveradressen bestaan voor niet (meer) bestaande Debiteuren. Die kans is klein, maar is op zich aanwezig als er zich in het verleden bepaalde storingen hebben voorgedaan; stel dat iemand een Debiteur verwijderde en het systeem zou zijn geblokkeerd, dan kan het voorkomen dat Profit niet in staat was het Afleveradres te verwijderen. Dit gebeurt nu dan alsnog.
Toch, in een tabel met 100.000 Afleveradressen neemt alleen dit deel (met name in ADS) al een aanzienlijk deel van de benodigde tijd in beslag. Binnen ADS is de performance van dit stuk in deze Releasenote aanzienlijk verbeterd het bepalen van deze Afleveradressen over te laten aan de SQL engine van ADS. Wat eerst een half uur duurde, wordt nu in een paar seconden uitgevoerd.
Na het opschonen van de Afleveradressen v.w.b. die adressen waarvan de Debiteur niet meer bestond, werden ook eventuele 'dubbele' Afleveradressen geëlimineerd. Saillant detail is dat we ons al wel eens hebben afgevraagd waar die dubbele adressen vandaan kwamen, terwijl nu blijkt dat deze run daar zélf debet aan kon zijn. In plaats van enkel te kontroleren of het Afleveradres 0 al bestond, probeerde ze ook dit record te locken. Indien het Afleveradres 0 gelockt kon worden, werd ze herschreven, en anders werd ze opnieuw toegevoegd. Ofwel: Afleveradres 0 in gebruik door een ander? dan werd er klakkeloos een nieuwe toegevoegd. Fout dus, en eveneens in deze Releasenote hersteld.
Daarnaast is het genereren van Afleveradres 0 aangepast m.b.t. de kontrole op de lengte van het Afleveradres. Hierin waren twee dingen voor verbetering vatbaar.
Allereerst: Bij de Relatiegegevens NAW kunnen we een Naam van een Relatie kwijt; hier kunnen we alleen voor de naam al ruim 50 characters invullen. Als we echter dit adres in een formeel adresblok moeten vermelden, zijn er ineens regels die stellen dat de regels van een adresblok niet breder mogen zijn dan 30 characters. Venster enveloppen, adresetiketten e.d. zullen ook van die lengte uit gaan.
Technisch gezien kunnen we bij de Relatiegegevens dus een bedrijfsnaam "Chinees-/Indisch Restaurant De Gouden Muur" invullen, maar, achter een Adresetiket zal het niet passen. Derhalve hebben we bij de Relatiegegevens NAW ook een "Postnaam" waarvan de lengte beperkt is tot 30 posities. Hier kan de gebruiker dan de afgekorte versie van de naam invullen: "De Gouden Muur"; die versie zal ook voor Afleveradres 0 worden gebruikt. Iedere keer als wij de Postnaam wijzigen, wordt deze opnieuw doorgekopieerd naar Afleveradres 0, en ook "Hergenereren Afleveradressen 0" kan dit (dus) straffeloos doen; de data is generiek.
LET OP: Op eenzelfde wijze staan de Relatie NAW gegevens ons toe om een Adres op te nemen. Hierbij is het adres van een Relatie gesplitst in een separaat Adres (de straatnaam) en een Huisnummer. Het eerste veld staat ons toe 30 characters in te vullen, het laatste veld 8.
Tezamen kunnen we hier 38 posities invullen, terwijl het Afleveradres (0) slechts over 30 posities beschikt (het adresetiket mag immers niet breder zijn). We zijn daarmee in staat om bij een Relatie een straatnaam "Haaldersbroekerdwarsstraat" invullen, met als Huisnummer "16271a". Deze kombinatie leidt tot een Adres:
Haaldersbroekerdwarsstraat 16271a welke bij het Afleveradres wordt 'afgekapt' op 30 posities. Het effekt daarvan is dat het adres op uw verzendetiket wordt:
Haaldersbroekerdwarsstraat 162 In 2011 is dit probleem gekonstateerd, echter, met enkel als oplossing "een melding" die aangeeft dat dit adres niet past. Daarna was het aan de Gebruiker om een korter adres in te vullen, maar ja, als die Gebruiker dat niet deed, of het belang van die melding niet in zag, dan konden we alsnog "door gaan".
In het verdere trajekt weet Profit vervolgens niet beter dan dat de goederen moeten worden afgeleverd op het Afleveradres 0, en dat Afleveradres bevat nu "Haaldersbroekerdwarsstraat 162". Uw goederen worden dus aan een verkeerd adres geleverd, en niemand die er erg in heeft.
Merk hierbij ook op dat een Afleveradres 0 niet gewijzigd kan worden en het *DUS* zo moet zijn dat de Gebruiker reeds bij het vastleggen van de Relatie het Adres zodanig moet afkorten dat ze (in kombinatie met het huisnummer) niet langer wordt dan 30 posities; biivoorbeeld:
Haaldersbroekerdwarsstr 16271a Heeft ze dit eenmaal ingekort, dan kan dit vervolgens weer probleemloos worden doorgekopieerd bij Genereren Afleveradressen 0.
Aanleiding voor deze Releasenote is dat we recentelijk bij een klant opnieuw Afleveradressen 0 hebben moeten genereren, en hier honderden keren de melding kwam dat het Adres niet paste. Dit is niet alleen 'lastig' omdat er honderden keren een melding weggedrukt moet worden, maar, het gaat dus ook echt fout! immers dit zijn honderden adressen waarbij het huisnummer gedeeltelijk zal komen te vervallen in het Afleveradres!
In plaats van een melding te geven (die overigens bij het Toevoegen van een nieuw Adres nog wel zal verschijnen) geldt dat Profit m.i.v. heden er voor zal zorgen dat het HUISNUMMER wel juist in het adres wordt opgenomen, en dat de Straatnaam wordt ingekort! Desnoods komt hier dan iets uit wat amper leesbaar is (bijv. "Haalderbroekerdwa" met een huisnummer), maar, dat is altijd nog beter dan een straatnaam te vermelden met een huisnummer welke niet korrekt is, want dan weten we zeker dat onze goederen naar een verkeerd adres gaan. En, nogmaals, als de Gebruiker zélf het adres al heeft ingekort, hoeft Profit hier niet in te grijpen; het is dus a.h.w. een noodprocedure bij het verzuimen van ingrijpen door de gebruiker.
Aanvullend zal de run "Genereren Afleveradressen 0" niet voor ieder foutief adres met een melding komen (dit waren er honderden) maar wordt er een logfile opgebouwd met daarin de foutieve adressen en waarin Profit e.e.a. gekorrigeerd heeft.
Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
LORDAAGN | Genereren Afleveradressen 0 | 22-05-2018 | 25-05-2018 |
LORDOP | Relatie Opnemen als Debiteur | 12-01-2018 | 25-05-2018 |
LORENWWY | Wijzigen Relatie NAW-gegevens | 13-07-2017 | 25-05-2018 |