Another (quick and dirty) option would be that of creating one single term type for the 30/60/90 type.
For example
termTypeId=FIN_PAY_TERM_306090

Jacopo


Scott Gray wrote:
Another option is to create an agreement item and use it's terms to split
the payments:
Agreement Term - Type=Payment (net days), Term days = 90
Agreement Item Term - Type=Payment (net days), Term days = 30, Term Value =
33
Agreement Item Term - Type=Payment (net days), Term days = 60, Term Value =
33
Agreement Item Term - Type=Payment (net days), Term days = 90, Term Value =
34

That looks pretty flexible to me.

Regards
Scott

On 15/04/07, Scott Gray <[EMAIL PROTECTED]> wrote:

Instead of your current approach (which I commented on in the jira),
perhaps you could create a new Agreement Term Type of Split Payment and use Term Value/Term Days to create the splits (eg. 33/30 with the last payment
adding on the 1% left over)?

Regards
Scott

On 15/04/07, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote:
>
> Hi Jacopo,
>
> thanks for your feedback.
> I have tried to create an agreement for user admin and organization
> Company for Sales Order and then in the backend I have tried to
> create a sales order selecting this agreement.
> After checkout the order I have seen that the OrderTerm, and also
> InvoiceTerm after shipping the order, are not corrected stored.
> They have a wrong itemSeqId and this is part of the PK and so only
> the last row of the terms was stored on the entity.
> I have create a patch to solve this little bug (https://
> issues.apache.org/jira/browse/OFBIZ-890).
> After apply this patch the OrderTerm/InvoiceTerm entity are correctly
> filled with the agreementTerm.
> Now I would like to know how can I do to understand when will be the
> dueDate of those payments, if I have one invoice with three terms and
> so probably we will have at minimum 3 payments (for example 30/60/90
> term days).
> May I have to calculate every time from the orderDate + the term days
> the dueDate or as I have proposed I can add some fields on the
> Payment entity.
> I thinks that it can be a good improve also in case of on-line
> payment (like paypal, google checkout, etc.) that the payment can
> have a dueDate with OrderDate + 7 days.
> Any feedback before start this improvement is important.
>
> Thanks in advance
> Marco
>
>
>
> Il giorno 13/apr/07, alle ore 20:21, Jacopo Cappellato ha scritto:
>
> > Hi Marco,
> >
> > maybe the best thing is to add the payment terms to the order as
> > OrderTerm records; the terms are (already) automatically moved to
> > the invoices associated to the order (InvoiceTerm).
> > Then you should just implement a report that shows you the upcoming
> > payments gathering the information from the invoice's date and terms.
> >
> > Jacopo
> >
> >
> > [EMAIL PROTECTED] wrote:
> >> Hi to all,
> >> I would like to know if there is the possibility to handle the
> >> payment due date.
> >> If I have an order with payment off-line (bank transfer) and we
> >> have three different term (30/60/90 days) and I would like to
> >> generate automatically according to the term three different
> >> payment that will have a due date on the order date + 30/60/90 days.
> >> Example :
> >> Order Date 14 April 2007 Total Order $ 300,00
> >> Term 30/60/90 days
> >>     1 Payment due date 14 May 2007  amount $ 100,00
> >> 2 Payment due date 14 June 2007 amount $ 100,00
> >> 3 Payment due date 14 July 2007  amount $ 100,00
> >> For implementing it I think I can add two fields into the Payment
> >> entity : dueDate and paidDate.
> >> Did you think it's ok for you or you have different idea ?
> >> Thanks in advance
> >> Marco Risaliti
> >
> >
>
>




Reply via email to