On the database I do a simple query and get the following results (we are multi-company but never actually use the company without the A) -
For some reason the vendor ID says 11016, yet in our “A” company we don’t even have a vendor on file with this ID…
All those invoices are actually for this supplier in our “A” company -
So why would the database have different information? When I go into the company without the “A” and look for this supplier’s (11016) invoices, there are none to be found - because we don’t use this company…
Am I just being stupid with the query and for some reason, not able to wrap my head around why we get the results?
Here’s a specific invoice that I know for a fact is not in the other company (and it not associated with the other supplier 11016) -
Why is it showing the invoice number associated with the vendor 11016 in the other company when there really isn’t any invoices in the other company?
VendorNum to see which vendor it thinks that
VendorID belongs to.
What is the VendorID for this particular supplier (the one with VendorNum 50) ?
So the company without the A (not being used) has the supplier ID as 11016 - this supplier has no invoices associated with it.
The company with the A (only company being used) has the supplier ID as 21035 - this supplier has all of the invoices associated with it.
So since my query connects the APInvHed and vendor tables together using the VendorNum field, that would be the reason why the invoices show incorretly for the company without the A?
Vendor.Company = ApInvHed.Company
to the join
Oh duh… Whoops!
That’s what did it - just a silly query mistake… This “issue” was brought to my attention by the Controller looking at the supplier tracker - I guess he saw some weird apply dates. I have no clue why the screen would show the wrong companies data… maybe he was accidentally clicked in the wrong company at the time? I don’t know
FWIW - You can change the VendorID field in Vendor Maintenance at any time. This is really more of a “shortcut” that users use instead of actually having to remember the VendorNum
This is why all references to a vendor should be done through the VendorNum.