Hi, every time I customize tables for a customer (almost all projects) I need to change the importers and/or make some tricks with not used fields on import. [Struggling today with this case]
Idea!
Not tested, but I think I could make a ModelValidator on udpate of I_ table (i.e. I_BPartner) and process the corresponding fields.
The other thing we could do is to add some free fields to every I_ table as wildcards to save customized or non considered fields and process them properly with the ModelValidator.
Maybe just adding i.e. 10 fields FreeField01 through FreeField10 on the tables can make the trick.
What do you think?
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have imported some objects and sometimes I missed fields in the standard import loader format (like in Inventory where there is no guaranty date). With the ModelValidator and the 10-something fields, the import of legacy data would be an easy task.
I definitely find it an excelent idea and support its integration into trunk.
Best regards,
Mario Calderon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
re: FreeField01
probably a bit obvious, you'd need a "set" for each type (int char date etc) ...
This was a common feature on other systems I worked with .. but to be honest I always felt the AD made it so easy to add fields this was somewhat obsoleted. The PO (with use of generatemodel) handles persistence of the new fields and we can use callouts & validators for manipulation of these fields without changing core code... BUT you are right none of this works for importing. So it seems like a good extension.
What precisely is the idea? To add generic fields to the Import tables and then use the validator during the processing of the I_tables to process these new generic fields updating some new non-generic field created in the AD?
that sounds like a good plan to me.
colin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> What precisely is the idea? To add generic fields
> to the Import tables and then use the validator
> during the processing of the I_tables to process
> these new generic fields updating some new
> non-generic field created in the AD?
Well Colin, again is better to give you an example:
Suppose you add a customized column to C_BPartner (i.e. ContributorType)
How could we load this new column without changing ImportBPartner process?
1 - Load the ContributorType in FreeField01
2 - Write a ModelValidator for I_BPartner table when the record is changed and the IsImported column = Y
The ModelValidator method must take the I_BPartner.FreeField01 and put it into the C_BPartner.ContributorType field.
Simple and extensible in my opinion.
I think we just need character fields - number and date fields can be managed/converted in the ModelValidator routine.
Regards,
Carlos Ruiz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, every time I customize tables for a customer (almost all projects) I need to change the importers and/or make some tricks with not used fields on import. [Struggling today with this case]
Idea!
Not tested, but I think I could make a ModelValidator on udpate of I_ table (i.e. I_BPartner) and process the corresponding fields.
The other thing we could do is to add some free fields to every I_ table as wildcards to save customized or non considered fields and process them properly with the ModelValidator.
Maybe just adding i.e. 10 fields FreeField01 through FreeField10 on the tables can make the trick.
What do you think?
Regards,
Carlos Ruiz
Hi Carlos,
this is a very good idea.
I have imported some objects and sometimes I missed fields in the standard import loader format (like in Inventory where there is no guaranty date). With the ModelValidator and the 10-something fields, the import of legacy data would be an easy task.
I definitely find it an excelent idea and support its integration into trunk.
Best regards,
Mario Calderon
re: FreeField01
probably a bit obvious, you'd need a "set" for each type (int char date etc) ...
This was a common feature on other systems I worked with .. but to be honest I always felt the AD made it so easy to add fields this was somewhat obsoleted. The PO (with use of generatemodel) handles persistence of the new fields and we can use callouts & validators for manipulation of these fields without changing core code... BUT you are right none of this works for importing. So it seems like a good extension.
What precisely is the idea? To add generic fields to the Import tables and then use the validator during the processing of the I_tables to process these new generic fields updating some new non-generic field created in the AD?
that sounds like a good plan to me.
colin
> What precisely is the idea? To add generic fields
> to the Import tables and then use the validator
> during the processing of the I_tables to process
> these new generic fields updating some new
> non-generic field created in the AD?
Well Colin, again is better to give you an example:
Suppose you add a customized column to C_BPartner (i.e. ContributorType)
How could we load this new column without changing ImportBPartner process?
1 - Load the ContributorType in FreeField01
2 - Write a ModelValidator for I_BPartner table when the record is changed and the IsImported column = Y
The ModelValidator method must take the I_BPartner.FreeField01 and put it into the C_BPartner.ContributorType field.
Simple and extensible in my opinion.
I think we just need character fields - number and date fields can be managed/converted in the ModelValidator routine.
Regards,
Carlos Ruiz
ok clear now Carlos... actually that's what I thought you said to begin with :)
yes that sounds like a very good idea ok.
colin