-
‘Voyage’ – Related information is displaying information as ‘Received’, although items are in-transit
When working with Voyages, once the goods are in transit, the information displayed in the ‘Related information’ factbox is mentioning that the items are received, while the items are actually in transit still. As the items not received and are in-transit, the kind ask is to have consider having this information easily seen from the ‘Related information’ on the 'Voyage' form. -
Unable to map to integer (number) field in System Defined Table Constrains within Product Configurator
When creating a new custom field of type ‘Number’ using Personalization, a new column will be added to the table with a data type of ‘bigint’. When creating a new Attribute of type ‘Integer’ with a range, creating a new table constraint of type ‘System defined,’ and mapping against the system table, an error message is triggered preventing the process: ‘'The selected field does not match any of the supported types; Enum, String, and Integer'. It is not possible to map to an integer (number) field in ‘System defined’ table constraints within Product configurator. Mapping is allowed to number fields with data type 'int', however not 'bigint'. Changing the current way the system is working would provide a great amount of help and flexibility to users when making use of product configurator module. -
Error when posting sales order invoice, if the Total discount % applied has ended up as an irrational number
A situation was identified as when trying to post an invoice for a sales order, having a Total discount Percentage configured, an error message would be preventing the process to complete. This situation may result if the Total discount percentage may end up as an irrational number. Error message presented: Sales order: xxxx Voucher: xxx The transactions on voucher xxx do not balance as per xxx. (accounting currency: 0.01 - reporting currency: 0.00) Voucher transactions Voucher xxx, date xxx, account xxx, transaction currency amount 38.34, accounting currency amount 38.34, reporting currency amount 0.00, currency GBP, text Voucher xxx, date xxx, account xxx, transaction currency amount -38.34, accounting currency amount -38.34, reporting currency amount 0.00, currency GBP, text Please kindly help in considering a change to accommodate/correct this behavior , the business impact Is very high. Auditing processes are not passing, and as well, manual solution to solve the behavior encountered on every sales order affected, is very tedious and subject to human error. *with reference to CR583498 -
Product configurator translation for documents is using user language instead of customer language
The following scenario have been reported: Translations for Product configuration models, attributes and components have been added. Notes are automatically generated based on the setup made in Product information parameters > Configuration documentation types . When generating a sales order for a customer account having a different language than the User language, the documents produced (eg. Sales order confirmation/packing slip/Invoice), do not display the Notes translated in the customer language, the notes are using the User language instead, which is not expected. In addition the Configuration is not translated at all. It would be very helpful if a change in this direction could be considered,. Based on received insight, maybe a parameter could be introduced, which would provide the user with the option on choosing which language should be used. -
Procurement & Sourcing Parameter - 'Direct Delivery Automation'
The following scenario has been reported and if such a possibility may exist the scenario should be considered for change. The visibility of the Direct Delivery Automation filed is driven by three rules. Two of which should not be present as parameters and should never be based on the user accessing them. This parameter is centrally managed and is therefore set irrespective of the retail channel or user configuration. 1. Config key enabled (This is ok and logical) 2. User ID is part of a retail channel (Not good practice) 3. The channel the user is assigned to must have "Enable order completion" set (Not good practice). The parameter should be enabled only if the configuration key is enabled and not be dependent on the latter two. If the user would not be assigned to a call centre channel, one would not know this problem would exist and therefore, potentially set the parameter to a completely incorrect value for an implementation. -
Inconsistent behavior in ‘Change Bom Item’ or ‘Change Formula Item’ forms
It was identified, that there is no difference of selected data, when using the ‘Change Bom Item’ or ‘Change Formula Item’. When selecting ‘Edit Bom Line’ or ‘Edit Formula lines’, the system will in both cases, display all the BOM and Formula lines. It is expected, that in each form, one would be seeing either only the Bom lines or the Formula lines. -
Financial dimensions are not updated automatically on project purchase order if ‘Update order lines’ parameter is set to ‘Always’
With reference to : LCS Issue 633539 When having the ‘Update order lines parameter’ set to Always update the dimensions, the system is not updating the project purchase order lines with the financial dimension newly added , as opposed to a non-project related purchase order, where it is working as expected and the update occurs. It is expected, that the process would be aligned as such to avoid any human error which may arise if the update may not occur. -
When cancelling the Deliver remainder quantity system is not updating the PurchTotalsSummaryPart
We have the following scenario: If the ‘Deliver remainder’ quantity is canceled , the system is not recalculating the information in the ‘Totals’ /' Purchase order totals form’.
Finance users would greatly benefit if the Totals form would be updated automatically or upon Refresh, without the need of spending a lot of time to calculate manually the Totals as soon as the deliver remainder quantity has been cancelled.
-
The project ID is not copied on the line details while creating a purchase agreement from RFQ
Both references are merged in Deliverable Issue:654615
Reference LCS Issue:572499 - The project ID is not copied on the line details while creating a purchase agreement from RFQ.
Reference LCS Issue:654615 - Error “You cannot specify a project after the record has been saved.” when editing project PO created from RFQ
Issue description:
When a PA (Purchase agreement) is created from a RFQ (Request for quotation), there are two possible outcomes:
- If RFQ header did not have project ID, there is no project information from RFQ lines in PA lines (project details such as project category and activity numbers are copied to the PA lines);
- If RFQ header has a project ID (and different project numbers in RFQ lines), PA lines have project ID from the header and not from RFQ lines;
As the current product does not accommodate the above scenarios as well, it is severely limiting the ability to purchase agreed services/material through the contract (=PA) and affects the reporting process as well as transparency of the purchasing process.
Having the possibility to make use of such case scenarios from a standard product perspective, would be of great benefit and flexibility.
-
The Proforma confirmation document number will always be 1 higher than actual purchase order version when change management is active
Issue reference# Issue 671284
Whenever posting a Proforma Confirmation journal, after the purchase order was submitted for approval and approved creating the first purchase order version, the PurchOrderDocNum is increased by 1 . The Proforma confirmation document number will always be 1 higher than actual purchase order version.
Customer who have implemented extensions to help with the internal business processes are highly impacted due to this behavior since internal reports and retrieved data are incorrect.
A change in order to amend the behavior would be of great benefit.
You’re offline. This is a read only version of the page.
