Nearly a year ago, I wrote about the external procedure SONRAW and how it changes values in the linked PARTARC table. I've just made an important discovery about this table after having run SONRAW.
Let's say that there is a part P0 that is the 'grandfather'; P1 will be both a son of P0 and a father, and R1 is a purchase part that is a son of P1. Assuming that there are no more sons in the BOMs of P0 and P1, and that SONRAW is 'fed' part P0, after SONRAW is run, there will be two rows in the linked PARTARC table. In both rows, PARTARC.PART will be P0; in the first row, PARTARC.SON will be P1 and in the second row, PARTARC.SON will be R1. So far, nothing new.
What I have just discovered is that in the first row, PARTARC.SONPARTREV will be P0 (not very useful), but in the second row, PARTARC.SONPARTREV will be P1! This means that the direct father of any purchase part can be found in the linked PARTARC table, something that I thought was not possible. This is even better if there is a phantom between P1 and R1, because looking at the unlinked PARTARC of P1 will show the phantom. Also, there's no real way of getting the parent of R1 - until now!
Not surprisingly, this is very important for a report that I am trying to write; the original version obtained the purchase parts, which is fine, but now I need to get some values from the direct father.
[Edit from 03/10/22: After SONRAW, PARTARC.SONQUANT also contains the internal number of the direct father, although again, this is a real number so one has to write PART.PART = ROUND (PARTARC.SONQUANT).]
No comments:
Post a Comment