That sounds pretty complicated. For an end-user wouldn't this result
in confusing and unexpected behavior? In other words, if they
unselected all of the check boxes wouldn't they expect to see nothing?
If the side effect is that coming to the screen results in only the
top form showing, I
[
https://issues.apache.org/jira/browse/OFBIZ-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chirag Manocha updated OFBIZ-2706:
--
Attachment: IssueCheck_OFBiz-2706.patch
Patch for issue checks functionality for Ap Invoices.
Initially the default behavior of the Picking screen was to group
orders by shipping method and user does not have any choice to select
any other grouping method. With the introduction of additional
grouping methods like grouping by Warehouse Area and Number of Order
Items, I tried to keep
[
https://issues.apache.org/jira/browse/OFBIZ-2531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729524#action_12729524
]
Hans Bakker commented on OFBIZ-2531:
ii is always better to use existing screens and ex
--- On Thu, 7/9/09, David E Jones wrote:
> > 1. The document proposes converting the Security
> abstract class to an interface, and adding new methods to
> the interface that will implement the new security design.
> If there are no objections to changing Security to an
> interface, then I will d
[
https://issues.apache.org/jira/browse/OFBIZ-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729503#action_12729503
]
Anil K Patel commented on OFBIZ-2702:
-
BJ,
Thanks for bringing this up. I'll look into
On Jul 9, 2009, at 9:40 AM, Adrian Crum wrote:
I'm bumping this because I would like to begin working on it.
I've been updating the design document when I have time - http://docs.ofbiz.org/x/Ch8
.
There are two design issues that I would like to get finalized soon,
so that work can begin:
It can be easily configured by including/excluding the appropriate
StatusValidChange record.
-Adrian
Vince Clark wrote:
I agree, some companies may not want to allow voiding of paid invoices. But I
think something like that should be optional, more like a business rule that
can be configured
Agreed. The original postings should not be modified, no records should be
deleted, and the transaction information on the document should not be modified
such as the invoice amount and line items. However it would need to be updated
with a status of void and preferably a comment written into so
I agree, some companies may not want to allow voiding of paid invoices. But I
think something like that should be optional, more like a business rule that
can be configured.
Vince Clark
vcl...@globalera.com
(303) 493-6723
- Original Message -
From: "Adrian Crum"
To: dev@ofbiz.apach
just as a note, I took a different approach to getting the ID numbers to
sequence with out gaps.
I added a two fields that line to the record ID previous and Record ID
next. I keep the first record and last record ID for each record type,
in preference.
The next was more for speed, when do a check
Looking back through the commit and re-reading Jacopo's comments, I
believe Vince is correct about semantics: voiding an invoice is called
canceling an invoice in code.
So, canceling (voiding) an invoice is fine, but my preference would be
to keep the restriction that paid invoices can not be
what is important, regardless of the name is the process.
there should NOT be:
1) modification of a record already created even if done in error.
2) deletion of a record, even if done in error.
I believe Vince, Adrian and I are all saying do a reverse entry with
appropriate association to the orig
I agree with supporting the ability to void an invoice. A voided invoice
would have to be replaced with a new one. This is common practice when a
customer is billed in error.
-Adrian
Vince Clark wrote:
Maybe this is just semantics, but the term I am more familiar with (and comfortable with) i
Maybe this is just semantics, but the term I am more familiar with (and
comfortable with) is "void." Any "document" in the system that has accounting
consequences should support a void function. This includes payments, invoices,
and shipments. The exception is direct GL entries, which if done in
David E. Jones wrote:
This additional issue makes me wonder if we should allow canceling of
invoices at all.
The argument I'm trying to make is this: No, we should never allow an
invoice to be canceled. There are other methods of dealing with these
situations - and those methods have been aro
While I don't have any experience with ICU, I think this all sounds
pretty good...
-David
On Thu, 2009-07-09 at 08:03 -0700, adrian.c...@yahoo.com wrote:
> I would like to work on improving OFBiz's support for internationalization.
>
> When I first started work on the internationalization of O
In that scenario could we just allow the user to change which invoice a
payment is applied to (but leave the invoice as-is otherwise)? This may
fall into the issue that Adrian mentioned, but it sounds reasonable.
-David
On Thu, 2009-07-09 at 11:43 +0200, Jacopo Cappellato wrote:
> Well,
>
> a
That's an interesting issue Adrian, and actually different from the one
I was thinking about which was breaking a sequence of invoice IDs, and
also if you change the ID you would technically need to reissue the
invoice to the customer/client (especially if it was already paid
chances are they have
Don't we already have a place to enter shipping instructions?
Alternatively, don't order notes already have a public / private flag?
-Joe
On Jul 9, 2009, at 1:22 AM, m...@apache.org wrote:
Author: mor
Date: Thu Jul 9 05:22:02 2009
New Revision: 792402
URL: http://svn.apache.org/viewvc?rev=
So you create a credit memo for the invoice that has the incorrect
payment. You issue a debit memo to the party who made the payment, then
apply the credit balance to the correct invoice. I still don't see a
need to cancel a paid invoice.
I spoke with our accountant - he has never heard of "ca
How is the "No Grouping" option different from just not selecting any
grouping options?
-David
On Thu, 2009-07-09 at 15:19 +, m...@apache.org wrote:
> Author: mor
> Date: Thu Jul 9 15:19:47 2009
> New Revision: 792578
>
> URL: http://svn.apache.org/viewvc?rev=792578&view=rev
> Log:
> On p
[
https://issues.apache.org/jira/browse/OFBIZ-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729321#action_12729321
]
BJ Freeman commented on OFBIZ-2702:
---
I see a lot of activity on Accounting.
I would think
[
https://issues.apache.org/jira/browse/OFBIZ-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729309#action_12729309
]
Ashish Vijaywargiya commented on OFBIZ-2699:
Thanks Awdesh & Rishi!
Done at r79
[
https://issues.apache.org/jira/browse/OFBIZ-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729307#action_12729307
]
BJ Freeman commented on OFBIZ-2714:
---
this is a duplicate of
https://issues.apache.org/ji
I'm bumping this because I would like to begin working on it.
I've been updating the design document when I have time -
http://docs.ofbiz.org/x/Ch8.
There are two design issues that I would like to get finalized soon, so
that work can begin:
1. The document proposes converting the Security
I would like to work on improving OFBiz's support for internationalization.
When I first started work on the internationalization of OFBiz date/time
methods, I relied on the java.util.* classes and Sun's advice.
I'm starting to change how I feel about that. I think we should use the ICU
(http:
[
https://issues.apache.org/jira/browse/OFBIZ-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evangelina Bowman updated OFBIZ-2714:
-
Description:
I get the following error when trying to delete a Product from a Category:
[
https://issues.apache.org/jira/browse/OFBIZ-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evangelina Bowman updated OFBIZ-2714:
-
Component/s: product
Description:
I get the following error when trying t
[
https://issues.apache.org/jira/browse/OFBIZ-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evangelina Bowman updated OFBIZ-2714:
-
Comment: was deleted
(was: I get the following error when trying to DELETE a Product from
[
https://issues.apache.org/jira/browse/OFBIZ-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729280#action_12729280
]
Evangelina Bowman commented on OFBIZ-2714:
--
I get the following error when trying
Delete Product from Category
Key: OFBIZ-2714
URL: https://issues.apache.org/jira/browse/OFBIZ-2714
Project: OFBiz
Issue Type: Sub-task
Reporter: Evangelina Bowman
--
This message is automatically
is there reason, like performance that is was commented out.
I use this adhoc.
if it is to be configurable, then it should be through the webtools
I don't want to have to re-compile just to use it.
Adam Heath sent the following on 7/9/2009 5:53 AM:
> jone...@apache.org wrote:
>> Author: jonesde
>>
[
https://issues.apache.org/jira/browse/OFBIZ-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Awdesh Singh Parihar updated OFBIZ-2699:
Attachment: OFBiz_2699.patch
--Generated DepositSlip for payment group(Batch)
--The
jone...@apache.org wrote:
> Author: jonesde
> Date: Thu Jul 9 06:48:05 2009
> New Revision: 792420
>
> Modified:
> ofbiz/trunk/framework/entity/src/org/ofbiz/entity/datasource/GenericDAO.java
> URL:
> http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/src/org/ofbiz/entity/datasource/Gene
[
https://issues.apache.org/jira/browse/OFBIZ-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729225#action_12729225
]
Ashish Vijaywargiya commented on OFBIZ-2699:
Thanks Awdesh & Rishi.
Done at r79
[
https://issues.apache.org/jira/browse/OFBIZ-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Awdesh Singh Parihar updated OFBIZ-2699:
Attachment: OFBiz_2699.patch
Implemented the functionality to cancel payment group
[
https://issues.apache.org/jira/browse/OFBIZ-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish Vijaywargiya closed OFBIZ-2545.
--
Resolution: Fixed
Code is in trunk with few improvement & refactoring.
For more details
[
https://issues.apache.org/jira/browse/OFBIZ-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Divesh Dutta resolved OFBIZ-2709.
-
Resolution: Fixed
This has been fixed in revision number 792470. Thanks to Jacopo for fixing it.
[
https://issues.apache.org/jira/browse/OFBIZ-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Divesh Dutta closed OFBIZ-2709.
---
> Header links like Supplier Pref Order Id, minimumOrderQuantity, and lastPrice
> should show in EditPr
[
https://issues.apache.org/jira/browse/OFBIZ-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729142#action_12729142
]
Ashish Vijaywargiya commented on OFBIZ-2706:
Thanks Arpit, Rishi!
Done at r7924
[
https://issues.apache.org/jira/browse/OFBIZ-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arpit Singh Pandya updated OFBIZ-2706:
--
Attachment: ApInvoices_OFBiz-2706.patch
Added Functionality to show form based on Actio
Well,
a credit memo is the right way of doing it if the company is giving
back some money to the customer (a payment was really received
etc...); the process we are working on should address the situation
where a user, by error, applied a payment to a wrong (never issued to
customers) inv
Thanks David for the pointer.
Somehow I forgot this feature.
--
Ashish
On Wed, Jul 8, 2009 at 8:12 PM, David E. Jones wrote:
>
> The approach I've always used was to put the data in the sequence value
> entity itself, and then you have granular control over each
> entity/sequence too. When migr
44 matches
Mail list logo
