Projekt in Korrektur setzen

Unter bestimmten Umständen kann die Korrektur von Informationen zur Eigenerzeugungsanlage erforderlich werden. Diese Korrekturen müssen vom Antragssteller im Kundenportal vorgenommen werden. TINA bietet die Möglichkeit, über einen Aktionsboxeintrag ein Projekt in Korrektur zu setzen. Der Antragssteller wird entsprechend über die notwendigen Korrekturen informiert.

Technische Dokumentation

Komponentenübersicht

Prozesse

• Projekt in Korrektur setzen (C14ProjectSetRevision)

Sprachvariablen

• C14ProjectStatus30_PortalSubject

• C14ProjectStatus30_PortalText

• C14ProjectStatus30_Subject

• C14ProjectStatus30_Text

Globale Variablen

• C12PortalUrl

Ablauf

Bei Unklarheiten bzw. bei manueller negativer Prüfung kann über die Aktion „Projekt in Korrektur setzen“ im Projekt für den Portalanwender eine Nachricht erfasst werden. Diese Nachricht wird in TINA als Aktivität erfasst und im Kundenportal als Kommentar zum Projekt/Vorgang angezeigt.

Bedingung: Die Aktion steht zur Verfügung, wenn der Projektstatus < 60 UND die Projektart-Details ungleich BKW ist und man sich in der Detailansicht eines Projekts befindet, oder in der Listenansicht, wenn genau ein Projekt ausgewählt ist.

• Prozessstart aus der Aktionsbox am Projekt über den Schalter “Projekt in Bearbeitung setzen”

• Projektstatus wird auf 30 - Auftrag in Korrektur gesetzt

• Ausgabe der Neuanlagemaske einer Aktivität vom Typ PORTAL-ACT
  Die Aktivität kann vom Anwender bearbeitet werden. Nach dem Speichern wird die Aktivität im Posteingang des Portalbenutzers im Kundenportal angezeigt

Aufbau der Aktivität

Sollten mehrere Aktivitäten vorhanden sein, wird im Portal immer nur die neuste/letzte (über Beginn) angezeigt. Die Nachricht selbst wird nicht per Mail versendet. Lediglich über die automatisch Status-E-Mail beim Setzen des Status 30 werden die entsprechenden Projektbeteiligten informiert.

Nachdem der Portalanwender die Daten korrigiert hat (alle Eingabefelder sind bearbeitbar im Portal) wird über das Portal der Status 40 - Auftrag nachgebessert im Projekt gesetzt und der Vorgang analog der Anmeldung an die entsprechende Gruppe gemäß Leistung delegiert.

Wenn das Projekt durch den Portalanwender korrigiert wurde, wird das Projekt mit dem Status 40 erneut übertragen (REST-Service ag.itc.createGeneratingUnit). Dabei werden die unter Anschlussobjekt identifizieren , Zähler identifizieren und Geschäftspartner identifizieren aufgeführten Prüfung / Logiken erneut ausgeführt.

Folgendes wird dabei je Objekt beachtet:

• Project: ID ist das JSON-Attribute projectNo. Alle übergebenen JSON-Attribute auf Ebene project werden aktualisiert.

• location: ID ist das JSON-Attribute pk. Wird der pk vom Portal mit übertragen und dieser stimmt mit dem am Projekt verknüpften Anschlussobjekt überein, erfolgt keine Änderung. Sollten weitere Anschlussobjekte zum Projekt verknüpft sein, wird die Verknüpfung entfernt.
  Wird kein pk übergeben (Adresse hat sich geändert), werden alle zuvor verknüpften Anschlussobjekte am Projekt entfernt. In diesem Fall muss erneut über die Adresse selektiert und die gefundenen Anschlussobjekte dem Projekt zugeordnet werden. Anschließend muss die Aktion Anschlussobjekt identifizieren erneut durchlaufen werden.

• installation: ID ist das JSON-Attribute pk. Die Liste der installation Objekte wird synchronisiert. Wenn ein installation Objekt nicht mehr aus dem Portal übertragen wird (pk fehlt), wird dies in TINA gelöscht (Installation.Active=false). Neue Objekte werden ohne pk übertragen und werden in TINA angelegt. Geänderte Objekte werden über den pk identifiziert und aktualisiert (alle JSON-Attribute).

  • instDetailPV: ID ist das JSON-Attribute modulePk. Die Prüfung auf neue, gelöschte oder geänderte instDetailPV-Objekte verhält sich analog dem installation-Objekt.

  • InstDetailSt: ID ist das JSON-Attribute powerStoragePk. Verhalten analog instDetailPV.

  • InstDetailInv: ID ist das JSON-Attribute inverterPk. Verhalten analog instDetailPV.

• projectParties: ID ist das JSON-Attribute type in Verbindung mit der projectNo.

  • customerProfile: ID ist das JSON-Attribute pk. Weicht der Geschäftspartner zu der übertragenen Projektrolle (JSON-Attribute type) ab, wird die Verknüpfung zwischen Projekt und Geschäftspartner entfernt (projectParties.type und customerProfile.pk müssen übereinstimmen). Anschließend erfolgt die Prüfung analog Geschäftspartner identifizieren .

  • address: keine ID im JSON-Objekt vorhanden. Bezieht sich auf die Postadresse zum Geschäftspartner (customerProfile). Wird lediglich für die Prüfung bzw. ggf. Übernahme in den GP (ohne SAP-Nr.) unter Geschäftspartner identifizieren verwendet.

  • contactProfile: Wird aktuell nicht beliefert aus dem Portal.

• installer:

  • InstallerDetail: wird bei Anmeldung oder Korrektur im Service ag.itc.createGeneratingUnit nicht beachtet.

  • customerProfile: Wenn die Projektrolle INSTALLATEUR am Projekt (genau eine) den gleichen PK hat wie das JSON-Attribute customerProfile.pk, ist keine Änderung erforderlich. Wird ein anderer PK übertragen, wird die vorhandene Projektrolle INSTALLATEUR entfernt und der GP mit dem neu übergebenen PK in dieser Rolle dem Projekt zugeordnet.

  • customerAddress: nicht rel. siehe InstallerDetail

  • contactProfile: nicht rel. siehe InstallerDetail

• activities: Jedes activity Objekt erzeugt immer eine neue Aktivität in TINA (mit jedem neuen Aufruf von ag.itc.createGeneratingUnit.

 Allgemein - Löschen von Feldinhalten

Wenn ein JSON-Attribute leer übertragen wird z.B. instDetailPV.product={} für Komplexe oder customerProfile.phoneNoBase=““, wird die Referenz auf das Produkt in den Anlagendetails-PV entfernt bzw. das Feld geleert.