I would suggest to replace static "equals" condition for "PURCHASE_INVOICE"
with the utility method:
if (CommonWorkers.hasParentType(delegator, "InvoiceType", "invoiceTypeId",
invoiceTypeId, "parentTypeId", "PURCHASE_INVOICE")) {
// ....
}
(where invoiceTypeId could contain "COMMISSION_INVOICE").
Of course it requires a proper definition of parent/child relationships for
invoice types.
A similar approach is used for "ProductType" for marketing packages.
Jacopo
On Feb 22, 2010, at 5:59 PM, Bob Morley wrote:
>
> We are making us of the generation of commission invoices from sales order.
> The invoice looks great, but when we try to make payment to the invoice and
> look at the resulting accounting transactions, they appear to be incorrect
> ...
>
> When other invoices are created (sales / purchase) there is an SECA that
> gets involved with the invoice moves into "INVOICE_READY" state. These are
> defined in secas_ledger.xml with service invocations for
> "createAcctgTransForPurchaseInvoice" and "createAcctgTransForSalesInvoice".
> Each of these implementations only work on invoice types that are explicitly
> "PURCHASE_INVOICE" and "SALES_INVOICE" and they typically create the
> transaction that works with the A/R or A/P and specifics from the invoice
> (determined by configured mapping using invoice type).
>
> Now, when a commission invoice is created and moved to ready it does not get
> included in the "createAcctgTransForPurchaseInvoice" service (even though
> its invoice type has purchase order as its parent type). I have made a
> minor change in our solution to allow this service to execute against
> invoices that are either "PURCHASE_INVOICE" or "COMMISSION_INVOICE". The
> logic in this service properly uses type mapping to determine the GL
> accounts to hit, so doing this resulted in the following:
>
> AcctgTrans of type "PURCHASE_INVOICE" that is related to our commissionable
> sales rep (partyId) and the commision invoice (invoiceId) (although the
> roleType BILL_FROM_VENDOR) looks incorrect.
>
> AcctgTransEntry - C A/P (210000) and D Sales Commissions (601300) and these
> look right.
>
>
> The back end GL transactions when you actually pay this invoice have always
> looked correct (to me). They are:
>
> C Cash (112000) & D Accrued Commissions Due (221100)
> C Accured Commissions Due (221100) & D A/P (210000)
>
> So after a commission invoice is created and paid to their employee, you are
> left with ...
>
> Cash goes down and Sales Commission expense goes up. (as the A/P to the
> employee and accrued commission due both net to $0). (This is assuming we
> paid the employee cash / cash equivalent that mapped to 112000).
>
> Does anyone have any comments on this? After doing a lot of reading and
> working on these things, it appears that this minor change produced the
> desired results. In fact, I believe what we should be doing is having this
> initial accounting transaction check the invoice type hierarchy when
> determining if it should act on the invoice. This would result in invoices
> of type commission, payroll, purchase, and customer return being handled as
> purchase invoices (money going out) and invoices of type sales, interest,
> purchase return being handled as sales invoices (money going in). (this is
> based on the invoice type hierarchy from the InvoiceType entity seeding).
>
> I am hoping someone has worked with the accounting transactions on invoices
> that were not the base sales/purchase types and can let me know if this
> seems right or if I have strayed off track.
> --
> View this message in context:
> http://n4.nabble.com/Accounting-transaction-for-commission-invoice-tp1564778p1564778.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
