Fixed a bug where over payments cause duplicate rows.
In other words: negative balanced bills would bug this
logic.
Also fixed the release note syntax.
Signed-off-by: blake <blake@mobiusconsortium.org>
Signed-off-by: Jason Boyer <JBoyer@equinoxOLI.org>
WHERE p.id = current_payment.id;
-- If we don't do this then OPAC CC payments have no payment_ou
IF NOT FOUND THEN
- SELECT home_ou INTO payment_ou FROM actor.usr WHERE id = (SELECT accepting_usr FROM money.bnm_payment WHERE id = current_payment.id);
+ SELECT home_ou INTO payment_ou FROM actor.usr WHERE id = (SELECT accepting_usr FROM money.bnm_payment WHERE id = current_payment.id LIMIT 1);
END IF;
-- Were we looking at a billing from a previous step in the loop?
maintain_billing_remainder := FALSE;
END IF;
- RETURN NEXT current_result;
+ IF current_result.amount <> 0.0 THEN
+ RETURN NEXT current_result;
+ END IF;
-- Done paying the billing rows when we run out of rows to pay (out of bounds)
EXIT WHEN array_length(billing_id_used, 1) = billing_row_count;
END IF;
billing_id_used = array_append( billing_id_used, current_billing_id );
END IF;
- RETURN NEXT current_result;
+ IF current_result.amount <> 0.0 THEN
+ RETURN NEXT current_result;
+ END IF;
IF continuing_payment_last_row THEN
-- This should only occur when the account_adjustment's do not line up exactly with the billing
-- So we are going to pay some other type of billing row with this odd account_adjustment
billing_id_used = array_append( billing_id_used, current_billing_id );
END IF;
- RETURN NEXT current_result;
+ IF current_result.amount <> 0.0 THEN
+ RETURN NEXT current_result;
+ END IF;
EXIT WHEN payment_remainder = 0.0;
END LOOP;
WHERE p.id = current_payment.id;
IF NOT FOUND THEN
- SELECT home_ou INTO payment_ou FROM actor.usr WHERE id = (SELECT accepting_usr FROM money.bnm_payment WHERE id = current_payment.id);
+ SELECT home_ou INTO payment_ou FROM actor.usr WHERE id = (SELECT accepting_usr FROM money.bnm_payment WHERE id = current_payment.id LIMIT 1);
END IF;
payment_remainder = -current_payment.amount; -- invert
END IF;
current_result.amount = -current_result.amount;
- RETURN NEXT current_result;
+ IF current_result.amount <> 0.0 THEN
+ RETURN NEXT current_result;
+ END IF;
-- Done paying the billing rows when we run out of rows to pay (out of bounds)
EXIT WHEN billing_offset = billing_row_count + 1;
END IF;
END IF;
current_result.amount = -current_result.amount;
- RETURN NEXT current_result;
+ IF current_result.amount <> 0.0 THEN
+ RETURN NEXT current_result;
+ END IF;
EXIT WHEN payment_remainder = 0.0;
WHERE p.id = current_payment.id;
-- If we don't do this then OPAC CC payments have no payment_ou
IF NOT FOUND THEN
- SELECT home_ou INTO payment_ou FROM actor.usr WHERE id = (SELECT accepting_usr FROM money.bnm_payment WHERE id = current_payment.id);
+ SELECT home_ou INTO payment_ou FROM actor.usr WHERE id = (SELECT accepting_usr FROM money.bnm_payment WHERE id = current_payment.id LIMIT 1);
END IF;
-- Were we looking at a billing from a previous step in the loop?
maintain_billing_remainder := FALSE;
END IF;
- RETURN NEXT current_result;
+ IF current_result.amount <> 0.0 THEN
+ RETURN NEXT current_result;
+ END IF;
-- Done paying the billing rows when we run out of rows to pay (out of bounds)
EXIT WHEN array_length(billing_id_used, 1) = billing_row_count;
END IF;
billing_id_used = array_append( billing_id_used, current_billing_id );
END IF;
- RETURN NEXT current_result;
+ IF current_result.amount <> 0.0 THEN
+ RETURN NEXT current_result;
+ END IF;
IF continuing_payment_last_row THEN
-- This should only occur when the account_adjustment's do not line up exactly with the billing
-- So we are going to pay some other type of billing row with this odd account_adjustment
WHERE p.id = current_payment.id;
IF NOT FOUND THEN
- SELECT home_ou INTO payment_ou FROM actor.usr WHERE id = (SELECT accepting_usr FROM money.bnm_payment WHERE id = current_payment.id);
+ SELECT home_ou INTO payment_ou FROM actor.usr WHERE id = (SELECT accepting_usr FROM money.bnm_payment WHERE id = current_payment.id LIMIT 1);
END IF;
payment_remainder = -current_payment.amount; -- invert
END IF;
current_result.amount = -current_result.amount;
- RETURN NEXT current_result;
+ IF current_result.amount <> 0.0 THEN
+ RETURN NEXT current_result;
+ END IF;
-- Done paying the billing rows when we run out of rows to pay (out of bounds)
EXIT WHEN billing_offset = billing_row_count + 1;
END IF;
END IF;
current_result.amount = -current_result.amount;
- RETURN NEXT current_result;
+ IF current_result.amount <> 0.0 THEN
+ RETURN NEXT current_result;
+ END IF;
EXIT WHEN payment_remainder = 0.0;
-Payments by Billing Type Reporting Source Added
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+== Payments by Billing Type Reporting Source Added ==
+
A new reporting source named Payments by Billing Type has been added
that associates payments and billings and displays the amount of each
payment applied to those billings.
Tips for using this source:
-.To show workstations associated with Payments, follow the source path Payment by Billing Type --> Payment ID and then pull the appropriate field from the relevant Detail table (Cash, Check, Credit Card).
-.OPAC payments will show as accepted at the paying user's home library. In order for your report to show these payments, make sure the appropriate patron Organizational Unit is set in your report filter.
-.Be careful when you build your report to distinguish between Billing Organizational Unit and Payment Organizational Unit - they can be, but do not have to be, the same.
-.Due to the reporter's use of GROUP BY, it is recommended that you include the Billing ID in your report output in order to prevent the reporter from rolling up payment data into one line.
+
+. To show workstations associated with Payments, follow the source path Payment by Billing Type --> Payment ID and then pull the appropriate field from the relevant Detail table (Cash, Check, Credit Card).
+. OPAC payments will show as accepted at the paying user's home library. In order for your report to show these payments, make sure the appropriate patron Organizational Unit is set in your report filter.
+. Be careful when you build your report to distinguish between Billing Organizational Unit and Payment Organizational Unit - they can be, but do not have to be, the same.
+. Due to the reporter's use of GROUP BY, it is recommended that you include the Billing ID in your report output in order to prevent the reporter from rolling up payment data into one line.
projects / working / Evergreen.git / commitdiff