I have hear from the some where the char of account is used based on the different country it means that the char of account used based on different different country and analytical account is used as in service type of products.
I don't know am i right or wrong.
Please clarify me in depth which situation we are using the chart of account and which is not and which situation we are using the analytical account in ODOO (Formally) and which is not.
In principle, accounts that made up the chart of accounts are taken into general ledger posting i.e used to prepare BS, P/L etc, while the analytical accounting are mainly used only for companies internal use and doesn't affect anything in real accounting.
The general accounting system is a legal obligation. It must conform to certain accounting principles and must represent a fair picture of the financial situation of the company by producing a balance sheet and a profit and loss statement. Its foundation is the Chart of Accounts, made up of eight classes. Classes 1-5 are balance sheet accounts and classes 6 and 7 (expenses and revenues) are used for the profit and loss statement. All journals and accounts post to the General Ledger.
The second accounting system used in some countries is called Analytical Accounting. Its main purpose is to track expense and revenue accounts by categories in order to derive profit and loss by activity. Its foundation is a separate Chart of Accounts made up of a single class (class 9). Its journals and accounts post to a separate ledger (the Analytical Ledger.)
Some European countries use two types of accounting systems. (The United States and most other countries use only one.)
The chart of accounting will differ from country to country. For example US uses Account receivable and Account payable accounts which is equal to Debtors and Creditors accounts in Indian accounting. So Odoo keeps the chart of account based on the country.
Chart of Accounts are real accounts used for legal Purpose but Analytic Accounts are Just like same but only for Analysis Purpose like Budget Management Purpose etc.
Related
To create an accounting report (such as Income statement/Balance sheet/ Cash flow statement), certain accounts have to be considered, for an income statement we need to consider the revenue, depreciation, cogs, interest, tax,... and so on.
My qestion is for an accounting software to generate the report, there is a critria/algorithm to use to pick the right group. How would this be approached?
surely not enumerating all the possible accounts, since those will just be names, and can be any value,
Enumerating the the tree then? enumerating the right part of the chart of account tree? This implies some rigidity in the initial setup of the tree, making sure every new account falls somewhere in the current tree (Assets/Liabilities/EQuity/Income/Expense)?
For a report like the income statement this is more involved since the income related to operating activities has to be distinguished from investing and financing, can this be distinguished in software simply from examining the right part of the chart of account tree?
Yes, it can be distinguished in software simply from examining the right part of the chart of account tree
I am wondering if there is a way in Excel, using Bloomberg API, to find if tickers have changed or acquired by other firms.
For example, given these values,
BOFI US (Axos Financial Inc)
EVHC US (Envision Healthcare Corp)
COOL US (PolarityTE Inc)
it should return
AX US (ticker change on 2018/10/01)
Acquired by KKR on 2018/10/11
PTE US (ticker change on 2018/09/18)
respectively.
The first thing worth doing is to find out what's the status of the security:
BDP("BOFI US Equity","MARKET_STATUS")
returns TKCH signifying a ticker change. Next, you probably want EQY_FUND_TICKER described as:
Returns the equity ticker for the primary security of this class/line. Primary security refers to the security trading in the class/line's primary market.
Or FUNDAMENTALS_TICKER described as:
Specifies the ticker to access equity fundamental data for a company. The price data of the fundamental ticker is used to compute most financial ratios which combine market data and equity fundamental data. If a company has several listings/tickers, Bloomberg selects the fundamental ticker based on listing dates, country of domicile, and liquidity.
To clarify, I would only use either of these 2 fields if MARKET_STATUS is TKCH.
I have searched and searched but to no avail... has anybody created a payroll module for a U.S. based company? It seems that most of what I've seen is that companies are using payroll companies to process their payroll, but I haven't found anybody using OpenERP 7 for hourly employees with the U.S. tax system (it's not a flat tax rate).
It seems like what I may have to do, is create tax table in PostgresQL for federal, state, and local taxes, then reference those tables in the deduction calculation. I read one article on using the vendors/ or suppliers module and implementing a tax structure from that, but then again, those are still flat rates. I have to believe someone else has done this for the U.S. payroll system, and probably done it better than I could as I am fairly new to OpenERP.
I am in the process of doing something similar for LedgerSMB. The thing is that doing this on an open source model is extremely painful business-model-wise. I am working on solutions to that part but that's outside the scope of your question.
In general many US taxes are set up in marginal rates with certain minimums and maximums. For example income tax withholding is a set of marginal rates within tax brackets. Same with FICA and FUMA, but FICA taxes are capped at a certain level, so a simple tax table with rates, minimums, maximums, etc. and then a way of handling deductions to determine the correct line may be sufficient.
But users of most open source ERP's use third party services for payroll.
I have worked in an ERP. How we did is just calculate the FIT in yearly for all the employee and subtract the withholding amount with multiples.
FIT => Taxable Wages Yearly - (No.of withholding(Exemption))
Do the process as per the revision based on single or married only for annually. No need to update all the tables.
Then,
Divided it based on the frequency from the employee table information
EX:
for monthly : FIT/12
for daily : FIT/365
For SIT you have to use based on the document in the state usine case function.
I have a cube that I built in SSAS for general ledger data. The cube uses 2 fact tables. One for accounts that are "normal" dollar based accounts and the other is for unit / statistical accounts - accounts that count ANYTHING, except for money usually.
I need for one calculated member in SSAS to be ANY of the "normal" dollar based accounts divided by ONLY one particular dimension of the statistical accounts.
If clear as mud - let me give the specific example. There is an statistical account called Gallons (measure is units) and there are many accounts such as sales, depreciation, tax expense, etc that are the "normal" G/L accounts (measure in dollars). I need to have the cube be able to report on ANY of the "normal" G/L accounts DIVIDED by Gallons (so that any of the normal revenue / expense accounts can have a measure that shows BY GALLON.)
I have no clue how to write the MDX to do this (the function to use and / or the syntax) and I have tried many times and researched quite a bit (I am a SQL person - FAR from a MDX person I guess!). I'm thinking I need to use FILTER but I'm not even sure that is the right direction.....
Little unsure with your design ,If you are having trouble with MDX you can create a calculated member in DSV using T-sql
We create point of sale software for the mac, and are looking to revamp our tax engine. It's pretty simple now, with taxes consisting of a name, code and rate that can be applied to every product individually. While this is good enough for some people, we've had lots of requests to handle more advanced situations. Some examples are US City/County sales tax, Canadian compound (stacked) taxes, French ecotax and NYC luxury tax.
We've identified most of the characteristics that these taxes have and are leaning towards a sort of rule-engine based implementation. We don't have to support every case out there, but we want to be able to extend it if needed (to avoid another rewrite).
We're looking for advise from people who built something like this before, or examples of projects that try to solve the same in an elegant way.
My suggestion would be to use database tables for what they are good for (storing values) and rules for what they are good for (business logic). I would certainly not put things like tax rates or lists of jurisdictions in rules - those should be in tables. What I would use a rules engine for is defining the logic that determines which rate to apply to which transactions. So, for instance, if I buy a set of products online from a company based in State X that ships from State Y to three different locations, what tax rates apply to which parts of the transaction?
This combination of rules and database tables is very common - the rules make sure you look up the right things while the tables aid in reporting etc. For instance, the California DMV did this with vehicle registration fees - all the various fees are stored in a database while the rules that determine which fee applies to which car are managed in a rulebase.
If you try and put everything in rules you will not be able to report well and if you try and put everything in database tables you will end up with dozens of tables to manage all the exceptions and corner cases.
JT
I would recommend a set of database tables and joins.
Example:
Jurisdiction: list of states, counties, countries, cities, etc.
Product: obvious
Store: list of locations you sell from
StoreJurisdiction(StoreID, JurisdictionID): the list of Jurisdictions the store is
responsible to collect taxes for
ProductTaxCode(ProductID int, TaxCodeID int): the type of product for the purposes of taxes: basic, luxury, etc.
JurisdictionTaxCodeRate(JurisdictionID, TaxCodeID, InterestRate, RateType): for each applicable combination of Jurisdiction and Tax Code, provide the tax rate to be applied, and the type of rate (compound, simple, etc.).
To find the list of taxes to apply, all you need is an INNER JOIN of the store, its jurisdictions, the jurisdictiontaxcoderates for those Jurisdictions, and the product's tax codes.
You could define ProductTaxCode as a View so all products receive a default TaxCode unless a special one is provided. By abstracting TaxCode, you can have the same metadata about a product ("Food" for instance) apply to different regions in different ways. If a particular jurisdiction has its own definition of "food", you just add a jurisdiction-specific code and apply it to products as needed.
This may require some tweaking for Internet purchases, wholesale purchases, and other situations where the sale is somehow exempt from taxes or the customer is responsible for remitting them. It would also need tweaking for situations where the customer's location, rather than the store, decides the tax rate.
Other tweaks: here in Texas, for instance, we have a "tax-free" weekend where state and local taxes are not collected on some classes of products where the individual item's sale price is less than $100. The idea is to provide cheaper school supplies, clothing, etc. for children heading off to school for a new year. This sort of tweak could be implemented by having a date range table for each JurisdictionTaxCodeRate going off in the future as far as they can be planned.
Here is an example of a "home rule" city in the Denver, CO metropolitan area:
http://www.c3gov.com/pages/about/division_salestax.html
You, as a retailer, may also need to send the tax payments to different locations. For cities that are not "home rule" cities (which is a special term that probably only applies to Colorado, but then probably every state has some equally special term like it), you'll send all the tax payments to the state who will then deal them out to the relevant parties. Colorado has a feature where there are "special tax districts" that are permitted to collect sales taxes for certain benefits (on the example link, RTD is the public transportation district, and "Invesco Field" is the stadium where the Denver Broncos play).
To expand upon Mr Tallent's answer on this thread, you'll need to also include in the Jurisdiction table some way of representing that the taxes may go to different places.