With reference to LCS Issue823033 

When Reporting currency and Transaction currency differ, while the postings occur on different dates, it has been observed that the 'Landed cost Goods in transit' is not correctly cleared, voucher transactions being unexpected.

The difference arises due to the exchange rate on the arrival journal date being different from the one on the date of the Purchase Order Invoice.

Dual Currency and its consistency, is highly needed in business processes, being a very common need.  

Many business processes would highly benefit from and enhancement in this area.'

With reference to LCS Issue827545:

When the Expiration date of a Purchase agreement, classified for Direct Invoicing is in the past, then no link is made between the invoice line and purchase agreement. **VendInvoiceInfoLine.AgreementLine_PSN is empty in the VendorInvoiceInfoLine table. 

There are many business case scenarios, where invoices would arrive after the purchase agreement expiration date, that relate to the services or goods from the specific purchase agreement. There is a need to link the purchase agreement as such to ensure that fulfillment is adequately established.

The current behavior is creating not only confusion amongst users since it is possible to select the purchase agreement in the lookup although the expiration agreement date is set in the past, however also incorrect reporting also.

 Additionally, users processing the invoices would not have access to the data, as such to understand, that the purchase agreement is expired, and no link has been made to the agreement.

With a change of the current logic, many customer business processes would greatly benefit from avoiding: incorrect reporting, user confusion, and time loss as such to identify the reasoning, during daily activity. 

 When two registration numbers exist in one legal entity (Germany) and transferring the Intrastat for Transfer orders of the two registration numbers, the Transaction code, statistics procedure Country/region and State/Province are not defaulting the correct values for the e.g. Arrival.

As per the legal requirement, the referenced fields must be transferred and populated for the Transfer order Shipping and Receiving, when the Intrastat is generated and reported.

It would be of great benefit to reconsider the current design of the product as such to more efficiently incorporate the fields to be available in the Transfer order line form for easier processing and avoiding manual rework during the Intrastat preparation as well as accommodate the current legal requirement.

With reference to LCS issue 921873:

When switching from a personalized/custom view to the ‘Standard view’ in the trade agreements form, all trade agreements are shown instead of the one from the particular vendor or customer account.

The behavior is confusing for users, as well as causing great loss of time to exit and re-enter the form to have the needed information displayed, since data is reviewed multiple times per day/per user. 

Users would greatly benefit if a change would be introduced as such to accommodate the current limitation, reduced efficiency and user sentiment would be avoided and would come in aid with the daily user experience. 

With reference to Lcs Issue927117:

When a vendor account is set on hold for ‘Purchase order’ and an existing purchase order is modified to add an extra line, no re-validation is performed, and confirmation is made, which is not expected.

As a daily process, purchase orders are amended regardless of the status. New lines will be added by users, who may not be aware that vendor account is on hold for any valid reason.

Introducing a change which will prevent the addition of lines while the vendor is placed on hold for ‘Purchase orders’, would greatly help avoiding any monetary implications which arise as well as any other undesired, directly triggered situation.

With reference to: LCS 927980 

When changing the quantity on purchase order lines the system will recalculate the Requested receipt date which was already updated/confirmed by the user.

Issues with Master scheduling output related to Planned Purchase orders have been faced, wherein lead time from the Purchase trade agreement has not been considered .In spite of having lead time defined on the Trade agreement, it was not being considered, and planned purchase orders were getting wrong delivery dates leading to wrong material planning for all the sites. This issue was corrected by having the flight enabled ReqCalcTradeAgreementDisregardLeadTimeRespectedFlight together with the need of setting the Disregard Lead Time=NO. Master planning parameters have been configured to find trade agreements with Search criterion=Minimum Lead Time per the business requirement. The process on the Master Planning side is working as expected for the customers in this context configuration, however, since there was a need to disable the Disregard Lead Time flag on the Trade agreement based on the recommendation received ,as such to have master planning consider the lead time based on vendor, it broke the process on the Procurement side, where, if the Disregard Lead Time flag=NO, it will recalculate the Requested Receipt Date on the lines.

Introducing an Infolog which would inform the user that the requested delivery date has been recalculated/updated, would be of great benefit to users as such to keep track of the original Requested receipt dates on the amended lines, and any inconveniences derived on the MRP recommendations right after. 

With reference to: LCS 927978 

When changing the Requested receipt date on the purchase order header, the system is not updating the Requested receipt date on the lines as well even if ‘Update requested receipt date’ =Yes unless the date is beyond the lead time period.

The system should provide a prompt which will inform the user, that the ‘Requested receipt date’ is being recalculated/and or not updated and provide the possibility to choose the action to be performed and propagate the manually input date towards all the lines within the purchase order, if choice is made.

Introducing a change/capability to accommodate this business requirement would greatly benefit customers, and users efficiency however not limited too, when dealing with purchase orders containing many lines. 

With reference to LCS Issue977286 

When a user is typing the customer account in the sales quotation creation form, and the drop-down selection is opened, when selecting the account from the list using the mouse to select the account, the system is not validating whether the account is set on hold or not.

If however, the user is typing the customer account and using e.g. the Tab key to make the selection, the validation occurs and Infolog "Invoice account XXX is stopped for All" is triggered as per the expectation and configuration put in-place.

Kindly help in considering a change to accommodate/correct this behavior as the business implications are very high, as it is leading to decreased business performance and monetary implications.

With reference to LCS 980364:

When posting an invoice for a partial product receipt, the inventory quantities are rounded, and the accrued inventory values of the purchase orders do not match the amounts on the ledger account for purchase accruals.

Due to the given context scenario and standard logic, when monitoring the accounting figures to understand the total amount of outstanding invoices the company needs to address, it is crucial that the outstanding invoices do not significantly deviate from the balance of the purchase accrual account. Should the amount of outstanding invoices increase substantially, the responsible parties must promptly identify which purchases are involved and where the significant amounts have originated from.

The companies must reserve funds for the outstanding purchase invoices. If the figures are inaccurate, the company may need to withhold such a substantial amount of money that it could hinder the ability to make necessary purchases due to the high risk of required credit. In the event that the estimated amount is excessively high, the management may decide to halt certain purchases, thereby slowing down both the purchasing process and the sales delivery process.

This could result in financial losses due to missed sales opportunities and delayed customer payments.

Customer businesses would greatly benefit from having the current application logic reconsidered to e.g. consider using inventory quantities instead.