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

Anthony Etzel
/ Categories: Infor LX & BPCS Tips

BPCS/LX Tip of the Week: Getting the Most Out of the Shop Order Inquiry Program – Part 2

Understanding: How many hours remain in total and at each operation?

Now let’s look at what information is being supplied from the shop floor.

It’s not uncommon for transaction reporting to be captured manually on the shop packet that was issued to the factory floor when the SO was released.

The big question is, is anything done with the data? Is it collected and keyed to a  spreadsheet and not shared, or is the transaction data keyed to SFC600? If it is being keyed, ask how often and by whom? Some companies use alternative methods to capture transaction data that do not require batch keying via a keyboard.

Not a lot of data is required to be keyed to SFC600 in order for the SO Inquiry to be useful. The data that should be reported for the transaction process is as follows:

  • The type of hours being reported – machine, run labor, setup labor
  • If reporting setup and run labor you want an employee clock number
  • The shop order and the operation that is being reported
  • Is the operation complete
  • How many good were produced at this operation
  • How many hours – the numbers of hours are critical. Do the employees estimate how many hours they worked, or do they track actual time started and stopped in order to calculate the actual number of hours.

Based on what is captured and how often will have an impact on the SO inquiry screen. Understanding the batch times as to when the transactions are keyed will provide you with the window as to the SO status at that point in time. Or, are they keyed as they happen in a near real time fashion so that you can have a more current view of the factory floor.

Previous Article Baan/LN Tip of the Week: ERP Setup - Pros & Cons
Next Article Downtime Tips
Print
33160 Rate this article:
No rating
Anthony Etzel

Anthony EtzelAnthony Etzel

Other posts by Anthony Etzel

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

Who gets involved?
  1. Most commonly Engineering is involved in writing the rules, creating the bills and routings.
  2. Sales or Customer Service determines the questions and the order they are asked in.
  3. Sales or Customer Service determines the rules for the pricing.
  4. Sales, or Customer Service, and Engineering work together in determining the part number, description and text.

What are the steps?

  1. You must start by defining the features and options (questions and answers) and the order in which these are asked. We work this out first using sticky notes and large easel paper. Normally during the process we find that we want to move these questions around. Setting them down on paper makes the process of getting the data into Baan much more efficient. We also then have a record of what decisions were made prior to entering the data. This is normally a joint effort of Engineering and Sales. This is required and must be the first step.
  2. Constraints for features and options. These are the rules for determining what questions are asked and which options are allowed. This is generally done by Engineering or whoever is responsible for the configurator. This is required.
  3. Generic Bill of Material. All possible bill options are entered here and constraints are written to determine which options are selected based on the answers to the questions. This is generally done by Engineering or whoever is responsible for the configurator. This is a required step.
  4. Generic Routing. Similar to the bill of material, but used for generation of the routing steps. This is generally done by Engineering or whoever is responsible for the configurator. This is optional.
  5. Generic Item Data. This consists of creating custom item numbers, descriptions, text, material, size or standard fields in the custom item master. This is generally done by Engineering or whoever is responsible for the configurator though Sales may have some involvement. This is optional.
  6. Generic Pricing. This is used to calculate the selling price based on the answers to the questions. This is normally a responsibility of Sales or whoever determines the pricing. This group is also trained on writing the constraints for this section only. This is optional.
First148149150151153155156157Last

Theme picker

Categories