Release 7.11 |
||||||
New Features and Enhancements - Release 7.11.0A summary of enhancements made in updates since Release 7.10 is also included in this document. These include Update 7.10.5.3 whic fixes some problems with SCM price exceptions. ERP Materials Management and FinancialsSourcing and Contract Management (SCM)
ERP Materials Management and Financials Enhancements
|
![]() |
![]() |
![]() |
This problem has been resolved so that documents can be added to a contract whether the user selects the "Workbench" icon, or opens the contract for editing.
The following changes were covered in previously released Notes for each hotfix or update.
ERP
- In some cases, 810 Invoices show "No Data" when edited under the 810 Exceptions menu.
Analysis shows-that records for the invoice were incorrectly unavailable to the edit. This problem has been resolved so that editing of these invoices works as designed.
- Invoices created from 810s were ending up with a Quantity exception if the relevant item was not received and the 810 listed the same item multiple times for the same PO and PO line.
When ERP creates an invoice match detail record from an 810, the received quantity is set as the invoiced quantity and the invoice goes into receipt exception. Later, when the item is received, the receipt exception clears. However, the received quantity was being set incorrectly, and not visible to the user. When the user noticed that the invoiced quantity was incorrect and changed it, the invoice had a quantity exception.
Since the problem of duplicate items is a vendor issue, we cannot influence it. However, we have made the following changes to help users avoid the effects of the problem.
Users were able to select a vendor’s suspended AP location for a check request. A vendor’s AP location for check payments was suspended because the vendor had an alternate AP location set up for ACH payments. However, when check requests were entered, users could select the suspended location. This problem has been resolved so that in situations like this, validations are in place for the suspension so users cannot select the suspended AP location for check requests.
- The system was able to post journal vouchers whose journal entries were out of balance. The likely source of the problem was that the journal vouchers were created from a GL export, and while the import was running, the system encountered a lock. The system could not update either the debit or credit amount on the journal voucher header. When the JV was later edited, the status changed from incomplete to entered. The code checks that the debits and credits are equal, and if they are, the status of the JV can be changed to entered. Since both the debit amount and credit amount on the JV were zero, the edit allowed this to happen.
The code and JV processing has been changed so that in situations like this, journal entries created in the system do not post when a journal voucher is out of balance.
- An out-of-balance approved EDI 810 invoice for a blanket PO created an out-of-balance journal voucher that-the system posted. The blanket PO had a single non-file, zero cost, zero quantity line with receipts. In this situation, processing the 810 import normally creates an invoice with a missing line exception, even if the distribution detail line for the matched amount does not yet exist. When clearing the missing line exception on the invoice and selecting the PO's receipt line to match, code should create the match distribution line, if it is not found. That was not happening. As a result, the PO liability GL transaction was not created when the invoice was approved and left a one-sided AP transaction.
This problem has been resolved by changing the code so that the distribution logic knows that it is clearing a missing line exception, allowing the matched distribution detail line to be created, and ultimately creating the GL transaction for PO liability when the invoice is approved.
- PO Invoices were being set as sales taxable when the vendor's AP location had a tax type of nontaxable.
When the AP Tax Enabled field was selected at the organization level, ERP was ignoring the AP location
default tax type. The correct behavior is: when the Tax Enabled field on the organization record is selected. the system should check the AP location to determine if it is taxable or not. Regardless of the hierarchy, when the vendor's AP location is
non-taxable, ERP should always set the invoice's tax type to non-taxable and the Tax Group field should be
empty.
This problem has been resolved. Here are the other tax rules:
- When the Tax Enabled organization record field is unselected, no tax is applied, and the AP location default tax
type is ignored.
- When selected, the Tax Enabled field for the asset location checks the AP location for the default tax type.
- When selected, the Tax Enabled field for the department checks the AP Location for the default tax type.
- The Tax Enabled field can be unselected at the organization level, but selected at the asset location.
- The Tax Enabled field can be unselected at the organization level, but selected at the department level.
- Blanket requisitions with zero cost/zero quantity lines were dropping the charge override department. When matching the PO to the invoice, users received a message that the GL account was invalid.
Blanket PO lines are receiptless, and their requisitions are created at the time of invoicing. Zero cost/zero quantity lines flow to the blanket PO created from the requisition. During invoicing, ERP deletes any zero quantity/zero cost lines, and writes a system note indicating the PO number created for the requisition.
Because the expense code -- but not the override charge department -- was copied to the PO line, the system was trying to validate the expense code against the department/organization, and could not.
This problem has been resolved. When matching PO invoices generated from blanket requisitions that contain..
• zero quantity line(s)
• an Override Charge Department entered on the Overrides tab,
you will not receive an error message for an invalid GL account.
- When clearing an invoice tax exception for a non-EDI invoice, the invoice would go into EDI Tax Exception status. This problem was traced to the code that sets the EDI Tax Exception flag. The problem has been resolved and clearing non-EDI tax exceptions behaves as designed. The Org Override Charge and the Department Override Charge values are now updated correctly on the PO Line records.
- With some activities, users noted an increase in concurrency errors; for example, changing the buyer on bill-only POs, and then trying to authorize the POs. In general, this problem occurred when modifying information on the PO header for a non-manual / unauthorized PO, and then trying to authorize, authorize later, or save the PO. A long pause could occur, the system would time out and produce an “unspecified error.” Other incorrect behavior could also occur when trying to edit PO lines.
This problem has been traced to an unintended impact of a previous code fix, and has been resolved. Changing data in a PO header or editing PO lines now behaves as designed when you authorize or save the PO.
- Inventory transactions for EDI invoices (direct delivery POs) displayed on-hand quantity for non-stock/non-file item lines. (Non-file and non-stock items do not normally have on-hand quantity.) This problem was related to the way ERP completes invoices and multiple receipt records when the first line is non-file/non-stock. The problem was traced to parts of the code that set transaction types for different types of lines. This problem has been resolved so that on-hand quantities display correctly for direct delivery items.
- In some situations, when a taxable invoice was approved, the invoice went out of balance during the approval process. The Difference for the out-of-balance invoice was twice the tax amount. The problem has been traced to calculations in the code that displays the invoice. This problem has been resolved. Invoices in balance will remain in balance during approvals.
- Deleting EDI 810 invoices with missing line exceptions was creating an “exception” status on the PO. When ERP processes an 810 invoice that contains one or more missing line exceptions, the invoice is put in exception. ERP updates the PO record with the number of missing lines, which then puts the PO match status in exception. When the invoice was deleted, the PO record was not getting changed to reverse the update, leaving the PO in exception. The exception could not be cleared.
This problem is resolved so that the match status on the PO record is now correct; e.g., “Part Received” or as appropriate.
- In some situations, the Invoiced Qty field on a PO line was being calculated incorrectly when the invoice was deleted.
This problem is unique in that a portion of the received quantity for the PO was previously canceled. An invoice was created for the PO ordered quantity, generating a quantity exception. The exception was cleared. However, when the invoice was subsequently deleted, the Invoiced Qty on the PO line detail showed values other than zero. This problem has been resolved so that in this situation, the correct invoiced quantity appears (zero) on the PO line detail.
- Some EDI 810 invoices with exceptions were not appearing on the 810 Import Exceptions - All Organizations list. The application now displays imported EDI 810 invoices with a known 810 detail exception
(present before processing) on the exceptions lists. These invoices have a status of “Ready For Processing.” Previously, these invoices would not appear on the 810 exceptions lists, and you would need to drill into the 810 header, then to the details to find any issues.
ERP, SCM
- After adding a new organization, the PO Edit panel was running slowly. This slowness was occurring only for POs in the new organization for sites with SCM (and ERP). The problem was traced to an SQL query, and has been resolved for the affected sites.
- Users could not process large numbers (over 100) of contract Price Exceptions. The system would time out when the Price Exceptions were being worked. This problem has been resolved so that large numbers of exceptions can be resolved without time outs.
- When the price exception count was clicked on the Contract Workbench's Exception tab, data was displayed, but contained items with a zero price difference. The problem occurred because the system was displaying items on tiers that were manually activated, and whose items should not have appeared as price exceptions. This issue was resolved so that SCM only displays price exceptions for tiers where "Activate All Items" was selected.
- When a contract appeared on the Contract Workbench Price Exceptions tab and the Exceptions tab of the Work with Contract panel, when the price exception count was clicked, the number of records displayed on the Price Exceptions panel did not match the price exceptions count for that contract. This problem has been resolved so that the counts are consistent.
Copyright © 2022by Premier Inc. All rights reserved.