Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Product types/hierarchy
Well, since it hasn't been done yet I'll start this:

I've been thinking about the need for product hierarchy as discussed. Since I've worked and maintained a coreBOS system at a manufacturing company I've got some background. I don't think there is the need for a real 'hierarchy'. In stead, I think we should start by looking at products in a more sub-divided way:

A product could roughly be three things (in a manufacturing context):
  • An end-product that you buy and sell as-is. Which is like it is now.
  • An assembly. Which basically means this is the product you sell, but it doesn't enter your company in the form it exits. In stead, you buy or manufacture the parts and assemble the product. Which leads to the third type:
  • A part. These products you buy from a supplier and use to create your end product (the assembly as mentioned above).

Now what should we do? First of all create the option to select which category (or more than one, more on that later in this text) the product belongs to. If it is an assembly, we should be able to choose which parts make up this assembly and how many of each part is needed to create one assembly. This way, by keeping stock you could see (and this should be automated) if you have enough of each part to create the assembly. Here's where the 'hierarchy' character kicks in, because a part could also be in turn an assembly. So a lot of small part could make one assembly, which in turn is a part for a larger assembly.

Functionality that comes to mind is:
  • When you sell an assembly, you should immediately see if you have all the required parts. If not, you should be able to create purchase orders for these parts (and preferably send an e-mail to the supplier).
  • You could easily produce lists for factory workers (the assemblers) that list which parts they need (and for instance where in the warehouse these are located).

There are probably a lot of other functions that could some to mind, and that is where I'd like some comment.

Now this is only internally. On quotes, sales orders and invoices you should only see the end-product. Customers don't care which parts you needed to assemble their end-product (and shouldn't know). Note, this should not be about the technical side of the manufacturing. That is way beyond the scope of what a CRM should be able to do.
most of that is in weberp and could easily be adapted if the licences are compatible.

But I am in favour of hierarchical categories, anyway.

edit: I can't get indentation working, so this list is not relly helpful: tabs don't work, leading blanks are deleted by the forum software ...

Look at any webshop: products e.g.
with reflector
without reflector
coulur computer controlled
colour manually adjustable

that would make long productlists easier to navigate, if not getting the lists from the webserver takes too long (probably should be build by js on client side).
Ah, but now I understand your need better. I was thinking more in the direction of internal organizational purposes, but yes, if you wanted to show your products on a webshop while not maintaining them in two places I understand the need for a hierarchy. But this is more about presentation and should be separate (in my opinion) from the assembly-part-endproduct functionality.

Anyway, my goal is to expand coreBOS, not to connect to other applications. From my experience with building the connector for Exact Online I've learned that (except for very special needs) it's best to keep it all in one app. Since coreBOS is modular and has many entry points to easily build new functionality this really isn't that hard. The hardest thing is establishing what it needs to do, not how to build that. For instance, product hierarchy could be a module where you define separate hierarchies. In the installation script you'd define a new block or field in products where a user can select a hierarchy(position) previously built in the hierarchy module. Then when your webshop connects to coreBOS via the webservice, it could also send this hierarchy information and your webshop could in turn use this to build its presentation. That's just from the top of my head.
no, it is not for the webshop, which we don't have.

But now, when doing quotes etc., I have a very long product list, some structure would be nice.
E.g.: do i need to see all spare parts if I do a sale of new products? I need them only occasionally when service is needed.

manufacturing: I was thinking of putting their code into cb, not to connect, that really would be tedious.
Hmm, okay, I see your point. But could you be a bit more specific about what you have in mind? Maybe create a mockup image? There is now an option to create product bundles but I just know of the existance, never investigated it.
I would like to see the mock up to, so I can better understand the needs.

First, I have a patch to set units on the existing product bundles and that could work rather well under limited circumstances.

Searching in the popup and restricting by a category pisklist for assembly or parts is rather easy...

Sadly weberp is GPL, so we can't use that code in coreBOS. GPL's viral aspect is not compatible with MPL/VPL
I just had a look at your webpage on licences and on the GNU page.

1) Can we have a parallel installation of weberp and get data from a  webservice? We would be exchanging only data, and the GPL pages exclude the data prepared by a GPL program from the licence.

2) Can we directly write into the mysql database? We would not be using any GPL code for that, but would be using the data structure (tables) (are they GPLed?).

3) Can we directly call weberp webpages  and interpret the data that is sent back?

You can exchange information freely, and you can license the code you create to move that information from one application to the other as you wish.

I would stay away from direct database manipulation because it will make your code easier to read and less dependent on future changes. Use webservices.
so the webservice/adapter would be part of weberp and gpl licenced, and we could then by webservice load result of MRP into corebos and manipulate that there, with out licence conflict between corebos licence and weberp licence (GPL) Do I understand that correctly?
Yes, that sounds correct:
- any change/addition you make in weberp must be GPL and stay that way
- any change you make in coreBOS base must be MPL or compatible
- if you add a new module/extension to coreBOS you can license it as you like
- if you make a totally stand alone application that reads and writes from/to both (via webservice) you can license that as you like

Forum Jump:

Users browsing this thread: 1 Guest(s)