This is a guide for anyone who wants to understand how to transfer his or her business processes into the NetSuite environment. It will be especially helpful for anyone in discussions with a NetSuite implementation partner (or currently preparing for those discussions). This is because in this guide we will focus on clarifying terminology and providing some examples to help flesh out the general structure of NetSuite’s record-keeping tools.
At the end of this NetSuite implementation guide you will not only have a better understanding of NetSuite’s default structure and terminology, but you will also be more aware of the software’s flexibility. This awareness will aid you in deciding what really needs to be customized in your version of NetSuite and (importantly) what would be just fine to leave pretty much just as-is. Armed with this knowledge, you will be able to communicate much more clearly to your NetSuite implementation consultants how they can serve you in setting up NetSuite for your company.
When going about an ERP implementation, rather than beginning with what NetSuite offers natively (“native” = something that NetSuite comes with by default. Generally, this is not something custom or based on custom code), you may find it more fruitful to first sit down and think about the day-to-day needs of your own business. Having a clearly defined list of requirements will help your NetSuite implementation team to understand what it is that you really want out of NetSuite. Here are some questions to get you going:
General questions
CRM / Sales
Order fulfillment
Timekeeping and project management
Understanding what information you will want to get out of NetSuite is crucial to figuring out the best way to put information into NetSuite. One of the benefits of using default fields and records to keep track of things is that NetSuite has already bothered setting up reports corresponding to those fields and records. It is always possible to create your own custom reports, but why work harder than you need to?
Here is where you might want to get input from your executive leadership team, and really from anyone who regularly needs to see reports for analyzing the general health of the business or the efficacy of a particular business practice.
Once you have answers to all of these questions, you are just about ready to meet with a NetSuite partner to discuss how to customize your NetSuite account to the specific needs of your business. Before those discussions, though, it would be well worth your time to learn a bit of NetSuite’s terminology; a common set of definitions will lend clarity and precision to your discussions, and might save you from paying for a customization different from what you really wanted.
So let’s dive in to the general outline of NetSuite. NetSuite is, at its core, an accounting software. There are many other great tools that have been added beyond just those used for accounting, but the basic structure is still that of an accounting software. What NetSuite keeps track of are records. There are three general record types: Item, Transaction, and Relationship. We’ll go through each of these in turn.
Items are things you sell, things you assemble, parts of things you assemble, things you keep in stock, things you ship, things you buy, etc.
Suppose that I am a shelving manufacturer. I build and sell bookshelves and utility shelves. Most likely I will want to keep track of how many of each type of shelf I have available to sell. In NetSuite, the item record type would make a lot of sense here. If I make each of my categories of shelf an item, now I can track those items from assembly through warehouse inventory right through the sales order and the customer invoice. For instance, if I sell 10 varieties of shelves, I would enter 10 items into NetSuite.
If any of my shelves come in options such as size or color or material, I might want to use a specific type of item record called a matrix item to keep all of those options grouped together under one parent item. The parent item could be “bookshelf”, while the child items (also called Matrix Sub-Items) could be “white bookshelf” and “red bookshelf.” Here we have an illustration of what NetSuite calls the parent-child relationship, which is a way of indicating that two records are distinct but still related, and one record is dependent upon or follows upon the other. The parent-child relationship can be one-to-one or a one-to-many. In this case, it is a one-to-many, because there is one parent item but several child items.
It is possible to have all sorts of relationships between all sorts of record types. For instance, as we will see in a moment, a sales order is naturally linked to an invoice. If there is ever an item returned, a return authorization can also be linked to the sales order.
We’ve given a brief look at how NetSuite can use the item record type to keep track of finished products. The item record type can also be used to keep track of the assembly parts. You can do this by means of creating assembly items, which are the same as normal inventory items except that NetSuite allows you to keep track of the parts used to build each item. Assembly items can even be stacked in layered parent-child relationships; for instance, if my shelves were assembled separately from the shelf supports, I could make just the shelf support an assembly item (with its own set of parts under it, such as wood, screws, and laminate, that each have their own item record associated with them). The shelf support assembly item could then, in turn, be part of the whole assembly item of the finished bookshelf. For more about manufacturing with NetSuite, see this article.
An item record, just like any record within NetSuite, will have a number of fields associated with it. Fields contain values like text, number, date, or a true/false option. These fields are then displayed to the user of NetSuite by means of a form. The form is the manner in which the fields are filtered and displayed. There can be multiple forms (e.g. modes of viewing) for a particular record type. This can be useful, for instance, if different roles within your company need to view the same item record, but don’t need to know the same things about that item. My sales rep might need to know the sale price of an item, but not the components necessary for manufacturing it. A manager on the shop floor, in contrast, might need to know the components, but doesn’t need to worry about the price. You could have different forms for different users.
Notice that this form has lots of fields that are empty. That is okay! At this point, don’t worry about the fields you don’t use or don’t understand; focus on the fields you do need. Later it will be possible to customize the form so the fields you don’t use are not displayed.
Notice also that each field has a field label. A label is what displays on the form next to or above the field. Don’t confuse labels with fields; labels only indicate fields, while fields actually hold data. Think of a label like the word “Eggs” on a carton of eggs, while a field is the actual cardboard carton, and the eggs themselves are the value contained by that field. Labels are easily customizable. For instance, if you would rather the Description field have the label “Comments” instead, you can change that label without changing the name or other properties of the underlying field.
Say that I want to keep track of which aisle in my warehouse I keep a particular item type in. Say, small, red bookshelves. Now, it might appear that the obvious choice here would be to use the Location native field. After all, you can see it right there on the form! And surely it is obvious what “location” means! But it is worth being careful here; the term “location” could refer to all sorts of things: property/campus, building, floor, room, section, aisle, etc. Your NetSuite implementation team should be able to tell you whether you are understanding the original intent of any particular field.
Of course, it is your NetSuite account, and you can use fields pretty much however you want. If you want to use the Location field to keep track of warehouse aisles, go ahead; that way you won’t have to bother creating a custom field. But if you want to reserve the Location field for keeping track of building or campus (an approach which would set you up well for future business expansion), then you will need another field for keeping track of which aisle bookshelves are stored in, and that would involve the creation of a custom field, which will probably involve creating a custom list from which the field can draw from.
The point to get here is to be careful not to assume the meaning and intended use of native fields like Location. Field labels often have multiple possible equivocal meanings, which only someone well-versed in NetSuite will be able to help clarify. Other native fields that might be misunderstood are Category, Campaign, and Lead Source, to name a few.
We’ve looked at one of the three main record types: items. We now turn to the second main record type, namely, Transactions. Transactions keep track of some exchange of goods or services that your company is involved in. Transactions include: opportunity (a record of potential sales), sales order (a record of when your company sells something), purchase order (a record of when your company buys something), invoice (a record of billing), and return authorization (a record of items returned to your company).
The final main record type is Relationship. Typically a Relationship is either with a contact (a person, who may or may not be associated with a company) or a customer. Customers (who can either be individuals or companies) come in three categories: Lead (possible customer), Prospect (likely customer / opportunity in discussion), and Customer (full-fledged / actually has a sales order). There are not really three different record types corresponding to these three categories; it is better to think of Lead, Prospect, and Customer as three stages of the same record type. For instance, if Freddy Fredrickson is one of my Prospects, but then a sales order is created associated with him, Freddy will be automatically changed to Customer status by NetSuite.
Remember, clarity of requirements is the key to the most powerful and cost-efficient NetSuite implementation. By familiarizing yourself with the native terminology and primary record types within NetSuite, you have already equipped yourself to engage in much more fruitful discussions with your implementation team. Of course, this was a general guide for preparing for a NetSuite implementation - to learn more about how to get the most out of NetSuite for your unique situation, reach out to an experienced consulting firm. Do it right the first time!
Hopefully, this post gives you something to work with while trying to understand NetSuite and what it can do for your business. If you have any questions and want some free consulting advice, feel free to contact our team at Anchor Group.