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

[Si Chen]

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
>