Faculteits ruimternummer bij ruimteselectie
Bij alle ruimte selecties wordt gebruik gemaakt van het Vastgoed ruimtenummer.
Nu is bij start van het project aangegeven dat dit voor de faculteiten een transparant gegeven moet zijn. M.a.w. De faculteiten moeten ook kunnen werken met de eigen ruimte nummering. (Faculteit Ruimtenummer) Hierover is enkele malen gesproken.
Voor de acceptatie is het dan ook van doorslaggevend belang dat dit mogelijk is.
Dit betekent dat naast:
Ruimtebeheer->ruimten->Zoeken->Ruimte nr :
Ook op een Faculteitsnummer gezocht kan worden.
En ook bij een Werkplek een faculteitsruimtenummer staat die geselecteerd kan worden.
Bij objecten geldt hetzelfde verhaal:
Zonder alle schermen te willen doorlopen wil ik stellen dat dit voor alle plaatsen geldt waar Ruimte een rol speelt.
Ik ben me er volledig van bewust wat dit betekent maar toch moet hiervoor een oplossing gevonden worden.
Suggestie:
Indien dit mogelijk is:
Ruimtes hebben een dubbele referentie.
Met Vastgoed rechten is ruimte een Vastgoed nummer
Met alleen WEB-ALGUSE is ruimte een Faculteitsruimte nummer.
(Om geen maatwerk te zijn moet dit een vaste functionaliteit worden waarbij een ruimte een dubbele nummering kan hebben.)
Dit niet gehinderd door enige vorm van kennis.
GEGEVEN: Voor het gebruik is het facnr belangrijker dan het VGnr.
AANNAME: Het facnr is (ook) uniek binnen een bouwlaag
OPTIE: Wissel het facnr en ruimtenr om, zodat bij normaal gebruik het facnr gebruikt wordt. Het kenmerk faculteitsruimtenr wordt dan vastgoedruimtenr.
KEUZE: Indien geen facnr bekend is, wordt [vgnr] gehanteerd
REALISATIE: Script maken en uitvoeren voor de omwisseling van deze data-elementen; kenmerk facnr hernoemen naar vgnr en volgnr wijzigen in <100 ipv >100; aanpassen van de VG rapportages om het vgnr nieuwe stijl te gebruiken.
Raming: ca 12 uur.
* 10-Mar-04: Actie bij Witting, Robert *
In overleg met Wim Geers zijn we in pricipe met deze voorgestelde aanpak. Het lijkt on goed om dit op de Testomgeving uit te voeren en dan de gevolgen te aanschouwen. Overigens ga ik ervan uit dat je met Bouwlaag verdieping bedoeld. E.e.a. houdt overigens ook in dat enkele rapportages dubbel uitgevoerd moeten worden of zijn ze te combineren door beide nummers op te nemen.
* 11-Mar-04: Actie bij Feij, Peter *
Bedankt. Ik stel voor in de VG rapportages de notatie 'VGnr (Facnr)' te gebruiken. Wat nog even over het hoofd gezien is: voor ruimtenr is nu WEB_ALGMAN vereist, en nu is WEB_ALGUSE gewenst. Dit onderscheid moet met een configuratiesetting te regelen zijn: FSN#835
svn path=/Customer/trunk/; revision=12595
Er is verzocht om een export vanuit Facilitor met ruimtegegevens naar Masterkey-Plus.
* 06-Jan-04: Actie bij Feij, Peter *
In overleg met MK besloten voorbeeldbestanden uit te wisselen. Op basis van XML is op 23-12-03 een voorbeeldbestand naar Wilco Lammers gezonden.
* 06-Jan-04: Actie bij Derks, Richard *
Na overleg met Robert Witting: XML "handmatig" genereren dmv aanroep batchfile (dit omdat verwacht wordt dat export 4x per jaar moet worden uitgevoerd). Bij de naamgeving van het exportbestand hoeft geen rekening gehouden te worden met eventuele naamconflicten met eerdere exports (dus constante naam voor export). O.a. omdat de batchfile SQLPLUSW aanroept is het handig even een (korte) manual te schrijven.
svn path=/Customer/trunk/; revision=12593
Bestanden:
1. RUIMTE_ALL.XML: volledig resultaat gebruikersrapport "XX - Alle ruimten in XML formaat"
2. ..\LEVERING\RUIMTE.XML: 5 records uit het bestand RUIMTE_ALL.XML.
3. TUDERAP2XML.XLS: met sheet "Opdrachtomschrijving", "XML Sample" (voorbeeldbestand van Masterkey-Plus B.V.)
en sheet FCLT2XML (afbeelding ruimtegegevens Facilitor op voorbeeldbestand)
4. USRRAPUPD_443.SQL: definitie gebruikersrapportage (kopie van \SQL\_CUST\TUDE\USRRAPUPD_443.SQL)
svn path=/Customer/trunk/; revision=12591
Jos,
Bij alle "aanbevelingen" zijn doorgevoerd. Lijkt me handig om interactief met jouw de puntjes op de i te zetten:
- evt. aanpassen veldnamen view ...
- kort bekijken views die ik niet heb geinitieerd ...
Tevens is view 1 nog niet opgesplitst: ruimten in gebruik TU, derden, leegstand .... Dit verschil herleiden uit kostenplaatsaanduiding, ik hoop van niet ...
Het volgende bleek (voor mij) handig te zijn:
1. Zo min mogelijk afwijken van Facilitor kolomnamen, bijvoorbeeld niet tude_ruimtegeg.omschrijving maar tude_ruimtegeg.alg_ruimte_omschrijving. Je kunt dan beter "gokken" wat de veldnaam moet zijn, bovendien kun je dan ook nog gebruik maken van relatieve aanduidingen (denk aan group by 1 etc.)
2. Afgeleide/bewerkte namen moeten als zodanig herkenbaar zijn en zo veel mogelijk aansluiten bij de Facilitornaamgeving, voorbeeld TUDE_GEBOUWGEG.gebouw_code.
3. Zo min mogelijk gebruik maken van een veld alias (meer verwarring en bij wijzigingen onnodig werk): de header van de view legt de veldnamen voor de gebruiker vast.
Met vriendelijke groet,
Dijkoraad IT bv
Richard Derks (richard.derks@it.dijkoraad.nl)
Tel. (053) 4800700
Fax (053) 4800711
//
// Dijkoraad IT doet meer dan u denkt : http://www.dijkoraad.nl/it
//
svn path=/Customer/trunk/; revision=12587
Wat ik zo bedenk (en wat ik altijd bereid ben toe te lichten)
01: Uitsplitsen in 01a, 01b en 01c?
Selectie kostenplaats niet nodig
02: Wat bedoel je met de opmerking 'Wel in DIT05/TUDE'
03:Selectie kostenplaats niet nodig maar laat maar
04: Selectie kostenplaats niet nodig maar laat maar
Selectie gebouw moet wel kunnen
20: Kolomkop SUBTOTAAL1 moet zijn "AANTAL_RUIMTES"
Selectie gebouw op zich niet nodig maar laat maar zitten
23 Selectie gebouw op zich niet nodig maar laat maar zitten
Algemeen
TUDE_GEBOUWGEG: VLEUGEL_SHORT er uit
VERDIEPING_RUIMTE_OMSCHRIJVING weg
GEBOUW_CODE_NAAM in RUIMTEGEG is niet echt netjes (en zit ook volgend punt)
Altijd gebouwcode als veld zodat 36 zonder % mogelijk is
Ik heb een variant van TUDE_RAP_22a gemaakt met naam Test JGL. De subtotaal regels hebben hierin een tekstje '{Totaal}' en '====>'. Lijkt mij mooier voor subtotalen. Wat dunkt jou?
Misschien meer KOSTENPLAATS IS NOT NULL erbij of NVL(KOSTENPLAATS,'{niet ingevuld}'
svn path=/Customer/trunk/; revision=12586
