Data Mismatch while fetching the data from one module to another



I was facing an data incosistency in few of my modules. Here in my model, "Import Rebate Actuals" is the module which drives data into rest of the modules. 


"Import Rebate Actual" is a module which has proper data init but while fetching this data into other modules then the data in fetched modules gives us inproper data.  Please find below screen shot, which has filtered the data with Contract Group Type is "REBREG", Contract Group is "State Program", Product is "BRILINTA' and the Customer "IN - Indiana" is showing Contractid's as 27_IN & 28_IN but in 'Import Rebate Actuals' module has only '27_IN' contractId for the same above selections.


What might be the cause of getting unappropriate data ? Please let me know if any additional information required that i can share to you for clear understanding ?






  • Hi,


    When linking data from one module into another via formula, either the lists that the modules are based on need to be aligned, or the Line Items (that are being referenced in sum/lookup/select statements) need to be aligned (which may be the case here).  By aligned, I mean they must be formatted the same. 


    In the "Import Rebate Actual" module, ensure that the Contract ID line item is formatted to the Contract ID list (in the destination module).  Often, Actual data is loaded into TEXT line items, and a TEXT line item will not sum into a List Formatted destination module... even though the values might look the same otherwise.


    I've seen this (recurring) issue handled two ways:

    1.  In "Import Rebate Actual", format the Contract ID Line Item to the Contract ID list... and load the correct values.  I prefer this approach because it forces the data to be loaded correctly, and kicks out any items that aren't defined in Anaplan yet.

    2.  In "Import Rebate Actual", load Contract ID to a Text formatted line item, and then add a 2nd line item that is formatted to the Contract ID list... inserting a FINDITEM function in that line item.  This will permit you to load bad data, but you will have to create a filtered view to audit the load (to make sure all your FINDITEM statements are finding somthing in the list).  I see this more often than not, but I'm not a fan.  In my opinion, persistent problems with data should be handled earlier in the workstream (there are always exceptions, but this is what I shoot for).