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.
Related
I am trying to calculate stock market liquidity by using the effective spread, quoted spread and price impact. one of the variables that I need is seller and buyer initiated trades. How am I able to extract that information from Bloomberg ?
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.
When using API calls such as https://developer.yodlee.com/Indy_FinApp/Aggregation_Services_Guide/REST_API_Reference/getItemSummaries to get item summaries, is there any guarantee of consistency of fields between different institutions for the same acctType?
As an example, if you have a savings account (i.e. acctType is savings) with Westpac (Australian Institution) which has a currentBalance with amount 368.00 and currency AUD, will the same field currentBalance exist for a savings acctType for ANZ (another Australian institution), with the exact same fields. Is there a comprehensive list which details which fields differ across acctType (should they differ at all)?
Furthermore, is there an enumeration of the possible acctType that you can get when querying customer data from an institution
Also is there documentation that describes what field names mean, as an example there is acctType and localizedAcctType, what is the difference between the two?
Finally is there a list of institutions separated by countries (in my case, Australia) that we can use by reference?
Yodlee has data model designed as per different types of banking products like bank accounts, credit card accounts, loan accounts, investment accounts and so on. In Yodlee's terminology all these different products are called as containers. Now each container has their own set of fields which are relevent to any type of accounts under that category. Account_types are also a field under each container.
Now savings/Checking accounts comes under bank container and will have same set of fields across all financial institutions and will not vary until and unless the financial institution does not have any of those fields present at their website.
You can find the list of accountTypes from this link
https://developer.yodlee.com/Indy_FinApp/Aggregation_Services_Guide/Data_Model/Yodlee_Account_Types
For complete look at the Yodlee data model you can check
https://developer.yodlee.com/Indy_FinApp/Aggregation_Services_Guide/Data_Model
As of now we don't have any documentation which provides the meaning of each an every fields. You can actually ignore the localizedAcctType field and use the value from acctType field. Similarly you can ignore any such fields for different responses.
There is no such list available but there are APIs to get list of institutions by geographic region.
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.
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.