In another post the recommendation was to use Datasource Aggregate Ref parameters to filter Custom LOV field.
We are having the same issue with 21R2 Update 20. A solution to this is more than welcome! I actually found a solution to the problem regarding my customer’s environment. After some debugging I was able to locate the problem being text translations. We had just done the Update 20 installation and for some weird reason it had updated the Fnd_Boolean_API “TRUE” and “FALSE” translations. After I just updated them manually in Text Translations page (the exact paths were “FndBoolean.FALSE” and “FndBoolean.TRUE”) and refreshed the language cache for component FNDBAS, I was again able to transfer work tasks to mobile. What exactly happened was that the Transfer procedure was fetching translated client values to the database value of “TRUE” or “FALSE”, and tried to insert it to the new row in Mobile_Work_Order_Tab table. Without translations, it ended in an error during the “Check_Insert” procedure.
We are having the same issue with 21R2 Update 20. A solution to this is more than welcome!
I had a similar experience. I got the error if I had Scandinavian letters (å, ä, ö) in a Failure Event popup text, but once I removed the “problematic” letters I was able to deploy my BPA process.
FYI, I’ve managed to narrow this down to external supplier invoices that have posting information in the incoming invoice message. Then the posting lines receive Posting Type = EXTERNAL. These rows do not generate cost lines in the Work Task.If I manually enter the posting lines to the posting proposal, then the rows naturally get Posting Type = MANUAL. These successfully generate cost lines to Work Task.I’ll post this issue to IFS support, let’s see what the investigation brings up.
OK, let’s see if there’s something to fix in the system code. I’ll post the results here when support investigation is done.
We finally managed to resolve this. The paths we used were:/auth//mob/ifsapplications/To clarify, their network software had a “Contains”-type validation for the HTTP requests, so we had to leave out the asterisks (*). In some other setup they might be necessary.Thank you both for your help!
We already tried with having only “/mob/*” as the limiting factor, but that did not help. It seems like we need something else in addition to “mob” and “auth”?
Okay, I somehow got it to work. After adding my custom field to the Purchase Orders page using Page Designer (in the global context) and publishing it, I went to “Translatable Texts” page as suggested by the Cloud documentation: https://docs.ifs.com/techdocs/22r1/040_tailoring/225_configuration/200_client_configurations/350_translations_in_configurations/ There I searched for my specific field ([global].PurchaseOrders.list…..) and added my Finnish translation (NOTE: These seem to have nothing to do with the translations set in the Entity Configuration page? I guess those are just a useless relic from the old EE client design...).After that, I refreshed the language cache and refreshed the Purchase Orders page in Chrome. It still didn’t affect my field, but then I tried once more to republish the page configuration in Page Designer, and then the correct Finnish translation appeared.Not the most straight forward flow I would say, but atleast it’s working now...
If there’s any news on this issue, I’m also interested in finding a solution. I’m not able to get Finnish translation to work for a Custom Field in Cloud (21R2 Upd6). I tried all the unpublish/republish and refresh language cache tricks, as well as manually re-entering the translation in Text Translations page and refreshing the language component once more.
@Tuukka Have you resolved this by translating the message with main type “WEB” ? Unfortunately not. I wasn’t able to find this translation in main type WEB. It might be that my customer is missing some of the language translation files (or some rows in them), so the translation is impossible to enter.
Check the Object Connection Transformations settings. If you have a connection there between certain logical units / entities, that no longer have a needed field in the view, you can get this error message. Check the logical units you currently working with.
I’m also worried about this. LCS does not seem to have knowledge of Cloud bugs and solutions, so it’s hard to investigate if an error found in a Cloud environment is already reported to IFS RnD. As a partner, we don’t have access to Jira and other issue reporting systems.
I would try having the check process in the Event Action code, instead of embedding it in the Custom Attribute. I’m not sure if the NVL is the correct format, but anyways you want to compare whatever value was entered into the specific Required Date field.IF (value) < sysdate THENError_sys…ELSENULL;END IF;
Hi @Tuukka, Can you please provide a screenshot of your data source designer. Best REgards, Bhagya FYI, I also tried using $CUSTOMER$ in the element Web URL, instead of $Customer$, but that didn’t solve the issue.
Translations for custom fields shown in Aurena need to be entered separately. Once you have added the field in the Aurena Page Designer and published the updated page, you will get a new entry in Text Translations. You must enter the same translation there, just like you originally entered it in the Custom Field translation. Below is an example of a custom field “NOTES” that I added to Purchase Order page in Aurena.Please see the Path so you can easily search for your own custom fields. Note that I added my field to the “global” context, so the Path has [global] as the prefix. Each context can have its own translation.After entering the translation and refreshing the language cache, you might need to unpublish and republish your Page in the Page Designer, so that the fields retrieve their proper translations.
Just to be clear, when I said to check the grants/permission set, I was referring to this: > I tried your suggestion with a direct URL ( ifsapf:frmDocbbClassFormat ) but unfortunately it does not work… My memory fails me now, but you should need to grant the whole presentation object connected to the B2B basic data form, and not only grant that view, in order to be able to use that form. Right? About the DocumentHomeB2b projection, if that is not there, then DOCBB has not been installed, or installed properly/fully. It’s not part of PCMBB. The presentation objects was also fully granted when I tested. I think you are onto something, that DOCBB might not have been fully or properly installed. We need to investigate this with our technical consultant.Thank you Mathias for your help, it’s given some light to this matter!
Thanks for testing! Could it be a granting/permission set issue? I have the view DOCBB_CLASS_FORMAT_B2B and related API granted, so it shouldn’t be a permission problem. Seems like the necessary projection from Aurena perspective is “DocumentHomeB2b” but that doesn’t exist at all in my customer’s environment. Here is a screenshot from another environment that has PCMBB installed. Unfortunately this seems to be an issue that won’t be solved without installing PCMBB or getting a code patch to Apps10...
After some investigation, it seems like you must have specific components DOCBB and PCMBB installed in the system. The document visibility in B2B portal is managed under the MRO or Service component basic data, which seems kinda strange because there might be cases where the customer doesn’t have MRO or Service processes, but they still want to show documents to the user in B2B portal. You are right and we actually did not realize this unfortunate dependency until very recently. For IFS Cloud we will make sure that you don’t need PCMBB to setup the B2B document classes and formats. If this is a major problem on Apps 10, file a support case and we can look into it for that version as well. And/or I actually think you can open the form if you know the name, even if you don’t have PCMBB. The form itself is, I think, in DOCMAN or DOCBB. The subpage “B2B Doc Classes and Formats” is indeed in the DOCBB component. I tried your suggestion with a direct URL ( ifsapf:frmDocbbClassForm
After some investigation, it seems like you must have specific components DOCBB and PCMBB installed in the system. The document visibility in B2B portal is managed under the MRO or Service component basic data, which seems kinda strange because there might be cases where the customer doesn’t have MRO or Service processes, but they still want to show documents to the user in B2B portal.
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
