I think the ball is now back to Aliya to clarify the data model. Tom - you're correct on what I'm asking. I'm asking for clarification because Aliya's previous reply seems to refer to actual Loan Accounts, rather than Loan Products. So I want to double check just to make sure.
On Nov 27, 2007 11:58 AM, Tom Bostelmann <[EMAIL PROTECTED]> wrote: > Ah, okay. So basically, the UI doesn't allow you to create multiple > "relationships" [LoanOfferFeesEntity] to the same fee. So, you're wondering > if that means that changes whether or not two instances of > LoanOfferFeesEntity with the same Fee are, in fact, distinct. Is this > correct? > > Aliya, you may correct me on this, but I think that it doesn't. Even > though the UI doesn't fully support the data model, I think the data model > needs to support two distinct relationships to the same fee. > > Does that answer your question, Sam? > > (good question btw ;) > -Tom > > > On Nov 26, 2007 9:53 PM, Sam Lee <[EMAIL PROTECTED]> wrote: > > > Tom / Aliya, > > > > Let me try again. What I'd like to get a clarity is whether > > LoanOfferFeesEntity has a business key or not. The answer will impact the > > correct equals() / hashCode() implementation for the Java object . > > > > I'll try to map the Java class in question to the actual UI and database > > tables to make sure we're on the same page. To the extent I could map, it > > looks like LoanOfferingBO refers to a Loan Product (rather than individual > > loan account). The UI (and the current ER data model) seems to imply a > > LoanOfferingBO (aka loan product on UI) can be associated with a FeeBO (aka > > Fee type on UI) at most once. > > > > > > The java classes in this context include: > > |---LoanOfferFeesEntity(id6)---| > > LoanOfferingBO(id1) -- ---- FeeBO(id2) > > |---LoanOfferFeesEntity(id5)---| > > > > 1. Could someone reconfirm if my understanding below is correct? > > 1a. A LoanOfferingBO (maps to prd_offering table + loan_offering table) > > instance maps to a Loan Product (rather than a Loan account) as in the the > > main object to be created in the Loan product definition screen: > > http://test.mifos.org:8085/mifos/loanproductaction.do?method=load&recordOfficeId=1&recordLoanOfficerId=1&randomNUm=-1022391167983022447 > > > > > > 1b. A LoanOfferFeesEntity (map to prd_offering_fees table) instance maps > > to the association between a fee type and the loan product (basically the > > fees section of the Loan Product definition screen above) > > > > 1c. A FeeBO (maps to fees table) instance maps to individual Fee Type. > > > > > > 2. If my understanding as in (1) is correct, > > 2a. Mifos web UI does not allow a loan product to be associated with a > > fee multiple times (it's a simple multi-selection form). > > 2b. Using the example Tom provided earlier on, I don't see anywhere in > > the loan product definition screen (loanproductaction.do) allowing the > > loan officers to define that a certain loan product require two consultation > > visits (and hence two consultation visit fees). > > 2c. in ER term, the LoanOfferFeesEntity (backed by prd_offering_fees > > table) has a business key of (product_id, fee_id). > > > > > > Thanks for the clarification in advance. Thanks. > > > > > > - sam > > On Nov 24, 2007 9:11 AM, Aliya Walji <[EMAIL PROTECTED]> > > wrote: > > > > > >> Here's my attempt at a business example (Aliya/Emily/Beth/Amy/... > > > please step in to correct me if I'm wrong): > > > > > > > > > > > > I think you're correct, Tom, on the functionality. According to the > > > FS "A particular fee instance can be applied multiple times to a customer > > > account". Checking out this functionality in the product also verifies > > > this > > > behavior. I can create a loan account with two of the same fee type > > > applied > > > to the account. > > > > > > > > > ------------------------------ > > > > > > *From:* [EMAIL PROTECTED] [mailto: > > > [EMAIL PROTECTED] * On Behalf Of *Tom > > > Bostelmann > > > *Sent:* Thursday, November 22, 2007 5:01 AM > > > *To:* Developer > > > * Subject:* Re: [Mifos-developer] issue 1512 persistent object > > > equals/hashCode- data model clarification needed > > > > > > > > > > > > This is a great question. The additional test fails - which it should > > > because LoanOfferingFeesEntity (bad use of plural 'Fees' in name aside) > > > represents an instance of a fee that is associated with the loan product. > > > > > > Here's my attempt at a business example (Aliya/Emily/Beth/Amy/... > > > please step in to correct me if I'm wrong): > > > > > > An example situation could be where the loan officer sets up a fee to > > > cover the costs of providing a consultation visit (this is represented by > > > the FeeBO). The loan officer has decided that a certain loan product > > > requires two such visits (two instances of LoanOfferingFeesEntity using > > > the > > > same FeeBO). Therefore there should be two different instances of the > > > same > > > fee associated with this loan product. > > > > > > Does that make sense? > > > > > > On Nov 14, 2007 11:12 PM, Sam Lee <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > I'm looking into issue 1512, the equals/hashCode issue identified from > > > findbug. > > > > > > To ensure I understand the business requirement / data model, could > > > someone clarify whether the following is true or not? > > > > > > 1. For each loan product, it may be associated with multiple fees. (I > > > guess fees the product could apply) > > > 2. However, each loan product will be associated with the same fee at > > > most once. In other words, in mysql, > > > table prd_offering_fees should have a unique constraint on > > > (prd_offering_id, fee_id) > > > > > > You can also see the attached patch on LoanOfferingBOTest that > > > reflects the above assumption. Or you can see the actual test right > > > below (rather than going through the patching). > > > > > > - sam > > > > > > A new test method in LoanOfferingBOTest.java (equivalent to the > > > attached patch) > > > > > > public void testBuildloanOfferingWithDuplicateFeeXXX() throws > > > SystemException, > > > ApplicationException { > > > createIntitalObjects(); > > > Date startDate = offSetCurrentDate(0); > > > LoanOfferingBO loanOffering = new > > > LoanOfferingBO(TestObjectFactory > > > .getContext(), "Loan Offering", "LOAN", > > > productCategory, > > > prdApplicableMaster, startDate, > > > interestTypes, > > > new Money("1000"), new Money("3000"), > > > 12.0, 2.0, 3.0, > > > (short) 20, (short) 1, (short) 12, > > > false, true, false, > > > frequency, principalglCodeEntity, > > > intglCodeEntity); > > > > > > FeeBO fee = TestObjectFactory.createOneTimeAmountFee("Loan > > > One time ", > > > FeeCategory.LOAN, "100", > > > FeePayment.UPFRONT); > > > > > > LoanOfferingFeesEntity loanOfferingFees1 = > > > new LoanOfferingFeesEntity(loanOffering, fee); > > > loanOffering.addPrdOfferingFee(loanOfferingFees1); > > > > > > // another fee for the proudct: which refers to the > > > same fee > > > // as the one above > > > LoanOfferingFeesEntity loanOfferingFees2 = > > > new LoanOfferingFeesEntity(loanOffering, fee); > > > loanOffering.addPrdOfferingFee (loanOfferingFees2); > > > > > > assertEquals("sam: I believe the business requirement > > > is that the > > > loan should not have fees that are essentially the same.", > > > 1, > > > loanOffering.getLoanOfferingFees().size()); > > > > > > assertEquals("sam: I belive these two offering fees are > > > considered > > > identical from business requirement", > > > true, > > > loanOfferingFees1.equals(loanOfferingFees2)); > > > > > > } > > > > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. > > > Still grepping through log files to find problems? Stop. > > > Now Search log events and configuration files using AJAX and a > > > browser. > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by: Microsoft > > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > > > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >
------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
