Hello Daniel,
As you describe your jobs, I would tend to use WorkEffort entity with
sub workEffort for each sub invoicing part.
When your functional schema is operational, detect what element trigger
the invoicing and peraphs create your own service to convert your
workEffort to invoice
Nicolas
On 13/10/2019 21:24, Daniel Watford wrote:
Hello,
A shipping company client of mine needs to replace their current
operations management software. I would like to build a solution based
on ofbiz, with a plugin designed to manage their operations.
The company creates Jobs to represent orders/instructions from their
customers. Each job can have a number of involved parties, including
potentially multiple parties being invoiced for different parts of the
job.
The new plugin should be able to replicate the company's Jobs with the
introduction of some Job related entities. Please see attached diagram.
Eventually the operations software would need to generate invoices,
email them to customers and post relevant information to accounting
ledgers. Therefore I thought I would really need to link a Job with an
Order.
When reading the code behind OrderServices#createOrder I noticed that
to create a SALES_ORDER it was necessary to include a productStoreId.
It seems that if I try to make use of the existing createOrder method
I will need to set up some other 'infrastructure' to make the company
appear a bit more like an ecommerce environment.
Is it appropriate for me to link Jobs to Orders in this way, or should
I be keeping the two entities separate and find an alternative way to
manage invoices?
If appropriate to link Jobs to Orders, should I avoid using the
existing OrderServices#createOrder method and just construct entities
as needed for my plugin's needs, or should I create any entities
createOrder might need (such as productId) to ensure Orders are
constructed in a consistent manner for use in other parts of ofbiz?
Any comments or suggestions greatly appreciated.
Many thanks,
Dan.
image.png
--
Daniel Watford
