Import historycznych zamówień sprzedaży

Jeśli konieczne jest przeniesienie danych zakończonych zamówień sprzedaży ze starszego systemu do systemu ERP – na przykład w celu spełnienia wymagań dotyczących przechowywania dokumentów biznesowych w ustawowych okresach retencji – należy skorzystać z aplikacji Import danych z odpowiednim filtrem dla importu historycznych zamówień sprzedaży.

Artykuł zawiera instrukcję obsługi aplikacji Import danych w kontekście historycznych zamówień sprzedaży. Przedstawiono tu ogólne instrukcje oraz wskazano funkcje specjalne, które należy uwzględnić podczas pracy z importem. Podano również informacje na temat możliwych warunków wstępnych oraz skutków operacji.

Opis samej aplikacji Import danych, wraz z opisami pól i przycisków, znajduje się w dokumentacji Import danych.

Informacje ogólne

Import historycznych zamówień sprzedaży opiera się na aktualnym modelu danych przechowywanym w bazie danych repozytorium. W przypadku eksportu dostępnych jest więcej atrybutów niż przy imporcie, dlatego zaleca się przygotowanie odrębnych filtrów dla eksportu i importu.

Relacje typu 1:1 w modelu danych bazują zazwyczaj na technicznym atrybucie GUID. W zależności od zastosowania możliwe jest wykorzystanie atrybutu GUID lub klucza funkcjonalnego obiektu docelowego (najczęściej kodu lub numeru). W przypadku niektórych obiektów biznesowych wymagane jest uwzględnienie organizacji, która umożliwia konwersję klucza funkcjonalnego na techniczny. Taka organizacja nie jest zazwyczaj zawarta bezpośrednio w źródle danych importowych, lecz jest ustalana kontekstowo – na podstawie dokumentu. Dalsze informacje znajdują się w rozdziale Przegląd: Atrybuty.

Niektóre dane historyczne zamówień sprzedaży, takie jak:

  • wartości w walucie lokalnej,
  • ilości planistyczne,
  • zestawy i ich komponenty,
  • oraz wewnętrzne atrybuty pomocnicze,
    nie podlegają importowi.

Zaimportowane dane historyczne zamówień sprzedaży są zapisywane w odpowiednich obiektach biznesowych:

  • Identyfikator i GUID

    • Dane reorganizacji dokumentu
      com.cisag.app.general.obj.DocumentReorganisationData

    • Dane reorganizacji pozycji dokumentu
      com.cisag.app.general.obj.DocumentDetailReorganisationData

Wskazówka
Atrybut createdByReorganisation ma wartość false dla importowanych danych historycznych zamówień sprzedaży, aby umożliwić ich rozróżnienie względem danych utworzonych w wyniku reorganizacji zamówień sprzedaży.

  • Dalsze dane:

    • Historyczne zamówienie sprzedaży
      com.cisag.app.sales.orderarchive.obj.SalesOrderArchive

    • Historyczna pozycja zamówienia sprzedaży
      com.cisag.app.sales.orderarchive.obj.SalesOrderArchiveDetail

Zaimportowane historyczne zamówienia sprzedaży można weryfikować w aplikacji Lista: Historyczne zamówienia sprzedaży.

Obiekty biznesowe kodu skrótu jako części

Obiekty biznesowe z kodem skrótu są wykorzystywane zarówno w danych nagłówkowych, jak i pozycjach historycznego zamówienia sprzedaży. Są to technicznie powiązane grupy atrybutów, które mają identyczną strukturę w wielu dokumentach. Ich ponowne wykorzystanie pozwala zoptymalizować przestrzeń w bazie danych oraz w pamięci operacyjnej systemu.

Dzięki specjalnej konwersji, obiekty z kodem skrótu są prezentowane jako części dostępne do eksportu i importu.

Szablon dla pliku importu

Jeśli nie ma pewności, jaki format pliku importu jest właściwy, można wykonać następujące kroki:

  1. Wprowadzić przykładowe zamówienie sprzedaży za pomocą aplikacji Zamówienia sprzedaży

  2. Zdefiniować, że dla tego zamówienia mają zostać wygenerowane dane historyczne w ramach reorganizacji.
    W tym celu należy wprowadzić odpowiedni wpis w aplikacji Ustawienia reorganizacji dokumentów/Dane historyczne, przypisany wyłącznie do typu dokumentu przykładowego zamówienia sprzedaży

  3. Przeprowadzić reorganizację zamówienia sprzedaży
    →W wyniku reorganizacji zamówienie sprzedaży zostanie zapisane jako historyczne zamówienie sprzedaży.

  4. Wyeksportować historyczne zamówienie sprzedaży z wykorzystaniem filtra do importu w żądanym formacie i z wymaganymi atrybutami

 Uzyskany plik może posłużyć jako wzorzec do tworzenia plików importu.

Zaleca się również zapoznać z sekcją Przykład pliku importu.

Tworzenie nowych historycznych zamówień sprzedaży

Minimalne wymagania

Atrybuty podstawowe – Zamówienie sprzedaży
Opis atrybutu Atrybut
Klient customerData.CustomerPartner
Data wprowadzenia data
Odbiorca faktury
(jeśli nie jest dostępny, używany jest klient)		 invoiceCustomerData.CustomerPartner
Rodzaj zamówienia sprzedaży
Wskazówka
Należy sprawdzić, czy zasadne jest zastosowanie odrębnego rodzaju zamówienia sprzedaży do importu danych historycznych, np. z systemów zewnętrznych.
 type
Organizacja sprzedaży
(w systemach jednofirmowych z wyłączonymi uprawnieniami do treści jest to automatycznie klient)		 invoicingPartyData.Partner
Waluta currency

Opcjonalnie można również przenieść numer za pomocą importu. W takim przypadku numer ustalony w ramach schematu numeracji przypisanego do rodzaju jest ignorowany. Należy stosować konwencję, która zapobiega niezgodnościom z numerami już istniejącymi lub mającymi być nadanymi automatycznie.

Minimalne wymagane atrybuty – Pozycja zamówienia
Opis atrybutu Atrybut
Artykuł
(w razie potrzeby z opisem pseudoartykułu)		 item
Ilość całkowita
(zalecane z wyjątkiem pozycji rozliczeniowych; w razie potrzeby z jednostką)		 totalQuantity
Preferowana data preferredDate
Data dostawy deliveryDate
Dostawca
(jeśli wymagany i nie przypisany wcześniej)		 supplier
Odbiorca dostawy

  • jeśli inny niż klient
  • jeśli nie jest dostępny, używany jest klient
 deliveryCustomerData.customer
Magazyn
(jeśli wymagany i nie przypisany wcześniej)		 storageArea.warehouse
Integracja z zaopatrzeniem
(jeśli różni się od typu dokumentu)		 purchasingReference
Cena netto

  • zalecane z wyjątkiem rabatów naturalnych
  • dla dokumentów z cenami dla konsumenta końcowego dodatkowo cena netto z podatkami)

Opcjonalnie można również przenieść numer za pomocą importu pozycji.

Przykład pliku importu

Odpowiedni minimalny XML z atrybutami funkcjonalnymi i dwoma pozycjami ma na przykład następującą zawartość:

<?xml version="1.0" encoding="UTF-8"?>

<semiramis xmlns="com.cisag.app.sales.orderarchive.obj.SalesOrderArchive" xsi:schemaLocation="com.cisag.app.sales.orderarchive.obj.SalesOrderArchive SalesOrderArchive.xsd" created="2023-07-27T05:53:59.154Z" locale="en-US-XMLSchemaCompliant" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<SalesOrderArchive xmlns="com.cisag.app.sales.orderarchive.obj.SalesOrderArchive">

<customerOrderData>

<purchaseOrder/>

<date>

<value/>

</data>

</customerOrderData>

<date>2022-07-25T22:00:00.000Z</date>

<numer>VA0001714</numer>

<customerData>

<CareOfPartner>

<numer>71002</numer>

</CareOfPartner>

<CustomerPartner>

<numer>10010</numer>

</CustomerPartner>

</CustomerData>

<invoiceCustomerData>

<CareOfPartner>

<numer>71002</numer>

</CareOfPartner>

<CustomerPartner>

<numer>10010</numer>

</CustomerPartner>

</invoiceCustomerData>

<invoicingPartyData>

<CareOfPartner xsi:nil="true"/>

<Partner>

<numer>90000</numer>

</Partner>

</invoicingPartyData>

<Currency>

<isoCode>EUR</isoCode>

</Currency>

<Type>

<code>100</code>

</Type>

<Details>

<totalQuantity>

<amount>1</amount>

<Uom>

<code>pc</code>

</Uom>

</totalQuantity>

<preferredDate>

<value>26#08#2023</value>

</preferredDate>

<deliveryDate>2023-08-25T18:00:00.000Z</deliveryDate>

<purchasingReference>NONE</purchasingReference>

<storageArea>

<magazyn>100</magazyn>

</storageArea>

<netPrice>

<amount>1024.1</amount>

<Currency>

<isoCode>EUR</isoCode>

</currency>

</netPrice>

<retailNetPrice>

<amount>0</amount>

<currency>

<isoCode>EUR</isoCode>

</currency>

</retailNetPrice>

<deliveryCustomerData>

<CareOfPartner>

<numer>71002</numer>

</CareOfPartner>

<CustomerPartner>

<numer>10010</numer>

</CustomerPartner>

</deliveryCustomerData>

<deliveryPartnerData>

<careOfName/>

<CareOfPartner xsi:nil="true"/>

</deliveryPartnerData>

<Item>

<numer>10010</numer>

</Item>

<PseudoItemDescription xsi:nil="true"/>

<SupplierPartner xsi:nil="true"/>

</Details>

<Details>

<totalQuantity>

<amount>4</amount>

<Uom>

<code>pc</code>

</Uom>

</totalQuantity>

<preferredDate>

<value>26#08#2023</value>

</preferredDate>

<deliveryDate>2023-08-25T18:00:00.000Z</deliveryDate>

<purchasingReference>NONE</purchasingReference>

<storageArea>

<magazyn>100</magazyn>

</storageArea>

<netPrice>

<amount>59.35</amount>

<Currency>

<isoCode>EUR</isoCode>

</currency>

</netPrice>

<retailNetPrice>

<amount>0</amount>

<currency>

<isoCode>EUR</isoCode>

</currency>

</retailNetPrice>

<deliveryCustomerData>

<CareOfPartner>

<numer>71002</numer>

</CareOfPartner>

<CustomerPartner>

<numer>10010</numer>

</CustomerPartner>

</deliveryCustomerData>

<deliveryPartnerData>

<careOfName/>

<CareOfPartner xsi:nil="true"/>

</deliveryPartnerData>

<Item>

<numer>10020</numer>

</Item>

<PseudoItemDescription xsi:nil="true"/>

<SupplierPartner xsi:nil="true"/>

</Details>

</SalesOrderArchive></semiramis>.

W tym przykładzie pozostałe atrybuty są dodawane za pomocą wartości domyślnych, na przykład zgodnie z danymi podstawowymi.

Można również zaimportować dodatkowe wartości i użyć atrybutów technicznych zamiast atrybutów funkcjonalnych. Listę atrybutów można znaleźć w rozdziale Przegląd: Atrybuty.

Anulowane pozycje

Jeśli pozycja zostanie utworzona, nie można jej anulować w tym samym imporcie (przypadek canceled==true nie jest dostępny). W celu anulowania nowo utworzonej pozycji należy przeprowadzić dwa osobne importy. W pierwszym imporcie należy utworzyć pozycję z kompletem danych, bez ustawionego atrybutu canceled. W drugim imporcie należy anulować tę samą pozycję, ustawiając atrybut canceled na true. Należy pamiętać, że w drugim imporcie wszystkie pozostałe zmiany dotyczące tej pozycji zostaną zignorowane.

Edycja istniejących historycznych zamówień sprzedaży

Wskazówka
Dokumenty historyczne utworzone w wyniku reorganizacji nie podlegają edycji za pomocą importu.

Dla importu historycznych zamówień sprzedaży nie udostępniono aplikacji korygującej. Oznacza to, że nieprawidłowe dane należy skorygować poprzez przygotowanie poprawnego pliku importu i wykonanie ponownego procesu importu.

W przypadku importu historycznych zamówień sprzedaży w systemach wielofirmowych oraz systemach jednofirmowych z aktywowanymi uprawnieniami do treści wymagana jest organizacja sprzedaży. Podczas edycji istniejącego zamówienia organizacja sprzedaży jest zawsze określana na podstawie danych dokumentu zapisanych w nagłówku. Wartości organizacji sprzedaży z pliku importu są w takim przypadku ignorowane.

W celu odnalezienia historycznego zamówienia sprzedaży zapisanego w bazie danych należy podać jego identyfikator techniczny (SalesOrderArchive:guid) lub funkcjonalny (rodzaj i numer).

Dla pozycji dostępne są wszystkie opcje importu, w tym usuwanie. W celu zidentyfikowania zapisanej pozycji należy również podać identyfikator techniczny (SalesOrderArchiveDetail:guid) lub identyfikator funkcjonalny (numer).

Zmiany za pomocą importu są możliwe tylko wtedy, gdy nie są zablokowane przez kontrolę systemową.

Pozycje anulowane

W przypadku pozycji anulowanych oraz pozycji, które zostały anulowane w ramach importu (atrybut canceled ustawiony na true), żadne inne dane nie są przetwarzane z pliku importu.

Jeśli znacznik usuwania zostanie usunięty dla pozycji szczegółowej, zostanie on automatycznie usunięty również dla odpowiedniej pozycji podstawowej. Należy jednak pamiętać, że wartości pozycji podstawowej nie są wtedy pobierane z pliku importu. Dane pozycji podstawowej mogą zostać wyświetlone jako dodatkowy blok po pozycjach szczegółowych.

Na przykład w poniższym pliku XML anulowanie zostaje cofnięte dla pozycji szczegółowej 10-10 historycznego zamówienia sprzedaży 100-VA12345, a jednocześnie pole Numer referencyjny w pozycji podstawowej przyjmuje wartość abc.

<?xml version="1.0" encoding="UTF-8"?><semiramis

xmlns="com.cisag.app.sales.orderarchive.obj.SalesOrderArchive"

xsi:schemaLocation="com.cisag.app.sales.orderarchive.obj.SalesOrderArchive SalesOrderArchive.xsd" created="2023-07-26T15:10:45.999Z" locale="en-US-XMLSchemaCompliant" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" nlsMode="SINGLE_LANGUAGE" dateTimeMode="COMPACT">

<SalesOrderArchive xmlns="com.cisag.app.sales.orderarchive.obj.SalesOrderArchive">

<numer>VA12345</numer>

<type>

<code>100</code>

</type>

<Details>

<numer>10</numer>

<SubDetails>

<numer>10</numer>

<subNumber>10</subNumber>

<canceled>false</canceled>

</subDetails>

</Details>

<Details>

<numer>10</numer>

<reference>abc</reference>

</Details>

</SalesOrderArchive>

</semiramis>

Alternatywnie można również anulować anulowanie dla pozycji głównej, co automatycznie usunie znacznik usuwania ze wszystkich pozycji szczegółowych w tej pozycji.

Automatyczne zwolnienie po imporcie

Po pomyślnym zakończeniu importu możliwe jest automatyczne zwolnienie historycznego zamówienia sprzedaży. Funkcja ta zapobiega użyciu niekompletnego zamówienia w dalszych procesach. W momencie zwolnienia historyczne zamówienie sprzedaży otrzymuje status Nieprawidłowe, co uniemożliwia jego dalsze wykorzystanie także na tym etapie.

W tym celu należy ustawić atrybut bazy wirtualnej autoRelease na wartość true dla odpowiedniej instancji.

Jeśli funkcja jest aktywna i nie wystąpiły inne błędy, w dzienniku komunikatów zostaje wyświetlona informacja o automatycznym zwolnieniu zamówienia. W przeciwnym razie pojawia się komunikat ostrzegawczy.

Należy mieć na uwadze, że po zwolnieniu możliwe jest już wyłącznie przeprowadzenie reorganizacji. Dokumenty o statusie W opracowaniu (com.cisag.app.general.obj.DocumentReorganisationData:archiveDataStatus) można usunąć np. przez import, używając trybu importu mode="delete" (patrz dokumentacja Wprowadzenie: Wymiana danych).

Instrukcja: Import historycznych zamówień sprzedaży

Wskazówka
Import historycznych zamówień sprzedaży dla danej organizacji sprzedaży może być wykonany wyłącznie przez użytkowników przypisanych jako wewnętrzni pracownicy tej organizacji.

Aby zaimportować historyczne zamówienie sprzedaży, należy:

  1. Uruchomić aplikację Import danych.

  2. Wyświetlić filtr dla obiektu biznesowego:
    com.cisag.app.sales.orderarchive.obj.SalesOrderArchive
    → Zostanie otwarty filtr dla importu historycznych zamówień sprzedaży.

  3. W razie potrzeby skopiować istniejący filtr lub utworzyć nowy dla tego obiektu biznesowego.

  4. Wprowadzić lub zmienić wartości atrybutów w filtrze zgodnie z wymaganiami.

  5. Nacisnąć przycisk [Import danych] na standardowym pasku przycisków.
    → Otworzy się okno dialogowe Import danych.

  6. W oknie dialogowym określić ustawienia importu dla danego pliku. Szczegółowe opisy pól znajdują się w dokumentacji Import danych.

  7. Uruchomić proces importu, naciskając przycisk [W tle].
    → Import zostanie wykonany.

Przegląd: Atrybuty

Atrybuty poszczególnych obiektów biznesowych dostępnych do importu przedstawiono poniżej. Dla atrybutów kluczy obcych podano również odpowiednią nazwę relacji. Pola identyfikacyjne i obowiązkowe mogą ulec zmianie oraz zostać rozszerzone poprzez dostosowanie.

W przypadku niektórych obiektów biznesowych konwersja kluczy funkcjonalnych na techniczne wymaga organizacji sprzedaży. Na listach atrybutów fakt ten oznaczono adnotacją Organizacja sprzedaży (zgodna z nagłówkiem) w kolumnie Atrybut.

Atrybuty identyfikacyjne (kluczowe) oznaczone są symbolem (K).

Dane podstawowe

Historyczne zamówienie sprzedaży (SalesOrderArchive)
Atrybut Relacja Opis
autoRelease (atrybut wirtualny) Automatyczne zwolnienie. Zobacz rozdział Automatyczne zwolnienie po imporcie.
currency – Waluta. Musi być określona i dostępna. Nie może być zmieniona po przypisaniu pozycji.
customerData – Zobacz rozdział Dane klienta (customerData, invoiceCustomerData).
customerOrderData.purchaseOrder – Zewnętrzny numer dokumentu.
customerOrderData.date – Data dokumentu zewnętrznego.
date – Data wprowadzenia.
guid (K) – Identyfikator techniczny dokumentu. Wymagany do modyfikacji lub usunięcia już zapisanych danych.
invoiceCustomerData – Zobacz rozdział Dane klienta (customerData, invoiceCustomerData).
invoicingPartyData.careOf invoicingPartyData.CareOfPartner Organizacja sprzedaży: Osoba kontaktowa.
Wskazówka
Nie musi być bieżącym partnerem kontaktowym.
invoicingPartyData.careOfName – Organizacja sprzedaży: Osoba kontaktowa – Nazwa.
invoicingPartyData.partner invoicingPartyData.Partner Organizacja sprzedaży. Musi być określona i istniejąca jako aktywna organizacja sprzedaży. Musi posiadać techniczne uprawnienia do danego rodzaju dokumentu. Nie można zmieniać po utworzeniu nowego dokumentu.
number (K) – Numer dokumentu (identyfikacja funkcjonalna). Opcjonalny przy nowym utworzeniu (jeśli pusty, określany automatycznie zgodnie z zakresem numeracji przypisanym do typu dokumentu). Obowiązkowy przy edycji lub usuwaniu, jeśli guid nie został podany.
responsible ResponsiblePartner Osoba odpowiedzialna.
Wskazówka
Nie musi być aktualnie zatrudnionym pracownikiem.
salesRepresentatives[0..2] SalesRepresentatives Przedstawiciele handlowi (maksymalnie trzech).
Wskazówka
Nie muszą być aktywnymi przedstawicielami.
type (K) – Rodzaj dokumentu (identyfikacja funkcjonalna). Obowiązkowy przy nowym utworzeniu, jeśli guid nie został określony. Nie może mieć ustawionego znacznika usuwania przy tworzeniu. Nie można zmieniać po utworzeniu.
Wskazówka
Znacznik usuwania można wstawić później.
Dane klienta (customerData, invoiceCustomerData)

Dane klienta w dwóch zastosowaniach są przechowywane w bazie danych jako obiekt biznesowy z kodem skrótu i są wyświetlane jako część eksportu/importu. To samo dotyczy danych adresowych. Następujące nazwy części zostały przypisane zgodnie z nazwami atrybutów technicznych:

  • customerData – Klient

  • invoiceCustomerData – Odbiorca faktury

Poniższe atrybuty występują osobno dla każdego zastosowania.

Wyjaśnienie relacji atrybutów:

Atrybut Relacja Opis
addressData.city adres – miasto
addressData.country addressData.Country adres – kraj
addressData.district adres – dzielnica
addressData.poBox adres – skrytka pocztowa
addressData.poBoxCity adres – skrytka pocztowa: miasto
addressData.poBoxPostalCode adres – kod pocztowy skrytki pocztowej
addressData.postalCode adres – kod pocztowy
addressData.region addressData.Region adres – region
addressData.street adres – ulica
customer CustomerPartner klient
Wskazówka
dla zastosowań Klient (customerData) i Odbiorca faktury (invoiceCustomerData), atrybut ten nie może zostać zmieniony przez import, jeśli istnieją pozycje zamówienia. W takim przypadku dane w pliku importu są ignorowane.
careOf CareOfPartner Osoba kontaktowa
careOfName Imię i nazwisko osoby kontaktowej
name nazwa klienta

Dane pozycji (pozycje podstawowe i szczegółowe)

Historyczne pozycje zamówień sprzedaży (SalesOrderArchiveDetail)

Atrybut Relacja Objaśnienie

Atrybut Relacja Opis
canceled Anulowane Patrz rozdział: Tworzenie nowych historycznych zleceń sprzedaży
deliveryCustomerData Patrz rozdział: Dane odbiorcy dostawy (deliveryCustomerData)
deliveryCustomerData.taxIdentificationNumber Identyfikator podatku od sprzedaży odbiorcy dostawy
deliveryDate Data dostawy
deliveryPartnerData.careOf CareOfPartner deliveryPartner: Osoba kontaktowa dostawy
deliveryPartnerData.careOfName deliveryPartner: Imię i nazwisko osoby kontaktowej
ean Europejski numer artykułu (EAN) – więcej informacji w dokumentacji: Import pozycji przy użyciu numeru EAN
guid (K) Identyfikacja techniczna (pozycja) do zmiany lub usunięcia zapisanych danych – jeśli znana
item Pozycja – artykuł
number (K) Numer (identyfikacja techniczna), opcjonalny przy nowym tworzeniu – w przeciwnym razie określany automatycznie; obowiązkowy, jeśli identyfikator nie został podany przy zmianie/usunięciu
preferredDate.value Preferowana data
priceDimension Wymiar ceny
priceUom Jednostka ceny
pseudoItemDescription Opis pseudoartykułu – tylko dla pseudoartykułów, dla pozostałych ignorowany
purchasingReference Odnośnik do zamówienia
reference Odniesienie
storageArea.warehouse Magazyn
supplier SupplierPartner Dostawca
totalQuantity.amount Całkowita ilość – ilość
totalQuantity.uom Uom Całkowita ilość – jednostka miary
Dane odbiorcy dostawy (deliveryCustomerData)

Dane odbiorcy dostawy są przechowywane w bazie danych jako obiekt biznesowy z kodem skrótu i są wyświetlane jako część eksportu/importu. To samo dotyczy danych adresowych. Nazwa części deliveryCustomerData została przypisana analogicznie do nazwy atrybutu technicznego.

Wyjaśnienie relacji atrybutów:

Atrybut Relacja Opis
addressData.city adres – miasto
addressData.country addressData.Country adres – kraj
addressData.district adres – dzielnica
addressData.poBox adres – skrytka pocztowa
addressData.poBoxCity adres – skrytka pocztowa miasto
addressData.poBoxPostalCode adres – kod pocztowy skrytki pocztowej
addressData.postalCode adres – kod pocztowy
addressData.region addressData.Region adres – region
addressData.street adres – ulica
careOf CareOfPartner osoba kontaktowa
careOfName imię i nazwisko osoby kontaktowej
customer CustomerPartner klient
name nazwa klienta

Czy ten artykuł był pomocny?

Wyślij opinie