Sage 100

To confirm - if you go into the Remit To, there is a different address there than what shows on the check AND the Main tab address is ALSO not what shows on the check?  If it's the Main address, they unchecked the Print Remit to on their check printing.  If it's neither address, then... gremlins.

Yes it's odd - the client has a screen shot of the check ( I can't verify that they actually check "print remit to" ) however the address on the check doesn't match either of the vendor master or remit to. They claim it's an old address.

The other wildcard could be someone it restoring a table though that seems unlikely to me.

To confirm - if you go into the Remit To, there is a different address there than what shows on the check AND the Main tab address is ALSO not what shows on the check?  If it's the Main address, they unchecked the Print Remit to on their check printing.  If it's neither address, then... gremlins.

Or someone updated after the check run.  You can bring up the Remit to and right click and see what the last date updated was (unless they've fixed it by now)

Yes it's odd - the client has a screen shot of the check ( I can't verify that they actually check "print remit to" ) however the address on the check doesn't match either of the vendor master or remit to. They claim it's an old address.

The other wildcard could be someone it restoring a table though that seems unlikely to me.

To confirm - if you go into the Remit To, there is a different address there than what shows on the check AND the Main tab address is ALSO not what shows on the check?  If it's the Main address, they unchecked the Print Remit to on their check printing.  If it's neither address, then... gremlins.

They did fix it - and when I look on the audit viewer I only see the person making the fix. There isn't any other record that looks like someone went in and changed it by mistake earlier. Leading me to think it is either (a) bug, (b) someone restored over the table  (c) some type of VI Job ( I looked but don't see any likely suspects) or (d) they're using some type of AP solution that had a sync glitch

Or someone updated after the check run.  You can bring up the Remit to and right click and see what the last date updated was (unless they've fixed it by now)

Yes it's odd - the client has a screen shot of the check ( I can't verify that they actually check "print remit to" ) however the address on the check doesn't match either of the vendor master or remit to. They claim it's an old address.

The other wildcard could be someone it restoring a table though that seems unlikely to me.

To confirm - if you go into the Remit To, there is a different address there than what shows on the check AND the Main tab address is ALSO not what shows on the check?  If it's the Main address, they unchecked the Print Remit to on their check printing.  If it's neither address, then... gremlins.

Any changes should show up on the audit report (manual, VI...) assuming you have the AP Option set to track "All" changes.

They did fix it - and when I look on the audit viewer I only see the person making the fix. There isn't any other record that looks like someone went in and changed it by mistake earlier. Leading me to think it is either (a) bug, (b) someone restored over the table  (c) some type of VI Job ( I looked but don't see any likely suspects) or (d) they're using some type of AP solution that had a sync glitch

Or someone updated after the check run.  You can bring up the Remit to and right click and see what the last date updated was (unless they've fixed it by now)

Yes it's odd - the client has a screen shot of the check ( I can't verify that they actually check "print remit to" ) however the address on the check doesn't match either of the vendor master or remit to. They claim it's an old address.

The other wildcard could be someone it restoring a table though that seems unlikely to me.

To confirm - if you go into the Remit To, there is a different address there than what shows on the check AND the Main tab address is ALSO not what shows on the check?  If it's the Main address, they unchecked the Print Remit to on their check printing.  If it's neither address, then... gremlins.

It seems to be tracking all changes because I do see changes going back almost 10 years.

They also have Concur which I've added to my list of likely suspects...(in order of easiest explanation for the problem)

1. Bug
2. VI 
3. Third party ( Concur )
4. Someone restored over Sage data

Any changes should show up on the audit report (manual, VI...) assuming you have the AP Option set to track "All" changes.

They did fix it - and when I look on the audit viewer I only see the person making the fix. There isn't any other record that looks like someone went in and changed it by mistake earlier. Leading me to think it is either (a) bug, (b) someone restored over the table  (c) some type of VI Job ( I looked but don't see any likely suspects) or (d) they're using some type of AP solution that had a sync glitch

Or someone updated after the check run.  You can bring up the Remit to and right click and see what the last date updated was (unless they've fixed it by now)

Yes it's odd - the client has a screen shot of the check ( I can't verify that they actually check "print remit to" ) however the address on the check doesn't match either of the vendor master or remit to. They claim it's an old address.

The other wildcard could be someone it restoring a table though that seems unlikely to me.

To confirm - if you go into the Remit To, there is a different address there than what shows on the check AND the Main tab address is ALSO not what shows on the check?  If it's the Main address, they unchecked the Print Remit to on their check printing.  If it's neither address, then... gremlins.

Also look for a modified report / form.  That could easily explain inconsistencies.

It seems to be tracking all changes because I do see changes going back almost 10 years.

They also have Concur which I've added to my list of likely suspects...(in order of easiest explanation for the problem)

1. Bug
2. VI 
3. Third party ( Concur )
4. Someone restored over Sage data

Any changes should show up on the audit report (manual, VI...) assuming you have the AP Option set to track "All" changes.

They did fix it - and when I look on the audit viewer I only see the person making the fix. There isn't any other record that looks like someone went in and changed it by mistake earlier. Leading me to think it is either (a) bug, (b) someone restored over the table  (c) some type of VI Job ( I looked but don't see any likely suspects) or (d) they're using some type of AP solution that had a sync glitch

Or someone updated after the check run.  You can bring up the Remit to and right click and see what the last date updated was (unless they've fixed it by now)

Yes it's odd - the client has a screen shot of the check ( I can't verify that they actually check "print remit to" ) however the address on the check doesn't match either of the vendor master or remit to. They claim it's an old address.

The other wildcard could be someone it restoring a table though that seems unlikely to me.

To confirm - if you go into the Remit To, there is a different address there than what shows on the check AND the Main tab address is ALSO not what shows on the check?  If it's the Main address, they unchecked the Print Remit to on their check printing.  If it's neither address, then... gremlins.

Also look for a modified report / form.  That could easily explain inconsistencies.

It seems to be tracking all changes because I do see changes going back almost 10 years.

They also have Concur which I've added to my list of likely suspects...(in order of easiest explanation for the problem)

1. Bug
2. VI 
3. Third party ( Concur )
4. Someone restored over Sage data

Any changes should show up on the audit report (manual, VI...) assuming you have the AP Option set to track "All" changes.

They did fix it - and when I look on the audit viewer I only see the person making the fix. There isn't any other record that looks like someone went in and changed it by mistake earlier. Leading me to think it is either (a) bug, (b) someone restored over the table  (c) some type of VI Job ( I looked but don't see any likely suspects) or (d) they're using some type of AP solution that had a sync glitch

Or someone updated after the check run.  You can bring up the Remit to and right click and see what the last date updated was (unless they've fixed it by now)

Yes it's odd - the client has a screen shot of the check ( I can't verify that they actually check "print remit to" ) however the address on the check doesn't match either of the vendor master or remit to. They claim it's an old address.

The other wildcard could be someone it restoring a table though that seems unlikely to me.

It seems to be tracking all changes because I do see changes going back almost 10 years.

They also have Concur which I've added to my list of likely suspects...(in order of easiest explanation for the problem)

1. Bug
2. VI 
3. Third party ( Concur )
4. Someone restored over Sage data

Any changes should show up on the audit report (manual, VI...) assuming you have the AP Option set to track "All" changes.

They did fix it - and when I look on the audit viewer I only see the person making the fix. There isn't any other record that looks like someone went in and changed it by mistake earlier. Leading me to think it is either (a) bug, (b) someone restored over the table  (c) some type of VI Job ( I looked but don't see any likely suspects) or (d) they're using some type of AP solution that had a sync glitch

Or someone updated after the check run.  You can bring up the Remit to and right click and see what the last date updated was (unless they've fixed it by now)

Yes it's odd - the client has a screen shot of the check ( I can't verify that they actually check "print remit to" ) however the address on the check doesn't match either of the vendor master or remit to. They claim it's an old address.

The other wildcard could be someone it restoring a table though that seems unlikely to me.

To confirm - if you go into the Remit To, there is a different address there than what shows on the check AND the Main tab address is ALSO not what shows on the check?  If it's the Main address, they unchecked the Print Remit to on their check printing.  If it's neither address, then... gremlins.

And I'm looking on their server at a Concur file - config.json - which I guess maybe I have access to as an admin. The SA for their SQL server seems to be stored in plain text... 

It seems to be tracking all changes because I do see changes going back almost 10 years.

They also have Concur which I've added to my list of likely suspects...(in order of easiest explanation for the problem)

1. Bug
2. VI 
3. Third party ( Concur )
4. Someone restored over Sage data

Any changes should show up on the audit report (manual, VI...) assuming you have the AP Option set to track "All" changes.

They did fix it - and when I look on the audit viewer I only see the person making the fix. There isn't any other record that looks like someone went in and changed it by mistake earlier. Leading me to think it is either (a) bug, (b) someone restored over the table  (c) some type of VI Job ( I looked but don't see any likely suspects) or (d) they're using some type of AP solution that had a sync glitch

Or someone updated after the check run.  You can bring up the Remit to and right click and see what the last date updated was (unless they've fixed it by now)

Yes it's odd - the client has a screen shot of the check ( I can't verify that they actually check "print remit to" ) however the address on the check doesn't match either of the vendor master or remit to. They claim it's an old address.

The other wildcard could be someone it restoring a table though that seems unlikely to me.

To confirm - if you go into the Remit To, there is a different address there than what shows on the check AND the Main tab address is ALSO not what shows on the check?  If it's the Main address, they unchecked the Print Remit to on their check printing.  If it's neither address, then... gremlins.

Maybe one of the work tables isn't getting cleared.