GRINYA is one of the more complex issues in ERP Finance. GRINYA is the tracking via ledger account of the value of items received on a purchase order that have not been matched to a supplier invoice.

Baan solutions for Baan IV and V were incomplete. To take full advantage of the current GRINYA reconciliation process, check Infor solution #107147, which contains the GRINYA user manual and a link to download the software for your version of Baan. For ERP LN, look at Document Code U8942C US.

It is called User Guide for Reconciliation and Analysis. If you are not running the latest GRINYA solutions, patching will require a good amount of time in filling the Interim tables this solution runs from. Infor has posted several procedural write ups, so check the Support Site and read up before tackling this for the first time.

Be careful with the Planned Delivery Date. Pick lists will not print for orders beyond the date selected. Printing the pick after the Outbound will then print the suggested location on the pick.

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.

What is it?
The configurator consists of a set of features (questions). The options (answers) to these questions then are used to generate the custom bill of material and routing. These questions may be answered at the time of order entry, prior to order entry (in a project or quote) or after order entry (in the project). The order of the questions need not have any relationship to the bill of materials. The configurator may also calculate the selling price, create a unique “smart” item number, custom description and text. Simple rules are used to interpret the answers.

Who uses the configurator?
Companies whose products have options. The configurator eliminates the need for part numbers for all combinations of options. The configurator ensures that the pricing and bills are correct. The configurator also keeps statistics on the frequency the options are selected.

In Baan IV, the order balance amount always includes the tax amount. Consequently, the tax amount must be recalculated every time an order line is modified in order to update the balance correctly. If the tax provider is activated, this requires an API call for every re-calculation of tax.

In Infor LN, users can select or clear the new Include Tax in Order Balance check box in the COM Parameters (tccom0000s000) session to indicate whether users want to include tax amounts in the order balance amount. This parameter has an effect on various sessions in Order Management.

In Infor LN, the configuration of a generic item not always results into a customized item. Configured items can now be customized items as well as standard items. If users configure items without PCS projects, standard items are generated instead of customized items.

In Baan IV, the order balance amount always includes the tax amount. Consequently, the tax amount must be recalculated every time an order line is modified in order to update the balance correctly. If the tax provider is activated, this requires an API call for every re-calculation of tax.

In Infor LN, users can select or clear the new Include Tax in Order Balance check box in the COM Parameters (tccom0000s000) session to indicate whether users want to include tax amounts in the order balance amount. This parameter has an effect on various sessions in Order Management.

One common GRINYA issue would be incorrectly entered Integration Setups.

Check the Baan/LN manual for recommended Integration setups. If such a mistake were to occur, it is important to know for what period of time the Integration was in error. It is recommended that the Integrations Setup tables be audited either through Baan or Database Auditing. Corrections can be quickly calculated when an exact timeframe can be determined.