In CAPO kunnen bijlagen per discipline worden uitgesplitst. Soms nemen meerdere netbeheerders van dezelfde discipline (bijvoorbeeld meerdere medianetbeheerders) deel aan een project. Als bijlagen aan de netbeheerder werden toegewezen, maakte het systeem automatisch voor elke netbeheerder van die discipline een bijlage aan. Werden de bijlagen aan de aannemer of de combi toegewezen, dan maakte het systeem per discipline één bijlage. Dat leidde bijvoorbeeld tot één Vergunning Media voor de aannemer, terwijl er twee of meer mediapartijen in het project zitten.

Bijlagen die per discipline worden toegewezen, krijgen voortaan een toewijzing per discipline‑netbeheerdercombinatie. Daardoor ontstaat altijd voor elke netbeheerder op het project een bijlage per discipline. In het scherm ziet u dit aan de toevoeging ‘namens …’ onder de toewijzing wanneer een bijlage per discipline wordt klaargezet.

Open

Via de API is er een nieuw, optioneel, veld netbeheerder toegevoegd aan de BijlageAssigned, dit veld komt mee bij het ophalen van een bijlage die per discipline wordt aangemaakt. Ook is dit veld in sommige gevallen verplicht bij het aanmaken van een toegewezen bijlage via de API; als een discipline meer dan één keer voorkomt op een project moet verplicht worden aangegeven voor welke netbeheerder-discipline de nieuw aan te maken toegewezen bijlage geldt.

Bijlagen die per discipline worden bijgehouden en zijn toegewezen aan de aannemer of combi krijgen voortaan het veld ‘namens’. Zo is meteen duidelijk voor welke netbeheerder het werk is.
Heeft een discipline meerdere netbeheerders (bijvoorbeeld twee mediapartijen)? Dan wordt zo'n bijlage automatisch gesplitst: één exemplaar per netbeheerder. Was de bijlage al aan één specifieke netbeheerder gekoppeld, dan verandert er niets.

Voorbeeld

Een project in Grond’g heeft twee Media netbeheerders: VWT en Ziggo. De bijlage CROW 500 media stond op naam van de aannemer en is nu opgesplitst in:

• CROW 500 media namens VWT

• CROW 500 media namens Ziggo

Was er al werk gedaan op een bijlage (bestanden geüpload of opgeleverd)? Dan is niet meer te achterhalen voor welke netbeheerder(s) dat werk bedoeld was. Deze bijlagen zijn daarom niet automatisch gesplitst.

Voor CAPO Hoofdleiding is er in SION bij Combi Combinatie Noord (samenwerking van Baas, Ahak en Verkley) de wens om aan te kunnen geven welke van de 3 aannemers het hoofdleidingproject oppakt. Om dat mogelijk te maken zijn de volgende 3 labels toegevoegd voor de gebieden waar CCN werkt:

• CCN_Baas

• CCN_AHak

• CCN_Verkley

Omdat CAPO Aansluiting en CAPO Hoofdleiding op dit moment dezelfde labels hebben, zijn deze nu ook beschikbaar voor CAPO Aansluiting projecten.

Het is sinds kort ook mogelijk om bijlagen te configureren die die pas actief worden als een voorgaande bijlage is opgeleverd. De deadline van deze bijlage kan dan ook gekoppeld zijn aan de oplevering van de voorganger.

Als deze bijlagen nu met de hand worden aangemaakt (bijvoorbeeld om fouten te herstellen) is het in de schermen nu duidelijk op welke bijlage ze wachten, en wat hun deadline zal zijn:

Open

Subproces Schouw kan nu volledig via de API afgehandeld worden, dus inclusief het optioneel toe te voegen Schouwrapport. Hierbij de volgende aandachtspunten:

• Detailinfo over de aanpassingen in de API zie hieronder. Met de aandachtspunten:

  • Een bijlage (Schouwrapport) aan het subproces toevoegen kan via de nieuwe route POST /project/{projectId}/subproces/{subprocesId}/bijlageassigned

  • Herkennen dat er een toegewezen bijlage bij een subproces is, kan door de lijst bijlagen op te halen en te controleren of er bijlagen zijn met een overeenkomend subprocesId. Als dit Id er is, betekent het dat de bijlage bij een subproces hoort.

  • Een subproces schouw kan alleen afgerond worden als er geen openstaande toegewezen bijlage meer onder dit subproces hangen.

• Volledig afhandelen via de API kan, maar we werken nog aan de volgende verbeteringen:

  • Het schouwrapport alleen via een subproces kunnen toevoegen (nu kan dat ook als reguliere toegewezen bijlage, wat niet de bedoeling is)

  • De (error)meldingen via de API voorzien van zowel de systeem status als de gebruikerstatus van de subprocesstappen.

  • Een extra annuleringsreden om aan te geven dat een schouw is geannuleerd, omdat het project naar een andere aannemer gaat.

• Nieuwe eigenschap netbeheerder aan type BijlageAssigned toegevoegd.

• Nieuwe eigenschap netbeheerder aan type CreateBijlageAssignedDetails toegevoegd

• Route POST /project/{projectId}/subproces/{subprocesId}/bijlageassigned toegevoegd - voor het aanmaken van een bijlage onder een subproces

• Eigenschap subprocesId aan type BijlageAssigned toegevoegd

• Eigenschappen subproces en subprocesStatus toegevoegd aan type BijlageTemplate

De netbeheerders voor Hoofdleiding projecten zijn bij SION anders dan voor Aansluiting projecten. De volgende netbeheerders zijn voor SION extra toegevoegd in alle gebieden, specifiek voor Hoofdleiding projecten:

• Deltafiber

• Glaspoort

• VWT (KPN)

• Ziggo (VodafoneZiggo)

Dit effect wordt alleen gemerkt op de QAS-omgeving, gezien SION op productie nog niet live is met CAPO Hoofdleiding.

• CAPO Aansluiting: Als een extra adres aan de aanvraag wordt toegevoegd door middel van het verstrekken van een DSP-opdracht, dan werd het huisnummer hiervan teruggeven als Integer (getal) in plaats van string (tekst). De documentatie omschrijft echter dat er een string terug gegeven dient te worden, dus dit is nu hersteld.
  Het issue is ontstaan met de introductie van DSP 2.0, waarin huisnummers als Integer worden opgevoerd.

• Bij snel en vaak doorklikken naar een volgende pagina op het projectenoverzicht ontstond er een fout met het inladen van de projectenlijst. Dit is verholpen.