I needed to advise about the woocommerce plug-in invoice, do you know any way of doing this if we have more languages on the site, such as EN, PL, CZ, HUN, so for each language we need separate invoice numbering. That means if the EN buyer purchases the product, then the invoice number starts 20190001 and if another client comes from the PL and purchases the product so that his invoice is again 20190001 because it is from another country? And so for all countries, each has a separate number of invoices.
Thanks for helping
A large part of the value of having an invoice number is that it uniquely identifies a transaction. If you implement your strategy, you will always need two pieces of information to identify the invoice, specifically the invoice number and the language code. If the language code is a business requirement, I would suggest you use a smart number format. A smart number is a unique identifier that communicates additional information about the entity identified. For example, in your case, the first invoice could be EN001, the second invoice PL002. The first two characters are a language code. The second three characters are a sequential number, and you know by looking at the second three characters that this was the n-th invoice created.
A disadvantage of using sequential numbers is that you expose some information about the volume of your business. This is sometimes illustrated as the "German Tank Problem", based on the story of how the Allies in World War 2 used the serial numbers found on captured / destroyed German tanks to estimate manufacturing capabilities, and subsequently the number of tanks the Germans had. More info: https://en.wikipedia.org/wiki/German_tank_problem
You could use a series of number for each language code, such as EN001 and PL001, but you would decrease the amount of information coded in the invoice number, and you would have a harder implementation in WooCommerce since you would need to maintain index numbers for all languages in order to create the unique invoice number for each invoice.
Related
I am currently trying to implement a trading engine. My code can successfully create and fill limit and market orders. In addition, I would like my engine to have the ability to successfully fill "Fill or Kill" orders. Unfortunately, I have no idea how to write an algorithm for this "Fill or Kill". Does anyone know if there is an efficient algorithm for doing this?
The following is some background for those of you with less trading knowledge. Usually assets to be bought are ordered in a manner such as the following:
Price Amount
$200 3
$300 4
$350 2.5
$400 1.11
If one wants to buy assets, a simple algorithm goes from top to bottom in order to give the customer the best value. A whole row does not have to be completely bought. For example, if I want 4 apples, the code will sell me 3 for $200 and 1 for $300 (going from top to bottom).
Now, certain sellers may give the option of "Fill or Kill". This means that a given row cannot be bought partially. So now lets say that the second row is designated "Fill or Kill":
Price Amount
$200 3
$300 4 (Fill or Kill)
$350 2.5
$400 1.11
In this case, if I want 4 apples, I cannot buy less than 4 from the second row. So now I have two obvious options. I can buy 4 apples from the second row for 4*$300=$1200, or I can buy three apples from the first row, and 1 from the third for a price of (3*$200)+(1*350)= $850. Now in this case, the second option is the better deal. Unfortunately, that will not always be the case depending on the different prices and amount of orders.
These tables will be implemented in SQL and ordered by price. I am trying to implement this algorithm in php. Any help will be greatly appreciated.
The purpose of a "Fill or kill" order is, to ensure that a position is placed to the market at a desired price. Therefore the transaction should be immediately and completely or not enter the market at all. A FOK order prohibits a broker from partially filling. You need a 1:1 order to market match, before the order is placed in the queue/book.
The "no partial fulfillment" is what differentiates "Fill Or Kill" (and "All or None") orders from "Immediate Or Cancel" orders. IoC orders allow partial filling and wait in the book to get more stock incrementally until order expiration time.
The difference between FOK orders and AON orders is, that AON, which cannot be executed immediately remain active until they are executed or cancelled. AON keeps waiting in the book for full match.
FOK gets dropped, if no immediate full match.
Efficient algorithm for Fill Or Kill?
There are two forms "Multi Fill Or Kill" and "Single Fill or Kill".
Single Fill Or Kill
This is probably the easier one. It's a 1:1 match of order to market. If no direct order match, kill. If you do this with a SQL command you have WHERE equals comparisons.
Single means: the order will be rejected, if it cannot be immediately filled against a single order of equal or greater size.
Multi Fill Or Kill
This is probably the algorithm, which you are after.
Multi means: fill with multiple internal orders.
It's said that a FOK order prohibits a broker from partially filling.
That's only true, for the order book communication to the outside.
Internally, an "immediate interal partial filling" happens, until the order is "filled".
For the incoming FOK order, you create an OrderEventGroup.
The matcher might have multiple orders sitting on the book that allow to satisfy the incoming FOK order, but only IF ADDED TOGETHER. On the MatchEvent the OrderEventGroup, is filled with contra-orders matching the order constraint. You match orders in order book, where the quantity/price is lower or equal to the requested amount and price. You fill the OrderEventGroup until the FOK.order.amount equals OrderEventGroup.amountTogether. If OrderEventGroup.amountTogether doesn't sum up at all and/or takes longer than, what you defined as "immediate" execution time, the FOK order is killed.
You get a single transaction, which might have multiple matching steps, with possibly different prices. But that's not communicated. The order report contains: "filled" and "price", "qty" - where price is the average price of the OrderEventGroup. The order submitter would not even know that his order was filled against more than one other order.
The good thing: elimination of execution risk for the order submitter.
The bad thing: you get the average price, without a clue of min max prices in the OrderEventGroup or the number of collected contra-orders.
Fill And Kill
Then, there is "Fill and Kill".
The order is filled to the extent of the quantity that can be immediately filled at the requested price. The remainder of the order is killed/canceled. These orders might end with a status "partially filled". The algo is the same as under 2., except that FOK.order.amount doesn't have to equal OrderEventGroup.amountTogether. The OrderEventGroup.amountTogether is allowed to be lower (partial fill).
The matching algorithm used is mainly a pure time priority (FIFO) algorithm, because this kind of algorithm maximizes the number of effective orders. (Some markets use Pro-Rata matching. And somewhere in-between are LIFFE and the CME algorithms, both combining elements from fifo and pro-rata.)
There should be a pseudo-polynomial dynamic programming solution, similar to that for the knapsack. Maintain a table giving, for all quantities <= the desired quantity, the lowest possible cost at which that quantity can be bought. Start with all entries in the table set to the best you can get using only ordinary offers. Take each fill or kill offer in turn and use this to ammend the table: the new cheapest price to quantity k is min(previous price for k, previous price for k-x plus cost to provide x shares according to the offer you are currently considering). Keep enough backtrack information to work back to a combination of offers from the cheapest price for the target quantity after considering all fill or kill offers. This could be, for instance, a note, for each offer, of the quantities for which it forms part of the cheapest price.
You can skip the offer with the attribute "Fill or kill" and pick the next product. Then repeat with the skipped offer and find the cheapest combination between both solutions.
First, FOK don't sit on the order book. They are like IOC (Immediate Or Cancel) and have a Time In Force of zero. If they don't execute, they are cancelled immediately.
All Or None orders, which are even less supported and less standard, might be have a TIF of end of day or good till cancel. In that case they are not displayed and will execute when they are able to.
Now with that our if the way, are you trying to obey securities law, or is this just a toy system? FOK aren't as standardized a Limit, Market, or IOC orders. Some venues may not even implement them and some have have different definitions if they do.
But, if you are trying to obey RegNMS, you cannot skip the inside of the book to fill deeper (the trade through requirement). I only ever see FOK orders filled on the the NBBO (best bid/offer, the inside), but I think I've used them at once place only that I can remember.
So the algorithm would be simple to see if the inside of the book has enough size and if so, execute against it. If you wanted to be a little more lenient, you could work to the next level, however under RegNMS, a venue couldn't do that if another venue was also showing size at that level (trade through strikes again). That is kind of the point of the order type though, to prevent leakage of your intent to buy/sell.
I'm building an API in Laravel.
Here's my system:
In the system there are performances, it's dates and it's prices. So, 3 tables.
An user can buy tickets to performances. So, another table.
An user has to be able to buy at once several tickets of different prices. One more table, Transaction.
What i have right now is an API that accept POST's with the following payloads:
performance_price_id, performance_id, performance_date_id
So it only accept one ticket per Transaction.
Problem: how to adapt this API to accept several performance_price_id's, so that an user can buy for example 5 VIP tickets and 5 normal tickets in a single Transaction(to the same performance at the same date, of course).
Note: there is not a static number of prices per performance.
Solved it by using a string with the next format:
performance_price_id,performance_date_id;performance_price_id,performance_date_id;...
And instead of having undefined number of payload arguments, i have a well-defined number (2), which are
performance_id and tickets
I am working on a project, and I am trying to find a way to associate my pricing plans table with a customer.
id name description price days
1 Free the free plan 0.00 0
2 Silver the silver plan 49.99 365
3 Gold the gold plan 99.99 365
My first thought was to add the plan id as foreign key to the customers table. But i also need to know when is the expire date (based on the purchase date and the days of the plan selected).
When attempting to do something like this, it is best to keep tables abstracted from each other.
user_pricing_plans - the table name
pricing_plans_id - the id for the record you want to associate with a user
user_id - the id of the user
date_expiration - the date the plan will expire
date_purchased - the date the plan was purchased
following an approach like this will allow you alter this table if needed to add extra information. you could also follow a similar approach in the future with another table.
the key to all of this is separating your concerns ( the data ) into separate containers.
Edit: to kind of hint at what I'm getting at about why separating the tables is a good idea, I added the date_purchased as a field in the user_pricing_plans table.
a dba I know once said that "mysql is not a place for developers - they try to create tables to work with their code. tables are meant to represent data. your code should be written to work with the data and the schemas that represent them - not the other way around"
I do not know why I can not add a comment to the best answer in the post.
As #Jonathon Hibbard points few years ago, there is another reason to separate the data between pricing plan and user model.
You used to have users who have one plan and choose another later, that is called, "history". To manage that, this third table is very important.
And in my opinion, more important, one thing is your pricing table, an another one is the final price you have with every client. Yo have knownledge people, close clients that you want "special" prices, this third table gives you the oportunity to set diferent prices for one plan with fixed price and a lot of other use cases.
Think about your main plan table like a product, the user is the client, and the third party as the ticket, with "temp pricing" aplied, ocassional discounts or whatever.
I am designing an online accounting system as a college project. I have got the following simple transactions.
Sales on cash $300
Cash burrowed from Smith $250
Electricity bill paid $50
I have referred Double Entry Accounting in a Relational Database and designed the above Transaction table(minus sign means the amount is credited). The id 1 and 2 belong to transaction 1, id 3 and 4 belong to transaction 2 and so on. How can I identify each two rows as a single transaction in MySQL database.For example if the first transaction to be selected how can I do it since there is no relationship between the two rows. If this design does not sound good can you suggest an alternative.
You should drop the two line design unless it's really necessary. I would merge the rows and add an extra field where you could store if it was cash or not and the amount value would be + when credited and - if debited (or reversed, I"m not good at accounting :))
Good Job.
The only thing I might add is two number columns for debit and credit. That would look just like a journal in the text books or old bookkeeping books. It would be a little more visibly obvious and handle any number of double entries. Your current amount column could be calculated by debit - credit if you like.
I do not think you need to make it relational unless you wanted a specific chart of accounts as a table, more complicated and less elegant. But, for more flexibly you could generate real time chart of accounts from the journal.
Since you are using MySQL relational database, you can add several tables.
To answer your question, you need to create another table to hold general information for each transaction (e.g. you could call it a TRANSACTIONS). This table could include Transaction ID, and Date Column.
Now, reference the Transaction ID column of the TRANSACTIONS table in your currently existing table. This means record 1 and 2 will have one Transaction ID and so you can reference it as such in your queries.
I have no idea what formulas I should use to create stock-market for my players that they could play it. I use php+mysql. Maybe you can throw any good ideas? I'll be grateful.
The simplest (but not necessarily the best) way of implementing fluctuation in stock prices is by using a random walk, since it has been hypothesised that stock prices can be modelled using such a process. See http://en.wikipedia.org/wiki/Random_walk_hypothesis
So, dp = rand(-1,1) * p * dt where p is the stock price and dt is the time elapsed (probably in days).
Assuming this is multiplayer, in addition to random walk, some consideration of supply and demand can be taken into account. If more shares are bought than sold of a particular stock over a period, its value should go up slightly, and vice-versa. This will increase volatility and perhaps make this portion of the game more exciting.
If you're allowing buying and selling between players (and assuming you've already created the storage part), you just need to expose four methods and let the players define the economy:
Bid (stock, price)
Offer (stock, price)
Buy (stock, price)
Sell (stock, price)
If the stocks already exist in your game, then you just need to let the players define what they want for theirs.