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: Remove Posted Payment/Direct Debit Batches

The functionality of session Remove Posted payment batches tfcmg1259m000 and Remove posted Direct Debit batches tfcmg4259m000 is explained below:

1.These 2 sessions can be used to removed already posted payment/direct debit batches that have been processed through CMG Module. After the batches are changed to removed status they can be deleted also.

2. Only a superuser, defined in the Payment Authorizations (tfcmg1100m000) can delete the payment/direct debit batch.

3. A payment/direct debit batch once removed cannot be retrieved. The data gets removed only from payment advice tfcmg1609m000/direct debit batch tfcmg4609m000 and composed payments/direct debits.

4. The details of the invoices that were selected in the removed payment/direct debit batch can be seen in session anticipated payment/receipt tfcmg2504m000 and from here you go into the anticipated document details to see the list of invoices selected.

5. Remove payment batches does not impact the check master and the check details remain in the check master. 

6. The anticipated receipt/payment document can be reconciled as usual following the receipt/payment reconciliation process.

7. The anticipated payment/receipt document details are not removed from GLD and ACR sessions or tables and can be seen in document history and ACP/ACR open entries.

8. The direct debit batch number can be retrieved from session tfacr6500m000(receipt related document). And the payment advice batch number can be retrieved from payment-related document tfacp6500m000 or the check master if the payment has been done through checks.

Previous Article Understanding Taxability Rules Is Key To Sales Tax Compliance
Next Article Infor LX & BPCS Manufacturing Tip: Production Register Listing
Print
26280 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

Role-Based Security introduces Role type profiles and allows combining the use of Role profiles with the traditional LX User type security profile functionality. The new Role type profile can be defined to allow or deny access to All Products, Attention Key, Products, Programs, and Transaction Effects. Facility, Warehouse, and Company securities are still defined solely by the User profile settings and are not affected by the assignment of a Role. Where applicable, the Role authority is displayed alongside the User authority on the security profile maintenance screens making it easy to see where there are differences in authority between the User and the assigned Roles. 

When Users are assigned to Roles, security access in LX becomes a combination of authorities granted or denied by the Role, plus any User Exceptions. User Exceptions override authorities set by the Roles. A User can also be assigned to more than one Role.

12345678910Last

Theme picker

Tips: LN | Baan

The functionality to block a warehouse for inbound or outbound transactions has been enhanced. A check for blocks is performed not only during receipt and shipment confirmation, but at multiple stages in the process. In addition, you can specify these blocking options for the inbound and outbound processes:

• No

• Yes

• Interactive

For example, if Blocked for Inbound is set to Yes, no inbound actions are allowed in the warehouse. Consequently, users cannot confirm receipts, generate and put away inbound advice or storage lists, and perform inbound inspections. 

If Interactive is set, during a non-automatic warehouse inbound procedure, warnings are displayed which offer the user a choice to either cancel the action or continue. Batch or automatic inbound processes continue, but the corresponding reports and logs make note of the blocking. However, in all scenarios, receipt confirmation is not allowed.

The same rules are applicable for the warehouse outbound procedure steps. The restriction for receipt confirmation also applies to shipment confirmation.

For warehouse transfer orders, not only the ship-from warehouse is checked for outbound process blocks, but also the ship-to warehouse. This prevents situations in which goods get stuck in transit due to inbound procedure blocks that apply to the destination warehouse. Now, the transfer process is already blocked during outbound.

Since label information can be unique to a business, item, customer or functional area, RMClabel allows for an easy method to configure exactly what is needed on any type of label, including 1-D barcode, 2-D barcode and RFID labels. 

Built in label logic allows for automatic switching of label formats. RMClabel is built for Infor LN and Baan. It natively understands the table structures and easily integrates with any data collection application or Infor LN/Baan session

First5859606163656667Last

Theme picker

Categories