As a general usability principle, you want to provide openness and flexibility, allowing users to do whatever they want whenever they want. This argues for providing multiple entry points rather than forcing users to follow only a single possible path which they may not know or may have forgotten or may not be consistent with their way of thinking.
The concern is that multiple paths can mean more complex menus and information architecture that add clutter, get users lost, and otherwise potentially cause confusion. There are a few variables that can mitigate this.
Firstly, as apps get more complex, with more possible tasks and paths, you can control both menu and architecture complexity by adopting an object-centered structure, rather than a wizard-like task-centered structure typical of web apps. In an object-centered structure, each page represents one or more object classes for which all tasks involving those classes can be accomplished. In a task-centered structure each page represents a single task or a single step in a task.
With an object-centered structure, you may have a Products page listing all products, with the supplier for each indicated in a field (which the user can sort on). Alternatively, you have a Suppliers page listing all suppliers, which includes the products for a given supplier in a tree or master-detail layout. Either way, all the information is on one page making the simplest menu and architecture and eliminating or at least reducing the need for multiple entry points.
Duplicating between Pages (versus in Pages)
Secondly, having duplicate commands on two different pages is not nearly as problematic as having duplicate commands in two different places on the same page. With the latter, users will wonder if the two commands are really the same or not. In contrast users often expect the same commands to appear on different pages (e.g., in side bar menu).
Depending on the tasks you need to support, it may be necessary to have both a Products and a Suppliers page even if you have an object-centered structure. However, having an Add Product menu item on both the Products and Suppliers pages is probably okay. Having an Add Product menu item under Product and Supplier menus is probably not.
Consistent Labels and Rules
Thirdly, multiple entry points result in the least complexity if they use the same labels and follow the same basic rules of interaction. For object-centered structures and most desktop GUIs, the basic rule is that if the user can see it, the user can interact with it. If users see products on both the Products and Suppliers page, they’ll expect to be able to interact with them, including adding to them. This is analogous to providing links to content whenever it is cited in a web site.
Consistent labels will help signal to users that it’s the same command in a different place, so be sure to consistently call it “Add Product,” not “Add Product” in one place and “Insert Product” in another.
Simple consistent rules can also simplify your menus. If your app supports object focus (necessary for master-detail relations), then you only need an Add menu item. If focus is on products (on either page) it adds a product. If focus is on the suppliers, it adds a supplier.