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 Scenario 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

Invoice Processed in Foreign Currency (e.g., GBP)

• After creating the invoice line, the amounts from the purchase order line are correctly adopted, meaning the correct encumbered amount from the finance app is used.
• However, additional costs cannot be processed in the primary currency (EUR).
  • This includes VAT, freight costs, etc.
• Currency differences cannot be compensated in the primary currency (as additional costs or similar).
  • Although it is possible to update the invoice amount by adjusting the exchange rate, which typically must be calculated first, this is very cumbersome in practice.

General Problem

1. The invoice shows either the primary or the foreign currency price.
2. It is essential to see both prices, especially for statistical surveys regarding price development and trends.

Required Fields and Functions

Scenario 1:

• During invoice processing, the encumbered amount from the purchase order should be used for further calculations.

Scenario 2:

• When adding additional costs, it should be possible to select a currency or at least use the set primary currency.

General:

• More transparent display of the original price (foreign currency) and the actual invoice price – possibly an additional field for the original price.
• When selecting the status "Checked":
  • Output of actual amounts (additionally in the target currency).
  • The invoice amount then has the status "intended for payment" in the budget overview of the finance app.
  • Advantage: all data of the invoice can still be changed.
  • Alternatively: new additional action: Review - as a function before approving and paying.
• Output of actual amounts (total price and additional costs) on the invoice, invoice lines, on the purchase order for linked invoices.
• Option to specify amounts in both foreign and primary currency – the system should then calculate the exchange rate.
• List price (in the original currency) as a separate field on invoice lines – added value for reports, especially for Scenario 1.

Tasks

• ...

Additional Information

• ...

Relevant Functional Analyses

• Beispiel Fremdwährung

Discussion in a D-SIG

• 2023-07-12 Besprechungsnotizen Erwerbung
• 2023-08-09 Besprechungsnotizen Erwerbung
• 2023-09-06 Besprechungsnotizen Erwerbung

Relevant existing Jira

Tickets

• ...