Re: Payment due date/paid date

[[EMAIL PROTECTED]]

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, [EMAIL PROTECTED] 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

[EMAIL PROTECTED] 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 <[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
> >
> >
>
>