Actuals data load issue - YTD adjustment being loaded

Peter is spot on. 

To add more color in how OneStream stores data and handles No Data situations.  By default, any data records loaded to the Cube is stored as YTD in the database.  Periodic is always derived, even if your data source is identified as Periodic and the data records in the file/data integration is Periodic.  For Periodic, we store the YTD number and then when Periodic is requested for rendering, we dynamically take current period YTD - prior period YTD to derive a current Periodic number.  Every data record loaded to the Cube for the year will be stored in a database table called DataRecordXXXX (XXXX is identified as the Year being loaded).  For every data record in the DataRecordXXXX, the data record contains 12 value columns ( 1 for each period 1-12 ) and 12 cell status columns ( 1 for each period 1-12 ).  This cell status column holds values that dictate the status of the value for a specific period.  This includes Calc Status, Storage Type ( Stored/Not Stored ), whether data is real or derived data, and if using NoData Zero View Override.  

The real and derived data and NoData Zero View override is what is used when a value for a data record is loaded to the Cube in Jan, for example, but in Feb, a value is NOT loaded for the same data record.  In Jan, the cell status for the individual data record will indicate real data and stored.  Remember when stored, it is stored as YTD.  In Feb, when you don't load a value for that data record, the cell status will indicate that the value is derived and uses NoData Zero View to determine how to handle this no data situation.  

In this situation, the following order of operations happens:

1.  As Peter has explained, the 1st step is to check the setting called No Data Zero View for Non-Adjustments and No Data Zero View for Adjustments in the Scenario Property Settings.

2.  Step 2 is another level of granularity and can override the No Data Zero View for Non-Adjustments and No Data Zero View for Adjustments for the Scenario.  These settings exist through the Import from the Workflow Profile and name as the following:

An example of why to use these setting.  If you had an organization that mostly loads data from a source system that is YTD for Actuals, you would set the Scenario settings as YTD.  However, maybe you have a section of the organization that has a source system that can only produce Periodic values for Actuals.  Since the Scenario settings crosses across all data in Actuals, the Workflow settings can specifically override the Scenario settings during data importing and loading the cube.  The override logic would happen during the Load and Process of the Workflow process.  

3.  The final override can be done at the Account level.  Same settings exist at the Account Member Property level as you would see in the Scenario Member Property.  The default setting is set to (Use Default) which means the Account will use the Scenario Settings first.  If the need is to override at the Account level, then you can do it.  As I like to say, just because you can do it, doesn't mean that you should.  This override should be used as more of "break glass in case of emergency" scenario.  

Hope this helps