Dev - re-factoring of returns model for taxes

[Si Chen-2]

David, everybody else who is following -

We have been working on OFBIZ-546 to separate out taxes from other
return items.  As we worked on this, it has become obvious that we would
need to separate out the other adjustments.  Otherwise calculating the
taxes becomes extremely complicated--trying to figure out what portion
of a return should be a taxed vs not.

It also now seems that we would need to create a separate entity for
ReturnItemAdjustments, as now we are forcing basically two different
concepts into ReturnItem, with a lot of duplicated code that's hard to
work with.  Let me know if you have any thoughts on this.

Si
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Andrew Sykes]

Si,

Could you give us an update on the status of the accounting module
please, i.e. how close is it to being fully funded?

Also, are you aware of anyone having done an integration with Sage?
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Andrew Sykes]

Sorry Si, that should have gone to the Users list, I'll repost...

On Wed, 2006-02-08 at 17:20 +0000, Andrew Sykes wrote:
> Si,
>
> Could you give us an update on the status of the accounting module
> please, i.e. how close is it to being fully funded?
>
> Also, are you aware of anyone having done an integration with Sage?
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

If creating a ReturnAdjustment will make this easier then we might as  
well do that. Given that with Orders and adjustment can be associated  
with an OrderHeader or an OrderItem, we may want to follow the same  
pattern here and call the entity ReturnAdjustment instead of  
ReturnItemAdjustment and put an optional returnItemSeqId on it.

-David


On Feb 8, 2006, at 10:14 AM, Si Chen wrote:

> David, everybody else who is following -
>
> We have been working on OFBIZ-546 to separate out taxes from other
> return items.  As we worked on this, it has become obvious that we  
> would
> need to separate out the other adjustments.  Otherwise calculating the
> taxes becomes extremely complicated--trying to figure out what portion
> of a return should be a taxed vs not.
>
> It also now seems that we would need to create a separate entity for
> ReturnItemAdjustments, as now we are forcing basically two different
> concepts into ReturnItem, with a lot of duplicated code that's hard to
> work with.  Let me know if you have any thoughts on this.
>
> Si
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

Ok.  Good idea.  We'll call it that.

Si

David E. Jones wrote:

>
> If creating a ReturnAdjustment will make this easier then we might as  
> well do that. Given that with Orders and adjustment can be associated  
> with an OrderHeader or an OrderItem, we may want to follow the same  
> pattern here and call the entity ReturnAdjustment instead of  
> ReturnItemAdjustment and put an optional returnItemSeqId on it.
>
> -David
>
>
> On Feb 8, 2006, at 10:14 AM, Si Chen wrote:
>
>> David, everybody else who is following -
>>
>> We have been working on OFBIZ-546 to separate out taxes from other
>> return items.  As we worked on this, it has become obvious that we  
>> would
>> need to separate out the other adjustments.  Otherwise calculating the
>> taxes becomes extremely complicated--trying to figure out what portion
>> of a return should be a taxed vs not.
>>
>> It also now seems that we would need to create a separate entity for
>> ReturnItemAdjustments, as now we are forcing basically two different
>> concepts into ReturnItem, with a lot of duplicated code that's hard to
>> work with.  Let me know if you have any thoughts on this.
>>
>> Si
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
>
>------------------------------------------------------------------------
>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev