Module 1. Episode 2. Types of Accounts


Very soon after money was invented, it turned out that it likes to be counted. By the mid 15 century, some smart Italian guys
came up with the accounting as we know it today. Some 500 years later,
the 1C:Enterprise Platform finally made it possible to build
your own accounting system without getting a degree
in computer science first. So, let’s see what 1C:Enterprise
has in store for us. The main Metadata Classes we use for accounting purposes in 1C:Enterprise are Charts of Accounts and Accounting Registers. The Chart of Accounts is,
basically, a catalog that we store all our accounts in. Besides our old friends – Reference, Code and Description predefined attributes, we’ve got some Chart of Accounts specifics. Namely the AccountType and OffBalance fields, we’re going to look at later in this episode. As for the Accounting Register, we use it to store the financial
transactions like purchases, sales and stuff like that. Normally, each financial transaction writes at least two records
into the Accounting Register. one record debiting an account and the second one crediting another account. In real-life there will be more than two records more often than not, but the total debited amount has to be equal to the total credited one within each transaction. Each individual record
of the Accounting Register refers to a specific account in the Chart, has its RecordType (Debit or Credit), knows what amount has been debited or credited and what document has posted this transaction. So, this is our diagram. Now, let’s implement it in the flesh and see how it works. OK, first things first. Сreating the Chart of Accounts and changing its Code length like this. These are the standard attributes
hardwired into any account. Here we already have the Reference, Code, and Description attributes, as well as the account Type, (not to be confused with the Record Type in the Accounting Register) and the OffBalance flag. Looks like we have all we need here. Now to the Accounting Register. Creating a new one. Let’s call it GeneralLedger like this. And this is how we tell the register what Chart of Accounts to use. Let’s see what we’ve got in the standard attributes department. and here are our Account, and RecordType attributes, as well as the Recorder which is nothing but a Document the record belongs to. The only thing missing here is the Amount field, so we need to add it to the register’s resources like this. To start playing with the register we also need a document
that posts some data to it. So, let’s create a new Document, call it BusinessTransactions, and this is where we will list all the records to be posted to the register. Let’s see what attributes we need to fill out these registers fields. We need a reference to an account, so I’m adding it like this. Then we need a record type,
that tells the register what side of an account this record goes to – Debit or Credit. So, let’s create an Enumeration storing these two values first, and then add the attribute of this type to the document’s tabular section. And the last thing we need
is the Amount attribute. So here it goes. Now, let’s post the document’s
records to the register. Running the wizard. Telling it to take the records from this tabular section. Mapping the register fields to the tabular section fields. And this is our Posting event handler. It cycles through the tabular section lines, creates a new register record for every line and fills out the register record’s attributes. The only thing is to be fixed here is this RecordType assignment. The wizard has set it to Debit but we might have different record type for each record, so I’m changing this piece of code like this. So, now all the financial transactions we want will go to the register through this document. Now let’s go here and look at the form I built behind the scenes
to show how it all works. So, this is what I did. I took our Chart of Accounts, Business Transactions document, And both Main and Balance tables
of the Accumulation Register and read them all to the form using these four dynamic lists. Then I placed them on the form using groups in a way that Chart of Accounts and Business Transactions documents go the left side of the form, and the Main and Balance tables of the Accounting register go to the right. And this is what it looks like in the runtime. This is a new Accounting subsystem, and this is the form we will play with. Now let’s create a couple of accounts and see how records posted to these accounts are processed by the accounting register depending on the account type and off-balance flag. So, I’m creating the Assets account having the type Active and Liabilities account having the type Passive. Now let’s register a business transaction that debits the Assets account with five bucks and credits the Liabilities one with the same amount of money. As soon as I post this document, these two records get copied to the Main table of the Accounting register and the register automatically
recalculates its balances. As you can see, besides
the usual Balance field, the Accounting register also has separate Debit and Credit balances. Active accounts are expected to have a debit balance, and it will be displayed
as is in the Balance field. Passive accounts, on the other hand, are supposed to have a credit balance, and it gets displayed in the Balance field with a minus sign. What will change
if balances are negative? Well, not much, really. If I credit the Active account and debit the Passive one, like this, all balances will stay put but will change their signs. Now let’s try this. I’m changing both accounts types to Active/Passive, reposting the document, and now the negative balance is reported in the Credit balance field, while the positive one
went to the Debit balance. Let’s reverse the transaction like this, and again the positive balance is reported on the Debit side and the negative one – on the Credit. So, here is a summary of how different types of account work. First of all, an account type
is set in a Chart of Accounts and affects how an Accounting
register balance is calculated. More specifically, what is called Active account in 1C:Enterprise is also known as a debit account or an account with the debit normal balance. Accounts of this type always show their balance on the debit side of Accounting registers. Passive accounts are known as Credit accounts or account with Credit normal balance. These guys always show their balance on the Credit side of Accounting registers. Active and Passive accounts
never swap the balance side regardless of whether they’re positive or negative. Unlike the Active/Passive accounts that have no normal balance and show the positive
balances on the Debit side and the negative ones on the Credit side. So, these are our account types. If I’d like to replace
1C Active and Passive terms with something else,
this is what I would do. The system enumeration
storing the account types lives here and is called AccountType. Let’s remember this name and open the form we were playing with. This is the dynamic list of accounts, So, I’m replacing the standard query with a slightly different version that compares account type to this enumeration values and maps them to whatever I want to call them. And let’s also change the title of this field, like this. I would also need to fix this account form we use to edit accounts. Changing the title. Turning on this flag to manually specify the list of values to choose from. And here is the list I want instead of the standard one. Let’s see. This is our form. And these are account type names I got used to. Let’s turn these two accounts back to Debit and Credit and see what this
off-balance flag is good for. So, here is the deal. In our first transaction we debit the exact
same amount we credit. We can add another account, and create a transaction consisting of more than two records, and it will be fine as long as the sum of all debits is equal to the sum of all credits. What happens if I break the equation? This is what. The Platform tracks the disbalance and doesn’t let the transaction in. OK. Now, I’m clearing records posted by this transaction, checking these off-balance flags for all the accounts, and now, all of a sudden, I can post this unbalanced
transaction no problem. But if I make even one
of the accounts on-balance, the whole party won’t go anywhere. So, these are different account types and how they work in 1C:Enterprise.

Leave a Reply

Your email address will not be published. Required fields are marked *