[OFBiz] Dev - service for accessing supplier product informat ion for purchase orders

[Si Chen]

Hi BJ,

I think those are good suggestions.

I think the former should be a service at a higher level than what I 
have, taking the list of supplier product entities and using whatever 
rules one needs.  There are cases (such as data exporting, which is what 
I'm writing this service for right now), where all you want is the 
entire list of possible suppliers.

The latter, there are supplier pref order and supplier rating fields in 
the SupplierProduct entity.  The question is how to use those, and I 
don't believe any seed data for them yet.

As soon as the jira site is back up, I'll put my code up there.  Feel 
free to improve on it.

Si

bjfree at free-man.net wrote:

>si,
>here are some thoughts.
>There should be or will be a service that evaluates the suppliers as to
>availability by lead times and stocking quotas.
>Think about a hook in your service to see this that has been done and call
>the service if not.
>also a hook to use rules to determine how the supplier should be ranked in
>the list.
>
>-----Original Message-----
>From: Si Chen [mailto:schen at graciousstyle.com]
>Sent: Friday, September 24, 2004 12:00 AM
>To: OFBiz Development
>Subject: Re: [OFBiz] Dev - service for accessing supplier product
>information for purchase orders
>
>
>Hi David,
>
>Just a couple of other questions:
>1.  Is there a reason why the fields in SupplierProduct are called 
>"availableFromDate" and "availableToDate" rather than "fromDate" and 
>"toDate"?  Using the latter would allow the use of 
>EntityUtil.filterByDate, which I think is better longer term than 
>writing custom conditions.  Would anyone mind if I changed these fields 
>in SupplierProduct?
>
>2.  Also, just out of curiousity, why is the field in SupplierProduct 
>called "lastPrice" rather than price or just cost?
>
>I'll start working on the service and post it when I'm done.
>
>Si
>
>David E. Jones wrote:
>
>  
>
>>Si,
>>
>>That sounds like a fine design to me. The definition of that service 
>>may have to change, and require changes to the code that calls it, but 
>>it should at least make that easier or perhaps avoid the whole 
>>problem. So, yes I think it is very worthwhile.
>>
>>-David
>>
>>
>>On Sep 23, 2004, at 11:56 AM, Si Chen wrote:
>>
>>    
>>
>>>Dear David, Andy, Olivier, Jacopo:
>>>
>>>I know you've been working on the purchase order component at some 
>>>point, so I'd like to get your opinion on this.
>>>
>>>It seems right now that there is the SupplierProduct entity defined 
>>>and services for maintaining it.  I didn't find any services for 
>>>getting information out of the SupplierProduct, such as price and 
>>>description, to put on a purchase order.  Did I miss it?
>>>
>>>If not, here is what I'm thinking about creating:
>>>service findSuppliersforProduct
>>>inputs: product (GenericEntity), productId (string), partyId 
>>>(string).  Later on, perhaps quantity, supplierPrefOrderId, 
>>>supplierRatingTypeId can be added as well.
>>>Service takes either product, or if not available, finds a product 
>>>from productId, and gets all its SupplierProduct entities.  If there 
>>>is a partyId, it checks that it is actually a supplier.  It then 
>>>filters them out for the currently applicable ones returns a list of 
>>>these SupplierProduct entities.  Later on, it can use quantity, 
>>>supplierPrefOrderId, supplierRatingTypeId to filter the returned 
>>>supplier product entities further.  For example, it can check that 
>>>quantity is an allowed quantity (ie, exceeds the minimum quantity, is 
>>>a fixed minimum quantity plus a multiple of the incremental order 
>>>quantity.) The user of the service can then take this list and figure 
>>>out which one to use for prices, product id, and product name on the 
>>>purchase order.  If the rules are very specific, there should only be 
>>>one returned.  If not, the calling service (such as the order 
>>>manager) can show the whole list to the user ask him/her to choose 
>>>the right one.
>>>
>>>If later the purchase order data is implemented with 
>>>Agreement-related entities as well, this service can be re-factored 
>>>to create SupplierProduct entities based on what is the 
>>>Agreement-related entities.  Or it can maybe use a combination of 
>>>Agreement-related and SupplierProduct entities, to maintain 
>>>compatibility with existing data.
>>>
>>>Does this sound like a good idea?  Please let me know, and I'll code 
>>>it up and put it on the issue tracker. :-)
>>>
>>>Si
>>>_______________________________________________
>>>Dev mailing list
>>>Dev at lists.ofbiz.org
>>>http://lists.ofbiz.org/mailman/listinfo/dev
>>>      
>>>
>>------------------------------------------------------------------------
>>
>>
>>_______________________________________________
>>Dev mailing list
>>Dev at lists.ofbiz.org
>>http://lists.ofbiz.org/mailman/listinfo/dev
>>
>>    
>>
> 
>_______________________________________________
>Dev mailing list
>Dev at lists.ofbiz.org
>http://lists.ofbiz.org/mailman/listinfo/dev
> 
>_______________________________________________
>Dev mailing list
>Dev at lists.ofbiz.org
>http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
>