We are developing custom fields and custom LU’s in a customers IFS 9 Environment. We will also be developing new report files (.rdl) that contain custom logic on custom fields. These .rdl files will not be sent to IFS Harvest as they contain custom logic and will not be accepted by IFS. We have also developed a custom API which has custom logic written as per IFS standards. we accept full responsibility on the support of all these configurations if any issues arise in the future. we will not be making any changes to core IFS code and will simply be using the configuration tools provided to us by IFS.
My Question is - Based on the nature of this work does this violate any IFS license?
Page 1 / 1
I can’t answer this fully, but only from a reporting perspective adding custom fields to a Report Designer RDL report is allowed and I don’t see any license violation.
Hi,
This does not violate the IFS license as long as you don’t touch the core code. And as you have mentioned you have to accept full responsibility for the support of all these configurations if any issues arise in the future.
If IFS has identified these configurations and packages are causing an issue for standard functionality. A correction should be made from your end.
Important: Don’t lose your configurations and code. Keep them safe somewhere or use an internal repository to store the code.
Thanks
Savinda
Many thanks for your answers so far!
I suppose I should clarify - i think the customer is looking at this from an oracle standpoint - are we violating any oracle license agreements?
Still I don’t think this is a license violation. As long as you develop according to IFS Standards this will not be a problem.
Still I don’t think this is a license violation. As long as you develop according to IFS Standards this will not be a problem.
Thanks Savinda - i think this is maybe where the issue then might lie…
we are not using IFS developer studio to do these changes, so we don’t have database schemas, .utility files, etc etc. We are also applying custom logic on custom fields which IFS dont accept. to be clear though this we are just using the tools IFS provide to us and we are not changing any core code…
would this cause an issue? - do you know the official “IFS Standards”?
To be clear, this is not a violation of IFS license. But its a violation of IFS Standards. The responsibility of any impact to IFS Application functionality, security or performance because of your work has to be taken care of you.
/Savinda
To be clear, this is not a violation of IFS license. But its a violation of IFS Standards. The responsibility of any impact to IFS Application functionality, security or performance because of your work has to be taken care of you.
/Savinda
thanks - and you believe also no oracle license violation?
you say “a violation of IFS Standards” - is this an actual problem or just the fact that IFS would recommend how WE SHOULD do things but if we don’t follow the standards them we are not violating any license agreement but we would have to accept full responsibility of the changes we are making?
Thanks everyone for your help so far...one more question:
This customer has many layouts for a single report, done by IFS as customisation initially. For an example, they have more than 10 layouts for Customer Order Confirmation. We need to add our custom field to all these 10 layouts. Could you please recommend whether we should add custom field on these layouts or take a copy and create it as a new layout with a prefix"
thanks
@lmackeath If you purchase Oracle from IFS as an ASFU license, then it’s okay to do this since your code is related to IFS Applications.
Regarding standards, it’s mainly because the framework expects (DB) code to be in a certain standard(naming, lengths,, view/column comments etc.). If your code doesn’t conform, the framework can run into issues. That’s why you should use the IFS Developer Studio when doing coding, since it will guide you in these.
Hi,
Regarding custom fields on reports:
For the safety of your layouts, just keep them as a backup in a repository. And then update the existing layouts with custom fields.
@lmackeath If you purchase Oracle from IFS as an ASFU license, then it’s okay to do this since your code is related to IFS Applications.
Regarding standards, it’s mainly because the framework expects (DB) code to be in a certain standard(naming, lengths,, view/column comments etc.). If your code doesn’t conform, the framework can run into issues. That’s why you should use the IFS Developer Studio when doing coding, since it will guide you in these.
Hi i have checked with the customer and this is what they have in place now..does this cover the changes we are making? both for the custom fields with custom logic on rdl file and the custom api work?
@lmackeath If you purchase Oracle from IFS as an ASFU license, then it’s okay to do this since your code is related to IFS Applications.
Regarding standards, it’s mainly because the framework expects (DB) code to be in a certain standard(naming, lengths,, view/column comments etc.). If your code doesn’t conform, the framework can run into issues. That’s why you should use the IFS Developer Studio when doing coding, since it will guide you in these.
Hi i have checked with the customer and this is what they have in place now..does this cover the changes we are making? both for the custom fields with custom logic on rdl file and the custom api work?
sorry to clarify, the customer purchased the licence from IFS