[jira] [Updated] (OFBIZ-9592) Order Item "Remaining" duplicates "Outstanding"
[ https://issues.apache.org/jira/browse/OFBIZ-9592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-9592: -- Description: In the quantities relating to order items, there are two numbers presented: "remaining" and "outstanding". The calculations for these two numbers are identical. Compare [https://github.com/apache/ofbiz-framework/blame/trunk/applications/order/template/order/OrderItems.ftl#L250] for a purchase order item (and two lines below for a sales order item) with [https://github.com/apache/ofbiz-framework/blame/trunk/applications/order/template/order/OrderItems.ftl#L302] for a purchases order item (and two lines below for a sales order item) The only difference I can see between the Remaining and Outstanding numbers is the extra test the second time to force the outstanding number to zero for a status of ITEM_COMPLETED. -As the comment says, some goods won't need a- -shipment. In that case, it seems confusing and ridiculous to say some items- -are "remaining" but none are "outstanding". In other words, the calculation- -for outstanding is slightly better.- -I propose we should remove "remaining".- I have worked out why there are two different numbers: the original intent was that Remaining is the quantity after any cancellations, so in the common situation where there have been no cancellations, Remaining should be the same as the original quantity ordered. A bug was introduced in a commit a long time ago, where "Remaining" was changed so it replicates "Outstanding". was: In the quantities relating to order items, there are two numbers presented: "remaining" and "outstanding". The calculations for these two numbers are identical. Compare https://github.com/apache/ofbiz-framework/blame/trunk/applications/order/template/order/OrderItems.ftl#L250 for a purchase order item (and two lines below for a sales order item) with https://github.com/apache/ofbiz-framework/blame/trunk/applications/order/template/order/OrderItems.ftl#L302 for a purchases order item (and two lines below for a sales order item) The only difference I can see between the Remaining and Outstanding numbers is the extra test the second time to force the outstanding number to zero for a status of ITEM_COMPLETED. As the comment says, some goods won't need a shipment. In that case, it seems confusing and ridiculous to say some items are "remaining" but none are "outstanding". In other words, the calculation for outstanding is slightly better. I propose we should remove "remaining". > Order Item "Remaining" duplicates "Outstanding" > > > Key: OFBIZ-9592 > URL: https://issues.apache.org/jira/browse/OFBIZ-9592 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: Trunk, Upcoming Branch >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Major > Labels: order, order_item > > In the quantities relating to order items, there are two numbers presented: > "remaining" and "outstanding". The calculations for these two numbers are > identical. > Compare > [https://github.com/apache/ofbiz-framework/blame/trunk/applications/order/template/order/OrderItems.ftl#L250] > for a purchase order item (and two lines below for a sales order item) > with > [https://github.com/apache/ofbiz-framework/blame/trunk/applications/order/template/order/OrderItems.ftl#L302] > for a purchases order item (and two lines below for a sales order item) > The only difference I can see between the Remaining and Outstanding numbers > is the extra test the second time to force the outstanding number to zero for > a > status of ITEM_COMPLETED. -As the comment says, some goods won't need a- > -shipment. In that case, it seems confusing and ridiculous to say some items- > -are "remaining" but none are "outstanding". In other words, the calculation- > -for outstanding is slightly better.- > -I propose we should remove "remaining".- > I have worked out why there are two different numbers: the original intent > was that Remaining is the quantity after any cancellations, so in the common > situation where there have been no cancellations, Remaining should be the > same as the original quantity ordered. > A bug was introduced in a commit a long time ago, where "Remaining" was > changed so it replicates "Outstanding". > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OFBIZ-12771) Confusing steps to create multiple transactions
[ https://issues.apache.org/jira/browse/OFBIZ-12771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Watford closed OFBIZ-12771. -- Fix Version/s: 22.01.01 Resolution: Fixed > Confusing steps to create multiple transactions > --- > > Key: OFBIZ-12771 > URL: https://issues.apache.org/jira/browse/OFBIZ-12771 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01 >Reporter: Daniel Watford >Assignee: Daniel Watford >Priority: Minor > Fix For: 22.01.01 > > Attachments: image-2023-03-07-14-38-39-731.png, > image-2023-03-07-14-39-48-134.png > > > OFBIZ-12447 removed the _Create an Accounting Transaction_ button from the > Accounting Transactions screens. > Compare the same screen on version 18 vs version 22: > [https://demo-stable.ofbiz.apache.org/accounting/control/FindAcctgTrans?organizationPartyId=Company] > [https://demo-next.ofbiz.apache.org/accounting/control/FindAcctgTrans?organizationPartyId=Company] > > !image-2023-03-07-14-38-39-731.png|width=512,height=247! > > !image-2023-03-07-14-39-48-134.png|width=464,height=239! > The button to create a GL Transaction has instead been made available in menu > MainActionMenu (AccountingMenus.xml). > To create a regular transaction (i.e. non-quick transaction) the user must > navigate to any of the Accounting application's screens via the app > navigation bar EXCEPT for the _Organization GL Settings_ screen. However, > clicking the _Create a Gl Transaction_ button in the menu will navigate the > user to the Organisation GL Settings screen (sub-application?). > The user can create their GL Transaction without issue. But if they then wish > to enter a second transaction, they must navigate away from the Organisation > GL Settings screen so they can once again click on the _Create a Gl > Transaction_ button. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12774) GL Transactions should default isPosted to 'N'
[
https://issues.apache.org/jira/browse/OFBIZ-12774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698500#comment-17698500
]
Daniel Watford commented on OFBIZ-12774:
Between version 18 and 22 there was a change to the createAcctgTrans service
definition:
release18.12
{quote}{{ }}
{{ Create a AcctgTrans record. isPosted is forced to
"N"}}
{{ }}
{{ }}
{{ }}
{{ }}
{quote}
release22.01
{quote}
Create a AcctgTrans record. isPosted is forced to
"N"
{quote}
It looks like using the override with a default-value attribute is not enough
to force isPosted to 'N', per the description of the service. Since the
decision to set isPosted to 'N' is a form of business logic, this service
should be implemented as code where isPosted can be clamped to 'N'.
An alternative approach might be to look at the override functionality to see
if we can force a value change.
> GL Transactions should default isPosted to 'N'
> --
>
> Key: OFBIZ-12774
> URL: https://issues.apache.org/jira/browse/OFBIZ-12774
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
>Affects Versions: 22.01.01
>Reporter: Daniel Watford
>Priority: Minor
> Fix For: 22.01.01
>
>
> There appears to be a change in behaviour between 18.12 and 22.01 for the
> default value of isPosted when creating a GL Transaction.
>
> In 18.12 this field defaults to 'N'.
> In 22.01 this field defaults to blank.
>
> Code appears to expect this field to either contain 'Y' or 'N' and uses this
> to determine whether the transaction is editable or read-only, and whether
> buttons, such as the "Post Transaction" button defined in
> AccountingMenu.xml#EditGlAcctTransSubTabBar are displayed.
>
> As an example, if a transaction is created with a blank isPosted value,
> screen GlScreens.xml#EditAcctgTrans will consider the transaction as NOT
> POSTED (since acctgTrans.isPosted is not equal to 'Y') and will therefore
> display an edit form for the transaction.
> However, AccountingMenu.xml#EditGlAcctTransSubTabBar will consider the
> transaction as POSTED (since acctgTrans.isPosted is not equal to 'N') and
> will therefore prevent display of the Post Transaction button.
> In this case the user can edit the transaction, but cannot click the button
> to post the transaction.
> Further, in the EditTransaction screen, the select box for isPosted does not
> permit blank values so, by default, the first value - 'Y' - is displayed.
> Leading the user to erroneously believe the transaction is posted.
>
> To resolve this issue, release18.12 behaviour should be reinstated and GL
> Transactions should default to have isPosted set to 'N' and blank values
> should not be permitted.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OFBIZ-12774) GL Transactions should default isPosted to 'N'
Daniel Watford created OFBIZ-12774: -- Summary: GL Transactions should default isPosted to 'N' Key: OFBIZ-12774 URL: https://issues.apache.org/jira/browse/OFBIZ-12774 Project: OFBiz Issue Type: Bug Components: accounting Affects Versions: 22.01.01 Reporter: Daniel Watford Fix For: 22.01.01 There appears to be a change in behaviour between 18.12 and 22.01 for the default value of isPosted when creating a GL Transaction. In 18.12 this field defaults to 'N'. In 22.01 this field defaults to blank. Code appears to expect this field to either contain 'Y' or 'N' and uses this to determine whether the transaction is editable or read-only, and whether buttons, such as the "Post Transaction" button defined in AccountingMenu.xml#EditGlAcctTransSubTabBar are displayed. As an example, if a transaction is created with a blank isPosted value, screen GlScreens.xml#EditAcctgTrans will consider the transaction as NOT POSTED (since acctgTrans.isPosted is not equal to 'Y') and will therefore display an edit form for the transaction. However, AccountingMenu.xml#EditGlAcctTransSubTabBar will consider the transaction as POSTED (since acctgTrans.isPosted is not equal to 'N') and will therefore prevent display of the Post Transaction button. In this case the user can edit the transaction, but cannot click the button to post the transaction. Further, in the EditTransaction screen, the select box for isPosted does not permit blank values so, by default, the first value - 'Y' - is displayed. Leading the user to erroneously believe the transaction is posted. To resolve this issue, release18.12 behaviour should be reinstated and GL Transactions should default to have isPosted set to 'N' and blank values should not be permitted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12771) Confusing steps to create multiple transactions
[ https://issues.apache.org/jira/browse/OFBIZ-12771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698416#comment-17698416 ] ASF subversion and git services commented on OFBIZ-12771: - Commit 7f352a5c31eb6b5eef172c9d63f35814ef1b3c45 in ofbiz-framework's branch refs/heads/release22.01 from Daniel Watford [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=7f352a5c31 ] Fixed: Added accounting main action menu to Organization GL Settings screens (OFBIZ-12771) Clicking on the Create a Gl Transactions button navigates to a screen within the Organisation GL Settings group of screens. Within this context the main actions menu - which included the Create button - is not visible, meaning it is cumbersome for the user to add another transaction. This commit adds the main actions menu to the Organization GL Settings screens, matching the way the actions are displayed in all other Accountancy screens. (cherry picked from commit 18cf371e1b55f093228b64bef361e946b4635ca8) > Confusing steps to create multiple transactions > --- > > Key: OFBIZ-12771 > URL: https://issues.apache.org/jira/browse/OFBIZ-12771 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01 >Reporter: Daniel Watford >Assignee: Daniel Watford >Priority: Minor > Attachments: image-2023-03-07-14-38-39-731.png, > image-2023-03-07-14-39-48-134.png > > > OFBIZ-12447 removed the _Create an Accounting Transaction_ button from the > Accounting Transactions screens. > Compare the same screen on version 18 vs version 22: > [https://demo-stable.ofbiz.apache.org/accounting/control/FindAcctgTrans?organizationPartyId=Company] > [https://demo-next.ofbiz.apache.org/accounting/control/FindAcctgTrans?organizationPartyId=Company] > > !image-2023-03-07-14-38-39-731.png|width=512,height=247! > > !image-2023-03-07-14-39-48-134.png|width=464,height=239! > The button to create a GL Transaction has instead been made available in menu > MainActionMenu (AccountingMenus.xml). > To create a regular transaction (i.e. non-quick transaction) the user must > navigate to any of the Accounting application's screens via the app > navigation bar EXCEPT for the _Organization GL Settings_ screen. However, > clicking the _Create a Gl Transaction_ button in the menu will navigate the > user to the Organisation GL Settings screen (sub-application?). > The user can create their GL Transaction without issue. But if they then wish > to enter a second transaction, they must navigate away from the Organisation > GL Settings screen so they can once again click on the _Create a Gl > Transaction_ button. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12771) Confusing steps to create multiple transactions
[ https://issues.apache.org/jira/browse/OFBIZ-12771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698413#comment-17698413 ] ASF subversion and git services commented on OFBIZ-12771: - Commit 18cf371e1b55f093228b64bef361e946b4635ca8 in ofbiz-framework's branch refs/heads/trunk from Daniel Watford [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=18cf371e1b ] Fixed: Added accounting main action menu to Organization GL Settings screens (OFBIZ-12771) Clicking on the Create a Gl Transactions button navigates to a screen within the Organisation GL Settings group of screens. Within this context the main actions menu - which included the Create button - is not visible, meaning it is cumbersome for the user to add another transaction. This commit adds the main actions menu to the Organization GL Settings screens, matching the way the actions are displayed in all other Accountancy screens. > Confusing steps to create multiple transactions > --- > > Key: OFBIZ-12771 > URL: https://issues.apache.org/jira/browse/OFBIZ-12771 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01 >Reporter: Daniel Watford >Assignee: Daniel Watford >Priority: Minor > Attachments: image-2023-03-07-14-38-39-731.png, > image-2023-03-07-14-39-48-134.png > > > OFBIZ-12447 removed the _Create an Accounting Transaction_ button from the > Accounting Transactions screens. > Compare the same screen on version 18 vs version 22: > [https://demo-stable.ofbiz.apache.org/accounting/control/FindAcctgTrans?organizationPartyId=Company] > [https://demo-next.ofbiz.apache.org/accounting/control/FindAcctgTrans?organizationPartyId=Company] > > !image-2023-03-07-14-38-39-731.png|width=512,height=247! > > !image-2023-03-07-14-39-48-134.png|width=464,height=239! > The button to create a GL Transaction has instead been made available in menu > MainActionMenu (AccountingMenus.xml). > To create a regular transaction (i.e. non-quick transaction) the user must > navigate to any of the Accounting application's screens via the app > navigation bar EXCEPT for the _Organization GL Settings_ screen. However, > clicking the _Create a Gl Transaction_ button in the menu will navigate the > user to the Organisation GL Settings screen (sub-application?). > The user can create their GL Transaction without issue. But if they then wish > to enter a second transaction, they must navigate away from the Organisation > GL Settings screen so they can once again click on the _Create a Gl > Transaction_ button. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [ofbiz-framework] danwatford merged pull request #601: Fixed: Added accounting main action menu to Organization GL Settings screens (OFBIZ-12771)
danwatford merged PR #601: URL: https://github.com/apache/ofbiz-framework/pull/601 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@ofbiz.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (OFBIZ-12773) Async Service with multiple tenants - tenant null
Ingo Wolfmayr created OFBIZ-12773:
-
Summary: Async Service with multiple tenants - tenant null
Key: OFBIZ-12773
URL: https://issues.apache.org/jira/browse/OFBIZ-12773
Project: OFBiz
Issue Type: Improvement
Affects Versions: Upcoming Branch
Reporter: Ingo Wolfmayr
Attachments: testsettings.patch
{*}System{*}: clean ofbiz trunk, Java 17
{*}Tenants{*}: demo, zdemo - both with demo data
DB: derby (issue not db related - same issue with mysq)
{code:java}
./gradlew createTenant -PtenantId=zdemo
./gradlew createTenant -PtenantId=demo
./gradlew loadTenant -PtenantId=demo -PtenantReaders=seed,seed-initial,demo
./gradlew loadTenant -PtenantId=zdemo -PtenantReaders=seed,seed-initial,demo
./gradlew ofbiz{code}
Attached is a "patch" with the service for testing and the tenant settings in
entityengine.xml.
I use two different browsers to login to both tenants.
*Tenant demo:*
Then goto "webtools" --> "service engine" -->"run service": enter testx -->
submit
Result: ofbiz will run the first 100 jobs (100 jobs defined in
serviceengine.xml). After some seconds will run the final 100 jobs. All jobs
will print the tenantId.
{code:java}
DISPATCHER:13 -
org.apache.ofbiz.service.GenericDispatcherFactory$GenericDispatcher@38b821e9
TENANT:13 - demo
DISPATCHER:195 -
org.apache.ofbiz.service.GenericDispatcherFactory$GenericDispatcher@38b821e9
TENANT:195 - demo{code}
*Tenant xdemo:*
Then goto "webtools" --> "service engine" -->"run service": enter testx -->
submit
Result: ofbiz will run through all 200 jobs (100 jobs defined in
serviceengine.xml). Only 100 jobs will print the tenantId.
{code:java}
DISPATCHER:13 -
org.apache.ofbiz.service.GenericDispatcherFactory$GenericDispatcher@495392e0
TENANT:13 - null
DISPATCHER:195 -
org.apache.ofbiz.service.GenericDispatcherFactory$GenericDispatcher@44fe81d9
TENANT:195 - zdemo{code}
It seems the the last tenant (zdemo) has a problem.
*The problem with this:* everything run in this jobs that require tenant
specific logic will fail.
I would appreciate every thought on this as I am a little bit clueless right
now (after hours and hours of debugging why my jobs fail ;)).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OFBIZ-10287) gradlew --no-daemon "ofbiz --shutdown" does not work
[
https://issues.apache.org/jira/browse/OFBIZ-10287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698250#comment-17698250
]
Daniel Watford commented on OFBIZ-10287:
I haven't noticed any problems with demo-trunk over the last two nightly resets.
Anyone else spotted any problems following the recent switch back to using
'ofbiz --shutdown'?
> gradlew --no-daemon "ofbiz --shutdown" does not work
> -
>
> Key: OFBIZ-10287
> URL: https://issues.apache.org/jira/browse/OFBIZ-10287
> Project: OFBiz
> Issue Type: Bug
>Reporter: Jacques Le Roux
>Priority: Major
>
> When in production, if you use several OFBiz instances on your server, to
> stop them safely you need to use {{./gradlew --no-daemon terminateOfbiz}}
> which actually kills all OFBiz instances using "kill -9"
> {{./gradlew --no-daemon "ofbiz --shutdown"}} does not work, at least on demos
> VM where there is 3 instances. So if you use it you get an unstable situation
> and have to use "kill -9" manually.
> You always can use "terminateOfbiz", but it means that you have to restart
> all OFBiz instances. So it's easier to do that with {{all-manual-nicely.sh}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
