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

Kathy Barthelt

Infor LN & Baan Tip & Tricks for OPERATIONS: Best Practices for Purchase Order Archiving / Deleting

 Here are some best practices to follow if you are considering archiving or deleting purchase order data:

  • If Financials is implemented, we recommend that you do not delete order data in a fiscal year that has not yet been fully closed. This is because the GRINYA process uses information that would be deleted by this action. For best results, check whether the logistical balance for non-invoiced receipts matches the balance of the GRINYA accounts for the periods up to which you want to delete purchase order data.
  • When a purchase order is canceled, you can only delete the purchase order and the related tables. If only a purchase order line is canceled, the line can be deleted and archived.
  • Purchase contracts must be archived before purchase orders can be archived.

You cannot delete a purchase order (line) if:

  • The linked warehouse order is closed but cannot be removed.
  • The purchase order is linked to a PCS project that is not yet archived. When the PCS project is archived, the purchase data is also archived and you can delete the purchase order.
  • A consignment replenishment order is not yet consumed completely.
  • The invoice is yet to be completely matched and approved.
  • The invoice amount is not yet inserted as turnover history.
  • The sales order or service order that's linked to the purchase order line, and for which an internal invoice must be sent from the purchas office to the sales office or service office, is not yet invoiced. In this case, you cannot delete the purchase order line before the sales order or service order is invoiced.

Previous Article Infor LN & Baan Tip & Tricks for TECHNOLOGY: Using Table Boosters to Speed Up Sessions & Processes
Next Article Infor LN / Baan Tips & Tricks for EXECUTIVES
Print
9301 Rate this article:
5.0
Kathy Barthelt

Kathy BartheltKathy Barthelt

Other posts by Kathy Barthelt

Theme picker

Contact author

Please solve captcha
x

Tips:  LX | BPCS | M3

The Infor Development Framework (IDF) re-architects the way a user interacts with the application. IDF provides an efficient, task-oriented process to view application information that is contained within Infor LX. IDF enables users to configure their view of the application data without modifying the core application and its supportability.

The examples below describe how users can configure their display of data and maximize overall productivity:

  • Arrange application information into multiple groupings and sequences that make sense for the job.
  • Hide information that does not apply to a particular job or task.
  • Filter records to show only the information that applies to the job or task that the user is performing.
  • Customize the information for an individual user, for a group of users, or for all users.
     

Did you know?  Product interface list, SYS635D

This program creates a report that contains all interface program call records that were created for the Infor LX programs specified in the range on this screen. The report contains a line for each record found. The line displays the following information:

  • The name of an Infor LX program that contains a user exit to an add-on program
  • The interface point in the Infor LX program, that is, an identifier of the point in the program code where the user exit is requested
  • The execution sequence number of the record, because more than one add-on program can exist that can run from the same interface point
  • The add-on program to call at the interface point. The Add-on Product Interface file, ZXI, stores the records.

Access: Menu SYS

First3637383941434445Last

Theme picker

Tips: LN | Baan

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.

12345678910Last

Theme picker

Categories