Several quesions about "inspection", "rejected", and "amount_actual"

Novice_Andy

Question about unreasoned inspection: We have discovered that in some cases, it will be inspected without any TRUE in “selected_random”, “selected_manually”, or “selected_manually”. It is out of the expectation according to the definition. What will be the possible reason?

Question about rejection: What is the exact meaning of “rejected”? Because according to the definition, we understand that the payment will be canceled after being rejected. However, there exist cases that received payment after rejection.

Question about penalty and payment amount: According to our sense, we thought that [payment_actual = payment_applied – penalty_amount]. However, the formula didn’t hold. Is the amount_applied cumulative?

Sorry for so many questions. We are just new to the data mining and still learning.

fborchert

>> Question about unreasoned inspection

This is a very interesting question. I had a look in the data and it appears that these applicants had a penalty with code "BGK" in the previous year. This can trigger an inspection in the next year.

>> Question about rejection

Rejected applications may still participate in the payment subprocess, however, no actual payments are initiated. These cases will, in the end, just show up in some report with a payment of 0.

>> Question about penalty and payment amount

The actual formula would be slightly more complicated, because there may be other reasons for small cuts to the payment amount. Anyway, due to the rounding / binning scheme described on the challenge website you shouldn't really do calculations with these numbers. They should just give you an idea of the application and penalty volume.

gwlax

fborchert said:

>> Question about unreasoned inspection

This is a very interesting question. I had a look in the data and it appears that these applicants had a penalty with code "BGK" in the previous year. This can trigger an inspection in the next year.

>> Question about rejection

Rejected applications may still participate in the payment subprocess, however, no actual payments are initiated. These cases will, in the end, just show up in some report with a payment of 0.

>> Question about penalty and payment amount

The actual formula would be slightly more complicated, because there may be other reasons for small cuts to the payment amount. Anyway, due to the rounding / binning scheme described on the challenge website you shouldn't really do calculations with these numbers. They should just give you an idea of the application and penalty volume.

Further questions about rejection:

However, there are many cases where rejected = TRUE and payment_actual{x} > 0. I'm curious how these payments could occur.

By the way, do all payment_actual{x} accumulate to be a total payment, or each of them represents a single payment? Because there are negative entries of payment_actual{x}, are they fines or discounts of final payment.

fborchert

>> However, there are many cases where rejected = TRUE and payment_actual{x} > 0. I'm curious how these payments could occur.

It appears that rejecting an application sometimes causes zeroing the values in the document and sometimes not.
You can just assume that when an application is rejected, the applicant did not receive any money (if he did not object or a change by the department was initiated).

>> By the way, do all payment_actual{x} accumulate to be a total payment, or each of them represents a single payment?

Each value represents a single payment (corresponding to a new subprocess). If the value is negative, this means that the applicant has to reimburse some amount of money.

 

dyadav

Additional question about variable "amount_applied{x}":

Since, you mentioned that each value in payment_actual represents a single payment, i.e. payment_actual_total is the sum of all payment_actual{x}.

Can we say the same regarding amount_applied? Is amount_applied_total, the sum of all amount_applied{x}?

fborchert

"amount_applied" does not accumulate, it is the current value per subprocess