Interfejs wejściowy dla księgowań

Rekordy księgowania mogą być przenoszone z systemów księgowych, takich jak ERP, do księgowości finansowej za pośrednictwem interfejsu wejściowego do księgowania. Interfejs księgowania obsługuje między innymi przesyłanie faktur, płatności, not uznaniowych, księgowań bilansu otwarcia, rozliczeń rozrachunków i księgowań różnic walutowych. Pochodzenie przeniesionych księgowań jest wskazywane przez pochodzenie, np. CUSTOMER_INVOICE dla faktury sprzedaży.

Przedmiotem niniejszego artykułu jest opis interfejsu wejściowego dla księgowań. Interfejs składa się z plików ExternalInterface i ExternalInterface2, które są ze sobą połączone w relacji 1:1.

Po pierwsze, użytkownik może przeglądać wszystkie pól interfejsu w formie tabelarycznej z informacjami o typie i wskazaniem, czy jest to pole obowiązkowe, czy nie. Następnie otrzymasz szczegółowy opis wartości, które należy wprowadzić w poszczególnych polach.

W rozdziale Import danych użytkownik może zapoznać się, jak zaimportować dane do systemu i jakie opcje są dostępne w celu poprawienia nieprawidłowych rekordów.

Artykuł Przykłady danych wyjściowych do interfejsu księgowania wykorzystuje różne księgowania, aby zilustrować pola, w których wymagane są wpisy, aby np. przesyłać i księgować faktury sprzedaży, płatności przychodzące, rozliczenia rozrachunków lub księgowania księgi głównej za pośrednictwem interfejsu.

Grupa docelowa

• Programiści
• Konsultanci techniczni

Tabelaryczny przegląd wszystkich pól interfejsu

Tabela zawiera pola plików ExternalInterface i ExternalInterface 2.

Interfejs wejściowy dla księgowań

Wyjaśnienie typów pól:

Instrukcje przetwarzania

Dla każdego księgowania muszą być wyprowadzone co najmniej dwa rekordy danych:

• Jedno księgowanie dla konta
• Jedno księgowanie dla konta przeciwstawnego

W przypadku podzielonych księgowań (podział na kilka kont przeciwstawnych lub wymiarów) należy odpowiednio wyprowadzić więcej księgowań.

Powiązane księgowania dokumentu są oznaczane za pomocą pola internalNumber. Oznacza to, że wszystkie księgowania należące do dokumentu muszą w tym polu zawierać znormalizowany numer.

W ramach dokumentu poszczególne księgowania są numerowane kolejno w porządku rosnącym i reprezentują księgowania wiodące i rozbijające lub księgowania brutto i netto.

Poniższe zasady mają zastosowanie do przenoszenia księgowań:

• Pierwsze księgowanie dokumentu musi być zawsze księgowaniem brutto.
• Może istnieć tylko jedno księgowanie brutto.

Rekordy są przetwarzane w następującej kolejności: numer rekordu wewnętrznego, dokument, typ dokumentu, pochodzenie 1 i pochodzenie 2.

Opis pól ogólnych

W tym rozdziale wymieniono poszczególne pola interfejsu. Opisano również szczegółowo, jakie wartości należy wprowadzić w poszczególnych polach.

Opis pól ExternalInterface

• internalNumber (str12) — to pole musi być zawsze wypełnione. internalNumber identyfikuje dokument. Należy przypisać kolejne numery dla każdego dokumentu. W przypadku wielu księgowań jednego dokumentu (np. przy księgowaniach dzielonych), wszystkie powiązane księgowania muszą otrzymać ten sam numer.
• number (str10) — to pole musi być zawsze wypełnione. Oznacza numerację poszczególnych księgowań w ramach dokumentu. Numeracja musi być nadawana w sposób ciągły.
  Rekomendacja: licznik od 0000001 do 99999999, początek 10 i zwiększanie co 10.
• subNumber (str10) — podnumer rekordu zawsze należy wypełniać wartością 0. Jeżeli dla pozycji księgowania istnieją podpozycje, np. przyporządkowania rozrachunków przy płatności, użytkownik podaje tu kolejną numerację dla każdej podpozycji.
  Rekomendacja: licznik od 0000001 do 99999999, początek 10 i zwiększanie co 10.
• status (vset) — to pole jest używane tylko wewnętrznie, dlatego należy je pozostawić puste. Służy do oznaczania statusu przetwarzania za pomocą następujących wartości:
  • TRANSFORMATION_PENDING — nadchodzący
  • TRANSFORMED — wygenerowany
• voucherNumber (str20) — to pole musi być zawsze wypełnione. Należy podać numer dokumentu. Numer dokumentu musi być zachowany dla wszystkich częściowych księgowań jednego dokumentu.
• voucherDate (stmp) — to pole musi być zawsze wypełnione. Należy podać datę dokumentu w formacie DD.MM.RRRR. Na podstawie tej daty dokumentu automatycznie ustalany jest okres księgowy. Jeśli data dokumentu przypada na okres księgowy, który został już definitywnie zakończony, księgowanie zostaje przesunięte do kolejnego otwartego okresu. W przypadku tymczasowo zamkniętego lub jeszcze nieotwartego okresu księgowego występuje błąd. Jeżeli księgowanie ma nastąpić w okresie innym niż wynikający z daty dokumentu, użytkownik powinien skorzystać z pola postingDate.
• postingPeriod (str10) — to pole należy zawsze pozostawić puste, ponieważ okres księgowy ustalany jest automatycznie na podstawie daty dokumentu. Jeśli dokument ma zostać zaksięgowany w okresie innym niż wynikający z daty dokumentu, użytkownik powinien użyć pola postingDate.
• shadowType (vset) — rodzaj księgowania jest wykorzystywany tylko wewnętrznie, dlatego to pole należy pozostawić puste
• dataType (str15) — w przypadku księgowań w księgowości finansowej to pole zawsze należy pozostawić puste
• transactionFlag (str4) — to pole użytkownik może wypełnić w razie potrzeby. Jeżeli jednak w tym polu zostanie podany rodzaj transakcji, może on być wyłącznie typu Wartość. Podany rodzaj transakcji musi istnieć w aplikacji Rodzaje transakcji. W konfiguracji należy zasadniczo zdefiniować domyślny rodzaj transakcji.
• origin (vset) — w tym polu należy zawsze podać pochodzenie. Pole to określa źródło danych w obrębie pliku. Ze względu na to, że jest to zestaw wartości, należy wskazać jedną z poniższych stałych w dokładnym zapisie (wielkimi literami, z podkreśleniem, bez spacji). W obrębie jednego pliku pochodzenie musi być identyczne we wszystkich rekordach danych:
  • FINANCIAL_ACCOUNTING
  • PURCHASE
  • CUSTOMER_INVOICE
  • SALES_ORDER
  • SUPPLIER_INVOICE
  • PRODUCTION_ORDER
  • INVENTORY_POSTING
  • EXTERNAL_SYSTEM
  • WAGE
  • DATA_COLLECTION
  • MIGRATION
  • TRAVEL_COSTS
• originalEntity (guid) — to pole jest wykorzystywane tylko wewnętrznie, dlatego należy je pozostawić puste
• originalItem (guid) — to pole jest wykorzystywane tylko wewnętrznie, dlatego należy je pozostawić puste
• detailType (vset) — to pole musi być zawsze wypełnione. Oznacza, czy księgowanie lub dany rekord jest księgowaniem wiodącym, czy rozbijającym.
  W obrębie jednego dokumentu może istnieć tylko jeden rekord oznaczony jako LEADING_POSTING. Ten rekord musi mieć najniższy numer w ramach dokumentu. Informacje o numeracji znajdują się w opisie pola number.
  Zależne księgowania rozbijające lub częściowe (rozbicie księgowania wiodącego na kilka kont, centrów kosztów lub jednostek kosztowych) muszą otrzymać wartość PART_POSTING. Rekordy te należy przekazać z rosnącą numeracją. Dodatkowo dla księgowania mogą być podane rekordy dodatkowe, np. przypisania do pozycji otwartych przy płatnościach. W takim przypadku należy podać wartość OI_ALLOCATION.
  Należy wskazać jedną z poniższych stałych w dokładnym zapisie (wielkimi literami, z podkreśleniem, bez spacji):
  • LEADING_POSTING — oznacza księgowanie jako wiodące lub brutto
  • PART_POSTING — oznacza księgowanie jako częściowe lub rozbijające
  • OI_ALLOCATION — oznacza księgowanie jako przyporządkowanie rozrachunku
  • OPEN_ITEM_CREATION — oznacza księgowanie jako nowy rozrachunek
  • OI_CURDIF — oznacza księgowanie jako różnica kursowa rozrachunku
  • OI_WRITE_OFF — oznacza księgowanie jako wyksięgowanie rozrachunku
  • WRITE_OFF — oznacza księgowanie jako wyksięgowanie
• organizationalUnit (str10) — to pole musi być zawsze wypełnione. Należy wskazać jednostkę organizacyjną (firmę), do której przypisane jest księgowanie. Jednostka organizacyjna musi być taka sama dla wszystkich księgowań danego dokumentu.
• voucherText (str65) — to pole należy pozostawić puste. Aby przekazać tekst księgowania, użytkownik powinien skorzystać z pola postingText.
• transactionCode (str15) — to pole nie jest obowiązkowe. Rodzaje dokumentów istotne dla księgowań z interfejsu mogą być zapisane w aplikacji Przyporządkowanie rodzajów dokumentów księgowych. W tej aplikacji można przypisać rodzaj dokumentu w zależności od pochodzenia, typu księgowania, typu transakcji (transactionType) oraz, w przypadku faktur z zarządzania materiałami Comarch ERP Enterprise, rodzaju faktury sprzedaży lub zakupu.
  Wartość wprowadzona w tym polu ma zawsze pierwszeństwo. Taki rodzaj dokumentu musi istnieć w aplikacji Rodzaje dokumentów księgowych.
• transactionType (vset) — to pole musi być obecnie zawsze wypełnione. Nawet jeśli w poprzednim polu został podany rodzaj dokumentu, w tym polu należy wskazać typ dokumentu przypisany do tego rodzaju.
  Jeśli rodzaj dokumentu nie został podany, może on zostać wyznaczony na podstawie typu dokumentu wskazanego w tym polu. Typ dokumentu musi być taki sam dla wszystkich księgowań danego dokumentu. Pole to jest zestawem wartości. Należy podać jedną z poniższych stałych w dokładnym zapisie (wielkimi literami, z podkreśleniem, bez spacji):
  • OPENING_BALANCES
  • GENERAL_LEDGER_POSTINGS
  • INVOICES
  • CREDIT_NOTE
  • OPI_CHANGE
  • PAYMENTS
  • OPI_CLEARING
  • CURRENCY_DIFFERENCE
  • GENERAL_LEDGER_CLEARING
  • COLLECTIVE_ACCOUNT_TRANSFER_POSTINGS
• taxKey (str3) — zawsze, gdy w ramach dokumentu naliczany jest podatek, w tym polu musi zostać podany prawidłowy kod podatkowy. Nie dotyczy to księgowania wiodącego w przypadku podziału podatku – wówczas pole to pozostaje puste. Podział podatku występuje, gdy w jednym dokumencie pojawiają się różne kody podatkowe.
  W przypadku faktur zwolnionych z podatku, użytkownik stosuje odpowiedni kod podatkowy z wartością 0%. Podany kod podatkowy musi istnieć w aplikacji Kod podatkowy.
• taxCountry (str2) — to pole należy zawsze wypełnić, jeśli przekazywane są księgowania z kluczami podatkowymi. Należy podać dwuliterowy kod kraju ISO odpowiadający krajowi opodatkowania. Jeśli księgowana organizacja (firma) jest przedsiębiorstwem niemieckim, należy podać wartość DE.
• taxDate (stmp) — obowiązuje dla Niemiec: to pole nie musi być obowiązkowo wypełnione. Jeśli pozostanie puste, zostanie uzupełnione datą dokumentu. Należy pamiętać, że na podstawie tej daty określana jest obowiązująca stawka podatkowa wynikająca z kodu podatkowego. Data musi być podana w formacie DD.MM.RRRR.
• taxRecordinfoInput (vset) — to pole należy wypełnić tylko wtedy, gdy księgowanie jest podziałem podatku. Wartość zależy zatem od oznaczenia podziału podatku (taxSplit). Rodzaj podatku wejściowego określa m.in., czy podatek dla księgowań rozbijających obliczany jest z kwot brutto czy netto. Pole stanowi zestaw wartości. Należy podać jedną z poniższych stałych w dokładnym zapisie (wielkimi literami, z podkreśleniem, bez spacji):

  • CALCULATE_FROM_POSITIONS — rodzaj podatku wejściowego CALCULATE_FROM_POSITIONS jest dopuszczalny wyłącznie w księgowaniu wiodącym. W tym przypadku podatek wyliczany jest na podstawie pozycji. Księgowanie wiodące przekazywane jest bez kwoty podatku i bez kodu podatkowego. W pozycjach rozbijających należy podać odpowiedni kod podatkowy i określić, czy podatek wyliczany jest z kwot brutto, czy netto.

  • GROSS — brutto, podatek jest naliczany: należy podać kwoty brutto, które zawierają podatek. Podatek jest wyliczany z kwot brutto.

  • NET — ta opcja może być używana wyłącznie w połączeniu z opcją TAX. Rozbicia księgowania przekazywane są z kwotami netto i kodami podatkowymi. Dodatkowo należy wykonać księgowanie bezpośrednio na konto podatkowe również z podanym kluczem podatkowym (księgowanie podatku). Rozbicia netto muszą mieć rodzaj podatku wejściowego NET. Księgowanie na konto podatkowe musi mieć rodzaj podatku wejściowego TAX.

  • TAX — ta opcja może być używana wyłącznie w połączeniu z opcją NET. Wyjaśnienie: patrz NET.

  • NET_CALCULATE_TAX — netto, podatek jest naliczany: należy podać kwoty netto, które nie zawierają podatku. Kwoty netto stanowią podstawę opodatkowania.

  • IMPORTATION_VAT — z tą opcją możliwe jest księgowanie podatku bezpośredniego, np. podatku od importu. W takim przypadku należy zaksięgować podatek bezpośrednio na konto podatkowe. Księgowanie to musi zawierać kod podatkowy i rodzaj podatku wejściowego IMPORTATION_VAT. Dla używanego klucza podatkowego musi być aktywne oznaczenie Bezpośrednie wprowadzenie podatku.

• taxPeriod (str10) — to pole nie musi być obowiązkowo wypełnione, ponieważ okres podatkowy ustalany jest na podstawie pola postingDate. Można jednak podać inny okres dla podatku, o ile podatek i podstawa opodatkowania wynikające z danego zdarzenia mają być zapisane i zgłoszone w innym okresie niż ten ustalony na podstawie pola postingDate.
• Podany okres podatkowy musi być utworzony i możliwy do zaksięgowania w aplikacji (otwarty i niezamknięty). Okres podatkowy należy podać w formacie siedmiocyfrowym: 0MMRRRR.
  Do przetwarzania interfejsu należy również uwzględnić ustawienia w aplikacji Konfiguracja dla księgowości finansowej (funkcja Wartości domyślne/zakładka Księgowanie, pole Zarządzanie okresami podatkowymi). Można tam ustawić m.in., że okres księgowy ma być okresem wiodącym. Przy takim ustawieniu nie może być podany inny okres podatkowy. Księgowanie z interfejsu z odmiennym okresem podatkowym zostałoby wówczas oznaczone jako błędne.
• taxSplit (bool) — to pole musi być zawsze wypełnione. Możliwe wartości:
  • true — wartość true należy podać, jeśli księgowania mają charakter podziału podatku
  • false — wartość false należy podać, jeśli księgowania nie mają charakteru podziału podatku

Faktury, noty uznaniowe lub księgowania księgi głównej, które w ramach jednego dokumentu zawierają różne stawki podatku, muszą być księgowane jako podział podatku. Także księgowania zawierające podatek od importu lub takie, w których podatek ma być zaksięgowany ręcznie, muszą być księgowane w ramach podziału podatku.W księgowaniu wiodącym należy pozostawić puste konto przeciwstawne i kod podatkowy. Ponadto należy podać łączną kwotę brutto i łączną kwotę podatku (postingTaxAmount). W księgowaniach rozbijających należy podać konta, różne klucze podatkowe oraz kwoty rozbicia. W zależności od wybranego rodzaju podatku wejściowego – brutto (GROSS) lub netto (NET_CALCULATE_TAX) — kwoty księgowań rozbijających muszą być podawane jako brutto lub netto. Kwoty podatku nie muszą być podawane w księgowaniach rozbijających, ponieważ są one automatycznie wyliczane przez system na podstawie kluczy podatkowych. Wyjątek stanowią tu rodzaje podatku wejściowego NET i TAX oraz IMPORTATION_VAT. Szczegóły znajdują się w opisie pola taxRecordinfoInput.

• debitCredit (vset) — to pole musi być zawsze wypełnione. Określa typ księgowania Wn/Ma. Każde pojedyncze księgowanie należy oznaczyć, czy ma być zaksięgowane po stronie debetowej (DEBIT), czy kredytowej (CREDIT). Należy podać jedną z poniższych stałych w dokładnym zapisie (wielkimi literami, z podkreśleniem, bez spacji):
  • DEBIT
  • CREDIT
• postingAmount (dec 21,6) — dla każdego księgowania musi być podana kwota księgowania. Jedyny wyjątek stanowią księgowania zerowe. W takim przypadku kwota w księgowaniu wiodącym musi pozostać pusta. Księgowania zerowe muszą być oznaczone jako dopuszczalne w rodzaju dokumentu.
  Księgowania zerowe mogą być przeprowadzane z użyciem konta rozliczeniowego. Konto rozliczeniowe musi w księgowaniu wiodącym mieć wartość zero. Księgowania rozbijające zawierają poszczególne kwoty księgowań, które sumują się do zera.
  W księgowaniach rozbijających kwota księgowania musi być zawsze kwotą netto. Jedyny wyjątek stanowi podział podatku. W tym przypadku księgowania rozbijające mogą być podane jako wartości brutto, jeśli wybrano rodzaj podatku wejściowego (taxRecordinfoInput) GROSS (brutto).
  Maksymalna długość: 21 znaków, z czego 15 przed przecinkiem i 6 po przecinku; przy księgowaniu w księgowości finansowej dopuszczalne są tylko 2 miejsca po przecinku.
• postingTaxAmount (dec 21,6) — to pole nie musi być obowiązkowo wypełnione. Kwotę podatku można podać ręcznie lub zostanie ona automatycznie wyliczona na podstawie klucza podatkowego i powiązanej stawki. Jeśli jednak księgowanie jest księgowaniem z podziałem podatku, w księgowaniu wiodącym należy koniecznie podać łączną kwotę podatku w tym polu.
  System sprawdza, czy podane wartości kwoty księgowania, kwoty podatku i kodu podatkowego są spójne. W przeciwnym razie księgowanie zostanie oznaczone jako błędne. Informacje dotyczące obsługi błędnych księgowań znajdują się w rozdziale Import danych.
  Maksymalna długość: 21 znaków, z czego 15 przed przecinkiem i 6 po przecinku; przy księgowaniu w księgowości finansowej dopuszczalne są tylko 2 miejsca po przecinku.
• postingText (str65) — to pole nie musi być obowiązkowo wypełnione. Można podać odrębny tekst księgowania dla każdego księgowania wiodącego oraz dla każdego księgowania dzielącego lub rozbijającego.
• interCompanyUnit (str10) — to pole nie jest obecnie wykorzystywane. Jest przewidziane do przyszłych rozszerzeń.
• accountingStandard (str15) — przy księgowaniu na konta kontrahentów to pole zawsze należy pozostawić puste – dla każdego aktywnego obszaru bilansowego tworzony jest zapis salda. Tylko w przypadku jednorodnych księgowań księgi głównej można podać w tym polu standard księgowania. Salda będą wtedy kontynuowane wyłącznie w tym standardzie księgowania. Podany standard księgowania musi istnieć w aplikacji Standardy księgowania.
• invoiceNumber (str40) — jeżeli w tym polu zostanie podany numer faktury, to rozrachunek zostanie zapisany pod tym numerem, o ile chodzi o księgowanie faktury na koncie dłużnika, wierzyciela lub na koncie księgowym prowadzącym rozrachunki.
  Jeżeli użytkownik pozostawi to pole puste, rozrachunek zostanie zapisany pod numerem dokumentu.
  Jeśli istnieje faktura z numerem rozrachunku 123 i zostanie następnie zaksięgowana nota uznaniowa z tym samym numerem rozrachunku 123, to nota uznaniowa zostanie przypisana do rozrachunku faktury i (ewentualnie) automatycznie rozliczona. Jeżeli nie jest to nota uznaniowa, lecz kolejna faktura, która ma zostać przypisana do istniejącego rozrachunku (na podstawie identycznego numeru rozrachunku), to decydujące są ustawienia w zastosowanym rodzaju dokumentu, czy jest to dopuszczalne.
• invoiceItem (long) — to pole nie jest obecnie brane pod uwagę dla księgowań pochodzących z zarządzania materiałami Comarch ERP Enterprise i nie powinno być jeszcze używane. W przyszłości pole to będzie wykorzystywane do dzielenia rozrachunku w ramach płatności ratalnej. Dla każdej pozycji raty będzie można przekazać różne terminy płatności i warunki skonta.
• oiExternalVoucherNumber (str40) — to pole jest obowiązkowe dla księgowań na kontach wierzycieli. Chodzi o numer dokumentu wystawcy faktury. Jeśli w używanym rodzaju dokumentu zdefiniowano, że numer dokumentu zewnętrznego ma być tworzony na podstawie numeru dokumentu (pole voucherNumber), to to pole może pozostać puste.
• accountingCode (vset) — to pole zawsze musi być wypełnione. Należy podać typ księgowania konta. Typ księgowania może dotyczyć konta dłużnika, wierzyciela lub konta księgowego. Należy podać jedną z poniższych stałych w dokładnym zapisie (wielkimi literami, z podkreśleniem, bez spacji):
  • DEBTOR
  • CREDITOR
  • GENERAL_LEDGER
• account (str15) — to pole zawsze musi być wypełnione. W zależności od typu księgowania (poprzednie pole) należy tu podać numer konta dłużnika, wierzyciela lub konta księgowego. Podane konto partnera musi istnieć w aplikacji Partner, a konto księgowe w aplikacji Konta księgowe.
• collectiveAccount (str15) — to pole należy pozostawić puste
• taxAccount (str15) — to pole należy pozostawić puste. Przy przetwarzaniu księgowania z kodem podatkowym odpowiednie konto podatkowe jest wyznaczane automatycznie. W przypadku bezpośredniego wprowadzenia podatku, konto podatkowe należy podać w polu Konto. Nawet wtedy pole taxAccount pozostaje puste.
• journalNumber (int) — to pole należy pozostawić puste
• journalType (str15) — to pole należy pozostawić puste
• voucherCurrency (str3) — to pole należy wypełnić tylko wtedy, gdy księgowanie odbywa się w walucie obcej. Jeżeli waluta nie zostanie podana, zostanie automatycznie przyjęta waluta lokalna. Zasadniczo waluta dokumentu w księgowaniach rozbijających musi być taka sama jak w księgowaniu wiodącym. Podana waluta obca musi istnieć w aplikacji Waluty.
  Jeśli dokument dotyczy waluty obcej, w kolejnych polach można podać kurs i datę kursu. Nie jest to jednak obowiązkowe. Jeśli data kursu jest pusta, zostanie uzupełniona datą dokumentu. Jeśli kurs jest pusty, zostanie pobrany z systemu.
• rateInfo.rate (dec 18,6) — to pole nie musi być obowiązkowo wypełnione. W przypadku księgowań w walucie obcej, kurs może zostać pobrany z systemu. Jeżeli jednak kurs zostanie podany, musi być taki sam we wszystkich księgowaniach częściowych. Kurs zawsze odnosi się do podstawowej waluty lokalnej.
  Maksymalna długość: 18 znaków, z czego 8 przed przecinkiem i 10 po przecinku.
• rateInfo.date (stmp) — to pole musi być obowiązkowo wypełnione. Jeśli nie można lub nie chce się podać konkretnej daty kursu, należy wprowadzić wartość 01.01.1900. Data musi być zawsze podana w formacie DD.MM.RRRR.
• rateInfo.use (str5) — to pole nie musi być obowiązkowo wypełnione. Jeżeli ma zostać użyty inny sposób użycia kursu walutowego niż ten zdefiniowany w konfiguracji, należy przekazać tę wartość przez interfejs. Podany sposób użycia kursu walutowego musi istnieć w aplikacji Zastosowania kursu wymiany.
• rateInfo.factor (vset) — to pole nie musi być obowiązkowo wypełnione. Za pomocą współczynnika kursu określa się, ile jednostek danej waluty odpowiada jednej jednostce waluty docelowej. Jest to przydatne w przypadku kursów walut do walut o znacznie niższej wartości, jak np. kursy między euro a lirą turecką lub rupią indyjską. Możliwe wartości: 1, 10, 100, 1000 i 10000. Jeśli pole pozostanie puste, zostanie użyta wartość domyślna 1 (VALUE_1).
  Należy podać jedną z poniższych stałych w dokładnym zapisie (wielkimi literami, z podkreśleniem, bez spacji):
  • VALUE_1
  • VALUE_10
  • VALUE_100
  • VALUE_1000
  • VALUE_10000
• rateInfo.type (vset) — to pole nie musi być obowiązkowo wypełnione. Jeżeli typ kursu wymiany pozostanie pusty, zostanie zastosowany kurs średni. Jeżeli ma być użyty inny typ, należy go tu przekazać. Należy podać jedną z poniższych stałych w dokładnym zapisie (wielkimi literami, z podkreśleniem, bez spacji):
  • BUYING_RATE
  • MIDDLE_RATE
  • SELLING_RATE
• rateInfo.quotation (vset) — przy księgowaniu w walucie obcej użytkownik podaje w tym polu, której konwencji notowania (notowanie cenowe lub ilościowe) podlega wskazany kurs wymiany. Należy podać jedną z poniższych stałych w dokładnym zapisie (wielkimi literami, z podkreśleniem, bez spacji):
  • DIRECT (notowanie cenowe)
  • INDIRECT (notowanie ilościowe)
  • NO_QUOTATION (brak notowania)
• dimensionReference.optionalDimension01 do 20 (str30) — pola opcjonalnych wymiarów 1–20 należy wypełnić tylko wtedy, gdy dla rodzaju kosztu przypisanego do księgowanego konta wymagany jest opcjonalny wymiar. Podany opcjonalny wymiar musi istnieć w aplikacji Opcjonalne wymiary.
• costClass (vset) — to pole nie musi być obowiązkowo wypełnione. Dla każdej organizacji (firmy) można określić, czy klasy kosztów są stosowane, czy nie. Jeśli klasy kosztów nie są używane, pole to jest wyświetlane w systemie księgowym tylko informacyjnie. W bazie danych przypisywana jest wartość domyślna Bez klasy kosztów. Można podać jedną z następujących stałych w dokładnym zapisie (wielkimi literami, z podkreśleniem, bez spacji):
  • WITHOUT_COST_CLASS
  • VARIABLE_STRUCTURE_COST
  • FIXED_STRUCTURE_COSST
  • VARIABLE_DIRECT_COST
  • FIXED_DIRECT_COST
• costType (str55) — to pole użytkownik może pozostawić puste. Rodzaj kosztu jest ustalany na podstawie konta rzeczowego. Rodzaje kosztów są obowiązkową informacją księgową dla księgowań w module controlling. Koszty i przychody, ilości, ceny i wskaźniki są odwzorowywane przez rodzaje kosztów.
• performanceDate (stmp) — to pole nie musi być obowiązkowo wypełnione. Oznacza ono datę wykonania dla obszaru Controlling. Obecnie pole performanceDate nie jest przejmowane z faktur systemu Comarch ERP Enterprise (zarządzanie materiałami). Data musi być zawsze podana w formacie DD.MM.RRRR.
  Dla daty wykonania obowiązuje następująca logika: jeśli performanceDate pozostanie puste, zostanie uzupełnione datą księgowania. Data księgowania jest ustalana automatycznie na podstawie daty dokumentu lub wprowadzana ręcznie.
• controllingPeriod (str10) — to pole użytkownik również może pozostawić puste, ponieważ okres controllingowy może być ustalony automatycznie. Przy jego ustalaniu obowiązuje następująca logika:
  jeśli w aplikacji Konfiguracja dla księgowości finansowej (funkcja Wartości domyślne / zakładka Księgowanie, pole Zarządzanie okresami) okres księgowy został określony jako okres wiodący, wówczas w ramach przetwarzania interfejsu okres controllingowy zostanie ustalony na podstawie okresu księgowego (pole postingPeriod).
  Jeżeli mimo to okres controllingowy pozostanie pusty, zostanie ustalony na podstawie pola performanceDate. Zasadniczo jednak użytkownik może podać okres controllingowy ręcznie.
• quantity.amount (dec 21,6) — w tym polu można podać ilość wykonanej usługi (istotne dla controlling). Maksymalna długość: 21 znaków, z czego 15 przed przecinkiem i 6 po przecinku.
• quantity.uom (str10) — jeżeli użytkownik podał wartość ilościową, musi również podać jednostkę miary. Podana jednostka musi istnieć w aplikacji Jednostki.
• discountable (vest) — to pole musi być zawsze wypełnione. Za pomocą tego pola można wykluczyć pojedyncze pozycje faktury z kalkulacji skonta.
  Pozycje oznaczone jako DISCOUNTABLE są uwzględniane przy obliczaniu kwoty skonta, w zależności od warunków płatności. Rozdzielenie kwot skonta (zarówno dla podatku, jak i kwoty netto) następuje tylko dla pozycji oznaczonych jako DISCOUNTABLE. Analogicznie dotyczy to rozdziału na opcjonalne wymiary (np. centra kosztów lub jednostek kosztowych).
  Ustawienie części pozycji jako nieskontowalnych może być konieczne np. w przypadku faktur za naprawy, gdzie wynagrodzenie godzinowe nie podlega odliczeniu skonta.
  Należy podać jedną z poniższych stałych w dokładnym zapisie (wielkimi literami, z podkreśleniem, bez spacji):
  • DISCOUNTABLE
  • NOT_DISCOUNTABLE
• oiText (str65) — w tym polu użytkownik może w razie potrzeby podać dodatkowy tekst rozrachunku do tekstu dokumentu. Tekst ten zostanie zapisany przy rozrachunku.
• oiReminderLevel (vset) — to pole nie musi być obowiązkowo wypełnione. Za pomocą tego pola można przypisać dokumentowi poziom przypomnienia. Pole to powinno być jednak używane wyłącznie w kontekście pierwszego importu danych. (Najwyższy poziom przypomnienia = 9). Należy podać jedną z następujących stałych w dokładnym zapisie (wielkimi literami, z podkreśleniem, bez spacji):
  • DUNNING_LEVEL_1
  • DUNNING_LEVEL_2
  • DUNNING_LEVEL_3
  • DUNNING_LEVEL_4
  • DUNNING_LEVEL_5
  • DUNNING_LEVEL_6
  • DUNNING_LEVEL_7
  • DUNNING_LEVEL_8
  • DUNNING_LEVEL_9
  • NO_DUNNING_LEVEL
• oiLastReminderDate (stmp) — w tym polu można w razie potrzeby wprowadzić datę ostatniego wezwania do zapłaty. To pole powinno być używane wyłącznie w związku z początkowym przejęciem danych. Datę należy zawsze podawać w formacie DD.MM.RRRR.
• oiReminderBlockUntil (stmp) — w tym polu można podać datę, która określa, jak długo ma obowiązywać blokada wezwania do zapłaty dla danego rozrachunku. Po upływie tej daty rozrachunek ponownie zostaje udostępniony do monitowania. Datę należy zawsze podawać w formacie DD.MM.RRRR.
• oiReminderBlockReason (str15) — to pole należy wypełnić tylko wtedy, gdy użytkownik chce wyłączyć dany dokument otwarty z procesu monitowania. Poprzez podanie uzasadnienia w tym polu, dokument zostaje zablokowany do monitowania, a przyczyna blokady jest jednocześnie widoczna. Podana przyczyna blokady musi istnieć w aplikacji Powody blokady monitów.
• oiReminderRecipient (str10) — w tym polu można w razie potrzeby podać innego odbiorcę wezwania do zapłaty w formie numeru konta partnera. Wezwanie do zapłaty za fakturę zostanie wówczas skierowane do tego partnera.
• oiPaymentTerm (str3) — to pole nie musi być obowiązkowo wypełnione. Jeśli pola dotyczące warunków płatności pozostaną puste, zastosowanie mają warunki płatności z danych podstawowych partnera. Jeśli tam nie wprowadzono żadnych warunków płatności, wykorzystywane są warunki z ustawień systemowych. Warunki płatności obejmują następujące pola:
  • oiDiscountInfo1.dueDate do oiDiscountInfo3.dueDate (data skonta 1–3)
  • oiDiscountInfo1.dueDays do oiDiscountInfo3.dueDays (dni skonta 1–3)
  • oiDiscountInfo1.percentage do oiDiscountInfo3.percentage (procent skonta 1–3)
  • oiDueDate (dni do terminu płatności)
  • oiDueDate (data terminu płatności)

Wymienione pola mogą zostać wypełnione jako alternatywa dla klucza warunków płatności. jeśli oba warianty są wypełnione, dane muszą być ze sobą spójne, w przeciwnym razie pojawi się komunikat o błędzie.

Jeśli faktura jest natychmiast wymagalna, użytkownik powinien wypełnić datę terminu płatności wprowadzając datę dokumentu. Wszystkie pozostałe pola powinny pozostać puste.

Wprowadzony klucz warunków płatności musi istnieć w aplikacji Warunki płatności.

• oiDueDate (stmp) — w tym miejscu można podać datę terminu płatności (datę netto faktury). Jeśli pole to jest wypełnione, termin netto dokumentu nie jest obliczany na podstawie dni netto, lecz przejmowana jest wartość z tego pola. Datę należy zawsze podawać w formacie DD.MM.RRRR.

• oiDueDays (int) — w tym polu można podać liczbę dni do terminu netto dokumentu. Dni netto są z zasady liczone od daty dokumentu, aby ustalić termin płatności. W przypadku faktur z walutowaniem, termin netto jest zawsze liczony od daty waluty.

• oiValutaDate (stmp) — jeśli podano dni walutowania, to pole musi pozostać puste. Data waluty jest obliczana na podstawie dni waluty. Data waluty stanowi datę początkową dla warunków płatności. Datę należy zawsze podawać w formacie DD.MM.RRRR.
• oiValutaDays (int) — w tym polu można podać liczbę dni walutowania. Data waluty jest obliczana na podstawie dni waluty (data dokumentu + dni waluty). Jeśli użytkownik poda zarówno dni waluty, jak i datę waluty, dni waluty są ignorowane.
• oiDiscountInfo1.dueDate (stmp) — to pole musi być obowiązkowo wypełnione. Nawet jeśli nie mają być stosowane warunki skonta-1 dla faktury, pole to należy wypełnić wartością 01.01.1900. Pozostałe pola dotyczące warunku skonta-1 (oiDiscountInfo1.dueDay oraz oiDiscountInfo1.percentage) muszą pozostać puste. Jeśli jednak zostanie podana ważna data skonta (format DD.MM.RRRR) dla 1. warunku skonta, odpowiednie pole procentu skonta (oiDiscountInfo1.percentage) również musi być wypełnione.

• oiDiscountInfo1.dueDay (int) — zamiast daty skonta można podać liczbę dni skonta dla 1. warunku skonta. Jeśli to pole jest wypełnione, należy również wypełnić odpowiednie pole procentu skonta (oiDiscountInfo1.percentage). Liczba dni skonta musi być mniejsza niż liczba dni netto (oiDueDays).
• oiDiscountInfo1.percentage (dec 7,4) — w tym polu można podać procent skonta dla 1. warunku skonta. Jeśli to pole zostanie wypełnione, należy podać albo liczbę dni skonta, albo ważną datę skonta dla 1. warunku skonta. maksymalna długość: 7 znaków łącznie – 3 znaki przed przecinkiem, 4 znaki po przecinku.
• oiDiscountInfo2.dueDate (stmp) — to pole musi być obowiązkowo wypełnione. Nawet jeśli nie mają być stosowane warunki skonta-2 dla faktury, pole to należy wypełnić wartością 01.01.1900. pozostałe pola dotyczące warunku skonta-2 (oiDiscountInfo2.dueDay i oiDiscountInfo2.percentage) muszą pozostać puste. Jeśli jednak zostanie podana ważna data skonta (format DD.MM.RRRR) dla 2. warunku skonta, odpowiednie pole procentu skonta (oiDiscountInfo2.percentage) również musi być wypełnione.

• oiDiscountInfo2.dueDay (int) — zamiast daty skonta można podać liczbę dni skonta dla 2. warunku skonta. Jeśli to pole jest wypełnione, należy również wypełnić odpowiednie pole procentu skonta (oiDiscountInfo2.percentage). Liczba dni skonta musi być mniejsza niż liczba dni netto (oiDueDays).
• oiDiscountInfo2.percentage (dec 7,4) — w tym polu można podać procent skonta dla 2. warunku skonta. Jeśli to pole zostanie wypełnione, należy podać albo liczbę dni skonta, albo ważną datę skonta dla 2. warunku skonta. Maksymalna długość: 7 znaków łącznie – 3 znaki przed przecinkiem, 4 znaki po przecinku.
• oiDiscountInfo3.dueDate (stmp) — to pole musi być obowiązkowo wypełnione. Nawet jeśli nie mają być stosowane warunki skonta-3 dla faktury, pole to należy wypełnić wartością 01.01.1900. Pozostałe pola dotyczące warunku skonta-3 (oiDiscountInfo3.dueDay i oiDiscountInfo3.percentage) muszą pozostać puste. Jeśli jednak zostanie podana ważna data skonta (format DD.MM.RRRR) dla 3. warunku skonta, odpowiednie pole procentu skonta (oiDiscountInfo3.percentage) również musi być wypełnione.

• oiDiscountInfo3.dueDay (int) — zamiast daty skonta można podać liczbę dni skonta dla 3. warunku skonta. Jeśli to pole jest wypełnione, należy również wypełnić odpowiednie pole procentu skonta (oiDiscountInfo3.percentage). Liczba dni skonta musi być mniejsza niż liczba dni netto (oiDueDays).
• oiDiscountInfo3.percentage (dec 7,4) — w tym polu można podać procent skonta dla 3. warunku skonta. Jeśli to pole zostanie wypełnione, należy podać albo liczbę dni skonta, albo ważną datę skonta dla 3. warunku skonta. Maksymalna długość: 7 znaków łącznie – 3 znaki przed przecinkiem, 4 znaki po przecinku.
• oiPaymentBlock (str10) — to pole należy wypełnić tylko wtedy, gdy użytkownik chce wyłączyć dany rozrachunek z procesu płatności. Poprzez podanie przyczyny w tym polu, dany rozrachunek zostaje zablokowany do płatności, a przyczyna blokady jest jednocześnie widoczna. Podana przyczyna blokady musi być ważnym kluczem w aplikacji.
• oiPaymentCode (str15) — to pole może pozostać puste. Z reguły metoda płatności jest pobierana z danych podstawowych partnera, a jeśli tam jej nie ma – z ustawień systemowych. Jeśli faktura ma być rozliczona za pomocą innej metody płatności, należy w tym polu podać ważny klucz.
• oiPaymentType (vset) — to pole należy obecnie pozostawić puste
• oiPaymentRegulator (str10) — z reguły to pole może pozostać puste. Obowiązuje następująca zasada: jeśli partner (na podstawie ustawień w danych podstawowych partnera) jest przypisany do realizatora płatności, numer konta realizatora jest automatycznie zapisywany w rozrachunku. To pole należy wypełnić tylko wtedy, gdy ten rozrachunek ma być przypisany do innego realizatora płatności, a dane księgowe dotyczą faktur i not uznaniowych dla dłużników i wierzycieli.
• oiPayee (str10) — w tym polu można w razie potrzeby podać innego odbiorcę płatności w formie numeru konta partnera. Płatność za fakturę zostanie wtedy zrealizowana z wykorzystaniem danych rachunku bankowego tego partnera. Z reguły chodzi tu wyłącznie o faktury lub noty uznaniowe dla wierzycieli.
• oiInvoiceListNumber (str40) — to pole nie musi być obowiązkowo wypełnione. Pole lista faktur może być używane tylko dla rozrachunków (dłużników lub wierzycieli), które należą do grupy.
• oiResubmissionDate (stmp) — w tym polu można w razie potrzeby podać datę ponownego przedłożenia w formacie DD.MM.RRRR. Ta data jest zapisywana dla każdego rozrachunku. Według tej daty można filtrować w widokach i analizach.
• oiResubmissionUser (str10) — w tym polu można w razie potrzeby podać użytkownika odpowiedzialnego za ponowne przedłożenie. Użytkownik przypomnienia jest zapisywany dla każdego rozrachunku. Według tego użytkownika można filtrować w widokach i analizach.
• oiTransactionBank (str15) — jeśli w tym polu zostanie podany bank główny, otwarty post może być regulowany wyłącznie przez ten bank. Podany tutaj bank musi istnieć w aplikacji Banki zapewniające stałą obsługę.
• oiLockPaymentHistory (vset) — aby obsłużyć określone przypadki, można wykluczyć rozrachunki z analizy lub aktualizacji historii płatności. Sytuacja ta występuje szczególnie wtedy, gdy płatność za jeden lub kilka rozrachunków zostaje wstrzymana za obopólną zgodą. Takie procesy mogą potrwać przez dłuższy czas. Aby uniknąć wpływu całego okresu kontrolnego na historię płatności partnera biznesowego, warto całkowicie zablokować ten rozrachunek do analizy historii płatności. W innych przypadkach ewentualnie przeprowadza się późniejsze walutowanie jako alternatywne rozwiązanie. W takim przypadku historia płatności byłaby liczona dopiero od daty waluty. Należy podać jedną z poniższych stałych w dokładnym zapisie (wielkie litery, z podkreśleniem i bez spacji):
  • UPDATE_PAYMENT_HISTORY
  • LOCK_UPDATE_PAYMENT_HISTORY
• oiAssociation (str10) — z reguły to pole może pozostać puste. Obowiązuje następująca zasada: jeśli partner jest przypisany do związku (poprzez ustawienia w danych podstawowych partnera), numer związku jest automatycznie zapisywany w rozrachunku.

• oiAssociationMember (str40) — w tym polu można podać numer członkowski związku, pod którym partner jest zarejestrowany w związku. Podczas zakładania nowego rozrachunku, numer członka stowarzyszenia zostaje przeniesiony do rozrachunku. Jeśli nie podano danych związku lub członka, dane podstawowe partnera zostają przeniesione do danych związku w rozrachunku.
• oiOwnVatIdentificationNumber (str20) — w tym polu można podać własny numer identyfikacyjny VAT, pod którym ma zostać zgłoszona dostawa wewnątrzwspólnotowa
• oiForeignVatIdentificationNumber (str20) — w tym polu można podać numer NIP partnera, pod którym ma zostać zgłoszona dostawa wewnątrzwspólnotowa
• oiSettlementGroup (str5) — to pole jest przestarzałe i nie jest już przetwarzane. Do podania grupy rozliczeniowej należy użyć analogicznego pola o wydłużonej długości 125 znaków w obszarze ExternalInterface2.
• oiChange (vset) — to pole służy do zmian w rozrachunku. Rejestrowane jest, które pole ma zostać zmienione. Aby na przykład zmienić tekst rozrachunku, użytkownik podaje w tym polu stałą OITEXT i wypełnia pole OITEXT nowym tekstem. Dla zmiany rozrachunku w polu transactionType należy podać typ dokumentu OPI_CHANGE. Dla każdego pola, które ma zostać zmienione w rozrachunku, konieczne jest osobne księgowanie częściowe ze stałą odpowiadającą temu polu oraz wartością do zmiany. Należy podać jedną z poniższych stałych w dokładnym zapisie (wielkie litery, z podkreśleniem i bez spacji):
  • OITEXT
  • INVOICELISTNUMBER
  • PAYMENTCODE
  • PAYMENTBLOCK
  • DEDUCTIONLOCK
  • REMINDERLEVEL
  • REMINDERBLOCKREASON
• serviceCode (str10) — w tym polu można w razie potrzeby podać kody usługi, a tym samym np. oznaczyć księgowanie do ujęcia w bilansie płatniczym. Podany kod usługi musi istnieć w aplikacji Kody usługi.
• serviceCodeCountryIsoCode (str2) — w tym polu można w razie potrzeby podać kod ISO kraju, dla którego ważny jest kod usługi. Musi to być ważny kod ISO.
• serviceCodeType (short) — w tym polu można w razie potrzeby podać rodzaj usługi. Rodzaj usługi służy do rozróżnienia kodów usługi według ich rodzajów.
• oiDeductionLock (bool) — poprzez to pole można ustawić blokadę potrącenia dla rozrachunku. Możliwe wartości:
  • true
  • false
• deductionInfo.deductionCode01 do 20 (str15) — w tych polach można podać rodzaje potrąceń, które mają być zastosowane do faktury, jeśli mają one różnić się od warunków określonych w profilu potrąceń partnera
• deductionInfo.deductionPercentage01 do 20 (dec 7,4) — w tych polach można podać odpowiednie wartości procentowe dla zastosowanych rodzajów potrąceń
• oiCollectiveAccountGroup (str15) — w tym polu można w razie potrzeby podać grupę kont zbiorczych. Poprzez grupę kont zbiorczych można ustalić, na które konto zbiorcze mają być księgowane należności lub zobowiązania.
  Jeśli to pole pozostanie puste, podczas przetwarzania księgowania zostanie zastosowana grupa kont zbiorczych, która jest zapisana jako wartość domyślna w profilu kont zbiorczych partnera.
  Możliwe jest jednak podanie innej grupy kont zbiorczych niż ta standardowa partnera (konta osobowego). Podana tutaj grupa kont zbiorczych musi istnieć w profilu kont zbiorczych partnera.
  W przypadku przeksięgowania kont zbiorczych należy w tym polu podać grupę kont zbiorczych, na którą rozrachunek ma zostać przeksięgowany.

Opis pól dla jednorazowych klientów i dostawców

Następujące pola (aż do pola bank.bankName) odnoszą się wyłącznie do danych adresowych i informacji o rachunku bankowym dla pseudopartnerów.

Pseudopartnerzy służą jako konto zbiorcze dla tych klientów i dostawców, z którymi prawdopodobnie zostanie nawiązana tylko jednorazowa relacja biznesowa (klienci/dostawcy jednorazowi). Dla tych klientów i dostawców nie trzeba zakładać własnych rekordów partnerów. Jeśli to konto zbiorcze zostanie użyte w księgowaniu, księgowania muszą zostać uzupełnione o adres oraz dane rachunku bankowego klienta lub dostawcy jednorazowego, aby w razie potrzeby móc wysłać przypomnienie lub dokonać płatności.

• oneTimeAddress.name (str200) — nazwa adresu jednorazowego. Tutaj można wprowadzić imię i nazwisko.
• oneTimeAddress.street (str256) — ulica adresu jednorazowego
• oneTimeAddress.city (str256) — miasto lub miejscowość adresu jednorazowego
• oneTimeAddress.postalCode (str16) — kod pocztowy adresu jednorazowego
• oneTimeAddress.district (str256) — to pole nie jest obecnie używane. Jest przewidziane do przyszłych rozszerzeń.
• oneTimeAddress.country (str2) — kraj adresu jednorazowego
• oneTimeAddress.region (str3) — region dla adresu jednorazowego. W przypadku adresów niemieckich można tu wprowadzić kraj związkowy.
• oneTimeAddress.poBox (str64) — skrytka pocztowa adresu jednorazowego
• oneTimeAddress.poBoxCity (str256) — miejscowość skrytki pocztowej adresu jednorazowego
• oneTimeAddress.poBoxPostalCode (str16) — kod pocztowy skrytki pocztowej adresu jednorazowego
• oneTimeAddress.regionCode (str10) — kod regionu adresu jednorazowego
• bank.bankAccount (str30) — numer konta bankowego, które ma zostać użyte do rozliczenia rozrachunku adresu jednorazowego
• bank.accountHolder (str80) — właściciel rachunku bankowego dla adresu jednorazowego
• bank.iban (str40) — numer IBAN dla rachunku bankowego adresu jednorazowego
• bank.bic (str11) — numer BIC dla rachunku bankowego adresu jednorazowego
• bank.bankId (str20) — numer rozliczeniowy banku dla rachunku bankowego adresu jednorazowego
• bank.bankIsoCode (str2) — kraj banku w formie kodu ISO (np. DE, IT lub FR) dla rachunku bankowego adresu jednorazowego
• bank.bankName (str65) — nazwa banku dla rachunku bankowego adresu jednorazowego

Opis pól dla ExternalInterface (część 2)

• version (str10) — to pole nie jest obecnie używane. W przyszłości ma tu być przekazywana informacja o używanej wersji.
• postingDate (stmp) — zasadniczo to pole może pozostać puste. Następuje przeniesienie daty dokumentu z pola voucherDate do tego pola. Przeniesiona tutaj data stanowi datę księgowania, na podstawie której program ustala okres księgowy, do którego dokument zostanie zaksięgowany. Ustalony okres księgowy zostaje przeniesiony do pola postingPeriod.
  Jeśli dokument ma zostać zaksięgowany w okresie innym niż wynikający z daty dokumentu, należy w tym polu podać datę, która mieści się w żądanym odmiennym okresie (format DD.MM.RRRR). Podana tutaj data służy wyłącznie do wyznaczenia okresu księgowego. Należy pamiętać, że dokument zostanie w ten sposób uwzględniony również podatkowo w odmiennym okresie. Zaleca się również zapoznanie z opisem pola taxPeriod.
• protocolNumber (str20) — to pole należy pozostawić puste. Jest przewidziane do przyszłych rozszerzeń.
• language (str4) — to pole należy pozostawić puste. Jest przewidziane do przyszłych rozszerzeń.
• reference (str40) — to pole nie musi być obowiązkowo wypełnione. Aby umożliwić powiązanie z pierwotnym księgowaniem w systemie źródłowym, można w tym polu przekazać wewnętrzny numer dokumentu z systemu źródłowego.

Opis pól dla ExternalInterface2

Poniżej opisano pola interfejsu zewnętrznego 2 (ExternalInterface2). Plik ten jest rozszerzeniem interfejsu zewnętrznego (ExternalInterface).

• oiInterestBearing (vset) — poprzez to pole użytkownik określa, czy dla rozrachunku mogą być naliczane odsetki. Jeśli w tym polu zostanie podana wartość INTEREST (oprocentowany), rozrachunek zostanie uwzględniony w kalkulacji odsetek.
  ponieważ pole to stanowi zbiór wartości, należy podać jedną z poniższych stałych w dokładnym zapisie (wielkie litery, z podkreśleniem i bez spacji):
  • INTEREST
  • NOT_INTEREST
• esrCodingLine (str59) — to pole należy stosować wyłącznie dla specjalnych wymagań obowiązujących w Szwajcarii
• esrReferenceNumber (str27) — to pole należy stosować wyłącznie dla specjalnych wymagań obowiązujących w Szwajcarii
• esrSubscribeNumber (str9) — to pole należy stosować wyłącznie dla specjalnych wymagań obowiązujących w Szwajcarii
• taxRegister (str5) — to pole należy stosować wyłącznie dla specjalnych wymagań obowiązujących we Włoszech
• deductionFreelancer (dec21,6) — to pole należy stosować wyłącznie dla specjalnych wymagań obowiązujących we Włoszech
• bankAssignment.bankAccount (str30) — numer konta bankowego, które ma zostać użyte do rozliczenia rozrachunku
• bankAssignment.accountHolder (str80) — właściciel rachunku bankowego
• bankAssignment.iban (str40) — numer IBAN dla rachunku bankowego konta osobistego
• bankAssignment.bic (str11) — numer BIC dla rachunku bankowego konta osobistego
• bankAssignment.bankId (str20) — numer banku dla rachunku bankowego konta osobistego
• bankAssignment.bankIsoCode (str2) — kraj banku w formie kodu ISO (np. DE, IT lub FR) dla rachunku bankowego konta osobistego
• bankAssignment.bankName (str65) — nazwa banku dla rachunku bankowego konta osobistego
• externalKey 1–10 (str65) — pola externalKey1-10 nie muszą być obowiązkowo wypełnione. Poprzez te klucze zewnętrzne użytkownik ma możliwość zapisywania wartości dla zewnętrznych identyfikatorów przy rozrachunku. Te identyfikatory mogą być następnie wykorzystywane podczas wyszukiwania rozrachunku.
• transactionDate (stmp) — to pole należy stosować wyłącznie dla specjalnych wymagań obowiązujących w Polsce
• invoiceReceiveDate (stmp) — to pole należy stosować wyłącznie dla specjalnych wymagań obowiązujących w Polsce
• mandateReference (str35) — w tym polu można podać referencję według autoryzacji dla poleceń zapłaty SEPA. Jeśli pole to pozostanie puste, przy poleceniach zapłaty SEPA automatycznie zostanie zastosowana preferowana referencja według autoryzacji zapisana przy partnerze w rozrachunku. Warunkiem jest, aby dla pochodzenia w polu origin(vset) podano wartość EXTERNAL_SYSTEM (z systemu zewnętrznego).
• archiveID (str125) — to pole jest używane wyłącznie wewnętrznie do integracji z ECM i dlatego należy je pozostawić puste
• documentType (str5) — to pole jest używane wyłącznie wewnętrznie do integracji z ECM i dlatego należy je pozostawić puste
• adjustmentPercentage (dec 5,2) — to pole ma znaczenie wyłącznie dla prognozowania w zarządzaniu płynnością. Jeśli wartość rozrachunku nie ma być uwzględniana w prognozach zarządzania płynnością w pełnej wysokości, należy tutaj podać procent, o jaki wartość ma zostać pomniejszona.
• excludeFromProjection (vset) — jeśli użytkownik korzysta z zarządzania płynnością, może poprzez to pole sterować, czy rozrachunek ma być uwzględniany w prognozach, czy też ma być z nich wyłączony. Można podać następujące stałe w dokładnym zapisie (wielkie litery, z podkreśleniem i bez spacji):
  • EXCLUDE
  • INCLUDE
• cFDIFiscalNumber (str36) — numer księgowy CFDI dotyczy wyłącznie wersji krajowej dla Meksyku
• targetExchangeAmount (dec 21,6) — przy księgowaniach walutowych użytkownik może tutaj podać kwotę do zaksięgowania w podstawowej walucie krajowej. Na podstawie tej wartości kurs zostanie przeliczony na nowo.
• ServiceCodeServiceCountry (str2) — to pole jest istotne dla bilansu płatniczego. tutaj można podać kod ISO kraju handlowego. Musi to być prawidłowy kod ISO kraju z aplikacji Kraje.
• ServiceCodeImportExport (vset) — to pole jest istotne dla bilansu płatniczego. Poprzez podanie wartości w tym polu użytkownik określa kierunek handlu. Należy podać jedną z następujących stałych w dokładnym zapisie (wielkie litery, z podkreśleniem i bez spacji):
  • IMPORT
  • EXPORT
• writeOffCode (vset) — to pole nie jest obecnie przetwarzane
• forceCreateNewOi (bool) — to pole jest istotne przy tworzeniu otwartych postów, jeśli w ramach jednej płatności powstaje różnica do rozliczenia. pole to należy zawsze wypełnić jedną z poniższych wartości:
  • true — wartość true oznacza, że zawsze tworzony jest nowy rozrachunek. W konsekwencji może się zdarzyć, że powstaną dwa rozrachunki o tym samym numerze.
  • false — jako wartość domyślną należy zasadniczo podać false. Ta wartość powoduje, że księgowanie następuje zawsze na już istniejący rozrachunek. Jeśli nie istnieje żaden rozrachunek, wówczas tworzony jest nowy.
• infoString 1–3 (str65) — te pola nie są obecnie uwzględniane i dlatego należy je pozostawić puste
• infoDate 1–3 (stmp) — te pola nie są obecnie uwzględniane i dlatego należy je pozostawić puste
• infoNumber 1–3 (int) — te pola nie są obecnie uwzględniane i dlatego należy je pozostawić puste
• riskType (vset) — rozrachunki, które są rozliczane przez weksel lub polecenie zapłaty RIBA, należy do czasu ich ostatecznego terminu płatności klasyfikować jako ryzyko. Poprzez typ ryzyka użytkownik może określić, czy dany rozrachunek stanowi ryzyko RIBA, ryzyko wekslowe lub brak ryzyka. Należy podać jedną z następujących stałych w dokładnym zapisie (wielkie litery, z podkreśleniem i bez spacji):
  • NO_RISK
  • RIBA
  • DRAF
• riskExpirationDate (stmp) — dla rozrachunku oznaczonego jako ryzyko można w tym polu podać datę wygaśnięcia ryzyka. Wartość ta może być podana jako termin płatności dla poleceń zapłaty RIBA w płatnościach.
• riskNumber (str40) — jeśli rozrachunek został oznaczony jako ryzyko (ryzyko wekslowe lub RIBA), w tym polu należy podać numer dla danego przypadku ryzyka. Numer ten jest automatycznie nadawany przez system płatności w momencie księgowania poleceń zapłaty RIBA. W aplikacji Lista: Ryzyka można przy użyciu numeru ryzyka wyświetlić odpowiedni rozrachunek.
• currencyOfCurrencyDifference (str3) — przy księgowaniu różnic kursowych wynikających z ponownej wyceny waluty obcej, użytkownik podaje w tym polu walutę obcą, która ma zostać ponownie wyceniona
• defermentCode (str15) — jeśli księgowanie ma zostać ujęte w okresowym rozliczeniu międzyokresowym, należy tutaj podać właściwy kod rozliczenia. W ramach klucza rozliczenia zdefiniowane są m.in. kontowanie księgowań rozliczających oraz okres obowiązywania rozliczenia.
• startDateDeferment (stmp) — to pole jest istotne tylko wtedy, gdy podano kod rozliczenia międzyokresowego. Tutaj użytkownik podaje datę, od której ma się rozpocząć rozliczenie tego księgowania. Na podstawie tej daty wyznaczany jest okres rozliczenia. Jeśli pole to pozostanie puste, data początkowa zostanie wyznaczona na podstawie daty dokumentu z uwzględnieniem pól Opóźnienie początku w miesiącach oraz Okres likwidacji określonych w podanym kodzie rozliczenia międzyokresowego.
• endDateDeferment (stmp) — to pole jest istotne tylko wtedy, gdy podano kod rozliczenia międzyokresowego. Zakończenie okresu rozliczenia wyznaczane jest automatycznie na podstawie daty początkowej oraz z uwzględnieniem pól Czas wykonania w miesiącach i Okres likwidacji w podanym kodzie rozliczenia międzyokresowego. Jeśli pole Czas wykonania modyfikowalny zostało tam aktywowane, użytkownik może tutaj podać datę zakończenia.
• firstRateAmount (dec 21,6) — to pole jest istotne tylko wtedy, gdy podano kod rozliczenia międzyokresowego. Wyliczenie kwot rozliczenia następuje zasadniczo poprzez podzielenie całkowitej kwoty rozliczenia przez liczbę okresów lub miesięcy przeznaczonych na rozliczenie. W tym polu użytkownik może ręcznie podać inną kwotę dla pierwszej raty rozliczenia. Może to być konieczne np. wtedy, gdy dokument księgowy obejmuje także już zamknięte okresy księgowe. Kwoty przypadające na te zamknięte okresy mogą wówczas zostać ujęte jako podwyższone rozliczenie w pierwszym ponownie otwartym okresie.
• firstRateCurrency (str3) — to pole jest istotne tylko wtedy, gdy podano kwotę dla pierwszej raty. Tutaj użytkownik podaje walutę, w której wprowadzono kwotę.
• deductions.deductionCode 01–20 (str15) — jeśli przy płatności mają być uwzględnione potrącenia, takie jak skonto, rabat itp., Użytkownik może w tych polach podać odpowiedni rodzaj potrącenia.
• deductions.deductionAmount 01–20 (dec 21,6) — w tych polach użytkownik podaje kwotę potrącenia (rzeczywiste potrącenie), która ma zostać uwzględniona dla danego rodzaju potrącenia
• deductions.deductionDebitCredit 01–20 (vset) — w tych polach użytkownik określa dla każdej podanej kwoty potrącenia, czy potrącenie stanowi wartość po stronie winien czy po stronie ma. Należy podać jedną z następujących stałych w dokładnym zapisie (wielkie litery, z podkreśleniem i bez spacji):
  • DEBIT
  • CREDIT
• automaticReversal (bool) — to pole należy zawsze wypełnić jedną z następujących wartości:
  
  • true — wartość true oznacza, że ten dokument jest automatycznym dokumentem storna
  • false — wartość false oznacza, że ten dokument nie jest automatycznym dokumentem storna
• oiSettlementGroup (str125) — w tym polu można podać grupę rozliczeniową. Grupy rozliczeniowe są częścią mechanizmu ustalania warunków i służą do podziału potrąceń w aplikacji Stopy procentowe potrącenia. Znaczenie grupy rozliczeniowej użytkownik może zdefiniować samodzielnie. Przykładowo, można za ich pomocą oznaczyć określone potrącenia obowiązujące tylko w wyjątkowych przypadkach, takie jak potrącenia przy akcjach specjalnych lub sprzedaży targowej.
• handleDeductions (vset) — to pole jest uwzględniane tylko w rekordach typu przypisanie rozrachunki w ramach płatności lub rozliczeń rozrachunków. W tym polu można określić, czy potrącenia mają zostać przekazane, czy też mają być ustalone na podstawie danych z dokumentu przekazania. Można podać jedną z następujących stałych w dokładnym zapisie (wielkie litery, z podkreśleniem i bez spacji):
  
  • CALCULATE — jeśli użytkownik poda stałą CALCULATE, potrącenia zostaną ustalone na podstawie danych z dokumentu przekazania
  • AS_DELIVERED — jeśli użytkownik poda stałą AS_DELIVERED, przekazywane są istniejące potrącenia. Jeśli nie zostaną przekazane, nie nastąpi też ich ustalanie.
  • ONLY_DISCOUNT — podanie stałej ONLY_DISCOUNT powoduje, że tylko skonto zostanie przeliczone na nowo
• clearInOtherCurrency (bool) — przy płatnościach w walucie obcej użytkownik określa poprzez to pole, czy rozrachunki będą rozliczane w walucie zaksięgowanej płatności, czy w wiodącej walucie krajowej organizacji. Pole należy zawsze wypełnić jedną z następujących wartości:
  • true — jeśli użytkownik poda wartość true, można przyporządkować do rozliczenia rozrachunków we wszystkich walutach. Całe rozliczenie rozrachunku (łącznie z ewentualnymi wyksięgowaniami, tworzeniem rozrachunku itd.) następuje wtedy w podstawowej walucie krajowej organizacji.
  • false — jeśli użytkownik poda wartość false, do rozliczenia można przyporządkować tylko te rozrachunki, które zostały założone w walucie płatności
• interval (vset) — to pole nie ma obecnie żadnej funkcji, jest ono przewidziane do późniejszego przekazywania księgowań okresowych. W tym polu można ustawić, w jakim interwale ma następować pobieranie księgowań okresowych. Można podać jedną z następujących stałych w dokładnym zapisie (wielkie litery, z podkreśleniem i bez spacji):
  • ONE-TIME — jeśli użytkownik poda w tym polu stałą ONE_TIME, pobieranie księgowań okresowych odbywa się raz na miesiąc kalendarzowy, niezależnie od okresu obrachunkowego
  • PERIODIC_FY — jeśli użytkownik poda stałą PERIODIC_FY, pobieranie księgowań okresowych odbywa się według okresu księgowego określonego w okresie obrachunkowym
• distance (int) — to pole nie ma obecnie żadnej funkcji, jest ono przewidziane do późniejszego przekazywania księgowań okresowych. W tym polu użytkownik podaje interwał wykonywania księgowania okresowego w miesiącach lub okresach księgowych.
• firstCall (stmp) — to pole nie ma obecnie żadnej funkcji, jest ono przewidziane do późniejszego przekazywania księgowań okresowych. W tym polu użytkownik podaje datę rozpoczęcia wykonywania księgowania okresowego. Na podstawie tej daty zostaje ustalony okres księgowy dla pierwszego wykonania. Datę należy podać w formacie DD.MM.RRRR.
• lastCall (stmp) — to pole nie ma obecnie żadnej funkcji, jest ono przewidziane do późniejszego przekazywania księgowań okresowych. W tym polu użytkownik podaje datę zakończenia wykonywania księgowania okresowego. Na podstawie tej daty zostaje ustalony okres księgowy dla ostatniego wykonania. Datę należy podać w formacie DD.MM.RRRR.
• voucherDay (int) — to pole nie ma obecnie żadnej funkcji, jest ono przewidziane do późniejszego przekazywania księgowań okresowych. W tym polu użytkownik może podać dzień miesiąca lub okresu, w którym ma zostać wykonane księgowanie okresowe.
• executionDays (int) — to pole nie ma obecnie żadnej funkcji, jest ono przewidziane do późniejszego przekazywania księgowań okresowych. W tym polu można podać wartość z zakresu od -30 do 0 dni. Na podstawie tej wartości zostaje ustalona data wykonania dla przeprowadzenia lub ponownego utworzenia księgowania okresowego. Data ta może być wcześniejsza lub równa dacie dokumentu.
• updateCurrency (bool) — to pole nie ma obecnie żadnej funkcji, jest ono przewidziane do późniejszego przekazywania księgowań okresowych. Przy księgowaniach w walucie obcej użytkownik steruje poprzez to pole, czy kurs do przeliczenia na walutę krajową ma być za każdym razem ustalany na nowo na podstawie tabeli kursów (kursy walut). Pole należy zawsze wypełnić jedną z następujących wartości:
  • true — jeśli użytkownik poda wartość true, kurs wymiany do waluty krajowej będzie ustalany na nowo przy każdym wykonaniu
  • false — jeśli użytkownik poda wartość false, kurs wymiany nie będzie ustalany na nowo
• activatePeriodicPostings (bool) — to pole nie ma obecnie żadnej funkcji, jest ono przewidziane do późniejszego przekazywania księgowań okresowych. Poprzez to pole użytkownik określa, czy księgowanie jest aktywnym księgowaniem okresowym. Pole należy zawsze wypełnić jedną z następujących wartości:
  • true — jeśli użytkownik poda wartość true, księgowanie jest aktywnym księgowaniem okresowym. Tylko dla aktywnych księgowań okresowych można utworzyć pobrania.
  • false — jeśli użytkownik poda wartość false, księgowanie nie jest aktywnym księgowaniem okresowym
• z4ReportRequired (vset) — to pole nie ma obecnie żadnej funkcji, jest ono przewidziane do późniejszego przekazywania księgowań w celu określenia, czy dla danego księgowania wymagane jest raport Z4. Należy podać jedną z poniższych stałych w dokładnym zapisie (wielkie litery, z podkreśleniem i bez spacji):
  • NONE — ustawienie NONE powoduje, że na podstawie informacji z księgowania, takich jak np. kod usługi, zostaje ustalone, czy wymagany jest raport Z4
  • YES — przy ustawieniu YES wymagany jest raport Z4
  • NO — przy ustawieniu NO raport Z4 nie jest wymagany
• oiClearingInMainCurrencyAllowed (vset) — przy przypisaniu rozrachunków w walucie obcej określa poprzez to pole, czy przypisany rozrachunek może zostać rozliczony również w podstawowej walucie krajowej organizacji. Należy podać jedną z poniższych stałych w dokładnym zapisie (wielkie litery, z podkreśleniem i bez spacji):
  
  • ALLOWED — jeśli użytkownik podał wartość ALLOWED, przypisany rozrachunek może zostać rozliczony także w wiodącej walucie krajowej organizacji
  • NOT_ALLOWED — jeśli podano wartość NOT_ALLOWED, przypisany rozrachunek może zostać rozliczony tylko w walucie, w której został utworzony
• debtorCreditType (str3) — to pole jest istotne przy obsłudze należności kredytowych od dłużników i jest wypełniane wyłącznie wewnętrznie
• debtorCreditNumber (str10) — to pole jest istotne przy obsłudze należności kredytowych od dłużników i jest wypełniane wyłącznie wewnętrznie
• debtorCreditDetailNumber (int) — to pole jest istotne przy obsłudze należności kredytowych od dłużników i jest wypełniane wyłącznie wewnętrznie
• debtorCreditDetailSubNumber (int) — to pole jest istotne przy obsłudze należności kredytowych od dłużników i jest wypełniane wyłącznie wewnętrznie
• handleOiWriteOff (vset) — jeśli w wyniku płatności lub rozliczenia rozrachunków powstanie saldo z resztą na rozliczanym rozrachunku, użytkownik może poprzez to pole sterować automatycznym odpisaniem tej reszty. Należy podać jedną z poniższych stałych w dokładnym zapisie (wielkie litery, z podkreśleniem i bez spacji):
  • CALCULATION — jeśli podano CALCULATION, powstała reszta rozrachunku zostaje automatycznie odpisana, o ile mieści się w granicach określonych w profilu odpisów
  • NO_CALCULATION — jeśli podano NO_CALCULATION, reszta rozrachunku powstała przy rozliczeniu nie zostanie automatycznie odpisana
• paymentInformation (str125) — to pole jest wykorzystywane wyłącznie dla szwajcarskich faktur QR. Jest ono zarezerwowane jako informacja płatnicza do opisu celu płatności na fakturze QR.
• additionalPaymentInformation (str125) — to pole jest wykorzystywane wyłącznie dla szwajcarskich faktur QR. Jest ono zarezerwowane jako dodatkowa informacja płatnicza do opisu celu płatności na fakturze QR.
• taxSettlementDate (stmp) — data rozliczenia podatku służy do ustalenia okresów podatkowych dla dokumentu. Z zasady przyjmuje wartość daty dokumentu księgowanego dokumentu. Wyjątkiem jest sytuacja, gdy data dokumentu nie mieści się w podanym okresie księgowym. W takim przypadku data rozliczenia podatku przyjmuje wartość daty początkowej okresu księgowego. Odbywa się to z uwzględnieniem ustawienia w polu Data rozliczenia podatkowego w aplikacji Konfiguracja.

Jeśli użytkownik chciałby ręcznie określić okresy podatkowe stosowane do dokumentu, powinien w tym polu podać datę, według której mają być rozliczone podatki dokumentu. Na podstawie tej daty ustalane są okresy podatkowe. Datę rozliczenia podatku należy podać w formacie DD.MM.RRRR.

• declarationIndicator 1–10 (str15) — wskaźniki podatkowe są używane do uzupełniania księgowań finansowych o dane istotne do zgłoszeń. Służą również jako dodatkowe kryterium przyporządkowania pozycji podatkowych do kodu podatkowego.

• mossInvoice (str40) — pole Faktura MOSS ma znaczenie tylko wtedy, gdy użytkownik zgłasza sprzedaż do konsumentów końcowych w innym kraju UE w ramach procedury OSS i księgowanie zawiera kod podatkowy aktywowany dla OSS. W tym polu przekazywane jest odwołanie do podstawowej faktury sprzedaży, np. w przypadku korekty. W przypadku faktury sprzedaży jest to numer dokumentu jako samo-odniesienie.
• mossReferenceValue (str40) — jeśli księgowania mają być również uwzględnione przy generowaniu pliku SAF-OSS, to w tym polu należy przekazać jednoznaczne odniesienie do faktury
• mossBeneficiaryTaxPurpose (str15) — pole Beneficjent dla celów podatkowych jest istotne w przypadkach, gdy odbiorca faktury nie jest tym samym partnerem, co odbiorca towarów lub usług. Jest ono używane np. w celu sprawdzenia, czy kraj odbiorcy towarów/usług odpowiada krajowi odbiorcy wynikającemu z użytego kodu podatkowego.
• account (str50) — jeśli księgowana organizacja pracuje z hierarchicznymi kontami księgowymi, to dla kont księgi głównej należy używać wyłącznie tego pola o długości 50 znaków. W tym polu zawsze należy podać numer konta księgi głównej, gdy pole accountingCode zawiera wartość GENERAL_LEDGER. Podane konto musi istnieć w aplikacji Konta księgowe.
• collectiveAccount (str50) — to pole należy pozostawić puste
• taxAccount (str50) — to pole należy pozostawić puste. Przy przetwarzaniu księgowania z kodem podatkowym odpowiednie konto podatkowe ustalane jest automatycznie. W przypadku ręcznego wprowadzenia podatku, konto podatkowe należy podać w polu account. Pole taxAccount również w tym przypadku powinno pozostać puste.

• targetExchangeTaxAmount (dec 21,6) — to pole jest wykorzystywane wewnętrznie i ma znaczenie tylko przy przenoszeniu faktur klientów lub dostawców z systemu źródłowego Comarch ERP Enterprise. Podana tutaj kwota podatku ma zastosowanie tylko wtedy, gdy w aplikacji Konfiguracja w funkcji Wartości domyślne, pole Zastosowanie kwot faktur CEE zostało aktywowane w zakładce Pozostałe.
• assetMasterNumber (str20) — to pole jest wykorzystywane wewnętrznie i ma znaczenie tylko przy przenoszeniu faktur zakupu środków trwałych z systemu źródłowego Comarch ERP Enterprise. Podany tutaj środek trwały służy jako wartość domyślna do księgowania w księdze środków trwałych
• assetMasterSubNumber (int) — to pole jest wykorzystywane wewnętrznie i ma znaczenie tylko przy przenoszeniu faktur zakupu środków trwałych z systemu źródłowego Comarch ERP Enterprise. W razie potrzeby użytkownik może tu podać podnumer środka trwałego jako wartość domyślną do księgowania w księdze środków trwałych.
• assetGroup (str10) — to pole jest wykorzystywane wewnętrznie i ma znaczenie tylko przy przenoszeniu faktur zakupu środków trwałych z systemu źródłowego Comarch ERP Enterprise. Za pomocą grupy środków trwałych można automatycznie zakładać odpowiednie środki trwałe dla środków produkcyjnych. Atrybuty środka trwałego, np. opcjonalny wymiar, są wtedy uzupełniane w następującej kolejności:
  • Faktura sprzedaży
  • Grupa środków trwałych
• supplierInvoiceDetailNumber (int) — to pole jest wykorzystywane wewnętrznie i ma znaczenie tylko przy przenoszeniu faktur zakupu środków trwałych z systemu źródłowego Comarch ERP Enterprise. W tym polu należy podać numer pozycji faktury zakupu zawierający informacje księgowe dla dokumentu w danych podstawowych środków trwałych.
• item (str25) — to pole jest wykorzystywane wewnętrznie i ma znaczenie tylko przy przenoszeniu faktur zakupu środków trwałych z systemu źródłowego Comarch ERP Enterprise. Dla artykułu o typie materiału Środek produkcyjny mogą zostać automatycznie utworzone odpowiednie środki trwałe. artykuł ten zostaje przejęty informacyjnie do danych podstawowych środków trwałych
• inventoryIdentifier (str20) — to pole jest wykorzystywane wewnętrznie i ma znaczenie tylko przy przenoszeniu faktur zakupu środków trwałych z systemu źródłowego Comarch ERP Enterprise. W tym polu użytkownik może w razie potrzeby podać wariant artykułu do ujęcia w danych podstawowych środków trwałych. Wariant ten zostaje przejęty informacyjnie do danych podstawowych środków trwałych
• splitOnSingleAsset (bool) — to pole jest wykorzystywane wewnętrznie i ma znaczenie tylko przy przenoszeniu faktur zakupu środków trwałych z systemu źródłowego Comarch ERP Enterprise. Poprzez to pole użytkownik określa, w jaki sposób ilość pozycji zostanie rozdzielona na księgowania środków trwałych. Pole należy zawsze wypełnić jedną z poniższych wartości:
  • true — jeśli użytkownik poda wartość true, dla każdej sztuki zostanie utworzone osobne księgowanie środka trwałego
  • false — jeśli użytkownik poda wartość false, cała ilość z tej pozycji zostanie zaksięgowana jako jeden środek trwały
• assetCount (int) — to pole jest wykorzystywane wewnętrznie i ma znaczenie tylko przy przenoszeniu faktur zakupu środków trwałych z systemu źródłowego Comarch ERP Enterprise. Użytkownik podaje tutaj liczbę środków trwałych do zaksięgowania.

Import danych

W przypadku importu do księgowości finansowej użytkownik umieszcza plik z danymi do przetworzenia (np. księgowania płac) w katalogu Knowledge Store. Import obsługuje typy plików: XML, CSV i XLS. Zalecane jest użycie formatu XML, ponieważ pozwala on na zapisanie również złożonych danych w jednym pliku, umożliwia określenie i sprawdzenie schematu pliku oraz ułatwia integrację zmian w modelu danych.

Aby przeprowadzić import, użytkownik otwiera w menu Zarządzanie systemem aplikację Import danych. W tej aplikacji wybiera filtr (np. EXTERNALINTERFACE) dla następującej jednostki biznesowej:

com.sem.ext.app.fin.financialaccounting.obj.ExternalInterface

W tym filtrze wyświetlane są wszystkie pola interfejsu. Pola te są już zaznaczone do przejęcia. To ustawienie domyślne nie powinno być zmieniane.

Oprócz informacyjnie prezentowanych pól Jednostka biznesowa i Baza danych można również wprowadzić inne ustawienia dotyczące importu danych.

• Pole Ustawienie języka określa, czy atrybuty wielojęzyczne mają być importowane w jednym języku (ustawienie Jeden język) czy we wszystkich językach bazy danych (ustawienie Wielojęzyczny).
  Wartość domyślna to Wielojęzyczny. W przypadku ustawienia Wielojęzyczny można użyć tylko typu pliku XML.
• Poprzez pole Format czasu można dla danego filtra określić, w jaki sposób atrybuty czasu mają być serializowane w danych
  • W ustawieniu Forma kompaktowa serializacja jest zgodna z Comarch ERP Enterprise do wersji 5.0 włącznie
  • W ustawieniu Forma znormalizowana atrybuty czasu są rozdzielane na składniki (data, godzina, strefa czasowa) i serializowane w sposób złożony

Dla ręcznego przetwarzania lepiej nadaje się tryb Forma znormalizowana. W przypadku EDI oraz migracji danych historycznych z systemów zewnętrznych należy indywidualnie zdecydować, który tryb będzie bardziej odpowiedni. Należy pamiętać, że format czasu obowiązuje dla całego pliku.

Szczegółowe informacje na temat znaczenia poszczególnych wartości znajdują się w rozdziale Format czasu oraz w rozdziale Daty i znaczniki czasu w artykule Wprowadzenie: Wymiana danych.

Rozpoczynanie importu

1. Aby rozpocząć import, użytkownik naciska przycisk [Importuj dane] lub używa klawisza F12.
   → Otwiera się okno dialogowe Import danych.
2. W tym oknie dialogowym użytkownik może wprowadzić ustawienia dotyczące pliku importu. Na przykład w zakładce Parametry może podać ścieżkę dostępu, typ pliku, odpowiadające typowi pliku kodowanie (np. UTF-8), używany separator (np. średnik) oraz znak rozpoznawania tekstu (np. cudzysłów). Szczegółowy opis pól znajduje się w artykule Import danych w rozdziale o tej samej nazwie.
3. Użytkownik może przeprowadzić import poprzez naciśnięcie przycisku [W tle].

Jeśli nie udało się pomyślnie zaimportować pliku, użytkownik może wyświetlić wpis w dzienniku w menu Zarządzanie systemem w aplikacji Lista: Wpisy protokołu wymiany danych, aby zidentyfikować możliwe źródła błędów. Błędy należy skorygować w pliku, a następnie ponownie zaimportować plik.

Lista: Przebiegi księgowań – Księgowość finansowa

Po pomyślnym zaimportowaniu pliku do interfejsu wejściowego do księgowania, jest on dostępny do dalszego przetwarzania jako przebieg księgowania w aplikacji Lista: Przebiegi księgowań – Księgowość finansowa. Należy odświeżyć ekran po otwarciu aplikacji. Przebieg księgowania utworzony przez import ma sześć różnych kategorii statusu, które obecnie mają następujące wartości statusu.

Aby dalej przetwarzać ten przebieg księgowania, aplikacja Lista: Przebiegi księgowania – Księgowość finansowa oferuje następujące akcje za pośrednictwem roli akcji:

• [Przejmij] — jeśli ta akcja zostanie wykonana, system sprawdza, czy wszystkie dane podstawowe rekordów transakcji (konta, kody podatkowe, waluty itp.) mogą być określone poprawnie pod względem technicznym (konwersja obiektów), ale bez natychmiastowego uruchamiania księgowania dla rekordów wolnych od błędów. Jeśli rekordy zawierają błędy, są one rejestrowane.
• [Przejmij i zaksięguj] — ta akcja uruchamia księgowanie w tym samym czasie, jeśli dane nie posiadają błędów. Jeśli dane zawierają błędy, nie następuje księgowanie, a błędy muszą zostać najpierw skorygowane.

Przejmowanie i księgowanie przebiegu księgowania

Poniżej znajdziesz procedurę dla akcji [Przejmij i zaksięguj] oraz jej efekty.

Instrukcje

1. Użytkownik wybiera swój przebieg księgowania, zaznaczając pole wyboru.
2. Następnie przechodzi do roli akcji i wybiera np. [Przejmij i zaksięguj].
   → Otwiera się okno dialogowe.
3. Użytkownik uruchamia przejęcie z ustawieniami domyślnymi w tym oknie dialogowym.
4. Użytkownik aktualizuje widok w aplikacji Lista: Przebiegi księgowania – Księgowość finansowa.
5. Użytkownik sprawdza status swojego przebiegu księgowania.

Przetwarzanie bez błędów

Jeśli operacja księgowania została przetworzona bez błędów, ma następujące wartości statusu:

Nieprawidłowe

Jeśli podczas przetwarzania, przygotowywania lub księgowania wykryte zostaną błędy, przebieg księgowania zostanie oznaczony jako nieprawidłowy w odpowiedniej kategorii statusu.

Poniżej wymieniono dwa możliwe warianty błędów i opcje ich korekty.

WARIANT 1

Księgowanie nie może zostać przetworzone, ponieważ nie można określić danych podstawowych. Przykładowo, przebieg księgowania zawiera konta, które nie istnieją w księgowości finansowej.

Przebieg księgowania ma następujące wartości statusu:

• Przeniesienie = Zakończony
• Przetwarzanie = Błędny
• Przygotowanie = Oczekujący
• Księgowanie = Oczekujący
• Anulowanie = Niewystornowano

Aby poprawić nieprawidłowe dane, należy wybrać przebieg księgowania w aplikacji Lista: Przebiegi księgowania – Księgowość finansowa. Następnie użyj przycisku akcji, aby przejść do aplikacji Lista: Przeniesione dane księgowania. Tutaj można otworzyć aplikację Wygenerowane dokumenty księgowe za pomocą przycisku akcji. W tej aplikacji masz możliwość zastąpienia nieprawidłowych danych istniejącymi lub poprawnymi danymi.

Alternatywnie użytkownik może również wprowadzić brakujące dane podstawowe, a następnie ponownie przenieść nieprawidłowe księgowanie za pomocą akcji [Przejmij i zaksięguj]. Użytkownik może również anulować stare nieprawidłowe księgowanie i ponownie zaimportować plik.

WARIANT 2

Znaleziono błędy w księgowaniach podczas księgowania.

Przebieg księgowania ma następujące wartości statusu:

• Przeniesienie = Zakończony
• Przetwarzanie = Zakończony
• Przygotowanie = Zakończony
• Księgowanie: = Błędne
• Anulowanie: = Niewystornowano

Te księgowania muszą zostać poprawione ręcznie w oknie dialogowym księgowania. Źródła błędów są wskazywane przez odpowiednie komunikaty o błędach.

W aplikacji Lista: Przebiegi księgowania – Księgowość finansowa użytkownik może skorzystać z przycisku akcji, aby przejść do aplikacji Lista: Wprowadzone zapisy księgowe. W tej aplikacji użytkownik może skorzystać z akcji [Zaksięguj], aby poprawić każdy pojedynczy rekord w oknie dialogowym księgowania.

Inną opcją jest bezpośrednie wywołanie okna dialogowego księgowania i wyświetlenie nieprawidłowych rekordów z pomocą wyszukiwania wartości w celu ich edycji lub zaksięgowania.

Szczegółowy opis aplikacji Lista: Przebiegi księgowania – Księgowość finansowa można znaleźć w artykule Lista: Przebiegi księgowania – Księgowość finansowa .