problem with posting payments on account for multiple stores??

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?
thanks kevin
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
: 7bit
Good morning Kevin, Thank you for posting your account payment question. As you stated the issue resolved in hotfix 1.3.1010 is not what you are experiencing; and as such applying the hotfix would not resolve the issue. Can you please let me know: 1. Does this occur for all payments? or Is this just a one time occurrence? 2. Is the same build, 1.3.1009, showing in all applications at all stores and HQ? HQ Admin, HQ Manager, HQ Client, HQ Server, SO Admin, SO Manager, SO POS 3. Is the option enabled at the store to Connect to HQ to get a customer's open AR's? Manager | File | Configuration | Options | Customer Options. NOTE: If this option is not enabled the AR's from the 2nd store would not show up in the payment window. 4. Are you selecting both the local and remote ARs when payments are made? 5. After making a payment does a window come up stating that there is an overpayment? If so are you choosing Yes to apply to Credit or No to Refund.
6. If you pull up this customer at the store where the payment was made are there any local credits? 7. If there are local credits is the amount the same as the ARs that are not showing as paid at the remote store? 8. Has the remote store connected, and ran a 401, after the payment was made? Thank you in advance. Todd Berger Microsoft Online Support Engineer
Get Secure! - www.microsoft.com/security ====================================================When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ====================================================This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
Subject: problem with posting payments on account for multiple stores?? Date: Thu, 8 Mar 2007 12:38:35 -0800
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?
thanks kevin
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
Kevin
"Todd Berger [MSFT]" wrote:

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

No there are not any local credits.

No - see above

Yes, many times since the payment was posted

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
: 7bit
Good morning Kevin, Thank you for the updates. You will want to post your questions to this newsgroup using the same address that you set up to monitor: snipped-for-privacy@win-4-u.com. As far as the remote payment not being applied: 1. Check to ensure if the customer's HQID is the same at both stores; and that this matches the ID at HQ for the customer: a. Run the following at the store where the payment was made; and note the HQID set for this customer (Administrator | File | Connect | Query | New | Enter Select statement | Press F5) NOTE: X is the customer account number. Select HQID, AccountNumber from Customer where AccountNumber = 'X' b. Run the following at the store where the purchase was made; and note the HQID set for this customer (Administrator | File | Connect | Query | New | Enter Select statement | Press F5) NOTE: X is the customer account number. Select HQID, AccountNumber from Customer where AccountNumber = 'X' c. Run the following at HQ; and note the ID set for this customer (Administrator | File | Connect | Query | New | Enter Select statement | Press F5) NOTE: X is the customer account number; and the ID at HQ should match the HQID for this customer at each store. Select ID, AccountNumber from Customer where AccountNumber = 'X' 2. Check to see if the IsProcessed box is checked on the payment at the store where they payment was made: a. Run the following at the store where the payment was made; and note the ID of the payment if the box is not checked. (Administrator | File | Connect | Query | New | Enter Select statement | Press F5) NOTE: Y is the payment amount. For example, -25.86. select * from ARHistoryMirror where payment = 'y' b. If the box is not checked in the above select statement try making a backup of the database and running the following: NOTE: Z is the ID noted from the above. Update ARHistoryMirror set RemoteStoreID = RemoteStoreID where id = Z c. If you ran the update statement in b. above connect via HQ Client and process a 401 from the store where the payment was made; and after that finishes connect via HQ Client and process a 401 for the store where the purchase was made. 3. Have any SQL scripts been run at HQ, or the store where the purchase was made, that may affect the AccountReceivable or AccountReceivableHistory tables? Please let me know what you find out. Todd Berger Microsoft Online Support Engineer
Get Secure! - www.microsoft.com/security ====================================================When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ====================================================This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
Subject: RE: problem with posting payments on account for multiple stores?? Date: Tue, 13 Mar 2007 12:27:16 -0700
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
Kevin
"Todd Berger [MSFT]" wrote:

occurrence?
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

customer's

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

Refund.
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

are

No there are not any local credits.

No - see above

Yes, many times since the payment was posted

rights.
of

what

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
1. - I checked, and the HQID for each customer is the same at both stores, they match
2. - 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
3. - 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
Any other ideas? Thanks for helping me w/ this
Kevin
"Todd Berger [MSFT]" wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
: 7bit
Good morning Kevin,
Thank you for the update. The next thing we need to do is determine if the RemoteStoreID is showing the correct ID for the store where the purchase was made; and the RemoteARID is the AccountReceivable.ID for the purchase. 1. Run the following query at the store where the payment was made; and note the RemoteStoreID and RemoteARID. select * from ARHistoryMirror where payment = 'y' 2. Run the following query at the store where the purchase was made to ensure that the record still exists and the amount, storeid, etc. are correct. Note: X is the RemoteARID from the query in step 1; and the StoreID in the AccountReceivable table should match the RemoteStoreID from the query in step 1. select * from AccountReceivable where ID = X 3. We can also try to run the following at the store where the payment was made in case the information from the ARHistoryMirror table did not make it to HQ: NOTE: the Z is the id from the ARHistoryMirror table record returned in step 1.
Update ARHistoryMirror set RemoteStoreID = RemoteStoreID where id = Z 4. We can also check to ensure that the ARHistoryMirror record exists at HQ. NOTES: The X is the StoreID from the query in step 1; and the Y is the ID of the record from the query in step 1. The RemoteStoreID, RemoteARID, etc. on the returned row should match what is found at the store where the payment was made. Select * from ARHistoryMirror where StoreID = X and ID = Y
Thank you in advance. Todd Berger Microsoft Online Support Engineer
Get Secure! - www.microsoft.com/security ====================================================When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ====================================================This posting is provided "AS IS" with no warranties, and confers no rights. --------------------
Subject: RE: problem with posting payments on account for multiple stores?? Date: Wed, 14 Mar 2007 07:05:05 -0700
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
1. - I checked, and the HQID for each customer is the same at both stores, they match
2. - 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
3. - 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
Any other ideas? Thanks for helping me w/ this
Kevin
"Todd Berger [MSFT]" wrote:

the

|
the

|
the

was

rights.
stores??
below,

have
to

issue.
posted

was

the

stores

Manager,

the

versed

to

not

made?
an

issues

are

so

each

one

at

fixed

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Good morning Todd, I've placed answers by your questions below:
"Todd Berger [MSFT]" wrote:

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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
: 7bit
Good afternoon Kevin, Thank you for the follow up. In testing the IsProcessed is not set to 1 until after the store where the purchase was made connects and processes a worksheet 401.
You stated that the AR exists at the store where the purchase was made and the amount is the original amount of the transaction. I am assuming that the StoreID is also correct for this record; and that you ran the following query at the store where the payment was made: Update ARHistoryMirror set RemoteStoreID = RemoteStoreID where id = Z
Can you also: 1. Check to see if the ARHistoryMirror record shows a RemotePaymentID? select * from ARHistoryMirror where RemotePaymentID = 0 2. Make a backup of the store and HQ databases and run Database | Check and Database | Reindex against all 3 databases. 3. Let me know if sales, etc. from the store where the ARs were made are still showing up at HQ? 4. Does the database name in HQ Client | File | Configuration at the store where the ARs were created match the database name if you take a look in Store Operations Administrator | File | Configuration? 5. Have they ever restored the HQ or store databases from backup? 6. How many records are in the ARHistoryMirror table at the store?
select count(id) from arhistorymirror 7. How many records exist in the ARHistoryMirror table at HQ for this store? Note: X is the id for the store where the payment was made. select count(id) from arhistorymirror where storeid = x 8. Check to see if the payment exists in the AccountReceivableHistory table of the store where the purchase was made. NOTE: This query will bring back a listing of all remote payments. select * from AccountReceivableHistory where RemotePaymentID <> 0 9. check to see if there are any entries in the AccountReceivableHistory table, at the store where the purchase was made, where there is not an associated AccountReceivable record: select * from AccountReceivableHistory where AccountReceivableID not in (select ID from AccountReceivable)
10. Check to see if there are any AccountReceivable entries where there are no associated AccountReceivableHistory records: select * from AccountReceivable where ID not in (select AccountReceivableID from AccountReceivableHistory)
Note: I will continue to assist as much as possible; but this may be an issue with your database(s) and if so you may need to contact Technical Support to see if they can resolve the issue and if not it may need to go through Professional Services if database repair is required.
Thank you in advance. Todd Berger Microsoft Online Support Engineer
Get Secure! - www.microsoft.com/security ====================================================When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ====================================================This posting is provided "AS IS" with no warranties, and confers no rights. --------------------
Subject: RE: problem with posting payments on account for multiple stores?? Date: Fri, 16 Mar 2007 09:29:03 -0700
Good morning Todd, I've placed answers by your questions below:
"Todd Berger [MSFT]" wrote:

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'.

the

This record exists, but instead of the Balance being 0, the Balance still equals the OriginalAmount

was

it

HQ.
etc.

Todd, I checked and this record does exist in the ARHistoryMirror table, in the HQ database

rights.
stores??
I
stores,

payment

was

and

New

New

|
the

and

the

so

need

are

that

AR

Options.
being

made

was

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Todd see my answers below:
"Todd Berger [MSFT]" wrote:

that is correct

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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
: 7bit
Good afternoon Kevin, Thank you for the follow up. I would try: 1. Make a backup of all store and hq databases; and try running the following at HQ to see if the payment shows up: NOTES: The X is the ID of the RemoteARID from the ARHistoryMirror table at the store where the payment was made; and the Y is the StoreID of the store where the payment was made. To ensure that you are updating the correct record you may first want to run this query at HQ: select * from arhistorymirror where remotearid = x and storeid = y. update arhistorymirror set isprocessed = 0 where remotearid = x and storeid = y 2. Try making a purchase on account where the payments are normally taken; and pay that AR off at the other store. Then see if the payment ends up showing up. Thank you in advance. Todd Berger Microsoft Online Support Engineer
Get Secure! - www.microsoft.com/security ====================================================When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ====================================================This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
Subject: RE: problem with posting payments on account for multiple stores?? Date: Fri, 16 Mar 2007 12:46:02 -0700
Todd see my answers below:
"Todd Berger [MSFT]" wrote:

the

and

that is correct

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

and

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

store

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

store?
there are 183 records in ARHistoryMirror at HQ

table

The payment does not exist here in this table

no there are not, all records in this table have and AccountReceivableID

are

AccountReceivableID

no there are not, all have an associated accountreceivablehistory record

rights.
stores??
showing

the

record

made,

in

make

at

ID

in

so

noted

that

those

I
nothing

note

note

statement

the

note

a
that

purchase

AccountReceivableHistory

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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?
Thanks Kevin
"Todd Berger [MSFT]" wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
: 7bit
Good afternoon Kevin, Thank you for the update. I am unable to recreate this issue; and as such do not feel it is a bug. 1. After making a payment does a 401 from the store where the payment was made show the following in HQ Client? "Uploaded X Record(s) from table 'ARHistoryMirror'" 2. After making a payment, and uploading the information from that store to HQ, does the store where the purchase was made show the following in HQ Client when running a 401? "Downloaded and processed X record(s) from table 'ARHistoryMirror'" In this connection you should also see the following: "Uploaded x record(s) from table 'AccountReceivable'" "Uploaded x record(s) from table 'AccountReceivableHistory'" The only thing I can think of is that the StoreID, in the AccountReceivable table at the Store where the purchase was made is not correct; or the ID no longer exists in the AccountReceivable table at the store where the purchase was made. For example, if I set the StoreID for one of the records = 0, and it is really store 1, then the remote payment cannot be applied because it links on both ID and StoreID. Hopefully this helps. Todd Berger Microsoft Online Support Engineer
Get Secure! - www.microsoft.com/security ====================================================When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ====================================================This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
Subject: RE: problem with posting payments on account for multiple stores?? Date: Thu, 15 Mar 2007 09:54:10 -0700
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?
Thanks Kevin
"Todd Berger [MSFT]" wrote:

the

|
the

|
the

was

rights.
stores??
below,

have
to

issue.
posted

was

the

stores

Manager,

the

versed

to

not

made?
an

issues

are

so

each

one

at

fixed

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Todd Berger [MSFT]" wrote:

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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

BeanSmart.com is a site by and for consumers of financial services and advice. We are not affiliated with any of the banks, financial services or software manufacturers discussed here. All logos and trade names are the property of their respective owners.

Tax and financial advice you come across on this site is freely given by your peers and professionals on their own time and out of the kindness of their hearts. We can guarantee neither accuracy of such advice nor its applicability for your situation. Simply put, you are fully responsible for the results of using information from this site in real life situations.