Is it me or is it Macola? (Cycle counts) 1

[rustylee]

What am I missing? This is from the cycle count select screen help in Macola regarding the check box labeled "Use Frozen Qtys In Calculations":

"If you activate this check box, Progression will use a calculated value based on the frozen quantity to update inventory. Leave this check box blank if you want Progression to update inventory based on the posted tag count quantities."

Here's the scenario. Cycle count select is started at 7:09am with the above checkbox checked. Frozen qty on worksheet show 9,000 some-odd pieces. Tags were entered and posted by 8:39am. However at 8:12am, an item that was part of the cycle count was received to inventory, raising the on hand qty to about 22,000 pcs. However, only around 9,000 pieces were counted, since the product was not physically moved.

When the tags were posted, the QOH was changed not by the difference found in the cycle count (1 pc), but rather the new QOH was the qty entered on the tag. So instead of having 22,000 some-odd pieces +/- the count variance, the QOH reads 9,000 some-odd pieces, the amount entered on the tag.

Shouldn't the help read like this: "If you activate this check box, Progression will ignore your selection and will post the amount entered on the tag, which is the same as not activating this box. Leave this check box blank if you want Progression to update inventory based on the posted tag count quantities, since this is what Macola will do anyway no matter if this box is checked or not."

Seriously, what is going on here? This has never worked for us. Do I have to pay extra to activate the code for this feature? I've always been under the impression that business could continue regardless because Macola could do a "relative" change to QOH, as opposed to an absolute change. Normally I'm an absolutist, but in this instance I wish to be a relativist.

V7.6.100a (P.SQL)

-Rusty

 

[wwwedward]

I have seen a lot of burnt toast on that little check box myself. My depth points to the fact that it only is for invoices that occur in the time gap between tag prints and counts post. I do not think it is built to deal with recv... However, I do thank all the people here who enlighten me every time.

mucho

 

[dgillz]

Rusty,

What was the freeze date of the cycle count, and what was the date of the transaction at 8:12am?

This feature definately works, I have been using it for years.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[rustylee]

The freeze date is the same date as the 8:12am transaction. All of this occured on the same day in a 1.5 hour window.

But here's something interesting. The cycle count workseet shows a frozen qty of 9,869 pcs (I'll be using the exact figures now - disregard the figures I used as examples). The physical count variance by item report, printed at 8:29, shows a frozen qty of 27,269 pcs, with a huge variance, since the count qty on the report shows 9,868 pcs. The tag posting register shows a posting of 9,868 pcs and a frozen qty of 27,269 pcs. The inv trx report shows a final qty adjustment of 17,401-.

The variance report should have tipped off the inventory control guy. Regardless, what does "frozen qty" mean if the frz qty value is increased after a receipt? Seems more like it's slushy, not frozen

Could it be that

http://wwwedward

correct, that the frozen qty checkbox only functions for invoices?


-Rusty

 

[dgillz]

The frozen qty will change for any transaction dated before the freeze date. This is what allows you to go on processing transactions without a hitch.

If someone entered a PO receipt on the same day, or on any previous day, this is exactly the expected bahavior.

This works for every transaction, not just invoices.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[rustylee]

Hi Don,

The receipt transaction was on the same date as the freeze date.

I guess there's something wrong here, since the facts belie how Macola should function. We can handle this procedurally I think.

 

[rustylee]

Don,

Sorry, I misread your last post which said that transactions on the date of the freeze and before would be cause the behavior I'm seeing. I just tested this by backdating the freeze date to the prior date and it worked fine.

This however seems counter-intuitive to have to back date the freeze date to make it work, but I guess that is necessary in order for Macola to calculate properly.

Couldn't let it go. Got it working. Thanks!