Representing transport jobs in Ofbiz

[Daniel Watford]

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.

--

[Nicolas Malin-2]

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

[Daniel Watford]

Thanks Nicolas,

I hadn't looked much at WorkEffort yet as I had thought it mainly related
to manufacturing tasks. After your prompting I see it will likely help in
estimating the various costs for a Job (vehicle, fuel, ferry crossings,
tolls, etc) and I like the idea of building a service to convert WorkEffort
to invoices.

In the infrequent cases where different parties might be invoiced for parts
of the job - e.g. shipper covers costs of transport but consignee covers
customs charges - I would need to store there various reference numbers (PO
numbers) for when invoices are created. I see that PO numbers can be stored
on OrderItem.correspondingPoId.

Would it be appropriate to create multiple OrderItems where each OrderItem
represents once of the parties to eventually be invoiced? Or would this be
stretching the intent of an OrderItem too far and instead I should
introduce a new entity to capture this information - perhaps a
JobInvoiceParty entity with fields jobId, partyId, purchaseOrderRef?

Thanks,

Dan.

On Mon, 14 Oct 2019 at 08:22, Nicolas Malin <[hidden email]>
wrote:

> 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: image.png]
>
> --
> Daniel Watford
>
>

--
Daniel Watford