Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
Locked
123
123
RE: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
 
|
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
|
|
RE: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
|
|
RE: JFreeChart
|
|
Re: JFreeChart
|
|
Re: JFreeChart
Administrator
|
Re: Billing Accounts
|
|
In reply to this post by SkipDever
A Payment applied to a BillingAccount does not mean the payment is closed, in fact I'm not even sure what it means to say a payment is closed... did you have something in mind? Whatever it means to you, a payment is either not, partially, or fully applied. -David On Nov 25, 2007, at 11:54 AM, skip@thedevers wrote: > Jacapo > > https://localhost:8443/accounting/control/editPaymentApplications > > and one of them involves applying it to the billing account. > > I don't see the point in applying a payment to a billing account. > Otherwise, how to you know when an invoice is paid? What happens > later, do > you take the money out of the billing account and apply it to an > invoice? > > There may be some european need that I am not aware of to apply a > customer > payment to a Tax Authority, but that is not the case in the U.S, so > I don't > see the point in the Tax Auth Geo ID. > > The main one for me is applying a payment to a billing account. If > there > are no invoices to apply to, the Payment should stay open. It makes > everything else then so easy. > > > Skip > > > > -----Original Message----- > From: Jacopo Cappellato [mailto:[hidden email]] > Sent: Saturday, November 24, 2007 11:45 PM > To: [hidden email] > Subject: Re: Billing Accounts > > > Skip, > > I very well remember that valuable message from David: it helped me a > lot when I've recently refactored the billing accounts. > Where is the current implementation not following David's notes? > > Thanks, > > Jacopo > > skip@thedevers wrote: >> I just ran across this in the Wiki from David concerning Billing >> Accounts >> from back in July. >> >> http://docs.ofbiz.org/display/OFBIZ/Billing+Account >> >> The current Ofbiz implementation does not operate as described in >> this >> document. The "addon" I partially provided here: >> >> https://issues.apache.org/jira/browse/OFBIZ-1421 >> >> follows it exactly or nearly so. Furthermore, the logic is so >> simple. It >> is a shame that billingAccountId ended up in so many entities. >> >> I think these paragraphs bear repeating because he says it so much >> better >> than me: >> >> "A BillingAccount is essentially nothing. Just forget that it >> exists in >> relation to regular Invoice and Payment processes. With or without a >> BillingAccount those operate and flow the same. >> >> A BillingAccount simply allows for more organization of Invoices and >> Payments related to things like the following (which is not an >> exhaustive >> list by any means):" >> >> >> >> Skip > > > |
smime.p7s (3K)
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
|
|
In reply to this post by Jacopo Cappellato
Yes, that is correct, I mis-wrote. The origin "document" (record is probably a better term) triggers/ causes the transaction and not each entry in the transaction. -David On Nov 25, 2007, at 1:59 AM, Jacopo Cappellato wrote: > David, > > after reviewing the AcctgTrans and AcctgTransEntry entity I've > noticed that fixedAssetId, inventoryItemId, physicalInventoryId, > partyId, roleTypeId, invoiceId, paymentId, finAccountTransId, > shipmentId, receiptId, workEffortId are in the AcctgTrans entity, > while partyId and productId are defined in the AcctgTransEntry entity. > This sounds slightly different from #4 in your notes: > > > 4. origin "documents" (detail records) are associated with the > > transaction entry, and there are structures for this in OFBiz > > If the data model is correctly defined, it should be: > > 4. origin "documents" (detail records) are associated with the > transaction > > Sorry for the many questions, but I'm moving the information from > the list to the Wiki page and I want to be sure I understand the > design. > > Thanks, > > Jacopo > > > David E Jones wrote: >> Some notes on journals (GlJournal), transactions (AcctgTrans), >> transaction entries (AcctgTransEntry), etc: >> 1. they are optional, transactions do not have to be associated >> with a journal >> 2. a transaction is not associated with a GL account and does not >> represent a debit or credit, each entry in a transaction does >> 3. journals are not meant to be balanced, individual transactions >> are (checking to see whether or not an entire journal is balanced >> is simply a matter of seeing if each transaction is balanced >> 4. origin "documents" (detail records) are associated with the >> transaction entry, and there are structures for this in OFBiz >> I think this is mostly a difference in terminology, most of the >> rest of what you wrote sounds correct to me based on my >> understanding based on my research and collaboration with others on >> accounting systems. >> -David > |
RE: Billing Accounts
|
|
Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta
|
|
In reply to this post by SkipDever
On Nov 25, 2007, at 12:07 PM, skip@thedevers wrote: > More commonly, there is one post for the sum of the inventory items > sold. > However, this method offers some flexibility if you want to split up > cost of > goods or maybe you have separate inventory accounts for different > inventory > types. For that reason, I like it. Why thank you, I'm glad to hear some agreement/validation for my designs in this area. Of course, they really aren't my ideas just an application of ideas from: 1. The Data Model Resource Book, Revised Edition, Volume 1 (accounting, party, and other related areas) 2. the OMG GL interface specification 3. various books on accounting, including the accounting and supply chain books at http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Related+Books 4. the proposed OMG AR/AP interface specification, that lost backing in 2003 (if I remember the timing right), just looked it up and that is right, here is some info: http://ledgerism.net/ARAP/arapxml.htm Anyway, those are good sources for understanding the whys and wherefores behind accounting in OFBiz, and a bit of history as well. -David |
Re: Billing Accounts
|
|
In reply to this post by SkipDever
I can see how this might be confusing. The status has nothing to do with how much of the payment is applied. The PMNT_CONFIRMED is the final status for payments sent (if a confirmation is received, otherwise it is just the sent status; depends on the company and supplier processes). The PMNT_RECEIVED status is the final status for payments received. For more info on these statuses and transitions between them see the AccountingTypeData.xml file. This pattern is followed throughout OFBiz for other status sets (one for each type basically). -David P.S. It's great to see your involvement and commentary and thoughts Skip. You might have a better experience if you invested in a little more study before trying to follow OFBiz... it really can be very large and confusing if you don't have at least a basic grasp of some of the patterns (this one is a good example). The best place to get started, as I've mentioned in other emails, is these free videos and supporting artifacts: http://docs.ofbiz.org/display/OFBTECH/Framework+Introduction+Videos+and+Diagrams On Nov 25, 2007, at 3:58 PM, skip@thedevers wrote: > David > > This "closed" is more of a programming construct than anything real, > to me > at least. The status is PMNT_CONFIRMED. PMNT_CONFIRMED cannot be > set until > the payment is fully applied, and once set to PMNT_CONFIRMED, payment > applications cannot be removed. So to me, closed means > PMNT_CONFIRMED. > > In Ofbiz, you cannot set the status to PMNT_CONFIRMED until the > payment is > fully applied. This means that if you apply some or all of it to a > billing > account, that part of the payment applied to the billing account > goes out > into space somewhere, i.e. cannot be applied to a real invoice at > some later > point. > > My new code has a service triggered by the creation of an invoice > that goes > out looking for unapplied payments (and these include credits from > returns > etc). If a payment has been applied to a billing account, it will > not be > found, so the customer ends up forever having paid some money that > cannot be > applied to an invoice, at least not without a lot of what would have > been > unnecessary code. > > An Invoice remains unpaid (not INVOICE_PAID) until it has a > paymentapplication(s) to fully cover it. So the issue here is not so > much > with the Payment status, but with Invoice status and accounting for > it and > providing audit trails. > > It is for these reasons that I do not think it should be permitted > to apply > a payment to a billing account and why I agree with your statement "A > BillingAccount is essentially nothing. Just forget that it exists in > relation to regular Invoice and Payment processes." > > Customer payments should remain PMNT_RECEIVED (or something less) > until > fully applied to Invoices. For those users who don't want to > manually apply > a payment to Invoices one at a time, I have a service that will > automatically apply a Payment to the oldest Invoice(s). > > Skip > > -----Original Message----- > From: David E Jones [mailto:[hidden email]] > Sent: Sunday, November 25, 2007 2:03 PM > To: [hidden email] > Subject: Re: Billing Accounts > > > > A Payment applied to a BillingAccount does not mean the payment is > closed, in fact I'm not even sure what it means to say a payment is > closed... did you have something in mind? Whatever it means to you, a > payment is either not, partially, or fully applied. > > -David > > > On Nov 25, 2007, at 11:54 AM, skip@thedevers wrote: > >> Jacapo >> >> https://localhost:8443/accounting/control/editPaymentApplications >> >> and one of them involves applying it to the billing account. >> >> I don't see the point in applying a payment to a billing account. >> Otherwise, how to you know when an invoice is paid? What happens >> later, do >> you take the money out of the billing account and apply it to an >> invoice? >> >> There may be some european need that I am not aware of to apply a >> customer >> payment to a Tax Authority, but that is not the case in the U.S, so >> I don't >> see the point in the Tax Auth Geo ID. >> >> The main one for me is applying a payment to a billing account. If >> there >> are no invoices to apply to, the Payment should stay open. It makes >> everything else then so easy. >> >> >> Skip >> >> >> >> -----Original Message----- >> From: Jacopo Cappellato [mailto:[hidden email]] >> Sent: Saturday, November 24, 2007 11:45 PM >> To: [hidden email] >> Subject: Re: Billing Accounts >> >> >> Skip, >> >> I very well remember that valuable message from David: it helped me a >> lot when I've recently refactored the billing accounts. >> Where is the current implementation not following David's notes? >> >> Thanks, >> >> Jacopo >> >> skip@thedevers wrote: >>> I just ran across this in the Wiki from David concerning Billing >>> Accounts >>> from back in July. >>> >>> http://docs.ofbiz.org/display/OFBIZ/Billing+Account >>> >>> The current Ofbiz implementation does not operate as described in >>> this >>> document. The "addon" I partially provided here: >>> >>> https://issues.apache.org/jira/browse/OFBIZ-1421 >>> >>> follows it exactly or nearly so. Furthermore, the logic is so >>> simple. It >>> is a shame that billingAccountId ended up in so many entities. >>> >>> I think these paragraphs bear repeating because he says it so much >>> better >>> than me: >>> >>> "A BillingAccount is essentially nothing. Just forget that it >>> exists in >>> relation to regular Invoice and Payment processes. With or without a >>> BillingAccount those operate and flow the same. >>> >>> A BillingAccount simply allows for more organization of Invoices and >>> Payments related to things like the following (which is not an >>> exhaustive >>> list by any means):" >>> >>> >>> >>> Skip >> >> >> > > |
Re: JFreeChart
|
|
Re: JFreeChart
|
|
Re: JFreeChart
|
|
| Free forum by Nabble | Edit this page |