To prevent spam users, you can only post on this forum after registration, which is by invitation. If you want to post on the forum, please send me a mail (h DOT m DOT w DOT verbeek AT tue DOT nl) and I'll send you an invitation in return for an account.

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

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.

Comments

  • >> 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.
  • 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.
  • >> 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
    edited May 2018
    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}?
  • "amount_applied" does not accumulate, it is the current value per subprocess
Sign In or Register to comment.