Import dokumentów z plików XML część II

Transkrypt

_________________________________________________________________________________________
Import dokumentów z plików XML
część II
(wersja 1.0)
Soneta Sp z o.o.
ul. Wadowicka 8a, wejście B
31-415 Kraków
tel./fax +48 (12) 261 36 41
http://www.enova.pl
e-mail: [email protected]
1
Spis treści
1
Wstęp....................................................................................................................................................................3
2
Import cech ...........................................................................................................................................................3
3
2.1
Cechy z nazwami wieloczłonowymi..............................................................................................................4
2.2
Import cech referencyjnych..........................................................................................................................4
Import zapłat ........................................................................................................................................................5
3.1
Import wpłaty gotówkowej ..........................................................................................................................5
3.1.1
3.2
Identyfikacja raportu i podmiotu..........................................................................................................5
Import rozliczenia .........................................................................................................................................6
3.2.1
Rozliczenie części kwoty .......................................................................................................................7
4
Uruchamianie importu z kodu ..............................................................................................................................7
5
Podsumowanie .....................................................................................................................................................8
2
1 Wstęp
W poprzednim artykule dotyczącym importów z plików XML omówione zostały podstawowe zasady budowy
plików XML wykorzystywanych do importu danych do systemu enova.
Zapoznaliśmy się w nim z ogólną strukturą plików importowych, znaczeniem atrybutu business, sposobem
tworzenia najprostszych dokumentów, podstawianiem danych relacyjnych, dodawaniem podlist (np. listy pozycji
czy listy płatności dokumentu) oraz dodawaniem kolejnych pól do pliku.
W bieżącym artykule zajmiemy się zagadnieniami:
Importu cech
Importu wpłat i rozliczeo
Uruchamiania importu z poziomu zewnętrznych dodatków
2 Import cech
Przeanalizujmy możliwośd importu kartoteki towarowej z przypisanymi cechami.
Ponieważ dla kartoteki towarowej wymagane są kod i nazwa, najprostszy plik XML do zaimportowania kartoteki
towarowej, będzie wyglądał jak poniżej (atrybut key jest użyty w celu zabezpieczenie przed duplikacją – o tym
była mowa w poprzednim artykule):
<?xml version="1.0" encoding="Unicode" ?>
<session xmlns="http://www.soneta.pl/schema/business" business="true">
<Towar key="Kod=ROW_TD_SCOUT_24">
<Kod>ROW_TD_SCOUT_24</Kod>
<Nazwa>Rower turystyczny damski Scout 24"</Nazwa>
</Towar>
</session>
Chcemy teraz dodad do pliku cechy Kolor oraz Typ, które w organizatorze listy są widoczne jako Features.Kolor i
Features.Typ. Zgodnie więc z logiką rozszerzania pliku XML do importu, po uzupełnieniu o cechy będzie on
wyglądał tak (uwaga – tu występuje pewne odstępstwo od ogólnej reguły – tag features ma nazwę pisaną z małej
litery):
<Towar key="Kod=ROW_TD_SCOUT_24">
<Kod>ROW_TD_SCOUT_24</Kod>
<Nazwa>Rower turystyczny damski Scout 24"</Nazwa>
<features>
<Kolor>niebieski</Kolor>
<Typ>turystyczny</Typ>
</features>
</Towar>
</session>
3
2.1 Cechy z nazwami wieloczłonowymi
Problem pojawia się, gdy cecha posiada nazwę wieloczłonową. Np. zamiast cechy Typ będzie zdefiniowana cecha
Typ modelu. Tag importujący cechy nie może wyglądad w ten sposób:
<features>
<Kolor>niebieski</Kolor>
<Typ modelu>turystyczny</Typ modelu>
</features>
bo nie będzie to wówczas poprawny plik XML.
W takim wypadku stosuje się inną notację – gdzie nazwa cechy jest atrybutem:
<features>
<feature name="Kolor">czerwony</feature>
<feature name="Typ modelu">turystyczny</feature>
</features>
W ten sposób jest możliwośd importowania cech do dowolnych obiektów w enova.
2.2 Import cech referencyjnych
Szczególnym rodzajem cech są cechy referencyjne. Dodajmy do towaru kolejną cechę Drugi dostawca, typu
referencyjnego, tabela danych referencyjnych Kontrahenci. W tym wypadku możliwe jest przekazanie wartości
takiej cechy wyłącznie przez GUID lub przez ID.
W przypadku identyfikacji przez GUID taki zapis będzie wyglądał następująco:
<features>
<feature name="Drugi dostawca">Kontrahent:ba66f548-1660-11d7-9ab0000795c951c8</feature>
</features>
Lub w uproszczeniu:
<features>
<feature name="Drugi dostawca">ba66f548-1660-11d7-9ab0-000795c951c8</feature>
</features>
W przypadku identyfikacji przez ID, musi ono byd poprzedzone znakiem #:
<features>
<feature name="Drugi dostawca">Kontrahent:#3</feature>
</features>
Lub w uproszczeniu:
<features>
<feature name="Drugi dostawca">#3</feature>
</features>
4
3 Import zapłat
Może zdarzyd się, że wraz z dokumentem handlowym chcemy zaimportowad również wpłatę do tego dokumentu.
Przykładowo – chcemy aby import paragonu z pliku XML wprowadził również zapłatę za paragon i powiązał tą
wpłatę z należnością.
3.1 Import wpłaty gotówkowej
W pierwszej kolejności musimy zaimportowad wpłatę. Dokumenty wpłat mogą byd wprowadzane w enova na
różne sposoby (przez Dokumenty, Raporty lub Ewidencję). W przykładzie zajmiemy się wprowadzaniem przez
Dokumenty, czyli tak, jak w standardowej kasie gotówkowej. Podstawowy plik dla takiego importu wygląda tak:
<DokKasowyBase class="Soneta.Kasa.DokumentWplata,Soneta.Kasa" raport="4334ca3e25e8-4505-9e70-607d93e87d8e">
<Kasa>00000000-0003-0002-0001-000000000000</Kasa>
<Definicja>00000000-0003-0003-0001-000000000000</Definicja>
<Data>2011-07-18</Data>
<Zaplata class="Soneta.Kasa.Wplata,Soneta.Kasa">
<Podmiot>Kontrahent:00000000-0009-0002-0001-000000000000</Podmiot>
<Kwota>123.00 PLN</Kwota>
<Opis>Zapłata za paragon</Opis>
</Zaplata>
<Bufor>False</Bufor>
</DokKasowyBase>
</session>
Niestety taki plik ma zasadniczą wadę, polegającą na posługiwaniu się GUID-ami. O ile w przypadku tagów Kasa
i Definicja możemy się łatwo pozbyd GUID-ów, wykorzystując atrybut where, o tyle w przypadku Raport i Podmiot
nie będzie to takie łatwe. Wynika to stąd, że:
Raport występuje w konstruktorze klasy DokumentWplata, musi byd więc wprowadzony jako atrybut (a
nie jako tag). A nie możemy zastosowad atrybutu dla atrybutu.
Podmiot w przypadku zapłaty może byd kontrahentem, pracownikiem, bankiem itp. Musi byd więc
określony jego typ. Przy takiej konstrukcji możemy się posłużyd jedynie GUID-em lub ID.
3.1.1 Identyfikacja raportu i podmiotu
Rozwiązaniem powyższego problemu jest wprowadzenie do pliku XML raportu oraz podmiotu (kontrahenta) jako
zupełnie odrębnych tagów. Zostaną one zidentyfikowane za pomocą atrybutu key (po polu unikalnym – dla
kontrahenta będzie to kod, a dla raportu numer), a na zapłacie zostaną podstawione za pomocą wewnętrznych
identyfikatorów (o użyciu atrybutu key, oraz o wewnętrznych identyfikatorach była mowa w poprzednim
artykule).
<session business="true" xmlns="http://www.soneta.pl/schema/business">
<RaportESP id="Raport_1" key="Numer.Pelny=RK/KASA/2011/07/0012"></RaportESP>
<Kontrahent id="Podmiot_1" key="Kod=Zefir"></Kontrahent>
<DokKasowyBase class="Soneta.Kasa.DokumentWplata,Soneta.Kasa" Raport="Raport_1">
<Kasa where="Symbol=Kasa" />
<Definicja where="Symbol=KP" />
5
<Kierunek>Przychod</Kierunek>
<Data>2011-07-18</Data>
<Bufor>True</Bufor>
<Zaplata class="Soneta.Kasa.Wplata,Soneta.Kasa">
<Podmiot>Podmiot_1</Podmiot>
</Zaplata>
</DokKasowyBase>
</session>
Proszę zwrócid uwagę, że np. kontrahent ma tag, który dzięki atrybutowi key spowoduje wyszukanie kontrahenta
w bazie danych, a za pomocą wewnętrznego identyfikatora (id="Podmiot_1") zostanie potem podstawiony na
dokumencie wpłaty. Oczywiście, taka zawartośd pliku XML zakłada, że zarówno kontrahent jak i raport kasowy
istnieją w bazie danych.
3.2 Import rozliczenia
Teraz pozostaje połączenie pliku zawierającego paragon z plikiem zawierającym wpłatę oraz dodanie rozliczenia
pomiędzy płatnością paragonu i wpłatą. W tym celu tagi płatnośd i i wpłata otrzymają wewnętrzne identyfikatory
(odpowiednio Platnosc_1 i Zaplata_1), którymi posłużymy się w tagu importującym rozliczenie.
Dodanie wewnętrznego identyfikatora do płatności:
<Platnosc class="Soneta.Kasa.Naleznosc,Soneta.Kasa" id="Platnosc_1">
[...]
</Platnosc>
Dodanie wewnętrznego identyfikatora do wpłaty:
<Zaplata class="Soneta.Kasa.Wplata,Soneta.Kasa" id="Zaplata_1">
[...]
</Zaplata>
I import rozliczenia:
<RozliczenieSP id="RozliczenieSP_1" dokument="Platnosc_1" zapłata="Zaplata_1">
</RozliczenieSP>
Cały plik będzie wyglądał następująco:
<session business="true" xmlns="http://www.soneta.pl/schema/business">
<RaportESP id="Raport_1" key="Numer.Pelny=RK/KASA/2011/07/0012"></RaportESP>
<Kontrahent id="Podmiot_1" key="Kod=Zefir"></Kontrahent>
<DokumentHandlowy id="Dokument_1">
<Definicja where="Symbol=PAR" />
<Magazyn where="Symbol=F" />
<Data>2010-04-27</Data>
<Kontrahent>Podniot_1</Kontrahent>
<Platnosci>
<Platnosc class="Soneta.Kasa.Naleznosc,Soneta.Kasa" id="Platnosc_1">
<SposobZaplaty where="Nazwa=Gotówka"/>
6
<TerminDni>0</TerminDni>
</Platnosc>
</Platnosci>
<Pozycje>
<Pozycja>
<Towar where="Kod=MONTAZ" />
<Ilosc>1 szt</Ilosc>
<Cena>123.00 PLN</Cena>
</Pozycja>
</Pozycje>
<Stan>Zatwierdzony</Stan>
</DokumentHandlowy>
<DokKasowyBase class="Soneta.Kasa.DokumentWplata,Soneta.Kasa" Raport="Raport_1">
<Kasa where="Symbol=Kasa" />
<Definicja where="Symbol=KP" />
<Kierunek>Przychod</Kierunek>
<Data>2011-07-18</Data>
<Bufor>True</Bufor>
<Zaplata class="Soneta.Kasa.Wplata,Soneta.Kasa" id="Zaplata_1">
<Podmiot>Podmiot_1</Podmiot>
</Zaplata>
</DokKasowyBase>
</RozliczenieSP>
</session>
3.2.1 Rozliczenie części kwoty
Gdyby rozliczenia miała podlegad nie cała kwota, ale tylko jej częśd, wówczas tag RozliczenieSP powinien zawierad
dodatkowo informację o tej kwocie:
<KwotaDokumentu>100.00 PLN</KwotaDokumentu>
</RozliczenieSP>
4 Uruchamianie importu z kodu
Czasami w rozwiązaniach dodatkowych dla enova pojawia się potrzeba automatycznego uruchomienia importu
danych z pliku XML (z poziomu kodu własnego programu czy serwisu). Za wczytywanie danych z plików XML
odpowiada klasa SessionReader. Zakładając, że do zmiennej filename podstawiona zostanie nazwa pliku XML,
a w zmiennej login będzie obiekt loginu do enova, samo zaimportowanie danych z pliku zawiera 3 linie kodu:
// Soneta.Business.App.Login login;
// string filename = "C:\\Folder\\NazwaPliku.XML";
System.Xml.XmlTextReader reader = new System.Xml.XmlTextReader(filename);
reader.WhitespaceHandling = System.Xml.WhitespaceHandling.Significant;
new SessionReader(login).Read(reader);
7
5 Podsumowanie
W dwóch artykułach dotyczących importu danych z plików XML przedstawione zostały podstawowe zasady
konstrukcji plików importu. Zawarte w artykułach informacje mogą posłużyd do budowy zewnętrznych
mechanizmów wymiany danych pomiędzy oprogramowaniem firm trzecich a systemem enova (przykładowo –
import zamówieo ze sklepu internetowego za pomocą plików XML). Wszystkie przykłady bazowały na imporcie
dokumentów handlowych i powiązanych z nimi danych. Wynika to stąd, że najczęściej pojawia się potrzeba
integracji właśnie w tym obszarze.
Oczywiście informacje zawarte w artykułach, dotyczące zasad konstrukcji plików, identyfikacji danych, dodawania
nowych pól do plików importowych itp. mają charakter ogólny i mogą byd pomocne w budowaniu plików
wymiany w innych obszarach.
8

Import dokumentów z plików XML część II

Transkrypt

Podobne dokumenty

Regulamin – formularz kontaktowy

Konkurs "Dziś oszczędzam w SKO jutro w BS"

Utwórz pdf

enova365 Przedstawiciel Handlowy

enova 8.0 CRM

Untitled