Sending data through input schedules in BPC 7.5

When a Planning and Consolidation (PC) user sends data from an input schedule in Excel the data typically looks like this:

 
In this example we are sending a value of 185 EUR to the following intersection:
CATEGORY=ACTUAL
P_ACCT=CE0004020
P_ACTIVITY=Line
P_CC=AUSTRALIA
P_DATASRC=MANUAL
RPTCURRENCY=EUR
TIME=2007.FEB

The application server receives the data and the COM+ objects will create an entry in the corresponding lck<application name> table – in this case the lckPLANNING table. The purpose of this entry is to provide a locking mechanism so no other users can send data to the same intersection at the same time. This is controlled by the concurrent lock settings specific to each application or model.

The data is saved to the sgData1<application name> table – in this case the sgData1Planning table.

A corresponding record is created in the sgQueue table for the SendGovernor service to process. The SendGovernor scans this table and as soon as a record is detected, it copies the data from the sgData1<application name> table to the tblWB<application name> table, then deletes the corresponding records in the sgData1<application name> table and ultimately frees the concurrent lock by deleting the row created earlier in the lck<application name> table.

When the SendGovernor detects new records in the sgData table, it creates a corresponding record in the sgQueue with the same value for the lckNumber field and with a value of -1 for the NumberOfRecords field.  The rest of the fields in that record have no value set at this point. After that, this record is updated with the complete information like NumberOfRecord. The NumberOfRecord must a smaller value than the SendGovernor UNITPER_SP parameter configured by the system administrator.
This record is then deleted when the records from SGData table are copied to the write back table ( tblWB<application name> ).

Additional information:

Having records with -1 remaining in the sgQueue table indicates there is an issue affecting the SendGovernor or one of the COM+ components (K2processing or EverestUpdate) may have a processing errors.
Restarting the SendGovernor service should delete these records.
If the LCK tables are never cleared, then the users are not able to send data for that specific intersection until these records are manually deleted.
The SendGovernor process may fail because the writeback table is locked by other processes writing data directly into that table or multiple Data Manager packages running at the same time.