OFBiz › OFBiz - Dev

Payment due date/paid date

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

18 messages Options

mrisaliti@libero.it

Payment due date/paid date

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

Walter Vaughan

Re: Payment due date/paid date

[hidden email] wrote:
<snip>
> 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 ?

If you asking about adding this as a feature into ofBiz, then this is the proper
forum and please ignore the rest of my message.

However, however it sounds like you are asking for advice customizing ofBiz, and
the proper forum for that is the [hidden email] mailing list.

http://mail-archives.apache.org/mod_mbox/ofbiz-user/
http://www.nabble.com/OFBiz---User-f2743.html

--
Walter

Jacopo Cappellato

Re: Payment due date/paid date

In reply to this post by mrisaliti@libero.it

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

[hidden email] 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

mrisaliti@libero.it

Re: Payment due date/paid date

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
>
>
> [hidden email] 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
>
>

Scott Gray

Re: Payment due date/paid date

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, [hidden email] <[hidden email]> 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
> >
> >
> > [hidden email] 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
> >
> >
>
>

Scott Gray

Re: Payment due date/paid date

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 <[hidden email]> 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, [hidden email] <[hidden email] > 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
> > >
> > >
> > > [hidden email] 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
> > >
> > >
> >
> >
>

mrisaliti@libero.it

Re: Payment due date/paid date

Hi Scott,

thanks for your promptly reply to this issue.
I think you are right from the entitiy design point of view but from
the user interface point of view the effects are different.
If you try to create a purchase order on the supplier DemoSupplier
selecting the agreement AGR_TEST you will see after the checkout that
on the screen the orderItemSeqId are used as rows of the terms.
So looking at the actual code I made I mistake because I have
understand that orderItemSeqId in this case was used as row of the
agreement term.
Probably in my opinion is enough to add the foreign key to the
AgreementTerm (agreementTermId) and also removed the redundant fields
termValue, termDays, description (directly retrieved from the new
foreign key) for the entity BillingAccountTerm, InvoiceTerm,
OrderTerm, QuoteTerm.
We have to think about also to change the PK of those entities (now
is termTypeId, orderId, orderItemSeqId) ?
Doing those changes probably I can solve the issue in the correct
way, entity design and u.i. point of view.

Thanks
Marco

Il giorno 15/apr/07, alle ore 01:10, Scott Gray ha scritto:

> 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 <[hidden email]> 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, [hidden email] <[hidden email] > 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
>> > >
>> > >
>> > > [hidden email] 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
>> > >
>> > >
>> >
>> >
>>

Jacopo Cappellato

Re: Payment due date/paid date

In reply to this post by Scott Gray

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 <[hidden email]> 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, [hidden email] <[hidden email] > 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
>> > >
>> > >
>> > > [hidden email] 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
>> > >
>> > >
>> >
>> >
>>
>

Jacopo Cappellato

Re: Payment due date/paid date

In reply to this post by mrisaliti@libero.it

In my opinion we should simply add to the primary key of the
AgreementTerm, BillingAccountTerm, InvoiceTerm, OrderTerm and QuoteTerm
entities the "sequenceNum" field.
In this way, for example, we could have the same termTypeId associated
to the same order.
AgreementTerm should not be mandatory; even if, right now, for sales
orders using the agreement is the only way to add the terms to an order,
this is only a user interface issue (and there is a Jira issue to fix it
https://issues.apache.org/jira/browse/OFBIZ-266); we should be able to
add order terms even if the supplier/customer doesn't have an agreement
on file.

Does it make sense?

Jacopo

[hidden email] wrote:

> Hi Scott,
>
> thanks for your promptly reply to this issue.
> I think you are right from the entitiy design point of view but from the
> user interface point of view the effects are different.
> If you try to create a purchase order on the supplier DemoSupplier
> selecting the agreement AGR_TEST you will see after the checkout that on
> the screen the orderItemSeqId are used as rows of the terms.
> So looking at the actual code I made I mistake because I have understand
> that orderItemSeqId in this case was used as row of the agreement term.
> Probably in my opinion is enough to add the foreign key to the
> AgreementTerm (agreementTermId) and also removed the redundant fields
> termValue, termDays, description (directly retrieved from the new
> foreign key) for the entity BillingAccountTerm, InvoiceTerm, OrderTerm,
> QuoteTerm.
> We have to think about also to change the PK of those entities (now is
> termTypeId, orderId, orderItemSeqId) ?
> Doing those changes probably I can solve the issue in the correct way,
> entity design and u.i. point of view.
>
> Thanks
> Marco
>
>
> Il giorno 15/apr/07, alle ore 01:10, Scott Gray ha scritto:
>
>> 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 <[hidden email]> 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, [hidden email] <[hidden email] > 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
>>> > >
>>> > >
>>> > > [hidden email] 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
>>> > >
>>> > >
>>> >
>>> >
>>>
>
>

cjhowe

Re: Payment due date/paid date

(Real world thinking)
Doesn't the use of a term presuppose an agreement? Whether that
agreement has been logged into OFBiz is a different story. Doesn't the
agreement actually exist?

--- Jacopo Cappellato <[hidden email]> wrote:

> In my opinion we should simply add to the primary key of the
> AgreementTerm, BillingAccountTerm, InvoiceTerm, OrderTerm and
> QuoteTerm
> entities the "sequenceNum" field.
> In this way, for example, we could have the same termTypeId
> associated
> to the same order.
> AgreementTerm should not be mandatory; even if, right now, for sales
> orders using the agreement is the only way to add the terms to an
> order,
> this is only a user interface issue (and there is a Jira issue to fix
> it
> https://issues.apache.org/jira/browse/OFBIZ-266); we should be able
> to
> add order terms even if the supplier/customer doesn't have an
> agreement
> on file.
>
> Does it make sense?
>
> Jacopo
>
> [hidden email] wrote:
> > Hi Scott,
> >
> > thanks for your promptly reply to this issue.
> > I think you are right from the entitiy design point of view but
> from the
> > user interface point of view the effects are different.
> > If you try to create a purchase order on the supplier DemoSupplier
> > selecting the agreement AGR_TEST you will see after the checkout
> that on
> > the screen the orderItemSeqId are used as rows of the terms.
> > So looking at the actual code I made I mistake because I have
> understand
> > that orderItemSeqId in this case was used as row of the agreement
> term.
> > Probably in my opinion is enough to add the foreign key to the
> > AgreementTerm (agreementTermId) and also removed the redundant
> fields
> > termValue, termDays, description (directly retrieved from the new
> > foreign key) for the entity BillingAccountTerm, InvoiceTerm,
> OrderTerm,
> > QuoteTerm.
> > We have to think about also to change the PK of those entities (now
> is
> > termTypeId, orderId, orderItemSeqId) ?
> > Doing those changes probably I can solve the issue in the correct
> way,
> > entity design and u.i. point of view.
> >
> > Thanks
> > Marco
> >
> >
> > Il giorno 15/apr/07, alle ore 01:10, Scott Gray ha scritto:
> >
> >> 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 <[hidden email]> 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, [hidden email] <[hidden email] > 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
> >>> > >
> >>> > >
> >>> > > [hidden email] 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
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
> >
> >
>
>
>

Jacopo Cappellato

Re: Payment due date/paid date

Chris,

yes, of course, an agreement between the company and the customer is
implied, even if not stored in OFBiz, when the term is added to an order.

Jacopo

Chris Howe wrote:
> (Real world thinking)
> Doesn't the use of a term presuppose an agreement? Whether that
> agreement has been logged into OFBiz is a different story. Doesn't the
> agreement actually exist?
>

cjhowe

Re: Payment due date/paid date

then..(program logic thinking)
When an invoice is created it should determine the InvoiceTerm by
cascading StoreSetting overridden by BillingAccountTerm setting
overridden by AgreementTerm overridden by OrderTerm (QuoteTerm's use
should only be used to create the OrderTerm when creating the Order and
should not be used during the creation of the InvoiceTerm)

--- Jacopo Cappellato <[hidden email]> wrote:

> Chris,
>
> yes, of course, an agreement between the company and the customer is
> implied, even if not stored in OFBiz, when the term is added to an
> order.
>
> Jacopo
>
>
> Chris Howe wrote:
> > (Real world thinking)
> > Doesn't the use of a term presuppose an agreement? Whether that
> > agreement has been logged into OFBiz is a different story. Doesn't
> the
> > agreement actually exist?
> >
>
>
>

Jacopo Cappellato

Re: Payment due date/paid date

I don't agree with this.
In my opinion the invoice should only look at the order terms (and maybe
the billing account terms).

Jacopo

Chris Howe wrote:

> then..(program logic thinking)
> When an invoice is created it should determine the InvoiceTerm by
> cascading StoreSetting overridden by BillingAccountTerm setting
> overridden by AgreementTerm overridden by OrderTerm (QuoteTerm's use
> should only be used to create the OrderTerm when creating the Order and
> should not be used during the creation of the InvoiceTerm)
>
>
> --- Jacopo Cappellato <[hidden email]> wrote:
>
>> Chris,
>>
>> yes, of course, an agreement between the company and the customer is
>> implied, even if not stored in OFBiz, when the term is added to an
>> order.
>>
>> Jacopo
>>
>>
>> Chris Howe wrote:
>>> (Real world thinking)
>>> Doesn't the use of a term presuppose an agreement? Whether that
>>> agreement has been logged into OFBiz is a different story. Doesn't
>> the
>>> agreement actually exist?
>>>
>>
>>

cjhowe

Re: Payment due date/paid date

To implement that redundancy onto the OrderTerm* would eliminate the
ability to model implicit terms and explicit terms. Therefore making
impossible to audit term changes.

*That's assuming that you're populating the OrderTerm with the cascaded
values from a store setting, BillingAccountTerm, AgreementTerm,
QuoteTerm.
--- Jacopo Cappellato <[hidden email]> wrote:

> I don't agree with this.
> In my opinion the invoice should only look at the order terms (and
> maybe
> the billing account terms).
>
> Jacopo
>
> Chris Howe wrote:
> > then..(program logic thinking)
> > When an invoice is created it should determine the InvoiceTerm by
> > cascading StoreSetting overridden by BillingAccountTerm setting
> > overridden by AgreementTerm overridden by OrderTerm (QuoteTerm's
> use
> > should only be used to create the OrderTerm when creating the Order
> and
> > should not be used during the creation of the InvoiceTerm)
> >
> >
> > --- Jacopo Cappellato <[hidden email]> wrote:
> >
> >> Chris,
> >>
> >> yes, of course, an agreement between the company and the customer
> is
> >> implied, even if not stored in OFBiz, when the term is added to an
> >> order.
> >>
> >> Jacopo
> >>
> >>
> >> Chris Howe wrote:
> >>> (Real world thinking)
> >>> Doesn't the use of a term presuppose an agreement? Whether that
> >>> agreement has been logged into OFBiz is a different story.
> Doesn't
> >> the
> >>> agreement actually exist?
> >>>
> >>
> >>
>
>
>

mrisaliti@libero.it

Re: Payment due date/paid date

In reply to this post by Jacopo Cappellato

Ok, Jacopo & Scott if you agree with me I can add this new field
sequenceNum to those 4 entities and insert it as new field of the
primary key.
Then I will update the issue already open with a new patch.
What about then to add the new fields dueDate and paidDate to the
Payment entity may I can do it in a different patch/jira issue ?

Thanks to both of you for your help
Marco

Il giorno 15/apr/07, alle ore 09:31, Jacopo Cappellato ha scritto:

> In my opinion we should simply add to the primary key of the
> AgreementTerm, BillingAccountTerm, InvoiceTerm, OrderTerm and
> QuoteTerm entities the "sequenceNum" field.
> In this way, for example, we could have the same termTypeId
> associated to the same order.
> AgreementTerm should not be mandatory; even if, right now, for
> sales orders using the agreement is the only way to add the terms
> to an order, this is only a user interface issue (and there is a
> Jira issue to fix it https://issues.apache.org/jira/browse/
> OFBIZ-266); we should be able to add order terms even if the
> supplier/customer doesn't have an agreement on file.
>
> Does it make sense?
>
> Jacopo
>
> [hidden email] wrote:
>> Hi Scott,
>> thanks for your promptly reply to this issue.
>> I think you are right from the entitiy design point of view but
>> from the user interface point of view the effects are different.
>> If you try to create a purchase order on the supplier DemoSupplier
>> selecting the agreement AGR_TEST you will see after the checkout
>> that on the screen the orderItemSeqId are used as rows of the terms.
>> So looking at the actual code I made I mistake because I have
>> understand that orderItemSeqId in this case was used as row of the
>> agreement term.
>> Probably in my opinion is enough to add the foreign key to the
>> AgreementTerm (agreementTermId) and also removed the redundant
>> fields termValue, termDays, description (directly retrieved from
>> the new foreign key) for the entity BillingAccountTerm,
>> InvoiceTerm, OrderTerm, QuoteTerm.
>> We have to think about also to change the PK of those entities
>> (now is termTypeId, orderId, orderItemSeqId) ?
>> Doing those changes probably I can solve the issue in the correct
>> way, entity design and u.i. point of view.
>> Thanks
>> Marco
>> Il giorno 15/apr/07, alle ore 01:10, Scott Gray ha scritto:
>>> 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 <[hidden email]> 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, [hidden email] <[hidden email] > 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
>>>> > >
>>>> > >
>>>> > > [hidden email] 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
>>>> > >
>>>> > >
>>>> >
>>>> >
>>>>
>
>

David E Jones

Re: Payment due date/paid date

If it is part of the primary key the naming convention means a suffix
of "SeqId", something like termSeqId.

-David

On Apr 16, 2007, at 2:58 PM, [hidden email] wrote:

> Ok, Jacopo & Scott if you agree with me I can add this new field
> sequenceNum to those 4 entities and insert it as new field of the
> primary key.
> Then I will update the issue already open with a new patch.
> What about then to add the new fields dueDate and paidDate to the
> Payment entity may I can do it in a different patch/jira issue ?
>
> Thanks to both of you for your help
> Marco
>
>
> Il giorno 15/apr/07, alle ore 09:31, Jacopo Cappellato ha scritto:
>
>> In my opinion we should simply add to the primary key of the
>> AgreementTerm, BillingAccountTerm, InvoiceTerm, OrderTerm and
>> QuoteTerm entities the "sequenceNum" field.
>> In this way, for example, we could have the same termTypeId
>> associated to the same order.
>> AgreementTerm should not be mandatory; even if, right now, for
>> sales orders using the agreement is the only way to add the terms
>> to an order, this is only a user interface issue (and there is a
>> Jira issue to fix it https://issues.apache.org/jira/browse/
>> OFBIZ-266); we should be able to add order terms even if the
>> supplier/customer doesn't have an agreement on file.
>>
>> Does it make sense?
>>
>> Jacopo
>>
>> [hidden email] wrote:
>>> Hi Scott,
>>> thanks for your promptly reply to this issue.
>>> I think you are right from the entitiy design point of view but
>>> from the user interface point of view the effects are different.
>>> If you try to create a purchase order on the supplier
>>> DemoSupplier selecting the agreement AGR_TEST you will see after
>>> the checkout that on the screen the orderItemSeqId are used as
>>> rows of the terms.
>>> So looking at the actual code I made I mistake because I have
>>> understand that orderItemSeqId in this case was used as row of
>>> the agreement term.
>>> Probably in my opinion is enough to add the foreign key to the
>>> AgreementTerm (agreementTermId) and also removed the redundant
>>> fields termValue, termDays, description (directly retrieved from
>>> the new foreign key) for the entity BillingAccountTerm,
>>> InvoiceTerm, OrderTerm, QuoteTerm.
>>> We have to think about also to change the PK of those entities
>>> (now is termTypeId, orderId, orderItemSeqId) ?
>>> Doing those changes probably I can solve the issue in the correct
>>> way, entity design and u.i. point of view.
>>> Thanks
>>> Marco
>>> Il giorno 15/apr/07, alle ore 01:10, Scott Gray ha scritto:
>>>> 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 <[hidden email]> 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, [hidden email] <[hidden email] > 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
>>>>> > >
>>>>> > >
>>>>> > > [hidden email] 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
>>>>> > >
>>>>> > >
>>>>> >
>>>>> >
>>>>>
>>
>>
>

smime.p7s (3K) Download Attachment

mrisaliti@libero.it

Re: Payment due date/paid date

Ok, Thanks David I will use termSeqId as field name.

Il giorno 16/apr/07, alle ore 23:07, David E. Jones ha scritto:

>
> If it is part of the primary key the naming convention means a
> suffix of "SeqId", something like termSeqId.
>
> -David
>
>
> On Apr 16, 2007, at 2:58 PM, [hidden email] wrote:
>
>> Ok, Jacopo & Scott if you agree with me I can add this new field
>> sequenceNum to those 4 entities and insert it as new field of the
>> primary key.
>> Then I will update the issue already open with a new patch.
>> What about then to add the new fields dueDate and paidDate to the
>> Payment entity may I can do it in a different patch/jira issue ?
>>
>> Thanks to both of you for your help
>> Marco
>>
>>
>> Il giorno 15/apr/07, alle ore 09:31, Jacopo Cappellato ha scritto:
>>
>>> In my opinion we should simply add to the primary key of the
>>> AgreementTerm, BillingAccountTerm, InvoiceTerm, OrderTerm and
>>> QuoteTerm entities the "sequenceNum" field.
>>> In this way, for example, we could have the same termTypeId
>>> associated to the same order.
>>> AgreementTerm should not be mandatory; even if, right now, for
>>> sales orders using the agreement is the only way to add the terms
>>> to an order, this is only a user interface issue (and there is a
>>> Jira issue to fix it https://issues.apache.org/jira/browse/
>>> OFBIZ-266); we should be able to add order terms even if the
>>> supplier/customer doesn't have an agreement on file.
>>>
>>> Does it make sense?
>>>
>>> Jacopo
>>>
>>> [hidden email] wrote:
>>>> Hi Scott,
>>>> thanks for your promptly reply to this issue.
>>>> I think you are right from the entitiy design point of view but
>>>> from the user interface point of view the effects are different.
>>>> If you try to create a purchase order on the supplier
>>>> DemoSupplier selecting the agreement AGR_TEST you will see after
>>>> the checkout that on the screen the orderItemSeqId are used as
>>>> rows of the terms.
>>>> So looking at the actual code I made I mistake because I have
>>>> understand that orderItemSeqId in this case was used as row of
>>>> the agreement term.
>>>> Probably in my opinion is enough to add the foreign key to the
>>>> AgreementTerm (agreementTermId) and also removed the redundant
>>>> fields termValue, termDays, description (directly retrieved from
>>>> the new foreign key) for the entity BillingAccountTerm,
>>>> InvoiceTerm, OrderTerm, QuoteTerm.
>>>> We have to think about also to change the PK of those entities
>>>> (now is termTypeId, orderId, orderItemSeqId) ?
>>>> Doing those changes probably I can solve the issue in the
>>>> correct way, entity design and u.i. point of view.
>>>> Thanks
>>>> Marco
>>>> Il giorno 15/apr/07, alle ore 01:10, Scott Gray ha scritto:
>>>>> 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 <[hidden email]> 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, [hidden email] <[hidden email] > 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
>>>>>> > >
>>>>>> > >
>>>>>> > > [hidden email] 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
>>>>>> > >
>>>>>> > >
>>>>>> >
>>>>>> >
>>>>>>
>>>
>>>
>>
>

mrisaliti@libero.it

Re: Payment due date/paid date

In reply to this post by David E Jones

Probably I think it's better to use orderTermSeqId as field name for
the OrderTerm entity (and InvoiceTermSeqId, ...).
What did you think of it ?

Thanks
Marco

Il giorno 16/apr/07, alle ore 23:07, David E. Jones ha scritto: