Hi,
can anyone explain how to start a BaaN - session from the product configurator? Is there a chance to fill a variable in the session and get it back to the product configurator?

thanks for your help, Thomas

We use the configurator quite extensively and it refers to a dll for quite complicated calculations etc. but if you can provide me with more informationas to what you are trying to achieve, I may be able to provide you with some help.

Originally posted by EdHubbard
We use the configurator quite extensively and it refers to a dll for quite complicated calculations etc. but if you can provide me with more informationas to what you are trying to achieve, I may be able to provide you with some help.


Hi Ed!

We do have generic items with different product features. One feature is a standard item. An other feature is a special colour. What we want to do is to start a session from the standard item feature to find the item. The session could be tiitm0502s000. Is there a possibilty to start this session from the product feature in the configuration process of generic items?

Thanks for your help, Thomas

Why do you need to zoom off to display the standard items?

I am sure what you ask is possible, but is it really necessary?

If it is just to be able to select the standard item, you could just add them as options in your feature. If they are changing frequently (example, the list of special colours keeps expanding) you could have a job that searched through the item master for a certain item group then it adds them to the generic item feature as new options (and adds them to the generic BOM as possible components). This is exactly what we do and it works very well.
I can provide you with extracts of our code if that helps.

I just had a quick play, and added the following line to a before.input section of a feature constraint:

!zoom.to$("tiitm0502s000",Z.SESSION,"tipcf5210s000",tiitm001.item",0)

It calls up the item session so it can be done!
However, as the before.input constraints get called as you go into the variant, then when you step into the relevant feature and finally as you exit the variant the item session gets displayed three times. Also, in my quick example it is not returning the item code you select but that should be simple to fix.

However, returning to my previous post, make sure you need to do this anyway!

Hi Ed!

Thanks a lot for your help. Everythings works perfect now!

Thomas

Please post how you achieved this - particularly how (if) you managed to get the other session to only open once.

thanks

Hi ED!

I think it is a little bit tricky!

I did it with 3 different product features:
Text
Pos1
Pos2

The first feature is a hidden feature, just to init a variable.
In the second feature the external program is started:

long sessionstarted
string test2 global
!extern string test1(8)
if [Text] <> "" and [Pos1] = "" and sessionstarted = 0 then
!zoom.to (start session, returning test1)
!test2 = test1
sessionstarted = 1
else
endif

And this is the third feature:
string test2 global
!if isspace(test2) then
[Pos2] = " "
!else
[Pos2] = test2
!endif

In the zoom - session I use put.var(parent, "test1", test1) to give the variable back to the pcf.

I think you do need the if - clause in the second feature to start the session and with the help of the varibale "sessionstarted" the program comes up only one time!
Now I managed to put the return varibale from the zoom - session in my third feature, it's ok for me, but it is not that nice. It would be nicer to put it into the second feature. But this version works and every one is happy here.

ok ???


Thomas

Thanks for your reply Thomas.
I will try this on my system when I get some free time!

Originally posted by EdHubbard
Why do you need to zoom off to display the standard items?

I am sure what you ask is possible, but is it really necessary?

If it is just to be able to select the standard item, you could just add them as options in your feature. If they are changing frequently (example, the list of special colours keeps expanding) you could have a job that searched through the item master for a certain item group then it adds them to the generic item feature as new options (and adds them to the generic BOM as possible components). This is exactly what we do and it works very well.
I can provide you with extracts of our code if that helps.

Hi EdHubbard,

i had a discussion with Thomas about this problem in the german forum.
I am interested about the solution you posted earlier.
You wrote that you have a job that searches through item master data and insert in feature options and generic BOM.
Now the Question:
How do you managed the constraint for validating the BOM-Line?
Is it always the same constraint for every Line or do you generate a new one in your job?

Greetings

Andreas

The constraint is always the same. Essentially, the items that are added as new options and in the generic BOM are inks. Therefore they are all treated the same way and there is no need to have a different constraint per ink.
The constraint code is as below if that helps:

!#pragma used dll otcmcsdll0009c
!#pragma used dll otcmcsdll0018c

!table tipcf500
!table tipcf310

!import("tipcf310.sitm", tipcf310.sitm)
!import("tipcf500.item, tipcf500.item)
!if strip$(shiftl$(tipcf500.item)) = "SPRINT1" then
!validate = tcmcs.dll0018c.okay.std.item.for.ink(tipcf310.sitm,
! [match1], [match2], [match3], [match4],
! [match5], [match6], [match7], [match8] )
!else
!validate = tcmcs.dll0009c.okay.std.item.for.ink(tipcf310.sitm,
! [match1], [match2], [match3], [match4],
! [match5], [match6], [match7], [match8] )
!endif

This calls a library function in 1 of 2 dlls (depending on the generic item being "SPRINT1" or not). Match1 to 8 are the upto 8 colours that the user may choose in a particular configuration.

function extern domain tcbool
tcmcs.dll0009c.okay.std.item.for.ink(
domain tcitem psitm,
domain tccpft pmth1,
domain tccpft pmth2,
domain tccpft pmth3,
domain tccpft pmth4,
domain tccpft pmth5,
domain tccpft pmth6,
domain tccpft pmth7, domain tccpft pmth8
)
{
if ( strip$(shiftl$(psitm) ) =
strip$(shiftl$(pmth1) ) ) then
return ( true )
endif
if ( strip$(shiftl$(psitm) ) =
strip$(shiftl$(pmth2) ) ) then
return ( true )
endif
if ( strip$(shiftl$(psitm) ) =
strip$(shiftl$(pmth3) ) ) then
return ( true )
endif
if ( strip$(shiftl$(psitm) ) =
strip$(shiftl$(pmth4) ) ) then
return ( true )
endif
if ( strip$(shiftl$(psitm) ) =
strip$(shiftl$(pmth5) ) ) then
return ( true )
endif
if ( strip$(shiftl$(psitm) ) =
strip$(shiftl$(pmth6) ) ) then
return ( true )
endif
if ( strip$(shiftl$(psitm) ) =
strip$(shiftl$(pmth7) ) ) then
return ( true )
endif
if ( strip$(shiftl$(psitm) ) =
strip$(shiftl$(pmth8) ) ) then
return ( true )
endif

return ( false )
}

We use the library for lots of calls from the constraints, but you could code it in the constraint if you wanted.

If you need me to send you the code for updating the possible list of inks from the item master, please let me know.

Hi Ed,
thanks for your quick response!

Our Problem is a little bit more difficult.
We have about 250 different papertypes for printing.
And this grows because we print on what the customer wants.
So there is no Problem to insert these new items in Product feature Options or in generic BOM. We do the first.
In generic BOM we have a Dummy-Paper which is changed after Projectgeneration by an extra program. This is not very elegant cause sometimes our people forgot to call this program which ended in a need for this dummy-paper.
So what I'm looking for is a possibility to get the paper changed during Projectgeneration.

I tried it like you coded it in your post with the import of tipcf310.sitm.
But i can not acces this field.
Maybe there is a difference between Baan IV and Baan 5.
I think that Baan had capsulated the Validation.

Greetings
Andreas

Perhaps the table structure is different in Baan 5 so that generic BOMs are not in tipcf310?

Other idea:
Could you call the "update generic BOM" program during product configuration?
This could insert the "option" just selected into the generic BOM at that point in time, so the user cannot forget or depending on how long between product configuration and customized item generation you could run a periodic session that scanned the certain feature's options and updated them into the generic BOM.
Then you could use somthing like my validation constraint posted earlier for the validation.

Hi Ed,
needed a bit of time to evaluate again coz i programmed it a while ago.

First, the table structure is not different in Baan 5, generic BOMs are still in tipcf310.
So what i want is not to update tipcf310 but tibom010 (BOM) during customized item generation. I do this with the extra session.
The field i can not access is not tipcf310.sitm but tibom010.sitm or tibom010.pono, Sorry ;)
Due to some other reasons i don't want to update tipcf310.
A little bit of debugging shows me that the generated BOM is commited in one step, so no chance to export my option to tibom010.sitm because i can not evaluate where the configuration stands in the moment.

So i have another idea how to manage this.
Suppose you have the following pono's in tipcf310:
10
20
30
40

30 is my paper.
In the configurator i know the main item and the paper needed.
So i can insert a record in tibom010 whith lets say pono 25 and set validation of pono 30 to no.
What do you think about that?

Andreas

Yes, sounds feasible.
So in the validation section of generic BOM pos 30 you will run a function to create a new record in tibom010 - obviously you will need to allow for the fact that the BOM may already have been created for a previous configuratio. Also the position 25 item you add/create in tibom010, I think must be existing in tiitm001 as well.