AKPolarBear
MIS
I have discovered an anomaly that is partially known but have never seen it used (abused) in this way. This is more of a comment than a question but maybe somebody has seen similar and knows why it did what it did.
A customer called yesterday about an invoice they received. The billing info was correct and one of the 2 line items was expected but the other item billed was not even close to what they had ordered or received.
Basically they ordered oranges and got billed for lemons (not the real items). Looking up the OE, it showed lemons ordered and as invoiced.
However, Salesman A (SalesA) who wrote the order produced a paper copy of the OE showing oranges. Wait, how can that be?
A review of the OE Audit showed another salesman, Salesman B (SalesB) for a different customer had opened the OE first (with that number) to write an order for the lemons. Without closing the OE, SalesB name appears on the report and adds oranges. Later Sales A name appears adding the lemons again.
Our receiver and OE shipper processes the paper work and bills the customer for lemons. He receives oranges as ordered. The good news is that both customers got what they ordered.
Complicating all this is that the oranges were a direct ship, special order item and a PO was generated through the OE to PO function. That explains how they got the right product.
SalesB customer was a stock item sale and was done correctly and billed on another OE number. But the Audit log shows otherwise.
This is very confusing.
We have long known (since the 2nd day we went live in Macola), that OE’s could be generated, printed, shipped and then cancelled before being invoiced with no tracking of OE numbers. This was a huge security hole that we had to deal with through process rather than in Macola which had no solution. This was partly due to how we operate our business rather then Macola’s version of we should. Nonetheless, it’s a Macola issue for not tracking OE numbers.
I have a non Macola method to track OE’s as they are opened. This information is written to a log. Not a perfect solution or tell all but does help to point out “missing” numbers and establish a time line.
You should know that it is a common practice here by the order takers to have a OE entry screen open all day long so they can look up items that various customers may get special prices for. The easiest way to do this is through creating an order. It is either used or cancelled and another screen is started again.
In this special log report, I see that Salesman C (SalesC) first opened an OE with the number in question. SalesB opened an order right after and correctly used the next sequential number. SalesB then closed the order, followed by SalesC closing their order. Apparently, neither created an order so both numbers were released and the next sequential number was reset to the one that SalesC first started with. This is by default from Macola.(If the number is not used and no other has been used, then the number is “put back” into sequence of next number. But if another number is used after that one was issued, then that number is disregarded when it is not used. Hence, no accountability)
SalesA comes along and opens an OE and gets that number again. By this time, that number has been opened and closed by 3 different people in a period of 10 minutes. SalesA opens it again (now the 4th time) and enters the order for oranges.
I know this is all very confusing. I have surmised at this point this is all a timing issue within Macola. Overlap occurred in updating the various databases and when the number was finally processed as an order, Macola put all the bits and pieces together as a complete order. Somewhere, the wrong salesman number was even added to the order but we use a custom field that allows the author of the order to be identified. This is so one person can write an order for another so they get the credit for the sale. This has more to do with commissions than anything else. It also shows who to ask when questions come up.
One salesmen printed his order but then for some reason, it was canceled, accidentally we think. This does not show up in the Audit log but has to be true.
In the 8 years I have been dealing with Macola issues, I think the users might actually be right this time when they claim Macola is possessed and requires that I bring in a witch doctor to do some sort of voodoo exorcism on it.
I think it’s a combination of the practice of keeping an OE screen with the next OE number selected and the slow updates of the various databases (read/write/delete) Macola uses that caused the overlap and problem. Macola apparently does not purge everything when orders are canceled before their status is changed.
What do you think?
A customer called yesterday about an invoice they received. The billing info was correct and one of the 2 line items was expected but the other item billed was not even close to what they had ordered or received.
Basically they ordered oranges and got billed for lemons (not the real items). Looking up the OE, it showed lemons ordered and as invoiced.
However, Salesman A (SalesA) who wrote the order produced a paper copy of the OE showing oranges. Wait, how can that be?
A review of the OE Audit showed another salesman, Salesman B (SalesB) for a different customer had opened the OE first (with that number) to write an order for the lemons. Without closing the OE, SalesB name appears on the report and adds oranges. Later Sales A name appears adding the lemons again.
Our receiver and OE shipper processes the paper work and bills the customer for lemons. He receives oranges as ordered. The good news is that both customers got what they ordered.
Complicating all this is that the oranges were a direct ship, special order item and a PO was generated through the OE to PO function. That explains how they got the right product.
SalesB customer was a stock item sale and was done correctly and billed on another OE number. But the Audit log shows otherwise.
This is very confusing.
We have long known (since the 2nd day we went live in Macola), that OE’s could be generated, printed, shipped and then cancelled before being invoiced with no tracking of OE numbers. This was a huge security hole that we had to deal with through process rather than in Macola which had no solution. This was partly due to how we operate our business rather then Macola’s version of we should. Nonetheless, it’s a Macola issue for not tracking OE numbers.
I have a non Macola method to track OE’s as they are opened. This information is written to a log. Not a perfect solution or tell all but does help to point out “missing” numbers and establish a time line.
You should know that it is a common practice here by the order takers to have a OE entry screen open all day long so they can look up items that various customers may get special prices for. The easiest way to do this is through creating an order. It is either used or cancelled and another screen is started again.
In this special log report, I see that Salesman C (SalesC) first opened an OE with the number in question. SalesB opened an order right after and correctly used the next sequential number. SalesB then closed the order, followed by SalesC closing their order. Apparently, neither created an order so both numbers were released and the next sequential number was reset to the one that SalesC first started with. This is by default from Macola.(If the number is not used and no other has been used, then the number is “put back” into sequence of next number. But if another number is used after that one was issued, then that number is disregarded when it is not used. Hence, no accountability)
SalesA comes along and opens an OE and gets that number again. By this time, that number has been opened and closed by 3 different people in a period of 10 minutes. SalesA opens it again (now the 4th time) and enters the order for oranges.
I know this is all very confusing. I have surmised at this point this is all a timing issue within Macola. Overlap occurred in updating the various databases and when the number was finally processed as an order, Macola put all the bits and pieces together as a complete order. Somewhere, the wrong salesman number was even added to the order but we use a custom field that allows the author of the order to be identified. This is so one person can write an order for another so they get the credit for the sale. This has more to do with commissions than anything else. It also shows who to ask when questions come up.
One salesmen printed his order but then for some reason, it was canceled, accidentally we think. This does not show up in the Audit log but has to be true.
In the 8 years I have been dealing with Macola issues, I think the users might actually be right this time when they claim Macola is possessed and requires that I bring in a witch doctor to do some sort of voodoo exorcism on it.
I think it’s a combination of the practice of keeping an OE screen with the next OE number selected and the slow updates of the various databases (read/write/delete) Macola uses that caused the overlap and problem. Macola apparently does not purge everything when orders are canceled before their status is changed.
What do you think?