cancel
Showing results for 
Search instead for 
Did you mean: 

Population of Division (SPART) in PCA documents/GLPCA

Former Member
0 Kudos

The following observations have been made regarding data in GLPCA.

1.  The SPART (division) field appears to be populated nearly 100% of the time for postings from SD invoicing activity (revenues/discounts)..

2.  The SPART fields is never populated for postings from PGI activiy (deliveries, material documents) (COGS)

Can anyone shed some light on how the SPART (division) field is populated in PCA?  Our reporting requirement would only be achievable from PCA if we could ensure it's population all the time.  I don't think this is something controllable via configuration.  We do use COPA, so that would be our primary option...but the business has raised the question "Why can't we report on division fully from PCA...its populated sometimes...why not all the time?".

There seem to be some other instances where the population of division in PCA is affected...Revenue Recognition postings from SD don't seem to have division populated...Settlement postings seem to be another area where the behavior might be affected. 

Accepted Solutions (1)

Accepted Solutions (1)

former_member198650
Active Contributor
0 Kudos

Hi Keith,

At the time of delivery(PGI), the table GLPCA has updated the division. The table will update the division, if it has maintained in material master. Otherwise it will be blank.

Regards,

Mukthar

Answers (1)

Answers (1)

Former Member
0 Kudos

Thank you for the quick answer.  Tested in our system and confirmed that is the case.  Just some more background on the reason for the question....while we have COPA and a division characteristic...there is a recent push to try to get some more reporting out of PCA for things like division that were traditionally only in COPA...this is because in our costing base COPA implementation it is difficult to reconcile COPA to PCA.  I'm finding that PCA's populate of things like division, etc, varies with processes tho...so even it is problematic.