I like to know that in Navision, Branch wise Profit & Loss statement can be generate while using Dimension as Branches. But Branch wise Balance sheet not possible. Is it true?
Dimension wise Balance Sheet might not match (debit = credit) if a single voucher has been posted with multiple dimensions and dimension wise total (debit = credit)does not match.
we are using Branch as a Global Dimension to control the Chart of Accounts Branch wise , we use the 1st Branch while doing the Transfer (Order) Shipment and use the 2nd Branch while Transfer (Order) Receipt .
In this case the G/L (Inventory) Account of the 1st Branch (Tranferer) should be Credited by the value & Receiving 2nd Branch G/L (Inventory) Account should be Debited by the Value.
But here in the G/L (Inventory) Account of the 1st Branch (Tranferer) it is both Credited and Debited by the Value again in the G/L (Inventory) Account of the 2nd Branch it is both Debited and Credited by the Value.
Is it Standard process or we are missing something ?
I like to know that in Navision, Branch wise Profit & Loss statement can be generate while using Dimension as Branches. But Branch wise Balance sheet not possible. Is it true?
it's more of a consistency checking problem. NAV only checks that the sum of amounts* by date is zero. For this, you would need a check of amounts by date and by branch. This can be done, and IMO it would be a prerequisite for the reporting by branch. We have done this with extra fields in the G/L entries, but it can also be done with dimensions (although I would prefer extra fields in this case).
When this check is implemented, all postings must satisfy these requirements. This makes "normal" posting a little more complicated and in some cases a lot more complicated. To mitigate this, a few rules need to be set up:
- Documents (Invoice, Credit Memo, all with a document type) need to have only one branch code for the entire document. The reason behind this is that Customer and Vendor Ledger entries can only have one branch code, or you would have a need for split entries (with all kinds of headaches).
- Bank Accounts and Fixed Assets must belong to one branch only and can only be posted with this branch.
To enforce these rules some additional coding needs to be done. And for the cases where you need a change of branch codes you need an interim account that needs to be inserted into the posting to meet the amounts by branch rule.
The "fun" part is that the repoting itself needs only a few customizations, none at all if you use dimensions.
* Amount means Amount (LCY) and Amount (ACY), separately.
Comments
http://ssdynamics.co.in
In this case the G/L (Inventory) Account of the 1st Branch (Tranferer) should be Credited by the value & Receiving 2nd Branch G/L (Inventory) Account should be Debited by the Value.
But here in the G/L (Inventory) Account of the 1st Branch (Tranferer) it is both Credited and Debited by the Value again in the G/L (Inventory) Account of the 2nd Branch it is both Debited and Credited by the Value.
Is it Standard process or we are missing something ?
When this check is implemented, all postings must satisfy these requirements. This makes "normal" posting a little more complicated and in some cases a lot more complicated. To mitigate this, a few rules need to be set up:
- Documents (Invoice, Credit Memo, all with a document type) need to have only one branch code for the entire document. The reason behind this is that Customer and Vendor Ledger entries can only have one branch code, or you would have a need for split entries (with all kinds of headaches).
- Bank Accounts and Fixed Assets must belong to one branch only and can only be posted with this branch.
To enforce these rules some additional coding needs to be done. And for the cases where you need a change of branch codes you need an interim account that needs to be inserted into the posting to meet the amounts by branch rule.
The "fun" part is that the repoting itself needs only a few customizations, none at all if you use dimensions.
* Amount means Amount (LCY) and Amount (ACY), separately.
with best regards
Jens