projekt kivitendo

Swiss QR-Bill: Datenbankupgrade: Spalte für Optionales Feature Rechnungsnummer automatisch in unstrukturierte Mitteilung kopieren

Auswahlliste Skonto soll keinen Fehler an der Oberfläche werfen

POD Anpassung für neue Parameter bei pay_invoice

Wechselkurs-Optimierung: Kosmetik weiter aufräumen

Payment-Helper: Debugs raus, Kosmetik

Nicht alle Charts müssen Links haben (bspw. gain_loss)

Payment-Helper: Warnungen, striktere regex, vorheriges Mult. Verfahren

Das Vorzeichen über is_sales für fx_gain_loss zu setzen ist doch
korrekt und liefert die richtigen Zuordnungen. Regex richtig setzen
und auf initialisierte Werte Prüfung, für tests

Payment-Helper: Wechselkursgewinn und -Verlust mit ungerundetem Betrag berechnen

Payment-Helper mehr Parameter prüfen (Testfall)

Wechselkurs beim Bankauszug verbuchen.

> Testfälle i.O. (bank_transaction.t)
> manuelle Prüfung fast i.O. (sechs Fälle) Rundungsdifferenzen
> Debugs n.i.O.
> automatisierte Testfälle n.i.O.

Zustand für negative Kreditorenbuchung oder EK-Rechnung als invoice_type hinzufügen

Entsprechend bei Wechselkursgebühren ausklammern

Wechselkurs verbuchen erstmal nicht mit Skonto-Verbuchen komibinierbar

Testfälle Verkaufsrechnung Nebenbuch und Bankzuweisung i.O. Debugs drin

Bei Wechselkursverlusten entsprechend im Nebenbuch abziehen und bei
Gewinnen addieren. Rückgabewert an Bankzuweisung auch summieren

Zu: Rückgabewert für invoice_amount auch wirklich aufaddieren. Fallunterschiede

Falls ein Dialogbuchung gemacht wird, diese berücksichtigen.
Falls der neu berechnete Betrag kleiner als vorher ist und die
Bank weniger bezahlt, entsprechend auch nur das ausbuchen....

fx_loss doch erstmal ignorieren für invoice_amount

Rückgabewert für invoice_amount auch wirklich aufaddieren. Ferner ...

... Wechselkursgewinne auch im Nebenbuch erfassen.
OFFEN: erneuter manueller Test

wip: REMOVE Wechselkursberechungen geändert in Payment-Helper

pay_invoice git als ersten Wert den zugewiesenen Betrag der Bankbuchung zurück

Payment-Helper: neue Methoden f. Wechselkurs, Bankgebühren:

get_exchangerate: Holt den Belegwechselkurs oder den Tageswechselkurs
get_exchangerate_for_bank_transaction: Holt den Wechselkurs zum Valutatag
einer Bankbewegung...

pay_invoice git als ersten Wert den verbuchten Betrag der Bankbuchung zurück

Payment-Helper exchangerate nicht mehr exportieren

Beißt sich mit dem DB-Eintrag

AR,AP und BankTransactions können eigenen Wechselkurs haben

S/D/H/Payment zwei Methoden leicht überarbeitet

get_payment_select_options_for_bank_transaction
> unnötige %params und test auf skontoable entfernt
> direkt auf Typ anstatt auf definiert prüfen

skonto_date
-> direkt auf Typ anstatt nur auf definiert prüfen

S/D/H/Payment check_skonto_configuration entfernt

S/D/H/P: New call to within_skonto. POD edited.

S/D/H/Payment Kosmetik

S/D/H/Payment: within_skonto_period umgeschrieben auf Params::Validate

Payment-Helper: subtilen toten Code entfernt

Aufruf über SEPA.pm war 'eigentlich' schon immer überflüssig

Payment-Helper: offensichtlich toten Code (Methoden) entfernt

Ferner einen Bug in einer Methode gefixt, die aber auch nie
richtig verwendet worden ist.

Refs #490: Lieferschein: entferne alle Verweise auf 'is_sales'

Gültigkeitstoken: Dialogbuchung

S:D:H:Mappings: doppelten Hash-Key ap entfernt

Gültigkeitstoken Einkaufsrechnung

Gültigkeitstoken Reklamationscontroller

S:D:DeliveryOrderItem: Carp-Modul einbinden für croak

Gültigkeitstoken Auftragscontroller

Gültigkeitstoken Lieferscheine (alter Controller)

zu Revert "Rechnungsmaske: "Browser-Zurück verhindern" konfigurierbar in Mandantenkonfig"

DB+Rose

S/D/MetaSetup/Defaults: erneut gebaut (andere Reihenfolge)

Beistelllieferschein/DeliveryOrder Lagerbuchungen mit in die Druckvariablen aufgenommen

Controller: DeliveryOrder: stock_dialog um Einlagern erweitert (WIP)

DeliveryOrderType richtig setzen

Reclamation: add billing_address_id to reclamation

Reclamation: Test for workflow invoice_to_reclamation

Reclamation: Test for workflow (reclamation, order, delivery_order)

Reclamation: set record_links automatic after reclamation->save

PriceTaxCalculator: adjusted for record items without marge fields

Reclamation: don't need shipped_qty

Workflow: sales_reclamation → credit_note

Workflow: (sales/purchase) invoice → reclamation

Workflow: delivery_order ↔ reclamation

Workflow: order ↔ reclamation

Reclamation: Controller and Templates created

also for ReclamationReason

Changes in SL/DB/Shipto.pm, SL/DB/Helper/TransNumberGenerator.pm,
    SL/Controller/File.pm and SL/Webdav.pm for Reclamation

Links in menus added for:
      - Reclamation/add...

Added alias record_id to order_item and delivery_order_item

Reclamation: add default settings

Reclamation: sql-script for data tables and rose objects added

Also created all needed functions in SL/DB/Reclamation.pm,
    SL/DB/ReclamationItem.pm and SL/DB/ReclamationReason.pm

Fehlerhafte MetaSetup/Default.pm (projektattribute) wieder entfernt

Belegweise E-Mail-Absender-Adressen

SEPA-Überweisungen sperren könnnen (Einkauf): DB und Rose.

Artikelbeschreibung bei Lieferantenartikelnummern: DB und Rose

Artikel als neu Speichern auch BDVs und Übersetzungen vom Vorgänger

E-Mail für Mahnungsempfänger hinterlegen

Payment-Helper um Rückgabewert invoice_amount für bank_transaction ergänzt

Testfälle und Anmerkung zu exchangerate

Swiss QR-Bill: Datenbankupgrade: Spalte für unstrukturierte Mitteilung in Rechnung hinzufügen

Nummerkreise für Artikel, eindeutig ja, aber auch eigenständig

Ansonsten werden Erzeugnis oder Sortimentsnummer einfach aus
den Warennummernkreis befüllt. Richtige Analyse in 5fcefdf78916e0bd3,
aber beide Anforderungen können in dem Helper erfüllt werden

S/D/Order new_from reqdate je nach Beleg-Typ und Konfig setzen

offen: Aktuell wird der Einkauf exakt wie der Verkauf behandelt
ggf, genauer differenzieren. Wobei der vorherige Standard
(next_working_day) wahrscheinlich auch nicht passt.

Auftragszentrische verknüpfte Belege: Optionen in Mandantenkonfiguration

- Beleg selber mit in der Liste Anzeigen
- Verkaufsangebote mit in der Liste Anzeigen

Auftragszentrische verknüpfte Belege überarbeitet

- alle über den Auftrag gefundenen Verknüpfungen sind mindestens
zwei Verknüpfungen weiter entfernt
- auch die Verknüpfungen in die Richtung "to" (also vom Beleg weg)
werden angezeigt
- Möglichkeit, um auch Verkaufsangebote zu liefern, die vor dem Auftrag...

Auftragzentrische verknüpfte Belege: Funktionsnamen deutlicher (Verkaufsaufträge)

Auftragzentrische verknüpfte Belege: Routine aus Controller in Helper verschoben

S:D:H:LinkedRecords: Pod: kleine Korrekturen

Update von ALLAuth-DB-Helper

Payment-Helper: Fall Anzahlungsrechnung nicht das Transferkonto als ARAP finden

Das Transferkonto hat auch den Typ AR was bei Anzahlungsrechnungen
dann dazu führt, dass entweder Sammelkonto Debitoren oder das
Verrechnungskonto für Anzahlungen gefunden wird.

Swiss QR-Bill: Beim Filter für Bankbuchungen bzw. Kontenabgleich QR-Referenz berücksichtigen

Swiss QR-Bill: Datenbankupgrade: QR-Referenz in Banktransaktionen hinzufügen

Payment-Helper: Wechselkursgewinn und -Verlust nur mit Wechselkurs berechnen

Swiss QR-Bill: Datenbankupgrade: QR-Referenz in Rechnung speichern

Hintergrund-Job: Fehler als Text bei Historie im Fehlerfall

Der Fehler kann hier auch z.B. eine Exception-Klasse sein, je nachdem,
was der Hintergrund-Job so als Fehler wirft.

Neue Belegmethode netamount_base_currency

• für Angebote und Aufträge und Lieferscheine in der Fremdwährung
• für EK- und VK-Rechnungen in der Hauptwährung.

Um in bestimmten Berichten, die auf mehrere Belege zugreifen (z.B. Finanzübersicht),...

Wiedervorlagen: Rose-Beziehung zu Tabelle mit Abschluss-Infos (done)

Wiedervorlagen: Mehr Infos über Abschluss speichern: DB-Upgrade-Skript und Rose

Gespeichert wird Benutzer und Datum des Abschlusses. Der Benutzer kann
leer sein, da diese Information in schon existierenden Wiedervorlagen nicht
vorhanden ist.
Bei der Migration existierender Wiedervorlagen wird das Abschlussdatum auf...

Wiedervorlagen: Rose-Beziehung zu Mitarbeitern

Wiedervorlage für mehrere Benutzer: DB-Upgrade und Rose

SL::DB::Order>new_from: mini-Refactoring

gleichen Code zusammen gefasst.

Auftrags-Controller: WF Kunden-Angebot/-Auftrag -> Preisanfrage

Auftrags-Controller: WF Preisanfrage -> Kunden-Auftrag

Auftrags-Controller: WF Preisanfrage -> Kunden-Angebot

InvoiceItem: Rose-Manager-Klasse wg. Sorted-Helper

DeliveryOrderItem: Rose-Manager-Klasse wg. Sorted-Helper

Angebot/Auftrag Status: Feld in Tabelle für Angebote/Aufträge: DB und Rose

Angebot/Auftrag Status: SimpleSystemSettings zum Anlegen und Verwalten

Angebot/Auftrag Status: DB-Upgrade und Rose

Unterversionen: Methode zum Prüfen, ob finalisierte Version, leicht vereinfacht

ShopOrder: invoice_mail richtig übernehmen

OrderVersion auch in ALL.pm

Unterversionierung über Mandantenkonfiguration aktivierbar

Unterversionen für Angebote/Aufträge

Versionen werden finalisiert sobald sie per E-Mail rausgeschickt wurden
Danach ist die Bearbeitung gesperrt, aber es ist möglich eine neue
Unterversion des Belegs zu erstellen.
Unterversionen bekommen den Postfix -x, wobei x:= 2 .. n...

Hilfstabelle oe_version erweitert

Rose-DB OrderVersion - Hilfstabelle zum Versionisieren von Orders

proof of concept: Formular-Gültigkeit beim Buchen von Verkaufsrechnungen

Ziel: verhindern, dass eine noch nicht gebuchte Rechnung durch
Verwendung des »Zurück«-Buttons im Browser mehrfach gebucht werden
kann.

Implementation: Beim Neuanlegen einer Rechnung wird ein einmaliges...