I like the idea of employee expenses, but we have not considered them to date
for our solution. Right now I think they would be entered by the bookkeeper
directly as an acctgTrans with associated entries. Not think I think having
that type of invoice is a bad idea (as a more robust model of these
expenses).
Jacopo --
I like the utility method that you provided. However, the implementation of
these services is in minilang so calling it is a little bit of a pain. As a
result, I have done the following (which is consistent with other recursive
checks in accounting related objects like payment types and account types).
Updated UtilAccountiing.java with the following:
public static boolean isPurchaseInvoice(GenericValue invoice) throws
GenericEntityException {
if (invoice == null) {
return false;
}
return CommonWorkers.hasParentType(invoice.getDelegator(),
"InvoiceType", "invoiceTypeId", invoice.getString("invoiceTypeId"),
"parentTypeId", "PURCHASE_INVOICE");
}
Then in my simple method I am doing the following ...
<entity-one entity-name="Invoice" value-field="invoice"/>
<set type="Boolean" field="isPurchaseInvoice"
value="${bsh:org.ofbiz.accounting.util.UtilAccounting.isPurchaseInvoice(invoice)}"
/>
<if-compare field="isPurchaseInvoice" operator="equals" value="true"
type="Boolean">
[logic ...]
I have not executed this; but if we are in agreement I will go ahead and
test it out and then create a patch for trunk.
--
View this message in context:
http://n4.nabble.com/Accounting-transaction-for-commission-invoice-tp1564778p1566142.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
