Why is a bogus Payment and OrderPaymentPreference created for Purchase Orders

[SkipDever]

There is this seca:

    -eca service="changeOrderStatus" event="commit" run-on-error="false"-
        -condition field-name="orderTypeId" operator="equals"
value="PURCHASE_ORDER"-
        -condition field-name="statusId" operator="equals"
value="ORDER_APPROVED"-
        -condition-field field-name="statusId" operator="not-equals"
to-field-name="oldStatusId/-
        -action service="createPaymentFromOrder" mode="sync" persist="true"-
   -eca-


If the order is approved and it is a purchase order, the service
createPaymentFromOrder is called which creates a payment and a
OrderPaymentPreference amoung other things.

This is causing me some problems because when the order is received, an
invoice is created by InvoiceServices.createInvoiceForOrder and around line
776 is this line:

            List<GenericValue> orderPaymentPrefs =
delegator.findList("OrderPaymentPreference",
EntityCondition.makeCondition(paymentPrefConds, EntityOperator.AND), null,
null, null, false);


This returns the above created OrderPaymentPreference and a
PaymentApplication is created for the payment created above.

There is a bug in this code that miscalculates the amount to apply and I get
errors like:

Error in service [createPaymentApplication] Tried to apply [692.5] which is
greater than the outstanding amount [623.25] of invoice [62741].

Now, I dont really care about this bug.  In my view, the Payment and
OrderPaymentPreference should not have been created.  In version 9.x, this
seca did not exist.

My question is what is the purpose?  No payment was ever received, it is a
completely bogus one.

I have commented out the seca and am in the process of writing a service to
remove all the payments, applications, and OrderPaymentPreference created by
the above seca.

I am just wondering what the logic here was.

Skip

[Jacques Le Roux]

This was added at http://svn.apache.org/viewvc?view=revision&revision=941132
And can be now parametrised in trunk using  http://svn.apache.org/viewvc?view=revision&revision=1494464

I don't know more

Jacques

Skip wrote:

> There is this seca:
>
>    -eca service="changeOrderStatus" event="commit" run-on-error="false"-
>        -condition field-name="orderTypeId" operator="equals"
> value="PURCHASE_ORDER"-
>        -condition field-name="statusId" operator="equals"
> value="ORDER_APPROVED"-
>        -condition-field field-name="statusId" operator="not-equals"
> to-field-name="oldStatusId/-
>        -action service="createPaymentFromOrder" mode="sync" persist="true"-
>   -eca-
>
>
> If the order is approved and it is a purchase order, the service
> createPaymentFromOrder is called which creates a payment and a
> OrderPaymentPreference amoung other things.
>
> This is causing me some problems because when the order is received, an
> invoice is created by InvoiceServices.createInvoiceForOrder and around line
> 776 is this line:
>
>            List<GenericValue> orderPaymentPrefs =
> delegator.findList("OrderPaymentPreference",
> EntityCondition.makeCondition(paymentPrefConds, EntityOperator.AND), null,
> null, null, false);
>
>
> This returns the above created OrderPaymentPreference and a
> PaymentApplication is created for the payment created above.
>
> There is a bug in this code that miscalculates the amount to apply and I get
> errors like:
>
> Error in service [createPaymentApplication] Tried to apply [692.5] which is
> greater than the outstanding amount [623.25] of invoice [62741].
>
> Now, I dont really care about this bug.  In my view, the Payment and
> OrderPaymentPreference should not have been created.  In version 9.x, this
> seca did not exist.
>
> My question is what is the purpose?  No payment was ever received, it is a
> completely bogus one.
>
> I have commented out the seca and am in the process of writing a service to
> remove all the payments, applications, and OrderPaymentPreference created by
> the above seca.
>
> I am just wondering what the logic here was.
>
> Skip

[SkipDever]

Thanks Jacques

Looks like a Hans Bakker addition.  Perhaps he can comment on the purpose
and value.

In the meantime, I am removing it because it causes later problems.

Skip

-----Original Message-----
From: Jacques Le Roux [mailto:[hidden email]]
Sent: Tuesday, October 15, 2013 10:54 AM
To: [hidden email]
Subject: Re: Why is a bogus Payment and OrderPaymentPreference created
for Purchase Orders


This was added at http://svn.apache.org/viewvc?view=revision&revision=941132
And can be now parametrised in trunk using
http://svn.apache.org/vkkeriewvc?view=revision&revision=1494464

I don't know more

Jacques

Skip wrote:

> There is this seca:
>
>    -eca service="changeOrderStatus" event="commit" run-on-error="false"-
>        -condition field-name="orderTypeId" operator="equals"
> value="PURCHASE_ORDER"-
>        -condition field-name="statusId" operator="equals"
> value="ORDER_APPROVED"-
>        -condition-field field-name="statusId" operator="not-equals"
> to-field-name="oldStatusId/-
>        -action service="createPaymentFromOrder" mode="sync"

persist="true"-
>   -eca-
>
>
> If the order is approved and it is a purchase order, the service
> createPaymentFromOrder is called which creates a payment and a
> OrderPaymentPreference amoung other things.
>
> This is causing me some problems because when the order is received, an
> invoice is created by InvoiceServices.createInvoiceForOrder and around
line

> 776 is this line:
>
>            List<GenericValue> orderPaymentPrefs =
> delegator.findList("OrderPaymentPreference",
> EntityCondition.makeCondition(paymentPrefConds, EntityOperator.AND), null,
> null, null, false);
>
>
> This returns the above created OrderPaymentPreference and a
> PaymentApplication is created for the payment created above.
>
> There is a bug in this code that miscalculates the amount to apply and I

get
> errors like:
>
> Error in service [createPaymentApplication] Tried to apply [692.5] which
is

> greater than the outstanding amount [623.25] of invoice [62741].
>
> Now, I dont really care about this bug.  In my view, the Payment and
> OrderPaymentPreference should not have been created.  In version 9.x, this
> seca did not exist.
>
> My question is what is the purpose?  No payment was ever received, it is a
> completely bogus one.
>
> I have commented out the seca and am in the process of writing a service

to
> remove all the payments, applications, and OrderPaymentPreference created
by
> the above seca.
>
> I am just wondering what the logic here was.
>
> Skip

[hans_bakker]

Hi Skip, not sure if added it, because running accounting s pretty
cumbersome if you have to create manually  payments and payment
application for the automatically generated invoice. It is much easier
to amend the automatically generated ones if required.

If i remember well there is a property setting if you do not want to
generate the payment automatically?

Regards,
Hans

On 10/16/2013 12:11 AM, Skip wrote:

> There is this seca:
>
>      -eca service="changeOrderStatus" event="commit" run-on-error="false"-
>          -condition field-name="orderTypeId" operator="equals"
> value="PURCHASE_ORDER"-
>          -condition field-name="statusId" operator="equals"
> value="ORDER_APPROVED"-
>          -condition-field field-name="statusId" operator="not-equals"
> to-field-name="oldStatusId/-
>          -action service="createPaymentFromOrder" mode="sync" persist="true"-
>     -eca-
>
>
> If the order is approved and it is a purchase order, the service
> createPaymentFromOrder is called which creates a payment and a
> OrderPaymentPreference amoung other things.
>
> This is causing me some problems because when the order is received, an
> invoice is created by InvoiceServices.createInvoiceForOrder and around line
> 776 is this line:
>
>              List<GenericValue> orderPaymentPrefs =
> delegator.findList("OrderPaymentPreference",
> EntityCondition.makeCondition(paymentPrefConds, EntityOperator.AND), null,
> null, null, false);
>
>
> This returns the above created OrderPaymentPreference and a
> PaymentApplication is created for the payment created above.
>
> There is a bug in this code that miscalculates the amount to apply and I get
> errors like:
>
> Error in service [createPaymentApplication] Tried to apply [692.5] which is
> greater than the outstanding amount [623.25] of invoice [62741].
>
> Now, I dont really care about this bug.  In my view, the Payment and
> OrderPaymentPreference should not have been created.  In version 9.x, this
> seca did not exist.
>
> My question is what is the purpose?  No payment was ever received, it is a
> completely bogus one.
>
> I have commented out the seca and am in the process of writing a service to
> remove all the payments, applications, and OrderPaymentPreference created by
> the above seca.
>
> I am just wondering what the logic here was.
>
> Skip
>

[Paul Foxworthy]

Hi Skip and Hans,

Once a purchase order has been approved, you could use the payment for projected cash flow. Yes, the amount is an estimate until the supplier's invoice is received, but that estimate might be better than nothing.

Cheers

Paul Foxworthy

hans_bakker wrote

Hi Skip, not sure if added it, because running accounting s pretty
cumbersome if you have to create manually  payments and payment
application for the automatically generated invoice. It is much easier
to amend the automatically generated ones if required.

If i remember well there is a property setting if you do not want to
generate the payment automatically?

Regards,
Hans

On 10/16/2013 12:11 AM, Skip wrote:
> There is this seca:
>
>      -eca service="changeOrderStatus" event="commit" run-on-error="false"-
>          -condition field-name="orderTypeId" operator="equals"
> value="PURCHASE_ORDER"-
>          -condition field-name="statusId" operator="equals"
> value="ORDER_APPROVED"-
>          -condition-field field-name="statusId" operator="not-equals"
> to-field-name="oldStatusId/-
>          -action service="createPaymentFromOrder" mode="sync" persist="true"-
>     -eca-
>
>
> If the order is approved and it is a purchase order, the service
> createPaymentFromOrder is called which creates a payment and a
> OrderPaymentPreference amoung other things.
>
> This is causing me some problems because when the order is received, an
> invoice is created by InvoiceServices.createInvoiceForOrder and around line
> 776 is this line:
>
>              List<GenericValue> orderPaymentPrefs =
> delegator.findList("OrderPaymentPreference",
> EntityCondition.makeCondition(paymentPrefConds, EntityOperator.AND), null,
> null, null, false);
>
>
> This returns the above created OrderPaymentPreference and a
> PaymentApplication is created for the payment created above.
>
> There is a bug in this code that miscalculates the amount to apply and I get
> errors like:
>
> Error in service [createPaymentApplication] Tried to apply [692.5] which is
> greater than the outstanding amount [623.25] of invoice [62741].
>
> Now, I dont really care about this bug.  In my view, the Payment and
> OrderPaymentPreference should not have been created.  In version 9.x, this
> seca did not exist.
>
> My question is what is the purpose?  No payment was ever received, it is a
> completely bogus one.
>
> I have commented out the seca and am in the process of writing a service to
> remove all the payments, applications, and OrderPaymentPreference created by
> the above seca.
>
> I am just wondering what the logic here was.
>
> Skip
>