Konzept mobile Plattform

Vorwort

Perspektivisch soll es möglich sein, Fakturama auch mit mobilen Endgeräten nutzen zu können. Da die Plattform allerdings nicht dafür ausgelegt wurde ist eine Untermenge zu finden, die die wichtigsten und sinnvollsten Funktionen abdeckt.

Ziele

  • Einsatz von Fakturama beim Erfassen von Lagerbeständen
  • Einsatz beim Erstellen von Lieferscheinen direkt im Lager
  • Aufstellen von Kommisionierungslisten
  • Vorerfassen von Rechnungen oder Angeboten
  • Anzeigen von Rechnungen (Übersicht und Detail)
  • Anzeigen von Kontakten (Übersicht und Detail)

Hintergrund und strategische Eignung

Mit der zunehmenden Verbreitung mobiler Endgeräte wird auch der Wunsch zur Verwendung dieser Endgeräte immer öfter geäußert. Dem soll mit dieser Entwicklung entsprochen werden.

Annahmen

  • Zugriff von unterschiedlichen mobilen Plattformen (Windows Phone, Android, Blackberry, iPhone)
  • nicht alle Funktionen von Fakturama werden gebraucht (Drucken, Datenexport- oder -Import)

Anforderungen

 
LoginAnmeldung an der AnwendungNotwendig
  • zunächst nur Prüfung der Zugangsdaten, noch keine Rollen
Datenimport

Import der Daten von der Hauptanwendung (Datenabgleich)

  • Dokumente (Rechnungen, Lieferscheine, Auftragsbestätigungen usw.)
  • Kontakte
  • Produkte
  • Einstellungen (nur initial)
Notwendig
  • offen ist hier noch das Protokoll (REST / Socket), über das die Daten übertragen werden sollen (wobei eine lokale Verbindung aufgrund der Datensicherheit besser ist als eine über das Web)
  • bei Datenkonflikten ist der User zu fragen, welche Daten aktuell sind

Ein Abgleich mit dem Webshop ist hier erst einmal nicht vorgesehen, da das zu Dateninkonsistenzen führen könnte (außerdem ist das auch eine Frage der Datensicherheit).

Rechnungen

Anzeigen / Ändern von Rechnungsdaten

Wichtig
  • Anzeige einer Übersichtsliste (nach Fälligkeit sortiert anzeigen)
  • Anzeige einer OP-Liste
  • Detailanzeige mit Änderungsmöglichkeit
Kontakte

Anzeigen / Ändern von Kontaktdaten

Wichtig
  • Anzeige einer Übersichtsliste
  • Detailanzeige mit Änderungsmöglichkeit (nur evtl.!)
  • Möglichkeit, den Kontakt direkt anzurufen, falls Tel.-Nr. hinterlegt ist (bspw. wenn man Artikel persönlich zum Empfänger bringt und den irgendwie erreichen möchte), ihm eine Mail zu senden oder ihn auf der Karte anzuzeigen
  • statistische Daten mit anzeigen (bezahlte / unbezahlte Rechnungen, Anzahl Bestellungen usw.), ggf. in separatem Tab
Einstellungen

Konfiguration der Anwendung

  • Anzeige mit/ohne Kategoriebaum
  • mit/ohne Mengeneinheit
  • IP (und Zugangsdaten für den Abgleich) des Basisrechners
  • Firmendaten
WichtigDie meisten Einstellungen sollten schon von der Hauptanwendung mit übernommen werden. Gerade für das Ein- oder Ausblenden diverser Felder (Rechnungen, Kontakte) wäre das für ein einheitliches Erscheinungsbild sinnvoll. Die Einstellungen sollten sich aber nach dem Erstimport trotzdem ändern lassen.
Produkte
  • Übersicht Produkte (in Listenform)
  • Anzeigen / Ändern von Produktdaten
Notwendig

Hier ist vor allem zu berücksichtigen, daß man die App als Lagerverwaltungs-App benutzt und damit seine Bestände erfaßt. Ggf. könnte man hier (später) noch vorsehen, den Barcode gleich einzuscannen und die Artikelnummer daraus zu entnehmen.

Evtl. vorsehen, daß auch die Eigenschaften / Varianten des Produktes (Farbe, Größe usw.) mit angezeigt werden können. Die Preisstaffel sollte auch nur angezeigt werden, wenn sie auf dem Basissystem vorhanden ist. Zusätzlich noch Gewicht / Tara anzeigen.

Suchfunktion

Suche (Produkte, Dokumente, Kontakte)

Notwendig

Diese Funktion ist sehr wichtig, da gerade im Außeneinsatz schnell bestimmte Dokumente/Kontakte/Produkte gefunden werden müssen. Folgende Suchkriterien sind initial zu implementieren (weitere könnten folgen):

  • Produkte: Artikelnummer, Kurzbezeichnung
  • Kontakte: Kundennr., Name, Vorname, PLZ, Ort
  • Dokumente (Rechnungen): Dok.-Nr., Addressfirstline, ggf. enthaltene Artikelkurzbezeichnungen
Statistik und Infos

Anzeige diverser Statistiken, Info / About-Box

Nice to have

Zur Abrundung der Funktionen wäre es gut, wenn folgendes noch implementiert werden könnte:

  • offene / bezahlte Rechnungen (gesamt oder pro Kontakt)
  • Anzahl Kontakte (evtl. in welcher Kategorie)
  • Anzahl Produkte (evtl. in welcher Kategorie)

Die Listen sollten immer mit einer Sortierfunktion ausgestattet sein.

Benutzerinteraktion und -design

Übersicht und Detailseite Rechnungen

Fragen

Unten finden Sie eine Liste von Fragen, die aufgrund dieses Anforderungsdokuments angesprochen werden müssen:

 
Wie funktioiniert die Schnittstelle zur Hauptanwendung? Per REST oder per Socket-Verbindung? Hier sollte man auch bedenken, daß die komplette Anwendung auch mal in einem Browser laufen könnte (RAP) und dadurch sicher auch einiges an den Server-Schnittstellen getan werden müßte. 

Verworfen