Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
There are several recommended practices that you should follow when you configure posting profiles throughout the system. This article describes different scenarios and the corresponding recommended practices.
Setting the Do not allow manual entry flag
On the Main accounts page, the Do not allow manual entry checkbox should be selected for any main account that is used for a posting profile. This setting prevents users from manually posting a journal entry to the main account. Therefore, it helps ensure that the subledger remains in balance with the general ledger and helps make the reconciliation process easier.
If adjustments are required to an account that is controlled by the system and automatically posted, you can use one of these approaches:
- Create a secondary main account where the adjustments can be posted. Then use a Total account or a special row on your financial reports to group and sum the accounts together.
- Reverse the original transactions in the appropriate subledger, make any required corrections, and then repost the transaction through the same subledger.
Changing posting profiles after transactions exist
If you change a posting profile after transactions exist, the reconciliation can fail, and your subledger and ledger can become out of balance. In general, we recommend that you not change the posting profile after transactions exist.
If changes are required, use the following guidelines to help ensure the integrity of the system:
- Make the changes during a period close.
- Make the changes when no other transactions are occurring in the system.
- Validate the ledger and reconcile it to subledger before and after you make the changes.
- Posted transactions aren't updated if you change the posting profile. Carefully consider whether any adjusting entries are required for your change.
- If you're changing inventory posting profiles, consider how the changes will affect your on-hand inventory and ledger balances. Some changes might require that you bring the inventory to 0 (zero), close the inventory, and then bring the inventory back in after the changes are made.
- Always test your changes in a non-production environment before you make them in production.
Using database logging to audit changes to posting profiles
Consider setting up database logging for each posting profile and parameters tables that control posting. Then, if a parameter or profile is changed, you will have a full audit record of what value was changed, who changed it, when it was changed, and what the previous value was. This information can be critical during your reconciliation process, and your auditor might require the supporting documentation.
For more information, see Configure database logging.
Use the following table as a reference for common table names that are related to posting profiles and related posting parameters.
Page name | Navigation path | Table name |
---|---|---|
Accounts payable parameters | Accounts payable > Setup > Accounts payable parameters | VendParm |
Vendor posting profile | Accounts payable > Setup > Vendor posting profile | VendPosting |
Charges code | Accounts payable > Charges setup > Charges code or Accounts receivable > Charges setup > Charges code | MarkupTable |
Methods of payment | Accounts payable > Payment setup > Methods of payment | VendPaymMode |
Cash discounts | Accounts payable > Payment setup > Cash discounts or Accounts receivable > Payment setup > Cash discounts | CashDisc |
Payment fee (Vendor) | Accounts payable > Payment setup > Payment Fee | VendPaymFee |
Accounts receivable parameters | Accounts receivable > Setup > Accounts receivable parameters | CustParm |
Customer posting profiles | Accounts receivable > Setup > Customer posting profile | CustPosting |
Methods of payment | Accounts receivable > Payments setup > Methods of payment | CustPaymMode |
Payment fee (Customer) | Accounts receivable > Payments setup > Methods of payments | CustPaymFee |
Asset leasing parameters | Asset leasing > Setup > Asset leasing parameters | AssetLeasePostingAccounts AssetLeaseJournalParameters AssetLeaseExecutoryCostPostingAccounts |
Bank accounts | Cash and bank management > Bank accounts > Bank accounts | BankAccountsTable |
Bank transaction types | Cash and bank management > Setup > Bank transaction types | BankTransType |
Elimination rules | Consolidations > Setup > Elimination rule | LedgerEliminationRule LedgerEliminationRuleLines |
Expense categories | Expense management > Setup > General > Expense categories | ProjCategories |
Fixed asset parameters | Fixed assets > Setup > Fixed asset parameters | AssetParameters |
Fixed asset posting profiles | Fixed assets > Setup > Fixed asset posting profiles | AssetLedgerAccounts AssetDisposalParameters |
Currency revaluation accounts | General ledger > Currencies > Currency revaluation accounts | CurrencyLedgerGainLossAccount |
Accounts for automatic transactions | General ledger > Posting setup > Accounts for automatic transactions | LedgerSystemAccounts |
Intercompany accounting | General ledger > Posting setup > Intercompany accounts | LedgerIntercompany |
Transaction posting definitions | General ledger > Posting setup > Transaction posting definitions | JournalizingDefinitionTrans |
Posting definitions | General ledger > Posting setup > Posting definitions | JournalizingDefintion |
Posting (Inventory) | Inventory management > Setup > Posting > Posting | InventPosting |
Cost type codes | Landed cost > Costing setup > Cost type codes | ITMCostTypeTable |
Resources | Production control > Setup > Resources > Resources | WrkCtrTable |
Resource groups | Production control > Setup > Resources > Resource groups | WrkCtrResourceGroup |
Production groups | Production control > Setup > Production > Production group | ProdGroup |
Cost categories | Production control > Setup > Routes > Cost categories | ProjCategory |
Project groups | Project management and accounting > Setup > Posting > Project groups | ProjGroup |
Ledger posting setup (Projects) | Project management and accounting > Setup > Posting > Ledger posting setup | ProjPosting |
Default offset accounts for expenses | Project management and accounting > Setup > Posting > Default offset accounts for expenses | ProjDefaultOffsetSetup |
Rebate management posting profiles | Rebate management > Rebate management posting setup > Rebate management posting profiles | TAMRebatePosting |
Ledger posting group (Tax) | Tax > Setup > Sales tax > Ledger posting group | TaxAccountGroup |
Changing groups after transactions exist
Use caution when you change groups in master data. If you're using groups to define your posting profiles, any change to a group on a master record can have a negative impact on the ability to reconcile the ledger to the subledger. For example, you can configure the inventory posting profile for sales order revenue so that a different revenue account is used for each item group. If you change the item group that is assigned to an item after transactions exist, the revenue on new transactions will be posted to the updated account. However, any revenue that was posted before the change will remain in the original account.
Testing posting profiles
Before your go-live, and after you make any changes or additions to your posting profiles or related parameters, you should test each scenario. At a minimum, you should test each posting type to validate that posting works correctly. However, the recommended approach is to test each posting profile transaction and combination.
For example, you have two customer posting profiles, each of which has three records that are specific to customer groups. In this case, you should test each transaction type.
Posting profiles:
- GEN – The general posting profile that has one group for employees, one for customers, and one for intercompany. Each group points to a different Accounts receivable Trade account.
- PRE – The prepayment posting profile that has one record for all prepayments that points to the Customer prepaids accounts.
Testing scenarios
- Free text invoice for a customer in the Employee group that uses the GEN posting profile
- Free text invoice for a customer in the Employee group that uses the PRE posting profile
- Sales order invoice for a customer in the Employee group that uses the GEN posting profile
- Sales order invoice for a customer in the Employee group that uses the PRE posting profile
- Customer payment journal for a customer in the Employee group that uses the GEN posting profile
- Customer payment journal for a customer in the Employee group that uses the PRE posting profile
For the preceding example, repeat one testing scenario for each customer group, and repeat each group of testing scenarios for each additional transaction type (for example, project invoices and service management).
Reconciling the ledger to the subledger
The ledger should be reconciled to the subledger every period. Many modules contain out-of-box reports that can be used to help do this reconciliation. However, depending on your local requirements, you might have to develop custom reports or extend the existing reports to meet your reporting requirements.
We recommend that you do a mock period close and reconcile each of your subledgers to the ledger before your go-live. We also recommend that you do a mock cutover of all open balances and open transactions before your initial go-live. As part of this process, you should run a complete reconciliation to ensure that the migration of balances and open transactions balance with the legacy systems, and that all subledgers balance with the ledger before new transactions are created.