Change Log include when record was created

I have a DD to populate the Change Log for the Part Table. I have a condition block to monitor 9 fields.

image

  1. Is there a condition I could test for, for when the record is first created? And if so, could a Change Log entry be created? (I’m of the school that going from ‘Non-existing’ to ‘Existing’ is a change)
  2. Is there a better way to specify the fields to be monitored, or is individual criteria OR’d together (like shown above) the way to go.

Add your vote!

Get’s my vote for this one.

why not using RowMod.Added() ?

@A.Baeisa - I don’t follow.

Is that a condition I can set in a DD Condition widget? If so which of these:

Or was that a method of a BO? If so, there is no ChangeLog widget in a BPM. I’d have to write custom code to add to that table, and I’d rather not.

My change log directives always have one condition Company <> “” then everything else is done in the change log widget block. That would include created date/time

So in this method, the DD fires on every change to a Part record, and the ChangeLog widget records only the fields that have changed?

Just curious, why even have the condition? Why not just have the ChangeLog tied right to the Start block?

I think maybe just habit from 9.05. You HAD to have a condition in 905 dunno if you do anymore. The result is this in the change log

Nice.

So the ChangeLog widget only creates entries for changes to the ticked-off fields?

If I have PrdoGrp and ClassID ticked-off in the CL widget, and only one changes, then only that one is recorded? Or is the value of every ticked-off field recorded, and only the ones that change have a “from -> to” entry?

@ckrusen
are you trying to catch any new Added Record In DD to lunch the ChangLog?

yes.

Background -

  • A OTF PartNum is used on an order, and the order and requires it to be BTO.
  • A PO is placed (line type BTO).
  • The PO Receipt creates a PUR-UKN tran
  • Someone decides to create a part in the system with that same P/N and as Qty Bearing
  • The shipment - even though the Order and line were specified during packer entry - it creates a STK-CUS tran. When it should have been an UKN-CUS.

So we need to know WHO and WHEN the part was created in the Part master.

EDIT: In addition to logging new records, log the changes to about a dozen fields.

All our Change Log widgets come straight from the start block and we do get Added records in there, but something always changes at the same time so I was assuming that was the difference. It hadn’t occurred to me to put a condition in.

1 Like

it can be done by both DD and MD, put let stick with DD as you trying to do:
i have just used the rowmod (Added) linked to any field -in this case PartNum-, to trigger my BPM as:






2 Likes

Just to wrap this up … It appears that change log records remain, even after the record is deleted. You can only see them with the change log viewer if you re create it. Here’s a part I:

  1. Created
  2. Changed
  3. Changed again
  4. Deleted - Note that there’s nothing to indicate its been deleted.
  5. Recreated.

image

Or you can create two UD fields on the relevant table, then use DD trigered the same way but this time set field value as:
Client.UserID
Current.DateTime
then you can create BAQ/Dashbord, and call this date and filter it the way you want, it is entirely up to you

if you conditioen this DD BPM as i explained it should only add new part to ChangeLog,
i have done many changes to my part, and as you can see only one change added

At least for Part, since 10.2.100 these are being populated (but not displayed):

The other fields, you’ll have to use @A.Baeisa’s solution.

Mark W.

Just curious… But when a field is added to a table, and it is mandatory (like CreatedOn), what value does that field get set to on records that pre-dated the addition of the field?

In this case, do they get set to the date the table was updated(when the new fields were added)? Or possible set to an obvious value like “01-01-1900” ?

Calvin,

Don’t know the answer to that but it does look like it has been tracking the creation date / User since at least 10.1.600.6. We went live Dec of last year on 10.1.600.6 and upgraded to 10.2.200.7 in July and have all the data from the migration parts created on 12/1 and creation dates on all new parts since then.

@ckrusen
this issue is called, historical data update, unfortunately, you need to deal with them separately, i.e. if you are keeping the data somewhere, then you can you use Updatable BAQ/Dashboard or DMT to update these UD fields, this is what i had to do when i create a UD filed in PartRev to store the FAIR Date as we keep this information in spread sheet, if you do not, then it will be null/blank.