Requirements Analysis

Description

A user creates a PO and POL, the price is recorded in a foreign crrency. The following errors occur when the user processes the invoice to this PO/POL:

Scenario 1: Invoice will be processed in primary currency (= system currency = EUR)

• User creates POL and enters the amount/price in a foreign currency
• The system calculates the encumbered amount in the primary (=system) currency - this will be displayed as encumbrance in the finance app as transaction
• The user creates an invioce and invoice line for the POL - when linking the POL, the system displays the original amount in foreign currency but displays it as amount in primary currency - only a EUR sign is attached to the original pricein foreign currency and thus further calculated
• The correct amount from encumbrances (finance app) is not used → 
• The further calculation is therefore based on the original price - just with primary currency → The correct amount from the encumbrance is not used
• The payment is therefore incorrect

Szenario 2: Rechnung wird in Fremdwährung (z.B. GBP) bearbeitet

• Nach dem Anlegen des Rechnungsposten erfolgt die korrekt Übernahme der Beträge aus dem Bestellposten, d.h. es wird mit dem korrekten Bindungsbetrag aus der Finanz-App weitergerechnet
• Allerdings können Zusatzkosten nicht in der Primärwährung (EUR) abgerechnet werden
  • darunter zählen Mehrwertsteuer, Frachtkosten usw.
• Währungsdifferenzen können nicht in Primärwährung (als Zusatzkosten o.ä.) ausgeglichen werden.
  • Es besteht zwar die Möglichkeit, den Rechnungsbetrag durch die Anpassung des Wechselkurses, der i.d.R. erst ausgerechnet werden muss, zu aktualisieren. Das ist allerdings in der Praxis sehr umständlich.

Allgemeines Problem:

• In der Rechnung wird entweder der Primär- oder der Fremdwährungspreis angegeben
• Wichtig wäre es, beide Preise sehen zu können. Insbesondere für statistische Erhebungen hinsichtlich Preisentwicklung und Tendenzen. 

Benötigte Felder und Funktionen

• Szenario 1: bei der Rechnungsbearbeitung sollte der Bindungsbetrag aus der Bestellung zur Weiterberechnung verwendet werden

• Szenario 2: beim Hinzufügen von Zusatzkosten sollte die Möglichkeit bestehen, eine Währung auszuwählen oder wenigstens die eingestellte Primärwährung verwenden zu können
• Allgemein: Transparentere Darstellung des Originalpreises (Fremdwährung) und des tatsächlichen Rechnungspreises → eventuell zusätzliches Feld Originalpreis 
• Bei Auswahl des Status "Überprüft" →
  • Ausgabe der tatsächlichen Beträge (zusätzlich in Zielwährung)
  • Rechnungsbetrag hat dann den Status "zur Bezahlung vorgesehen" in der Budgetübersicht der FinanzenApp
  • Vorteil: alle Daten der Rechnung können noch geändert werden
  • alternativ: neue zusätzliche Aktion: Prüfen - als Funktion vor Freigeben und Bezahlen
• Ausgabe der tatsächlichen Beträge (Gesamtpreis und Zusatzkosten) auf der Rechnung, Rechnungsposten, auf der Bestellung bei verknüpften Rechnungen
• Möglichkeit Betrag in Fremd- und Primärwährung anzugeben → das System soll dann den Wechselkurs ausrechnen
• Listenpreis (in Originalwährung) als separates Feld auf Rechnungsposten ausweisen → Mehrwert für Reports | speziell für Scenario 1

Aufgaben

• ...

Weitere Informationen

Anforderungsanalyse

• ...

Relevante Funktionsanalysen

• Beispiel Fremdwährung

Besprechung in einer D-Gruppe/SIG

• 2023-07-12 Besprechungsnotizen Erwerbung

• 2023-08-09 Besprechungsnotizen Erwerbung

• 2023-09-06 Besprechungsnotizen Erwerbung

Relevante vorhandene Jira-Tickets