Completed Date off 1 day in SFDTLFIL_SQL 1

[pticarl]

Macola 7.6.100a SQL

I am having some funkiness in SFDTLFIL_SQL that I cannot explain and I hope that you all can help. We currently have Production Associates recording activity against Shop Orders on the Shop Floor using the Shop Floor Activity Transaction screen in Shop Floor Control. I am developing some reports that track the flow of materials through the production process and I want to key off of the compl_dt field in SFDTLFIL_SQL, which is populated with the current data when the operation complete checkbox is checked (at least this is how it appears when I have tested the functionality). The odd thing that is happening is that for a good part of today I can verify that production was reported correctly but when I look into the table itself via Access, Crystal Reports, and an Excel ADO query, the compl_dt field is actually reading yesterday(that is 20040622 NOT 20040623).

I have checked the server date as well as the workstation date and they are both correct.

Even more strangely I watched the same person report production later in the day and the compl_dt field was populated correctly with the proper date.

Is there a step that I am missing somewhere in the process (ie a need for posting to occur first) or is this a Macola bug?

Any help would be greatly appreciated.

Thanks!

 

[dgillz]

I still suspect the date setting is incorrect. Did you verify the AM/PM portion of the date?

For example if it is 11:30pm on the workstation date when the physical time is 11:30am, then the workstation will forward to the next day after 12 noon physical time. A quick look at the date without checking AM/PM would miss this.

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

http://www.trianglepartners.com

 

[pticarl]

Dgillz,

Yes, unfortunately for me the AM/PM portions of the date are correct. On further investigation I have found that the Trx Date field on the Activity Trx by Shop Order screen is set to the previous day and this provides the datestamp for compl_date (ie it is user-settable) for the two PC's that I have this problem on. I was a little suprised at this capability but it does make sense to allow user entered dates to be here. What does suprise me however is that this field's default value is set to the system date. Perhaps my 3rd shift operators are changing the dates and the changes are being saved instead of reverting to a default value. We do tend to report transactions on a batch basis (that is when several orders have been completed as opposed to one at a time) so perhaps this is my problem.

Thanks for your suggestions, it has definitely given me some ideas to run down. When I get the problem fixed I will post back with my solution.

 

[maccrystal]

Some Macola programs capture the date when you start them up and does NOT refresh the date until you exit the program and restart it.

http://www.appstratinc.com

 

[pticarl]

maccrystal,

That's exactly what is happening to me and I was able to duplicate the "bug/feature" internally. Once I restarted Macola PWE on the two systems that I have seen the problem on (and are also machines on the shop floor that were not logged off as they should have been) the inaccurate date was reset to the current system date.

Our short-term fix is to make sure that Macola users log out at the end of the shift (thankfully there access rights are tighly controlled), with a possible long term look at hooking some Flex code in to do some date validation or rewrite the correct date to the SFDTLFIL_SQL table.

I can't for the life of me figure out why this would be programmed this way. The ability to override the default date makes sense, but how hard is it to capture the current system date either from the workstation or from the server-side? (Not hard at all but I am sure that you all know that already)

Anyway, thanks for the excellent responses dgillz and maccrystal. Stars for both of you !!