Visma Net
About posting settings
The Inventory workspace of Visma Net is tightly integrated with the General ledger workspace.
Depending on the
configuration settings selected for the Inventory workspace, the inventory transactions
can be automatically posted to the general ledger each time an inventory transaction
is released. Posting classes give you great flexibility to create appropriate rules
for choosing accounts to be updated in the general ledger by specific inventory
transactions.
The settings used to configure the level of integration between the Inventory and General ledger workspaces are located on the General settings tab of the Inventory preferences (IN101000) window. The following options are available:
- Update general ledger:
If this option is selected, transactions originating in the Inventory workspace will update the general ledger.
If this option is cleared, inventory transactions do not update the general ledger, and the inventory can be maintained independently from the General ledger workspace. - Post summary when updating the general ledger:
If this option is selected, only summary information (for the account / subaccount pair) will be included into the batch.
If this option is cleared, the detailed information for each document line will be included in the batch generated for the document. - Automatically post on release:
If this option is cleared, inventory transactions will not be automatically posted to the general ledger on release of Inventory documents; they should be posted through the General ledger workspace. If this option is selected, inventory transactions will be posted on the release of inventory documents.
A posting class groups stock or non-stock items by the way general ledger accounts
are selected for posting specific transactions to the general ledger.
The posting class
also provides the account and subaccount to be used if the source of general ledger
accounts for a transaction is a posting class itself.
You create posting classes using the Posting classes (IN206000) window.
You can assign a posting class to an item class as the default
posting class for stock items of the item class.
You can also assign a posting
class to a stock item using the Stock items (IN202500) window and to a non-stock item using the Non-stock items (IN202000) window.
A posting class defines the rules for selecting general ledger accounts and
subaccounts to be used for transactions with items assigned to the posting class.
When a transaction with an item is performed, several similar accounts are
involved.
For example: When a stock item is received at a particular warehouse, a
debit amount can be recorded to either the inventory account associated with the
warehouse or the inventory account associated with the item. Subaccounts
for various types of transactions can be combined from multiple involved subaccounts
depending on the policies established in your organisation.
Accounts and subaccount
segment values can be chosen from the following sources:
- Item
- Warehouse
- Posting class
For more details about using posting classes, see: About posting classes: definition and usage.
If inventory transactions are generated from the Purchases or Sales workspace, the system will use the purchase accrual account (for purchase receipts) or the COGS account (for sales orders). The offset account and subaccount for a receipt, issue, adjustment, or transfer are determined by the document's reason code, which is selected depending on the specific transaction being performed. For different types of inventory transactions, different types of offset accounts should be selected. Reason codes also can be used to gather statistics about specific inventory transactions.
You define reason codes in the Reason codes (CS211000) window.
Each reason code is associated with the type of inventory
transaction it will be used for.
For each type of inventory transaction, multiple
reason codes can be created if necessary to further categorise transactions within
their types.
By using the Inventory preferences (IN101000) window, you can define the reason
codes used most frequently with each type of as the default reason codes for types
of transactions.
The reason code serves the same two purposes as the posting class does:
- To define the sources of the offset subaccount segment values on a per-segment basis
- To provide the offset account and offset subaccount, if the source is the reason code itself
For more information on using reason codes, see: About reason codes: definition and usage.