Please Wait a Moment
X

Infor LX Tips, Infor LN Tips, BPCS Tips, Baan Tips, Infor M3 Tips & Infor ERP News

Crossroads Connections

Infor ERP Tips & News from the Experts

Infor LX | Infor LN | BPCS | Baan | Infor M3

Infor LX/BPCS Tips & Tricks for EXECUTIVES

George Moroses 0 30710 Article rating: 5.0

TECHNOLOGY: Facility Security Ranges

Previously, a user could complete the Cost Transfer (CST920) process for any range of facilities regardless of their security settings established in SYS600. This enhancement verifies the user security settings set up in SYS600 before processing cost transfers for a range of facilities in CST920. If the user has authority for a facility range, but there are facilities within that range that are not authorized, the program skips those facilities and completes the cost transfer process.

FINANCE: Expiration Date for Quotes and RMAs

A Cancel-by-Date has been added to the Quote Header and RMA Header panels. This optional field can limit how long a quote or authorization to return items for credit is valid.  

For quotes, this enhancement provides an optional end date for the quote. For RMAs, it provides an optional date by which the customer must return the items to receive the credit listed on the RMA.

The Cancel-By-Date prints on the Order Acknowledgement and RMA Acknowledgement to inform the customer of this important limitation to the quote or return authorization. 

An Order Entry user cannot copy the quote to create a new order if the Cancel By Date has caused the quote to expire.

OPERATIONS: Default Split Salesperson to Customer Orders

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.

Infor LX/BPCS Tips & Tricks for TECHNOLOGY: Facility Security Ranges

George Moroses 0 19775 Article rating: 5.0

Previously, a user could complete the Cost Transfer (CST920) process for any range of facilities regardless of their security settings established in SYS600. This enhancement verifies the user security settings set up in SYS600 before processing cost transfers for a range of facilities in CST920. If the user has authority for a facility range, but there are facilities within that range that are not authorized, the program skips those facilities and completes the cost transfer process.

Infor LX/BPCS Tips & Tricks for FINANCE: Expiration Date for Quotes and RMAs

George Moroses 0 16840 Article rating: 5.0

A Cancel-by-Date has been added to the Quote Header and RMA Header panels. This optional field can limit how long a quote or authorization to return items for credit is valid.  

For quotes, this enhancement provides an optional end date for the quote. For RMAs, it provides an optional date by which the customer must return the items to receive the credit listed on the RMA.

The Cancel-By-Date prints on the Order Acknowledgement and RMA Acknowledgement to inform the customer of this important limitation to the quote or return authorization. 

An Order Entry user cannot copy the quote to create a new order if the Cancel By Date has caused the quote to expire.

Infor LX/BPCS Tips & Tricks for OPERATIONS: Default Split Salesperson to Customer Orders

George Moroses 0 12526 Article rating: 5.0

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.

Infor LN & Baan Tips & Tricks for TECHNOLOGY: Advantages of Data Replication

Kathy Barthelt 0 68748 Article rating: 5.0

Instead of sharing tables through logical linking, you can replicate table content between companies. This approach allows certain non-key attributes of a record to vary by company. For example, if you replicate bills of materials rather than sharing them, each company can associate a different warehouse with the same bill of material. This way, the bills of materials are consistent across companies, while the warehouses can differ.

Replication also enables selective availability of records in other companies. For instance, when replicating items, you might limit which items are available in a sales company based on their item group, only including end items. You can further refine replication to specific subsets, such as particular item groups.

Keep in mind that replication requires any referenced tables to be either replicated or shared as well.

Infor LN & Baan Tips & Tricks for FINANCE:  Currency Differences Accounts

Kathy Barthelt 0 79022 Article rating: 5.0

Currency differences can make the financial analysis and reconciliation more complex. These types of currency differences can occur:

  • Currency differences
    Currency result caused by fluctuations in the exchange rate, for example, if the rate differs between the invoice date and the payment date.

  • Exchange gain and loss
    Currency result caused by the use of different exchange rate types, for example, the Sales rate type and the Internal rate type, or if using the rate determiner you have changed the exchange rate for a transaction during the order handling procedure.

  • Translation gain and loss
    Currency result caused by the use of different currencies during the order handling procedure, for example, if the order currency or the payment currency differs from the invoice currency.

  • Destination gain and loss
    Currency result caused by different results when the transaction currency is converted to the various home currencies. Destination gain and loss can only occur in an independent currency system.

To support good reconciliation possibilities, currency differences and exchange gain and loss are posted to these accounts:

Infor LN & Baan Tips & Tricks for OPERATIONS: Update, Cancel or Remove Outbound Order Lines

Kathy Barthelt 0 59122 Article rating: 5.0

When the originating order or order line of an outbound order line is canceled or changed, this affects the outbound order line and may affect the related outbound advice, shipments, or shipment lines.

For most order origins, warehousing order-type parameters determine whether these actions are allowed:

  • Update the outbound order line if the originating order is changed.
  • Cancel the originating order line and the outbound order line.
  • Delete the canceled outbound order line.

If updating is allowed...

First1516171820222324Last

Tips:  LX | BPCS | M3

Tips: LN | Baan

Kathy Barthelt

Infor LN & Baan Tips & Tricks for EXECUTIVES

TECHNOLOGY & FINANCE: Archiving Finalized Transactions

To support correct archiving in a multicompany structure, the following rules apply:

  • Each company must have its own archive company. Companies cannot share an archive company.
  • The structure of archive companies must be an exact copy of the live environment.
  • A company must keep the same archive company until the end of its lifetime. Once data has been archived, you cannot change the archive company.

If extra archiving capacity is required, it is recommended that you set up a second archiving environment, which must also be an exact copy of the live environment. Define the companies of the second archive environment as the archive companies of the companies of the first archive environment. If necessary, a third and more archiving environments can be set up. You must then archive the data from each archive company to its archive company in the second archiving environment, and so on.

When you archive the data, LN builds an array with all the companies of the group and the archive company linked to each company. If any of the companies in the group does not have an archive company, LN reports an error and aborts the archiving process.

Batches and batch lines are only archived and/or deleted if you perform archiving and deletion in the company in which they exist. This is always the source company. Any intercompany documents and related finalized transactions that belong to the batch are not archived and/or deleted until the target company is archived.

If the batch has been deleted from the live environment, such intercompany documents and transactions will then temporarily exist without a batch in the live environment until the target company’s transactions are archived. Therefore, it is recommended to archive all the companies of a group within a short time.

Finalization runs are also archived. A finalization run can only be deleted from the live environment if all the attached batches have also been deleted.

Financial documents are archived and/or deleted if you perform archiving and deletion in the company in which they exist. For each document, LN searches whether a related intercompany document exists.

If the document’s transaction type indicates that the document numbering does not have to be in a fixed sequence, the document is not deleted from the live environment, to avoid duplicate document numbers.

A finalized transaction is not deleted from the live environment if the fiscal year of the transaction does not equal the fiscal year of the batch and the fiscal year of the transaction cannot yet be archived. If the Archive option is selected, the related batch, batch line, and document are copied to the archive company and retained in the live environment.

If a transaction is still referenced by open sales orders or purchase orders, it is marked as Deleted but not actually deleted. The related batch, batch line, and document are copied to the archive company and retained in the live environment. They are deleted when the referenced open transactions are closed and archived, for example, when you run the Archive/Delete Fully Paid Purchase Invoices (tfacp2250m000) session

If the transaction’s ledger account is a matchable account, any related matching data is also archived.

During the archiving process, the originating company of the finalized transaction is replaced with the originating company’s archive company. In this way, the archive environment will not contain references to the live environment.

During archiving, intercompany document relations are also copied to the archive environment. In the archive environment, these relations are updated in such a way, that each document in the relation refers to the environment in which the document actually exists. In the live environment, the document relation is retained until all related finalized transactions are deleted. For invoice-related transactions, this only occurs during the removal of fully-paid invoices. The document relation is also updated in the live environment, in order to refer to the archived document if all related finalized transactions have been removed from the live environment.

After the normal archiving process, an additional archiving step is performed in which all transactions and documents in the live company that arise from intercompany postings, are archived. During this step, intercompany relations are archived and/or deleted as described earlier.

Batches, batch lines, and documents that have the Deleted status are deleted from the live environment, unless the document’s transaction type indicates that the document numbering does not have to be in a fixed sequence. Such documents are not deleted from the live environment, to avoid duplicate document numbers.

OPERATIONS: Simulated Purchase Prices (ticpr1170m000)

Use this session to define simulated purchase prices for purchased items per site.

Field Information:

  • Cost Calculation Code - price calculation code
  • Item

The raw materials, subassemblies, finished products, and tools that can be purchased, stored, manufactured, and sold.

An item can also represent a set of items handled as one kit, or which exist in multiple product variants.

You can also define nonphysical items, which are not retained in inventory but can be used to post costs or to invoice services to customers. The examples of nonphysical items:

  • Cost items (for example, electricity)
  • Service items
  • Subcontracting services
  • List items (menus/options)
     
  • ​Site - The site for which the purchase price is simulated.
  • Purchase Currency - The currency of the simulated purchase price.
  • Simulated Price - Purchase price

The simulated purchase price and currency are recorded twice.

  • Simulated Price Multi Currency - The purchase price in multiple currencies.

The simulated purchase price and currency are recorded twice. The amount in this field is related to the price of the supplier.

  • Unit - Purchase price unit
  • Cost Component - The cost component that must be of the type Material Costs.

Note: The cost component specified in this field does not become part of the standard cost detail structure if it is part of the cost component scheme of the selected item. If calculations are performed with a calculation code not used for actualization (simulations only), the simulated purchase price is mapped to the cost component defined in the records for this session.

  • Latest Price - The purchase price that is displayed on the most recent invoice received for the selected purchased item.

  • Average Price - The average purchase price which is based on cumulative purchases or on the current inventory, as specified in the Method of Calculating Average Purchase Price field of the Purchase Order Parameters (tdpur0100m400) session.

Previous Article Infor LN & Baan Tips & Tricks for TECHNOLOGY: Table Sharing with a Multi-Company Setup - Using a Master Data Company
Next Article Infor LN & Baan Tips & Tricks for TECHNOLOGY & FINANCE: Archiving Finalized Transactions
Print
492 Rate this article:
5.0
Kathy Barthelt

Kathy BartheltKathy Barthelt

Other posts by Kathy Barthelt

Contact author

x

Categories