The two methods are refactored to the point where upsRateInquire calls upsRateEstimateByPostalCode. The parameter set of upsRateInquire is controlled by calcShipmentEstimateInterface which does not have isResidentialAddress flag.
As you have mentioned, even if we add this attribute to service interface. Order create / invoice and for future reference we'll need to remember why somebody was pricing is different. In order to consistently get good shipping estimate we will have to remember value of this flag beyond user web session. +1 for adding some kind of attribute to Postal Address to be able to remember this. Regards Anil On 5/18/07, Tim Ruppert <[EMAIL PROTECTED]> wrote:
Anil, I remember when this feature was added to the upsRateInquireByPostalCode method. Last I remember I thought that these two methods were refactored to clean up the code redundancy, so the isResidential flag would have been still used right? Now, your question appears to be a bit different in that you are looking for a way to store the isResidential flag on the Postal Address in some manner. My vote would be to either extend the PostalAddress or to just pass this information along in the cart process that you're working on. Is this a flag everyone would like to see supported by default in OFBiz? Cheers, Tim -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On May 18, 2007, at 11:04 AM, Anil Patel wrote: Hi, There is noticeable difference in shipping estimate (definitely in case of UPS) if Postal Shipping address is ResidentialAddress or Not. Shipping estimate services (other then upsRateInquireByPostalCode) don't account for this attribute when request is sent. In case of UPS this always defaults to commercial. What is best to do in this case? Should we add an attribute to Postal address, a flag that tells me if the address is ResidentialAddress. Or there is some other better option to handle this. Regards Anil Patel
