I would like to make report from sales data in a POS system.
So, I have a ReportGenerator that has a List <Ticket>
The Ticket class represents a registration in the cash register. This can be a SalesTicket (DirectSalesTicket, InvoiceSalesTicket,...) or CashRegisterMovementTicket for a registration of money leaving or entering the cash register without a sale (e.g. taking money to the bank).
InvoiceSalesTicket has a invoiceNumber which a DirectSalesTicketdoesn't have. So I'm OK with having 2 different classes.
For CashRegisterMovementTicket I could make 2 classes (CashInRegisterMovementTicket and CashOutRegisterMovementTicket) that inherent from CashRegisterMovementTicket(which is a Ticket) that represent money that was added to the cash register or money that was taken out of the register.
That would make 3 classes, that do not really differ from one another internally.
When I want to generate a report with al the money that has been taken out of the cash register I can just take the List <Ticket> and only use the ones that are of the CashOutRegisterMovementTicket type.
Another example:
SalesTicket has List <SalesLine>
Some reports are based on SalesTicket that have a gift certificate
So I have NormalSalesLine and GiftCertificateSalesLine, both inherent from SalesLine but internally they are the same.
It feels like I have a lot of classes that are sometimes very similar.
What am I missing?
I think your approach is fine, however if you had only a SalesTicket with a TransactionType property (Invoice, Direct Sales, Cash, etc.) then you can use that property in the report for display or filtering.
If you had some abstract method that is implemented differently across the various SalesTicket types (like CalculateTax()... ) then you had a good reason for multiple types.
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.
I'm using the Yodlee API and its pulling all the data I need including line item transactions for Credit Card/Rewards Points/Bill Pay etc.. but it's only giving a summary for my debit/checking transactions..
I need to be able to pull line item transactions for debit card and checking transactions as well..
I'm using Fast Link and it's showing that its linked as I'm able to pull balances, refresh dates etc.. but I'm unable to access the per transaction data I'm able to pull on the Credit Card accounts..
This works for Credit Card:
$trans_data_checking[5]['itemData']['accounts'][$b]['cardTransactions'][$i]['plainTextDescription']
But the 'cardTransactions' field doesn't occur for the checking/debit card accounts..
What am I missing?
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 relevant to any type of accounts under that category. Now savings/Checking accounts comes under bank container and transactions belonging to these accounts will have field called bankTranasctions and hence you are not finding cardTransaction field for checking/debit card accounts.
In the Yodlee DAG templates, there are fields for ISIN and SEDOL and some other fields that we do not see in the API. Are these fields able to be pulled via the Yodlee API?
If you have downloaded the complete Yodlee SDK folder contents and search the Javadoc/index-all.html for sedol and ISIN you will find multiple properties with these names all in Investment/SEcurities related structures/classes.
A warning, just because the property is there does not mean it's populated. Just because it's populated doesn't mean it's populated with all information (e.g often times sensitive information is obsecured to the last 4 digits such as Account #s).
The fact that I see it as a property in the SecuritiesSearchCriteria however might lend hope to the fact that it is populated with usable info.
ISIN is an unique identifier of a holding in India and SEDOL is a unique identifier used in UK and Ireland. Hence they will be populated for investment account of users from those parts. Also their population is dependent on the availability at the end site(The website from where we are scraping the data)
You can get these details through Yodlee's DataService API.
This API will return the itemSummary which contains ItemData object.
This ItemData object contains the list of accounts and then each account will have Investment data and this investment data contains Holding details which contains all the details for a holding. In the Holding details you can find the method to retrieve ISIN , SEDOL etc.
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.