Classes | |
| interface | IAccount |
| All bookings are based on COA (Chart of Accounts) accounts. IAccount interface provides access to Topal COA accounts. All postings have a link to COA account by account identity. More... | |
| interface | IAccountArea |
| All accounts divided on account areas: Assets and Liabilities accounts only placed in balance account area, Cost and Revenue accounts only placed in nominal account area. There usually two account areas – “Balance” and “Nominal”, but it is possible to create more. More... | |
| interface | IBalancePosting |
| Represents information of account statement. More... | |
| interface | IBank |
| Represents instance of Master Data bank More... | |
| interface | IBankAccount |
| Represents instance of Master Data bank account More... | |
| interface | IClient |
| Represents instance of client More... | |
| interface | ICOA |
| COA (Chat of Accounts) is an instance that contains COA Tree View. There could be one or more COA. There is main COA which is always exists called Master COA and all other COAs based on it and contain only COA elements defined in master COA. There are two collections of COA tree items: • TreeItems – is a linear sorted list of COA items • Nodes – is a collection of Top-level items, which contains their child nodes. In other words, Nodes is a COA items in tree representation. You can use one of two properties to access to the tree items depending on what is more comfortable for your case. More... | |
| interface | ICOABasedReportFilter |
| Report filter for COA based reports More... | |
| interface | ICOATreeView |
| COATreeView is a representation of a COA tree view. There are two properties, which help detect place of element within COA tree – ParentID and GroupID. Parent is an element, which is placed before current in the group. Group is a group where element is placed. More... | |
| interface | ICOAView |
| Contains information abot COA group state (collapsed/expanded) More... | |
| interface | ICostCenter |
| Represents instance of Cost Center More... | |
| interface | ICostCenterMethod |
| There is a way to distribute cost center amount between several cost centers by using Cost Center Methods. Total cost center amount will be distributed between cost centers within cost center method by percentage defined for each cost center item. Each method has only one master (cost center) instance and one or several child (cost center) instances. To make cost center method you have to create ICostCenterMethod interface instances, where you define existing master cost center instance and child cost center instance(s) with theirs percentage. Every ICostCenterMethod instance contains information only about one method item. The MasterFID property has the same value for different method items within one cost center method, the ChildFID property shows which exactly cost center instance linked to method item and its percentage. ICostCenter instance has a Methods property where you can find all ICostCenterMethod items include to the method of cost center. More... | |
| interface | ICounterDetail |
| Counter details is an item that is contained by COATreeView object in CounterDetails. It has two properties – CoaItem – is a linked COATreeView item and State – Boolean value. If state is equal to true then linked item balance added to counter balance, otherwise balance deducted. More... | |
| interface | ICountry |
| Represents instance of Master Data country More... | |
| interface | ICreditor |
| Represents instance of party creditor More... | |
| interface | ICurrency |
| Represents instance of Master Data currency More... | |
| interface | ICurrencyRate |
| Contain information abount currency rate starting from date defined in DateFrom. More... | |
| interface | IData |
| Each list of instances e.g. Currencies, Languages or Party is based on IData interface, that build a collection. By calling the GetItem method, defineing the item list index, you can acces the items in the list, where you should define the item list index. There is an alternative way to access items. You can use current property, which returns the current item in counter. To go to the next item you can call MoveNext method. If you want to start, counting again call Reset method. More... | |
| interface | IDebtor |
| Represents instance of party debtor More... | |
| interface | IDefaults |
| IDefaults provides information about default ID and numbers for different transaction type. More... | |
| interface | IDepreciation |
| interface | IFiscalYear |
| Transactions in Topal are linked to the fiscal year. A fiscal year could be closed, which means that you cannot modify any transaction within it. DateFrom and DateUntil contain the start and end of a fiscal year. The limits of a fiscal years cannot intersect with another, that means that the day after the last day of the a fiscal year is the beginning of the next fiscal year. You can set DocDateFrom and DocDateUntil within the fiscal year period. Documents, which are created within this fiscal year, should have a date within these limits. More... | |
| interface | IInterest |
| interface | IInvoice |
| Like transactions and party, an invoice number also identifies an invoice. However, there is a difference. Like party, the invoice numbers needs to be unique within a given client but not within a fiscal year. Since there are different kinds of invoices (purchase or sales), the sales and purchase invoices have their own number. Hence, it is possible that you will find different invoices with the same number but with a different person role (which actually indicates the invoice type). You can use the method free invoice number to set any number, which could not be unique. Each invoice is linked to a transaction, but there is a special case where it is not. In the first fiscal year, we store invoices without transactions if the invoice date is lower than the start date of the fiscal year. In all other cases, the transaction must be created for the invoice. All invoice payment postings are available in PaymentPostings property. More... | |
| interface | ILanguage |
| Represents isntance of Master Data langauge More... | |
| interface | IManager |
| The IManager interface is a first interface with which you start your work. It gives you the possibility to receive, delete, or save and edit data. All the functionality is encapsulated under the manager class, which connects to the server (in case of a network installation) or starts the standalone server (in case of a standalone installation), depending on the kind of installation. The first thing you do after creation is login to the Topal System. To start working with accounting you have to set the current client, fiscal year and VAT periods. Fiscal year and VAT period are global variables for a given client. The loading of any list with Manager Class will provide you with current client instances. When you create a transaction, it will be inserted in the current fiscal year, so the date of the document should correspond with the beginning and end of a fiscal year. When you logout from the Topal System, the last client used and the fiscal year will be stored. When you log in again you can set the current client manually or use the defaults. If you want to use the defaults, you need to set UseDefaults property to true before login. Usually, in order to refresh any list of instance, you have to call methods, which start with Load. In most cases, it is enough to have all information about instances within this list, but some instances have a link to other instances. For example, the ITransaction interface has a posting list. When you call the LoadTrasanctions method, you will receive only base information about transactions like document number, transaction type etc. If you want to load the whole transaction, you have to call LoadTransaction methods that provides you with transaction with linked posting. To call LoadTransaction you have to refresh the whole transaction list, but if you know the document number, you can use FindTransaction method where you have to define the document number of needed transaction. Similar methods (approach) are available for all “complex” interfaces, which have a link to other interface(s) – IInvoice, IParty. More... | |
| interface | INumRange |
| A document number identifies every transaction, which is unique within a given fiscal year. You may use different range of numbers Topal Systems sets this number: When you select a number range, you will receive the current number of this particular range. However, you are not required to use this number, you may set one yourself. However, if you enter a number that already exists in another transaction, the Topal system will automatically set the number to the next available number in the given range. More... | |
| interface | IPartner |
| interface | IParty |
| As the transaction, its own unique number identifies the Party instance, but unlike to the transaction, this number is unique for the whole client, not only for the current fiscal year. The origin for these numbers is controlled by the system in the same way as the document number for transactions. IParty has an interface IDebtor and ICreditor. Use the LoadParty method or use FindParty first to find the party number. Before you can create a debtor or a creditor that is linked to party (by partyFID) you have to save the party. More... | |
| interface | IPayment |
| IPayment represents the manual payment entity of Topal. It contains IPaymentDetail lists. To pay some invoice you have to use one of two methods: PayInvoice - add payment with amounts based on invoice balance so after payment invoice balance will be zero. PayInvoiceCustom – allow to pay custom amount of invoice. One manual payment could contain more than one invoice but these invoices should be linked to the same party and to same person role of a party (debtor/creditor). Each payment is a transaction. So it is necessary to fill transaction properties such a document date. After payment created and invoice paid, you can call SavePayment method of IManager. More... | |
| interface | IPaymentDetail |
| Each instance of IPaymentDetail contains link to paid Invoice and complete information about payment of invoice including pay amount, write off and discount. More... | |
| interface | IPayMethod |
| interface | IPayTerm |
| interface | IPayTermDetail |
| interface | IPayType |
| interface | IPerson |
| interface | IPosting |
| interface | IRepLanguage |
| interface | IReport |
| IReport interface represents report instance of Topal Reporting System. It has name and type. The type and name are not unique, so there could be few report of same type or name. Most of reports are common for all clients. However some reports could be client specific. Report of type GL_VAT_OFFICIAL_SAVED that contains VAT Report is always client specific. There are following report types: More... | |
| interface | IReportFilter |
| Base report filter More... | |
| interface | IReportJob |
| IReportJob is a collection of report created in Topal Reporting System and printed out in one document. See also IReport for additional information. More... | |
| interface | ITransaction |
| interface | IUserAccount |
| interface | IUserGroup |
| interface | IVAT |
| interface | IVATPeriod |
| VAT has its own rate, quote and other attributes. Legislation could change (new VAT %) and so you would have to create a new VAT period with new VAT values. More... | |
Enumerations | |
| enum | AccountType { None = TzAccountTypeEnum.None, Assets = TzAccountTypeEnum.Assets, Liabilities = TzAccountTypeEnum.Liabilities, Revenue = TzAccountTypeEnum.Revenue, Cost = TzAccountTypeEnum.Cost } |
| There are two different account areas in the COA, Balance and Nominal. Only Assets and Liabilities account can exist in Balance area and only Revenue and Costs accounts in Nominal area. This enumerator shows the Type of an account. More... | |
| enum | BankAccountType { None = TzBankAccountType.None, BankAccount = TzBankAccountType.BankAccount, PostalAccount = TzBankAccountType.PostalAccount, GLAccount = TzBankAccountType.GLAccount } |
| In Topal, you can create different bank account for several reasons. It will influence the transaction method and consequently payments. More... | |
| enum | COATreeViewType { None = TzTreeItemType.None, Account = TzTreeItemType.Account, AccountGroup = TzTreeItemType.AccountGroup, Counter = TzTreeItemType.Counter, AccountMirror = TzTreeItemType.AccountMirror, AccountCopy = TzTreeItemType.AccountCopy, Result = TzTreeItemType.Result, Comment = TzTreeItemType.Comment } |
| Type of COA Tree elements More... | |
| enum | CopyBudgetType { NotCopy = TzCopyBudgetKind.NotCopy, Zero = TzCopyBudgetKind.Zero, CurrentBalance = TzCopyBudgetKind.CurrentBalance, CurrentBudget = TzCopyBudgetKind.CurrentBudget } |
| enum | PaymentType { All = TzPaymentType.All, None = TzPaymentType.None, ESR = TzPaymentType.ESR, RoterESBank = TzPaymentType.RoterESBank, RoterESPost = TzPaymentType.RoterESPost, RoterESTreuhand = TzPaymentType.RoterESTreuhand, LSV = TzPaymentType.LSV, Manual = TzPaymentType.Manual, Postmandant = TzPaymentType.Postmandant, Fremdwauhrung = TzPaymentType.Fremdwauhrung, IBAN = TzPaymentType.IBAN } |
| There are several payment types available for making money transfer through the payment system. The invoice has a field that shows how it will be paid (paymethodFID). Payment method instance has a field, which defines a Payment type of this method. More... | |
| enum | PersonRole { PersonRole.Party = TzPersonRole.PartyPerson, PersonRole.Debtor = TzPersonRole.DebtorPerson, PersonRole.Creditor = TzPersonRole.CreditorPerson } |
| Person Role enumerator are used in several places. You see that in Party instances. In order to see to which kind of instance a Person is linked, check the person role field. The same field shows the type of the invoice – sales or purchase. The payment type and payment method instance also use this field to indicate the kind of Party instance to which it is linked or applicable. More... | |
| enum | PostingType { None = TzPostingType.None, Compound = TzPostingType.Compound, Invoice = TzPostingType.Invoice, Payment = TzPostingType.Payment, WriteOff = TzPostingType.WriteOff, Discount = TzPostingType.Discount, Fee = TzPostingType.Fee, Difference = TzPostingType.Difference } |
| When you create a transaction, you should add at least two postings to it. Actually, a posting is a booking. The type of posting depends on the type of transaction. When you create an invoice, in most cases an invoice transaction is created (remember the exception, invoices before the first fiscal year do not need transactions). The postings of this transaction will be an Invoice type (???). Payment is also a transaction, which pays an invoice, deducts a discount from it or writes off an amount. The corresponding postings will be created for these actions; their types will show you what a particular posting means. More... | |
| enum | TransactionType { TransactionType.None = TzTransactionType.None, TransactionType.Simple = TzTransactionType.Simple, TransactionType.Compound = TzTransactionType.Compound, TransactionType.Invoice = TzTransactionType.Invoice, TransactionType.Payment = TzTransactionType.Payment } |
| Transaction Type enumerator shows the type of a transaction. There are several types; usually it depends in which window the transaction has been created. In the invoice window, you create an invoice type transaction, in the payment window a payment type transaction. More... | |
| enum | UserGroupType { Unknown = 0, Admin = 1, PowerUser = 2, Guest = 3 } |
|
strong |
There are two different account areas in the COA, Balance and Nominal. Only Assets and Liabilities account can exist in Balance area and only Revenue and Costs accounts in Nominal area. This enumerator shows the Type of an account.
|
strong |
In Topal, you can create different bank account for several reasons. It will influence the transaction method and consequently payments.
|
strong |
Type of COA Tree elements
|
strong |
There are several payment types available for making money transfer through the payment system. The invoice has a field that shows how it will be paid (paymethodFID). Payment method instance has a field, which defines a Payment type of this method.
|
strong |
Person Role enumerator are used in several places. You see that in Party instances. In order to see to which kind of instance a Person is linked, check the person role field. The same field shows the type of the invoice – sales or purchase. The payment type and payment method instance also use this field to indicate the kind of Party instance to which it is linked or applicable.
| Enumerator | |
|---|---|
| Party | Party person |
| Debtor | Debtor person |
| Creditor | Creditor person |
|
strong |
When you create a transaction, you should add at least two postings to it. Actually, a posting is a booking. The type of posting depends on the type of transaction. When you create an invoice, in most cases an invoice transaction is created (remember the exception, invoices before the first fiscal year do not need transactions). The postings of this transaction will be an Invoice type (???). Payment is also a transaction, which pays an invoice, deducts a discount from it or writes off an amount. The corresponding postings will be created for these actions; their types will show you what a particular posting means.
|
strong |
Transaction Type enumerator shows the type of a transaction. There are several types; usually it depends in which window the transaction has been created. In the invoice window, you create an invoice type transaction, in the payment window a payment type transaction.