Anbindung softgate-archiv

Im Zuge der IKAROS Entwicklung der 2018.1 P7 wurde für das softgate-archiv eine Optimierung der Anbindung vorgenommen. [Aufgabe 88624]
Diese beinhaltet, neben der Fokussierung der Archivübersicht beim Öffnen eines Dokumentes aus IKAROS, das Teilen der SessionId im Browser.
Durch die Teilung der SessionId minimiert sich die Anzahl der notwendigen Anmeldungen am softgate-Posteingangskorb und der softgate-Archivübersicht, wenn IKAROS in mehreren Browsertabs verwendet wird.

Die Korrektur des Fokusverhaltens der softgate-Archivübersicht ist in der Version 2019.1 P1 von IKAROS enthalten.
Das Komfort-Feature (Teilen der SessionId im Browser) ist erst in der Version 2019.1 P2 standardmäßig enthalten.

Wenn Sie dieses Feature bereits in der Version 2019.1 P1 von IKAROS nutzen möchten, bieten wir Ihnen die folgende Möglichkeit:

Spielen Sie die im Kundenbereich abgelegte Datei auf Ihrem Web-Server in jeder Instanz (Prod/Inte/Dev) im Ordner „Talos\_talos\communication\“ ein und überschreiben damit die vorhandene Datei.
Dies erlaubt die Teilung der SessionId für das softgate-archiv im Browser.

Die Korrektur wird mit Patch 2 zur Version 2019.1 und mit der Version 2019.2 im Standard ausgeliefert.

Fehler beim Starten von externen Programmen nach Update von Google Chrome

Der Fehler tritt nach Aktualisierung des Browsers Google Chrome auf Version 71 auf und betrifft alle Versionen von IKAROS, die die G4 Web-Oberfläche mit der neuen Web-Technologie verwenden (TALOS; ab IKAROS Version 2017.1).

Sie sind nur betroffen, wenn Sie Chrome in einer Version größer oder gleich 71 einsetzen und externe Anwendungen während der Vorgangserzeugung starten bzw. in anderer Custom-Code-Programmierung mehrfach hintereinander aufrufen.

Beschreibung:


Für die Ansteuerung von Word während der Vorgangserzeugung sowie für das Starten von externen Anwendungen verwendet IKAROS den IKAROS-ProtocolHandler. In Google Chrome ist die mehrfache Ansteuerung des ProtocolHandlers, ohne dass eine Benutzerinteraktion mit dem Browser zwischen den Aufrufen stattgefunden hat, normalerweise untersagt.

Um dies zu umgehen, erfolgt für Chrome eine Sonderbehandlung, die nur in Kraft tritt, wenn der Nutzer wirklich Chrome verwendet. Mit der Version 71 von Chrome wird der Browser jedoch von IKAROS nicht mehr als Chrome erkannt. Somit wird die Sonderbehandlung nicht mehr angewendet und die mehrfache Ansteuerung schlägt fehl.

Umgehungsmöglichkeiten:


Verzögern Sie das Update des Browsers Google Chrome bis Sie auf Patch 6 zur IKAROS-Version 2018.1 oder zur Version 2019.1 gewechselt haben.

Korrektur des fehlerhaften Programmverhaltens:


Sofern Sie von diesem Problem betroffen sind, spielen Sie die im Kundenbereich abgelegte Datei auf ihrem Web-Server in jeder Instanz (Prod/Inte/Dev) im Ordner „Talos\_talos\basics\“ ein und überschreiben damit die vorhandene Datei. Dies korrigiert die Erkennung der Browser.

Die Korrektur wird mit Patch 6 zur Version 2018.1 und mit der Version 2019.1 im Standard ausgeliefert.

Beschreibung des EU-DSGVO-Konzepts zur IKAROS-Version 2018.1

Die erste Fassung des Konzepts zur Umsetzung der europäischen Datenschutzgrundverordnung (EU-DSGVO) in IKAROS-Version 2018.1 steht zum Download unter Konzept EU-DSGVO v1.0.pdf bereit.

In diesem Dokument wird zum einen dargestellt, welche generellen Anforderungen sich aus der EU-DSGVO aus Sicht von Ferber-Software für den Einsatz von IKAROS ergeben und welche Lösungsmöglichkeiten dafür vorgesehen sind. Dieses Kapitel ist als Ausblick auch für Kunden interessant, die ab 1. Mai 2018 noch nicht IKAROS 2018.1 einsetzen werden, sondern z. B. noch mit einer G3-Version arbeiten.

Zum anderen enthält das Konzept einen Überblick über die konkrete Umsetzung der Lösungsmöglichkeiten in IKAROS 2018.1, inklusive Screenshots auf Grundlage des aktuellen Entwicklungsstands.

Ein ähnliches Dokument zur Beschreibung des Konzepts für die Versionen 2.12 und 2017.1/2017.2 werden wir in der nächsten Zeit ebenfalls zur Verfügung stellen.

Sollten Sie bezüglich der EU-DSGVO im Zusammenhang mit IKAROS weitere Fragen haben, können Sie sich gerne an Hrn. Schürmann (bernfried.schuermann@ferber-software.de) wenden.

Punktlandung der Version 2017.1 von IKAROS

Das gesamte Team von Ferber-Software freut sich sehr, die Veröffentlichung der Version 2017.1 von IKAROS enterprise und IKAROS plus bekannt zu geben.

Bereits einen Tag vor dem geplanten Releasetermin am 30.06.2017 konnten wir unseren Kunden mitteilen, dass die Version zum Download bereitgestellt worden ist.

Mit dieser Version profitieren unsere Anwender von vielen Aspekten der 4. Generation von IKAROS, sei es die neu konzipierte und bedienerfreundliche Aktenbearbeitung, die webbasierte Oberfläche oder die überzeugende Performance. Für uns bedeutet die Version ein großer Schritt  in Richtung IKAROS G4.

Sie erwartet ein neues Arbeiten mit IKAROS, wir erwarten Ihre spannenden Rückmeldungen.

Gesetz zur Bekämpfung von Zahlungsverzug im Geschäftsverkehr

Am 29. Juli 2014 trat das „Gesetz zur Bekämpfung von Zahlungsverzug im Geschäftsverkehr“, eine Umsetzung der EU-Richtlinie „2011/7/EU“, in Kraft.

In diesem Gesetz ist unter anderem festgelegt, dass der Zinssatz für Entgeltforderungen, an denen kein Verbraucher beteiligt ist, von acht auf neun Prozentpunkte über dem Basiszinssatz ansteigt. Diese Änderung ist anwendbar auf Schuldverhältnisse, die nach dem 29. Juli 2014 entstanden sind. Bei Forderungen aus Dauerschuldverhältnissen, die vor dem 29. Juli 2014 entstanden sind, deren Gegenleistungen aber erst nach dem 30. Juni 2016 erbracht werden, kann der neue Satz ebenfalls verwendet werden.

Die Umstellung der Vorgabe für neue Zinsdefinitionen können Sie in IKAROS in den Stammdaten der Gläubiger vornehmen. Bitte prüfen Sie auch, ob ggf. Änderungen in Importkonvertierungen durchgeführt werden müssen. Das ist z. B. der Fall, wenn Sie Forderungen bekommen, bei denen evtl. abweichende Zinssätze beachtet werden müssen.

Zudem haben Gläubiger Anspruch auf eine Pauschale in Höhe von 40 €, wenn auch hier kein Verbraucher beteiligt ist. Hier ist jedoch zu beachten, dass laut Gesetz „die Pauschale […] auf einen geschuldeten Schadensersatz“ anzurechnen ist, „soweit der Schaden in Kosten der Rechtsverfolgung begründet ist“. Wir klären augenblicklich, ob entsprechende Unterstützung in IKAROS benötigt wird und wie diese aussehen kann. Sie können hier gerne Ihre Meinungen und Kommentare dazu hinterlassen.

Sobald neue Erkenntnisse zu diesem Thema vorliegen, werden wir Sie hier entsprechend informieren.


Einführung der EDA-Version 4.1.0 für Kosten-/Erlassnachrichten zum MB und für Widerspruchsnachrichten

Wir weisen darauf hin, dass die zentralen Mahngerichte ab dem 01.01.2014 Kosten- und Erlassnachrichten zum MB sowie Widerspruchsnachrichten im neuen EDA-Format 4.1.0 liefern.

Die genannten Nachrichten werden ab dem 01.01.2014 zusätzliche Informationen über zulässige Rechtsmittel beinhalten.

Zur Lieferung dieser Informationen sind die Gerichte durch das Gesetz zur Einführung einer Rechtsbehelfsbelehrung im Zivilprozess verpflichtet (vgl. BGBl I 2012 S. 2418). Die Rechtsmittelbelehrung enthält Informationen zur Art und Frist des Rechtsmittels, der zugrundeliegenden Gesetzesnorm, sowie zu den Gerichten, bei denen das Rechtsmittel angebracht werden kann.

Die Versionen 2.7 Patch 7, 2.8 Patch 5, 2.9 Patch 2 und 2012.1 Patch 8 sind bereits seit einiger Zeit verfügbar und ermöglichen die Verarbeitung der genannten Nachrichten. Die Version 2013.1 Patch 2 erscheint in der KW 51 und wird ebenfalls die nötige Unterstützung bieten.

Bitte beachten Sie, dass das Einspielen der Patches zwingend nötig ist, um ab dem 01.01.2014 Kosten-/Erlassnachrichten zum MB sowie Widerspruchsnachrichten mit IKAROS-GMV einzulesen und nach IKAROS zu übernehmen.

Bitte beachten Sie weiterhin, dass die Rechtsmittelinformationen in den Versionen 2.7 Patch 7, 2.8 Patch 5 und 2012.1 Patch 8 nicht nach IKAROS übernommen werden. Diese Versionen stellen lediglich sicher, dass die genannten Nachrichten fehlerfrei verarbeitet werden können. Erst die Versionen 2.9 Patch 2 und 2013.1 Patch 2 bieten volle Unterstützung für die Rechtsmittelinformationen (Anzeige und PROSA-Zugriff).

Alle aufgezählten Versionen können die genannten Nachrichten weiterhin auch im alten Format verarbeiten (EDA 4.0.0).

Gern unterstützen wir Sie beim Update auf diese Versionen.

Software-Entwicklung mit und nach SCRUM, Teil 2: SCRUM kurz und knapp

Dieser Blog-Eintrag ist eine Fortsetzung des ersten Teils über SCRUM.

Die Umsetzung der Prinzipien Transparenz, Überprüfung und Anpassung wird in SCRUM durch folgende Elemente abgebildet:

Rollen:

  • Der Product Owner gibt die fachliche und strategische Ausrichtung des Produkts vor.
  • Das Entwicklungs-Team setzt die Vorgaben des Product Owners um.
  • Der SCRUM-Master ist für das Gelingen des SCRUM-Prozesses verantwortlich. Er arbeitet mit dem Product Owner und dem Entwicklungsteam zusammen, gehört aber nicht dazu. Er beseitigt Probleme, die den Fortschritt des Projekts verhindern und achtet darauf, dass alle Projektteilnehmer nach den Regeln spielen.

Artefakte:

  • Im Product Backlog hält der Product Owner in Form von User Stories, also Beschreibungen aus Benutzersicht, Anforderungen an sein Produkt fest.
  • Im Sprint Backlog ist, für jedes Team-Mitglied ersichtlich, der aktuelle Projektstatus festgehalten. Das Sprint Backlog beinhaltet unter anderem abgeschlossene und offene Aufgaben sowie den Fortschritt in Form eines Burndown-Charts.
  • In der Impediment-Liste werden Probleme festgehalten, die das Team bei der Arbeit behindern. Es ist Aufgabe des SCRUM-Masters diese Probleme zu beseitigen.

Der Ablauf von SCRUM ist durch seine Zeremonien definiert:

  • Ein Sprint beschreibt einen festen Zeitraum von mindestens zwei, maximal vier Wochen, in denen ein Produkt entwickelt wird. Ziel eines Sprints ist immer ein „potentially shippable Product“, also ein Produkt, das soweit gereift ist, dass es theoretisch mit der neuen Funktionalität an Kunden herausgegeben werden kann und einen Mehrwert bietet.
  • Im Sprint Planning wird durch den Product Owner und das Entwicklungs-Team zunächst festgelegt, welche User-Stories im kommenden Sprint umgesetzt werden. Der Product Owner stellt die von ihm hoch priorisierten Stories vor. Dabei schätzt das Team die Größe der User-Stories und wie viel in einem Sprint umgesetzt werden kann. Im zweiten Teil des Meetings, das nun ohne den Product Owner stattfindet, legt das Team anschließend fest, wie die gewählten Stories umzusetzen sind. Die einzelnen Stories werden in Tasks aufgebrochen und im Sprint umgesetzt.
  • Das Daily Scrum findet jeden Morgen während des gesamten Sprints statt und dauert nicht länger als 15 Minuten. Während des Daily Scrums erklärt jedes Mitglied des Entwicklungs-Teams, was es am Vortag getan hat, was es plant am aktuellen Tag zu tun und ob es Hindernisse bei der täglichen Arbeit gibt, die vom Scrum-Master beseitigt werden müssen. Das Sprint Backlog und die Impediment-Liste werden entsprechend aktualisiert.
  • Das Sprint Review findet am Ende eines Sprints statt. Das Entwicklungs-Team präsentiert dem Product Owner, ggf. auch einem Benutzer oder Auftraggeber, die Ergebnisse des vergangenen Sprints. Der Product Owner bewertet und beurteilt die Ergebnisse. Es wird überprüft, ob die im Sprint Planning gesteckten Ziele im Sprint erreicht worden sind. Bei der Bewertung werden keine Kompromisse eingegangen. Eine User-Story aus dem Product Backlog gilt erst dann als abgeschlossen, wenn sie die „Definition Of Done“, einer vor Umsetzung festgelegten Menge von Anforderungen, entspricht. Sollten User-Stories nicht vollständig abgeschlossen sein oder Änderungsbedarf bestehen, so kann der Product Owner sie zurück ins Product Backlog aufnehmen und neu bewerten.
  • Im Sprint Retrospective, welches zwischen Sprint Review und Sprint Planning stattfindet, reflektiert das Team gute und schlechte Erfahrungen, die während des letzten Sprints gemacht worden sind. Das Sprint Retrospective soll dem Entwicklungs-Team die Möglichkeit geben, aus diesen Erfahrungen zu lernen.

Alle Zeremonien in SCRUM sind „time-boxed“, das bedeutet, dass sie für einen fest angegebenen Zeitrahmen angesetzt sind, der nicht überschritten werden darf. Es ist Aufgabe des Scrum-Masters auf die Einhaltung des Time-Boxing zu achten. Dadurch sollen endlose Diskussionen und Verstrickungen in Details vermieden werden.

Lesen Sie im folgenden dritten Teil, wie SCRUM bei Ferber-Software zum Einsatz kommt und was wir bisher für Erfahrungen damit gemacht haben.

Software-Entwicklung mit und nach SCRUM, Teil 1: Motivation

Das klassische Projektmanagement in der Welt der Software-Entwicklung, z.B. nach dem Wasserfall- oder V-Modell, hat diverse Schwachpunkte. Die Planung eines Projekts beruht auf Schätzungen und Nebenbedingungen (man bezeichnet sie auch als „Unbekannte“), die sich während eines Projekts ändern. Das kann dazu führen, dass kurzfristig Planungen angepasst oder komplett geändert werden müssen. Im schlimmsten Fall wird die komplette Planung obsolet.

Dies ist der Ansatzpunkt und Grundgedanke von SCRUM: Ein Projekt ist aufgrund vieler Unbekannter zu komplex, um es vom Start bis zum Abschluss komplett durchplanen zu können. Wenn sich die Unbekannten – und damit wahrscheinlich auch Anforderungen – ändern, muss kurzfristig darauf reagiert werden können, unabhängig davon, was ein Projektplan vorschreibt. Man bezeichnet SCRUM daher auch als ein Vorgehensmodell zur agilen Softwareentwicklung.

SCRUM versucht, den Schwachpunkten des klassischen Projektmanagements mit drei Prinzipien entgegenzutreten:

  • Transparenz: Wissen bzgl. Projektfortschritt und Hindernissen wird täglich im Team gestreut.
  • Überprüfung: Projektergebnisse und Funktionalitäten werden regelmäßig abgeliefert und bewertet.
  • Anpassung: Anforderungen werden nicht festgeschrieben, sondern können nach jeder Lieferung von Projektergebnissen neu angepasst und bewertet werden.

Festgehalten sind diese Prinzipien im Agilen Manifest:

Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Lesen Sie im folgenden zweiten Teil, wie sich diese Prinzipien in Form von Rollen, Artefakten und Zeremonien in SCRUM darstellen.

Neuerungen in IKAROS enterprise

IKAROS enterprise 2011.3 zeichnet sich durch mehrere funktionale Verbesserungen aus. Neuerungen bei der Generierung der Postausgangsdokumente, Gläubigerwechsel, Adressgültigkeiten sowie die Dynamisierung der Begrenzung von Konten in Verrechnungsfolgen sind ebenso enthalten wie Neuerungen im Import. Die wichtigsten Neuerungen finden Sie im Nachfolgenden PDF in Kurzform aufgelistet.

IKAROS 2011.3 Vorteile

Open Playground

Am 23. und 24. März fand in den Abteilungen Entwicklung und Technische Innovation zum ersten Mal der Open Playground statt.

Die Idee hinter dem Open Playground ist, dass sich die Teilnehmer in kleinen Teams mit Themen aus der IT-Welt befassen können, die sie interessiert, denen sie aber im Arbeitsalltag nicht begegnen. Die Teilnahme ist freiwillig. Alle Teilnehmer werden für die Zeit des Open Playground vom Alltagsgeschäft freigestellt, so dass sie ungestört an ihren Themen arbeiten können. Am zweiten Tag werden die Ergebnisse der einzelnen Arbeitsgruppen vorgetragen.

Insgesamt haben sich am ersten Open Playground acht Teilnehmer mit fünf Themenbereichen beschäftigt: Portierung von .NET nach Mono, Skalierbarkeit von Java unter Sybase SQL Anywhere, Swimlanes im IKAROS-Workflow-Management, Microsoft SQL-Server 2012 und App-Entwicklung für iOS.

Die Ergebnisse der Teams werden nun von den Mitgliedern unseres Innovationskreises ausgewertet und ggf. weitere Schritte festgelegt. Möglicherweise legen die gewonnenen Erkenntnisse Grundsteine für zukünftige Entwicklungen in IKAROS.

Alle Teilnehmer waren sehr zufrieden und haben sich für eine Wiederholung des Open Playground ausgesprochen. Jeder war mit Elan bei der Sache und es hat allen viel Spaß gemacht.

Update: Das Datum des Open Playgrounds wurde korrigiert.