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
/ Categories: Infor LN & Baan Tips

Infor LN & Baan Tip of the Week: Warehouse Blocking – LN 10.7

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.

Previous Article Partner News: Are you up to date on all of the sales tax changes that have gone into effect this year?
Next Article Consulting News: Are you familiar with your Infor LN / Baan System Log?
Print
36582 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 “Use Customer Requested Delivery Date” parameter has been introduced in the Sales Order Parameter (tdsls0100s400) session, which is used to track the customer’s requested delivery date.

If this parameter check box is selected, various additional date fields become available to track the customer Initial Requested Delivery Date and the Original Promised Planned Delivery Date.

In a scenario where performing job A depends on the result of job B, it is hard to decide at what time job A must be scheduled, and how long job B runs. To handle dependent jobs, you can now create a job group. Use the Job Groups (ttaad5140m000) session to create a job group. A job group has a name, with the same characteristics as a job name, and a description. The Status and User of the job group are handled automatically.

After creating the job group, the jobs are added to the group, approximately in the order the jobs must be performed. The first job in the group (with the lowest Group Number) determines the handling of the whole job group, such as execution date and whether the job group is being repeated. If the job group is not repeating, the job group and all non-repeating jobs in the job group are deleted when the job group has run.

The dependencies of the jobs in the job group are also determined. A job in the job group can only depend on a job in the same job group with a lower job number.

You can use the specific options in the Job Groups (ttaad5140m000 andttams5640m000) sessions to change the status of the job group. The job group statuses have the same meaning as the status of the jobs and the same status changes are allowed.

Note: Job groups are only handled by the BSE service Job Scheduler Service.

First6364656668707172Last

Theme picker

Categories