Kinaxis KX3-003 Certified RapidResponse Author Level 3 Exam Exam Practice Test

Given the order policies of MultipleQty: 10, MinimumQty: 15, MultipleUsage: Use, and MinimumUsage: Use, the sizes of the planned orders are determined by rounding up to meet the minimum quantity and then to the nearest multiple of the MultipleQty. Order A needs to meet the demand of 25, so it must at least meet the MinimumQty of 15 and then round up to the nearest multiple of 10, which is 30. Order B, with a demand of 12, will also round up to the minimum quantity of 15 and then to the nearest multiple of 10, which is 20, since the MultipleUsage is "Use." The same logic applies to order C, with an initial demand of 20, it is already at a multiple of 10, so it remains 20.

ReferencesThis answer applies the principles of order quantity rounding based on multiples and minimums as commonly used in supply chain planning and as described in Kinaxis RapidResponse's order policy settings.

References:

• The Kinaxis RapidResponse documentation and training materials provide guidelines on how to apply order policies to determine the sizes of planned orders123.

In the WhereConsumed table, the PegPart represents the item driving the need for the component. In this case, the independent demand for AAA requires components BBB and DDD to be produced. The DriverPart is the direct parent in the Bill of Material (BOM) for DDD, which is BBB. The NeedQuantity is calculated by multiplying the demand for AAA by the quantity per of BBB (100 units * 4) and then by the quantity per of DDD (400 units * 4), resulting in a NeedQuantity of 1600 for DDD.

ReferencesThis answer follows the logic of BOM explosion and the principles of MRP (Material Requirements Planning) that can be found in the Kinaxis RapidResponse documentation, which outlines how to calculate the required quantities of each item in the BOM based on the independent demand.

The DaysSupplyRule set to ByPeriod with a PeriodSupplyInterval of a Week means that the planned orders will be generated to cover demands within each supply interval (week) separately. For the first week, the total demand is 25+15+30=70, but the order quantity is rounded up to the nearest multiple of the Days of Supply number, which is 2. Therefore, the order quantity is 80. For the second week, the demand is 40+20+15=75, which matches the Days of Supply number, hence no rounding is needed, and the order quantity is 75.

ReferencesThis answer is based on the Kinaxis RapidResponse concepts for demand and supply planning where Days of Supply calculations determine the size and timing of planned orders, considering the rules set for supply intervals and calendars.

Performance issues often stem from the complexity of calculations and the size of the data sets they are applied to. In this case, the use of a calculated field (NameAndDescription) in the hierarchy definition is the most likely cause of performance degradation. This field is calculated on the fly using a concatenation of the Name and Description, which is a more resource-intensive process compared to using static fields.

Calculated fields, especially those involving string operations like concatenation, can be significantly slower because they require runtime computation. This contrasts with static fields that are indexed and retrieved directly from the database without additional computational overhead.

References:

• Kinaxis RapidResponse documentation on hierarchy design and performance considerations.
• Kinaxis best practices for creating efficient hierarchies and using calculated fields.

Using a calculated field, especially one that concatenates strings like in option C, can significantly impact performance because it requires additional computation for each record. This is more resource-intensive than using a direct field value, which would explain the poorer performance when using the PartFamily hierarchy compared to the PartPlanner hierarchy.

References:

• Kinaxis RapidResponse Author Level 3 training materials1.
• Web search results and Kinaxis best practices2.

To identify the buyer responsible for the component part, you would use the Responsibility function with the appropriate role and the component part as arguments. The resulting column should display the user name, which allows you to interact with that user directly from the worksheet, including inviting to a collaboration, messaging, and sharing scenarios. Enabling the "Display as user name" checkbox on the Column Formatting tab would provide this functionality directly in the worksheet.

ReferencesThe Kinaxis RapidResponse function library contains the Responsibility function and outlines how to display responsible parties for certain records. Additional user interface functionalities such as messaging and collaboration options are detailed in the system's user management and worksheet configuration sections.

To pass information from columns in a worksheet to a script, the form controls used to collect input from users need to be mapped to the script arguments. This mapping allows the script to receive the column data as arguments. Additionally, making sure the names of the script arguments match the ID of the form controls is necessary for the script to correctly identify and use the data passed from the form.

ReferencesKinaxis RapidResponse documentation and best practices for forms and scripting indicate that mapping form controls to script arguments and ensuring the argument names match the control IDs are critical for passing data to scripts.

To enable data caching on a worksheet, you should minimize the dynamic content that can cause the cache to become outdated quickly. Removing hierarchy columns can improve performance because hierarchies often involve complex joins and calculations that can slow down data retrieval. Disabling the "Use As Reference" checkbox on the Part column means that changes in the Part table will not cause the cache to be invalidated, which can be beneficial if the Part data does not change frequently.

References:

• Kinaxis RapidResponse documentation on worksheet performance optimization.
• Kinaxis best practices for enabling and managing data caching in worksheets.

To ensure that a forecast entry is spread correctly across multiple sites, the Site column in the spreading worksheet must be mapped to the Part.Site field. This way, the system knows how to allocate the entered forecast quantity among the different sites associated with the part.

A is incorrect because changing the base table from Part to IndependentDemand would not directly address the issue of distributing the forecast across sites. B is not relevant to the error because mapping the Name to Part.Name does not affect the distribution of forecast quantities across sites. D is not correct because adding a Date column to the spreading worksheet is not related to solving the error associated with distributing forecast quantities across sites.

References:

• Kinaxis RapidResponse documentation on forecast entry and spreading across sites.
• Kinaxis support articles on troubleshooting forecast entry errors and worksheet configurations.

To identify an automation chain and its associated resources, searching for resources based on the specific table involved in the automation (in this case, "HistoricalPartKPI") will help you find the correct automation chain. This approach ensures that you identify all the resources related to that particular table, including automation chains.

ReferencesThe Kinaxis RapidResponse documentation for administrators provides guidance on how to search for and identify resources associated with specific tables or actions within the system, which includes searching for resources based on table names.

Given that the control table setting for OrderPriority.AllocationRule is FairShare and all demands are the same priority, the available supply quantity will be allocated evenly among the demands. The graphic shows there are demands due on Monday, Tuesday, and Wednesday with planned orders due on each day as well. If the total supply on Thursday is not specified in the question, we assume it is enough to meet or exceed the demand. Since all demands have the same priority and the allocation rule is FairShare, the entire supply quantity for Thursday will be evenly distributed. Without the exact supply quantity, the best assumption is that the full quantity needed for the demand due on Wednesday will be allocated.

ReferencesThis explanation is based on the FairShare allocation rule which distributes available supply evenly across all demands when they have the same priority, as per the Kinaxis RapidResponse documentation on supply allocation.

To enable customers to view only their independent demands within RapidResponse, profile variables and worksheet filters are used. The profile variable 'CustomerView' will be set to match the customer name to the user's group name. In the worksheet filter, theOrder.Customer.IDis the correct field to match against the profile variable because user IDs and customer IDs are more likely to be used as unique identifiers in system configurations, rather than customer names which could potentially have duplicates or variations.

Thus, when customers log in, the worksheet filter will apply, and they will only see the independent demands that correspond to their own customer ID, ensuring data visibility is restricted appropriately.

References:

• Kinaxis RapidResponse documentation on user group configuration and data access control.
• Kinaxis training materials on creating profile variables and configuring worksheet filters for personalized data views.

ReferencesThe information is based on the best practices for creating filters and profile variables within RapidResponse as indicated in the training materials and documentation provided by Kinaxis123.

The AvailableRule control table is used to define how available dates for supply and demand are calculated in Kinaxis RapidResponse. This includes the rules for when supplies are considered available for meeting demand and vice versa, such as lead times, transit times, and other considerations that might affect when a part can realistically be expected to be available.

ReferencesThe function of the AvailableRule control table and its impact on the calculation of available dates for supplies and demands is outlined in Kinaxis RapidResponse configuration settings for supply chain planning processes.

When setting the bucket date in an insert definition, if the requirement is to have the record due on the last workday of the week (which is Friday or Thursday if Friday is a non-workday), then the correct approach is to configure the insert definition to use the last workday in the bucket. This will ensure that the due date falls on the correct day according to the specified requirement.

ReferencesThe Kinaxis RapidResponse documentation details how to use bucket dates and adjust them according to workdays in the insert definition setup for crosstab worksheets.

A. The DeliveryRoutes being a Set data type indicates that there can be multiple Delivery Routes referencing a carrier, allowing for one-to-many relationships between a carrier and delivery routes.

C. The Shipments being a Set data type as well indicates that multiple shipments can reference a single carrier, also suggesting a one-to-many relationship.

D. The DefaultTransportationMode being a Reference data type allows for the possibility that several carriers can share the same transportation mode, as references do not enforce uniqueness.

B is not correct because the TransitCalendar being a Reference data type indicates a one-to-one relationship; each carrier can reference only one Transit Calendar. E is also incorrect because the Sources field being a Set data type implies that a carrier can be associated with multiple sources.

References:

• Kinaxis RapidResponse documentation on data modeling and table relationships.
• Kinaxis learning resources on understanding data types and their implications on table relationships.

Using the NOT IN operator with the key fields from the PlannedOrder table in the LKPScheduledReceipt worksheet is the most direct and efficient way to excluderecords that already exist. This filter checks if the combination of Part and DueDate from PlannedOrder records does not exist in the LKPScheduledReceipt worksheet, ensuring that only new ScheduledReceipt records will be created.

ReferencesThe best practices for filter expressions in Kinaxis RapidResponse workbooks, as described in the documentation, recommend using simple and direct expressions that efficiently exclude existing records to improve performance.

Developing a cross scenario data change allows for controlled updates from child to parent scenarios, aligning with company policy on not adjusting lead times in shared scenarios.

To evaluate the impact of converting planned orders to scheduled receipts and then push changes to the parent scenario, while adhering to company policy that prohibits adjustments to lead times in shared scenarios:

• Statement B:Develop a cross scenario data change. This will allow users to make their changes in their scenarios and then push these changes to the parent scenario. This method ensures that changes are captured and transferred correctly while adhering to the company’s policy regarding lead times.

References:

Scenario planning

• Scenario planning capabilities in Kinaxis RapidResponse allow for testing changes in private scenarios before pushing them to shared ones1.

Change management

• The Engineering Change Management application in RapidResponse supports evaluating the effect of changes and determining the optimal time for implementation, which can be adapted for evaluating the impact of converting planned orders2.

• Kinaxis documentation suggests using scenarios to track changes and push them to parent scenarios without affecting system performance3.

• Best practices in Kinaxis RapidResponse include maintaining the integrity of shared scenarios by not altering critical parameters like lead times45.

To manage the demand forecast effectively while simplifying user controls, enabling hierarchy columns would allow users to make selections across different levels of the data hierarchy in one go. For instance, if a user wanted to select a particular product for a specific customer region and distribution site, they could do so without navigating through multiple filters. Additionally, having a hierarchy available for users to select regional distribution sites will allow them to filter data based on their particular region, which aligns with the management of demand forecast by customer region and distribution site. Disabling default filters that are not relevant to the users’ needs can also simplify the user experience but is not specifically mentioned in the given options.

ReferencesThe guidance is based on Kinaxis RapidResponse workbooks best practices, which suggest using hierarchies for filtering to simplify user experience and enable efficient data navigation, as documented in the RapidResponse Author Level 3 training resources.

References:

• Kinaxis RapidResponse documentation highlights the importance of using hierarchies to simplify user controls and enhance data management within workbooks1.
• The Certified RapidResponse Author Level 3 badge details the skills required to create and edit various types of complex workbooks, which includes managing hierarchies effectively2.

This setup allows for flexible data visibility based on user permissions. By creating a profile variable that contains the allowed countries for each user, you can then apply a filter expression to the worksheet that evaluates this variable. If a user is permitted to see all countries (indicated by an asterisk '*'), the expression returns TRUE, otherwise, it checks if the demand's country is in the user's permitted list.

References:

• Kinaxis RapidResponse documentation on configuring data visibility through profile variables and worksheet filters.
• Kinaxis training materials on setting up user permissions and responsibility definitions.