Sales and purchase are two essential business areas in all companies. In many organizations, the salesperson or the purchase department are the ones responsible for generating quotes and orders. People from the finance area are the ones in charge of finalizing the sales and purchase processes by issuing the documents that have an accountant reflection: invoices and credit memos.
In the past, most systems required someone to translate all the transactions to accountancy language, so they needed a financier to do the job. In Dynamics NAV, anyone can issue an invoice, with zero accounting knowledge needed. But a lot of companies keep their old division of labor between departments. This is why we have decided to explain the sales and purchase processes in this book.
This chapter explains how their workflows are managed in Dynamics NAV.
In this chapter, you will learn the following:
What Dynamics NAV is and what it can offer to your company
How to define the master data needed to sell and purchase
How to set up your pricing policies
What kind of documents you can issue
The workflows inside the sales and purchase area
Dynamics NAV is an Enterprise Resource Planning (ERP) system aimed at small and medium-sized companies.
An ERP is a system, a piece of software, that integrates the internal and external management information across an entire organization. The purpose of an ERP system is to facilitate the flow of information between all business functions inside the boundaries of the organizations. An ERP system is meant to handle all the organization areas on a single software system. This way, the output of an area can be used as an input of another area.
Dynamics NAV 2016 covers the following functional areas:
Financial Management: This includes accounting, G/L budgets, account schedules, financial reporting, cash management, receivables and payables, fixed assets, VAT reporting, intercompany transactions, cost accounting, consolidation, multicurrency, and intrastat
Sales and Marketing: This area covers customers, order processing, pricing, contacts, and marketing campaigns
Purchase: The purchase area includes vendors, order processing, approvals, planning, costing, and other such areas
Warehouse: In the warehouse area, you will find inventory, shipping and receiving, locations, picking, and assembly
Manufacturing: This area includes product design, capacities, planning, execution, costing, and subcontracting
Job: Within the job area, you can create projects, phases and tasks, planning, time sheets, work in process, and other such areas
Resource Planning: This helps you to manage resources, capacity, and so on.
Service: Within this area, you can manage service items, contracts, order processing, planning and dispatching, and service tasks
Human Resources: This helps you to manage employees, absences, and so on
Some of these areas will be covered in detail in this book.
Dynamics NAV offers much more than robust financial and business management functionalities. It is also a perfect platform to customize the solution to truly fit your company's needs. If you have studied different ERP solutions, by now you would know that customizations to fit your specific needs will always be necessary. Dynamics NAV has a reputation as being easy to customize, which is a distinct advantage.
Since you will probably have customizations in your system, you might find some differences with what is explained in this book. Your customizations could imply the following:
You have more functionality in your implementation
Some steps are automated, so some manual work can be avoided
Some features behave different from what they explained here
There are new functional areas in your Dynamics NAV
In addition, Dynamics NAV has around forty different country localizations that are meant to cover country-specific legal requirements or common practices.
Many people and companies have already developed solutions on top of Dynamics NAV to cover horizontal or industry-specific needs, and they have registered their solution as an add-on, such as the following:
Solutions for the retail industry or the food and beverages industry
Electronic Data Interchange (EDI)
Quality or maintenance management
Integration with third-party applications such as electronic shops, data warehouse solutions, or CRM systems
These are just a few examples. You can find almost 2,000 registered third-party solutions that cover all kinds of functional areas. If you feel that Dynamics NAV does not cover your needs and you will need too much customization, the best solution will probably be to look for an existing add-on and implement it along with your Dynamics NAV.
Anyway, with or without an add-on, we said that you will probably need customizations. How many customizations can you expect? This is hard to tell as each case is particular, but we'll try to give you some highlights.
If your ERP system covers 100 percent of your needs without any customization, you should worry. This means that your procedures are so standard that there is no difference between you and your competence. You are not offering any special service to your customer, so they are only going to measure you by the price they are getting.
On the other hand, if your Dynamics NAV only covers a low percentage of your needs, it could just mean two things: this is not the product you need, or your organization is too chaotic and you should re-think your processes to standardize them a bit.
Some people agree that the ideal scenario would be to get about 70-80 percent of your needs covered out of the box, and about 20-30 percent as customizations to cover those needs that make you different from your competitors.
In order to use Dynamics NAV, all organizations have to use the Financial Management area. It is the epicenter of the whole application. Any other area is optional and their usage depends on the organization's needs. The sales and the purchase areas are also used in almost any Dynamics NAV implementation.
Actually, accountancy is the epicenter, and the general ledger is included inside the Financial Management area. In Dynamics NAV, everything leads to accounting. It makes sense as accountancy is the act of recording, classifying, and summarizing, in terms of money, the transactions and events that take place in the company.
Every time the warehouse guy ships an item, or the payment department orders a transfer, these actions can be written in terms of money using accounts, credit, and debit amounts.
An accountant could collect all the company transactions and translate them one by one to the accounting language. But this means manual duplicate work, a lot of chances of getting errors and inconsistencies, and no real-time data.
On the other hand, Dynamics NAV is capable of interpreting such transactions and translating them to accountancy on the fly. In Dynamics NAV, everything leads to accountancy, so all the company's employees are helping the financial department with their job. The financers can now focus on analyzing the data and taking decisions, and they don't have to bother on entering the data anymore.
One of the first things you will face when working with Dynamics NAV is the inability to modify what has been posted, whether it's a sales invoice, a shipment document, a general ledger entry, or any other data. Any posted document or entry is unchangeable.
This might cause frustration, especially if you are used to working with other systems that allow you to modify data. However, this feature is a great advantage since it ensures data integrity. You will never find an unbalanced transaction.
If you need to correct any data, the Dynamics NAV approach is to post new entries to null the incorrect ones, and then post the good entries again. For instance, if you have posted an invoice, and the prices were wrong, you will have to post a credit memo to null the original invoice and then issue a new invoice with the correct prices:
Credit Memo 01
This nulls the original invoice
As you can see, this method that is used for correcting mistakes always leaves a track of what was wrong and how we solved it. Users get the feeling that they have to perform too many steps to correct the data with the addition that everyone can see that there was a mistake at some point. Our experience tells us that users tend to pay more attention before they post anything in Dynamics NAV, which leads to making fewer mistakes in the first place.
So another great advantage of using Dynamics NAV as your ERP system is that the whole organization tends to improve their internal procedures, so no mistakes.
Dynamics NAV does not have any kind of Save button anywhere in the application. Data is saved into the database while it is being introduced. When you enter data in one field, right after you leave the field, the data is already saved. There is no undo feature.
The major advantage is that you can create any card (for instance, customer card), any document (for instance, sales order), or any other kind of data without knowing all the information that is needed.
Imagine you need to create a new customer. You have all their fiscal data except their VAT number. You could create the card, fill in all the information except the VAT Registration No. field, and leave the card without losing the rest of the information. When you have figured out the VAT number of your customer, you can come back and fill it in. The not-losing-the-rest-of-the-information part is important.
Imagine that there actually was a Save button; you spend a few minutes filling in all the information and, at the end, click on Save. At that moment, the system carries out some checks and finds out that one field is missing. It throws you a message saying that the customer card cannot be saved. So you basically have two options:
To lose the information introduced, find out the VAT number for the customer, and start all over again.
To cheat. Fill the field with some wrong value so that the system actually lets you save the data. Of course, you can come back to the card and change the data once you've found out the right one. But nothing will prevent any other user posting a transaction with the customer in the meantime.
Master data is all the key information to the operation of a business. Third-party companies, such as customers and vendors, are part of the master data. The items a company manufactures or sells are also part of the master data.
Many other things can be considered master data, such as the warehouses or locations, the resources, or the employees.
The first thing you have to do when you start using Dynamics NAV is loading your master data into the system. Later on, you will keep growing your master data by adding new customers, for instance. To do so, you need to know what kind of information you need to provide.
We will open a customer card to see what kind of information is stored in Dynamics NAV about customers. To open a customer card, follow these steps:
Departments/Sales & Marketing/Sales/Customers.
You will see a list of customers, find No.
10000 The Cannon Group PLC.
Double-click on it to open its card, or select it and click on the View icon found on the Home tab of the ribbon.
The following screenshot shows the customer card for The Cannon Group PLC:
Customers are always referred to by their No., which is a code that identifies them. We can also provide the following information:
Name, address, and contact: A Search Name can also be provided if you refer to your customer by its commercial name rather than by its fiscal name.
Invoicing information: It includes posting groups, price and discount rates, and so on.
You may still not know what a posting group is, since it is the first time these words are mentioned on this book. At this moment, we can only tell you that posting groups are important. But it's not time to go through them yet. We will talk about posting groups in Chapter 6, Financial Management Setup.
Payments information: It includes when and how we will receive payments from the customer.
Shipping information: It explains how to ship items to the customer.
Besides the information you see on the card, there is much other information we can introduce about customers. Take a look at the Navigate tab found on the ribbon:
The other information that can be entered is as follows:
Information about bank accounts: This is so that we know where we can request the payments. Multiple bank accounts can be set up for each customer
Credit card information: This is in case customers pay using this procedure.
Prepayment information: This is in case you require your customers to pay in advance, either totally or partially
Additional addresses: This is where goods can be shipped (Ship-to Addresses).
Contacts: You may relate to different departments or individuals from your customers
Relations: This is the relation between our items and the customer's items (cross references)
Prices and discounts: This will be discussed in the Pricing section
But customers, just as any other master data record, do not only have information that users inform manually. They have a bunch of other information that is filled in automatically by the system as actions are performed:
History: You can see it on the right side of the card and it holds information such as how many quotes or orders are currently being processed or how many invoices and credit memos have been issued.
Entries: You can access the ledger entries of a customer through the Navigate tab. They hold the details of every single monetary transaction done (invoices, credit memos, payments, and so on).
Statistics: You can see them on the right side and they hold monetary information such as the amount in orders or the amount of goods or services that have been shipped but not yet invoiced.
Balance: This is a sum of all invoices issued to the customer minus all payments received from the customer.
Not all the information we have seen on the customer card is mandatory. Actually, the only information that is required if you want to create a transaction is to give it a No. (its identification) and to fill in the posting group's fields (Gen. Bus. Posting Group and Customer Posting Group). All other information can be understood as default information and setup that will be used in transactions so that you don't have to write it down every single time. You don't want to write the customer's address in every single order or invoice, do you?
Now, let's take a look at an item card to see what kind of information is stored in Dynamics NAV about items. To open an item card, follow these steps:
Departments/Sales & Marketing/Inventory & Pricing/Items.
You will see a list of items. Find item
Double-click on it to open its card.
The following screenshot shows the item card for item
As you can see in the screenshot, items first have a No., which is a code that identifies them. For an item, we can enter the following information:
Description: This is the item's description. A Search Description can also be provided if you better identify an item using a different name.
Base unit of measure: This is the unit of measure in which most quantities and other information such as Unit Price for the item will be expressed. We will see later what other units of measure can be used as well, but the Base is the most important one and should be the smallest measure in which the item can be referred.
Classification: The Item Category Code and Product Group Code fields offer a hierarchical classification to group items. The classification can fill in the invoicing information we will see in the next point.
Invoicing information: This includes posting groups, the costing method used for the item, and so on. Posting groups are explained in Chapter 6, Financial Management Setup, and costing methods are explained in Chapter 3, Accounting Processes.
Pricing information: This is the item's unit price and other pricing configuration that we will cover in more detail in the Pricing section.
Foreign trade information: This is needed if you have to do Instrastat reporting.
Replenishment, planning, item tracking, and warehouse information: These fast-tabs are not explained in detail because they are out of the scope of this book. They are used to determine how to store the stock and how to replenish it.
Besides the information you see on the item card, there is much other information we can introduce about items through the Navigate tab found on the ribbon:
As you can see, the other information that can be entered is as follows:
Units of measure: This is useful when you can sell your item either in units, boxes, or other units of measure at the same time.
Variants: This is useful when you have multiple items that are actually the same one (thus, they share most of the information) but with some slight differences. You can use variants to differentiate colors, sizes, or any other small difference you can think of.
Extended texts: This is useful when you need long descriptions or technical info to be shown on documents.
Translations: This is used so that you can show the item's descriptions in other languages, depending on the language used by your customers.
Prices and discounts: This will be discussed in the Pricing section.
As with customers, not all the information in the item card is mandatory.
We will start with third-parties-customers and vendors. They work exactly the same way. We will just look at customers, but everything we will explain about them can be applied to vendors as well. Then, we will look at items, and finally, we will take a brief look at locations and resources.
The concepts learned can be used in resources and locations, and also to other master data such as G/L accounts, fixed assets, employees, service items, and so on.
Pricing is the combination of prices for items and resources and the discounts that can be applied to individual document lines or to the whole document.
Prices can be defined for items and resources and can be assigned to customers. Discounts can be defined for items and documents and can also be assigned to customers.
Both prices and discounts can be defined at different levels and can cover multiple pricing policies. The following diagram illustrates different pricing policies that can be established in Dynamics NAV:
Sales prices can be defined in different levels to target different pricing policies.
The easiest scenario is when we have a single price per item or resource. That is, the One single price for everyone policy. In that case, the sales price can be specified on the item card or on the resource card, in a field called Unit Price.
In a more complex scenario, where prices depend on different conditions, we will have to define the possible combinations and the resulting price.
We will explain how prices can be configured for items. Prices for resources can be defined in a similar way, although they offer fewer possibilities.
To define sales prices for an item, follow these steps:
Departments/Sales & Marketing/Inventory & Pricing/Items.
You will see a list of items. Find item
1936-S BERLIN Guest Chair,
Double-click on it to open its card.
On the Navigate tab, click on the Prices icon found under the Sales group.
The Edit - Sales Prices page will open:
As you can see in the screenshot, multiple prices have been defined for the same item. A specific price will only be used when all the conditions are met. For example, a
Unit Price will be used for any customer that buys item
20/01/2017 but only if they buy a minimum of
Different fields can be used to address each of the pricing policies:
A combination of the Sales Type and Sales Code fields enable the different prices for different customer policies
The Unit of Measure Code and Minimum Quantity fields are used on the different prices per volume policy
The Starting Date, Ending Date, and Currency Code fields are used on the different prices per period or currency policy
They can all be used at the same time to enable mixed policies.
When multiple pricing conditions are met, the price that is used is the one that is most favorable to the customer (the cheapest one).
Customer 10000 belongs to the
RETAIL price group. On
20/01/2017 he buys 20 units of item
1936-S. There are three different prices that could be used: the one defined for him, the one defined for its price group, and the one defined to all customers when they buy at least
11 units. Among the three prices,
130.20 is the cheapest one, so this is the one that will be used.
Sales discounts can be defined in different levels to target different pricing policies.
We can also define item discounts based on conditions. This addresses the Discounts based on items policy and also the Discounts per volume, period or currency policy, depending on which fields are used to establish the conditions.
In the following screenshot, we can see some examples of item discounts based on conditions, which are called Line Discounts because they will be applied to individual document lines:
In some cases, items or customers may already have a very low profit for the company and we may want to prevent the usage of line discounts, even if the conditions are met.
A field called Allow Line Disc can be found on the customer card and on sales prices. By unchecking it, we will prevent line discounts being applied to a certain customer or when a specific sales price is used.
Besides the line discounts, invoice discounts can be defined to use the General discounts per customer policy. Invoice discounts apply to the whole document and they depend only on the customer.
Follow these steps to see and define invoice discounts for a specific customer:
Open the customer card for customer
The Cannon Group PLC.
On the Navigate tab, click on Invoice Discounts.
The following screenshot shows that customer
10000 has an invoice discount of 5 percent:
Just like line discounts, invoice discounts can also be disabled using a field called Allow Invoice disc. that can be found on the item card and on sales prices.
There is a third kind of discount, payment discount, which can be defined to use the Financial discounts per early payments policy. This kind of discount applies to the whole document and depends on when the payment is done. Payment discounts are bound to a Payment Term and are to be applied if the payment is received within a specific number of days.
The following screenshot shows the payment terms that can be found by navigating to
Departments/Sales & Marketing/Administration/Payment Terms:
As you can see, a 2% payment discount has been established when the 1M(8D) Payment Term is used and the payment is received within the first eight days.
Purchase prices and discounts can also be defined in Dynamics NAV. The way they are defined is exactly the same as you can define sales prices and discounts. There are some slight differences:
When defining single purchase pricing on the item card, instead of using the Unit Price field, we will use the Last Direct Cost field. This field gets automatically updated as purchase invoices are posted.
Purchase prices and discounts can only be defined per single vendor and not per group of vendors as we could do in sales prices and discounts.
Purchase discounts can only be defined per single item and not per group of items as we could do in sales discounts.
We cannot prevent purchase discounts being applied.
Purchase prices can only be defined excluding VAT.
Dynamics NAV is not an accountancy system, but an Enterprise Management system. Invoices are not the general ledger entries that resume them, but the document that you ship to your customer. The ledger entries are just a result of posting the document.
Documents are used to create transactions bound to one customer (or vendor) and to one or many items or resources.
Let's see how documents work by creating a sales invoice. There are other types of document. They will be explained in the next section.
To create an invoice such as the one in the previous screenshot, perform the following steps:
Sales & Marketing/Order Processing/Sales Invoices.
Click on the New button found on the ribbon bar.
A new blank invoice opens.
On the Sell-to Customer No. field, start typing the code
20. As you type, a drop-down list shows all the results that match the No. typed so far:
A message will tell us that the customer has an overdue balance and will ask us for confirmation to proceed. Click on Yes.
On the Line tab, create lines by filling in the fields of the following table:
Unit Price Excl. VAT
Let's explain the different types of lines that can be used:
Item: This is used when you need to sell an inventory item. When the invoice is posted, it will create an item entry to reduce its stock.
Charge (Item): This is used to adjust the costs of items. In our example, the freight charges will count as sales amount for the items, and therefore it might adjust the benefit of this particular sale. Charges can be used either on the sales and purchase area, on the same document, or in a different document. You have charged you customer for the freight; your carrier will charge you. When you get your vendor's invoice, you will need to use charges to adjust the cost of the sale.
Resource: It can be employees, machinery, or other company resources.
G/L accounts: Yes, you can also use G/L accounts in documents. In an ideal scenario, you will try to avoid them for two reasons: you need accounting knowledge to select the correct account, and you cannot define prices and other commercial info.
Fixed asset: This is used to buy or sell fixed assets.
Item charges require one extra step to be performed before the invoice is ready to post.
Select the freight charge line, and click on the Line icon and then choose the Item Charge Assignment option. Write
1in the Qty. to Assign field and close the page.
To get an overview of the invoice before it is posted, use the Statistics option found on the ribbon bar. You can also press F7 to access this option:
In this page, you can change both the fields shown in the previous screenshot.
Go back to the invoice. Choose Post from the ribbon bar or press F9.
The invoice is already posted. It has been moved from the
Sales Invoiceslist to the
Posted Sales Invoicelist. You can access it by writing
Posted Documents/Posted Sales Invoiceson the navigation bar.
The posted invoice has created multiple entries on different areas of the application. Let's see them:
General ledger entries: The system has translated the invoice to accounting language. We selected the customer, so it knew what account from group 23 to use. We sold an Item, so the system knew what income account to use, and so on. Dynamics NAV is capable to choose the right accounts, thanks to some setup tables called Posting groups. They are covered in detail in Chapter 6, Other Financial Functionalities:
TAX entries: They are created when invoices are posted. They will be used later on to post the VAT Settlement and to report VAT to the authorities:
Customer ledger entries: They are used to keep track of all the transactions posted to one customer. Customer ledger entries are also used to manage receivables. The Remaining Amount field tells us how much money the customer owes us for this invoice. It will be zero when the invoice is completely paid:
Item ledger entries: Since we sold 50 units, we need to decrease the item stock. Item ledger entries help us keep track of the company stock. It also keeps track of the Sales Amount and Cost Amount of this particular entry:
Value entries: The Sales Amount and Cost Amount shown in each Item Ledger Entry are the sum of their value entries. In future, the cost of this particular item entry might change if we post new item charges or the item gets revaluated. If any of this happens, new value entries will be created:
Resource ledger entries: The resource called
MARKworked 8 hours to assemble the item we sold. We keep track of the resource, thanks to their ledger entries. We also know the cost and total price for each entry:
As you can see, one single invoice has generated 18 different entries in different ledgers. A financer will mainly focus on general ledger and VAT entries, while the warehouse guy will focus on item ledger entries, and the resource manager will focus on resource entries. One single invoice impacts on all areas of the company. So we have demonstrated what was told in the introduction: An ERP system is meant to handle all the organization areas on a single software system. This way, the output of an area can be used as input of another area.
In the previous section, we have seen what a document is. In this section, we will see how many documents exist in Dynamics NAV, how they are related to each other, and which are the commonly used workflows to create them. We will see sales documents, but the exact same purchase documents exist in Dynamics NAV.
There are two kinds of document in Dynamics NAV:
Open documents: They hold the information that we will use to start an action or a transaction. An order, for instance, is the beginning of the action of shipping items to our customers. Open documents can be modified.
Posted documents: They hold the result of a transaction that has been posted. They can be understood as historical documents and they cannot be modified. A shipment, for instance, is the result of shipping items to our customers.
The following diagram shows the available documents that exist in Dynamics NAV. There are other warehouse-specific documents that could be used on the sales and purchase processes, but we have skipped them because they are out of the scope of this book:
Documents in white are open documents, while those in grey are posted documents.
Not all documents have to be used. Some can be skipped and some may appear multiple times. For example, you could not use Quote, Order, Shipment, Return order, and Return receipt, and thus only use Invoice, Posted invoice, Credit memo, and Posted Cr.Memo. You can also use Order, which may lead to multiple Shipments (when the order is shipped partially) and then use a single Invoice to group all shipments and end up having a single Posted Invoice. This scenario is shown in the following diagram:
Actually, in an invoice, we can group multiple shipments, no matter if they are shipments from the same order or from different orders. There is still another possible workflow, not using invoices and generating the posted invoice from the order:
There are many other possible combinations, since all the workflows we have seen could start with a quote document, for instance. We have not seen different workflows for the sales return path, but the same workflows can be used.
Dynamics NAV has a document approval functionality that can be applied over open documents to prevent users from posting them (and thus reaching the next document, a posted document) while they have not been approved.
Document approval can be set up in different ways so that not all documents have to go through an approval process. Only the documents that met certain conditions will actually require someone to approve them. We can decide the following:
Which kinds of open document will require approval.
The hierarchy of approvers. The hierarchy is based on the maximum amount each approver can approve.
The conditions that should be met to require approval for a specific document. All the possible conditions are based on the document amounts.
A workflow enables you to design and execute business processes within the application system. A simple workflow is the pairing of a single Event and a Response. For the workflow, we need to perform the following setup:
Set up workflow users: This is used to specify the users' number in a process sequence to receive notification:
Here is the Purchase Approver window:
Set up workflow notifications: This is used to specify when and how the notification will be generated:
Set up SMTP e-mail: This is used to send an e-mail saying we have to configure the SMTP server:
Workflow template: Workflow templates are non-editable workflows that exist in Dynamics NAV:
Create workflows: You can create workflows that connect with your business process, such as automatic posting, that can be included as steps in workflows, preceded or followed by user tasks. Requesting and granting approval to create new records are typical workflow steps:
The following is the setup required for the workflow configuration in NAV 2016:
Setting up approval users (including setting up a user in Windows and in Microsoft Dynamics NAV):
Create a user in active directory
Create a user in NAV and link with Windows directory
Set up Approval
Set up a workflow user group
Setting up notifications for approval users:
Create a notification schedule
Create a notification setup
Modifying and enabling an approval workflow:
View the workflow template
Create a new workflow
Starting the job queue that dispatches notifications:
Job queue setup
Requesting approval of a purchase order, as user A:
Create purchase order, after login from user A
Send the request to approve
Receiving a notification and then approving the request, as user B:
Login from user B and approve the purchase order
A G/L account is used to record all the financial transactions in Dynamics NAV. An account is a unique record for each type of asset, liability, revenue, and expense.
Now, let's take a look at a G/L card to see what kind of information is stored in Dynamics NAV. To open a G/L card, follow these steps:
Departments/Financial Management/General Ledger/Chart of Account.
You will see a list of G/L accounts. Find
11600 Bank Operations Cash.
Double-click on it to open its card.
The following screenshot shows the G/L account card for
11600 Bank Operation Cash Account:
The chart of accounts window displays all the accounts, and the G/L account card window has a card for each line in the chart of accounts, so you can work with only one account at a time.
G/L accounts are always referred to by their No., which is a code that identifies them. We can also provide the following information:
The General tab: This is used for information about G/L account number, name, and account type (balance sheet of income account)
The Posting tab: This is used for information about the general posting group and tax posting group
The Consolidation tab: This is used for information about the consolidation debit or credit account and the translation method
The Cost Accounting tab: This is used to show with which cost account G/L is linked
The G/L card window includes the following actions on the ribbon:
General journals are used to post to general ledger accounts and other accounts such as bank, customer, vendor, and fixed asset accounts. Posting with a general journal always creates entries on general ledger accounts.
The following are the types of journal entries:
General Journal: This is used to post simple expense and revenue transactions.
Standard Journal: This is used to save the transaction that you might need to reuse again. Standard journals are used for time saving.
Recurring Journal: This is used for periodic or recurring transaction for expenses and revenue.
Reversing Journal: This is used to cancel or reverse the wrong posted transaction.
Follow these steps to enter and post in the General Journal:
Go to General Journal (
Departments/Financial Management/General Ledger/General Journal).
Enter the Posting Date.
Select the G/L account as Account Type and select 61100 (advertising) account.
100in the Amount field.
And then select cash account as offset account.
Post the General Journal.
In this chapter, we have learned that Dynamics NAV as an ERP system meant to handle all the organization areas on a single software system.
The sales and purchase processes can be held by anyone without the need of having accountancy knowledge, because the system is capable of translating all the transactions to accountant language on the fly.
Customers, vendors, and items are the master data of these areas. Its information is used in documents to post transactions. There are multiple options to define your pricing policy: from one single price to different prices and discounts per groups of customers, per volume, or per period, or currency. You can also define financial discounts per early payment.
In the next chapter, we will learn how to manage cash by showing how to handle receivables, payables, and bank accounts.