I think more in automation.
nor am I suggesting an new order type just useing purchase orders.
I have dealt with them enough to know what is attached.
the scenario is each store has it own facility and inventory with
reorder levels.
so each store sales will deal with there inventory in thier facility.
when the re-order levels are triggered the PO is generated. this is a
noral way ofbiz works.
the difference is the PO is sent to the Hub company.
now this is where the customization is done.
the scheduled service looks for the PO to the Hub company and creates a
transfer for the items in the hub to the facility of the company in the PO.
the acconting requires sub accounts for each store (profit center)
the key to all this is roles and partyrelationships.
=========================
BJ Freeman
Strategic Power Office with Supplier Automation
<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Paul Foxworthy sent the following on 2/1/2011 2:47 PM:
In Ofbiz, adding a new Order Type or any other entity type should be handled
with care.
There are business rules sprinkled through the code looking for a particular
type and doing things when they see a type they recognise. If you want to
add a new type, you need to grep for every use of the existing types and
think carefully about what needs to happen for your new type. Try not to
break the rules for existing types as you implement what you need for your
new one :-). Of course, this job will be easier for some types compared to
others.
In our user's heads, a transfer would probably be a very different thing
compared to a purchase or sales order involving an external party. So the
*UI* should probably draw a distinction between them. It may be that when
you want to find transfers, all you need to do is look for orders where both
parties are internal organisations.
Cheers
Paul Foxworthy
