projekt kivitendo

EmailJournalAttachment: FIX: entferne nicht genutzten Import

S:D:Order::TypeData: Typenreihenfolge angepasst

TypeData: Füge Übersetzung für Typ hinzu

SL::DB::Helper::ZUGFeRD: FIX: fehlendes use

Workflow: E-Mail → Angebot/Auftrag

S:D:Reclamation: Nutze TypeData zum bestimmen ob VK/EK-Reklamation

EmailJournal: Zusätzlicher Type für Beleg-Importe

EmailJournalAttachment: Funktion um Datei zum Beleg hinzufügen

ImportRecordEmails: BJ zum importieren von Emails als Beleg-Grundlage

Verallgemeinerung und Ersetzung von BJ "ImportPurchaseInvoiceEmails"

FIX: EmailImport: korrigiere EmailJournal-Key zu email_journals

EmailJournal: ZUGFeRD-Emailanhänge in Kreditorenbuchen konvertieren

ZUGFeRD: Kreditorenbuchung direkt aus ZUGFeRD-XML erstellen

S:D:H:RecordLink: FIX: mehrere Ursprungsbelege unterstützen

FIX: DeliveryOrder: Setze Aufträge auf geliefert

Order: Nutze Type und ID zum Erstellen von verknüpften Belegen

FIX: S:D:H:RecordLink: Belegpositionen können aus verschieden Belegen kommen

S:D:H:FlattenToForm: Bestätigungsnummer des Lieferanten

WF Lieferantenauftragsbestätigung->EK-Lieferschein: Auftragsnummer mitnehmen

Die Nummer des Vorgängerauftrags wird im LS eingetragen.
Die Nummer der Bestätigung ist weiterhin über Verknüpfungen verfügbar.

Lieferantenauftragsbestätigung: Nummernbezeichnung in Makse geändert.

Und Anzeige der Vorgänger-Auftragsnummer

EK-Lieferschein: Nummer der Lieferantenbestätigung in Maske anzeigen

Die Nummer wird aus den Verknüpfungen geholt.

Lieferantenauftragsbestätigung: Bestätigungsnummer des Lieferanten: Maske und WF

Lieferantenauftragsbestätigung: Bestätigungsnummer des Lieferanten (DB+Rose) …

… bei Aufträgen (oe) und Lieferscheinen

Lieferantenauftragsbestätigung: Nicht drucken, nicht per Mail verschicken.

Erscheint mir beides hier nicht sinnvoll.
Funktionalität ist aber da; Druckvorlagen fehlen noch.

Kosmetik: Ausrichtung

Lieferantenauftragsbestätigung: Verknüpfte Belege

Kosmetik: Ausrichtung

Lieferantenauftragsbestätigung: S:D:Order:new_from

S:D:Order:Typedata: Kosmetik: Ausrichtung

Lieferantenauftragsbestätigung: DB-Type order_types

Lieferantenauftragsbestätigung: S:C:Order:TypeData

S:D:H:TransNumberGenerator: Kosmetik: Ausrichtung

Lieferantenauftragsbestätigung: DB und Nummernkreis

S:D:Order: new_from: Workflow-Abkuerzungen prüfen

S:D:Order: Fix: new_from: falsche Workflow-Abkürzung f. Angebots-Eingang

DisplayableNamePrefs: preferences nicht in Package-Variable speichern.

Dort bleiben die Werte bei fcgi auch über einen Request erhalten, somit auch
beim Benutzerwechsel. Das führte dazu, dass andere Einstelungen als die
eigenen verwendet werden konnten.
...

DisplayableNamePrefs: Typos im POD

fix: mehr SL::DB zirkuläre includes

fix: kein use SL::DB in SL::DB

fix: kein explizites use SL::DB in SL::DB

EK von Erzeugnissen und Sortimenten setzen: Artikel nicht cachen.

Wenn hier die Erzeugnisse oder Sortimenten gechached werden, dann kann
es passieren, das die Preise nicht richtig summiert werden, wenn sich in
einem Request die Preise mehrerer Bestandteile ändern (z.B. EK-Rechnung)....

S:D:Part: letztes Preise-Update: neben Datum auch nach Id sortieren, …

… sonst kommt ein evtl. ein falsches (nicht das letzte) letzte Preis-Update
zurück, wenn der Zeitstempel gleich ist.

Preisfaktor mit in Preishistorie aufnehmen: DB und Rose

sql-update und rose für Zolltarifnummer

Erzwungener Layout-Stil: Mandantenkonfiguration

Möglichkeit, den sonst automatisch ermittelten Stil vorzugeben
für erzwungenes Layout (Desktop/Mobil).

Dispostionsmanager Controller an record_type angepasst

DispositionManager: FIX: teste zuerst ob Wert definiert ist

DispositionManager: Fehlermeldung bei doppelter Bestellung von Artikeln

DispositionManager: Zeige keine Lieferanten-Artikel die im Warenkorb sind

DispositionManager: Lieferschein beim Erstellen nicht automatisch speichern

Part: um Helferfunktionen für den Warenstand erweitert

PurchaseBasketItem: Datenbankscript und DB-Dateien

Positionsebene für den Einkaufskorb

Besteller zu Auftrags- und Lieferscheinpositionen hinzugefügt

Part: Bestellmenge hinzugefügt

S:D:BankTransaction: Quotemeta in Regex für Depositor

S:C:DeliveryOrder: Workflow zu Rechnung und Reklamation hinzugefügt

DeliveryOrder: Weiteren Link auf neuen Lieferschein-Controller zeigen lassen

Workflow Auftrag → Lieferschein auf neuen Controller umgestellt

S:D:Order:TypeData: Unterversionen: Flag überall aus Mandanten-Konfig.

S:D:Order: Typo

S:D:Order:TypeData: Texte für Auftragsbestätigung verdeutlicht.

Anpassung nach Record-Controller/Rebase

Model::Record: Nutzte record_type für Erstellung aus Workflow

S:D:Order: Hooks sollen truish zurück liefern, wenn alles ok ist.

S:D:Order: mini-Optimierung für Methoden intake und quotation

S:D:Order: is_sales und customervender verwenden TypeData

S:D:Order: Auftrags-Eingäng schließen, wenn AB erstellt

Wenn eine AB gespeichert wird und im vorhergehenden Workflow ein
AE vorhanden ist, so wird der AE geschlossen.

Umsetzung als after-save-Hook.

Anpassung nach RecordController/Rebase

Model::Record: FIX: Workflow Angebots- und Auftrags-Eingänge

Model::Record: Workflow zu Angebots- und Auftrags-Eingänge eingefügt

S:D:Order:TypeData: Zugriff auf Instance-Conf. gefixt

S:D:Order:TypeData: Daten für Angebots- und Auftrags-Eingänge

DB::DeliveryOrder: Nutze record_type

anstelle order_type

DeliveryOrder: nicht genutzter Code entfernt

Model::Record: Helferfunktion für Typ zu Klasse von Record Objekten

Order::TypeDate: fix typo

Order: nutze TypeData

Angebotsflag/Intakeflag aus Datenbankzugriffen entfernt

DB::Order: is_sales verwende record_type

DB::Order: Funktionen angepasst (kein Angebotsflag/Intakeflag)

Reclamation: nutze Record-Type

Order: nutze Record-Type

DB::DeliveryOrder: Persistenter Record-Type

Verändere oder_type zu record_type als Enum

DB::Reclamation: Persistenter Record-Type

DB::Order: Persistenter Record-Type

Model::Record: TypeData-Feature Unterversionen

LinkRecord: close_quotations nicht mehr im link record post save hook ausführen

Das war Teil der link_record behandlung, ist aber so unintuitiv, dass es
jetzt vom Controller an den Model::Record gegeben wird.

TypeData: fix füge Ordertypes zu DB::Reclamation hinzu

TypeData: nutzte Konstanten anstatt String für Typen

Reclamation TypeData: delete text

TypeData: features

RecordLink: typo

DeliveryOrder: TypeData jetzt über proxy eingebunden

Macht den Controller proxy unnötig. reqdate default werden jetzt anders
behandelt

DO::TypeData: nicht mehr benötigte stock_transfer daten

TypeData: verschiebe get_new_reqdate nach defaults->reqdate

Model::Record: move get_new_reqdate to TypeData

TypeDataProxy: _via

TypeData: typo in reclamation

TypeData: proxy um $record->type_data benutzen zu können

TypeData: Reclamation

TypeData: Order

TypeData: unnötige imports

DB::DeliveryOrder: entferne nicht genutzten Wert