we are using 1.3.1009, has anyone else experienced this or a similar problem in a multi-store environment:
we have two separate stores, a customer does one sale on account in each store. they send one check for both sales. we apply the payment in one of the stores at the POS. the account balance for the sale that was done at the same store where the payment is applied gets, zeroed out, but the other balance at the other store does not.
i know in hotfix 1010 it mentions that there is something that gets fixed having to do with making payments on account at one store when the sale originated in a different store, but it does not mention this specific problem.
has anyone else had this problem - and will the hotfix go back and fix what did not correctly post to the customer's account, or will we have to manually adjust their account balance?
we are using 1.3.1009, has anyone else experienced this or a similar problem in a multi-store environment:
we have two separate stores, a customer does one sale on account in each store. they send one check for both sales. we apply the payment in one of the stores at the POS. the account balance for the sale that was done at the same store where the payment is applied gets, zeroed out, but the other balance at the other store does not.
i know in hotfix 1010 it mentions that there is something that gets fixed having to do with making payments on account at one store when the sale originated in a different store, but it does not mention this specific problem.
has anyone else had this problem - and will the hotfix go back and fix what did not correctly post to the customer's account, or will we have to manually adjust their account balance?
Hi Todd, thanks for your reply - I've answered all of your questions below, right underneath each question. If you have any additional questions please let me know, and thank you very much for your help. Also, I currently have my email address to monitor set as snipped-for-privacy@win-4-u.com, do I need to change this and remove the NOSPAM in order for monitoring to by MSFT to work correctly? I was just trying to avoid getting spammed of of the board, just let me know. Thanks again
Kev> Good morning Kevin,
Todd this is not a one-time occurrence, but it only occurred when we posted a payment that was for both a local AR and a remote AR, or if a payment was posted for a remote AR only. The local AR posted correctly and reduced the balance but the remote AR did not.
Todd we have two stores, and after digging into this I've discovered that one store was running on 1.3.1010 while the other store (the one where the payments were posted) was running 1.3.1009. Is this what caused this problem, and if so, is there a way I can manually fix this so that the AR balances, the aging, and the statements are all correct? I am well versed in SQL and would be comfortable running queries if that were necessary
Yes this option is turned on at both of the stores. The AR's from the remote store do show up in the payment window when selecting a customer to post a payment. It just isn't reducing the balance after the payment transaction is tendered and completed. If you open the account payment window and select the customer again, that remote AR still shows as being due even after several worksheet 401's have been done
Yes, we are selecting both
When there is an overpayment, yes we do get this window, and we always choose yes to apply as a credit. In these cases where we had these issues though, there was not an overpayment
Hi Todd, thanks for your reply - I've answered all of your questions below, right underneath each question. If you have any additional questions please let me know, and thank you very much for your help. Also, I currently have my email address to monitor set as snipped-for-privacy@win-4-u.com, do I need to change this and remove the NOSPAM in order for monitoring to by MSFT to work correctly? I was just trying to avoid getting spammed of of the board, just let me know. Thanks again
Kev> Good morning Kevin,
Todd this is not a one-time occurrence, but it only occurred when we posted a payment that was for both a local AR and a remote AR, or if a payment was posted for a remote AR only. The local AR posted correctly and reduced the balance but the remote AR did not.
Todd we have two stores, and after digging into this I've discovered that one store was running on 1.3.1010 while the other store (the one where the payments were posted) was running 1.3.1009. Is this what caused this problem, and if so, is there a way I can manually fix this so that the AR balances, the aging, and the statements are all correct? I am well versed in SQL and would be comfortable running queries if that were necessary
Yes this option is turned on at both of the stores. The AR's from the remote store do show up in the payment window when selecting a customer to post a payment. It just isn't reducing the balance after the payment transaction is tendered and completed. If you open the account payment window and select the customer again, that remote AR still shows as being due even after several worksheet 401's have been done
Yes, we are selecting both
When there is an overpayment, yes we do get this window, and we always choose yes to apply as a credit. In these cases where we had these issues though, there was not an overpayment
Hi Todd - I'll continue posting to the newsgroup with the email you noted below, just wanted to make sure i was doing it right, I asked this questions through a support request on customersource, and was led to believe that I needed to change it, so i hope i don't get charged anything for that
- I checked, and the HQID for each customer is the same at both stores, they match
- I ran the query against the ARHistoryMirror table for each of those payments, and in each case, the IsProcessed field was set to '1' which I assumed means that it is 'checked' or it's what it should be if the payment was processed successfully - so I did not run the UPDATE statement
- I haven't run any queries against the AccountReceivable or the AccountReceivableHistory tables, except for some SELECT queries where I was just looking at the some of the AR records for these customers - nothing has been changed though
Todd I have another update for you - we got both stores on the same build the other day. Well we posted another payment at Store 2 that was for a sale on account done at Store 1, and it is still not showing the balance due getting taken off, something is wrong. In the past we've had lots of these types of payments, and looking back, I'm sure this worked fine right before we went to
1.3.1010. We've never had this issue in the past when processing these types of payments, and none of our configuration settings at the store, HQ, or on client have been changed since then.
Could this be a bug?? Have you been able to test this and repeat the problem, or has anyone else had a the same problem when processing payments for multiple stores?
Hi Todd - I'll continue posting to the newsgroup with the email you noted below, just wanted to make sure i was doing it right, I asked this questions through a support request on customersource, and was led to believe that I needed to change it, so i hope i don't get charged anything for that
- I checked, and the HQID for each customer is the same at both stores, they match
- I ran the query against the ARHistoryMirror table for each of those payments, and in each case, the IsProcessed field was set to '1' which I assumed means that it is 'checked' or it's what it should be if the payment was processed successfully - so I did not run the UPDATE statement
- I haven't run any queries against the AccountReceivable or the AccountReceivableHistory tables, except for some SELECT queries where I was just looking at the some of the AR records for these customers - nothing has been changed though
Todd I have another update for you - we got both stores on the same build the other day. Well we posted another payment at Store 2 that was for a sale on account done at Store 1, and it is still not showing the balance due getting taken off, something is wrong. In the past we've had lots of these types of payments, and looking back, I'm sure this worked fine right before we went to
1.3.1010. We've never had this issue in the past when processing these types of payments, and none of our configuration settings at the store, HQ, or on client have been changed since then.
Could this be a bug?? Have you been able to test this and repeat the problem, or has anyone else had a the same problem when processing payments for multiple stores?
The record is there and the remotestoreID is the ID of the store where the sale was originally made, also the remoteARID matches the ID of the record in the AccountReceivable table in the store database where the sale was made, so that looks correct. Isprocessed is also set to '1'.
This record exists, but instead of the Balance being 0, the Balance still equals the OriginalAmount
Todd, I checked and this record does exist in the ARHistoryMirror table, in the HQ database
Todd I looked through our event log viewer, first for the store that processed the payment. I looked at the 401 worksheet that was done immediately after we did a batch of 10 payments where 1 of these payments was for a sale done at the other store. It did show 10 records were written to AccountReceivable and 10 records were written to AccountReceivableHistory. It also shows that 1 record was written to ARHistoryMirror. I presume that is the payment for the sale that was done at the other store.
When I look at the log for the 401 worksheet done at the other store at the same, and at all of the 401's that were done subsequent to that I do not see any indication that anything was processed for the ARHistoryMirror table
Also no records uploaded for the AccountReceivable or the AccountReceivableHistory table. When I do a select query on the AccountReceivableHistory table for the original sale store and on the same table in the HQ database, there is a record for the original sale, but there is no record for the subsequent payment
I queried the AccountReceivable table in the store where the purchase was made, and all of the records in that table have a storeID of 1, which is correct for that store
The record is there and the remotestoreID is the ID of the store where the sale was originally made, also the remoteARID matches the ID of the record in the AccountReceivable table in the store database where the sale was made, so that looks correct. Isprocessed is also set to '1'.
This record exists, but instead of the Balance being 0, the Balance still equals the OriginalAmount
Todd, I checked and this record does exist in the ARHistoryMirror table, in the HQ database
yes that's correct, and yes i did run that update statement
yes all of the records in ARHistoryMirror, including the ones I'm having the issues with, have a RemotePaymentID
I will do that - we also reindex the databases every night as part of our regular maintenance
the sales from the original sales store all show up in HQ
yes it does
we have restored from a backup but that a long time ago, shortly after we got RMS, probably at least two years
there are 32 records in ARHistoryMirror at the store where we normally collect the payments there are 151 records at the other store and there are 183 records in ARHistoryMirror in the HQ database
there are 183 records in ARHistoryMirror at HQ
The payment does not exist here in this table
no there are not, all records in this table have and AccountReceivableID
no there are not, all have an associated accountreceivablehistory record
yes that's correct, and yes i did run that update statement
yes all of the records in ARHistoryMirror, including the ones I'm having the issues with, have a RemotePaymentID
I will do that - we also reindex the databases every night as part of our regular maintenance
the sales from the original sales store all show up in HQ
yes it does
we have restored from a backup but that a long time ago, shortly after we got RMS, probably at least two years
there are 32 records in ARHistoryMirror at the store where we normally collect the payments there are 151 records at the other store and there are 183 records in ARHistoryMirror in the HQ database
there are 183 records in ARHistoryMirror at HQ
The payment does not exist here in this table
no there are not, all records in this table have and AccountReceivableID
AccountReceivableID
no there are not, all have an associated accountreceivablehistory record
BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.