#983 Credit Available Check ignore No Credit Check

[Armen Rizal (Goodwill)]

CalloutOrder.java, function bpartner()

// CreditAvailable
if (IsSOTrx)
{
double CreditLimit = rs.getDouble("SO_CreditLimit");
String SOCreditStatus = rs.getString("SOCreditStatus");
if (CreditLimit != 0)
{
double CreditAvailable = rs.getDouble("CreditAvailable");
if (!rs.wasNull() && CreditAvailable < 0)
mTab.fireDataStatusEEvent("CreditLimitOver",
DisplayType.getNumberFormat(DisplayType.Amount).format(CreditAvailable),
false);
}
}

It should test if No Credit Check

if (CreditLimit != 0 || !SOCreditStatus.equals(MBPartner.SOCREDITSTATUS_NoCreditCheck))

same thing in CalloutInOut.

Also, do you think we should not perform this check if it's a return trx ?

Regards,

Armen

[Tobias Schöneberg]

[Tobias Schöneberg]

Logged In: YES
user_id=1544115
Originator: NO

Hi,
The patch I added includes the proposed check for MBPartner.SOCREDITSTATUS_NoCreditCheck in CalloutOrder.
As usual I have a rather limited understanding of the business processes, so I refrained from changing more.

Pls review.

Regards, Tobi
File Added: BF1883543.patch

[Tobias Schöneberg]

Unassigning the bug from me to encourage someone else to review and possibly commit the proposed fix.

[Armen Rizal (Goodwill)]

Ok, I'll take it myself within this weekend.

Armen

[Michael Judd]

I agree with your fix and I do not think this should be applicable to a return - i.e. you should be able to return even if you are over your credit limit (stop credit)

I will take this on.

[Michael Judd]

I think this should include the current order amount to stop one big final order and also only be for the following DocTypes.....

DocSubTypeSO_OnCredit
DocSubTypeSO_Standard
DocSubTypeSO_Warehouse
MOrder.DocSubTypeSO_POS

POS sub types should be included as you might have a POS counter sale without payment (i.e. on account) even though usually the goods are paid for at the time.

We should include the same logic in CallOutInvoice

Any comments?

[Michael Judd]

A suggested patch

[Michael Judd]

I've added patch.txt - which incorporates the call out for both order and invoice - and includes the doc sub types.

[Carlos Ruiz]

Armen / Michael

Let me check the following.

There is no data corruption here and the user can save the order without problems - so the priority of this tracker is not 9. Indeed I think it's not a bug, but a feature request.

Now, as I see the message is shown just as a warning, and I think it's ok. If you don't want the warning just assign zero to the credit limit. But if you assign a value to the credit limit then the warning is shown, the "no credit check" rule allows to save the order. I think the functionality is ok.

WDYT?

I haven't tested - probably the part of "not check on returns" is right. On an authorized return is wrong to check the credit, is Adempiere doing that?

Regards,

Carlos Ruiz

[Michael Judd]

Hi Carlos,

Well I think it is probably a bug that the credit check stops you returning goods. In my opinion - it should only check credit for the following SO sub types:

DocSubTypeSO_OnCredit
DocSubTypeSO_Standard
DocSubTypeSO_Warehouse
DocSubTypeSO_POS

I only include POS as it is possible to do a POS sale without taking money.

The problem is that the flag - "No Credit Check" currently does not work as intended and a work around does exist - so I agree it should not be priority 9.

Currently, this check is applied for all sales transactions. My proposed patch is attached for both orders and invoices.

I believe however, we should also include the order / invoice amount when checking the limit as the credit available should include the current document being input. WDYT?

[Carlos Ruiz]

Michael, I just tested window "Customer Return" and the credit check is not being done.

So, in my opinion Adempiere is working ok.

The warning message appears - but I think it's ok as it's a warning to the user that the behavior of this customer must be reviewed - even as we don't need to stop the credit.

We can consider this:

Credit Limit -> filled to control the credit for customers OR TO ISSUE WARNINGS ABOUT CREDIT LIMIT REACHED (if configured with No Credit Check)

Credit Status -> this is to determine HOW Adempiere must behave - if a sale must be stopped, allowed and if the customer is flagged as "watch this".

So, in my opinion, this is not a bug, Adempiere is behaving correctly.

Regards,

Carlos Ruiz

[Michael Judd]

The prepareIT in MOrder works as follows:

If the order is POS and the payment type is Cash and the system config variable is CHECK_CREDIT_ON_CASH_POS_ORDER then do not check credit.

If this is a prepay order and the CHECK_CREDIT_ON_PREPAY_ORDER config variable is set then do not check credit

Else if the bp is on stop or hold then display a message and do not complete and invalidate the document

Else check the document amount and put the bp on hold if the doc amount exceeds the hold / limit.

Don't you think we should align the warnings with this or perhaps drop the warning from the callout ?

I guess the problem is inconsistent behaviour between order / invoice and callout.

I also guess this will prevent proposals / quotations from being raised for the bp - I would have thought this would be allowed .....

[Carlos Ruiz]

Michael

> I guess the problem is inconsistent behaviour between order / invoice and
> callout.

My point is that they are not designed to be consistent.

The callout issues just a warning to let the user know that something wrong can be happening with this customer.

The prepare method do stop the sale or shipment or even vendor payment depending on the credit hold and the sysconfig parameters.

I think the warning is good - and if somebody doesn't want the warning then simply the credit limit must be zero.

Regards,

Carlos Ruiz

[Michael Judd]

ok - I will pass this back to armen for to either close or comment.

[Armen Rizal (Goodwill)]

Hi all,

>I think the warning is good - and if somebody doesn't want the warning
>then simply the credit limit must be zero.

I share from experience with users.

If I dont' want the warning, can we just set the credit status to No Credit Check instead of changing the limit ? After all, what is that status suggesting in the first place ? No credit check means I don't want the warning. It's that simple.

About return trx, it's correct that Adempiere doesn't forbid you from completing the process but many users found that the warning is unnecessary. Typical users want the most quick and effort-less way possible to input transaction. That's reality.

BTW, I agree it's not top priority bug.

Regards,

Armen

[Carlos Ruiz]

Thanks Armen,

> After all, what is that status suggesting in the first place ?
> No credit check means I don't want the warning. It's that simple.

I counter-ask - what is the meaning of setting no credit check - and setting a credit limit ?

So, why the user wants to set a credit limit if no credit check is selected? IMHO it can mean the user wants a check warning, but not stopping the sale.

Is that possible in the scenario you describe?

> Typical users want the most quick and effort-less way possible
> to input transaction. That's reality.

For such users just put the credit limit = 0 - what's the issue?

Regards,

Carlos Ruiz