Changelog
= Neue Funktion
= Verbesserung
= Fehlerbehebung
|
Typ |
Bereich |
Beschreibung |
| |
Sendungssymbole
|
Die Symbole für Coloading sowie SubMaster- und SubHouse-Sendungen wurden in den Übersichten für Luft- und Seefracht-Export und -Import sowie in der Home View optisch überarbeitet. Auch die Symbole für Sendungen light und Buchungen wurden in der Home View aktualisiert. Eine überarbeitete Übersicht der Scope-Symbole finden Sie unter
|
| |
Sanktionslistenprüfung |
Der Dialog zum Festlegen einer Ausnahme bei der Sanktionslistenprüfung verfügt jetzt über ein Freitextfeld für Bemerkungen. Dort können Sie optional die Begründung für die Ausnahme dokumentieren. |
|
Sanktionslistenprüfung |
Neue Symbole machen den Status der Sanktionslistenprüfung leichter erkennbar. Verbotssymbol für ein aktuelles kritisches Prüfergebnis: |
| |
Sendungsauftrag-Schnittstelle | Fehler bei der Verarbeitung von Container- und Güterdaten in den kürzlich eingeführten Versionen 4.0 und 4.1 der Schnittstelle für eingehende Sendungsaufträge korrigiert. |
|
Typ |
Bereich |
Beschreibung |
| |
Air Export | Unter Stammdaten > Luftfracht > Konsolflugplan Vorlagen können Sie jetzt über das Menü „Neu“ eine neue Vorlage auf Basis der ausgewählten Zeile erstellen. |
| |
Air Messaging | Bei der Übertragung von eAWB- und eHouse-Nachrichten werden jetzt erstmals EBR-Kennzeichen unterstützt – in den beiden von Air France/KLM und Lufthansa Cargo geforderten Formaten. Das EBR-Kennzeichen wird gesetzt, wenn für die Sendung ein EBR-Dokument vorhanden ist, das aus Scope gedruckt wurde. |
| |
Sendungsauftrag-Schnittstelle | Die Schnittstelle für eingehende Sendungsaufträge wurde um die Unterstützung von SLAC erweitert. Voraussetzung ist die Shipping Order XML-Version 4.1. |
|
Typ |
Bereich |
Beschreibung |
| |
Seefracht Export FCL: Vorlauf und Freetime-Verwaltung |
Die Registerkarte „Vorlauf“ innerhalb der Registerkarte „Güter“ wurde vollständig überarbeitet und zeigt jetzt die drei wesentlichen Stationen:
Die überarbeitete Ansicht bietet mehr Details und wird anhand eingehender Ereignisse automatisch aktualisiert. Zusätzlich wird die Freetime auf Containerebene anhand der Vorgaben berechnet, die Sie im Reiter „Allgemein“ hinterlegen. |
| |
Erfassung und Validierung von Seefracht-sendungen |
Bei Seefrachtsendungen und Master-Sendungen werden Eingaben in den Feldern „OBL-Nummer“, „Buchungsreferenz(en)“ und „Siegelnummer“ (für Container) in den jeweiligen Editoren automatisch in Großbuchstaben umgewandelt. Führende und nachgestellte Leerzeichen werden entfernt. Bei der Eingabe ungültiger Zeichen wird ein Validierungsfehler angezeigt. Zulässig sind die Buchstaben A–Z, die Ziffern 0–9 sowie die Sonderzeichen ( ) _ - . /. Für die Felder „OBL-Nummer“ und „Buchungsreferenz(en)“ wird außerdem ein Validierungsfehler angezeigt, wenn die Eingabe nicht zwischen 6 und 35 Zeichen lang ist. |
| |
Registerkarte Dokumente |
Von einer Reederei empfangene Text- und PDF-Dokumente, die sich auf eine übermittelte Buchung, Verschiffungsinstruktion oder VERMAS-Nachricht beziehen, werden jetzt in der Registerkarte „Dokumente“ nach Nachricht gruppiert. Alle Dokumente zur selben Nachricht werden in einer auf- und zuklappbaren Gruppe zusammengefasst. |
| |
House B/L und B/L Instruktionen | Beim Drucken von House B/Ls oder B/L-Instruktionen bleibt das Feld für das Gesamtvolumen jetzt leer, wenn der Wert 0 beträgt. Die Angabe „0 cbm“ wird nicht mehr auf dem Dokument ausgegeben. |
| |
Seefracht Import Sendungs-übersicht |
In der Sendungsübersicht für Seefracht Import steht der Incoterm jetzt als Filter, als sortierbare Spalte und als Kriterium für gespeicherte Filter zur Verfügung. |
| |
DAKOSY, Portbase & BHT Monitoring |
In den Home Views von DAKOSY, Portbase und BHT steht jetzt die Funktion zum Exportieren der Ansicht zur Verfügung. Damit können Sie gefilterte und individuell angepasste Nachrichtenlisten für Auswertungen und die weitere Bearbeitung exportieren. |
| |
Tracking Plan Vorlagen |
Die Ereigniszuordnung für Gate-Out-Meilensteine im Import wurde verbessert: Ein Meilenstein wird erst abgeschlossen, wenn sowohl der Container- als auch der Bestimmungsort übereinstimmen. |
| |
Sendung light Übersicht |
Die Übersicht „Sendung light“ wurde um eine Temperaturspalte ergänzt. Damit können Sie temperaturgeführte Sendungen direkt in der Übersicht und in den exportierten Auswertungen erkennen. |
| |
Ocean Carrier Booking |
Bei erneuten EDI-Buchungsversuchen an Reedereien werden jetzt die aktualisierten Haupttransportdaten (Schiffs- und Etappendaten) aus der Sendung übernommen. Die Haupttransportdaten des vorherigen Buchungsversuchs werden nicht mehr verwendet. |
| |
Allgemein = Spedition und Zoll |
Scope unterstützt jetzt 40 zusätzliche Dokumenttypen. |
| |
Bill of Lading |
Das Feld „Freight Payable At“ wird jetzt anhand der ausgewählten Frachtzahlungsbedingung automatisch vorbelegt: bei „Prepaid“ mit dem Ladehafen, bei „Collect“ mit dem Löschhafen. Manuell eingegebene Werte werden durch die automatische Vorbelegung nicht mehr überschrieben. |
| |
Sea Carrier EDI/Tracking |
Zusätzlich zu Buchungen, Verschiffungsinstruktionen und VGM-Meldungen werden jetzt auch Ereignismeldungen von Reedereien unterstützt, die über Coneksion eingehen. |
| |
Sea Carrier EDI: Depot- und Terminal-Mapping |
Mit dem neuen EDI-Profil „OCE“ können Benutzer und Administratoren Zuordnungen für bislang nicht zugeordnete Depots und Terminals pflegen, deren Adressen über Buchungsbestätigungen der Reedereien eingehen. Damit steht die bestehende Funktion zum Zuordnen einer Einmaladresse zu einem Partner jetzt auch für Container-Depots und Container-Terminals zur Verfügung. Weitere Einzelheiten in den Details zur neuen Scope Version 26.10 |
| |
AMS Filing & Tradetech |
Verschiffungsinstruktionen (z. B. über INTTRA) und das Tradetech-Manifest unterstützen jetzt AMS-Anmeldungen für die folgenden Länder und Gebiete:
|
| |
ClearingCenter Portsystems, Portbase messages | Ein Fehler wurde behoben, durch den nach dem Senden einer M1001-Nachricht an Portbase keine T1000-Nachricht erstellt werden konnte. |
| |
Scope, Cargosteps Kommunikation | Ein Fehler wurde behoben, durch den Scope die Kommunikation mit Cargosteps als erfolgreich einstufte, obwohl sie im ClearingCenter fehlgeschlagen war. Scope zeigt jetzt an, welcher Fehler aufgetreten ist. |
| |
Dakosy XML |
Bei DAKOSY-Aufträgen (HDS / Kaiauftrag) im XML-Format ist das Adressfeld „PostalIdentificationCode“ auf 9 Zeichen begrenzt. Wird diese Länge überschritten, zeigt der Editor jetzt einen Validierungsfehler an. Zusätzlich werden führende und nachgestellte Leerzeichen aus allen Feldwerten entfernt, die in die ausgehende XML-Nachricht übernommen werden. Dies erfolgt vor der Erstellung der Nachricht. |
| |
Container Web Tracking | Ein Fehler bei der Verarbeitung von Ereignissen für CWT (Container Web Tracking) wurde behoben: Wurde eine Sendung wegen eines fehlenden Haupttransports nicht gefunden, konnte eine NullPointerException auftreten. Dies war möglich, wenn eine Sendung mit Haupttransport in eine Sendung ohne Haupttransport umgewandelt worden war, bevor die CWT-Nachverarbeitung das Ereignis verarbeitete. |
| |
Dakosy XML | Bei einem HDS muss die DAKOSY-Reisenummer aus 3 Buchstaben gefolgt von 4 Ziffern bestehen. Bei abweichenden Eingaben wird ein Validierungsfehler angezeigt. |
| |
Ocean Carrier EDI / CargoSmart |
Ein Fehler wurde behoben, durch den die Einstellungen zur Containerbefeuchtung in CargoSmart-Buchungsnachrichten (IFTMBF) mit einem falschen Qualifier übermittelt wurden. Die Befeuchtungswerte werden jetzt in dem von CargoSmart erwarteten Format gesendet. |
| |
Dakosy EMP |
Bei der Bearbeitung eines DAKOSY-HDS oder Kaiauftrags sind die Abmessungen einer Güterposition jetzt keine Pflichtangaben mehr. |
| |
Import Sendungen |
Die Bezeichnung der Aktion „Sendungstyp ändern“ ist für Importsendungen jetzt einheitlich. |
| |
Sea Import Master |
Beim Export der Containerentladeliste tritt jetzt auch dann kein Fehler mehr auf, wenn Container zu House-Sendungen anderer Niederlassungen gehören. |
| |
Tradetech |
Meldungen zu Validierungsergebnissen von Tradetech werden jetzt an Scope weitergeleitet. |
| |
Ocean Carrier Stammdaten |
In Mehrmandantensystemen können Benutzer*innen die Stammdaten von Reedereien nicht mehr pflegen oder löschen. |
| |
Carrier Events via Coneksion |
Ein Fehler wurde behoben, durch den Ereignismeldungen von Reedereien zu bestehenden EDI-Buchungen über das Coneksion-Portal in der Registerkarte „Ereignisse“ der Sendung nicht korrekt angezeigt wurden. Für über Coneksion weitergeleitete Meldungen werden generische Scope-Ereignisse verwendet, während für INTTRA, CargoSmart und InforNexus die jeweiligen proprietären Ereignisse zum Einsatz kommen. |
| |
Prealert |
Empfangene XML-Prealerts werden jetzt auch dann automatisch gedruckt, wenn sie keine Dokumente enthalten. Bisher wurde ein Prealert nur gedruckt, wenn mindestens ein Dokument enthalten war. |
|
Typ |
Bereich |
Beschreibung |
| |
Zoll Event-Schnittstelle | Wird eine SumA Position zollseitig storniert, so werden die genauen Informationen im CPR Event im Remarks Element aufgeführt. |
| |
Zoll Event-Schnittstelle | Für alle von Scope generierten Zoll-Events aus dem Bereich ATLAS WKS wird nun die Bezugsnummer des Vorgangs im Element customsReferenceNumber übergeben. |
| |
SCI-Schnittstelle | Das SCI Mapping wurde in allen betroffenen Verfahren um die Angaben PV Wertsteigerung, Gehaltsangaben für Alkohol, Milch und Saccharose erweitert. |
| |
SCI Events | Korrekterweise wird bei einem Passar Ausfuhrevent in dem XML ab sofort unter ‘procedure’ <Export> geschrieben. |
|
Typ |
Bereich |
Beschreibung |
| |
ATLAS AES | Bei der Erstellung einer neuen Ausfuhranmeldung in Scope wird nun ein Warnhinweis angezeigt, wenn das Bestimmungsland nicht mit dem Land des Empfängers übereinstimmt. |
| |
ATLAS AES | Bei der Erstellung einer neuen Ausfuhranmeldung wird nun bei fehlendem statistischen Wert eine Warnung angezeigt, da dieser laut ATLAS IHB nicht verpflichtend ist, aber dringend empfohlen wird. |
| |
ATLAS WKS | Die Fehlerdarstellung im Fall von Übertragungsfehlern an den Zoll wurde verbessert. |
| |
ATLAS Einfuhr | Bei der Erfassung des Vorpapiers in allen Verfahrensbereichen in ATLAS Einfuhr wurde eine fehlende Validierung für die Art der Identifikation ergänzt. |
| |
ATLAS AES |
Es wurde ein Fehler behoben, durch den die MRN eines AES-Vorgangs in bestimmten Fällen nach einem Statusupdate verloren gehen konnte. Die MRN bleibt nun auch bei eingehenden Statusänderungen am Vorgang erhalten und wird nicht mehr unbeabsichtigt entfernt. |
|
Typ |
Bereich |
Beschreibung |
| |
Passar Durchfuhr / Transportanmeldung | Feldbezeichnungen wurden angepasst. Die Validierung des Formats wurde auf alphanumerisch, max. Länge 35 Zeichen, angepasst. |
| |
Passar Einfuhr / Chartera Input | Dokumente, welche an den Zoll geschickt werden, können gelöscht werden. Dies wird entsprechend angezeigt und dokumentiert. Dazu gibt es auch neue Spalten. |
| |
Passar Einfuhr - SCI Schnittstelle | Unsere Scope Zollschnittstelle (SCI) wurde erweitert, sodass auch Nachrichten via Schnittstelle ins Modul Passar Einfuhr geschickt werden können. Zusätzlich werden Events retourniert. Dies kann erst im Livebetrieb genutzt werden, wenn Passar Einfuhr Live genommen wird. Zu Testzwecken ist die Anpassung verfügbar. |
| |
Passar Ausfuhr | Bei den E-Mail Einstellungen > Vorlagen > Sendungsmonitor: Erledigungsnachrichten kann als Platzhalter ab sofort auch die s.exportCustomsReference verwendet werden. |
| |
Passar Einfuhr/Ausfuhr |
Wenn aus einer Sendung eine Zollanmeldung angelegt wird, und es mehrere, verschiedene Packstücke gibt, werden diese nun 1:1 in die Deklaration übernommen. |
| |
Passar Einfuhr |
Die GP-IDs können unter der Rolle BAZG Teilnehmer gepflegt werden. |
| |
Passar Einfuhr |
Neue Filtermöglichkeit „Handlungsbedarf“ |
| |
Passar Einfuhr |
Transportanmeldung wurde um das Feld Reise ID erweitert, welche speziell für den Bereich Luftfracht und Seefracht benötigt wird. |
| |
Passar |
Die Reihenfolge der Passar Module wurde angepasst. |
| |
Passar Einfuhr | Die Nachrichten NI062 / NI081 können nun korrekt vom Webservice verarbeitet werden. |
| |
Passar Einfuhr |
Die Länge der Tarifnummer wird nun rot validiert. |
| |
Passar Einfuhr/Ausfuhr |
Eine Richtigstellung darf erst nach Erhalt der Abschlussnachricht und nach 45 Tagen gestellt werden. Bis zu diesem Zeitpunkt ist immer eine Korrektur vorgesehen. Dies wurde entsprechend angepasst und ist bereits mit 26.8 verfügbar. |
|
Typ |
Bereich |
Beschreibung |
| |
E-Rechnung |
Für Ausgangsrechnungen unterstützt Scope jetzt das E-Rechnungsformat ZUGFeRD mit dem Profil EN16931 (ehemals COMFORT). Dieses Format erfüllt die gesetzlichen Anforderungen an die verpflichtende elektronische Rechnungsstellung in Deutschland. Damit stehen in Scope beide relevanten E-Rechnungsformate für Rechnungen in Deutschland zur Verfügung: ZUGFeRD und XRechnung. Das Format kann für den E-Rechnungsversand per E-Mail entweder für einzelne Debitoren über die Partnerrolle „Debitor“ oder für alle entsprechenden Debitoren einer Landesorganisation aktiviert werden. Ein auf Ebene der Landesorganisation in Deutschland konfiguriertes E-Rechnungsformat lässt sich für einzelne Debitoren durch ein debitorenspezifisches Format überschreiben. Um ein E-Rechnungsformat auf Ebene der Landesorganisation zu aktivieren, wenden Sie sich bitte an das Riege Service Team. |
| |
Eingangs-belegimport |
Um die gesetzlichen Anforderungen an die verpflichtende elektronische Rechnungsstellung in Deutschland zu unterstützen, wurde der Eingangsbelegimport um eine automatische technische Validierung erweitert. Sie prüft importierte E-Rechnungen, die als konform mit der Norm EN 16931 gekennzeichnet sind. Bitte beachten Sie: Die technische Validierung ersetzt nicht die inhaltliche oder kaufmännische Prüfung einer Rechnung. Sie prüft ausschließlich, ob die technischen Anforderungen des E-Rechnungsstandards erfüllt sind. |
| |
Ausgangsbelege |
Scope unterstützt bereits eine spezifische Referenz des Rechnungsempfängers auf Ausgangsrechnungen, die aus der zugehörigen Sendung übernommen wird. Diese Referenz kann auf Rechnungsausdrucken, in E-Mail-Vorlagen für Rechnungen und in verschiedenen Berichten verwendet werden. Damit die Referenz des Rechnungsempfängers leichter sichtbar ist und gepflegt werden kann, steht sie jetzt als eigenes Feld im Rechnungseditor zur Verfügung. Für E-Rechnungen ist diese Referenz besonders wichtig, da ihr Wert in das Feld BT-13 „Purchase Order Reference“ (Bestellreferenz) der Norm EN 16931 übernommen wird. |
| |
Ausgangs-belege und |
Die Funktion zur Auswahl der Rechnungsanhänge, die bisher kontrollierte welche Dokumente an Rechnungs-E-Mails angehangen werden, wurde erweitert. Sie unterstützt nun auch E‑Rechnungsformate, die eingebettete Dokumente erlauben, wie XRechnung, ZUGFeRD oder Peppol. Scope unterstützt dabei zwei Fälle:
Durch diese Erweiterung lassen sich jetzt auch die Anhänge von Peppol-E-Rechnungen über die Auswahl der Rechnungsanhänge verwalten. Bisher wurde ausschließlich der Rechnungsausdruck als festes Dokument eingebettet. Weitere eingebettete Anhänge konnten nicht konfiguriert werden. Beim Versand von E-Rechnungen per E-Mail, wie in Deutschland üblich, bestimmt die Auswahl der Rechnungsanhänge, welche Dokumente in die E-Rechnung eingebettet werden. Die E-Mail selbst enthält nur einen Anhang: die E-Rechnungsdatei. So erhalten die Empfänger alle ausgewählten Begleitdokumente direkt in dieser Datei und nicht als separate E-Mail-Anhänge. |
| |
Ausgangsbelege und E-Rechnungsexport |
Die Konfiguration der Bankverbindungen auf Ebene der Landesorganisation wurde erweitert: Einer Rechnung können jetzt mehrere Bankverbindungen zugeordnet werden. Wenn die E-Rechnung aktiviert ist, müssen die Bankverbindungen in Scope gepflegt sein, da diese Angaben ein verpflichtender Bestandteil von E-Rechnungen sind. |
| |
E-Rechnungs- export |
In den Stammdaten steht jetzt ein neuer Konfigurationsdialog für Rechnungshinweise zur Verfügung. Dort lassen sich rechtliche Angaben und ergänzende Hinweise verwalten, die in ausgehenden E-Rechnungen enthalten sein müssen. Die zentrale Pflege in Scope ersetzt die bisher fest in den Rechnungsformularen hinterlegten Texte und stellt sicher, dass die Angaben auf dem PDF-Rechnungsausdruck und in der zugehörigen E-Rechnung übereinstimmen. Welche Arten von Rechnungshinweisen verfügbar sind, richtet sich nach den länderspezifischen Anforderungen. Für Deutschland werden derzeit folgende Hinweisarten unterstützt:
|
| |
E-Rechnungs- export |
Für das Rechnungsfactoring wurde der E-Rechnungsexport erweitert: Gemäß dem E-Rechnungsstandard EN 16931 kann jetzt ein abweichender Zahlungsempfänger angegeben werden. Die Angaben zum Zahlungsempfänger werden aus der in Scope konfigurierten Bankverbindung übernommen. Auf Ebene der Landesorganisation kann eine separate Bankverbindung für das Factoring-Unternehmen hinterlegt werden. Dabei muss der Kontoinhaber als abweichender Zahlungsempfänger gekennzeichnet werden. Diese Bankverbindung kann anschließend entweder allen Ausgangsrechnungen oder gezielt den Rechnungen bestimmter Debitoren zugeordnet werden. Die debitorenspezifische Zuordnung erfolgt über die Konfiguration der Bankverbindungen im Partnerprofil des Debitors. |
| |
Eingangs-belegimport |
Der Eingangsbelegimport unterstützt jetzt auch den Import von Abrechnungsgutschriften (Self-Billing). Dabei handelt es sich um debitorenbezogene Belege und nicht um klassische Eingangsrechnungen. Die Zuordnungslogik für diesen E-Rechnungstyp wurde daher um die Nutzung der Partnerrolle „Debitor“ erweitert. Zusätzlich werden Rückstellungen während des Imports jetzt automatisch aufgelöst. |
| |
E-Rechnungs- export |
Der E-Rechnungsexport für Rechnungen aus Verträgen und Aufträgen wurde erweitert: Sofern das E-Rechnungsformat dies unterstützt, wird jetzt der Rechnungszeitraum anstelle eines Lieferdatums exportiert. |
| |
E-Rechnungs- export |
Der E-Rechnungsexport für die Formate UBL und ZUGFeRD wurde erweitert, um die Anforderungen des Marktes besser zu erfüllen:
|
| |
Partner Export |
Im Zuge der Vorbereitungen auf die Anforderungen an E-Rechnungen in Deutschland wurden die debitorenbezogenen Felder im Partnerexport der Partnerübersicht überarbeitet. Neben der Korrektur bestehender Spaltenbezeichnungen wurden folgende Spalten ergänzt:
|
| |
Debitor Rolle Editor |
Die debitorenspezifische Konfiguration der Bankverbindungen wurde im Editor der Partnerrolle „Debitor“ von der Registerkarte „Rechnungserstellung“ auf die Registerkarte „Allgemein“ verschoben. |
| |
Rechnungs-dokumente / Dokumentenarchiv-Schnittstelle |
Für Rechnungsausdrucke im PDF-Format wurden neue Dokumenttypen eingeführt, um Standardrechnungen und Gutschriften von Abrechnungsgutschriften (Self-Billing) und Zahlungsabzügen zu unterscheiden:
Diese Dokumenttypen stehen jetzt auch in der Dokumentenarchiv-Schnittstelle zur Verfügung. Ihr Export kann jeweils separat konfiguriert werden. Weitere Informationen finden Sie in der Dokumentation zur Dokumentenarchiv-Schnittstelle: https://riege.github.io/scope-document/document-archive-interface.html Um die Abwärtskompatibilität sicherzustellen, aktiviert eine Migration den Export der neuen Dokumenttypen automatisch, sofern der jeweils zugehörige Basisdokumenttyp zuvor für den Export aktiviert war. |
| |
Offerten API |
Die Fehlerausgabe der Offerten-API wurde verbessert: Wird in einer API-Anfrage ungültiges JSON übermittelt, werden jetzt klarere und aussagekräftigere Fehlermeldungen angezeigt. Die Korrektur ist auch in Scope-Version 26.8 verfügbar. |
| |
Sendungseditor |
Die Registerkarte „Jobcosting“ im Sendungseditor zeigt jetzt bei Geldbeträgen auch die Währung an. Das sorgt für mehr Klarheit in Organisationen mit mehreren lokalen Währungen, in denen Beträge in einer anderen Währung als der lokalen Währung der aktuellen Landesorganisation angezeigt werden können. |
| |
Offerten |
Die Registerkarte „Kalkulation“ im Offerteneditor zeigt jetzt bei Geldbeträgen auch die Währung an. Das sorgt für mehr Klarheit bei der Bearbeitung von Offerten. |
| |
Eingangs-belegimport |
Der Eingangsrechnungsimport wurde um folgende Verbesserungen erweitert:
|
| |
Eingangs-belegimport |
Ein Fehler beim Eingangsbelegimport aus CSV- und Excel-Dateien wurde behoben. Betroffen waren Spalten, die für den Import von Beträgen für eine festgelegte Kostenart konfiguriert sind. Die Korrektur ist auch in Scope-Version 26.8 verfügbar. |
| |
Steuerberechnung für Mexiko |
Ein Fehler bei der Berechnung der Quellensteuer für Mexiko wurde behoben. Er konnte unter bestimmten Bedingungen auftreten, wenn eine Rechnung mehrere quellensteuerpflichtige Rechnungspositionen enthielt. Die Korrektur ist auch in Scope-Version 26.8 verfügbar. |
| |
Offerten |
Für Abhol- und Zustelltransportaufträge, die keine FCL-Transporte sind, wurden die Felder „Beförderungsart“ und „Containerdepot“ aus dem Offerteneditor entfernt. Damit entspricht die Logik im Offerteneditor jetzt der des Transportauftragseditors in den zugehörigen Sendungen. |
| |
Ausgangsbelege |
Die Anzeige des Kostenspezifikationstyps in der Übersicht der Ausgangsbelege wurde wiederhergestellt. |
| |
Suche nach Benutzern |
Die automatische Vervollständigung der Benutzer in den erweiterten Suchfiltern aller Übersichten (z. B. in Sachbearbeiterfeldern) wurde korrigiert: Externe Benutzer werden jetzt standardmäßig ausgeschlossen. In den folgenden Übersichten und Suchfeldern werden externe Benutzer weiterhin ausdrücklich unterstützt:
|
| |
Erwartete Rechnungsbeträge |
Ein Fehler wurde behoben, durch den geschätzte erwartete Rechnungsbeträge für ATLAS-Zollanmeldungen unter bestimmten Bedingungen nicht entfernt wurden, wenn der zugehörige Zollauftrag gelöscht wurde. |
| |
Auftrags-API |
Ein interner Serverfehler (HTTP 500) in der Auftrags-API wurde behoben. Dieser konnte unter bestimmten Bedingungen bei der Verarbeitung von Aufträgen auftreten, die gelöschten Niederlassungen zugeordnet waren. |