I am attempting to determine the difference in PartTran between EntryPerson (I think the E10 user) and EmpID (I think the MES emp). To do this, I built a simple BAQ on the PartTran table to display a few key items.
I filter by TranType = “MFG-STK”, TranQty > 0, and TranDate > Today - 10days — I do not see ANY of the transactions I am doing!?
Other than that, I still cant fathom why I see none of the 10’s of transactions I’ve made (Report Qty from MES) in the PartTran table. I’ll also add, I think they are posting because my BPM’s process just fine off that table to print the labels when reported.
Hmmmm… Seems like TranDate is either the date of the job OR the date of emp login, not the actual date of the transaction. It appears that SysDate is the actual transaction date.
Thanks for the reply Scott - that typo only affected my post, I was doing it proper in the criteria The issues that caused this mess are:
SysDate = transaction date, not TranDate
EmpID is NOT populated by MES for some reason
What do you mean by committed? After changing my filter from TranDate to SysDate I can see the transactions immediately in PartTran table without logging EMP off the job. Auto-rec is check and there is only 1 operation so it is the final.
My immediate fix was to simply use the Session.EmployeeID to get what I needed (printing a label including EMP) - since it seems EmpID is not being populated. How can fix that?
My first thought is that I’d have to do a PRE BPM to modify the value before it is written to table. On the other hand - why cant I just link the TranNum of my ttPartTran to PartTran to access to proper record - seems E10 doesn’t like that.
Am I overcomplicating this and overlooking some simple solution like simply setting the EmpID field in the ttPartTran table?
I guess the moral of the story is - what happens that turns a ttTable into an actual record?
No problem - Just making sure I wasn’t overlooking something. Anybody have any input on:
what happens that turns a ttTable into an actual record? does each record in that ttTable become an actual record?
ttTables are temporary tables that exist in memory, not ALL ttTables have a direct co-relation to a physical table in SQL but a lot of them do.
But for example if you are in a Pre-Processing BPM or an InTran Data Directive the ttRecord may not yet exist as a physical equivalent record in the Database.
For example
If you put a BPM on Part.Update
you have
Pre-Processing
Base
Post Processing
on a Pre-Processing BPM you will have a ttPart record, but if this is a NEW part the actual Part table record will not yet exist.
on Post-Processing (that is AFTER the business logic of the Update method has executed) you will have the ttPart record as well as a physical record on the Part table
Hopefully this clarifies some
I am not sure I follow what your issue with the ttRecord is though
I was noting that EMPID was not being stored in the PartTrans table, I was going to remedy that somehow. I wasn’t sure if I could just update that field in the temptable and it will propagate to the appropriate record.
The issues that caused this mess are: