Historia modułu dla Sage X3
Poprawki Sage X3
Pakiet nie zawierał składników rozszerzenia ekranu adresowania elektronicznego YB2E5EAD.
Dostawa nie zapewniała wszystkich procesów powiązanych ze zdarzeniami tego ekranu.
Brakujące składniki rozszerzenia zostały dodane do pakietu Sage X3 V18.1.
Pakiet zawiera rozszerzenie niezbędne do kontroli i aktualizacji danych ekranu adresowania elektronicznego.
Niektóre wcześniejsze pozycje CDAR 212 zachowywały pusty status i pozostawały zablokowane, mimo że ich pozostałe informacje umożliwiały wznowienie.
Istniejący plik XML nie mógł zostać ponownie użyty dla tych pozycji.
Wznowienie jest dozwolone wyłącznie dla pozycji spełniających przewidziane warunki kwalifikacji, bez zdalnego identyfikatora ani odpowiedzi HTTP, z istniejącym i czytelnym plikiem XML. Zachowuje tę samą tożsamość i ten sam plik; pozostałe stany pozostają chronione.
Wcześniejsze kwalifikujące się pozycje CDAR 212 można wznowić bez tworzenia nowej tożsamości ani ponownego aktywowania pozycji, których wysyłka już trwa lub ma niepewny wynik.
Lista wyboru dostawców dla adresowania CDAR była w praktyce ograniczona do 200 wyników.
Kwalifikującego się dostawcy poza tym limitem nie można było odnaleźć na liście.
Wybór dostosowano do natywnego stronicowania Sage X3. Zachowuje filtry kraju, środowiska, aktywacji, adresu elektronicznego oraz roli wystawcy lub nabywcy.
Przeglądanie kwalifikujących się dostawców w wyborze adresowania CDAR bez praktycznego limitu.
Proces stosował niewłaściwe konwersje do numerów pozycji, które już były typu tekstowego.
Ta niezgodność mogła powodować błąd Sage X3 w procesach e-reportingu.
Usunięto odpowiednie konwersje z procesów sprzedaży, zakupów, płatności i mapowań. Konwersje dat pozostają bez zmian.
Numery pozycji są przetwarzane w ich pierwotnym typie bez powodowania błędu związanego z niewłaściwą konwersją.
Wartość „Unexpected” mogła być używana jako identyfikator dokumentu podczas odczytu statusu.
Wywołanie statusu było wtedy uruchamiane bez użytecznego zdalnego identyfikatora.
Wartość ta jest teraz rozpoznawana niezależnie od wielkości liter, a odczyt jest przerywany przed jakimkolwiek wywołaniem sieciowym. Wcześniej zapisane identyfikator i status są zachowane.
Niewywoływanie middleware, gdy zapisana wartość Unexpected nie jest użytecznym zdalnym identyfikatorem.
Transport HTTP używany w trybie wsadowym nie był jednakowo dostosowany do różnych wersji Sage X3. Błędy pobierania zakupów mogły również być zgłaszane z poziomem ważności nieodpowiednim dla zaplanowanego przetwarzania.
Wywołanie mogło zakończyć się niepowodzeniem zależnie od wersji lub zakłócić wykonanie wsadowe bez prawidłowego odróżnienia tej sytuacji od błędu interaktywnego.
Wybór transportu uwzględnia wersję i kontekst: Java jako pierwsza w trybie wsadowym V9/V11, transport natywny w V12 i w trybie interaktywnym. Po próbie wysyłki przez Java nie uruchamia się transportu zastępczego. Błędne odpowiedzi HTTP podczas pobierania są zgłaszane jako ostrzeżenia w trybie wsadowym, bez ukrywania niepowodzenia ani ponawiania próby.
Wybór transportu HTTP zależnie od wersji i kontekstu oraz zgłaszanie błędów zakupów jako ostrzeżeń w trybie wsadowym bez zmiany przepływu.
Pusta, nieznana lub nieprawidłowo sformatowana wartość środowiska mogła prowadzić do domyślnego lub niespójnego routingu między procesami.
Przepływy i adresy elektroniczne mogły używać różnych środowisk.
Ujednolicono rozpoznawanie Production i Sandbox. Wielkość liter oraz spacje na początku i końcu są normalizowane; wartości niejednoznaczne są odrzucane. Adresy elektroniczne muszą odpowiadać jednemu z dwóch dozwolonych środowisk.
Ten sam parametr środowiska daje spójną trasę we wszystkich procesach Sage X3 albo wyraźne odrzucenie, jeśli jest niejednoznaczny.
Wznowienie po niepewnym wyniku sieciowym lub równoczesne wykonanie mogło ponownie rozpocząć wysyłkę faktury.
Ta sama faktura mogła być przesyłana wielokrotnie, mimo że wynik pierwszej próby nie był znany.
Próba jest teraz rezerwowana przed wywołaniem sieciowym. Istniejąca wysyłka, zdalny identyfikator lub niepewny wynik blokują ponowną transmisję do czasu uzgodnienia statusu. Jeśli transakcja nadal trwa, wysyłka zostaje odroczona do kolejnego uruchomienia.
Zapobieganie podwójnej wysyłce po utracie potwierdzenia sieciowego lub równoczesnym wznowieniu, z zachowaniem możliwości jawnego uzgodnienia.
Dane zawierające znaki zastrzeżone mogły tworzyć niepoprawny XML. Niespójności znaczników i kwot dotyczyły również modeli dla Francji i Polski.
Wygenerowany dokument mógł być nieczytelny lub odrzucany podczas przetwarzania.
Dane zmienne i etykiety załączników są prawidłowo kodowane pod kątem znaków specjalnych, bez zmiany zawartości binarnej załączników. Poprawiono odpowiednie znaczniki oraz kwotę netto modelu dla Polski. Jeśli kodowanie znaków specjalnych się nie powiedzie, dokument nie jest wysyłany.
Tworzenie poprawnego składniowo XML dla danych zawierających znaki zastrzeżone i poprawienie potwierdzonych niespójności strukturalnych.
Odczyt pliku XML do transmisji mógł obcinać dużą zawartość lub zawartość skompaktowaną w jednym długim wierszu.
Platforma mogła otrzymywać niekompletny dokument, różniący się od wygenerowanego pliku.
Odczyt obejmuje teraz cały dokument, w tym ostatnią zawartość odczytaną na końcu pliku, bez dodawania separatorów. Pusty plik lub błąd odczytu blokuje wysyłkę. Pełna zawartość jest używana niezależnie od transportu HTTP.
Przesyłanie całego dużego lub zminimalizowanego XML bez obcinania ani dodawania separatorów.
Poziom ważności odrzuceń funkcjonalnych nie zawsze był ustalany na podstawie rzeczywistego kontekstu wykonania na serwerze wsadowym.
Odrzucenie danych jednej faktury mogło blokować zaplanowane przetwarzanie zamiast zostać zgłoszone z umożliwieniem kontynuowania partii.
Odrzucenia funkcjonalne są teraz zgłaszane jako ostrzeżenia na serwerze wsadowym i pozostają błędami w trybie interaktywnym. Nieoczekiwane błędy techniczne zachowują poziom błędu.
Na serwerze odrzucenie funkcjonalne jest zapisywane jako ostrzeżenie i przetwarzana jest kolejna faktura; w trybie interaktywnym to samo odrzucenie pozostaje widocznym błędem.
Błąd danych jednej faktury mógł zakłócać dalsze przetwarzanie kolejnych faktur.
Partia nie przetwarzała prawidłowo innych faktur niezależnych od odrzuconej.
Wynik i komunikaty o błędach są teraz izolowane dla każdej faktury. Odrzucona faktura jest zliczana i zgłaszana, a proces kontynuuje partię; faktura niekwalifikująca się jest pomijana. Błędy techniczne nadal są wyraźnie zgłaszane.
Nieprawidłowa faktura jest zliczana i zapisywana w dzienniku bez blokowania przetwarzania kolejnych faktur; nieoczekiwany błąd techniczny nadal jest zgłaszany na poziomie 1.
Odczyty wykonywane podczas generowania XML mogły przesuwać kursory używane do przeglądania oddziałów i faktur partii.
Proces mógł nie wznowić prawidłowo przebiegu przy kolejnej fakturze.
Przeglądanie w trybie wsadowym jest izolowane od odczytów generowania XML, a bieżąca faktura jest zapamiętywana przed wywołaniami generowania i transmisji.
Generowanie dokumentu nie zakłóca już przebiegu partii, która może kontynuować przetwarzanie kolejnych faktur.
Generowanie XML CDAR 210 mogło zakończyć się niepowodzeniem, gdy nie można było użyć katalogu lub pliku wyjściowego.
Dokument nie był tworzony, a błąd nie zawsze pozwalał precyzyjnie określić napotkaną przeszkodę.
Przygotowanie katalogu, uprawnienia zapisu, otwarcie pliku oraz kolizje nazw są teraz kontrolowane. Każde niepowodzenie zwraca odrębną przyczynę.
Generowanie CDAR zapisuje XML w sprawdzonej lokalizacji i zwraca użyteczny błąd, gdy nie można użyć katalogu lub pliku.
Dziennik wywołań statusu mógł zawierać poufne dane HTTP.
Informacje o połączeniu lub surowa zawartość odpowiedzi mogły być ujawniane w dzienniku technicznym.
Sekrety, nagłówki i surowa treść HTTP nie są już rejestrowane. Dziennik zachowuje informacje niezbędne do zrozumienia wyniku wywołania bez ujawniania tych danych.
Odczyt statusów zapewnia użyteczny dziennik bez ujawniania sekretów połączenia ani surowej zawartości HTTP.
Kontekst używany dla parametrów połączenia CDAR 210 wymagał poprawy, aby odpowiadał firmie odbiorcy.
Niespójny kontekst firmy lub oddziału mógł powodować użycie niewłaściwych parametrów nabywcy.
Firma jest teraz ustalana na podstawie adresu elektronicznego odbiorcy typu firma lub oddział, a następnie sprawdzana przed wczytaniem parametrów. Gdy faktura zostanie odnaleziona, nadal sprawdzana jest jej spójność z tą firmą i oddziałem.
CDAR 210 używa parametrów firmy rzeczywiście wskazanej przez odbiorcę i odrzuca niespójny kontekst nabywcy.
Schemat identyfikatora prawnego nie był ustalany odpowiednio do obszaru geograficznego partnera.
XML e-reportingu mógł zawierać schemat niezgodny z krajem partnera.
Ustalanie rozróżnia teraz Francję, pozostałe kraje Unii Europejskiej oraz kraje trzecie. Jeśli kraj lub identyfikator nie pozwala ustalić schematu, zwracany jest wyraźny błąd zamiast arbitralnej wartości.
Przepływ e-reportingu dla Francji wysyła schemat identyfikatora spójny z obszarem geograficznym partnera.
Kokpit mógł nadal wyszukiwać niekońcowy CDAR dla Francji długo po zakończeniu śledzenia Avalara.
Zbędne wywołania statusu były powtarzane dla wcześniejszych transmisji.
Gdy status Avalara jest końcowy, automatyczne wyszukiwanie niekońcowego CDAR dla Francji jest ograniczone do 30 dni kalendarzowych po transmisji, z uwzględnieniem dnia J-30. Nadal aktywne śledzenie Avalara, śledzenie KSeF dla Polski oraz wywołania ręczne pozostają bez zmian.
Kokpit ogranicza zbędne wywołania GetStatus dla Francji bez przerywania aktywnego śledzenia Avalara ani śledzenia KSeF.
Końcowy status Avalara mógł przerywać odczyt, zanim dostępny był krajowy status CDAR dla Francji lub numer KSeF dla Polski.
Kokpit mógł zachowywać niepełne śledzenie krajowe mimo późniejszej dostępności tych informacji.
Odczyt trwa, dopóki oczekiwana informacja krajowa pozostaje niepełna. To uzupełnienie nie cofa już końcowego statusu Avalara.
Końcowy status Avalara nie uniemożliwia już późniejszego uzupełnienia CDAR dla Francji lub numeru KSeF dla Polski.
Analiza dużych odpowiedzi statusowych lub odpowiedzi z zakodowanymi znakami specjalnymi oraz wybór ostatniego zdarzenia krajowego mogły pozostawiać śledzenie CDAR lub KSeF niepełne lub niespójne.
Kokpit mógł nie prezentować ostatniego użytecznego stanu krajowego lub stwarzać ryzyko błędnej zmiany końcowego statusu Avalara.
Usprawniono niezawodność analizy odpowiedzi, która wybiera ostatnie odpowiednie zdarzenie krajowe. Odrzucenie dla Francji jest uzgadniane z odpowiednim statusem CDAR, a numer KSeF jest zapisywany dla Polski. Nieprawidłowa odpowiedź nie zmienia już zapisanego statusu.
GetStatus uzupełnia ostatni użyteczny stan krajowy, zachowując już końcowy status Avalara.
Brakująca wartość CDAR mogła być wyświetlana w kokpicie z etykietą menu.
Użytkownik mógł interpretować tę etykietę jako rzeczywiście wprowadzony status.
Komórki CDAR pozostają teraz puste przy braku wartości we wszystkich trzech tabelach kokpitu. Styl CDAR jest stosowany tylko wtedy, gdy status jest wyświetlany.
Brakująca wartość CDAR w YB2E5V pozostaje wizualnie pusta w kokpicie i nie prezentuje mylącej etykiety.
Ustalanie firmy objętej kontrolą licencji wymagało uzgodnienia z kryteriami firmy i oddziału przetwarzania wychodzącego.
Niespójna kombinacja kryteriów mogła nie prowadzić do kontroli oczekiwanego zakresu prawnego.
Proces ustala teraz firmę prawną na podstawie wprowadzonego oddziału lub firmy i odrzuca ich niespójność. W przypadku braku tych kryteriów każda firma prawna wybranego zakresu jest kontrolowana tylko raz. Kontrola odbywa się przy zgłoszeniu i wykonaniu.
Przetwarzanie wychodzące weryfikuje licencję zakresu prawnego rzeczywiście objętego kryteriami Sage X3 i odrzuca niespójne kombinacje firmy/oddziału.
Pobieranie zakupów mogło być uruchamiane bez wystarczająco określonego kontekstu do ustalenia parametrów na poziomie firmy.
Wczytywanie parametrów pobierania nie dysponowało jednoznacznie ustaloną firmą.
Wprowadzenie firmy lub oddziału jest teraz obowiązkowe. Oddział pozwala odnaleźć swoją firmę prawną, a niespójność między dwoma kryteriami blokuje uruchomienie. Parametry są następnie odczytywane dla tak ustalonej firmy.
Pobieranie zakupów używa parametrów firmy jednoznacznie ustalonej przez kryteria uruchomienia.
Spróbuj innego hasła lub usuń filtr.
