The query that you tried seems to show that you have the intuition that group by will help you, but misuse it in the details.

Grouping will effectively help you to generate one output rows from multiple rows fetched from the joins.

Before grouping you should ask yourself what reality each row represents, and what columns are duplicates regarding your problem: they are the ones you will group on.

For example, with the following data (intermediate results of an hypothetical join on the database of an hypothetical clothes seller):

You can choose to group by against two different axes, depending on what you're interested in:

• if you want to have an history per customer, you will only group by the columns representing the customer (customer_id, first_name, last_name).
  You cannot only group by first and last name, because, as you can see customers 1 and 3 are homonyms.
  In fact, customer_id being your primary key, you would avoid a lot of problems if you only worked with customer_id for the 1..n relation (1 customer has multiple orders), group by on it, then only enrich your data for display with the customer's names:
  • you'd avoid typing (adding all 3 columns to the GROUP BY, because all those 3 columns represent the physical reality of a unique customer)
  • you'd give less work to your database (it has to internally fetch first and last name as many times as they are orders, then compare them to make sure that, in the end, they can be merged)
  • and later you'd avoid possible errors if your query uses multiple 1..n joins.
    For example if you want to display each customer with its count of orders and count of cash withdrawals at an ATM, and our customer did 2 withdrawals to pay for its 3 orders, a customer join orders join withdrawals would return 6 rows, one for each combination of withdrawal and order, so you would apparently end up with 2 trousers.
    So in general try to work each 1..n relation by each 1..n relation, particularly when they represent orthogonal realities (withdrawals are not related to orders: one withdrawal could have been used to get money to buy the trousers and bread at the bakery, or there can be no withdrawal if everything is paid by credit card, etc.).
    Having one dedicated sub-select per group by may be a strategy to think of, to reduce your relations to 1..1 (each customer that has n orders, has only 1 count of orders) and then do your grand-join for final display.\ This is a general warning that I thought of while seing the number of joins you have, with PedidoRecarga which role is unclear to me.
• if you want to make your stock inventory, you won't group by customer (you don't mind who bought it), but instead you'll group by what and only that because this is what represents a distinct product. The quantity does not distinguish one product from another, they are an attribute of the order, not of the product, and it doesn't make the product nor the order unique: as you see two orders can have the same quantity, exactly as two customers can have the same name, but it doesn't make them the same "entity" in reality. So if you group by quantity too, your 2 orders (customer bought 1 sock, then remembered that by chance he had got two feet, and came back to the shop and bought the other sock) will appear as 1, and your inventory will tell that you've sold only 1 sock while in fact you've sold 1 + 1.
  So group by only on what uniquely defines the reality you want to represent (such as a primary key).
  Other columns should be aggregated (here: in a sum(), because you sold 1 + 1 sock to customer 1).
  And here in the case of an inventory you'll want to group by only on what, which is the PK of each product, not on quantity which is an attribute of the order but not even on order_id which is the PK of the order, not the product, and would only be useful for a per-order listing.

The problem I see in your query is that you group by (nearly) every field you encounter so probably you first have to question yourself about what reality do I want a unique row for in my end result?