Account Lock - Allow Input false
HI
Am looking to lock the accounts (Rev first and then COGS ), such that if the Rev load is done i should be locking the Rev account for a particular scenario, then lock COGS account based on the I...
Forum Discussion
Thank you, users will only lock or certify once all their inputs are completed, is there any other option available to lock the accounts for a specific scenario..
I think there may be a misunderstanding going on. How would you like to lock accounts without locking accounts? Using workflow channels is the way.
E.g. if we use Golfstream.
Let us assume the "Import" step is used to import your Rev accounts. After the import, the Import step can be locked.
If that has been set up using workflow channels as described, locking only this single import step will lock only the Rev accounts in the WF period and WF scenario the user loaded and locked the Rev data to.
Then, the users can load the COGS data using the - in this not well-chosen example - "Sales Detail" import step. Once done, this single import step can be locked, which will then lock only the COGS accounts.
The users can then still load data to accounts that do not share any of the WF channels used for Rev or COGS accounts. Only when the overall step is locked, all data of that scenario / time / entity (simplified) is locked. Such as the step for Feb:
If my understanding is correct i should be creating one Import step for Rev accounts, and one for COGS account. But i assume the users will load every accounts in a single import step, they will not separate their load by Rev or COGS. i was thinking if any Business rule or SQL query could make the Allow Input property of account to False based on a Scenario
Hi, yes, that is correct, the WF steps need to be split up. If they are not split up, the import would fail even without WF channels if one theoretically locks the Rev accounts a different way, assuming the users re-load the same dataset (but with updated COGS numbers), because they would try to load to (b)locked accounts. This is why the system requires this split either way.
If you are concerned about a direct connection that loads all data, this can be split as well and only pull the relevant data for the relevant accounts. If the users only have a single source file they manually load, the different steps can use different transformation rules, bypassing the accounts that are not supposed to be loaded in the respective WF step (e.g. bypass Rev accounts in the COGS load step).
The Allow Input property on an account is neither time nor scenario dependent. So even if you were to use this property, you'd be blocking this for everything. And for the next load one would need to re-open the members.
