Re: Representing transport jobs in Ofbiz
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 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
Re: Representing transport jobs in Ofbiz
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
Representing transport jobs in Ofbiz
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
