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