• Nie Znaleziono Wyników

Zastosowanie elektronicznej wymiany danych w procesach Trade Finance

N/A
N/A
Protected

Academic year: 2021

Share "Zastosowanie elektronicznej wymiany danych w procesach Trade Finance"

Copied!
9
0
0

Pełen tekst

(1)

Streszczenie

Celem artykułu jest przybliĪenie znaczenia zastosowania systemów informatycz-nych, w tym w szczególnoĞci narzĊdzi klasy EDI, do wspomagania działalnoĞci ban-ków związanej z obsługą transakcji handlowych miĊdzy kooperantami znajdującymi siĊ z róĪnych krajach. Artukuł opisuje podstawowe zasady trade finance oraz rolĊ systemów informatycznych w realizacji czynnoĞci związanych z finansowaniem han-dlu. W opisie funkcjonowania systemów, szczególną rolĊ przypisano elektronicznej wymianie danych, jako podstawowemu medium wymiany informacji miĊdzy bankami stron przedsiĊwziĊcia oraz miĊdzy bankami i ich klientami.

Słowa kluczowe: Trade finance, EDI, akredytywy, inkasa, gwarancje, Swift 1. Wprowadzenie

Trade Finance – finansowanie handlu, jest instrumentem finansowym oferowanym przez ban-ki, podmiotom instytucjonalnym, bdcym ich klientami. Rola trade finance polega na wspomaga-niu przez banki realizacji transakcji handlowych lub usługowych poprzez obsług procesów zwizanych z przekazywaniem dokumentów handlowych i/lub finansowaniem przedsiwzi midzy podmiotami gospodarczymi.

Na trade finance składaj si dwie grupy instrumentów: operacje dokumentowe oraz gwaran-cje bankowe.

1. Operacje dokumentowe to akredytywy i inkasa dokumentowe. Zadaniem banków jest zorganizowanie przesyłu i kontroli dokumentów handlowych midzy stronami a take dokonanie rozliczenia transakcji handlowej/usługowej, na podstawie przedstawionych dokumentów.

2. Gwarancja bankowa jest form zabezpieczenia transakcji handlowej/usługowej przez bank na rzecz jednej ze stron transakcji.

Akredytywa dokumentowa oraz gwarancja stanowi zobowizanie banku. Inkaso dokumen-towe takim zobowizaniem nie jest.

W dalszej cz ci opracowania opisano przebieg podstawowych procesów trade finance oraz rol systemów informatycznych w ich automatyzacji a take zastosowanie EDI w tych procesach.

(2)

2. Procesy w Trade Finance Operacje dokumentowe

Operacje dokumentowe składaj si z podobnych procesów, std zaklasyfikowane zostały do jednej grupy instrumentów finansowych. Jak wspomniano wcze niej, na instrumenty te składaj si inkasa dokumentowe i akredytywy dokumentowe.

Schemat akredytywy/inkasa   = OH F H Q LH R WZ D UF LD D N UH G \ W\ Z \  3 U] \ MĊ F LH ] D E H ] S LH F ] H Ĕ  = D Z D UF LH X P R Z \   $ Z L] R Z D Q LH D N UH G \ W\ Z \  D  = D S áD WD   3 U] H N D ] D Q LH G R N X P H Q Wy Z  E  = D S áD WD   ' R N X P H Q W\

Rys. 1. Schemat działania akredytywy dokumentowe ródło: Opracowanie własne.

Akredytywa dokumentowa ma na celu wspomoenie przez banki importera i eksportera ope-racji zwizanych z przekazaniem towaru oraz zapłat za towar. Usługa ta pozwala stronom kon-traktu na przeprowadzenie procesu handlowego zgodnie z wymogami handlu midzynarodowego oraz stanowi zabezpieczenie, dla obu stron, prawidłowego wykonania transakcji i jej rozliczenia.

Jak wida na powyszym rysunku, w realizacji akredytywy dokumentowej, udział bior czte-ry strony:

• Zleceniodawca akredytywy – importer (kupujcy) • Beneficjent akredytywy – eksporter (sprzedajcy)

• Bank importera – bank, obsługujcy akredytyw od strony importera

• Bank eksportera (bank po redniczcy) – bank obsługujcy akredytyw od strony ekspor-tera.

Najogólniej ujmujc proces akredytywy dokumentowej przebiega w sposób nastpujcy: Na bazie kontraktu (1.), zawartego midzy kupujcym a sprzedajcym, kupujcy (importer) zwraca si do swojego banku (banku importera) z wnioskiem o otwarcie akredytywy dokumento-wej (3.). Na podstawie wniosku, po przeprowadzeniu poprawnej weryfikacji, bank importera otwiera akredytyw dokumentow, rejestrujc odpowiednie limity. Informacja o otwartej

(3)

akredy-tywie przesyłana jest do banku eksportera (3.). Na podstawie informacji o otwarciu akredytywy, bank eksportera dokonuje zarejestrowania akredytywy i jej awizacji (przedstawienia) eksporterowi (4.).

Zarejestrowana akredytywa jest podstaw do wysłania przez eksportera towarów, bdcych przedmiotem transakcji handlowej (5.). Towar z reguły nie trafia bezpo rednio do importera, gdy, aby go odebra , importer musi by w posiadaniu dokumentów przewozowo-spedycyjnych. Doku-menty te przekazane zostaje przez eksportera do swojego banku (6.), za nastpnie przez bank eksportera, wraz z tzw. listem przewodnim (wykazem dokumentów) do banku importera (7.). W banku importera dokumenty podlegaj kontroli pod wzgldem zgodno ci z warunkami akredy-tywy. W sytuacji, gdy dokumenty s niezgodne bank prezentuje je importerowi, który moe zgodzi si na realizacj akredytywy (dokonanie zapłaty za towar), na podstawie dokumentów niezgodnych. Jeeli dokumenty s zgodne lub importer wyraził zgod na realizacj akredytywy, dokonywana jest płatno za transakcj. Płatno dokonuje najpierw importer na rzecz banku importera (8a.) za nastpnie bank importera do banku eksportera na rzecz eksportera (8.). Bank eksportera po otrzymaniu zapłaty, przekazuj j eksporterowi (8b.). Po dokonaniu płatno ci, bank importera przesyła importerowi oryginały dokumentów (9.), które s podstaw do odbioru towaru przez importera.

Procesy zwizane z obsługa inkas dokumentowych

Poniszy rysunek prezentuje schemat działania inkasa. Inkaso jest generalnie instrumentem podobnym do akredytywy. Główne rónice polegaj na tym, i w inkasie stron inicjujc proces jest eksporter oraz to, e aden z banków (importera i eksportera) nie musi traktowa inkasa jako zobowizania. Fakt ten wpływa na brak funkcji gwarancyjnych tego instrumentu.

Schemat działania inkasa

Rys. 2. Schemat działania inkasa ródło: Opracowanie własne.

(4)

Gwarancje

Gwarancje s instrumentem finansowym, mogcym stanowi zabezpieczenie pod zakup towa-rów, wykonanie towaru lub usługi, spłaty zadłuenia i innych czynno ci. Gwarancja bankowa stanowi zobowizanie banku do wykonania wiadczenia zapłaty na rzecz beneficjenta gwarancji, gdy spełnione zostan wszystkie warunki gwarancji. W konsekwencji oznacza to, e bank dokona realizacji gwarancji (wypłaty rodków z tytułu gwarancji), w sytuacji, gdy beneficjent gwarancji zgłosi si do banku z wnioskiem o jej realizacj, pod warunkiem oczywi cie, e bd spełnione inne warunki realizacji gwarancji. Przykładowo gwarancja moe dotyczy zapłaty za zakup towarów. Beneficjentem gwarancji bdzie sprzedajcy towar, za sama gwarancja bdzie zabez-pieczeniem zapłaty za towar. W sytuacji, gdy kupujcy dokona zapłaty za towar własnymi rod-kami, gwarancja automatycznie zostanie zamknita. Jeeli jednak kupujcy nie dokona zapłaty za towar, sprzedajcy moe zada od banku realizacji gwarancji i w efekcie wypłaty rodków z gwarancji na rzecz sprzedajcego. Gwarancja zrealizowana staje si automatycznie wymagaln naleno ci banku od kupujcego.

Przebieg gwarancji jest nastpujcy: wnioskodawca zwraca si do banku o otwarcie gwarancji (czsto najpierw otwierana jest linia gwarancyjna, w ramach której bank udziela kolejnych gwa-rancji, do wysoko ci okre lonego limitu. Limit z reguły jest odnawialny, co oznacza, e zakocze-nie jednej z gwarancji, zawartych w ramach linii, zwiksza dostpny limit o wielko gwarancji zakoczonej). Bank rozpatruje wniosek i po przyjciu odpowiednich zabezpiecze, dokonuje rejestracji gwarancji. Informacja o otwartej gwarancji wysyłana jest do beneficjenta gwarancji. Jeeli beneficjent gwarancji nie zwróci si do banku z wnioskiem o realizacj gwarancji, wyga nie ona po terminie wano ci. Zgłoszenie przez beneficjenta wniosku o realizacj gwarancji powoduje wypłat rodków z tytułu gwarancji i realizacj zabezpiecze. Gwarancja zrealizowana staje si wymagaln naleno ci banku, w stosunku do wnioskodawcy. Dalsze czynno ci podejmowane przez bank zwizane s z procesami windykacyjnymi. Majcymi na celu odzyskanie naleno ci.

3. Zastosowanie systemów informatycznych w procesach trade finance

Zastosowanie systemów informatycznych w realizacji procesów zwizanych z trade finance ma ogromne znaczenie. W tym punkcie opracowania wskazano najwaniejsze aspekty informaty-zacji operacji finansowania handlu.

Podział systemów informatycznych trade finance

Mona dokona podziału systemów informatycznych trade finance, co najmniej pod wzgl-dem dwóch kryteriów:

• Uytkowników systemu, do których jest dedykowany • Rodzaju produktu oraz roli klienta w procesie

Zgodnie z pierwszym kryterium, systemy te mona podzieli na front end oraz back office. Systemy front end, s to aplikacje przeznaczone dla klientów banków, biorcych udział w procesach trade finance. Głównym zadaniem tych systemów jest umoliwienie klientom dost-pu do zawartych przez nich transakcji oraz, w miar moliwo ci, składanie rónego rodzaju wniosków. Specyfika tego zagadnienia sprawia, i systemy front end nie mog stanowi jedynie platformy informacyjnej, pozwalajcej na proste składanie zlece. Operacje trade finance s zagadnieniami trudnymi, wymagajcymi czsto duego do wiadczenia w handlu midzynarodo-wym i znajomo ci przepisów midzynarodowego regulujcych ten handel. Fakt ten midzynarodo-wymusza na

(5)

wytwórcach oprogramowania wspomagajcego trade finance, zaimplementowania narzdzi, pozwalajcych pracownikom banku na współtworzenie lub przynajmniej aktywne pomaganie w budowaniu wniosków TF.

Systemy te powinny by zaopatrzone w mechanizmy pozwalajce na wprowadzanie wnio-sków przez klientów i nastpnie ich udostpnianie pracownikom banku w celu dokonania oceny ich poprawno ci merytorycznej. Wanym aspektem jest to, aby wnioski na tym etapie obsługi nie były traktowane jako zlecenie klienta o zawarcie umowy a jedynie stanowiły form projektu wniosku.

Systemy front end mog wspomaga dodatkowo komunikacj midzy klientem a pracowni-kiem banku, poprzez zastosowanie rónego rodzaju komunikatorów, pozwalajcych na przesyłanie zapyta ze strony klienta czy uwag ze strony pracownika banku.

Inna wan cech systemów front end jest moliwo wykorzystania wcze niej wykonanej pracy do budowy nowych wniosków. W tym celu stosuje dwie proste techniki:

• Moliwo wykorzystania istniejcych wniosków lub umów. Na ich podstawie tworzony jest nowy wniosek z warunkami wniosku lub umowy ju istniejcej w systemie.

• Moliwo budowania i wykorzystania szablonów wniosków. Szablony tworzone s z re-guły przez uytkownika, na podstawie zebranych do wiadcze lub na podstawie istniej-cych, dobrze sprawdzonych wniosków lub umów.

Inn rol warstwy klienckiej tych rozwiza jest umoliwienie klientom dostpu do przekro-jowych danych dotyczcych ich kontraktów w postaci rónego rodzaju raportów.

Systemy back office przeznaczone s dla pracowników banku, odpowiedzialnych za obsług transakcji TF. Zadaniem tych systemów jest obsługa procesów zwizanych z operacjami trade finance oraz dokonywanie wylicze niezbdnych wielko ci i ich rejestracja, zarówno w bazie danych transakcyjnych jak i w narzdziach ksigowych.

Rola tych systemów sprowadza si do rejestrowania i procesowania wniosków i spraw zwi-zanych z umowami. Systemy te czsto oparte s o rozwizania work flow, pozwalajce na proste budowanie przepływów wniosków i umów midzy odpowiednimi komórkami w banku oraz midzy innymi systemami.

Bardzo wanym aspektem funkcjonalno ci systemów back office jest komunikacja z innymi rozwizaniami, biorcymi udział w procesach TF. Dotyczy to głównie dwóch obszarów wymiany danych: wymiana komunikatów z innymi bankami oraz przesyłanie danych i odbieranie do/z in-nych systemów banku, najcz ciej systemu ksigowego (korowego).

Drugie kryterium pozwala na podział tych systemów na trzy grupy, w ramach kadej z nich na podgrupy:

• Systemy do obsługi akredytyw:

o Systemy do obsługi akredytyw importowych o Systemy do obsługi akredytyw eksportowych • Systemy do obsługi inkas:

o Systemy do obsługi inkas importowych o Systemy do obsługi inkas eksportowych • Systemy do obsługi gwarancji:

o Systemy do obsługi gwarancji udzielonych o Systemy do obsługi gwarancji otrzymanych

(6)

Automatyzacja procesów zwizanych z operacjami dokumentowymi.

Zarówno akredytywa dokumentowa jak i inkaso dokumentowe realizowane s w sposób od-mienny dla importerów i dla eksporterów. Std inkasa i akredytywy dzieli si importowe i ekspor-towe.

Systemy informatyczne musz posiada odmienne funkcjonalno ci, pozwalajca na obsług inkas i akredytyw na rzecz importera i eksportera.

Akredytywa importowa

System informatyczny powinien wspomaga obsług akredytyw importowych w zakresie po-niszych operacji:

• Obsługa wniosków o akredytyw importow, w tym obsługa draftów wniosków • Rejestracja umowy (sprawy) akredytyw importowej

• Uzgadnianie/odrzucenie dokumentów otrzymanych z banku eksportera • Realizacja akredytywy – wypłata rodków z tytułu akredytywy Akredytywa eksportowa

Obsługa akredytyw od strony eksportera jest troch bardziej skomplikowana ni od strony importera. Eksporter ma moliwo składania dodatkowych wniosków dotyczcych akredytywy:

• Wniosek o przeniesienie akredytywy • Wniosek o cesj

• Wniosek o przeniesienie wpływów • Wniosek o dyskonto akredytywy • Wniosek o potwierdzenie akredytywy

Do złoenia kadego z wniosków, systemy informatyczne powinny by zaopatrzone w obsług odpowiednich formularzy w portalu klienta oraz ich procesowanie w cz ci back office systemu. Niektóre z wniosków, jak: wniosek o dyskonto akredytywy czy wniosek o jej potwier-dzenie, wymagaj zgody departamentu kredytowego. System back office powinien by zaopatrzo-ny o rozwizanie work flow, pozwalajce na modelowanie procesu.

Typowe czynno ci zwizane z zarejestrowaniem i obsług akredytywy eksportowej polegaj na moliwo ci odbierania komunikatów Swift o otwarciu akredytywy importowej w banku impor-tera i/lub komunikatów Swift o zmianie warunków akredytywy. System informatyczny w banku eksportera powinien pozwala na odebranie odpowiednich komunikatów oraz wykonanie automa-tycznie czynno ci zwizanych z ich dalsz obsług: załoenie akredytywy eksportowej i powiado-mienie o tym fakcie klienta czy te automatyczne dokonanie zmiany jej parametrów. Koncepcja automatycznego reagowania na nadchodzce komunikaty oraz automatycznego ich wysyłania na podstawie czynno ci wykonywanych w systemie nazywa si Straight Through Processing (STP) i jest jednym z podstawowych załoe systemu Swift.

Inkasa dokumentowe

Obsługa inkas dokumentowych jest generalnie znacznie prostsza ni obsługa akredytyw. W zaleno ci od strony transakcji, systemy informatyczne musz zapewni automatyzacj co najmniej czynno ci:

• Inkaso eksportowe:

o Obsługa wniosku o inkaso dokumentowe

o Prezentowanie i negocjowanie dokumentów handlowych o Obsługa płatno ci zwizanych z inkasem

(7)

• Inkaso importowe:

o Rejestracja inkasa na podstawie otrzymanego wniosku o Prezentacja dokumentów

o Obsługa płatno ci z tytułu inkasa.

W wikszo ci czynno ci te obsługiwane s w sposób analogiczny do akredytyw, z t podsta-wow rónic, e inkasa nie wymagaj dokonywania ksigowa pozabilansowych.

Gwarancje bankowe

Funkcjonalno systemów informatycznych, zwizana z obsług gwarancji bankowych uza-leniona jest, tak jak w przypadku operacji dokumentowych, od strony transakcji handlowej czy usługowej. Wnioskodawc gwarancji jest strona zamawiajca towar lub usług, za jej beneficjen-tem dostawca. Std te gwarancja od strony wnioskodawcy nazywa si gwarancj wystawion, za od strony beneficjenta gwarancj otrzyman.

Gwarancje wystawione

Podstawow obsług oferowan przez systemy informatyczne jest moliwo obsługi wnio-sków o wystawienie gwarancji oraz realizacja gwarancji.

Informacja o wystawieniu gwarancji wysyłana jest do banku beneficjenta za pomoc komuni-katu Swift MT760, z tego te powodu formularz wniosku powinien posiada szereg walidacji, pozwalajcych na takie przygotowanie wniosku przez klienta, aby spełniał on podstawowe wymo-gi techniczne systemu do obsłuwymo-gi komunikatów Swift.

Podobnie jak w przypadku akredytyw importowych, obsługa wniosków o gwarancje bankowe moe zosta podzielona na obsług draftów wniosków oraz na obsług wła ciwych wniosków.

Otwarcie gwarancji bankowe wie si z konieczno ci zarejestrowania szeregu zabezpiecze tej gwarancji, przeprowadzeniem procesu weryfikacyjnego, w tym weryfikacji kredytowej oraz dokonaniem zapisów ksigowych.

Realizacja gwarancji jest czynno ci polegajc na dokonaniu płatno ci z tytułu gwarancji. Gwa-rancja zrealizowana moe zosta na wyrane danie beneficjenta gwarancji.

Zrealizowanie gwarancji wie si z postawieniem gwarancji w stan natychmiastowej wyma-galno ci. Std systemu informatyczne powinny by zaopatrzone w narzdzia pozwalajce na naliczanie odsetek karnych oraz obsług windykacji zarówno mikkiej jak i twardej.

Gwarancja, do które nie wystpiono z daniem realizacji automatycznie wymaga. System in-formatyczny powinien pozwala na automatyczne zamykanie gwarancji w chwili gdy mija jej termin wano ci. Zamknicie gwarancji dokonywane jest w procesach koczcych dzie roboczy i wie si z wyksigowaniem zobowizania gwarancyjnego, zwolnieniem zabezpiecze oraz zamkniciem rachunku gwarancji.

Gwarancja otrzymana

Obsługa gwarancji otrzymanej jest znacznie prostsza od gwarancji udzielonej i ograniczana do jej zarejestrowania oraz zamknicia albo na podstawie płatno ci wynikajcej z realizacji gwa-rancji albo w wyniku minicia terminu jej wano ci.

(8)

4. Komunikaty Swift w Trade Finance

Jednym z podstawowych narzdzi informatycznych stosowanych w trade finance jest nikacja za pomoc rozwiza Swift. Poniej zamieszczona jest lista najcz ciej uywanych komu-nikatów, odpowiedzialnych za przekazywanie rónych zdarze wizanych z obsług instrumentów trade finance:

Akredytywy i gwarancje:

MT700/MT701 – otwarcie akredytywy MT705 – awizo akredytywy

MT707 – wniosek o zmian warunków akredytywy MT710 – awizo do banku po redniczcego

MT720 – transfer akredytywy do innego banku MT730 – potwierdzenie odbioru akredytywy

MT732 – awizacja potwierdzenia (akceptacji) dokumentów MT734 – awizacja odrzucenia dokumentów

MT740 – autoryzacja rembursu (pokrycia) MT742 – danie rembursu

MT750 – awizacja niezgodno ci MT752 – autoryzacja płatno ci MT754 – awizacja płatno ci MT760 – awizacja gwarancji

MT767 – zmiana warunków gwarancji Inkasa dokumentowe

MT400 – awizacja płatno ci z tytułu inkasa MT405 – inkaso bezdokumentowe

MT416 – awizacja braku płatno ci/akceptacji MT430 – zmiana warunków inkasa

5. Podsumowanie

Usługi z zakresu finansowania handlu jest jednymi z wielu oferowanych przez banki klientom instytucjonalnym. Specyfika tego produktu polega na pełnieniu przez banki roli doradcy z zawieraniu tych transakcji ze wzgldu na duy stopie skomplikowania operacji zwizanych z handlem midzynarodowym. Realizacja tych usług bez zastosowania systemów informatycznych jest prawie niemoliwa a na pewno bardzo utrudniona. Wpływ na taki stan rzeczy ma kilka aspek-tów:

Konieczno stosowania jednolitej komunikacji w wymianie informacji midzy bankami, uczestnikami transakcji trade finance – najcz ciej stosowanym standardem wymiany danych s komunikaty Swift, co wymusza konieczno dostosowania si formatem danych oraz składni danych do standardu narzuconego przez t organizacj

Powszechna dostpno Internetu w szczególno ci w kontaktach klientów z bankami a take skomplikowanie procedur handlu midzynarodowego, wymuszaj na bankach udostpnianie klientom portali internetowych, w których klienci nie tylko mog składa wnioski czy przeglda obsługiwane sprawy, ale take konsultowa z do wiadczonymi pracownikami banku form oraz posta składanych wniosków.

(9)

Trade Finance jest jednym z produktów bankowych i czynno ci z tym zwizane wymuszaj na bankach dokonywanie odpowiednich rejestracji ksigowych. Przepisy ksigowe narzucaj konieczno jednolitego ksigowania w specjalnych rejestrach zwanych ksigami głównymi banku, zgodnie z zasadami rachunkowo ci polskiej i midzynarodowej. Niewyobraalnym jest dokonywanie rejestracji zapisów ksigowych bez udziału systemów informatycznych. Wymusza to zastosowanie Informatyki do realizacji czynno ci zaliczeniowych i ksigowych do operacji Trade Finance.

W kontek cie przytoczonych aspektów, szczegółowo opisanych we wcze niejszej cz ci arty-kułu, wydaje si zasadnym postawienie tezy, e oferowanie przez banki usług zwizanych ze wspomaganiem handlu midzynarodowego nie moe si obej bez stosowania narzdzi informa-tycznych. Za standardy, narzucane przez organizacj Swift, na pierwszy plan wysuwaj zastoso-wanie narzdzi elektronicznej wymiany danych.

Bibliografia

[1] A. Gospodarowicz (red.), “Technologie informatyczne w bankowo ci”, Wydawnictwo Akademii Ekonomicznej we Wrocławiu, 2002.

[2] A. Pawełczak, „Informatyka bankowa”, Wydawnictwo WSB, Pozna, 1998.

[3] Z. Ryznar, „Informatyka bankowa. Próba syntezy”, Wydawnictwo WSB, Pozna, 1998.

USING THE EDI IN TRADDE FINANCE PROCESSES Summary

The aim of this article is showing of necessity of using IT solutions for require-ment of bank activities in fields of trade finance operations. Author describes the main base of trade finance and the role of IT solution in realization of activities refer to trade finance. The article focuses on the role of EDI as a main solution in inter-changing information between banks of importer and exporter and between banks and their clients.

Keywords: Trade Finance, EDI, Letter of Credit, Guaranties, Documentary Collections, Swift

Jarosław Zajc

Katedra Informatyki Ekonomicznej Wydział Ekonomiczno-Socjologiczny Uniwersytet Łódzki

ul. Narutowicza 65, Łód e-mail: jzajac@uni.lodz.pl

Cytaty

Powiązane dokumenty

W pracach poœwiêconych problemom rozwoju zrównowa¿onego stosunkowo rzadko po- dejmowane s¹ oceny porównawcze gospodarstw o ró¿nych kierunkach produkcji [Krasowicz 2004]..

Dzia³ produkcji zwierzêcej jest decyduj¹cym o poziomie dochodów rolników. W dziale produkcji zwierzêcej dominuj¹cymi ga³êziami s¹: ¿ywiec trzodowy, którego udzia³ w

II.1.4) Określenie przedmiotu oraz wielkości lub zakresu zamówienia: A. Przedmiotem zamówienia jest dostęp on-line do 8 tytułów czasopism zagranicznych z dziedziny teorii

Mimo teoretycznej mo liwo ci wyst pienia ró norodnych bł dów topologicznych po transformacji mapy z uwzgl dnieniem korekt posttransformacyjnych, przeprowadzone analizy

Coraz czêœciej do pomiarów wielkoœci geometrycznych s¹ stoso- wane metody cyfrowej analizy obrazu [1, 2, 6, 7]. Znane dotychczas metody optyczne takie jak mikroskopy pomiarowe

Stwierdzono, e ciasta sporz dzone z dodatkiem tłuszczów stałych S-1 i M charakteryzowały si wy szymi warto ciami maksymalnej siły ci cia ni te z dodatkiem margaryn

Interesuj cym przykładem zastosowania unieruchomionych drobnoustrojów jest hodowla bakterii fermentacji mlekowej w pełnych elach, w której ł czy si etap namna

Do opisu/tworzenia strony często stosuje się język HTML (z ang. Hypertext Markup Language). Nazwa strona jest jednak nazwą umowną, ponieważ jest zbudowana z wielu stron, które