Converting hand made "WMS" to ofbiz

Hi all,


first of all, please excuse me if I am asking things that have already
been explained 100 times, and I am asking it for the 101st time.

I am in the process of evaluating if I can replace the ERP/WMS I wrote
myself in the past by something like ofbiz.
I wrote it in the past from the ground, because there was nothing on the
market at that time that was affordable and could fit the specifics of
what we are doing.
(we are in the distribution of beer).
We are at the point where we need to decide on the future of the
package. The technology used is becoming of age (FlagShip www.fship.com
in combination with mysql) and some of the foundations it was build on
in the past are no longer valid, or have changed. Consequently we need
to make drastic changes in the software.  Hence the evaluation process.

Basically, we have warehouses where breweries deliver their beer, and
from there it is shipped towards all countries in the world either
directly to the customer or towards an other warehouse.
 From within that warehouse the inventory of several independent
operating companies (different importers from different countries are
using the same warehouse and software) is used to dispatch towards their
customers.
(the warehouse itself is not the owner of the inventory, it just is
responsible for all services that need to be rendered)

The current system allows the warehouse to do all order picking, create
shipping notes, and consolidates different shipping notes into a
"transport".
A "transport" is a consolidation of shipping notes that leave at the
same moment the warehouse with the same transportation. (e.g. on the
same truck, in the same container)
For this "transport" the current system creates all administrative
documents automatically. (e.g. the declaration of excise movements )
Based on the shipping notes, invoices are created towards the customers
of the different companies.

Between the different companies there is automatic order creation and
invoicing for items that they are the preferred supplier. E.g.

  * Company A sells product XY to customer Z.
  * Within Company A, for product XY the company B is defined as the
    preferred supplier.
  * Automatically the system creates within company A a purchase order
    towards company B for the product XY
  * Within company B a sales order is created for the product XY towards
    company A
  * When company A looks at the "available to promise" inventory, the
    system takes the sum of the inventory of company A and the inventory
    of company B (preferred supplier for the product)
  * Any status on the sales order within company B automatically updates
    the purchase and sales order in company A.

On the product itself there is a form of master data management so that
the companies only need to create the article once.
On top when company B defines its selling price, the purchase price of
company A is updated automatically.

A similar system of automatically creating purchase orders from sales
orders exists for products that are leaving directly from the supplier.
E.g. Company A creates a sales order for a customer that is dispatched
directly from the supplier (drop shipment), the system creates
automatically the purchase order for that supplier.

An important part of our current system is excises. On beer the
government raises excises.
Those excises need to be paid when you put the beer on the market for
the end consumer.
Between the brewery and e.g. the tax warehouse you can move the product
without needing to pay excises, however you need to have a bookkeeping
on all excise movements.
(this works like in accounting, you need to book incoming and outgoing
movements on the account)
The sum of all movements needs to equal to you actual inventory for that
excise account.

An excise account is created for each packing form of a product. E.g.

Account Number
        Beer
1
        Augustijn 24 * 1/3 L One way packaging
2
        Augustijn 24 * 1/4 L One way packaging
3
        Bornem 24 * 1/3 L One way packaging
4
        Bornem 24 * 1/4 L One way packaging
5
        Augustijn 24 * 1/3 L Reusable  packaging
6
        Augustijn 24 * 1/4 L Reusable  packaging
...
        ...

       

       



In the current system, we link certain products to an excise account.
E.g. Augustijn 24 * 1/3 L from company A is linked to that excise
account, but also Augustijn 24 * 1/3 L from company B is linked to that
account.
(internally these products have different product ids in each company,
so we link them via a link table to the same excise account
(exciseaccount_productid)
When the government comes checking the tax warehouse (this is at minimum
a yearly exercise they do), we need to be able to print all movements on
the account, together with the number of the document that accompanied
the transport and/or the inventory that is available per excise accounts

For calculating weights and contents of the products we use the BOM of
the product.
We have in our system different types of products
Articles : things we sell and have a selling price
Bottles, Keggs, Glasses, Accessories that are used to create the article
via a BOM

Eg.

Augustijn 24 * 1/3 L One way packaging is composed of

Carton 1
Steiny bottle 24



Augustijn 24 * 1/3 L One way packaging + 1 Augustijn glas 33 cl  is
composed of

Augustijn 24 * 1/3 L One way packaging 1
Augustijn glas 33 cl
        1


If we want to have the weight of Augustijn 24 * 1/3 L One way packaging
+ 1 Augustijn glas 33 cl, the system calculates this automatically  by
recursively  traversing the BOM and for the bottles multiplying with the
contents of the bottle. (.33 L)
At the same time based on the packaging within the BOM, the "warranty" /
"Bond" / "caution" you pay for reusable packaging is calculated (this is
defined on the bottle, kegg, packaging, ...)

On this example, we have an extra complexity :

  * When people are ordering Augustijn 24 * 1/3 L One way packaging + 1
    Augustijn glas 33 cl.
  * We need to calculate for the picking note, how many boxes of glasses
    need to be put on the shipment.
  * (glasses traditionally are packed per 6)
  * So if a customer orders 10. We calculate that we need to give 2
    boxes of glasses, but in the background we keep track that we gave
    the customer 2 glasses to much.
  * For a next order we take the glasses we have given to much into account

Next to the excise duties, there is also ecotax to take into consideration.
On packaging you bring on the market and that is one way, you need to
pay a disposal tax, unless the dispossal tax was paid for by the
producer of the product.
E.g. sometimes it happens that certain breweries pay for all products
that are brought on a market, whatever the importer was. In other cases
it is the task of the importer to pay for the ecotax to the local
government.

When creating an invoice for a customer, the customer sees for each
orderline on the invoice, the amount of excises, the ecotax, the
warranty and the discount.
When discounts are applied these are applied before excises, ecotax,
warranty and all other possible taxes.
The transportation cost is added to the total as a net cost.
No margin is taking on the transportation cost.

Last year we added to our current software the possibility to
communicate with the EMCS system from the government.
This allows us for communicating in an electronic way with the
government for declaring excise free transports etc.
(currently this is done by generating an XML file representing the SOAP
message and we post it via SOAPUI on the webservice of the gouvernment.
We do this via SOAPUI because the interface provided by the gouvernment
is still not 100% stable and is sometimes giving errors. As soon as we
are sure the interfacing is stable, we would replace this by e.g. and
ESB that can do the work (e.g. ServiceMix or WSO2)

The question I have, is this possible within ofbiz ?
Would it require a lot of changes in ofbiz ?


Kind regards

Tore

[Anil Patel-3]

Tore,
Like many other deployments, your requirements are tuned for certain vertical. Ofbiz is good ERP application framework for building such solution. It has the data model and business process/rules implemented as services to support most of your requirements. The UI may not be ready and UX may not get you excited.

One of the possible answer is to build your own custom component that has UI artifacts which use services and UI elements from OOTB applications. Special purpose ecommerce component is example of similar thing. Its bunch of UI artifacts that use services from Order Manager, Catalog Management etc.

Regards
Anil Patel
 

On Dec 18, 2012, at 4:05 PM, [hidden email] wrote:

> Hi all,
>
>
> first of all, please excuse me if I am asking things that have already been explained 100 times, and I am asking it for the 101st time.
>
> I am in the process of evaluating if I can replace the ERP/WMS I wrote myself in the past by something like ofbiz.
> I wrote it in the past from the ground, because there was nothing on the market at that time that was affordable and could fit the specifics of what we are doing.
> (we are in the distribution of beer).
> We are at the point where we need to decide on the future of the package. The technology used is becoming of age (FlagShip www.fship.com in combination with mysql) and some of the foundations it was build on in the past are no longer valid, or have changed. Consequently we need to make drastic changes in the software.  Hence the evaluation process.
>
> Basically, we have warehouses where breweries deliver their beer, and from there it is shipped towards all countries in the world either directly to the customer or towards an other warehouse.
> From within that warehouse the inventory of several independent operating companies (different importers from different countries are using the same warehouse and software) is used to dispatch towards their customers.
> (the warehouse itself is not the owner of the inventory, it just is responsible for all services that need to be rendered)
>
> The current system allows the warehouse to do all order picking, create shipping notes, and consolidates different shipping notes into a "transport".
> A "transport" is a consolidation of shipping notes that leave at the same moment the warehouse with the same transportation. (e.g. on the same truck, in the same container)
> For this "transport" the current system creates all administrative documents automatically. (e.g. the declaration of excise movements )
> Based on the shipping notes, invoices are created towards the customers of the different companies.
>
> Between the different companies there is automatic order creation and invoicing for items that they are the preferred supplier. E.g.
>
> * Company A sells product XY to customer Z.
> * Within Company A, for product XY the company B is defined as the
>   preferred supplier.
> * Automatically the system creates within company A a purchase order
>   towards company B for the product XY
> * Within company B a sales order is created for the product XY towards
>   company A
> * When company A looks at the "available to promise" inventory, the
>   system takes the sum of the inventory of company A and the inventory
>   of company B (preferred supplier for the product)
> * Any status on the sales order within company B automatically updates
>   the purchase and sales order in company A.
>
> On the product itself there is a form of master data management so that the companies only need to create the article once.
> On top when company B defines its selling price, the purchase price of company A is updated automatically.
>
> A similar system of automatically creating purchase orders from sales orders exists for products that are leaving directly from the supplier.
> E.g. Company A creates a sales order for a customer that is dispatched directly from the supplier (drop shipment), the system creates automatically the purchase order for that supplier.
>
> An important part of our current system is excises. On beer the government raises excises.
> Those excises need to be paid when you put the beer on the market for the end consumer.
> Between the brewery and e.g. the tax warehouse you can move the product without needing to pay excises, however you need to have a bookkeeping on all excise movements.
> (this works like in accounting, you need to book incoming and outgoing movements on the account)
> The sum of all movements needs to equal to you actual inventory for that excise account.
>
> An excise account is created for each packing form of a product. E.g.
>
> Account Number
> Beer
> 1
> Augustijn 24 * 1/3 L One way packaging
> 2
> Augustijn 24 * 1/4 L One way packaging
> 3
> Bornem 24 * 1/3 L One way packaging
> 4
> Bornem 24 * 1/4 L One way packaging
> 5
> Augustijn 24 * 1/3 L Reusable  packaging
> 6
> Augustijn 24 * 1/4 L Reusable  packaging
> ...
> ...
>
>
>
>
>
>
>
> In the current system, we link certain products to an excise account.
> E.g. Augustijn 24 * 1/3 L from company A is linked to that excise account, but also Augustijn 24 * 1/3 L from company B is linked to that account.
> (internally these products have different product ids in each company, so we link them via a link table to the same excise account (exciseaccount_productid)
> When the government comes checking the tax warehouse (this is at minimum a yearly exercise they do), we need to be able to print all movements on the account, together with the number of the document that accompanied the transport and/or the inventory that is available per excise accounts
>
> For calculating weights and contents of the products we use the BOM of the product.
> We have in our system different types of products
> Articles : things we sell and have a selling price
> Bottles, Keggs, Glasses, Accessories that are used to create the article via a BOM
>
> Eg.
>
> Augustijn 24 * 1/3 L One way packaging is composed of
>
> Carton 1
> Steiny bottle 24
>
>
>
> Augustijn 24 * 1/3 L One way packaging + 1 Augustijn glas 33 cl  is composed of
>
> Augustijn 24 * 1/3 L One way packaging 1
> Augustijn glas 33 cl
> 1
>
>
> If we want to have the weight of Augustijn 24 * 1/3 L One way packaging + 1 Augustijn glas 33 cl, the system calculates this automatically  by recursively  traversing the BOM and for the bottles multiplying with the contents of the bottle. (.33 L)
> At the same time based on the packaging within the BOM, the "warranty" / "Bond" / "caution" you pay for reusable packaging is calculated (this is defined on the bottle, kegg, packaging, ...)
>
> On this example, we have an extra complexity :
>
> * When people are ordering Augustijn 24 * 1/3 L One way packaging + 1
>   Augustijn glas 33 cl.
> * We need to calculate for the picking note, how many boxes of glasses
>   need to be put on the shipment.
> * (glasses traditionally are packed per 6)
> * So if a customer orders 10. We calculate that we need to give 2
>   boxes of glasses, but in the background we keep track that we gave
>   the customer 2 glasses to much.
> * For a next order we take the glasses we have given to much into account
>
> Next to the excise duties, there is also ecotax to take into consideration.
> On packaging you bring on the market and that is one way, you need to pay a disposal tax, unless the dispossal tax was paid for by the producer of the product.
> E.g. sometimes it happens that certain breweries pay for all products that are brought on a market, whatever the importer was. In other cases it is the task of the importer to pay for the ecotax to the local government.
>
> When creating an invoice for a customer, the customer sees for each orderline on the invoice, the amount of excises, the ecotax, the warranty and the discount.
> When discounts are applied these are applied before excises, ecotax, warranty and all other possible taxes.
> The transportation cost is added to the total as a net cost.
> No margin is taking on the transportation cost.
>
> Last year we added to our current software the possibility to communicate with the EMCS system from the government.
> This allows us for communicating in an electronic way with the government for declaring excise free transports etc.
> (currently this is done by generating an XML file representing the SOAP message and we post it via SOAPUI on the webservice of the gouvernment. We do this via SOAPUI because the interface provided by the gouvernment is still not 100% stable and is sometimes giving errors. As soon as we are sure the interfacing is stable, we would replace this by e.g. and ESB that can do the work (e.g. ServiceMix or WSO2)
>
> The question I have, is this possible within ofbiz ?
> Would it require a lot of changes in ofbiz ?
>
>
> Kind regards
>
> Tore
>
>
>
>
>
>
>
>
>