Payment does not show in BCOL for Registration in Modernized System #19532
Comments
|
I will check the account this morning to see if something was posted since yesterday. I will attach the acct debits since yesterday. |
|
@lbergero819 just to confirm, the issue here is that Sharon completed a transaction for new Registration in the modernized system and then did the Transport Permit in the legacy system. Are you stating neither the new registration or the transport permit from legacy are showing in BCOL? Or is just one transaction missing in BCOL? |
mstanton1
changed the title
|
Modernized registrations do not set the legacy DB2 document.bcolacct value. Maybe this is causing a problem for legacy change registration payments? |
|
Should we ask John McColl to check
From: Doug Lovett ***@***.***>
Sent: Friday, January 26, 2024 10:28 AM
To: bcgov/entity ***@***.***>
Cc: Bergeron, Louise CITZ:EX ***@***.***>; Mention ***@***.***>
Subject: Re: [bcgov/entity] Payment does not show in BCOL for Registration in Modernized System (Issue #19532)
[EXTERNAL] This email came from an external source. Only open attachments or links that you are expecting from a known sender.
Modernized registrations do not set the legacy DB2 document.bcolacct value. Maybe this is causing a problem for legacy change registration payments?
—
Reply to this email directly, view it on GitHub<#19532 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AT3A4LZX6Q5WEAGFDRWEX23YQPYRTAVCNFSM6AAAAABCMNY2DSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJSGUYDEMBUGI>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
|
@lbergero819 @doug-lovett do modernized search's set the legacy DB2 document.bcolacct value? Search is correctly writing back to BC Online. If we aren't setting the legacy document.bcolacct value for search we can assume that isn't the issue. @lbergero819 have you checked with Patty on whether she could take a look? cc @arlentees |
|
After meeting with Louise and John M, here is the issue: As an example, a new MH registration for MHR 108186 was created with a timestamp of 2024-01-25 22:07:58 UTC (2:07 PM). From the MHR API log, the Pay API request data is: And the Pay API response is: @mstanton1 from the response, it looks like no fee was charged even though the BCOL account info was submitted and payment was not waived (no fee). Can you verify the PROD fee is set up correctly for INREG? |
|
Patty is on flex today, Darci does not know anything about how it would be set up for the new system. I can try John
From: mstanton1 ***@***.***>
Sent: Friday, January 26, 2024 11:51 AM
To: bcgov/entity ***@***.***>
Cc: Bergeron, Louise CITZ:EX ***@***.***>; Mention ***@***.***>
Subject: Re: [bcgov/entity] Payment does not show in BCOL for Registration in Modernized System (Issue #19532)
[EXTERNAL] This email came from an external source. Only open attachments or links that you are expecting from a known sender.
@lbergero819<https://github.com/lbergero819> @doug-lovett<https://github.com/doug-lovett> do modernized search's set the legacy DB2 document.bcolacct value? Search is correctly writing back to BC Online. If we aren't setting the legacy document.bcolacct value for search we can assume that isn't the issue.
@lbergero819<https://github.com/lbergero819> have you checked with Patty on whether she could take a look?
cc @arlentees<https://github.com/arlentees>
—
Reply to this email directly, view it on GitHub<#19532 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AT3A4L7VXABHCY7L4STFRNDYQQCI3AVCNFSM6AAAAABCMNY2DSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJSGYYDMNZXG4>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
|
@doug-lovett to you question on whether the INREG fee code is set up properly in PROD I can see it is set up with at 50.00 fee as expected. When I go into the edit screen I can also see it is mapped to the right distribution code (GL coding for modernized MHR system - Registrations). Looking at our fee requirements though, I notice that when policy did a deeper review of fee codes we had some duplication. INREG - Initial Registration was noted as being the same as Notice of Ownership (NTOWN) and since Notice of Ownership as a fee code better aligned with regulations that was recommended as the code we retained. I recall work with relationships, maybe @seeker25 to try to remove some fee codes which weren't needed (EXTTM, CORDS, AFFDV, INREG) and recall some issues with doing that because we were using / had used some of those codes. @seeker25 do you recall that? Was any change made to inactivate the fee code 'INREG'? |
|
@mstanton1 @seeker25 if we can retroactively apply a charge manually, the 4 INREG payment transactions identified in this ticket are invoice numbers: |
|
@doug-lovett @seeker25 is there a way to provide us with the MHR Registration number for those four invoices? |
|
MHR108186-7-8 |
|
@mstanton1 @lbergero819 Louise I think you identified 4 MHR registrations in the meeting today. Here they are with the registration timestamps: |
|
Sharon is asking if she should debit their BCOL account manually since they have not been charged for these registrations below.
I just wanted to make sure with you both Doug and Melissa, that you have not processed any payments behind the scene, I want to make sure they are not charged twice.
I will wait for your response and let Sharon know on Monday morning
Thanks
Louise
From: Doug Lovett ***@***.***>
Sent: Friday, January 26, 2024 4:00 PM
To: bcgov/entity ***@***.***>
Cc: Bergeron, Louise CITZ:EX ***@***.***>; Mention ***@***.***>
Subject: Re: [bcgov/entity] Payment does not show in BCOL for Registration in Modernized System (Issue #19532)
[EXTERNAL] This email came from an external source. Only open attachments or links that you are expecting from a known sender.
@mstanton1<https://github.com/mstanton1> @lbergero819<https://github.com/lbergero819> Louise I think you identified 4 MHR registrations in the meeting today. Here they are with the registration timestamps:
MHR Invoice
2024-01-25 22:07:58 108186 4640717
2024-01-25 22:22:59 108187 4640885
2024-01-25 22:28:27 108188 4640959
2024-01-25 22:31:52 108189 4641008
—
Reply to this email directly, view it on GitHub<#19532 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AT3A4L7DDOITLZFRD7CIX23YQQ7RNAVCNFSM6AAAAABCMNY2DSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJSHA2DMNJTG4>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
|
Adding @arlentees . Arlen, Doug also included timestamps and these are just from yesterday so we could ask the business re-enter the payment given it failed. It would be best to reach out to Jeff Zukowski and Sharon Merlino to request this is completed. The only other outstanding questions I would have are about how we ensure this failure doesn't keep happening. If this was from INREG being used as the code there would be a need to switch to NTOWN. If that takes place we need to verify the UI still shows the right wording in the fee code summary box, and would want to watch to make sure the first registration using that code worked properly. There may be an additional request needed to Patty Stemkens for support in making sure that maps to a BCOL fee code and shows in the legacy system. Let me know how I can assist when I'm back next week:) |
|
@mstanton1 Update on some conversations: Sharon will be able to go in and manually re-enter the payment. After discussing the issue with @doug-lovett the NTOWN code is associated with the description "Change of Ownership" and it would be best if the app could continue to use the INREG code and receive the correct charge amount from the Pay API. We will be reaching out today to Relationships to discuss activating the INREG code. |
|
INREG, is set to $50 in the pay-admin,
|
|
For tracking, from Louise's new registration in TEST, here is the pay api response with the correct $50 charge from the MHR API log: |
|
apply_filing_fees = 'f' for MHR, set by Melissa |
|
Requested by Doug to set apply_filing_fees = 't' for MHR |
|
@doug-lovett @arlentees @mstanton1 There is a comment above from Doug to set apply_filing_fees = 't' for MHR, is it something done by Melissa, it is it by a developer? If Melissa, Arlen and I should get a demo for setting that. |
|
Can be done in the interface:
|
|
@lbergero819 I checked in both TEST and PROD and the statutory fee is set to 'True'. The Service Fee in PROD was incorrectly set to $1.00 and has been updated in PROD to $1.50. That shouldn't have any impact though because the only time a Service Fee will apply with MHR is in the case where a client is completing their own MHR Search or MHR Combo Search. When staff complete a MHR or Combo search on a client's behalf different fee codes are used and no service fee applies. @seeker25 with the notes, I saw that you said the INREG was tied to a $50.00 fee (which I'd seen in the admin) yet we had a handful of cases where it didn't result in a charge. Did you take any action to edit that fee code to make it available for use again? @doug-lovett @seeker25 the four MHR registrations that were listed where a 0$ fee was charged are very recent. Was anything done to look further back and verify that other initial registrations performed by staff or pilot users are incurring fees? I could look at our pilot documents to pull the pilot users accounts? cc @arlentees |
|
@mstanton1 as Travis noted above, he flipped the PROD apply_filing_fees flag from false to true yesterday afternoon for the INREG filing type. I have not reviewed other PROD staff MH registrations to see if a fee was missed. We do not save payment details in the MHR database, only the invoice ID, so the only way for assets to research if staff applied a payment is to review the API logs. |
|
@doug-lovett thank you. Given we don't save payment in the MHR database, would it make more sense for you to just query all the MHR registrations done in the new system and we could then seek relationships support in looking those up in auth to confirm if fees were taken? Ultimately, we will need to be able to confirm the full set of impacted MHR's and then @arlentees and I can work with the business and report up on the issue. |
|
@doug-lovett I've taken the payload above and recharged, could you re-associate to this invoice?
request: Response: |
|
Here are the invoices after the filing fee update December 22nd/23rd?: |
|
@mstanton1 @doug-lovett let me know which other fields you need in this query, I see filingId, but it's only populated some of the time |
|
@doug-lovett @seeker25 the list above shows the Manufactured Home Registrations that have a 0$ charge, but doesn't identify the Manufactured Home Registration numbers. It sounds like we might need to look these up from the Assets side. @doug-lovett are you able to run a query to list all MHR Registration Numbers from December 22nd to current for New Registrations in the modernized system? |
|
@mstanton1 @seeker25 Attached below are the MH registrations from 2023-12-22 to now with the pay invoice id. Travis, from the pay invoice id can you find the request payment information (BCOL account, DAT)? |
|
Do not process / re-process the payments for these production MHR (from the ticket description as specified below). These are the original payments reported as not working and staff has reprocessed the payments manually already. The registration numbers are MHR108186-7-8), |
|
@doug-lovett @seeker25 Do not process / re-process the payments for these production MHR (from the ticket description as specified below). These are the original payments reported as not working and staff has reprocessed the payments manually already. The registration numbers are MHR108186-7-8), |
|
Ok, I'll refund the one I just did and email you and Sharon.
|
|
|
@seeker25 thanks Travis. @mstanton1 from Travis's query results above, and given that Sharon manually applied the charges for the 4 2024-01-25 registrations, it looks like there is no further action. The remaining staff registrations in this period are all no fee. |
|
@seeker25 @mstanton1 @arlentees @doug-lovett If you find other charges to be applied Sharon wants to see and approve the list before any action is taken to re-process the payments. |
|
@lbergero819 Doug provided a list above with MHR registration numbers since the date the issue arose. Travis provided a list showing which payments were taken. From that it appears about 24 payments failed, all of which were staff. Client payments show the 50.00 charge. I will compile a list of only those that did not include payment in an email which will need to be sent to the business but should include leads as well (Sharon, Jeff, Megan). I will have that sent off today and we can start to look at resolution. |
|
I have sent a list to Sharon, Jeff and Megan advising of the issue and requesting the businesses support in re-charging. I only included lines which showed a 0$ total and 0$ paid value in the screenshot above. MHR Registration Number Invoice Number Date Dat Number BCOL Account |
|
@seeker25 we met with the business and in the further discussion they noted a number of initial registrations are sent in from Service BC offices. In those cases they would choose the 'No Fee' option in the staff payment modal since payment was collected at Service BC. @doug-lovett mentioned there is a waive_fee flag. Are you able to update the query you'd run above to also include the waive_fee flag? |
|
@arlentees @mstanton1 the payment reversal has been completed by Sharon successfully. |
|
We'll have to reconcile this later with PAY. Technically by manually adjusting in BCOL there are monetary transactions in BCOL that don't exist in PAY and no invoice reference that ties from PAY to BCOL I believe. (KEY column, doesn't have REG in it in COLIN) Also there isn't any linkage in MHR/PPR -> Pay (besides the linkage to a $0 invoice, perhaps if we could update the invoice to the correct value it would match up, but we're still missing an invoice reference from PAY -> BCOL). @pstemkens probably something we need to look at later -^ |
|
@seeker25 it looks like the fee code MHR400 is not configured correctly on the mainframe. Its showing as a negative. I checked a few other fee codes and none of them show as a negative.
|
|
@pstemkens what is the impact of the MHR400 being configured as a negative? A good comparison for how this should work would be MHR Search or one of the PPR codes. I could provide a fee code for comparison in the new system if needed? |
|
@pstemkens @mstanton1 @arlentees @lbergero819 This is not a negative, this is just the way it displays when setting a fix rate. |
|
@lbergero819 @pstemkens it seems like there might be a need to meet and discuss. I'm not actually sure where MHR400 would play in. We are using the code INREG in the modernized system and I lack the knowledge of how that maps back to the legacy system. With this ticket becoming unwieldly I'd recommend we look at breaking it down into a few smaller tickets with clear objectives so we can reduce the number of comments in one spot. For this ticket the first issue was the use of a code that wasn't collecting fees. INREG is activated and being used again. The two other pieces that could possibly be logged separately in my opinion are:
|
|
I think we only use BMHRVC1,CMHRVC1,BMHRVC2,BMHRVC3 from pay-api |
|
@lbergero819 @pstemkens @seeker25 @arlentees MHR400 is only used when the filing is done from the mainframe and is working fine. As recommended by Melissa above, I will create 2 new tickets: 1) for Verifying BCOL mapping for INREG and 2) Ensuring past transactions using INREG have all incurred a fee / collecting fees on any that are outstanding. |
|
@mstanton1 @arlentees |
Sharon has reported that there was no fee debited in BCOL for the registrations she performed in the new system for RBC condos acct 274888 (fee code MHR400 in BCOL $50 when filing done in legacy system). The registration numbers are MHR108186-7-8) and the fees were not debited from their BCOL acct 274888.
Note: In the modernized system Initial Registration uses MHR Fee Code NTOWN.
The text was updated successfully, but these errors were encountered: