[
https://issues.apache.org/jira/browse/OFBIZ-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anil K Patel closed OFBIZ-1557.
---
Resolution: Fixed
Tasks in scope are complete.
> Accounts Receivable & Accounts Paya
more needed to be open, we can close this issue.
> Accounts Receivable & Accounts Payable web applications added in Accounting
> Component
> -
>
> Key: OFBIZ-1557
>
[
https://issues.apache.org/jira/browse/OFBIZ-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux closed OFBIZ-1421.
--
Resolution: Incomplete
Fix Version/s: SVN trunk
> Accounts Receivable mod
[
https://issues.apache.org/jira/browse/OFBIZ-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux reassigned OFBIZ-1421:
--
Assignee: Christian Geisert (was: Jacques Le Roux)
> Accounts Receivable mod
[
https://issues.apache.org/jira/browse/OFBIZ-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619125#action_12619125
]
BJ Freeman commented on OFBIZ-1421:
---
so no further work
so it can be closed
> A
its funcitonality.
> Accounts Receivable module
> --
>
> Key: OFBIZ-1421
> URL: https://issues.apache.org/jira/browse/OFBIZ-1421
> Project: OFBiz
> Issue Type: Improvement
>
ssed.
> Accounts Receivable module
> --
>
> Key: OFBIZ-1421
> URL: https://issues.apache.org/jira/browse/OFBIZ-1421
> Project: OFBiz
> Issue Type: Improvement
> Components: accounting
>
bmit
> Accounts Receivable module
> --
>
> Key: OFBIZ-1421
> URL: https://issues.apache.org/jira/browse/OFBIZ-1421
> Project: OFBiz
> Issue Type: Improvement
> Components: accounting
>
ting code that has had the ASF
approval.
that was my question.
figured that was the reason it was not put in ofbiz.
> Accounts Receivable module
> --
>
> Key: OFBIZ-1421
> URL: https://issues.apache.org/jira/browse/OFBIZ-1421
&g
[
https://issues.apache.org/jira/browse/OFBIZ-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux reopened OFBIZ-1421:
Nothing better than a closed to see if an issue is still alive :D
> Accounts Receiva
(the collections screens notably) not currently in
Ofbiz. It is currently in production use and heavily used by the AR folks.
Happy to help however I can.
Skip
> Accounts Receivable module
> --
>
> Key: OFBIZ-1421
> URL: https:
code, although module this was finished some
time ago for me.
Skip
> Accounts Receivable module
> --
>
> Key: OFBIZ-1421
> URL: https://issues.apache.org/jira/browse/OFBIZ-1421
> Project: OFBiz
>
tted. However, feel free to close
it if there is no community interest.
Skip
> Accounts Receivable module
> --
>
> Key: OFBIZ-1421
> URL: https://issues.apache.org/jira/browse/OFBIZ-1421
> Project: OFBiz
when you will get a chance... Maybe Skip as well might be
interested...
> Accounts Receivable module
> --
>
> Key: OFBIZ-1421
> URL: https://issues.apache.org/jira/browse/OFBIZ-1421
> Project: OFBiz
>
been licensed for inclusion in ASF works.
I didn't have a look at this yet but it sounds interesting and Skip seems
willing to help to adapt this further to OFBiz
> Accounts Receivable module
> --
>
> Key: OFBIZ-1421
> URL: h
[
https://issues.apache.org/jira/browse/OFBIZ-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux closed OFBIZ-1421.
--
Resolution: Invalid
Assignee: Jacques Le Roux
> Accounts Receivable mod
27;t have the apache clearance.
doubt this will go further.
> Accounts Receivable module
> --
>
> Key: OFBIZ-1421
> URL: https://issues.apache.org/jira/browse/OFBIZ-1421
> Project: OFBiz
> Issue Type: Imp
mation about it you may find useful
information in this thread:
http://www.nabble.com/Adding-a-new-field-%28bankPartyId%29-to-the-EftAccount-entity-tp13907779p13907779.html
Jacopo
> Accounts Receivable & Accounts Payable web applications added
[
https://issues.apache.org/jira/browse/OFBIZ-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pankaj Savita updated OFBIZ-1557:
-
Attachment: Accounting_AR_AP.patch
Here is the patch for the basic setup of Accounts Receivable
Accounts Receivable & Accounts Payable web applications added in Accounting
Component
-
Key: OFBIZ-1557
URL: https://issues.apache.org/jira/browse/OFBIZ-1557
Pro
{
background-color: #95;
}
.purpleOdd {
background-color: #FFCEFF;
}
.purpleEven {
background-color: #FFB06F;
}
> Accounts Receivable module
> --
>
> Key: OFBIZ-1421
> URL: https://issues.apache.org/jira/br
be happy to refactor the monolithic BillingAccountWorker.java if I had
some direction as to what would be acceptable for inclusing in the Ofbiz
project.
> Accounts Receivable module
> --
>
> Key: OFBIZ-1421
> URL: https://is
specific is given freely.
> Accounts Receivable module
> --
>
> Key: OFBIZ-1421
> URL: https://issues.apache.org/jira/browse/OFBIZ-1421
> Project: OFBiz
> Issue Type: Improvement
>
significant portion of
their sales to customers with net xxx terms, like net 30. It has no value for
normal web based businesses unless you are selling over and over to the same
customer and they don't pay the bill at the sale time.
> Accounts Receivabl
Opentaps references in the widgets directory.
However, I am happy to pull that out and resubmit it if desired.
> Accounts Receivable module
> --
>
> Key: OFBIZ-1421
> URL: https://issues.apache.org/jira/browse/OFBIZ-1421
>
Accounts Receivable module
--
Key: OFBIZ-1421
URL: https://issues.apache.org/jira/browse/OFBIZ-1421
Project: OFBiz
Issue Type: Improvement
Components: accounting
Reporter: Skip Dever
+1
Chris
-Original Message-
From: Adrian Crum [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 21, 2007 3:03 PM
To: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable
[EMAIL PROTECTED] wrote:
> The big question for me is, are there any users who need real accounts
receiva
color me interested.
On Nov 21, 2007 2:03 PM, Adrian Crum <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > The big question for me is, are there any users who need real accounts
> > receivable? This is not your typical need for most web based sales. It is
>
[EMAIL PROTECTED] wrote:
The big question for me is, are there any users who need real accounts
receivable? This is not your typical need for most web based sales. It is
more appropriate for organizations that do a significant part of their business
using net x terms.
Skip,
Our company
I have the proposed modificatins to implement a real accounts receivable module
finished except for the collections part which I am working on ATM and a SECA
to apply avaliable credits automatically (not really sure if I want to do this
or maybe have it configurable). All the code however is
CTED]
Sent: Friday, November 02, 2007 11:32 PM
To: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable
Hi Skip,
[EMAIL PROTECTED] wrote:
> Scott
>
> In my view, this is kinda the hard way of doing things.
>
> Easy way:
>
> billing account amount = SUM(unpaid invoice amoun
riday, November 02, 2007 11:32 PM
To: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable
Hi Skip,
[EMAIL PROTECTED] wrote:
> Scott
>
> In my view, this is kinda the hard way of doing things.
>
> Easy way:
>
> billing account amount = SUM(unpaid invoice amounts)
> bill
Hi Skip,
[EMAIL PROTECTED] wrote:
Scott
In my view, this is kinda the hard way of doing things.
Easy way:
billing account amount = SUM(unpaid invoice amounts)
billing account available balance = billing acount limit - (billing account
amount + uninvoiced orders)
Because customer returns and
Subject: Re: Accounts Receivable
GL has a defualt all in one number for non GL accounting
however if the granularity gets down to individual GL for each customer
account I can see that you would need to do transactions to keep them
uptodated.
and in a GL it has to be a transaction for audit trail
-
> From: BJ Freeman [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 02, 2007 7:27 PM
> To: dev@ofbiz.apache.org
> Subject: Re: Accounts Receivable
>
>
> skip how does this fit with GL and transactions.
>
> [EMAIL PROTECTED] sent the following on 11/2/2007 12:58
: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable
skip how does this fit with GL and transactions.
[EMAIL PROTECTED] sent the following on 11/2/2007 12:58 PM:
> Scott
>
> In my view, this is kinda the hard way of doing things.
>
> Easy way:
>
> billing account amount
to:[EMAIL PROTECTED]
> Sent: Friday, November 02, 2007 1:02 PM
> To: dev@ofbiz.apache.org
> Subject: Re: Accounts Receivable
>
>
> Hrmm that is a bit of problem, perhaps instead of using maxAmount we
> should do this:
> billing account amount = order grand total -
> SUM(otherPaymentP
.
Skip
-Original Message-
From: Scott Gray [mailto:[EMAIL PROTECTED]
Sent: Friday, November 02, 2007 1:02 PM
To: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable
Hrmm that is a bit of problem, perhaps instead of using maxAmount we
should do this:
billing account amount = order grand
Thank you sir.
-Original Message-
From: Scott Gray [mailto:[EMAIL PROTECTED]
Sent: Friday, November 02, 2007 12:54 PM
To: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable
Here's the diff:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/src/org/ofbiz/or
der/shoppin
ferences is not
> the data underlying billing account.
>
> Skip
>
> -Original Message-
> From: Scott Gray [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 01, 2007 11:48 PM
> To: dev@ofbiz.apache.org
> Subject: Re: Accounts Receivable
>
>
> Hi Skip,
what files were affected? I want to move this fix into my
> production code, but not the whole 591434 svn download.
>
> Skip
>
> -Original Message-
> From: Scott Gray [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 02, 2007 2:47 AM
> To: dev@ofbiz.apache.org
>
: Accounts Receivable
Found and fixed the problem in rev. 591283, quick checkout wasn't
recalculating shipping and taxes before loading the payment info.
Regards
Scott
On 02/11/2007, Scott Gray <[EMAIL PROTECTED]> wrote:
> Hi Skip, Jacopo
>
> >There are flaws
> >and compli
branch to its
limits now)."
My response? YAAA
Skip
-Original Message-
From: Jonathon -- Improov [mailto:[EMAIL PROTECTED]
Sent: Friday, November 02, 2007 1:18 AM
To: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable
A quick question here. Isn't maxAmount *not* su
the data underlying billing account.
Skip
-Original Message-
From: Scott Gray [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 01, 2007 11:48 PM
To: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable
Hi Skip, Jacopo
>There are flaws
>and complications in the latter in that t
ot hooked it up to Ofbiz
code and won't unless this becomes mainsteamed.
Skip
-Original Message-
From: Jacopo Cappellato [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 01, 2007 11:09 PM
To: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable
Hi Skip,
this looks interesting
> > > captureBillingAccountPayments and let the Ofbiz service run. There is one
> > > screen to change in Opentaps code in viewCustomerBillAcct."Customer
> > > Billing
> > > Account Transactions" where outstanding invoices are not being displayed.
>
ginal Message-
From: Scott Gray [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 01, 2007 3:43 AM
To: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable
Yeah I guess it would help with that, although you still could still
pay an invoice directly with it (no billingAccountId on the Invoice
; the same named (and modified) Ofbiz routines.
> >
> > TODO is a SECA to automatically apply any available credits when a new
> > billing account invoice is created.
> >
> > Can anyone see any holes in this or have any comments?
> >
> > Skip
> >
> &
vember 01, 2007 3:43 AM
To: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable
Yeah I guess it would help with that, although you still could still
pay an invoice directly with it (no billingAccountId on the Invoice),
but you couldn't associate the Payment with more than one billing
acc
---
From: Scott Gray [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 01, 2007 3:43 AM
To: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable
Yeah I guess it would help with that, although you still could still
pay an invoice directly with it (no billingAccountId on the Invoice),
but you couldn&
To: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable
Hi Jacopo
I decided to have a look at this stuff and it doesn't make sense to me
why we have the billingAccountId on PaymentApplication rather than on
Payment itself? It seems like the logic is pretty much the same
except we're d
Yeah I guess it would help with that, although you still could still
pay an invoice directly with it (no billingAccountId on the Invoice),
but you couldn't associate the Payment with more than one billing
account unless you went for a many to many relationship. But that's
fine, I just thought I'd
Hi Scott,
Scott Gray wrote:
Hi Jacopo
I decided to have a look at this stuff and it doesn't make sense to me
why we have the billingAccountId on PaymentApplication rather than on
Payment itself?
I agree with you that having the billingAccountId in the Payment entity
would have made things si
mailto:[EMAIL PROTECTED]
> Sent: Monday, October 29, 2007 12:05 PM
> To: dev@ofbiz.apache.org
> Subject: Re: Accounts Receivable
>
>
> [EMAIL PROTECTED] wrote:
> > Jacopo
> >
> > The assumtion for me is that these are all dealing with billing accounts.
&g
Thanks Jacopo, I'll implement it in this way and see how it goes.
Skip
-Original Message-
From: Jacopo Cappellato [mailto:[EMAIL PROTECTED]
Sent: Monday, October 29, 2007 12:05 PM
To: dev@ofbiz.apache.org
Subject: Re: Accounts Receivable
[EMAIL PROTECTED] wrote:
> Jacopo
[EMAIL PROTECTED] wrote:
Jacopo
The assumtion for me is that these are all dealing with billing accounts.
No billing account, no AR. Stated differently, the sum of billing account
invoices - (billing account payments + store credits) = Accounts Receivable.
Is there some billing account entity I
Jacopo
The assumtion for me is that these are all dealing with billing accounts.
No billing account, no AR. Stated differently, the sum of billing account
invoices - (billing account payments + store credits) = Accounts Receivable.
Is there some billing account entity I missed to hold credits
Okeydokey Jacques, moved the discussion here (in spite of the fact that I'll
get another gazillion emails to sort through :).
One final issue to deal with for me, and that is credits. Right now, if you
overpay, you get an orphan PaymentApplication (no Invoice). This is fine
for computing the bal
Hi Skip,
[EMAIL PROTECTED] wrote:
Okeydokey Jacques, moved the discussion here (in spite of the fact that I'll
get another gazillion emails to sort through :).
One final issue to deal with for me, and that is credits. Right now, if you
overpay, you get an orphan PaymentApplication (no Invoice)
59 matches
Mail list logo
