SAPExecuteMethod PlanDataSave can result in successful saves of inconsistent data

[Former Member]

I've been testing the SAPExecuteMethod PlanDataSave functionality in VBA, and it seems to differ from the Analysis Save button.

If I edit a restricted key figure, at various time periods, so that they're inconsistent, as follows (The order of edits doesn't seem to be important):

Half 1: 5,000

Half 2: 6,000

Year: 14,000

I can press the official Analysis Calculate and/or Save buttons as many times as I like, but I will always get a BRAIN error: "Disaggregation not possible. No reference data found (BRAIN 280)". After which, if I want to save my data, I must go back to Previous Consistent State or Previous Saved State.

However, if I try to use the Save method from VBA, I get an error on the first attempt, but a subsequent attempt will successfully save. It seems to save the lowest level edits (in this case, H1 and H2), and discard edits at higher aggregation levels, so the data, after save, appear as:

Half 1: 5,000

Half 2: 6,000

Year: 11,000

Furthermore, in my testing, the number of save attempts required for a successful save seems to depend on the number and level of the edits. For example, editing year and half requires only 2 VBA calls before a Save succeeds, whereas editing year, half and quarter might take up to 4 save attempts via VBA.

I also find that attempting a save via the Analysis Save button (which fails, as it should), followed by a single call to the VBA method, will succeed (when editing year/half, as per above example).

Clearly the VBA functionality should match the Analysis Save button functionality, but it does not. It seems like Analysis keeps track of when it encounters inconsistent data (after a calculate or save attempt), because an initial calculate/save attempt using the Analysis toolbar takes some time, but subsequent attempts fail almost instantly. The VBA save method however, seems to take it's time on every attempt, as if it is ignorant of whether it has tried to save the data before. At some point, the VBA save will succeed, and the user will not necessarily know that they've only saved some of the data, and that the data that was saved might not have been the data they intended to save.

As an aside, perhaps an "InconsistentState" property could be a property that is exposed via an Analysis API call?

I consider this to be a rather serious bug. If developers make the VBA save functionality available to users, or part of a larger routine, then it should behave the same as the Analysis ribbon's Save functionality. In fact, I'd argue that once Analysis encounters an inconsistent data state, it should disable the Calculate and Save buttons in the ribbon until the data is reverted to a consistent state. The VBA Save and Calculate methods should also, on subsequent attempts, fail (almost instantly), until the data is reverted to a consistent state.