Sales commissions are based on combinations of the Primary, Split, and Line-Level salesperson and the commission codes defined for the customer and item. You can now define the Split Salesperson in the same master files as the Primary Salesperson. While the Primary Salesperson is mandatory, the Split Salesperson is optional. It defaults during Order Create using the identical hierarchy as Primary Salesperson. Using Split Salesperson provides more flexibility in the calculation of sales commissions. The ability to define a default Split Salesperson improves the accuracy of sales commission qualification and calculation and reduces maintenance and adjustments necessitated by corrections.

Previously, Material Requirements Planning (MRP) preferred practices meant that the component's due date was the same as the parent's shop order release date. Because MRP trends have changed, the preference for this due date is the day before the release date of the parent. Although Infor LX already has this functionality in Shop Order Maintenance programs (SFC500), users could not change how due dates were determined for lower-level shop orders in Multi-Level Shop Order Release, SFC530D.

This enhancement provides an additional parameter for Multi-Level Shop Order Release. This parameter allows the user to change how the due date of the child components is determined. The Multi-Level Shop Order Release, SFC5302, has a new parameter for shop orders. The Due Date of Children = Release Date of Prent (Due Date of Children) field allows the user to set the due date determined for multi-level shop orders.

You can use a problem code to indicate that a problem exists for a sales invoice. If the invoice-to business partner notifies you about a problem with the invoice and does not pay it, you can link a problem code to the invoice.

In the direct debits procedure, problem invoices are automatically discarded. For each problem code, you can set an option to prevent linked invoices from being selected on reminder letters.

The audit server logs all database actions that change the contents of a table in so-called audit files. The Exchange module can use these audit files, which are useful in a multisite environment because the databases on all sites must have identical data. These audit files can also be used in data conversions.

Only the updates in a specific period are exchanged, which leads to an improvement in performance. Specify this period in the Export Data (Non-Regular) (daxch0233m000) and Export Data (on a Regular Basis) (daxch0234m000) sessions. Changes such as insert, update, and delete are processed and written into the ASCII files. Actions such as drop, clear, and create tables are ignored.

Audit control data is added to the resulting ASCII file. This data consists of a batchline ID, transaction ID, sequence ID, and an indicator. The control data is added at the beginning of each line and is formatted like other data fields such as the enclosing and separator characters.

An update writes two lines to the ASCII file. One line contains the key fields and old values of the updated fields. The other line contains the new values of the key fields and updated fields, even if a key field does not change.

The batchline ID is used for recognition when processing the ASCII files. The transaction and sequence IDs are used to ensure that the transactions are replayed in the same order as on the exporting site. The indicator defines the type of action that is executed on the table. Use the letter I to insert; use the letter D to delete; use the letter U to update with old values; and use the letter N to update with new values.