Skip to main content
Why is my data not showing correctly in AGR?
Updated over a month ago

Overview

Occasionally, data entered or updated in your ERP system may not appear as expected in AGR.

In this article, we’ll explore potential reasons for this issue and outline steps you can take to resolve it.

1. Missing item

1.1. Is the item blocked in your ERP or Closed in AGR?

Check if the item is Blocked/Blocked for purchasing (the names of these fields will depend on your ERP's data mapping).

Items marked as such will not be visible at all or appear as Closed at AGR.

AGR filters out items marked as "Closed" through a default filter in View Settings.

  • Change it from "No" to "Yes" to see all closed items.

  • Closed items will not get a calculated forecast

  • The order transfer between AGR and your ERP, does not allow closed items to be sent to your ERP system.

1.2. Data Mapping

Remember to check your Data Mapping document for any ERP conditions. Only the items that fulfill those conditions will be brought into AGR.

Therefore, populate any missing fields or update existing ones to the expected values.

In the BC example below, the Item.Type needs to be "Inventory" for items to appear in AGR.

Check our ERP-specific data mapping documents to see which criteria's apply to your items:

1.3. Items with variants

When an item has at least one variant assigned to it, standard AGR mapping is that the original item will not appear in AGR.

It's possible to define multiple variants for the same item, but each Item + Variant combination should be mapped into AGR as a separate item.

2. Vendor changes not updating

Vendor updates that are not reflected in AGR, could be due to updates made at a higher level not cascading down to the item level.

  • lead time on vendor not updating due to lead time on item level

  • primary vendor on item card not updating, due to another vendor on location-item level (i.e. discrepancy in vendor data in stock keeping unit table in BC)

Example (BC users):

The vendor details mapped from the Item Card will override those of the Vendor card.

3. Stock levels don't match

There can be several reasons why the stock in AGR does not match the stock in the ERP:

  • A stock transaction has been posted to the Item Ledger (BC) or equivalent transaction table in your ERP after AGR's daily job, around midnight.

    • AGR takes a snapshot of the data at that point, so if e.g. a purchase order was received after the snapshot was taken, it will show in the stock the next time AGR updates data (tomorrow).

In this case, the quantity will show as Undelivered in AGR, and therefore order calculations and Estimated Stock would show the same results, as they consider both Stock Qty and Undelivered

  • Un booked transfer order from another location

  • Is the ERP stock considering the same location(s) as AGR? You can see which locations AGR is considering in Settings > Location setup, accessed via the Navigation bar:

For BC/NAV ERPs, if an Item number is changed, it can cause discrepancies in the Item Ledger Entry table and therefore cause incorrect stock quantities to be presented in AGR.


4. Sales figures don't match

Remember to check your Data Mapping document for any ERP conditions. Only the transactions that fulfill those conditions will be brought into AGR.

Examples of fields include Entry Type, Transaction Type, or similar.

Therefore, populate any missing fields or update existing ones to the expected values.

Check our ERP-specific data mapping documents to see which criteria apply to your transactions:

5. BOM Demand

BOM demand is calculated daily from the need to produce the finished goods, specifically from their Sales Plan and Stock level.

Therefore, expected future orders of the finished good are derived into "BOM Demand" of its components, according to their BOM recipes.

Make sure that your BOM recipes are correctly filled in in your ERP.

If the BOM demand looks unusually high, that might be because the item is being sold independently, but it’s also a component of something else. This is a multi-level BOM.


Did this answer your question?