[jira] [Created] (OFBIZ-9677) Backorder reservations used in packing

2017-09-05 Thread Paul Foxworthy (JIRA)
Paul Foxworthy created OFBIZ-9677:
-

 Summary: Backorder reservations used in packing
 Key: OFBIZ-9677
 URL: https://issues.apache.org/jira/browse/OFBIZ-9677
 Project: OFBiz
  Issue Type: Bug
  Components: product
Affects Versions: Trunk
Reporter: Paul Foxworthy
Assignee: Paul Foxworthy


During packing, OFBiz looks for reservations (OrderItemShipGrpInvRes) for the 
order item. Some reserevations are for back ordered items not on hand. These 
reservations should not be used during packing, but they are.

The attached patch fixes this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (OFBIZ-9592) Order Item "Remaining" duplicates "Outstanding"

2017-08-17 Thread Paul Foxworthy (JIRA)
Paul Foxworthy created OFBIZ-9592:
-

 Summary: 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
Reporter: Paul Foxworthy
Assignee: Paul Foxworthy


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".



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-08-02 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16111856#comment-16111856
 ] 

Paul Foxworthy commented on OFBIZ-6330:
---

Hi Moatasim,

What is the status of the special party?

If it's a second organization you administer, you need to create details for it 
in more places, not just in TaxAuthorityGlAccounts. You may need a 
ProductStore, and you should use OrganizationGlAccount to create a separate 
chart of GL accounts for that organization. See 
https://cwiki.apache.org/confluence/display/OFBENDUSER/Apache+OFBiz+Business+Setup+Guide
 for a discussion of things to configure.

If it's a customer, supplier or some other party you interact with and for 
which you want separate GL accounts, use PartyGlAccount.

They key partyId is the one on the transaction: in which organization's 
accounts do we want the transaction to appear? The partyIds on transaction 
entries are more descriptive: to which party was money or other resources 
transferred?

I think this is separate from OFBIZ-6330. Can we continue this discussion on 
the ofbiz-user mailing list?

Cheers

Paul Foxworthy 

> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
>  Labels: tax, vat
> Attachments: GeneralLedgerServices.patch, GL.PNG, JORTAXAUTH.PNG, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns-alternative.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, pic01.PNG, pic02.png
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
> {code}
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> {code}
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
> {code}
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> {code}
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (OFBIZ-9492) Tax Authorities need two GL accounts for sales and purchases

2017-08-02 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16111772#comment-16111772
 ] 

Paul Foxworthy commented on OFBIZ-9492:
---

Hi [~pierre smits],

I see your point. I'm still curious what the reasoning was behind the 
suggestion/advice/deprecation to use an accounting transaction type of plain 
"SALES" instead of the three more specific things. AcctgTransType has 
parent-child relationships, so it would be possible to introduce SALES as a 
parent without removing the three.

Cheers

Paul

> Tax Authorities need two GL accounts for sales and purchases
> 
>
> Key: OFBIZ-9492
> URL: https://issues.apache.org/jira/browse/OFBIZ-9492
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>  Labels: accounting, vat
>
> In jurisdictions with Value Added Tax, you need to track tax you have paid on 
> purchases, and tax you have collected with sales. When you report to a tax 
> authority, you pay them the difference between the two, i.e. you pay tax on 
> the value added, not on your inputs.
> OFBiz has an entity, TaxAuthorityGlAccount (TAGLA), which currently assumes 
> the GL account is for a sale.
> We need to extend OFBiz so it is possible to find two GL accounts for a tax 
> authority, one for sales and one for purchases.
> I propose:
> - Define a new Enumeration for the direction of a transaction. I suggest
> calling the Enumeration TAGLADIR, with two values TAGLADIR_INCOMING
> and TAGLADIR_OUTGOING.
> We could reuse an existing indication of the direction of a transaction,
> for example the GlAccountClassIds INCOME and EXPENSE. However, when we receive
> income from a sale, we would incur a tax *liability*, and the GL account for 
> that
> would be a liability account. So I think it would be less confusing to have a
> separate enum here that's just for TAGLA.
> - add a new attribute to the TaxAuthorityGlAccount entity for the direction 
> of the transaction.
> The new attribute should be included in the primary key.
> - Add a new service in TaxAuthorityServices named getTaxAuthorityGlAccountId 
> which
> looks up a TAGLA given primary key values, including the direction
> - There are two places in TaxAuthorityServices that would call 
> getTaxAuthorityGlAccountId: getTaxAdjustments and getItemTaxAdjustments, one 
> for orders, and the other for invoice item types. The direction can be 
> inferred from the order type or the invoice item type
> - createAcctgTransForPurchaseInvoice and 
> createAcctgTransForCustomerReturnInvoice
> should use getTaxAuthorityGlAccountId
> - createAcctgTransactionForSalesInvoice should be rewritten to use 
> getTaxAuthorityGlAccountId.
> I am working on a patch to do this, but I'd like your thoughts on my proposal



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Resolved] (OFBIZ-5936) Invoice transactions for purchase order sale tax not supported

2017-07-30 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy resolved OFBIZ-5936.
---
Resolution: Duplicate

> Invoice transactions for purchase order sale tax not supported
> --
>
> Key: OFBIZ-5936
> URL: https://issues.apache.org/jira/browse/OFBIZ-5936
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Christian Carlow
> Attachments: MissingTaxEntry.pdf, TransacationNotGettingPosted.pdf
>
>
> Invoice transactions for sales tax adjustments manually added to purchase 
> orders are not supported leading to an error when attempting to change the 
> invoice status to "Ready for Posting".  
> GeneralLedgerServices.xml#createAcctgTransForPurchaseInvoice does not include 
> logic to set the glAccountTypeId for purchase invoices for item type 
> PITM_SALES_TAX.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (OFBIZ-9492) Tax Authorities need two GL accounts for sales and purchases

2017-07-30 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106479#comment-16106479
 ] 

Paul Foxworthy commented on OFBIZ-9492:
---

Hi [~deepak.nigam], [~jacopoc], [~pfm.smits]

Jacopo did some cleaning up of the accounting transaction types in 2007 
(https://github.com/apache/ofbiz/commit/4d8ab57b0173a98e82c23268708c0c9f4247c3a7)

I see in /applications/accounting/data/AccountingTypeData.xml that 
AcctgTransType values of SALES_INVOICE, PURCHASE_INVOICE and CUST_RTN_INVOICE 
have a comment saying they should be replaced with "SALES". I presume the 
thinking is that exactly the same set of information is a purchase invoice from 
the perspective of the buyer, and a sales invoice from the perspective of the 
seller. If the two parties are both using OFBiz, it could even be exactly the 
same entity.

I was considering using these three values in the revision of the 
TaxAuthorityGlAccount entity. Now I wonder the relationship should be to 
InvoiceType instead. There are other situations where we may incur and pay a 
tax obligation beyond when we raise and receive invoices, such as income tax. 
However, in those situations you would just directly set the GL accounts for  a 
payment. Does anyone see a problem with using InvoiceType?

Cheers

Paul





> Tax Authorities need two GL accounts for sales and purchases
> 
>
> Key: OFBIZ-9492
> URL: https://issues.apache.org/jira/browse/OFBIZ-9492
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>  Labels: accounting, vat
>
> In jurisdictions with Value Added Tax, you need to track tax you have paid on 
> purchases, and tax you have collected with sales. When you report to a tax 
> authority, you pay them the difference between the two, i.e. you pay tax on 
> the value added, not on your inputs.
> OFBiz has an entity, TaxAuthorityGlAccount (TAGLA), which currently assumes 
> the GL account is for a sale.
> We need to extend OFBiz so it is possible to find two GL accounts for a tax 
> authority, one for sales and one for purchases.
> I propose:
> - Define a new Enumeration for the direction of a transaction. I suggest
> calling the Enumeration TAGLADIR, with two values TAGLADIR_INCOMING
> and TAGLADIR_OUTGOING.
> We could reuse an existing indication of the direction of a transaction,
> for example the GlAccountClassIds INCOME and EXPENSE. However, when we receive
> income from a sale, we would incur a tax *liability*, and the GL account for 
> that
> would be a liability account. So I think it would be less confusing to have a
> separate enum here that's just for TAGLA.
> - add a new attribute to the TaxAuthorityGlAccount entity for the direction 
> of the transaction.
> The new attribute should be included in the primary key.
> - Add a new service in TaxAuthorityServices named getTaxAuthorityGlAccountId 
> which
> looks up a TAGLA given primary key values, including the direction
> - There are two places in TaxAuthorityServices that would call 
> getTaxAuthorityGlAccountId: getTaxAdjustments and getItemTaxAdjustments, one 
> for orders, and the other for invoice item types. The direction can be 
> inferred from the order type or the invoice item type
> - createAcctgTransForPurchaseInvoice and 
> createAcctgTransForCustomerReturnInvoice
> should use getTaxAuthorityGlAccountId
> - createAcctgTransactionForSalesInvoice should be rewritten to use 
> getTaxAuthorityGlAccountId.
> I am working on a patch to do this, but I'd like your thoughts on my proposal



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-07-30 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106447#comment-16106447
 ] 

Paul Foxworthy commented on OFBIZ-6330:
---

Hi again,

The reason there's no GL Account for the tax-related entry or entries is 
OFBIZ-9492. I'm inclined to commit this issue as-is. The work to obtain the 
right GL account for taxes on purchases can continue in OFBIZ-9492.

Cheers

Paul

> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
>  Labels: tax, vat
> Attachments: GeneralLedgerServices.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns-alternative.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, pic01.PNG, pic02.png
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
> {code}
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> {code}
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
> {code}
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> {code}
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-07-30 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106349#comment-16106349
 ] 

Paul Foxworthy commented on OFBIZ-6330:
---

Hi all,

If you apply the OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch and 
run the above test script, the GL entries now balance - in other words the 
accounts payable amount is tax-inclusive. However the sales tax entry does not 
have a GL Account Type or Account Code. I will look into that now.

Cheers

Paul

> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
>  Labels: tax, vat
> Attachments: GeneralLedgerServices.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns-alternative.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, pic01.PNG, pic02.png
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
> {code}
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> {code}
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
> {code}
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> {code}
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-07-30 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106339#comment-16106339
 ] 

Paul Foxworthy edited comment on OFBIZ-6330 at 7/30/17 6:03 AM:


Hi all,

I now have a script to demonstrate this on the demo site.

_Add a supplier for service product SV-1000._

Catalog
Edit Product With Product ID: SV-1000 
https://demo-trunk.ofbiz.apache.org/catalog/control/EditProduct?productId=SV-1000

click on Suppliers

In Add Product Supplier, enter Last Price of 100 and Supplier Product Id of 
SV-1000. Click Create

_Enter an order of the service product_

Order-Order Entry 
(https://demo-trunk.ofbiz.apache.org/ordermgr/control/orderentry)

Select Supplier of Acct Big Supplier, click Continue on Purchase Order screenlet
Click Continue again
Choose Product SV-1000
Click Finalize Order
Click Continue multiple times, then Create Order
Click Approve Order

_Because this is a service, no shipment is necessary. Order status will be set 
to Completed, and an purchase invoice will be created. If you do this with the 
initial demo data, the invoice will have an ID of 1._

Click on link from Order to Invoice
Click on "Status To Ready"

_In Transactions, the GL entries don't balance. The item and tax are there, but 
the accounts payable amount should be $101, not $100._
_The GL entries have been added to the suspense journal because they don't 
balance._



was (Author: paul_foxworthy):
Hi all,

I now have a script to demonstrate this on the demo site.

_Add a supplier for service product SV-1000._

Catalog
Edit Product With Product ID: SV-1000 
https://demo-trunk.ofbiz.apache.org/catalog/control/EditProduct?productId=SV-1000

click on Suppliers

In Add Product Supplier, enter Last Price of 100 and Supplier Product Id of 
SV-1000. Click Create

_Enter an order of the service product_

Order-Order Entry 
(https://demo-trunk.ofbiz.apache.org/ordermgr/control/orderentry)

Select Supplier of Acct Big Supplier, click Continue on Purchase Order screenlet
Click Continue again
Choose Product SV-1000
Click Finalize Order
Click Continue multiple times, then Create Order
Click Approve Order

_Because this is a service, no shipment is necessary. Order status will be set 
to Completed, and an purchase invoice will be created. If you do this with the 
initial demo data, the invoice will have an ID of 1.

Click on link from Order to Invoice
Click on "Status To Ready"

_In Transactions, the GL entries don't balance. The item and tax are there, but 
the accounts payable amount should be $101, not $100._
_The GL entries have been added to the suspense journal because they don't 
balance._


> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
>  Labels: tax, vat
> Attachments: GeneralLedgerServices.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns-alternative.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, pic01.PNG, pic02.png
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
> {code}
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> {code}
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
> {code}
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> {code}
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-07-30 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106339#comment-16106339
 ] 

Paul Foxworthy commented on OFBIZ-6330:
---

Hi all,

I now have a script to demonstrate this on the demo site.

_Add a supplier for service product SV-1000._

Catalog
Edit Product With Product ID: SV-1000 
https://demo-trunk.ofbiz.apache.org/catalog/control/EditProduct?productId=SV-1000

click on Suppliers

In Add Product Supplier, enter Last Price of 100 and Supplier Product Id of 
SV-1. Click Create

_Enter an order of the service product_

Order-Order Entry 
(https://demo-trunk.ofbiz.apache.org/ordermgr/control/orderentry)

Select Supplier of Acct Big Supplier, click Continue on Purchase Order screenlet
Click Continue again
Choose Product SV-1000
Click Finalize Order
Click Continue multiple times, then Create Order
Click Approve Order

_Because this is a service, no shipment is necessary. Order status will be set 
to Completed, and an purchase invoice will be created. If you do this with the 
initial demo data, the invoice will have an ID of 1.

Click on link from Order to Invoice
Click on "Status To Ready"

_In Transactions, the GL entries don't balance. The item and tax are there, but 
the accounts payable amount should be $101, not $100._
_The GL entries have been added to the suspense journal because they don't 
balance._


> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
>  Labels: tax, vat
> Attachments: GeneralLedgerServices.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns-alternative.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, pic01.PNG, pic02.png
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
> {code}
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> {code}
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
> {code}
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> {code}
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-07-30 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106339#comment-16106339
 ] 

Paul Foxworthy edited comment on OFBIZ-6330 at 7/30/17 6:02 AM:


Hi all,

I now have a script to demonstrate this on the demo site.

_Add a supplier for service product SV-1000._

Catalog
Edit Product With Product ID: SV-1000 
https://demo-trunk.ofbiz.apache.org/catalog/control/EditProduct?productId=SV-1000

click on Suppliers

In Add Product Supplier, enter Last Price of 100 and Supplier Product Id of 
SV-1000. Click Create

_Enter an order of the service product_

Order-Order Entry 
(https://demo-trunk.ofbiz.apache.org/ordermgr/control/orderentry)

Select Supplier of Acct Big Supplier, click Continue on Purchase Order screenlet
Click Continue again
Choose Product SV-1000
Click Finalize Order
Click Continue multiple times, then Create Order
Click Approve Order

_Because this is a service, no shipment is necessary. Order status will be set 
to Completed, and an purchase invoice will be created. If you do this with the 
initial demo data, the invoice will have an ID of 1.

Click on link from Order to Invoice
Click on "Status To Ready"

_In Transactions, the GL entries don't balance. The item and tax are there, but 
the accounts payable amount should be $101, not $100._
_The GL entries have been added to the suspense journal because they don't 
balance._



was (Author: paul_foxworthy):
Hi all,

I now have a script to demonstrate this on the demo site.

_Add a supplier for service product SV-1000._

Catalog
Edit Product With Product ID: SV-1000 
https://demo-trunk.ofbiz.apache.org/catalog/control/EditProduct?productId=SV-1000

click on Suppliers

In Add Product Supplier, enter Last Price of 100 and Supplier Product Id of 
SV-1. Click Create

_Enter an order of the service product_

Order-Order Entry 
(https://demo-trunk.ofbiz.apache.org/ordermgr/control/orderentry)

Select Supplier of Acct Big Supplier, click Continue on Purchase Order screenlet
Click Continue again
Choose Product SV-1000
Click Finalize Order
Click Continue multiple times, then Create Order
Click Approve Order

_Because this is a service, no shipment is necessary. Order status will be set 
to Completed, and an purchase invoice will be created. If you do this with the 
initial demo data, the invoice will have an ID of 1.

Click on link from Order to Invoice
Click on "Status To Ready"

_In Transactions, the GL entries don't balance. The item and tax are there, but 
the accounts payable amount should be $101, not $100._
_The GL entries have been added to the suspense journal because they don't 
balance._


> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
>  Labels: tax, vat
> Attachments: GeneralLedgerServices.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns-alternative.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, pic01.PNG, pic02.png
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
> {code}
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> {code}
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
> {code}
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> {code}
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (OFBIZ-5403) Implement separate glAccounts per TaxAuthority-ProductCategory combination

2017-07-20 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-5403:
--
Labels: accounting tax transactions  (was: Tax, accounting transactions)

> Implement separate glAccounts per TaxAuthority-ProductCategory combination
> --
>
> Key: OFBIZ-5403
> URL: https://issues.apache.org/jira/browse/OFBIZ-5403
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>  Labels: accounting, tax, transactions
>
> In current setup only 1 glAccount can be defined for each combination of 
> TaxGeo, TaxAuthority and Internal Organization.
> However, it is common that multiple tax rates exist per TaxGeo (e.g. VAT 
> rates of 0, 6 and 21% for The Netherlands) and it also customary to report 
> separately for sales and purchasing per tax rate and audit registered tax 
> bookings vs sales and purchases per period.
> As such implementing a glAccount per 
> TaxGeo-TaxAuth-IntOrganisation-ProductCategory, and upgrading applicable 
> transaction processing services would facilitate the above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (OFBIZ-7012) VAT tax are not recorded as separate line items in Invoice for products with VAT tax included in their price

2017-07-20 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-7012:
--
Labels: VAT tax  (was: )

> VAT tax are not recorded as separate line items in Invoice for products with 
> VAT tax included in their price
> 
>
> Key: OFBIZ-7012
> URL: https://issues.apache.org/jira/browse/OFBIZ-7012
> Project: OFBiz
>  Issue Type: New Feature
>  Components: accounting, order
>Reporter: Divesh Dutta
>Assignee: Divesh Dutta
>  Labels: VAT, tax
> Attachments: OFBIZ-7012.patch
>
>
> In countries like UK VAT system works. So in VAT system, VAT taxes are 
> included in product's price. So OFBiz have support of VAT tax where you can 
> include VAT in product's price itself. Here is the example data we create to 
> enable VAT calculations:
>  {code}
> 
>  
> 
>  
> 
>  
>  taxAuthGeoId="GBR" taxAuthPartyId="GB_TA"/>
>  
>  productStoreId="9000" taxAuthGeoId="GBR" taxAuthPartyId="GB_TA" 
> taxAuthorityRateTypeId="VAT_TAX" taxPercentage="20.00" />
>  productPricePurposeId="PURCHASE" productPriceTypeId="DEFAULT_PRICE" 
> productStoreGroupId="_NA_" taxAuthGeoId="GBR" taxAuthPartyId="GB_TA" 
> taxInPrice="Y" />
>  {code}
> When invoices are created, tax amount included in product's price is not 
> separated in new invoice line item. And when general ledger postings are 
> done, then tax amount is not posted in Liability account. So due to this 
> organizations have no way to figure out how much tax is to be paid to tax 
> authority. 
> Ideally, product's actual price (without VAT) should be recorded in revenue 
> account and tax should be recorded in liability account. 
> For doing this, when invoice is created, VAT amount should be separated and 
> created as new line item. 
> Recently we have worked for one of our client where we have fixed this issue 
> and enabled invoicing in OFBiz to record vat tax amount as separate line 
> items. [~lektran] has actively worked with us to finalize the solution design 
> and completing the implementation. [~ankush.upadhyay] is the developer who 
> worked on solution design. [~ankush.upadhyay] please provide the patch for 
> this issue. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (OFBIZ-9500) Maintain accountingQuantity for all COGS valuation methods

2017-07-19 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-9500:
--
Description: 
>From 
>http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html

*Why accounting quantity?*

When inventory is shipped, there's an accounting transaction that debits the 
inventory on hand value and credits Cost of Goods Sold (COGS). 

There's more than one way of deciding what value is added to COGS. 

First and most obvious is the actual cost of the inventory item. But companies 
may prefer other strategies. OFBiz has the option of three others: average 
cost, first-in-first-out or last-in-first-out. There's a nice survey of _why_ 
you might choose one of these at 
http://www.dummies.com/business/operations-management/choosing-an-accounting-method-for-the-cost-of-goods-sold-expense/,
 
http://www.dummies.com/business/accounting/the-fifo-method-for-cost-of-goods-sold/,
 
http://www.dummies.com/business/accounting/the-lifo-method-for-cost-of-goods-sold/
 

Note that if you choose anything other than inventory item cost, the money 
amount transferred to the COGS account may be *different* to the cost price of 
the inventory items being shipped. When you choose FIFO or LIFO, the amount may 
have originated from a different inventory item, received at a different time. 

*Current situation in OFBiz*

The cogsMethodId field in the PartyAcctgPreference entity is a enum with four 
possible values: COGS_INV_COST, COGS_AVG_COST,  COGS_FIFO, COGS_LIFO.. 

The accountingQuantity field in the InventoryItem entity and 
accountingQuantityDiff in the InventoryItemDetail entity track the quantity of 
an item still "live" for the purpose of inventory valuation and COGS. 

In the service createAcctgTransForShipmentReceipt implemented in 
/applications/accounting/minilang/ledger/GeneralLedgerServices.xml 
(http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1306)
 

the accountingQuantity is always set to the same value as the quantity received 
(i.e. the same as the quantityOnHand) for a newly received inventory item 
regardless of the COGS method. 

When items are shipped, the service createAcctgTransForSalesShipmentIssuance 
will only reduce the accounting quantity if the COGS method is FIFO or LIFO 
(http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1127).
 With FIFO, when an item is shipped, inventory items for the product with a 
non-zero accounting quantity are found sorted from earliest to latest received. 
The quantity of the item shipped must be decremented from the accounting 
quantities, starting with the earliest. Similarly, with LIFO, items are sorted 
from latest to earliest, and the latest item or items are 
decremented. 

In other words, if you have chosen a COGS method of COGS_INV_COST or 
COGS_AVG_COST, the accounting quantity is meaningless and in OFBiz as of 
now, should be ignored. 

And yet, the Inventory Valuation report uses accounting quantity, regardless of 
the the COGS method 
(http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/widget/ReportFinancialSummaryForms.xml?view=markup#l535).
 In other words, the Inventory Valuation report is broken for COGS methods of 
COGS_INV_COST or COGS_AVG_COST. 

*What should happen*

The Inventory Valuation report, and anybody else who cares, should always be 
able to trust the accounting quantity. For COGS_INV_COST and COGS_AVG_COST, 
maintaining the accounting quantity is simple - 
createAcctgTransForSalesShipmentIssuanceit should just adjust it to match the 
remaining quantity on hand.

No matter what the COGS method, the total accounting quantity for a product 
across all inventory items should always be equal to the total QOH. 

  was:
>From 
>http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html

*Why accounting quantity?*

When inventory is shipped, there's an accounting transaction that debits the 
inventory on hand value and credits Cost of Goods Sold (COGS). 

There's more than one way of deciding what value is added to COGS. 

First and most obvious is the actual cost of the inventory item. But companies 
may prefer other strategies. OFBiz has the option of three others: average 
cost, first-in-first-out or last-in-first-out. There's a nice survey of _why_ 
you might choose one of these at 
http://www.dummies.com/business/operations-management/choosing-an-accounting-method-for-the-cost-of-goods-sold-expense/,
 
http://www.dummies.com/business/accounting/the-fifo-method-for-cost-of-goods-sold/,
 
http://www.dummies.com/business/accounting/the-lifo-method-for-cost-of-goods-sold/
 

Note that if you choose anything other than inventory item cost, the money 
amount transferred to the COGS account 

[jira] [Updated] (OFBIZ-9500) Maintain accountingQuantity for all COGS valuation methods

2017-07-19 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-9500:
--
Description: 
>From 
>http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html

*Why accounting quantity?*

When inventory is shipped, there's an accounting transaction that debits the 
inventory on hand value and credits Cost of Goods Sold (COGS). 

There's more than one way of deciding what value is added to COGS. 

First and most obvious is the actual cost of the inventory item. But companies 
may prefer other strategies. OFBiz has the option of three others: average 
cost, first-in-first-out or last-in-first-out. There's a nice survey of _why_ 
you might choose one of these at 
http://www.dummies.com/business/operations-management/choosing-an-accounting-method-for-the-cost-of-goods-sold-expense/,
 
http://www.dummies.com/business/accounting/the-fifo-method-for-cost-of-goods-sold/,
 
http://www.dummies.com/business/accounting/the-lifo-method-for-cost-of-goods-sold/
 

Note that if you choose anything other than inventory item cost, the money 
amount transferred to the COGS account may be *different* to the cost price of 
the inventory items being shipped. When you choose FIFO or LIFO, the amount may 
have originated from a different inventory item, received at a different time. 

*Current situation in OFBiz *

The cogsMethodId field in the PartyAcctgPreference entity is a enum with four 
possible values: COGS_INV_COST, COGS_AVG_COST,  COGS_FIFO, COGS_LIFO.. 

The accountingQuantity field in the InventoryItem entity and 
accountingQuantityDiff in the InventoryItemDetail entity track the quantity of 
an item still "live" for the purpose of inventory valuation and COGS. 

In the service createAcctgTransForShipmentReceipt implemented in 
/applications/accounting/minilang/ledger/GeneralLedgerServices.xml 
(http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1306)
 

the accountingQuantity is always set to the same value as the quantity received 
(i.e. the same as the quantityOnHand) for a newly received inventory item 
regardless of the COGS method. 

When items are shipped, the service createAcctgTransForSalesShipmentIssuance 
will only reduce the accounting quantity if the COGS method is FIFO or LIFO 
(http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1127).
 With FIFO, when an item is shipped, inventory items for the product with a 
non-zero accounting quantity are found sorted from earliest to latest received. 
The quantity of the item shipped must be decremented from the accounting 
quantities, starting with the earliest. Similarly, with LIFO, items are sorted 
from latest to earliest, and the latest item or items are 
decremented. 

In other words, if you have chosen a COGS method of COGS_INV_COST or 
COGS_AVG_COST, the accounting quantity is meaningless and in OFBiz as of 
now, should be ignored. 

And yet, the Inventory Valuation report uses accounting quantity, regardless of 
the the COGS method 
(http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/widget/ReportFinancialSummaryForms.xml?view=markup#l535).
 In other words, the Inventory Valuation report is broken for COGS methods of 
COGS_INV_COST or COGS_AVG_COST. 

*What should happen*

The Inventory Valuation report, and anybody else who cares, should always be 
able to trust the accounting quantity. For COGS_INV_COST and COGS_AVG_COST, 
maintaining the accounting quantity is simple - 
createAcctgTransForSalesShipmentIssuanceit should just adjust it to match the 
remaining quantity on hand.

No matter what the COGS method, the total accounting quantity for a product 
across all inventory items should always be equal to the total QOH. 

  was:
>From 
>http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html

*Why accounting quantity? *

When inventory is shipped, there's an accounting transaction that debits the 
inventory on hand value and credits Cost of Goods Sold (COGS). 

There's more than one way of deciding what value is added to COGS. 

First and most obvious is the actual cost of the inventory item. But companies 
may prefer other strategies. OFBiz has the option of three others: average 
cost, first-in-first-out or last-in-first-out. There's a nice survey of _why_ 
you might choose one of these at 
http://www.dummies.com/business/operations-management/choosing-an-accounting-method-for-the-cost-of-goods-sold-expense/,
 
http://www.dummies.com/business/accounting/the-fifo-method-for-cost-of-goods-sold/,
 
http://www.dummies.com/business/accounting/the-lifo-method-for-cost-of-goods-sold/
 

Note that if you choose anything other than inventory item cost, the money 
amount transferred to the COGS 

[jira] [Updated] (OFBIZ-9500) Maintain accountingQuantity for all COGS valuation methods

2017-07-19 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-9500:
--
Description: 
>From 
>http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html

*Why accounting quantity? *

When inventory is shipped, there's an accounting transaction that debits the 
inventory on hand value and credits Cost of Goods Sold (COGS). 

There's more than one way of deciding what value is added to COGS. 

First and most obvious is the actual cost of the inventory item. But companies 
may prefer other strategies. OFBiz has the option of three others: average 
cost, first-in-first-out or last-in-first-out. There's a nice survey of _why_ 
you might choose one of these at 
http://www.dummies.com/business/operations-management/choosing-an-accounting-method-for-the-cost-of-goods-sold-expense/,
 
http://www.dummies.com/business/accounting/the-fifo-method-for-cost-of-goods-sold/,
 
http://www.dummies.com/business/accounting/the-lifo-method-for-cost-of-goods-sold/
 

Note that if you choose anything other than inventory item cost, the money 
amount transferred to the COGS account may be *different* to the cost price of 
the inventory items being shipped. When you choose FIFO or LIFO, the amount may 
have originated from a different inventory item, received at a different time. 

*Current situation in OFBiz *

The cogsMethodId field in the PartyAcctgPreference entity is a enum with four 
possible values: COGS_INV_COST, COGS_AVG_COST,  COGS_FIFO, COGS_LIFO.. 

The accountingQuantity field in the InventoryItem entity and 
accountingQuantityDiff in the InventoryItemDetail entity track the quantity of 
an item still "live" for the purpose of inventory valuation and COGS. 

In the service createAcctgTransForShipmentReceipt implemented in 
/applications/accounting/minilang/ledger/GeneralLedgerServices.xml 
(http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1306)
 

the accountingQuantity is always set to the same value as the quantity received 
(i.e. the same as the quantityOnHand) for a newly received inventory item 
regardless of the COGS method. 

When items are shipped, the service createAcctgTransForSalesShipmentIssuance 
will only reduce the accounting quantity if the COGS method is FIFO or LIFO 
(http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1127).
 With FIFO, when an item is shipped, inventory items for the product with a 
non-zero accounting quantity are found sorted from earliest to latest received. 
The quantity of the item shipped must be decremented from the accounting 
quantities, starting with the earliest. Similarly, with LIFO, items are sorted 
from latest to earliest, and the latest item or items are 
decremented. 

In other words, if you have chosen a COGS method of COGS_INV_COST or 
COGS_AVG_COST, the accounting quantity is meaningless and in OFBiz as of 
now, should be ignored. 

And yet, the Inventory Valuation report uses accounting quantity, regardless of 
the the COGS method 
(http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/widget/ReportFinancialSummaryForms.xml?view=markup#l535).
 In other words, the Inventory Valuation report is broken for COGS methods of 
COGS_INV_COST or COGS_AVG_COST. 

*What should happen*

The Inventory Valuation report, and anybody else who cares, should always be 
able to trust the accounting quantity. For COGS_INV_COST and COGS_AVG_COST, 
maintaining the accounting quantity is simple - 
createAcctgTransForSalesShipmentIssuanceit should just adjust it to match the 
remaining quantity on hand.

No matter what the COGS method, the total accounting quantity for a product 
across all inventory items should always be equal to the total QOH. 

  was:
>From 
>http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html

*1. Why accounting quantity? 

When inventory is shipped, there's an accounting transaction that debits the 
inventory on hand value and credits Cost of Goods Sold (COGS). 

There's more than one way of deciding what value is added to COGS. 

First and most obvious is the actual cost of the inventory item. But companies 
may prefer other strategies. OFBiz has the option of three others: average 
cost, first-in-first-out or last-in-first-out. There's a nice survey of *why* 
you might choose one of these at 
http://www.dummies.com/business/operations-management/choosing-an-
accounting-method-for-the-cost-of-goods-sold-expense/, 
http://www.dummies.com/business/accounting/the-fifo-
method-for-cost-of-goods-sold/, http://www.dummies.com/
business/accounting/the-lifo-method-for-cost-of-goods-sold/ 

Note that if you choose anything other than inventory item cost, the money 
amount transferred to the COGS 

[jira] [Created] (OFBIZ-9500) Maintain accountingQuantity for all COGS valuation methods

2017-07-19 Thread Paul Foxworthy (JIRA)
Paul Foxworthy created OFBIZ-9500:
-

 Summary: Maintain accountingQuantity for all COGS valuation methods
 Key: OFBIZ-9500
 URL: https://issues.apache.org/jira/browse/OFBIZ-9500
 Project: OFBiz
  Issue Type: Improvement
  Components: accounting, order, product
Affects Versions: Trunk
Reporter: Paul Foxworthy


>From 
>http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html

*1. Why accounting quantity? 

When inventory is shipped, there's an accounting transaction that debits the 
inventory on hand value and credits Cost of Goods Sold (COGS). 

There's more than one way of deciding what value is added to COGS. 

First and most obvious is the actual cost of the inventory item. But companies 
may prefer other strategies. OFBiz has the option of three others: average 
cost, first-in-first-out or last-in-first-out. There's a nice survey of *why* 
you might choose one of these at 
http://www.dummies.com/business/operations-management/choosing-an-
accounting-method-for-the-cost-of-goods-sold-expense/, 
http://www.dummies.com/business/accounting/the-fifo-
method-for-cost-of-goods-sold/, http://www.dummies.com/
business/accounting/the-lifo-method-for-cost-of-goods-sold/ 

Note that if you choose anything other than inventory item cost, the money 
amount transferred to the COGS account may be *different* to the cost price of 
the inventory items being shipped. When you choose FIFO or LIFO, the amount may 
have originated from a different inventory item, received at a different time. 

*2. Current situation in OFBiz 

The cogsMethodId field in the PartyAcctgPreference entity is a enum with four 
possible values: COGS_INV_COST, COGS_AVG_COST,  COGS_FIFO, COGS_LIFO.. 

The accountingQuantity field in the InventoryItem entity and 
accountingQuantityDiff in the InventoryItemDetail entity track the quantity of 
an item still "live" for the purpose of inventory valuation and COGS. 

In the service createAcctgTransForShipmentReceipt implemented in 
/applications/accounting/minilang/ledger/GeneralLedgerServices.xml 
(http://svn.apache.org/viewvc/ofbiz/trunk/applications/
accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1306) 

the accountingQuantity is always set to the same value as the quantity received 
(i.e. the same as the quantityOnHand) for a newly received inventory item 
regardless of the COGS method. 

When items are shipped, the service createAcctgTransForSalesShipmentIssuance 
will only reduce the accounting quantity if the COGS method is FIFO or LIFO 
(http://svn.apache.org/viewvc/
ofbiz/trunk/applications/accounting/minilang/ledger/ 
GeneralLedgerServices.xml?view=markup#l1127).

With FIFO, when an item is shipped, inventory items for the product with a 
non-zero accounting quantity are found sorted from earliest to latest received. 
The quantity of the item shipped must be decremented from the accounting 
quantities, starting with the earliest. Similarly, with LIFO, items are sorted 
from latest to earliest, and the latest item or items are 
decremented. 

In other words, if you have chosen a COGS method of COGS_INV_COST or 
COGS_AVG_COST, the accounting quantity is meaningless and in OFBiz as of 
now, should be ignored. 

And yet, the Inventory Valuation report uses accounting quantity, regardless of 
the the COGS method (http://svn.apache.org/viewvc/
ofbiz/trunk/applications/accounting/widget/ReportFinancialSummaryForms. 
xml?view=markup#l535). In other words, the Inventory Valuation report is broken 
for COGS methods of COGS_INV_COST or COGS_AVG_COST. 

*3. What should happen 

The Inventory Valuation report, and anybody else who cares, should always be 
able to trust the accounting quantity. For COGS_INV_COST and COGS_AVG_COST, 
maintaining the accounting quantity is simple - 
createAcctgTransForSalesShipmentIssuanceit should just adjust it to match the 
remaining quantity on hand.

No matter what the COGS method, the total accounting quantity for a product 
across all inventory items should always be equal to the total QOH. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (OFBIZ-9464) Accounting quantity transfer should not be zero while transferring inventory from one facility to another

2017-07-19 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-9464:
--
Labels: inventory stock valuation  (was: )

> Accounting quantity transfer should not be zero while transferring inventory 
> from one facility to another
> -
>
> Key: OFBIZ-9464
> URL: https://issues.apache.org/jira/browse/OFBIZ-9464
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Vaibhav Jain
>Assignee: Divesh Dutta
>  Labels: inventory, stock, valuation
> Fix For: 16.11.04
>
> Attachments: OFBIZ_9464.patch
>
>
> when we transfer inventory, the accountingQuantityTotal field of 
> _InventoryItem_ entity is always ZERO. There is no reflection of ATP/QOH in 
> accountingQuantityTotal.
> This will create following issues in the system.
> # Accounting quantity total will mismatch with the original quantity in the 
> facility which shows the wrong result when we calculate facility specific 
> inventory valuation.
> # Inventory reservation also throws an error in some specific case like when 
> AQT of respective product is zero in the specific facility from when 
> reservation happens.
> As we manage 5 different statuses of inventory transfer in OFBiz and 
> according to my current understanding these processes are associated with the 
> respective statuses, which are as show below
> Requested: As inventory transfer is requested for another facility. 
> a)ATP, QOH and AQT should decrease from the inventory item of From Facility 
> and QOH of To Facility should increase.
> b)ATP and AQT should be Zero in To Facility as inventory is not transferred 
> yet. But QOH should increase at To Facility because QOH shows the 
> xferquantity later. At the time of the completion of the transfer
> ATP = ATP + (QOH - ATP) (Adjustment in case of backorder)
> AQT = QOH
> b)AQT should not decrease because AQT is used for accounting purpose and as 
> of now quantity is still in From Facility as the transfer is not done yet. 
> which shows the xferQuantity later 
> Scheduled: As inventory transfer is Scheduled for another facility. ATP, QOH 
> and AQT should not affect in both From Facility and To Facility.
> En-route: As inventory is routed to reach at To Facility. Even in this case 
> ATP, QOH and AQT should not affect in both From Facility and To Facility.
> Complete: As inventory transfer is completed 
> a)ATP, QOH and AQT should not affect at From Facility. 
> b)QOH will be same but ATP and AQT should affect respectively
> ATP = ATP + (QOH - ATP)
> AQT = QOH
> Cancelled: As inventory transfer is cancelled and inventory item record is 
> already created  so 
> a) ATP, QOH and AQT should decrease from old inventory item and ATP, QOH and 
> AQT should increase in the newly created inventory item.
> Key points: 
> If the whole ATP and QOH is moved then new inventory item will not create. 
> Only Facility and location are changed for existing inventory item.
> Before Changes:-
> As I know there are following processes are associated with respective 
> statuses 
> **Note:   ATP-> Available to promiseQOH-> Quantity on handAQT-> 
> Accounting quantity total
> 1. Requested:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 2. Scheduled:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 3.En-Route:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 4.Complete:-
> If the partial quantity of any inventory item is transferred.
> ATP =Transferred quantity   QOH=Transferred quantity   AQT=0
> If the whole quantity is transferred then only facility id and location 
> will change no new inventory item record will create. 
> 5.Cancelled:-
> No new inventory item record will create. An inventory transfer record is 
> created with whole ATP/QOH in cancelled status.
> After Changes:-
> As shown above, accounting quantity transfer will not affect in transfer 
> inventory. After the following changes, records will be updated a shown below.
> 1. Requested:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 2. Scheduled:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 3.En-Route:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 4.Complete:-
> If the partial quantity of any inventory item is transferred.
> ATP =Transferred quantity   QOH=Transferred quantity   
> AQT=Transferred quantity
> If the whole quantity is transferred then only facility id and location 
> will change no new inventory item 

[jira] [Reopened] (OFBIZ-9464) Accounting quantity transfer should not be zero while transferring inventory from one facility to another

2017-07-19 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy reopened OFBIZ-9464:
---

> Accounting quantity transfer should not be zero while transferring inventory 
> from one facility to another
> -
>
> Key: OFBIZ-9464
> URL: https://issues.apache.org/jira/browse/OFBIZ-9464
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Vaibhav Jain
>Assignee: Divesh Dutta
> Fix For: 16.11.04
>
> Attachments: OFBIZ_9464.patch
>
>
> when we transfer inventory, the accountingQuantityTotal field of 
> _InventoryItem_ entity is always ZERO. There is no reflection of ATP/QOH in 
> accountingQuantityTotal.
> This will create following issues in the system.
> # Accounting quantity total will mismatch with the original quantity in the 
> facility which shows the wrong result when we calculate facility specific 
> inventory valuation.
> # Inventory reservation also throws an error in some specific case like when 
> AQT of respective product is zero in the specific facility from when 
> reservation happens.
> As we manage 5 different statuses of inventory transfer in OFBiz and 
> according to my current understanding these processes are associated with the 
> respective statuses, which are as show below
> Requested: As inventory transfer is requested for another facility. 
> a)ATP, QOH and AQT should decrease from the inventory item of From Facility 
> and QOH of To Facility should increase.
> b)ATP and AQT should be Zero in To Facility as inventory is not transferred 
> yet. But QOH should increase at To Facility because QOH shows the 
> xferquantity later. At the time of the completion of the transfer
> ATP = ATP + (QOH - ATP) (Adjustment in case of backorder)
> AQT = QOH
> b)AQT should not decrease because AQT is used for accounting purpose and as 
> of now quantity is still in From Facility as the transfer is not done yet. 
> which shows the xferQuantity later 
> Scheduled: As inventory transfer is Scheduled for another facility. ATP, QOH 
> and AQT should not affect in both From Facility and To Facility.
> En-route: As inventory is routed to reach at To Facility. Even in this case 
> ATP, QOH and AQT should not affect in both From Facility and To Facility.
> Complete: As inventory transfer is completed 
> a)ATP, QOH and AQT should not affect at From Facility. 
> b)QOH will be same but ATP and AQT should affect respectively
> ATP = ATP + (QOH - ATP)
> AQT = QOH
> Cancelled: As inventory transfer is cancelled and inventory item record is 
> already created  so 
> a) ATP, QOH and AQT should decrease from old inventory item and ATP, QOH and 
> AQT should increase in the newly created inventory item.
> Key points: 
> If the whole ATP and QOH is moved then new inventory item will not create. 
> Only Facility and location are changed for existing inventory item.
> Before Changes:-
> As I know there are following processes are associated with respective 
> statuses 
> **Note:   ATP-> Available to promiseQOH-> Quantity on handAQT-> 
> Accounting quantity total
> 1. Requested:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 2. Scheduled:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 3.En-Route:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 4.Complete:-
> If the partial quantity of any inventory item is transferred.
> ATP =Transferred quantity   QOH=Transferred quantity   AQT=0
> If the whole quantity is transferred then only facility id and location 
> will change no new inventory item record will create. 
> 5.Cancelled:-
> No new inventory item record will create. An inventory transfer record is 
> created with whole ATP/QOH in cancelled status.
> After Changes:-
> As shown above, accounting quantity transfer will not affect in transfer 
> inventory. After the following changes, records will be updated a shown below.
> 1. Requested:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 2. Scheduled:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 3.En-Route:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 4.Complete:-
> If the partial quantity of any inventory item is transferred.
> ATP =Transferred quantity   QOH=Transferred quantity   
> AQT=Transferred quantity
> If the whole quantity is transferred then only facility id and location 
> will change no new inventory item record will create. 
> 5.Cancelled:-
> No new inventory item record will create. An inventory 

[jira] [Commented] (OFBIZ-9464) Accounting quantity transfer should not be zero while transferring inventory from one facility to another

2017-07-19 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16094012#comment-16094012
 ] 

Paul Foxworthy commented on OFBIZ-9464:
---

This fix is OK for COGS methods of inventory cost and average cost, but not for 
FIFO and LIFO.

See this thread from January: 
http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html#a4700869
 .

During a sale, the createAcctgTransForSalesShipmentIssuance service adjusts the 
accountingQuantity for the most or least recent inventory item, not necessarily 
the item being sold. The same should happen during transfers.

> Accounting quantity transfer should not be zero while transferring inventory 
> from one facility to another
> -
>
> Key: OFBIZ-9464
> URL: https://issues.apache.org/jira/browse/OFBIZ-9464
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Vaibhav Jain
>Assignee: Divesh Dutta
> Fix For: 16.11.04
>
> Attachments: OFBIZ_9464.patch
>
>
> when we transfer inventory, the accountingQuantityTotal field of 
> _InventoryItem_ entity is always ZERO. There is no reflection of ATP/QOH in 
> accountingQuantityTotal.
> This will create following issues in the system.
> # Accounting quantity total will mismatch with the original quantity in the 
> facility which shows the wrong result when we calculate facility specific 
> inventory valuation.
> # Inventory reservation also throws an error in some specific case like when 
> AQT of respective product is zero in the specific facility from when 
> reservation happens.
> As we manage 5 different statuses of inventory transfer in OFBiz and 
> according to my current understanding these processes are associated with the 
> respective statuses, which are as show below
> Requested: As inventory transfer is requested for another facility. 
> a)ATP, QOH and AQT should decrease from the inventory item of From Facility 
> and QOH of To Facility should increase.
> b)ATP and AQT should be Zero in To Facility as inventory is not transferred 
> yet. But QOH should increase at To Facility because QOH shows the 
> xferquantity later. At the time of the completion of the transfer
> ATP = ATP + (QOH - ATP) (Adjustment in case of backorder)
> AQT = QOH
> b)AQT should not decrease because AQT is used for accounting purpose and as 
> of now quantity is still in From Facility as the transfer is not done yet. 
> which shows the xferQuantity later 
> Scheduled: As inventory transfer is Scheduled for another facility. ATP, QOH 
> and AQT should not affect in both From Facility and To Facility.
> En-route: As inventory is routed to reach at To Facility. Even in this case 
> ATP, QOH and AQT should not affect in both From Facility and To Facility.
> Complete: As inventory transfer is completed 
> a)ATP, QOH and AQT should not affect at From Facility. 
> b)QOH will be same but ATP and AQT should affect respectively
> ATP = ATP + (QOH - ATP)
> AQT = QOH
> Cancelled: As inventory transfer is cancelled and inventory item record is 
> already created  so 
> a) ATP, QOH and AQT should decrease from old inventory item and ATP, QOH and 
> AQT should increase in the newly created inventory item.
> Key points: 
> If the whole ATP and QOH is moved then new inventory item will not create. 
> Only Facility and location are changed for existing inventory item.
> Before Changes:-
> As I know there are following processes are associated with respective 
> statuses 
> **Note:   ATP-> Available to promiseQOH-> Quantity on handAQT-> 
> Accounting quantity total
> 1. Requested:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 2. Scheduled:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 3.En-Route:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 4.Complete:-
> If the partial quantity of any inventory item is transferred.
> ATP =Transferred quantity   QOH=Transferred quantity   AQT=0
> If the whole quantity is transferred then only facility id and location 
> will change no new inventory item record will create. 
> 5.Cancelled:-
> No new inventory item record will create. An inventory transfer record is 
> created with whole ATP/QOH in cancelled status.
> After Changes:-
> As shown above, accounting quantity transfer will not affect in transfer 
> inventory. After the following changes, records will be updated a shown below.
> 1. Requested:-
> ATP =0QOH=Transferred quantity
>AQT=0
> 2. Scheduled:-
> ATP =0QOH=Transferred quantity
>

[jira] [Commented] (OFBIZ-9492) Tax Authorities need two GL accounts for sales and purchases

2017-07-18 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16091164#comment-16091164
 ] 

Paul Foxworthy commented on OFBIZ-9492:
---

Hi [~deepak.nigam],

Yes and no.

No, I think the tax paid and collected shouldn't be put in the same account, at 
least in Australia. At the end of a reporting period, you need to know and be 
able to report the total tax paid on purchases and collected with sales as two 
separate numbers. The tax to pay is indeed the difference between the two, but 
the difference number alone will not satisfy the good people at the Australian 
Tax Office.

I would expect when this Jira is completed, during purchases there will be a 
credit to a "tax paid on purchases" asset GL account, and during sales there 
will be a debit to a "tax collected on sales" liability GL account.

So technically, you could use a debitCreditFlag in the TaxAuthorityGlAccount 
entity.

But imagine someone trying to do the data entry to configure the GL accounts 
for a tax authority, something like 
https://demo-trunk.ofbiz.apache.org/accounting/control/EditTaxAuthorityGlAccounts
 . I think asking the user to choose Credit or Debit would be very confusing. 
We *could* reuse one of the existing ways of categorising things in OFBiz: 
debitCreditFlag as you say, or INCOME vs EXPENSE (very general GL account 
types). I have explored a little more in thinking about your suggestion, and I 
wonder if the right thing is to use the AcctgTransType entity instead of 
inventing a new one. There are already SALES_INVOICE, PURCHASE_INVOICE and 
CUST_RTN_INVOICE values which correspond to the three services. I could imagine 
a larger company wanting to account for tax in other transactions like a credit 
note.

What does everyone think of using AcctgTransType instead of inventing a new 
enum or entity which is trying to do similar categorisation of transactions?

Cheers

Paul


> Tax Authorities need two GL accounts for sales and purchases
> 
>
> Key: OFBIZ-9492
> URL: https://issues.apache.org/jira/browse/OFBIZ-9492
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>  Labels: accounting, vat
>
> In jurisdictions with Value Added Tax, you need to track tax you have paid on 
> purchases, and tax you have collected with sales. When you report to a tax 
> authority, you pay them the difference between the two, i.e. you pay tax on 
> the value added, not on your inputs.
> OFBiz has an entity, TaxAuthorityGlAccount (TAGLA), which currently assumes 
> the GL account is for a sale.
> We need to extend OFBiz so it is possible to find two GL accounts for a tax 
> authority, one for sales and one for purchases.
> I propose:
> - Define a new Enumeration for the direction of a transaction. I suggest
> calling the Enumeration TAGLADIR, with two values TAGLADIR_INCOMING
> and TAGLADIR_OUTGOING.
> We could reuse an existing indication of the direction of a transaction,
> for example the GlAccountClassIds INCOME and EXPENSE. However, when we receive
> income from a sale, we would incur a tax *liability*, and the GL account for 
> that
> would be a liability account. So I think it would be less confusing to have a
> separate enum here that's just for TAGLA.
> - add a new attribute to the TaxAuthorityGlAccount entity for the direction 
> of the transaction.
> The new attribute should be included in the primary key.
> - Add a new service in TaxAuthorityServices named getTaxAuthorityGlAccountId 
> which
> looks up a TAGLA given primary key values, including the direction
> - There are two places in TaxAuthorityServices that would call 
> getTaxAuthorityGlAccountId: getTaxAdjustments and getItemTaxAdjustments, one 
> for orders, and the other for invoice item types. The direction can be 
> inferred from the order type or the invoice item type
> - createAcctgTransForPurchaseInvoice and 
> createAcctgTransForCustomerReturnInvoice
> should use getTaxAuthorityGlAccountId
> - createAcctgTransactionForSalesInvoice should be rewritten to use 
> getTaxAuthorityGlAccountId.
> I am working on a patch to do this, but I'd like your thoughts on my proposal



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (OFBIZ-9492) Tax Authorities need two GL accounts for sales and purchases

2017-07-17 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090890#comment-16090890
 ] 

Paul Foxworthy commented on OFBIZ-9492:
---

Thanks [~jacopoc].

I would create a new entity if there is or might be another attribute to add. 
It strikes me that a description might be a very useful thing here, so let's 
make it an entity. In OFBIZ-9127 I raised the possibility of internationalising 
descriptions that are currently hard-coded in English. We could prototype that 
here, by adding an attribute (perhaps named descriptionKey or 
i18nDescriptionKey) that can be used to fetch a localised description in the 
same way as the UI components of OFBiz.

I would like to get the word "direction" or something like it into the name, 
something along the lines of TaxAuthorityGlAccountDirectionType, to 
differentiate this entity from GlAccountType. We are talking about a type of 
direction (the transaction that initiated the tax event is in or out, income or 
expense) and not a type of GL account. What does everyone think?

Cheers

Paul

> Tax Authorities need two GL accounts for sales and purchases
> 
>
> Key: OFBIZ-9492
> URL: https://issues.apache.org/jira/browse/OFBIZ-9492
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>  Labels: accounting, vat
>
> In jurisdictions with Value Added Tax, you need to track tax you have paid on 
> purchases, and tax you have collected with sales. When you report to a tax 
> authority, you pay them the difference between the two, i.e. you pay tax on 
> the value added, not on your inputs.
> OFBiz has an entity, TaxAuthorityGlAccount (TAGLA), which currently assumes 
> the GL account is for a sale.
> We need to extend OFBiz so it is possible to find two GL accounts for a tax 
> authority, one for sales and one for purchases.
> I propose:
> - Define a new Enumeration for the direction of a transaction. I suggest
> calling the Enumeration TAGLADIR, with two values TAGLADIR_INCOMING
> and TAGLADIR_OUTGOING.
> We could reuse an existing indication of the direction of a transaction,
> for example the GlAccountClassIds INCOME and EXPENSE. However, when we receive
> income from a sale, we would incur a tax *liability*, and the GL account for 
> that
> would be a liability account. So I think it would be less confusing to have a
> separate enum here that's just for TAGLA.
> - add a new attribute to the TaxAuthorityGlAccount entity for the direction 
> of the transaction.
> The new attribute should be included in the primary key.
> - Add a new service in TaxAuthorityServices named getTaxAuthorityGlAccountId 
> which
> looks up a TAGLA given primary key values, including the direction
> - There are two places in TaxAuthorityServices that would call 
> getTaxAuthorityGlAccountId: getTaxAdjustments and getItemTaxAdjustments, one 
> for orders, and the other for invoice item types. The direction can be 
> inferred from the order type or the invoice item type
> - createAcctgTransForPurchaseInvoice and 
> createAcctgTransForCustomerReturnInvoice
> should use getTaxAuthorityGlAccountId
> - createAcctgTransactionForSalesInvoice should be rewritten to use 
> getTaxAuthorityGlAccountId.
> I am working on a patch to do this, but I'd like your thoughts on my proposal



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (OFBIZ-9492) Tax Authorities need two GL accounts for sales and purchases

2017-07-17 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089506#comment-16089506
 ] 

Paul Foxworthy commented on OFBIZ-9492:
---

Hi [~pierre smits],

Of course you're right, thanks for your insight.

Invoice items for tax have a foreign key that refers to the relevant 
TaxAuthorityRateProduct(TARP) entity. TARP has an attribute 
taxAuthorityRateTypeId, so we can discover the tax type when we're generating 
GL transactions for the invoice item. If we add a similar attribute 
taxAuthorityRateTypeId to TaxAuthorityGlAccount (TAGLA) , do you think that 
will do the trick?

Cheers

Paul





> Tax Authorities need two GL accounts for sales and purchases
> 
>
> Key: OFBIZ-9492
> URL: https://issues.apache.org/jira/browse/OFBIZ-9492
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>  Labels: accounting, vat
>
> In jurisdictions with Value Added Tax, you need to track tax you have paid on 
> purchases, and tax you have collected with sales. When you report to a tax 
> authority, you pay them the difference between the two, i.e. you pay tax on 
> the value added, not on your inputs.
> OFBiz has an entity, TaxAuthorityGlAccount (TAGLA), which currently assumes 
> the GL account is for a sale.
> We need to extend OFBiz so it is possible to find two GL accounts for a tax 
> authority, one for sales and one for purchases.
> I propose:
> - Define a new Enumeration for the direction of a transaction. I suggest
> calling the Enumeration TAGLADIR, with two values TAGLADIR_INCOMING
> and TAGLADIR_OUTGOING.
> We could reuse an existing indication of the direction of a transaction,
> for example the GlAccountClassIds INCOME and EXPENSE. However, when we receive
> income from a sale, we would incur a tax *liability*, and the GL account for 
> that
> would be a liability account. So I think it would be less confusing to have a
> separate enum here that's just for TAGLA.
> - add a new attribute to the TaxAuthorityGlAccount entity for the direction 
> of the transaction.
> The new attribute should be included in the primary key.
> - Add a new service in TaxAuthorityServices named getTaxAuthorityGlAccountId 
> which
> looks up a TAGLA given primary key values, including the direction
> - There are two places in TaxAuthorityServices that would call 
> getTaxAuthorityGlAccountId: getTaxAdjustments and getItemTaxAdjustments, one 
> for orders, and the other for invoice item types. The direction can be 
> inferred from the order type or the invoice item type
> - createAcctgTransForPurchaseInvoice and 
> createAcctgTransForCustomerReturnInvoice
> should use getTaxAuthorityGlAccountId
> - createAcctgTransactionForSalesInvoice should be rewritten to use 
> getTaxAuthorityGlAccountId.
> I am working on a patch to do this, but I'd like your thoughts on my proposal



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-07-16 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089349#comment-16089349
 ] 

Paul Foxworthy commented on OFBIZ-6330:
---

Thanks [~jacques.le.roux],

I hesitate to create local methods in minilang because they don't create their 
own scope, so you need to know and avoid all variable names used by your 
caller. 

I did create an inline simple method in my work on OFBIZ-4386. It was fiddly 
but I think necessary to help understand what was happening. My conclusion was 
to only do so when there is a significant gain in understanding.

The work on the Groovy DSL to replace minilang should help here.

Cheers

Paul

> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
>  Labels: tax, vat
> Attachments: GeneralLedgerServices.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns-alternative.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
> {code}
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> {code}
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
> {code}
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> {code}
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (OFBIZ-9492) Tax Authorities need two GL accounts for sales and purchases

2017-07-12 Thread Paul Foxworthy (JIRA)
Paul Foxworthy created OFBIZ-9492:
-

 Summary: Tax Authorities need two GL accounts for sales and 
purchases
 Key: OFBIZ-9492
 URL: https://issues.apache.org/jira/browse/OFBIZ-9492
 Project: OFBiz
  Issue Type: Improvement
  Components: accounting
Affects Versions: Trunk
Reporter: Paul Foxworthy
Assignee: Paul Foxworthy


In jurisdictions with Value Added Tax, you need to track tax you have paid on 
purchases, and tax you have collected with sales. When you report to a tax 
authority, you pay them the difference between the two, i.e. you pay tax on the 
value added, not on your inputs.

OFBiz has an entity, TaxAuthorityGlAccount (TAGLA), which currently assumes the 
GL account is for a sale.

We need to extend OFBiz so it is possible to find two GL accounts for a tax 
authority, one for sales and one for purchases.

I propose:

- Define a new Enumeration for the direction of a transaction. I suggest
calling the Enumeration TAGLADIR, with two values TAGLADIR_INCOMING
and TAGLADIR_OUTGOING.

We could reuse an existing indication of the direction of a transaction,
for example the GlAccountClassIds INCOME and EXPENSE. However, when we receive
income from a sale, we would incur a tax *liability*, and the GL account for 
that
would be a liability account. So I think it would be less confusing to have a
separate enum here that's just for TAGLA.

- add a new attribute to the TaxAuthorityGlAccount entity for the direction of 
the transaction.

The new attribute should be included in the primary key.

- Add a new service in TaxAuthorityServices named getTaxAuthorityGlAccountId 
which
looks up a TAGLA given primary key values, including the direction

- There are two places in TaxAuthorityServices that would call 
getTaxAuthorityGlAccountId: getTaxAdjustments and getItemTaxAdjustments, one 
for orders, and the other for invoice item types. The direction can be inferred 
from the order type or the invoice item type

- createAcctgTransForPurchaseInvoice and 
createAcctgTransForCustomerReturnInvoice
should use getTaxAuthorityGlAccountId

- createAcctgTransactionForSalesInvoice should be rewritten to use 
getTaxAuthorityGlAccountId.

I am working on a patch to do this, but I'd like your thoughts on my proposal




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-07-12 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16084855#comment-16084855
 ] 

Paul Foxworthy edited comment on OFBIZ-6330 at 7/12/17 10:45 PM:
-

Hi all,

I agree with Nicholas's suggestion to use the tax amounts the service is 
already gathering, and not calling getInvoiceTaxTotal. Christian's patch did 
that for createAcctgTransForPurchaseInvoice.

This OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline patch adds that for 
createAcctgTransForCustomerReturnInvoice and 
createAcctgTransForPurchaseInvoice. I have modified 
createAcctgTransForSalesInvoice to work in the same way.

I have also added a glAccountTypeId of TAX_ACCOUNT for returns and purchases.

It should be possible to set  the GL account for tax authorities on purchases, 
but at present OFBiz only does so for sales. I will create a separate Jira for 
that issue.

Please review!


was (Author: paul_foxworthy):
Hi all,

I agree with Nicholas's suggestion to use the tax amounts the service is 
already gathering, and not calling getInvoiceTaxTotal.

This patch adds that for createAcctgTransForCustomerReturnInvoice and 
createAcctgTransForPurchaseInvoice. I have modified 
createAcctgTransForSalesInvoice to work in the same way.

I have also added a glAccountTypeId of TAX_ACCOUNT for returns and purchases.

It should be possible to set  the GL account for tax authorities on purchases, 
but at present OFBiz only does so for sales. I will create a separate Jira for 
that issue.


> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
> Attachments: GeneralLedgerServices.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns-alternative.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Assigned] (OFBIZ-4514) Taxes are not handled correctly when creating accounting transactions from purchase invoices

2017-07-12 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy reassigned OFBIZ-4514:
-

Assignee: Paul Foxworthy

> Taxes are not handled correctly when creating accounting transactions from 
> purchase invoices
> 
>
> Key: OFBIZ-4514
> URL: https://issues.apache.org/jira/browse/OFBIZ-4514
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
>Priority: Trivial
>  Labels: VAT, tax
> Attachments: OFBIZ-4514_combined.patch, OFBIZ-4514.patch
>
>
> Taxes are not handled correctly when creating accounting transactions from 
> purchase invoices in GeneralLedgerServices#createAcctgTransForPurchaseInvoice



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-07-12 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-6330:
--
Labels: tax vat  (was: )

> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
>  Labels: tax, vat
> Attachments: GeneralLedgerServices.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns-alternative.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-02-09 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860379#comment-15860379
 ] 

Paul Foxworthy commented on OFBIZ-6330:
---

Thanks Christian,

Sorry, duh, I shoulda got the package name right. New patch attached.

I'm leaning towards Nicolas's suggestion to avoid the call to 
getInvoiceTaxTotal and just add up the tax amounts. We want the accounting 
transaction to balance debits and credits. If we just add up the tax amounts, 
we are surer everything will balance, compared to trusting getInvoiceTaxTotal. 
And we avoid one method call, so the service would be fractionally faster.

Jacopo and Christian, what do you think?

People did discover the problem (OFBIZ-4514 and OFBIZ-5936), but a fix was 
never committed. If we had reasonable tests ("does the accounting transaction 
balance?"), we'd have highlighted how flawed these services were years ago. 
Anyone want to work on some tests now?



> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
> Attachments: GeneralLedgerServices.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-02-09 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-6330:
--
Attachment: OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch

> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
> Attachments: GeneralLedgerServices.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (OFBIZ-4514) Taxes are not handled correctly when creating accounting transactions from purchase invoices

2017-02-09 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859327#comment-15859327
 ] 

Paul Foxworthy commented on OFBIZ-4514:
---

OK will put together a combined patch

> Taxes are not handled correctly when creating accounting transactions from 
> purchase invoices
> 
>
> Key: OFBIZ-4514
> URL: https://issues.apache.org/jira/browse/OFBIZ-4514
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Martin Kreidenweis
>Priority: Trivial
>  Labels: VAT, tax
> Attachments: OFBIZ-4514.patch
>
>
> Taxes are not handled correctly when creating accounting transactions from 
> purchase invoices in GeneralLedgerServices#createAcctgTransForPurchaseInvoice



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-02-08 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859023#comment-15859023
 ] 

Paul Foxworthy commented on OFBIZ-6330:
---

[~jacopoc], you commented on a similar issue OFBIZ-4514. What do you think of 
this?

> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
> Attachments: GeneralLedgerServices.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-02-07 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856988#comment-15856988
 ] 

Paul Foxworthy commented on OFBIZ-6330:
---

Hi Nicolas,

The code here generates individual accounting entries for the tax authorities. 
There is nothing adding the amounts up, so when the tax-inclusive price is 
calculated, the variable invoiceTaxTotal has never been used and will have a 
value of zero.

One reason I didn't take that approach (and I guess Kongrath thought the same) 
is that createAcctgTransForSalesInvoice also just calls getInvoiceTaxTotal.

I understand that adding up the tax amounts would avoid a call to one more 
method, at the expense of making the code a little more complicated. If you 
still think that's a good idea, I'll change all three methods 
createAcctgTransForCustomerReturnInvoice, createAcctgTransForSalesInvoice, 
createAcctgTransForPurchaseInvoice to work that way.

What do you think?

Cheers

Paul

> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
> Attachments: GeneralLedgerServices.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-02-06 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-6330:
--
Attachment: OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch

> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
> Attachments: GeneralLedgerServices.patch, 
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-02-06 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855110#comment-15855110
 ] 

Paul Foxworthy commented on OFBIZ-6330:
---

Kongrath,

I found your report after I encountered exactly this issue. Thank you for this. 
You are absolutely right. This is a serious problem and it's disappointing it 
has been in OFBiz so long. For my own part, I'm sorry I missed this issue when 
you first raised it.

I think there are several factors that have contributed to it. Many people are 
using OFBiz for e-commerce and ERP but not for accounting, so incorrect figures 
in the General Ledger accounts don't affect them. In addition, in the US there 
are sales taxes that apply to (you guessed it) sales, but not to purchases, so 
there would be no tax to add on to the base purchase price for the total owed. 
In Europe, Australia, New Zealand and other places with VAT or GST, tax applies 
to purchases too.

There is a similar issue with the createAcctgTransForCustomerReturnInvoice 
method also. I will revise your patch to add that.

If there are no comments in the next few days, I'll commit the change.

Thanks again

Paul Foxworthy


> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
> Attachments: GeneralLedgerServices.patch
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service

2017-02-06 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy reassigned OFBIZ-6330:
-

Assignee: Paul Foxworthy

> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice 
> service
> 
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
> Attachments: GeneralLedgerServices.patch
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of 
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did 
> not call the method to get invoiceTaxTotal.
>  class-name="org.ofbiz.accounting.invoice.InvoiceWorker" 
> ret-field="invoiceTaxTotal">
> 
> 
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code 
> below:
>  decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
> 
> 
> 
> 
> 
> That it should work like the createAcctgTransForSalesInvoice service of the 
> sales invoice.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (OFBIZ-5312) Proposal: URL-Generation Changes (mostly for SEO reasons but not only)

2017-01-24 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15837156#comment-15837156
 ] 

Paul Foxworthy commented on OFBIZ-5312:
---

With the recent discussion on ecomseo on the dev mailing list, I'd like to make 
some observations here.

Good, clean URLs are good for human beings, not just for SEO. .../control/... 
is definitely not a good, clean URL.

Good, clean URLs are beneficial for all of OFBiz, not just e-commerce, not just 
product information.

Several times in the discussion on this issue, people have said different URLs 
should not lead to the same content. It is true duplicate content will 
disadvantage you with Google and other search engines. The solution is *not* 
one unique URL for given content. The solution is to add a canonical URL link 
(https://en.wikipedia.org/wiki/Canonical_link_element) to the content, to make 
clear the primary URL and to make clear alternative URLs are just that, 
alternative paths to the same thing.

One of the strengths of OFBiz is that a product can belong to more than one 
category. If we have URLs containing categories, naturally there will be more 
than one URL for a product. For example

https://mysite.com/products/SKU-1234
https://mysite.com/products/christmas-hat
https://mysite.com/products/christmas/christmas-hat
https://mysite.com/products/hats/christmas-hat

might all get you to the same page. 

That's a good thing not a bad thing, provided we get the canonical URL right.

> Proposal: URL-Generation Changes (mostly for SEO reasons but not only)
> --
>
> Key: OFBIZ-5312
> URL: https://issues.apache.org/jira/browse/OFBIZ-5312
> Project: OFBiz
>  Issue Type: New Feature
>  Components: specialpurpose/ecommerce
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: changes, ecommerce, friendly, seo, url
> Fix For: 16.11.01
>
> Attachments: classloaderpatch.txt, 
> OFBiz-5312-allowpaths-email-jsp-patch-20140625.patch, 
> OFBIZ-5312-infinite-loop-20141209.patch, OFBIZ-5312 - 
> ofbiz-ecommerce-seo.patch, OFBIZ-5312 - ofbiz-ecommerce-seo.patch, OFBIZ-5312 
> - ofbiz-ecommerce-seo.patch, OFBIZ-5312 - ofbiz-ecommerce-seo.patch, 
> OFBIZ-5312 - ofbiz-ecommerce-seo.patch, OFBIZ-5312 - 
> ofbiz-ecommerce-seo.patch, OFBIZ-5312 - ofbiz-ecommerce-seo.patch, OFBIZ-5312 
> - ofbiz-ecommerce-seo.patch, OFBIZ-5312 - ofbiz-ecommerce-seo.patch, 
> OFBIZ-5312 - ofbiz-ecommerce-seo.patch, OFBIZ-5312 - 
> ofbiz-ecommerce-seo.patch, OFBIZ-5312 - ofbiz-ecommerce-seo.patch, 
> OFBiz-5312-product-ecommerce-seo-20131031.patch, 
> OFBiz-5312-product-ecommerce-seo-for-seo-branch.patch, 
> OFBiz-5312-product-ecommerce-seo.patch, SeoContextFilter.java.patch
>
>
> [This was proposed by Paul Piper in Nabble 7 months 
> ago|http://ofbiz.135035.n4.nabble.com/Proposal-URL-Generation-Changes-td4639289.html].
>  Here is quoted Paul's proposal
> {quote}
> Hey Everyone,
> over at ilscipio (www.ilscipio.com) we developed a set of functional OFBiz 
> changes that we believe the entire community could benefit from. The changes 
> have been implemented in parts in Syracus (www.syracus.net) for a while now, 
> but we figured that some of which are too crucial for ofbiz' success in the 
> long run, so we are considering the contribution (as we did with the SOLR 
> component).
> As you are probably aware, OFBiz has a pretty uncommon way of generating 
> URLs. Most of this has to do with the fact that OFBiz uses a servlet 
> (ControlServlet)  to handle all requests. The servlet is mounted at /control, 
> so that it won't interfere with other servlets. Though functionally valid, 
> this has the sideeffect that all urls are actually created on /control, which 
> is neither pretty, nor good by any measures of SEO. It also means that a few 
> 302 redirects are necessary to forward the user from / to /control/main. It 
> also makes requests more complicated, since many forwards are necessary 
> whenever somebody wants to move away from this implementation.
> Since this is hurtful to many of the implementers, I wanted to discuss 
> whether or not you guys would be interested in the changes we have made. The 
> functional changes contain:
> * Removal of /control out of all the urls
> * SEO-friendly URLS
> * Configurable product/category and other URLs
> * Frontpage mapping from /main to /
> It was tested on our end and contains all necessary improvements (Transforms, 
> Sample Configuration, Servlets & Filters) for it to be applicable.
> If interested, I would create a new JIRA ticket for this and after a few 
> minor internal discussions, we will gladly provide the rest of you with it.
> Regards,
> Paul 
> {quote}
> There is even a patch, mostly done by 

[jira] [Commented] (OFBIZ-4427) Runtime errors with UtilValidate.isEmpty(Object) and IsNotEmpty should be caught during compilation

2016-12-03 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15718987#comment-15718987
 ] 

Paul Foxworthy commented on OFBIZ-4427:
---

OK.

The patch should be considerably smaller because OFBIZ-8471 has already cleaned 
up use of IsEmpty with GenericValue objects.

> Runtime errors with UtilValidate.isEmpty(Object) and IsNotEmpty should be 
> caught during compilation
> ---
>
> Key: OFBIZ-4427
> URL: https://issues.apache.org/jira/browse/OFBIZ-4427
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: UtilValidate.isEmpty
> Attachments: OFBIZ-4427.patch, OFBIZ-4427_isEmpty.patch
>
>
> Hence we need to remove the UtilValidate.isEmpty(Object) method and provide 
> methods that accept explicit types.  
> Adrian then (http://markmail.org/message/37rtrnulhmyzxfoo) suggested that 
> bq. Scripting languages should use a facade class that provides methods for 
> working with generic Objects or providing default behaviors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (OFBIZ-4427) Runtime errors with UtilValidate.isEmpty(Object) and IsNotEmpty should be caught during compilation

2016-12-03 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy reassigned OFBIZ-4427:
-

Assignee: Paul Foxworthy  (was: Jacques Le Roux)

> Runtime errors with UtilValidate.isEmpty(Object) and IsNotEmpty should be 
> caught during compilation
> ---
>
> Key: OFBIZ-4427
> URL: https://issues.apache.org/jira/browse/OFBIZ-4427
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Paul Foxworthy
>Priority: Minor
>  Labels: UtilValidate.isEmpty
> Attachments: OFBIZ-4427.patch, OFBIZ-4427_isEmpty.patch
>
>
> Hence we need to remove the UtilValidate.isEmpty(Object) method and provide 
> methods that accept explicit types.  
> Adrian then (http://markmail.org/message/37rtrnulhmyzxfoo) suggested that 
> bq. Scripting languages should use a facade class that provides methods for 
> working with generic Objects or providing default behaviors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-4427) Runtime errors with UtilValidate.isEmpty(Object) and IsNotEmpty should be caught during compilation

2016-12-03 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-4427:
--
Summary: Runtime errors with UtilValidate.isEmpty(Object) and IsNotEmpty 
should be caught during compilation  (was: Possible runtime errors with 
UtilValidate.isEmpty(Object) should be rather caught during compilation)

> Runtime errors with UtilValidate.isEmpty(Object) and IsNotEmpty should be 
> caught during compilation
> ---
>
> Key: OFBIZ-4427
> URL: https://issues.apache.org/jira/browse/OFBIZ-4427
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: UtilValidate.isEmpty
> Attachments: OFBIZ-4427.patch, OFBIZ-4427_isEmpty.patch
>
>
> Hence we need to remove the UtilValidate.isEmpty(Object) method and provide 
> methods that accept explicit types.  
> Adrian then (http://markmail.org/message/37rtrnulhmyzxfoo) suggested that 
> bq. Scripting languages should use a facade class that provides methods for 
> working with generic Objects or providing default behaviors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-9134) Add party criteria to Routing Tasks

2016-12-03 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-9134:
--
Summary: Add party criteria to Routing Tasks  (was: Add required skills to 
Routing Tasks)

> Add party criteria to Routing Tasks
> ---
>
> Key: OFBIZ-9134
> URL: https://issues.apache.org/jira/browse/OFBIZ-9134
> Project: OFBiz
>  Issue Type: New Feature
>  Components: manufacturing
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Assignee: Deepak Dixit
>Priority: Minor
> Attachments: OFBIZ-9134.patch, OFBIZ-9134.patch
>
>
> OFBIZ-5852 enables you to add a Party to a Routing Task (the 
> WorkEffortPartyAssignment entity), to specify a person who is preferred to 
> perform the task.
> If the person is on leave or unavailable, the production manager would have 
> to manually specify a different person.
> It would be better to specify skill or skills required for the Routing Task. 
> Then on each production run, any Party with the right skills could be 
> scheduled to perform the task.
> There are already entities WorkEffortSkillStandard, PartySkill and SkillType  
> which could be used to enable this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-9134) Add Party criteria to Routing Tasks

2016-12-03 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-9134:
--
Summary: Add Party criteria to Routing Tasks  (was: Add party criteria to 
Routing Tasks)

> Add Party criteria to Routing Tasks
> ---
>
> Key: OFBIZ-9134
> URL: https://issues.apache.org/jira/browse/OFBIZ-9134
> Project: OFBiz
>  Issue Type: New Feature
>  Components: manufacturing
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Assignee: Deepak Dixit
>Priority: Minor
> Attachments: OFBIZ-9134.patch, OFBIZ-9134.patch
>
>
> OFBIZ-5852 enables you to add a Party to a Routing Task (the 
> WorkEffortPartyAssignment entity), to specify a person who is preferred to 
> perform the task.
> If the person is on leave or unavailable, the production manager would have 
> to manually specify a different person.
> It would be better to specify skill or skills required for the Routing Task. 
> Then on each production run, any Party with the right skills could be 
> scheduled to perform the task.
> There are already entities WorkEffortSkillStandard, PartySkill and SkillType  
> which could be used to enable this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-9134) Add required skills to Routing Tasks

2016-12-03 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15718972#comment-15718972
 ] 

Paul Foxworthy commented on OFBIZ-9134:
---

Thanks Pierre,

No, I'm not sure. I think this area is one many OFBiz adopters will want to 
customise. What I'm contemplating is a simple example implementation, and 
support in the data model so it would be fairly easy to write a customised 
service to assign parties to a routing task.

You have implemented OFBiz in a manufacturing situation, so if you think 
there's no prospect for a simple implementation, I'd be happy to accept your 
advice.

What really got me going on this was OFBIZ-5852. It is absolutely better than 
nothing, but won't scale. Associating a fixed party with a task means when that 
party is unavailable, there can be no automatic assignment at all. In contrast, 
if the assignment is skills based, when a party goes on leave or ceases to work 
for the organisation, the service can assign or suggest another party with 
appropriate skills.

In the default implementation in OFBiz, I would be happy if the skills 
associated with the task are used to filter a list of parties, so only parties 
with the appropriate skills are offered to the production manager. If there are 
no skills, allow the production manager to browse all parties. Where skills 
have been set up, perhaps offer a list of parties filtered by skills first, 
with the ability to browse all parties if that's what the production manager 
wants to do.

You say a production manager would only be able to assign parties that he or 
she can direct, members of a team over which the manager has some authority. So 
maybe the filter would not just be on skills. If we attach a party filter to a 
task to narrow down parties that might possibly perform it, we should think 
about criteria. Membership of a PartyGroup (a team or department) would be one, 
skills would be another. Are there any more we can think of?

Cheers

Paul

> Add required skills to Routing Tasks
> 
>
> Key: OFBIZ-9134
> URL: https://issues.apache.org/jira/browse/OFBIZ-9134
> Project: OFBiz
>  Issue Type: New Feature
>  Components: manufacturing
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Assignee: Deepak Dixit
>Priority: Minor
> Attachments: OFBIZ-9134.patch, OFBIZ-9134.patch
>
>
> OFBIZ-5852 enables you to add a Party to a Routing Task (the 
> WorkEffortPartyAssignment entity), to specify a person who is preferred to 
> perform the task.
> If the person is on leave or unavailable, the production manager would have 
> to manually specify a different person.
> It would be better to specify skill or skills required for the Routing Task. 
> Then on each production run, any Party with the right skills could be 
> scheduled to perform the task.
> There are already entities WorkEffortSkillStandard, PartySkill and SkillType  
> which could be used to enable this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-9134) Add required skills to Routing Tasks

2016-12-01 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713381#comment-15713381
 ] 

Paul Foxworthy commented on OFBIZ-9134:
---

Thanks Pierre.

This is the easy bit, the hard bit is using the skills data to allocate a party 
when scheduling a production run.


> Add required skills to Routing Tasks
> 
>
> Key: OFBIZ-9134
> URL: https://issues.apache.org/jira/browse/OFBIZ-9134
> Project: OFBiz
>  Issue Type: New Feature
>  Components: manufacturing
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Assignee: Deepak Dixit
>Priority: Minor
> Attachments: OFBIZ-9134.patch, OFBIZ-9134.patch
>
>
> OFBIZ-5852 enables you to add a Party to a Routing Task (the 
> WorkEffortPartyAssignment entity), to specify a person who is preferred to 
> perform the task.
> If the person is on leave or unavailable, the production manager would have 
> to manually specify a different person.
> It would be better to specify skill or skills required for the Routing Task. 
> Then on each production run, any Party with the right skills could be 
> scheduled to perform the task.
> There are already entities WorkEffortSkillStandard, PartySkill and SkillType  
> which could be used to enable this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-9134) Add required skills to Routing Tasks

2016-11-30 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15711035#comment-15711035
 ] 

Paul Foxworthy commented on OFBIZ-9134:
---

Thanks Suraj.

The request maps createRoutinTaskSkill, updateRoutinTaskSkill and 
deleteRoutinTaskSkill all need a "g" to make the word Routing.

> Add required skills to Routing Tasks
> 
>
> Key: OFBIZ-9134
> URL: https://issues.apache.org/jira/browse/OFBIZ-9134
> Project: OFBiz
>  Issue Type: New Feature
>  Components: manufacturing
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Assignee: Suraj Khurana
>Priority: Minor
> Attachments: OFBIZ-9134.patch
>
>
> OFBIZ-5852 enables you to add a Party to a Routing Task (the 
> WorkEffortPartyAssignment entity), to specify a person who is preferred to 
> perform the task.
> If the person is on leave or unavailable, the production manager would have 
> to manually specify a different person.
> It would be better to specify skill or skills required for the Routing Task. 
> Then on each production run, any Party with the right skills could be 
> scheduled to perform the task.
> There are already entities WorkEffortSkillStandard, PartySkill and SkillType  
> which could be used to enable this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-4427) Possible runtime errors with UtilValidate.isEmpty(Object) should be rather caught during compilation

2016-11-30 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15710204#comment-15710204
 ] 

Paul Foxworthy commented on OFBIZ-4427:
---

OK, thanks Jacques.

ObjectType.isEmpty should remain for minilang, querying and other framework 
code that needs it. So minilang should continue to work without any change.

It's just UtilValidate.isEmpty(Object) and UtilValidate.isNotEmpty(Object) that 
are going away, so *service* code in Java and Groovy will get better checking.


> Possible runtime errors with UtilValidate.isEmpty(Object) should be rather 
> caught during compilation
> 
>
> Key: OFBIZ-4427
> URL: https://issues.apache.org/jira/browse/OFBIZ-4427
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: UtilValidate.isEmpty
> Attachments: OFBIZ-4427.patch, OFBIZ-4427_isEmpty.patch
>
>
> Hence we need to remove the UtilValidate.isEmpty(Object) method and provide 
> methods that accept explicit types.  
> Scripting languages should use a facade class that provides methods for 
> working with generic Objects or providing default behaviors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (OFBIZ-4427) Possible runtime errors with UtilValidate.isEmpty(Object) should be rather caught during compilation

2016-11-30 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15707440#comment-15707440
 ] 

Paul Foxworthy edited comment on OFBIZ-4427 at 11/30/16 10:56 PM:
--

Jacques says in the description: "Scripting languages should use a facade class 
that provides methods for working with generic Objects or providing default 
behaviors"

Are you suggesting that UtilValidate.isEmpty( Object ) should be available to 
scripting languages, but not to Java?

The whole point of this issue is to enable isEmpty for types where emptiness is 
relevant , and not for other types where isEmpty is misleading and we should 
just use == null. I'd argue that if "emptiness" does not make sense, then 
isEmpty should not work, even from a scripting language.

In Groovy you can retrofit an interface onto a class using metaclasses without 
rewriting the code for that class. So we can add the 
org.apache.ofbiz.base.lang.IsEmpty interface to everything we need, and still 
deprecate it for Objects in general.


was (Author: paul_foxworthy):
Jacques says in the description: "Scripting languages should use a facade class 
that provides methods for working with generic Objects or providing default 
behaviors"

Are you suggesting that UtilValidate.isEmpty( Object ) should be available to 
scripting languages, but not to Java?

The whole point of this issue is to enable isEmpty for types where emptiness is 
relevant , and not for other types where isEmpty is misleading and we should 
just use == null. I'd argue that is "emptiness" does not make sense, the 
isEmpty should not work, even from a scripting language.

In Groovy you can retrofit an interface onto a class using metaclasses without 
rewriting the code for that class. So we can add the 
org.apache.ofbiz.base.lang.IsEmpty interface to everything we need, and still 
deprecate it for Objects in general.

> Possible runtime errors with UtilValidate.isEmpty(Object) should be rather 
> caught during compilation
> 
>
> Key: OFBIZ-4427
> URL: https://issues.apache.org/jira/browse/OFBIZ-4427
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: UtilValidate.isEmpty
> Attachments: OFBIZ-4427.patch, OFBIZ-4427_isEmpty.patch
>
>
> Hence we need to remove the UtilValidate.isEmpty(Object) method and provide 
> methods that accept explicit types.  
> Scripting languages should use a facade class that provides methods for 
> working with generic Objects or providing default behaviors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (OFBIZ-7129) Recognise "BASE TABLE" table type in metadata

2016-11-29 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy closed OFBIZ-7129.
-

> Recognise "BASE TABLE" table type in metadata
> -
>
> Key: OFBIZ-7129
> URL: https://issues.apache.org/jira/browse/OFBIZ-7129
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
> Attachments: OFBIZ-7129_BaseTableMetadata.patch, 
> OFBIZ-7129_BaseTableMetadata.patch
>
>
> In framework/entity/src/org/ofbiz/entity/jdbc/DatabaseUtil.java, the 
> getTableNames method looks for table types of "TABLE", "VIEW", "ALIAS" and 
> "SYNONYM" 
> (https://fisheye6.atlassian.com/browse/ofbiz/trunk/framework/entity/src/org/ofbiz/entity/jdbc/DatabaseUtil.java?r=1644354#to989).
> MariaDB produces a table type of "BASE TABLE", so OFBiz didn't detect the 
> tables were there, and attempted to create them. In fact, the tables do exist 
> so the create failed.
> The JDBC docs suggest that plain "TABLE" is a "typical" value for table type 
> (https://docs.oracle.com/javase/8/docs/api/java/sql/DatabaseMetaData.html#getTables-java.lang.String-java.lang.String-java.lang.String-java.lang.String:A-)
> But it seems "BASE TABLE" is more standards compliant - see for example 
> http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt page 576. I assume 
> some JDBC drivers transform "BASE TABLE" to plain "TABLE", but the MariaDB 
> one does not.
> I've attached a patch so OFBiz will recognise "BASE TABLE" if that's what it 
> receives in the metadata.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-4427) Possible runtime errors with UtilValidate.isEmpty(Object) should be rather caught during compilation

2016-11-29 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15707418#comment-15707418
 ] 

Paul Foxworthy commented on OFBIZ-4427:
---

Hi Jacques,

I think there's no need to be scared :-). I agree with your analysis: 
conversionRate will be null, so the inner if statement can be removed.

I suggest: change the else part of the inner if to throw an exception, then 
create a unit test to verify the exception never happens.


> Possible runtime errors with UtilValidate.isEmpty(Object) should be rather 
> caught during compilation
> 
>
> Key: OFBIZ-4427
> URL: https://issues.apache.org/jira/browse/OFBIZ-4427
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: UtilValidate.isEmpty
> Attachments: OFBIZ-4427.patch, OFBIZ-4427_isEmpty.patch
>
>
> Hence we need to remove the UtilValidate.isEmpty(Object) method and provide 
> methods that accept explicit types.  
> Scripting languages should use a facade class that provides methods for 
> working with generic Objects or providing default behaviors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-9134) Add required skills to Routing Tasks

2016-11-29 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-9134:
--
Description: 
OFBIZ-5852 enables you to add a Party to a Routing Task (the 
WorkEffortPartyAssignment entity), to specify a person who is preferred to 
perform the task.

If the person is on leave or unavailable, the production manager would have to 
manually specify a different person.

It would be better to specify skill or skills required for the Routing Task. 
Then on each production run, any Party with the right skills could be scheduled 
to perform the task.

There are already entities WorkEffortSkillStandard, PartySkill and SkillType  
which could be used to enable this.

  was:
OFBIZ-5852 enables you to add a Party to a Routing Task (the 
WorkEffortPartyAssignment entity), to specify a person who is preferred to 
perform the task.

If the person is on leave of unavailable, the production manager would have to 
manually specify a different person.

It would be better to specify skill or skills required for the Routing Task. 
Then on each production run, any Party with the right skills could be scheduled 
to perform the task.

There are already entities WorkEffortSkillStandard, PartySkill and SkillType  
which could be used to enable this.


> Add required skills to Routing Tasks
> 
>
> Key: OFBIZ-9134
> URL: https://issues.apache.org/jira/browse/OFBIZ-9134
> Project: OFBiz
>  Issue Type: New Feature
>  Components: manufacturing
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Priority: Minor
>
> OFBIZ-5852 enables you to add a Party to a Routing Task (the 
> WorkEffortPartyAssignment entity), to specify a person who is preferred to 
> perform the task.
> If the person is on leave or unavailable, the production manager would have 
> to manually specify a different person.
> It would be better to specify skill or skills required for the Routing Task. 
> Then on each production run, any Party with the right skills could be 
> scheduled to perform the task.
> There are already entities WorkEffortSkillStandard, PartySkill and SkillType  
> which could be used to enable this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-9134) Add required skills to Routing Tasks

2016-11-29 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-9134:
--
Issue Type: New Feature  (was: Improvement)

> Add required skills to Routing Tasks
> 
>
> Key: OFBIZ-9134
> URL: https://issues.apache.org/jira/browse/OFBIZ-9134
> Project: OFBiz
>  Issue Type: New Feature
>  Components: manufacturing
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Priority: Minor
>
> OFBIZ-5852 enables you to add a Party to a Routing Task (the 
> WorkEffortPartyAssignment entity), to specify a person who is preferred to 
> perform the task.
> If the person is on leave of unavailable, the production manager would have 
> to manually specify a different person.
> It would be better to specify skill or skills required for the Routing Task. 
> Then on each production run, any Party with the right skills could be 
> scheduled to perform the task.
> There are already entities WorkEffortSkillStandard, PartySkill and SkillType  
> which could be used to enable this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-5852) Add ability to assign parties to Schema tasks

2016-11-28 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15703960#comment-15703960
 ] 

Paul Foxworthy commented on OFBIZ-5852:
---

Thanks Pierre, I have created OFBIZ-9134 to track this.

> Add ability to assign parties to Schema tasks
> -
>
> Key: OFBIZ-5852
> URL: https://issues.apache.org/jira/browse/OFBIZ-5852
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Pranay Pandey
> Fix For: 16.11.01
>
> Attachments: OFBIZ-5852.patch
>
>
> Currently it is not possible to assign parties to routing tasks. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (OFBIZ-9134) Add required skills to Routing Tasks

2016-11-28 Thread Paul Foxworthy (JIRA)
Paul Foxworthy created OFBIZ-9134:
-

 Summary: Add required skills to Routing Tasks
 Key: OFBIZ-9134
 URL: https://issues.apache.org/jira/browse/OFBIZ-9134
 Project: OFBiz
  Issue Type: Improvement
  Components: manufacturing
Affects Versions: Trunk
Reporter: Paul Foxworthy
Priority: Minor


OFBIZ-5852 enables you to add a Party to a Routing Task (the 
WorkEffortFixedAssetStd entity), to specify a person who is preferred to 
perform the task.

If the person is on leave of unavailable, the production manager would have to 
manually specify a different person.

It would be better to specify skill or skills required for the Routing Task. 
Then on each production run, any Party with the right skills could be scheduled 
to perform the task.

There are already entities WorkEffortSkillStandard, PartySkill and SkillType  
which could be used to enable this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-9128) Document current possiblities of the EntityAutoEngine

2016-11-27 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15701227#comment-15701227
 ] 

Paul Foxworthy commented on OFBIZ-9128:
---

OK, I've added something to the 
[https://cwiki.apache.org/confluence/display/OFBIZ/Service+Engine+Guide Service 
Engine Guide]. Please review.

> Document current possiblities of the EntityAutoEngine
> -
>
> Key: OFBIZ-9128
> URL: https://issues.apache.org/jira/browse/OFBIZ-9128
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: Confluence, framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Release
>
>
> As explained [~paul_foxworthy] [in this 
> comment|https://issues.apache.org/jira/browse/OFBIZ-9117?focusedCommentId=15672946=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15672946]
> {quote}
> I don't expect entity-auto to handle every possible situation. I'd suggest we 
> keep it simple and 80-20 rather than fiddle with it forever.
> There's an error message if you try to push it too hard which lists what it 
> can do:
> "1. a single OUT pk for primary auto-sequencing, " +
> "2. a single INOUT pk for primary auto-sequencing with optional override, " +
> "3. a 2-part pk with one part IN (existing primary pk) and one part OUT (the 
> secondary pk to sub-sequence), " +
> "4. a N-part pk with N-1 part IN and one party OUT only (missing pk is a 
> sub-sequence mainly for entity assoc), " +
> "5. all pk fields are IN for a manually specified primary key");
> So it can deliver one new id in an out parameter, but not more than one. I 
> can live with that. For more complex situations, we can write a service 
> rather than use entity auto.
> {quote}
> I suggest we document it in services.xsd and the [Service Engine 
> Guide|https://cwiki.apache.org/confluence/display/OFBIZ/Service+Engine+Guide],
>  explaining what the possiblities are based on the message above. BTW I had a 
> look at services.xsd and it's not yet documented enough.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-5761) Allow to edit ship groups contents after and order has been created

2016-11-27 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15701192#comment-15701192
 ] 

Paul Foxworthy commented on OFBIZ-5761:
---

Hi Sharad,

Agreed, OrderStatus tracks that an OrderItem was cancelled. So if we add a 
status flag to OISGA to allow for it to be cancelled, that would cover most 
requirements.

OrderStatus doesn't track the history of revisions to ship groups for an 
OrderItem. I think most of us most of the time don't need to know that history, 
so I suggest we don't worry about OISGA history until someone has a need for it.

> Allow to edit ship groups contents after and order has been created
> ---
>
> Key: OFBIZ-5761
> URL: https://issues.apache.org/jira/browse/OFBIZ-5761
> Project: OFBiz
>  Issue Type: Improvement
>  Components: order
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01
>
> Attachments: OFBIZ-5761 - OISG Management.patch, OFBIZ-5761 - OISG 
> Management.patch, OFBIZ-5761 - OISG Management.patch, OFBIZ-5761 - OISG 
> Management.patch, OFBIZ-5761 - OISG Management.patch, OFBIZ-5761 - OISG 
> Management.patch, OFBIZ-5761 - OISG Management.patch.change, OFBIZ-5761 - 
> OISG Management.patch.diff, OFBIZ-5761 - OISG Management.patch.diff, 
> OFBIZ-5761.patch.diff
>
>
> Currently you can only move order items between ship groups while you create 
> an order. I needed to do it after order creation. When I met Olivier (Heintz) 
> at the RMLL 2014 in July, I found the Neogia team has developed a such 
> feature and had it as an addon (named oisg-management) for R12.04. Then 
> exchanging with Nicolas (Malin), and Pierre (Gaudin) I decided to give it a 
> go. I will quickly explain the following history, for the Neogia team to know 
> the current situation and what has changed. 
> After updating the code to work with current trunk (instead of R12.04) I 
> found it was working well but some minor issues. I then exchanged with Leila 
> (Mekika) from the Neogia team and we could quickly fix the minor issues:
> * text harcoded, no labels. I began to fix them, thanks to Leila who 
> completed the major part and explained me some tricks about the 
> oisg-management addon.
> * A redundant button associated with the new addOrderItemShipGroup service.  
> I removed it because the current button calls createOrderItemShipGroup which 
> is enough. We could BTW consider using addOrderItemShipGroup instead. It's 
> more complete (see below for instance) but that"s rather a matter of taste.
> There was a mechanism to merge sales taxes to get them grouped by ship groups 
> in order adjustments. I removed it because this can be done dynamically (see 
> invoice.pdf) and it was removing the shipGroupSeqId from the order 
> adjustments.
> I sorted (DESC) the OrderItemShipGroup in addOrderItemShipGroup in order to 
> use the 1st ship group when copying shipmentMethodTypeId, carrierPartyId, 
> carrierRoleTypeId, contactMechId when shipmentMethodTypeId and carrierPartyId 
> are not passed to the service.
> I later fixed a bug I found in loadCartForUpdate service when removing the 
> adjustments. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-9128) Document current possiblities of the EntityAutoEngine

2016-11-27 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15700533#comment-15700533
 ] 

Paul Foxworthy commented on OFBIZ-9128:
---

Variation 3 in the list of auto-engine capabilities is a special case of number 
4. It might make sense to treat 2 part keys differently from 3-or=more part 
keys in the code, but documentation can leave out case 3 altogether.

I suggest the XSD should have a brief reference to the Service Engine Guide, 
and should not duplicate documentation elsewhere.

> Document current possiblities of the EntityAutoEngine
> -
>
> Key: OFBIZ-9128
> URL: https://issues.apache.org/jira/browse/OFBIZ-9128
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: Confluence, framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Release
>
>
> As explained [~paul_foxworthy] [in this 
> comment|https://issues.apache.org/jira/browse/OFBIZ-9117?focusedCommentId=15672946=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15672946]
> {quote}
> I don't expect entity-auto to handle every possible situation. I'd suggest we 
> keep it simple and 80-20 rather than fiddle with it forever.
> There's an error message if you try to push it too hard which lists what it 
> can do:
> "1. a single OUT pk for primary auto-sequencing, " +
> "2. a single INOUT pk for primary auto-sequencing with optional override, " +
> "3. a 2-part pk with one part IN (existing primary pk) and one part OUT (the 
> secondary pk to sub-sequence), " +
> "4. a N-part pk with N-1 part IN and one party OUT only (missing pk is a 
> sub-sequence mainly for entity assoc), " +
> "5. all pk fields are IN for a manually specified primary key");
> So it can deliver one new id in an out parameter, but not more than one. I 
> can live with that. For more complex situations, we can write a service 
> rather than use entity auto.
> {quote}
> I suggest we document it in services.xsd and the [Service Engine 
> Guide|https://cwiki.apache.org/confluence/display/OFBIZ/Service+Engine+Guide],
>  explaining what the possiblities are based on the message above. BTW I had a 
> look at services.xsd and it's not yet documented enough.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-5852) Add ability to assign parties to Schema tasks

2016-11-24 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15694938#comment-15694938
 ] 

Paul Foxworthy commented on OFBIZ-5852:
---

Hi all,

I know I've missed the boat here, however...

In a slightly larger organization, there may not be one specific person who 
might perform the task.

When you define the task, you might specify the skill or skills required. Then 
for different runs, different people who have the skills might be assigned.

There are already PartySkill and SkillType entities in OFBiz. Could we use them 
here?

> Add ability to assign parties to Schema tasks
> -
>
> Key: OFBIZ-5852
> URL: https://issues.apache.org/jira/browse/OFBIZ-5852
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Pranay Pandey
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-5852.patch
>
>
> Currently it is not possible to assign parties to routing tasks. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-7725) Document the routing number fields in entities

2016-11-24 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15694228#comment-15694228
 ] 

Paul Foxworthy commented on OFBIZ-7725:
---

OK, created OFBIZ-9127

>  Document the routing number fields in entities
> ---
>
> Key: OFBIZ-7725
> URL: https://issues.apache.org/jira/browse/OFBIZ-7725
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting
>Affects Versions: Upcoming Branch
>Reporter: Swapnil Shah
>Assignee: Jacques Le Roux
>Priority: Trivial
> Fix For: Upcoming Branch
>
>
> Let's extend EftAccount by adding 'BranchCode' that could indicate the branch 
> code of the Bank through which Eft Account is linked, It could be allowed to 
> optionally set for any existing and new EftAccount in Ofbiz system.
> Let's ask for 'Branch Code' with other details while Eft Account is being 
> added/edited from UI (e..g Party >> Profile etc.).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (OFBIZ-9127) Internationalise descriptions of entity attributes

2016-11-24 Thread Paul Foxworthy (JIRA)
Paul Foxworthy created OFBIZ-9127:
-

 Summary: Internationalise descriptions of entity attributes
 Key: OFBIZ-9127
 URL: https://issues.apache.org/jira/browse/OFBIZ-9127
 Project: OFBiz
  Issue Type: Improvement
  Components: framework, framework/webtools
Affects Versions: Trunk
Reporter: Paul Foxworthy
Priority: Minor


Entities have titles, and fields within them have descriptions.

These are only defined in English.

Web Tools allows you to browse entity definitions. It should present names and 
descriptions in a localised language.

I propose
- the *name* attribute of  and *description* attribute of  
remain as-is for backward compatibility and as a default value if localised 
text is not available for a language.
- A new optional attribute for  and for , each of which contain 
a key for a resource property, much like the keys for text in widgets. Names 
might be *nameKey* and *descriptionKey*
- XML property files with localised values for different languages



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-7725) Document the routing number fields in entities

2016-11-24 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15694200#comment-15694200
 ] 

Paul Foxworthy commented on OFBIZ-7725:
---

I was talking about your suggestion that "explanations on how to do it in 
OFBiz" should be in the XML definition of the entity. I still think that's not 
the right place for procedural documentation :-).

>  Document the routing number fields in entities
> ---
>
> Key: OFBIZ-7725
> URL: https://issues.apache.org/jira/browse/OFBIZ-7725
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting
>Affects Versions: Upcoming Branch
>Reporter: Swapnil Shah
>Assignee: Jacques Le Roux
>Priority: Trivial
> Fix For: Upcoming Branch
>
>
> Let's extend EftAccount by adding 'BranchCode' that could indicate the branch 
> code of the Bank through which Eft Account is linked, It could be allowed to 
> optionally set for any existing and new EftAccount in Ofbiz system.
> Let's ask for 'Branch Code' with other details while Eft Account is being 
> added/edited from UI (e..g Party >> Profile etc.).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-7725) Document the routing number fields in entities

2016-11-24 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-7725:
--
Summary:  Document the routing number fields in entities  (was:  Document 
the rounting number fields in entities)

>  Document the routing number fields in entities
> ---
>
> Key: OFBIZ-7725
> URL: https://issues.apache.org/jira/browse/OFBIZ-7725
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting
>Affects Versions: Upcoming Branch
>Reporter: Swapnil Shah
>Assignee: Jacques Le Roux
>Priority: Trivial
> Fix For: Upcoming Branch
>
>
> Let's extend EftAccount by adding 'BranchCode' that could indicate the branch 
> code of the Bank through which Eft Account is linked, It could be allowed to 
> optionally set for any existing and new EftAccount in Ofbiz system.
> Let's ask for 'Branch Code' with other details while Eft Account is being 
> added/edited from UI (e..g Party >> Profile etc.).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-7725) Document the rounting number fields in entities

2016-11-23 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15691829#comment-15691829
 ] 

Paul Foxworthy commented on OFBIZ-7725:
---

Thanks Jacques,

What you've done in the descriptions is fine by me. It was "explanations" I 
didn't like. Knowledge of how to use the routingNumber is as important (maybe 
more so) for business analysts and owners as well as developers.

There is an internationalisation issue with descriptions too. It should be 
possible to see descriptions in the Web Tools in languages other than English.

Cheers

Paul

> Document the rounting number fields in entities
> ---
>
> Key: OFBIZ-7725
> URL: https://issues.apache.org/jira/browse/OFBIZ-7725
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting
>Affects Versions: Upcoming Branch
>Reporter: Swapnil Shah
>Assignee: Jacques Le Roux
>Priority: Trivial
> Fix For: Upcoming Branch
>
>
> Let's extend EftAccount by adding 'BranchCode' that could indicate the branch 
> code of the Bank through which Eft Account is linked, It could be allowed to 
> optionally set for any existing and new EftAccount in Ofbiz system.
> Let's ask for 'Branch Code' with other details while Eft Account is being 
> added/edited from UI (e..g Party >> Profile etc.).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-7263) Price rule created with product specific quantity condition not applied to the order when adding the product to cart with less quantity than mentioned in condition

2016-11-23 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15691777#comment-15691777
 ] 

Paul Foxworthy commented on OFBIZ-7263:
---

Hi Aditi,

Good work, I think you've found a bug.

Compare the code in ShoppingCartServices with the updateApprovedOrderItems 
method in OrderServices:

https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/order/src/main/java/org/apache/ofbiz/order/order/OrderServices.java?r=1768192#to3712

in particular, lines 3712 and 3740.

If I understand the code correctly, isModified should say there has been human 
intervention to set a one-off price for this order that is different to the 
standard rules. Adjusting a quantity should *not* change the value of 
isModified.

Can you create a patch for your change?

Thanks

Paul



> Price rule created with product specific quantity condition not applied to 
> the order when adding the product to cart with less quantity than mentioned 
> in condition
> ---
>
> Key: OFBIZ-7263
> URL: https://issues.apache.org/jira/browse/OFBIZ-7263
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Trunk
>Reporter: Aditi Patidar
>Assignee: Aditi Patidar
>
> Steps to regenerate the issue:
> 1. Create a price rule.
> 2. Add a condition, select input 'Quantity', operator 'Is' and add the value 
> '2' or any quantity more than 1.
> 3. Add an action, select action type 'Flat Amount Override'  and add it's 
> value.  
> 4. Create a sale order:
> i. Add product with quantity one to the order.
> ii. Update the quantity to 2 or to the value entered in condition for 
> quantity in price rule.
>iii. Recalculate the order.
> Expected result: Unit price should override to the amount added in action.
> Actual result: It's not getting overridden to the amount added in action.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-5761) Allow to edit ship groups contents after and order has been created

2016-11-23 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15691484#comment-15691484
 ] 

Paul Foxworthy commented on OFBIZ-5761:
---

Wow. Sharad, a lightbulb moment. You are right.

As you know, it's rare to delete things in OFBiz. Rather, we expire them. For 
many entities, that means setting a thruDate.

It seems to me OISGA tracks the current live state of the association, e.g 
updateOrderItemShipGroupAssoc modifies OISGA records.

But OrderItemShipGroupAssoc has an attribute cancelQuantity. This seems strange 
if the entity is supposed to just hold the current live state of the 
association.

I wonder if the answer is to have a second entity that tracks the history of 
changes to an OISGA. The same model is used for inventory, where InventoryItem 
has the current live state, and InventoryItemDetail has the history of changes. 
So when you add inventory, there's a new IID created, and an II modified.

So a new "OISGA Detail" or "OISGA History" entity might solve the problem you 
describe. 

So if an order item is cancelled, the OISGA would be modified to quanity zero 
and a Cancelled status, but it would not be deleted. The new history entity 
would have a series of records for changes to the association. Typically, there 
would be a history record when the association to the ship group was defined, 
and a second when the order item was cancelled.

What do you think?

> Allow to edit ship groups contents after and order has been created
> ---
>
> Key: OFBIZ-5761
> URL: https://issues.apache.org/jira/browse/OFBIZ-5761
> Project: OFBiz
>  Issue Type: Improvement
>  Components: order
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01
>
> Attachments: OFBIZ-5761 - OISG Management.patch, OFBIZ-5761 - OISG 
> Management.patch, OFBIZ-5761 - OISG Management.patch, OFBIZ-5761 - OISG 
> Management.patch, OFBIZ-5761 - OISG Management.patch, OFBIZ-5761 - OISG 
> Management.patch, OFBIZ-5761 - OISG Management.patch.change, OFBIZ-5761 - 
> OISG Management.patch.diff, OFBIZ-5761 - OISG Management.patch.diff, 
> OFBIZ-5761.patch.diff
>
>
> Currently you can only move order items between ship groups while you create 
> an order. I needed to do it after order creation. When I met Olivier (Heintz) 
> at the RMLL 2014 in July, I found the Neogia team has developed a such 
> feature and had it as an addon (named oisg-management) for R12.04. Then 
> exchanging with Nicolas (Malin), and Pierre (Gaudin) I decided to give it a 
> go. I will quickly explain the following history, for the Neogia team to know 
> the current situation and what has changed. 
> After updating the code to work with current trunk (instead of R12.04) I 
> found it was working well but some minor issues. I then exchanged with Leila 
> (Mekika) from the Neogia team and we could quickly fix the minor issues:
> * text harcoded, no labels. I began to fix them, thanks to Leila who 
> completed the major part and explained me some tricks about the 
> oisg-management addon.
> * A redundant button associated with the new addOrderItemShipGroup service.  
> I removed it because the current button calls createOrderItemShipGroup which 
> is enough. We could BTW consider using addOrderItemShipGroup instead. It's 
> more complete (see below for instance) but that"s rather a matter of taste.
> There was a mechanism to merge sales taxes to get them grouped by ship groups 
> in order adjustments. I removed it because this can be done dynamically (see 
> invoice.pdf) and it was removing the shipGroupSeqId from the order 
> adjustments.
> I sorted (DESC) the OrderItemShipGroup in addOrderItemShipGroup in order to 
> use the 1st ship group when copying shipmentMethodTypeId, carrierPartyId, 
> carrierRoleTypeId, contactMechId when shipmentMethodTypeId and carrierPartyId 
> are not passed to the service.
> I later fixed a bug I found in loadCartForUpdate service when removing the 
> adjustments. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-7073) Add WebSocket support in OFBiz

2016-11-22 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15689255#comment-15689255
 ] 

Paul Foxworthy commented on OFBIZ-7073:
---

Good! Thanks Jacques.

> Add WebSocket support in OFBiz
> --
>
> Key: OFBIZ-7073
> URL: https://issues.apache.org/jira/browse/OFBIZ-7073
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Amardeep Singh Jhajj
>Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7073.patch, OFBIZ-7073.patch, 
> tomcat-embed-websocket-8.0.33.jar
>
>
> I tried to use websockets in OFBiz. I simply added tomcat-embed-websocket.jar 
> in catalina lib and created one webapp for websocket and also added server 
> endpoint class.
> It didn't work. After that, I tried the same thing with plain j2ee 
> application with embedded tomcat. It worked there.
> I researched on above issue in OFBiz and got the reason. Websockets 
> implementation need jar scanning enabled and it is currently disabled in 
> OFBiz. Below is the code snippet of disabling jar scan from 
> CatalinaContainer.java:
> {code}
> JarScanner jarScanner = context.getJarScanner();
> if (jarScanner instanceof StandardJarScanner) {
> StandardJarScanner standardJarScanner = (StandardJarScanner) jarScanner;
> standardJarScanner.setScanClassPath(false);
> }
> {code}
> Jar scanning enabling increase OFBiz server startup time upto couples of 
> minutes (in my case, it took approx 8 minutes), so we don't want this much of 
> startup time for OFBiz.
>  
> I got the following document where I found the reason why websocket is not 
> working if scanning disabled.
> https://wiki.apache.org/tomcat/HowTo/FasterStartUp
> Here tips are given to decrease the startup time. This tips also include 
> disabling of jar scanning. 
> We can say disabling jar scanning is right approach because if we enable it 
> then scanner will scan all the jars loaded in OFBiz startup that we don't 
> want.
> But, If we want websockets working then we have to enable jar scanning.
> For enabling jar scanning, we need below code:
> {code}
> standardJarScanner.setScanClassPath(true); // Will increase server startup 
> time.
> {code}
> Solution: We can add filter on jar scanning. It will allow only some kind of 
> jars only. For example: jars having websockets endpoints. I am attaching 
> patch for the same here.
> I added filter like if jar name string contains "discoverable" word then only 
> it will be considered for jar scan. We can change jar name of our jars using 
> build.xml to make it discoverable for jar scanning.
> For example: I have added my websocket endpoint class in 
> "specialpurpose/ecommerce/src" and changed the "name" property in build.xml 
> of ecommerce component from "ofbiz-ecommerce"
> to "ofbiz-ecommerce-discoverable". Here is the code snippet from build.xml:
> {code}
> 
> {code}
> This change will create the jar with name "ofbiz-ecommerce-discoverable.jar" 
> in "ecommerce/build/lib/".
> Now created jar will be scanned in jar scanner as its name contains 
> "discoverable" word in it.
> This change will not increase server start up time more than couple of 
> seconds (in my case, it just two seconds). So scanning time totally depends 
> on the list of jars scanned.
> Conclusion: We can use websocket support with the help of jar filters.
> I am also attaching the version 8.0.33 tomcat-embed-websocket.jar.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-7714) Introduce a quick way for adding Purchase Price agreements with Suppliers for any specific product from Catalog

2016-11-22 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15689052#comment-15689052
 ] 

Paul Foxworthy commented on OFBIZ-7714:
---

Hi Swapnil,

OK, if buyers have the permissions that's fine. Also fine to have a Create 
Agreement button while looking at a product, something like the Edit Agreement 
that's already there.

Would it be a new screen different from the Create Agreement in the Accounting 
application?

Thanks

Paul

> Introduce a quick way for adding Purchase Price agreements with Suppliers for 
> any specific product from Catalog
> ---
>
> Key: OFBIZ-7714
> URL: https://issues.apache.org/jira/browse/OFBIZ-7714
> Project: OFBiz
>  Issue Type: New Feature
>  Components: product
>Affects Versions: 14.12.01, 15.12.01
>Reporter: Swapnil Shah
>Assignee: Swapnil Shah
> Attachments: PPA.png
>
>
> Currently new pricing agreements creation takes user to Accounting app where 
> it is quite an long and arduous process. And many a times a buyer or 
> procurement users doesn't have direct accounting permission in case quick 
> pricing agreement needs to be placed with Supplier for specific product(s).
> We can provide a quick option from Catalog >> Product >> Agreement screen 
> over "Purchase" section that could unfold as follows:
> # Have a 'Create Price Agreement' link/button on the 'Purchases' Panel and 
> hitting this link could ask user to enter following very basic parameters:
> #- Party Id From (Default it to facility's owner party id)
> #- Party Id To (show list of suppliers like we show at the time of Purchase 
> Order entry screen)
> #- From Date (default it to show as now() timestamp)
> #- Through Date
> #- Description
> #- Price
> #- Currency
> #- Supplier Product Id
> # Upon successful submission of above details system should create Agreement 
> and AgreementItem & SupplierProduct between Supplier and organization by 
> passing following default values:
> #- Role Type Id From = 'Internal Organization'
> #- Role Type Id To = ''Supplier"
> #- Agreement Type Id = 'Purchase'
> #- Agreement Item Type Id = 'Pricing'
> #- Product Id= ''
> Please refer to attached screenshot for reference placeholder
> !PPA.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (OFBIZ-7073) Add WebSocket support in OFBiz

2016-11-22 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15688892#comment-15688892
 ] 

Paul Foxworthy edited comment on OFBIZ-7073 at 11/23/16 4:39 AM:
-

I'm really uncomfortable with adding metadata to the name of a jar. If there 
are three other characteristics we want to selectively enable, would we have 
jars named
{noformat}
 -discoverable--.jar
{noformat}? 

Do I need to customise the standard Gradle build file to enable WebSockets?

Since we're overriding the check method and we can put whatever code we like 
there, could we read a setting out a properties file instead of embedding it in 
the name of the jar?


was (Author: paul_foxworthy):
I'm really uncomfortable with adding metadata to the name of a jar. If there 
are three other characteristics we want to selectively enable, would we have 
jars named -discoverable--.jar? Do I need to 
customise the standard Gradle build file to enable WebSockets?

Since we're overriding the check method and we can put whatever code we like 
there, could we read a setting out a properties file instead of embedding it in 
the name of the jar?

> Add WebSocket support in OFBiz
> --
>
> Key: OFBIZ-7073
> URL: https://issues.apache.org/jira/browse/OFBIZ-7073
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Amardeep Singh Jhajj
>Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7073.patch, OFBIZ-7073.patch, 
> tomcat-embed-websocket-8.0.33.jar
>
>
> I tried to use websockets in OFBiz. I simply added tomcat-embed-websocket.jar 
> in catalina lib and created one webapp for websocket and also added server 
> endpoint class.
> It didn't work. After that, I tried the same thing with plain j2ee 
> application with embedded tomcat. It worked there.
> I researched on above issue in OFBiz and got the reason. Websockets 
> implementation need jar scanning enabled and it is currently disabled in 
> OFBiz. Below is the code snippet of disabling jar scan from 
> CatalinaContainer.java:
> {code}
> JarScanner jarScanner = context.getJarScanner();
> if (jarScanner instanceof StandardJarScanner) {
> StandardJarScanner standardJarScanner = (StandardJarScanner) jarScanner;
> standardJarScanner.setScanClassPath(false);
> }
> {code}
> Jar scanning enabling increase OFBiz server startup time upto couples of 
> minutes (in my case, it took approx 8 minutes), so we don't want this much of 
> startup time for OFBiz.
>  
> I got the following document where I found the reason why websocket is not 
> working if scanning disabled.
> https://wiki.apache.org/tomcat/HowTo/FasterStartUp
> Here tips are given to decrease the startup time. This tips also include 
> disabling of jar scanning. 
> We can say disabling jar scanning is right approach because if we enable it 
> then scanner will scan all the jars loaded in OFBiz startup that we don't 
> want.
> But, If we want websockets working then we have to enable jar scanning.
> For enabling jar scanning, we need below code:
> {code}
> standardJarScanner.setScanClassPath(true); // Will increase server startup 
> time.
> {code}
> Solution: We can add filter on jar scanning. It will allow only some kind of 
> jars only. For example: jars having websockets endpoints. I am attaching 
> patch for the same here.
> I added filter like if jar name string contains "discoverable" word then only 
> it will be considered for jar scan. We can change jar name of our jars using 
> build.xml to make it discoverable for jar scanning.
> For example: I have added my websocket endpoint class in 
> "specialpurpose/ecommerce/src" and changed the "name" property in build.xml 
> of ecommerce component from "ofbiz-ecommerce"
> to "ofbiz-ecommerce-discoverable". Here is the code snippet from build.xml:
> {code}
> 
> {code}
> This change will create the jar with name "ofbiz-ecommerce-discoverable.jar" 
> in "ecommerce/build/lib/".
> Now created jar will be scanned in jar scanner as its name contains 
> "discoverable" word in it.
> This change will not increase server start up time more than couple of 
> seconds (in my case, it just two seconds). So scanning time totally depends 
> on the list of jars scanned.
> Conclusion: We can use websocket support with the help of jar filters.
> I am also attaching the version 8.0.33 tomcat-embed-websocket.jar.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-7073) Add WebSocket support in OFBiz

2016-11-22 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15688892#comment-15688892
 ] 

Paul Foxworthy commented on OFBIZ-7073:
---

I'm really uncomfortable with adding metadata to the name of a jar. If there 
are three other characteristics we want to selectively enable, would we have 
jars named -discoverable--.jar? Do I need to 
customise the standard Gradle build file to enable WebSockets?

Since we're overriding the check method and we can put whatever code we like 
there, could we read a setting out a properties file instead of embedding it in 
the name of the jar?

> Add WebSocket support in OFBiz
> --
>
> Key: OFBIZ-7073
> URL: https://issues.apache.org/jira/browse/OFBIZ-7073
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
>Reporter: Amardeep Singh Jhajj
>Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7073.patch, OFBIZ-7073.patch, 
> tomcat-embed-websocket-8.0.33.jar
>
>
> I tried to use websockets in OFBiz. I simply added tomcat-embed-websocket.jar 
> in catalina lib and created one webapp for websocket and also added server 
> endpoint class.
> It didn't work. After that, I tried the same thing with plain j2ee 
> application with embedded tomcat. It worked there.
> I researched on above issue in OFBiz and got the reason. Websockets 
> implementation need jar scanning enabled and it is currently disabled in 
> OFBiz. Below is the code snippet of disabling jar scan from 
> CatalinaContainer.java:
> {code}
> JarScanner jarScanner = context.getJarScanner();
> if (jarScanner instanceof StandardJarScanner) {
> StandardJarScanner standardJarScanner = (StandardJarScanner) jarScanner;
> standardJarScanner.setScanClassPath(false);
> }
> {code}
> Jar scanning enabling increase OFBiz server startup time upto couples of 
> minutes (in my case, it took approx 8 minutes), so we don't want this much of 
> startup time for OFBiz.
>  
> I got the following document where I found the reason why websocket is not 
> working if scanning disabled.
> https://wiki.apache.org/tomcat/HowTo/FasterStartUp
> Here tips are given to decrease the startup time. This tips also include 
> disabling of jar scanning. 
> We can say disabling jar scanning is right approach because if we enable it 
> then scanner will scan all the jars loaded in OFBiz startup that we don't 
> want.
> But, If we want websockets working then we have to enable jar scanning.
> For enabling jar scanning, we need below code:
> {code}
> standardJarScanner.setScanClassPath(true); // Will increase server startup 
> time.
> {code}
> Solution: We can add filter on jar scanning. It will allow only some kind of 
> jars only. For example: jars having websockets endpoints. I am attaching 
> patch for the same here.
> I added filter like if jar name string contains "discoverable" word then only 
> it will be considered for jar scan. We can change jar name of our jars using 
> build.xml to make it discoverable for jar scanning.
> For example: I have added my websocket endpoint class in 
> "specialpurpose/ecommerce/src" and changed the "name" property in build.xml 
> of ecommerce component from "ofbiz-ecommerce"
> to "ofbiz-ecommerce-discoverable". Here is the code snippet from build.xml:
> {code}
> 
> {code}
> This change will create the jar with name "ofbiz-ecommerce-discoverable.jar" 
> in "ecommerce/build/lib/".
> Now created jar will be scanned in jar scanner as its name contains 
> "discoverable" word in it.
> This change will not increase server start up time more than couple of 
> seconds (in my case, it just two seconds). So scanning time totally depends 
> on the list of jars scanned.
> Conclusion: We can use websocket support with the help of jar filters.
> I am also attaching the version 8.0.33 tomcat-embed-websocket.jar.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-6807) UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema with publicId [null] and the file/resource is [web-app_3_0.xsd]

2016-11-22 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15688726#comment-15688726
 ] 

Paul Foxworthy commented on OFBIZ-6807:
---

schemaLocation and noNamespaceSchemaLocation are hacks. It is silly to expect 
an XML document to know the right place for its schema. So its good that you 
removed schemaLocation from the webapp files.

However, there are still thousands of noNamespaceSchemaLocation in other XML 
files.

What the XML files *should* have is a namespace. Then external tools can map 
from the namespace to a catalogue of schemas to validate elements within those 
namespaces.

I suspect the noNamespaceSchemaLocation attributes are there because people 
were used to SGML and SGML-like documents (including HTML) having a DOCTYPE 
that refers to a location for a DTD. With experience, that has turned out to be 
a mistake - note in HTML5 you just say "it's HTML", no mention of a DTD.

So if you're doing anything to improve XML files, I suggest you include a 
namespace instead of schemaLocation and noNamespaceSchemaLocation. XML 
validators and IDEs like IntelliJ IDEA and Eclipse can find the right schema 
based on the namespace.

> UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema with 
> publicId [null] and the file/resource is [web-app_3_0.xsd]
> 
>
> Key: OFBIZ-6807
> URL: https://issues.apache.org/jira/browse/OFBIZ-6807
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Release Branch 14.12, Trunk, Release Branch 15.12
>Reporter: Deepak Dixit
>Assignee: Jacques Le Roux
>Priority: Trivial
>
> System throws following exception on server start:
> {code}
> [java] 2016-01-16 15:04:50,942 |catalina-startup-2   |UtilXml 
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL 
> DTD/Schema with publicId [null] and the file/resource is [web-app_3_0.xsd]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-7714) Introduce a quick way for adding Purchase Price agreements with Suppliers for any specific product from Catalog

2016-11-22 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15688391#comment-15688391
 ] 

Paul Foxworthy commented on OFBIZ-7714:
---

There are several issues here that need careful consideration.

If the user interface for creating an Agreement is long and arduous, let's 
review that. I think it's no big deal that you need to navigate into the 
Accounting application.

If a user does not have permission to create an Agreement, they should not be 
able to do so. Full stop. This is a matter of governance, not just convenience. 
I think the scenario you're talking about suggests a need for more limited 
permissions for staff to create Agreements. I can envisage permissions:
- to lower a price from a supplier but not increase it
- to offer a discount to customers for some products in some categories with 
limits (not below cost, etc)

The feel here is something like pricing rules. There are many factors that 
might constrain the Agreements a staff member is authorised to enter into.

So it will be tricky to really address well the scenario you describe. Allowing 
a sneaky way to bypass accounting permissions is not the answer.





> Introduce a quick way for adding Purchase Price agreements with Suppliers for 
> any specific product from Catalog
> ---
>
> Key: OFBIZ-7714
> URL: https://issues.apache.org/jira/browse/OFBIZ-7714
> Project: OFBiz
>  Issue Type: New Feature
>  Components: product
>Affects Versions: 14.12.01, 15.12.01
>Reporter: Swapnil Shah
>Assignee: Swapnil Shah
> Attachments: PPA.png
>
>
> Currently new pricing agreements creation takes user to Accounting app where 
> it is quite an long and arduous process. And many a times a buyer or 
> procurement users doesn't have direct accounting permission in case quick 
> pricing agreement needs to be placed with Supplier for specific product(s).
> We can provide a quick option from Catalog >> Product >> Agreement screen 
> over "Purchase" section that could unfold as follows:
> # Have a 'Create Price Agreement' link/button on the 'Purchases' Panel and 
> hitting this link could ask user to enter following very basic parameters:
> #- Party Id From (Default it to facility's owner party id)
> #- Party Id To (show list of suppliers like we show at the time of Purchase 
> Order entry screen)
> #- From Date (default it to show as now() timestamp)
> #- Through Date
> #- Description
> #- Price
> #- Currency
> #- Supplier Product Id
> # Upon successful submission of above details system should create Agreement 
> and AgreementItem & SupplierProduct between Supplier and organization by 
> passing following default values:
> #- Role Type Id From = 'Internal Organization'
> #- Role Type Id To = ''Supplier"
> #- Agreement Type Id = 'Purchase'
> #- Agreement Item Type Id = 'Pricing'
> #- Product Id= ''
> Please refer to attached screenshot for reference placeholder
> !PPA.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-7004) Allow to accept CDATA

2016-11-20 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682553#comment-15682553
 ] 

Paul Foxworthy commented on OFBIZ-7004:
---

Probably way too late, but should location= be changed to src= , similar to 
HTML? The script element can have a src attribute, or embedded script. 
html-template might be easier to understand if it follows the same conventions.

> Allow  to accept CDATA
> -
>
> Key: OFBIZ-7004
> URL: https://issues.apache.org/jira/browse/OFBIZ-7004
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Trunk
>Reporter: james yong
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: OFBIZ-7004.patch, OFBIZ-7004.patch
>
>
> Currently, html-template tag accepts a location attribute.
> Propose that the html-template tag also accepts CDATA content.
> OFBiz will look for CDATA content if the location attribute is empty.
>   
> The advantage is that we need not create a .ftl file whenever we add some 
> html contents into the screen widget.
> I need some opinions before starting work on this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-9122) Check GeoData against 2016 updates for ISO region codes

2016-11-20 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-9122:
--
Summary: Check GeoData against 2016 updates for ISO region codes  (was: 
Review 2016 updates for ISO region codie)

> Check GeoData against 2016 updates for ISO region codes
> ---
>
> Key: OFBIZ-9122
> URL: https://issues.apache.org/jira/browse/OFBIZ-9122
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>Priority: Minor
>
> The International Organization for Standardization (ISO) has released an 
> update to its list of country and region codes
> Below is the list of links to the new codes for different countries.
> Please check the OFBiz Geo codes in the files GeoData_xx.xml in 
> framework/common/data 
> (https://fisheye6.atlassian.com/browse/ofbiz/trunk/framework/common/data)
> If any changes to GeoData are needed, attach a patch here or just go ahead 
> and commit the change, and add a comment here. Once you have completed the 
> review, move the line for a country from "TO REVIEW" below to "COMPLETED".
> Thanks in anticipation!
> TO REVIEW:
> AW /Aruba/
> BD  /Bangladesh/
> BF   /Burkina Faso/
> BR  /Brazil/
> BT  /Bhutan/
> CD /Congo (the Democratic 
> Republic of the)/
> CI    /Côte d'Ivoire/
> CL  /Chile/
> CO    /Colombia/
> CZ /Czechia/
> DJ  /Djibouti/
> DO   /Dominican Republic (the)/
> DZ /Algeria/
> ES /Spain/
> FI    /Finland/
> FJ  /Fiji/
> GD   /Grenada/
> GR   /Greece/
> ID    /Indonesia/
> IL    /Israel/
> IQ  /Iraq/
> KE    /Kenya/
> KG   /Kyrgyzstan/
> KH /Cambodia/
> KR /Korea (the Republic of)/
> KZ  /Kazakhstan/
> LA  /Lao People's 
> Democratic Republic (the)/
> MM    /Myanmar/
> MV /Maldives/
> MX  /Mexico/
> NA  /Namibia/
> PW /Palau/
> RW /Rwanda/
> SI  /Slovenia/
> TG  /Togo/
> TJ    /Tajikistan/
> TV  /Tuvalu/
> TW    /Taiwan (Province of 
> China)/
> UG /Uganda/
> YE  /Yemen/
> COMPLETED:
> AU   /Australia/
> FR    /France/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-9122) Review 2016 updates for ISO region codie

2016-11-20 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-9122:
--
Description: 
The International Organization for Standardization (ISO) has released an update 
to its list of country and region codes

Below is the list of links to the new codes for different countries.

Please check the OFBiz Geo codes in the files GeoData_xx.xml in 
framework/common/data 
(https://fisheye6.atlassian.com/browse/ofbiz/trunk/framework/common/data)

If any changes to GeoData are needed, attach a patch here or just go ahead and 
commit the change, and add a comment here. Once you have completed the review, 
move the line for a country from "TO REVIEW" below to "COMPLETED".

Thanks in anticipation!

TO REVIEW:

AW /Aruba/
BD  /Bangladesh/
BF   /Burkina Faso/
BR  /Brazil/
BT  /Bhutan/
CD /Congo (the Democratic 
Republic of the)/
CI    /Côte d'Ivoire/
CL  /Chile/
CO    /Colombia/
CZ /Czechia/
DJ  /Djibouti/
DO   /Dominican Republic (the)/
DZ /Algeria/
ES /Spain/
FI    /Finland/
FJ  /Fiji/
GD   /Grenada/
GR   /Greece/
ID    /Indonesia/
IL    /Israel/
IQ  /Iraq/
KE    /Kenya/
KG   /Kyrgyzstan/
KH /Cambodia/
KR /Korea (the Republic of)/
KZ  /Kazakhstan/
LA  /Lao People's Democratic 
Republic (the)/
MM    /Myanmar/
MV /Maldives/
MX  /Mexico/
NA  /Namibia/
PW /Palau/
RW /Rwanda/
SI  /Slovenia/
TG  /Togo/
TJ    /Tajikistan/
TV  /Tuvalu/
TW    /Taiwan (Province of China)/
UG /Uganda/
YE  /Yemen/

COMPLETED:
AU   /Australia/
FR    /France/


  was:
The International Organization for Standardization (ISO) has released an update 
to its list of country and region codes

Here is the list of links to the new codes for different countries.

AU   /Australia/
AW /Aruba/
BD  /Bangladesh/
BF   /Burkina Faso/
BR  /Brazil/
BT  /Bhutan/
CD /Congo (the Democratic 
Republic of the)/
CI    /Côte d'Ivoire/
CL  /Chile/
CO    /Colombia/
CZ /Czechia/
DJ  /Djibouti/
DO   /Dominican Republic (the)/
DZ /Algeria/
ES /Spain/
FI    /Finland/
FJ  /Fiji/
FR 

[jira] [Assigned] (OFBIZ-9122) Review 2016 updates for ISO region codie

2016-11-20 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-9122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy reassigned OFBIZ-9122:
-

Assignee: Paul Foxworthy

> Review 2016 updates for ISO region codie
> 
>
> Key: OFBIZ-9122
> URL: https://issues.apache.org/jira/browse/OFBIZ-9122
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>Priority: Minor
>
> The International Organization for Standardization (ISO) has released an 
> update to its list of country and region codes
> Here is the list of links to the new codes for different countries.
> AU   /Australia/
> AW /Aruba/
> BD  /Bangladesh/
> BF   /Burkina Faso/
> BR  /Brazil/
> BT  /Bhutan/
> CD /Congo (the Democratic 
> Republic of the)/
> CI    /Côte d'Ivoire/
> CL  /Chile/
> CO    /Colombia/
> CZ /Czechia/
> DJ  /Djibouti/
> DO   /Dominican Republic (the)/
> DZ /Algeria/
> ES /Spain/
> FI    /Finland/
> FJ  /Fiji/
> FR    /France/
> GD   /Grenada/
> GR   /Greece/
> ID    /Indonesia/
> IL    /Israel/
> IQ  /Iraq/
> KE    /Kenya/
> KG   /Kyrgyzstan/
> KH /Cambodia/
> KR /Korea (the Republic of)/
> KZ  /Kazakhstan/
> LA  /Lao People's 
> Democratic Republic (the)/
> MM    /Myanmar/
> MV /Maldives/
> MX  /Mexico/
> NA  /Namibia/
> PW /Palau/
> RW /Rwanda/
> SI  /Slovenia/
> TG  /Togo/
> TJ    /Tajikistan/
> TV  /Tuvalu/
> TW    /Taiwan (Province of 
> China)/
> UG /Uganda/
> YE  /Yemen/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (OFBIZ-9122) Review 2016 updates for ISO region codie

2016-11-20 Thread Paul Foxworthy (JIRA)
Paul Foxworthy created OFBIZ-9122:
-

 Summary: Review 2016 updates for ISO region codie
 Key: OFBIZ-9122
 URL: https://issues.apache.org/jira/browse/OFBIZ-9122
 Project: OFBiz
  Issue Type: Task
  Components: framework
Affects Versions: Trunk
Reporter: Paul Foxworthy
Priority: Minor


The International Organization for Standardization (ISO) has released an update 
to its list of country and region codes

Here is the list of links to the new codes for different countries.

AU   /Australia/
AW /Aruba/
BD  /Bangladesh/
BF   /Burkina Faso/
BR  /Brazil/
BT  /Bhutan/
CD /Congo (the Democratic 
Republic of the)/
CI    /Côte d'Ivoire/
CL  /Chile/
CO    /Colombia/
CZ /Czechia/
DJ  /Djibouti/
DO   /Dominican Republic (the)/
DZ /Algeria/
ES /Spain/
FI    /Finland/
FJ  /Fiji/
FR    /France/
GD   /Grenada/
GR   /Greece/
ID    /Indonesia/
IL    /Israel/
IQ  /Iraq/
KE    /Kenya/
KG   /Kyrgyzstan/
KH /Cambodia/
KR /Korea (the Republic of)/
KZ  /Kazakhstan/
LA  /Lao People's Democratic 
Republic (the)/
MM    /Myanmar/
MV /Maldives/
MX  /Mexico/
NA  /Namibia/
PW /Palau/
RW /Rwanda/
SI  /Slovenia/
TG  /Togo/
TJ    /Tajikistan/
TV  /Tuvalu/
TW    /Taiwan (Province of China)/
UG /Uganda/
YE  /Yemen/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-9117) EntityAuto engine override the passed service in parameters

2016-11-16 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15672977#comment-15672977
 ] 

Paul Foxworthy commented on OFBIZ-9117:
---

I'd argue that "OUT" line is a bug. It's at least misleading. It was in OFBiz 
when it became an Apache top level project, almost ten years ago :-)

> EntityAuto engine override the passed service in parameters
> ---
>
> Key: OFBIZ-9117
> URL: https://issues.apache.org/jira/browse/OFBIZ-9117
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Fix For: Upcoming Branch
>
> Attachments: errorlog.txt
>
>
> There is an bug in EntityAuto engine, it override the passed service in 
> parameters. 
> In createInvoiceForOrder service calls the createInvoiceContactMech to crate 
> invoice contactMech for PAYMENT_LOCATION purpose (at line no 357). In case of 
> SO it should use Company PAYMENT_LOCATION contactMech. It get the Company 
> contactMechId correctly and set it createInvoiceContactMech service in 
> context correctly, but system throws foreign key constraints error for 
> incorrect contactMechId. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-9117) EntityAuto engine override the passed service in parameters

2016-11-16 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15672946#comment-15672946
 ] 

Paul Foxworthy commented on OFBIZ-9117:
---

Thanks Deepak. Does that mean we can now use entity-auto in the case of 
createInvoiceContactMech?

I don't expect entity-auto to handle every possible situation. I'd suggest we 
keep it simple and 80-20 rather than fiddle with it forever.

There's an error message if you try to push it too hard which lists what it can 
do:

 "1. a single OUT pk for primary auto-sequencing, " +
"2. a single INOUT pk for primary auto-sequencing with optional override, " +
"3. a 2-part pk with one part IN (existing primary pk) and one part OUT (the 
secondary pk to sub-sequence), " +
"4. a N-part pk with N-1 part IN and one party OUT only (missing pk is a 
sub-sequence mainly for entity assoc), " +
"5. all pk fields are IN for a manually specified primary key");

So it can deliver one new id in an out parameter, but not more than one. I can 
live with that. For more complex situations, we can write a service rather than 
use entity auto.


> EntityAuto engine override the passed service in parameters
> ---
>
> Key: OFBIZ-9117
> URL: https://issues.apache.org/jira/browse/OFBIZ-9117
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Deepak Dixit
> Attachments: errorlog.txt
>
>
> There is an bug in EntityAuto engine, it override the passed service in 
> parameters. 
> In createInvoiceForOrder service calls the createInvoiceContactMech to crate 
> invoice contactMech for PAYMENT_LOCATION purpose (at line no 357). In case of 
> SO it should use Company PAYMENT_LOCATION contactMech. It get the Company 
> contactMechId correctly and set it createInvoiceContactMech service in 
> context correctly, but system throws foreign key constraints error for 
> incorrect contactMechId. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-9117) EntityAuto engine override the passed service in parameters

2016-11-16 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15672583#comment-15672583
 ] 

Paul Foxworthy commented on OFBIZ-9117:
---

Hi Deepak and Jacques,

I think the problem is in the definition of the createInvoiceContactMech 
Service:


Create a ContactMech for an invoice





Why the "OUT" on the contactMechId? The service should *not* be generating a 
new contactMechId, it's an input to associate an existing ContactMech with the 
invoice.

If we delete the line  , will everything then work? I think so.

> EntityAuto engine override the passed service in parameters
> ---
>
> Key: OFBIZ-9117
> URL: https://issues.apache.org/jira/browse/OFBIZ-9117
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Deepak Dixit
> Attachments: errorlog.txt
>
>
> There is an bug in EntityAuto engine, it override the passed service in 
> parameters. 
> In createInvoiceForOrder service calls the createInvoiceContactMech to crate 
> invoice contactMech for PAYMENT_LOCATION purpose (at line no 357). In case of 
> SO it should use Company PAYMENT_LOCATION contactMech. It get the Company 
> contactMechId correctly and set it createInvoiceContactMech service in 
> context correctly, but system throws foreign key constraints error for 
> incorrect contactMechId. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-7725) Extend EftAccount entity with 'branchCode' and provide necessary support in code and UI

2016-11-16 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15672056#comment-15672056
 ] 

Paul Foxworthy commented on OFBIZ-7725:
---

Can we close this issue? Or at least revise down the priority?

"Routing number" is the US terminology for the same idea. If that isn't 
meaningful for people in other locales, I suggest that the UI labels could be 
changed to a better description for that locale. In Australia, that would be 
BSB (Bank-State-Branch) .

Jacques, wouldn't this be better documented in the Business Setup Guide and the 
online help, rather than in the definition of the entity?



> Extend EftAccount entity with 'branchCode' and provide necessary support in 
> code and UI
> ---
>
> Key: OFBIZ-7725
> URL: https://issues.apache.org/jira/browse/OFBIZ-7725
> Project: OFBiz
>  Issue Type: New Feature
>  Components: accounting
>Affects Versions: Upcoming Branch
>Reporter: Swapnil Shah
>
> Let's extend EftAccount by adding 'BranchCode' that could indicate the branch 
> code of the Bank through which Eft Account is linked, It could be allowed to 
> optionally set for any existing and new EftAccount in Ofbiz system.
> Let's ask for 'Branch Code' with other details while Eft Account is being 
> added/edited from UI (e..g Party >> Profile etc.).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-9117) EntityAuto engine override the passed service in parameters

2016-11-14 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15666319#comment-15666319
 ] 

Paul Foxworthy commented on OFBIZ-9117:
---

Hi Deepak,

I understand now. Did the entity auto engine *create* ContactMech 10060, or did 
it already exist?

> EntityAuto engine override the passed service in parameters
> ---
>
> Key: OFBIZ-9117
> URL: https://issues.apache.org/jira/browse/OFBIZ-9117
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Deepak Dixit
> Attachments: errorlog.txt
>
>
> There is an bug in EntityAuto engine, it override the passed service in 
> parameters. 
> In createInvoiceForOrder service calls the createInvoiceContactMech to crate 
> invoice contactMech for PAYMENT_LOCATION purpose (at line no 357). In case of 
> SO it should use Company PAYMENT_LOCATION contactMech. It get the Company 
> contactMechId correctly and set it createInvoiceContactMech service in 
> context correctly, but system throws foreign key constraints error for 
> incorrect contactMechId. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-9117) EntityAuto engine override the passed service in parameters

2016-11-14 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15666164#comment-15666164
 ] 

Paul Foxworthy commented on OFBIZ-9117:
---

Are we getting the 10060 because it's creating a new ContactMech, rather than 
using 9001?

Is "create this new entity, but associate it with existing related entities" 
beyond the capabilities of entity auto engine?

> EntityAuto engine override the passed service in parameters
> ---
>
> Key: OFBIZ-9117
> URL: https://issues.apache.org/jira/browse/OFBIZ-9117
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Deepak Dixit
> Attachments: errorlog.txt
>
>
> There is an bug in EntityAuto engine, it override the passed service in 
> parameters. 
> In createInvoiceForOrder service calls the createInvoiceContactMech to crate 
> invoice contactMech for PAYMENT_LOCATION purpose (at line no 357). In case of 
> SO it should use Company PAYMENT_LOCATION contactMech. It get the Company 
> contactMechId correctly and set it createInvoiceContactMech service in 
> context correctly, but system throws foreign key constraints error for 
> incorrect contactMechId. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-9117) EntityAuto engine override the passed service in parameters

2016-11-14 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15666044#comment-15666044
 ] 

Paul Foxworthy commented on OFBIZ-9117:
---

Hi Deepak,

OK. Sorry, I don't understand the problem you've found. Could you explain it 
again?

Thanks

> EntityAuto engine override the passed service in parameters
> ---
>
> Key: OFBIZ-9117
> URL: https://issues.apache.org/jira/browse/OFBIZ-9117
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Deepak Dixit
> Attachments: errorlog.txt
>
>
> There is an bug in EntityAuto engine, it override the passed service in 
> parameters. 
> In createInvoiceForOrder service calls the createInvoiceContactMech to crate 
> invoice contactMech for PAYMENT_LOCATION purpose (at line no 357). In case of 
> SO it should use Company PAYMENT_LOCATION contactMech. It get the Company 
> contactMechId correctly and set it createInvoiceContactMech service in 
> context correctly, but system throws foreign key constraints error for 
> incorrect contactMechId. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-9117) EntityAuto engine override the passed service in parameters

2016-11-14 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-9117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15665957#comment-15665957
 ] 

Paul Foxworthy commented on OFBIZ-9117:
---

Hi Deepak,

Where in EntityAuto is it overriding the parameters that have been passed to it?

Thanks

Paul

> EntityAuto engine override the passed service in parameters
> ---
>
> Key: OFBIZ-9117
> URL: https://issues.apache.org/jira/browse/OFBIZ-9117
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Deepak Dixit
> Attachments: errorlog.txt
>
>
> There is an bug in EntityAuto engine, it override the passed service in 
> parameters. 
> In createInvoiceForOrder service calls the createInvoiceContactMech to crate 
> invoice contactMech for PAYMENT_LOCATION purpose (at line no 357). In case of 
> SO it should use Company PAYMENT_LOCATION contactMech. It get the Company 
> contactMechId correctly and set it createInvoiceContactMech service in 
> context correctly, but system throws foreign key constraints error for 
> incorrect contactMechId. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-7129) Recognise "BASE TABLE" table type in metadata

2016-11-14 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15665661#comment-15665661
 ] 

Paul Foxworthy commented on OFBIZ-7129:
---

I've now checked SQL 99 
(https://mariadb.com/kb/en/sql-99/information_schematables/) and SQL 2011 
(Download draft from http://www.wiscorp.com/sql20nn.zip). The actual SQL 
standards documents would cost money.

In both cases, the value ought to be "BASE TABLE". It's unfortunate Sun/Oracle 
didn't say so in their documentation of the getTables method.

Despite the fact my patch is not strictly necessary for MariaDB, I'm inclined 
to commit it. In future, another database might come along and implement 
standards-based SQL. Whoever writes a JDBC driver may not be aware that 
getTables is documented to deliver something different to the standard.

My change will make startup of OFBiz fractionally slower, but mean it accepts 
the SQL standard value. If there are no objections, I'll commit this in a few 
days.

> Recognise "BASE TABLE" table type in metadata
> -
>
> Key: OFBIZ-7129
> URL: https://issues.apache.org/jira/browse/OFBIZ-7129
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
> Attachments: OFBIZ-7129_BaseTableMetadata.patch, 
> OFBIZ-7129_BaseTableMetadata.patch
>
>
> In framework/entity/src/org/ofbiz/entity/jdbc/DatabaseUtil.java, the 
> getTableNames method looks for table types of "TABLE", "VIEW", "ALIAS" and 
> "SYNONYM" 
> (https://fisheye6.atlassian.com/browse/ofbiz/trunk/framework/entity/src/org/ofbiz/entity/jdbc/DatabaseUtil.java?r=1644354#to989).
> MariaDB produces a table type of "BASE TABLE", so OFBiz didn't detect the 
> tables were there, and attempted to create them. In fact, the tables do exist 
> so the create failed.
> The JDBC docs suggest that plain "TABLE" is a "typical" value for table type 
> (https://docs.oracle.com/javase/8/docs/api/java/sql/DatabaseMetaData.html#getTables-java.lang.String-java.lang.String-java.lang.String-java.lang.String:A-)
> But it seems "BASE TABLE" is more standards compliant - see for example 
> http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt page 576. I assume 
> some JDBC drivers transform "BASE TABLE" to plain "TABLE", but the MariaDB 
> one does not.
> I've attached a patch so OFBiz will recognise "BASE TABLE" if that's what it 
> receives in the metadata.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-7129) Recognise "BASE TABLE" table type in metadata

2016-11-10 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15656446#comment-15656446
 ] 

Paul Foxworthy commented on OFBIZ-7129:
---

But wait! The MariaDB JDBC driver was updated in May to report plain old 
"TABLE": https://jira.mariadb.org/browse/CONJ-218 .

Looks like my change isn't needed now.

I will document the problem with a fix of "upgrade to MariaDB connector version 
1.4.5 or later".

> Recognise "BASE TABLE" table type in metadata
> -
>
> Key: OFBIZ-7129
> URL: https://issues.apache.org/jira/browse/OFBIZ-7129
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
> Attachments: OFBIZ-7129_BaseTableMetadata.patch, 
> OFBIZ-7129_BaseTableMetadata.patch
>
>
> In framework/entity/src/org/ofbiz/entity/jdbc/DatabaseUtil.java, the 
> getTableNames method looks for table types of "TABLE", "VIEW", "ALIAS" and 
> "SYNONYM" 
> (https://fisheye6.atlassian.com/browse/ofbiz/trunk/framework/entity/src/org/ofbiz/entity/jdbc/DatabaseUtil.java?r=1644354#to989).
> MariaDB produces a table type of "BASE TABLE", so OFBiz didn't detect the 
> tables were there, and attempted to create them. In fact, the tables do exist 
> so the create failed.
> The JDBC docs suggest that plain "TABLE" is a "typical" value for table type 
> (https://docs.oracle.com/javase/8/docs/api/java/sql/DatabaseMetaData.html#getTables-java.lang.String-java.lang.String-java.lang.String-java.lang.String:A-)
> But it seems "BASE TABLE" is more standards compliant - see for example 
> http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt page 576. I assume 
> some JDBC drivers transform "BASE TABLE" to plain "TABLE", but the MariaDB 
> one does not.
> I've attached a patch so OFBiz will recognise "BASE TABLE" if that's what it 
> receives in the metadata.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-7789) ReserveStoreInventory with insufficient inventory

2016-11-08 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15646991#comment-15646991
 ] 

Paul Foxworthy commented on OFBIZ-7789:
---

Hi Mirko,

I think it should be possible to create an order when a product is not 
currently in stock. In other words, that's not an error, it's just a back order 
situation.

If the reservations *for this order* are removed and re-added, that should be 
fine. If the quantity of the order has changed, we might need to reserve 
additional quantities.

If you think there really is a problem, can you create a unit test to 
demonstrate it?

Cheers

Paul Foxworthy




> ReserveStoreInventory with insufficient inventory
> -
>
> Key: OFBIZ-7789
> URL: https://issues.apache.org/jira/browse/OFBIZ-7789
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: Release Branch 13.07, Trunk
>Reporter: Mirko Vogelsmeier
> Fix For: Trunk
>
> Attachments: OFBIZ-7789.patch
>
>
> When trying to reserve inventory for an item that does not have sufficient 
> amount of inventory ( ProductStoreServices#reserveStoreInventory ) no error 
> is thrown. This results in a successfully processed service.
> Following problem occured to us:
> We have a unique product (qoh 1) that is in the current order.
> Using the appendOrderItem on the exact product, does trigger 
> updateCartForUpdate which removes all reservations followed by 
> saveUpdatedCartToOrder that does store all orderItems to the order. Since no 
> error is being thrown due to the insufficient inventory, the product is added 
> to the order twice, although there is not enough inventory.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-7789) ReserveStoreInventory with insufficient inventory

2016-11-08 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy updated OFBIZ-7789:
--
Component/s: product

> ReserveStoreInventory with insufficient inventory
> -
>
> Key: OFBIZ-7789
> URL: https://issues.apache.org/jira/browse/OFBIZ-7789
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: Release Branch 13.07, Trunk
>Reporter: Mirko Vogelsmeier
> Fix For: Trunk
>
> Attachments: OFBIZ-7789.patch
>
>
> When trying to reserve inventory for an item that does not have sufficient 
> amount of inventory ( ProductStoreServices#reserveStoreInventory ) no error 
> is thrown. This results in a successfully processed service.
> Following problem occured to us:
> We have a unique product (qoh 1) that is in the current order.
> Using the appendOrderItem on the exact product, does trigger 
> updateCartForUpdate which removes all reservations followed by 
> saveUpdatedCartToOrder that does store all orderItems to the order. Since no 
> error is being thrown due to the insufficient inventory, the product is added 
> to the order twice, although there is not enough inventory.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-7824) Add validation for credit card number length

2016-11-07 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15645786#comment-15645786
 ] 

Paul Foxworthy commented on OFBIZ-7824:
---

Some credit cards have different lengths. For example, American Express is 15, 
not 16 digits.

Credit cards have a built-in checksum using the Luhn algorithm 
(https://en.wikipedia.org/wiki/Luhn_algorithm). It would be far better to 
verify the checksum, rather than just the number of digits.

There already is credit card checksum checking in OFBiz.  Have a look at 
https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/UtilValidate.java?r=1761200#to1193
 and the preceding code.

Is there somewhere in OFBiz that should be using this validation, but isn't 
currently?



> Add validation for credit card number length 
> -
>
> Key: OFBIZ-7824
> URL: https://issues.apache.org/jira/browse/OFBIZ-7824
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Affects Versions: Trunk
>Reporter: Padmavati Rawat
>Priority: Minor
>
> Ofbiz allows for any length for credit card numbers, as default length is 16 
> digits.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-7950) Improve consistency of service createEmployee

2016-11-02 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15631043#comment-15631043
 ] 

Paul Foxworthy commented on OFBIZ-7950:
---

I can see you might need special business rules for the name of an employee, 
but for a postal address?

Surely the rules for creating an employee's postal address should be consistent 
with those for a PostalContactMech in general. And so they are at the moment.

Which leads to an interesting thought. If several services might create and 
update the data within an entity, why is the optional flag on the services? 
Shouldn't it be on the entity itself? Then an auto-fields-service could get 
optional values from the entity itself. In more sophisticated services, you 
would define optional values yourself, but at least you'd have some guidance 
from the definition of the entity.

> Improve consistency of service createEmployee
> -
>
> Key: OFBIZ-7950
> URL: https://issues.apache.org/jira/browse/OFBIZ-7950
> Project: OFBiz
>  Issue Type: Improvement
>  Components: humanres
>Affects Versions: Trunk
>Reporter: Montalbano Florian
>Assignee: Nicolas Malin
>Priority: Minor
>  Labels: consistency, create, employee, service
> Attachments: OFBIZ-7950_proposition.patch
>
>
> In the humanres component, we can create an employee through the form 
> https://localhost:8443/humanres/control/NewEmployee .
> This form has required fields that are not the same requirement than the 
> service called when submitting the form.
> The service called is createEmployee.
> In the service, everything is declared optional but the 
> postalAddContactMechPurpTypeId (which is set in the form as an hidden field).
> This means we could create an Employee without forcing a telephone number or 
> a primary address or even a first name.
> But then, within the service, a check is done on the firstName and lastName 
> parameters and if missing, an error shows up.
> We could harmonize things a little.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-4749) OfBiz 10.04 Does not compile with Oracle JDK 7

2016-10-31 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15621961#comment-15621961
 ] 

Paul Foxworthy commented on OFBIZ-4749:
---

Jacques's r1386469 https://fisheye6.atlassian.com/rdiff/ofbiz?csid=1386469 
does indeed fix release 10.04
In addition, there are some missing dependencies from build.xml files. These 
were fixed in OFBIZ-5835.

Do both these things, and 10.04 compiles with the OpenJDK 8 compiler.



> OfBiz 10.04 Does not compile with Oracle JDK 7
> --
>
> Key: OFBIZ-4749
> URL: https://issues.apache.org/jira/browse/OFBIZ-4749
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Release 10.04
> Environment: Windows 7, Oracle JDK 7
>Reporter: Karl Laird
>Assignee: Jacques Le Roux
>Priority: Critical
>  Labels: build-failure
> Fix For: Release 10.04, Release Branch 11.04
>
>
> The OFBIZ version is apache-ofbiz-10.04
> When I'm compiling the project with the embedded and using ant run-install 
> run there is a error message
> classes:
>   [javac16] Compiling 13 source files to 
> C:\_portable\PortableApps\apache-ofbiz-10.04\framework\security\build\classes
>   [javac16] warning: [options] bootstrap class path not set in conjunction 
> with -source 1.6
>   [javac16] 
> C:\_portable\PortableApps\apache-ofbiz-10.04\framework\security\src\org\ofbiz\security\OFBizSecurity.java:52:
>  error: invalid inferred types for V; inferred type does not conform to 
> declared bound(s)
>   [javac16] protected static final Map> 
> simpleRoleEntity = UtilMisc.toMap(
>   [javac16]   
>^
>   [javac16] inferred: Map
>   [javac16] bound(s): Map
>   [javac16]   where V,V1,V2,V3 are type-variables:
>   [javac16] V extends Object declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] V1 extends V declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] V2 extends V declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] V3 extends V declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] 1 error
>   [javac16] 1 warning
> Changing to use JDK 6 works around this issue - however given that EOL for 
> JDK6 is November 2012 (IE this year, already extended from July) this is not 
> a long term solution.
> Regards
> Karl



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-4749) OfBiz 10.04 Does not compile with Oracle JDK 7

2016-10-27 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15613133#comment-15613133
 ] 

Paul Foxworthy commented on OFBIZ-4749:
---

Hi Jacques,

Sorry, that was a bit obscure. I'm working on a codebase even older than 10.04 
at the moment, and revision 718655 was one more change I needed to get it to 
compile with Java 7. I have revised my original comment above. I will 
consolidate all the changes into one patch and attach it here. 1059352 has 
other changes not relevant to this issue - I'll split that patch into two.


> OfBiz 10.04 Does not compile with Oracle JDK 7
> --
>
> Key: OFBIZ-4749
> URL: https://issues.apache.org/jira/browse/OFBIZ-4749
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Release 10.04
> Environment: Windows 7, Oracle JDK 7
>Reporter: Karl Laird
>Assignee: Jacques Le Roux
>Priority: Critical
>  Labels: build-failure
> Fix For: Release 10.04, Release Branch 11.04
>
>
> The OFBIZ version is apache-ofbiz-10.04
> When I'm compiling the project with the embedded and using ant run-install 
> run there is a error message
> classes:
>   [javac16] Compiling 13 source files to 
> C:\_portable\PortableApps\apache-ofbiz-10.04\framework\security\build\classes
>   [javac16] warning: [options] bootstrap class path not set in conjunction 
> with -source 1.6
>   [javac16] 
> C:\_portable\PortableApps\apache-ofbiz-10.04\framework\security\src\org\ofbiz\security\OFBizSecurity.java:52:
>  error: invalid inferred types for V; inferred type does not conform to 
> declared bound(s)
>   [javac16] protected static final Map> 
> simpleRoleEntity = UtilMisc.toMap(
>   [javac16]   
>^
>   [javac16] inferred: Map
>   [javac16] bound(s): Map
>   [javac16]   where V,V1,V2,V3 are type-variables:
>   [javac16] V extends Object declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] V1 extends V declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] V2 extends V declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] V3 extends V declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] 1 error
>   [javac16] 1 warning
> Changing to use JDK 6 works around this issue - however given that EOL for 
> JDK6 is November 2012 (IE this year, already extended from July) this is not 
> a long term solution.
> Regards
> Karl



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (OFBIZ-4749) OfBiz 10.04 Does not compile with Oracle JDK 7

2016-10-27 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611435#comment-15611435
 ] 

Paul Foxworthy edited comment on OFBIZ-4749 at 10/27/16 8:30 PM:
-

revision 718655 https://fisheye6.atlassian.com/changelog/ofbiz?cs=718655 was 
also a change to ensure OFBiz compiles with Java 7. It predates version 10.04 
of OFBiz, so is already in place in that version. But I thought it might be 
useful to mention this in case anyone is trying to build an old OFBiz codebase 
with Java 7.


was (Author: paul_foxworthy):
revision 718655 https://fisheye6.atlassian.com/changelog/ofbiz?cs=718655 
predates 10.04 but is similar

> OfBiz 10.04 Does not compile with Oracle JDK 7
> --
>
> Key: OFBIZ-4749
> URL: https://issues.apache.org/jira/browse/OFBIZ-4749
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Release 10.04
> Environment: Windows 7, Oracle JDK 7
>Reporter: Karl Laird
>Assignee: Jacques Le Roux
>Priority: Critical
>  Labels: build-failure
> Fix For: Release 10.04, Release Branch 11.04
>
>
> The OFBIZ version is apache-ofbiz-10.04
> When I'm compiling the project with the embedded and using ant run-install 
> run there is a error message
> classes:
>   [javac16] Compiling 13 source files to 
> C:\_portable\PortableApps\apache-ofbiz-10.04\framework\security\build\classes
>   [javac16] warning: [options] bootstrap class path not set in conjunction 
> with -source 1.6
>   [javac16] 
> C:\_portable\PortableApps\apache-ofbiz-10.04\framework\security\src\org\ofbiz\security\OFBizSecurity.java:52:
>  error: invalid inferred types for V; inferred type does not conform to 
> declared bound(s)
>   [javac16] protected static final Map> 
> simpleRoleEntity = UtilMisc.toMap(
>   [javac16]   
>^
>   [javac16] inferred: Map
>   [javac16] bound(s): Map
>   [javac16]   where V,V1,V2,V3 are type-variables:
>   [javac16] V extends Object declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] V1 extends V declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] V2 extends V declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] V3 extends V declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] 1 error
>   [javac16] 1 warning
> Changing to use JDK 6 works around this issue - however given that EOL for 
> JDK6 is November 2012 (IE this year, already extended from July) this is not 
> a long term solution.
> Regards
> Karl



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-4749) OfBiz 10.04 Does not compile with Oracle JDK 7

2016-10-27 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611435#comment-15611435
 ] 

Paul Foxworthy commented on OFBIZ-4749:
---

revision 718655 https://fisheye6.atlassian.com/changelog/ofbiz?cs=718655 
predates 10.04 but is similar

> OfBiz 10.04 Does not compile with Oracle JDK 7
> --
>
> Key: OFBIZ-4749
> URL: https://issues.apache.org/jira/browse/OFBIZ-4749
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Release 10.04
> Environment: Windows 7, Oracle JDK 7
>Reporter: Karl Laird
>Assignee: Jacques Le Roux
>Priority: Critical
>  Labels: build-failure
> Fix For: Release 10.04, Release Branch 11.04
>
>
> The OFBIZ version is apache-ofbiz-10.04
> When I'm compiling the project with the embedded and using ant run-install 
> run there is a error message
> classes:
>   [javac16] Compiling 13 source files to 
> C:\_portable\PortableApps\apache-ofbiz-10.04\framework\security\build\classes
>   [javac16] warning: [options] bootstrap class path not set in conjunction 
> with -source 1.6
>   [javac16] 
> C:\_portable\PortableApps\apache-ofbiz-10.04\framework\security\src\org\ofbiz\security\OFBizSecurity.java:52:
>  error: invalid inferred types for V; inferred type does not conform to 
> declared bound(s)
>   [javac16] protected static final Map> 
> simpleRoleEntity = UtilMisc.toMap(
>   [javac16]   
>^
>   [javac16] inferred: Map
>   [javac16] bound(s): Map
>   [javac16]   where V,V1,V2,V3 are type-variables:
>   [javac16] V extends Object declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] V1 extends V declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] V2 extends V declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] V3 extends V declared in method 
> toMap(String,V1,String,V2,String,V3)
>   [javac16] 1 error
>   [javac16] 1 warning
> Changing to use JDK 6 works around this issue - however given that EOL for 
> JDK6 is November 2012 (IE this year, already extended from July) this is not 
> a long term solution.
> Regards
> Karl



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


<    1   2