How to group data in SQL query?

Question

SQL

How to group by accounts_count field and by ecminvoiceouts_count field ?
So that the output has the amount in the
accounts_count field: 29+9=31, 24+6=30
ecminvoiceouts_count: 49+10=59, 25+8=33

Answer 1

GROUP BY ..._month
GROUP BY ..._year
or you can combine: GROUP BY ..._month, ..._year

Answer 2

group by accounts_trype, ecminvoiceouts_month, ecminvoiceouts_year

Answer 3

You also add various kinds of games with prices to the production: promotions, discounts, mixes ... well, loyalty to the heap. The theme of terminals or points of sale must also be disclosed, otherwise it will be redone later ..

Answer 4

If I understand correctly, then the SKU needs to be formed in a separate table as a composition of the store, product and price. The product in this scheme can also be a composition of the product itself and its properties (vendor). Right next to the SKU, you can store the price.
That is, the price will combine goods (Items), store (stores), product properties (?). Get the price in a specific store - 1 join. Get all the prices of one item - a simple index query.
Post your MWB project to make it easier.

Answer 5

How is the price calculated?

Answer 6

Hello.
I must say right away that I have little experience in this, but the task is interesting, so I will follow this thread and just give a couple of thoughts.
It seems to me that all the same, the main unit you should have is a product, not a price. And the price should be for the type of product.

Answer 7

If you need price history by dates, then perhaps add the date to the primary key (or unique) in the price table. and if you need the SKU of each product, then instead of item_id in prices you can use SKU, which in turn will refer to the desired item_id

Answer 8

Do you need the network parameter for something specifically?
If not, then you can imagine everything as points of sale, each point of sale has an address, contacts, and, well, its own legal entity. person owner. And the price is just a showcase, which is different for each point of sale. But only if you have unrelated points of sale (each store has its own 1C business with the nomenclature, and the nomenclature IDs between the stores do not overlap), then each nomenclature should have its own. and more milk at point of sale 1 <> milk at point of sale 2 because the expiration date is different or the manufacturer, etc.

Answer 9

You can go from the Price Types establishment. There is a commodity item - Milk (it is also in Africa - Milk), there are "options" of Milk, in this case: "Producer", "Percentage of fat", etc.
We start "Price type" - "Basic". which can simply be calculated from the purchase price. Next, we start other types of prices (Points, Networks, Branches, "Prices for a store in Bobruisk", etc.) An important characteristic of the Price Type is the calculation rule - dynamic or based on a different price + a fixed percentage (or any other algorithm) - the essence calculation rules - assign/calculate a price based on incoming data, such as: Product, its options, network point, etc.
Each product has its own price type, depending on the options and / or networks - for the product (and with options - this is already a SKU) a certain / own type of price is assigned for its calculation.
It's short)
PS I think it's important to have a common NSI for the entire IT field. And even if each store has its own database and "its own item id" - you need to introduce a common attribute to synchronize them. This applies to "price types" and "price calculation rules" as well.