Hello just after some updates. When we select any item to create a sales quote its now not taking initial quantity as 1 the quantity column is empty. Which is causing quite effort and errors as usually items are in 1 quantity and now we have to carefully select 1. On the contrary sales invoices are just fine and are giving the base quantity 1. Can it be resolved with sales quote please
Make sure your software is fully up to date. There were recent changes in this area. But a blank quantity is interpreted as 1. So you don’t need to enter it. Just enter the unit price.
The stock is not being subtracted by this new update if there is no quantity mentioned in the quantity column @lubos can previous default quantity of 1 be restored as now we have to manually add in every line
Inventory quantities have never been affected by sales quotes. They have no impact anywhere in the system.
That is obvious. But when sales quotes are copied to sales invoices its not loading the quantity 1 automatically. Its empty there. Of course we are manager from a long time we know that sales quote has no impact on quantity. We are trying to address this issue being caused in further transactions like sales invoice when copied from sales quote. Can you please fix the issue?
You are mixing behaviors. But you need to understand that Manager accounts for financial and quantitative aspects of transactions separately.
The first behavior concerns how Manager treats blank quantities. If the quantity is blank, Manager will interpret that as 1 for purposes of determining the amount on a line item from the unit price. You are correct that it does not carry anything forward when copying. This is consistent throughout the program. Suppose you were quoting services instead of an inventory item. You would probably not want a quantity of 1 to be carried forward. But if the quantity is 1, it will definitely carry forward, just as you would expect. Only if a quantity is shown will inventory quantities be adjusted (when the transaction type is appropriate for that).
The second behavior concerns default quantities on the various transaction types. You have noticed that sales invoices behave differently from sales quotes. For that matter, so do credit notes, purchase invoices, and debit notes. And purchase quotes and orders behave like their sales counterparts. All of the first group will default to a quantity of 1 when an inventory or non-inventory item is selected. That is because lines with items on such transactions virtually always involve movement of quantities as well as money. But if you enter some other type of good or service that is not defined as an item, the default quantity is blank.
There is logic to both aspects of behavior. You may not see it with your particular workflow. But it is not random. So there is nothing to be fixed.
Your explanation following that statement is illogical when it comes to inventory & non-inventory.
Group 1 - Sale / Purchase Invoices & Credit / Debit Notes.
Upon entering an inventory item or non-inventory item the quantity will default to 1.
Group 2 - Sales /Purchases Quotes / Orders.
Upon entering an inventory item or non-inventory item the quantity will NOT default to 1.
Therefore, if Manager is going to be consistent throughout the programme, then whenever the 
field appears on a transaction type and is selected then the quantity should always default to 1.
To say that this field on one transaction form does get a default quantity, while this exact same field on another transaction form doesn’t get a default quantity, when entering inventory or non-inventory items, is illogical.
As @fahadalarab has highlighted, this failure to have the default quantity occurring on group 2 forms is causing issues when coping to group 1 forms - whereas the issue should never be occurring if Manager followed its own programme constancy mantra.
Also, as @fahadalarab has highlighted, (being a long time user) that this issue has only arisen after recent updates. So this appears to be another instance of Manager removing basic programme functionality for what purpose - user workflow frustration.
Just to be clear, this issue has nothing to do with good or services not defined as items, nor is it to do with inventory or financial impacts.
1 Like
My statement, “There is logic to both aspects of behavior,” was not directed to inventory and non-inventory items on what you have described as Group 1 and Group 2 transaction types. The aspects of behavior I was discussing were:
- Treatment of blank quantities when copying one transaction type to another, and
- Default quantities of the various transaction types. (All your discussion of Groups 1 and 2 falls under this aspect.)
The point I had already made about the second aspect of behavior was that selection of an inventory or non-inventory item for Group 1 transactions almost always means a quantity is being moved. On the other hand, selection of the same inventory or non-inventory item for a Group 2 transaction never involves movement of a quantity. That was the only logic I was referring to concerning default quantities.
I agree the logic is not obvious. But it is there, and not random, which is why I did not consider it a bug. I also agree the default quantity behavior is inconsistent with the rest of the program. Personally, I would prefer the consistent behavior you advocate.
Yes exactly.
The previous logic and default quantity 1 was better.
And we used them for both, inventory and services.
When manually quantity 1 was removed from all items /services the quantity column used to be disappeared from the quote or invoice, which was a better representation of services quotes.
If we can have that default quantity back to 1. It would make copying quotes to invoices would be great.
Or i have a better idea i think, we can use sales quote or sales order for products and services respectively or vice versa. Like one would have default quantity 1 and other doenst have it. But not sure if it is right to implement in manager
@Tut, did you read and understand these points made in my post:
This topic has nothing to do with “There is logic to both aspects of behaviour” and all your unrelated distracting red herring discussion.
This topic is all about and I repeat “another instance of Manager removing basic programme functionality for what purpose”.
This arbitrary removal of previously basic programme functionality seems to becoming an increasing theme of Manager’s un-development.
Yes, @Brucanna, I read everything you wrote. That is how I knew you had misunderstood me. In fact, if you want to complain about red herrings, it was you who hijacked the topic by diverting it into a rant about disappearing features.
Meanwhile, did you notice I agreed with what you said that was on topic?
SORRY, but how can comments which address the core of the topic be considered a rant.
And if you are uncertain about that, then please re-read the topic’s originator’s response to my post.
@fahadalarab the latest version version (21.3.60) will make quantity 1 as default for inventory items and inventory kits. Not for non-inventory items.
1 Like
I don’t understand the logic of having 1 as default for inventory items and inventory kits, but not for non inventory items. I buy and sell non inventory items where most often the quantity will be 1. The difference between non inventory and inventory is purely down to the fact that I am either buying something or selling something in non inventory, but never both. Other than that, nothing else is different. So to me it would make sense to have quantity of 1 for the non inventory to keep everything consistent.
1 Like
That may be your practice, but not everyone’s. Many non-inventory items can be both bought and sold, especially when they are services obtained from a subcontractor. But the same can be true for goods, such as when they are only purchased when required for completion of a job and are never stocked or held for later sale. In those circumstances, there is no reason to take on full inventory management functions.
I think the point is that non-inventory items never have a quantity aspect beyond the simple multiplication by unit price. That is, nothing to deliver or receive, no average costs to calculate, and so on.
My point is that the difference between non inventory and inventory is more in how I use it. Naturally other people use it differently.
Regardless, the non inventory should have a quantity of 1 as default similar to inventory as the concept is the same even if the use is different. Otherwise this will cause problems copying quotes to invoices etc if 1 is not set to default.
@dalacor, the discussion in this and another related thread have, I think, been somewhat difficult to follow due to interspersing of various issues. But if I understand your concern, I don’t think you will have any problems.
After some back and forth, the program is once again interpreting blank quantities as 1’s. And they copy to other transaction types as blanks and are interpreted there as 1’s also. The concern that was being addressed was whether blank quantities should be interpreted as zeros, which caused problems with recurring payslips.
Currently, you can issue a sales quote with blank quantities but a unit price. If the customer opts to buy multiple units, you can copy the quote to a sales invoice and edit the quantity upwards. But if they buy just 1, you won’t have to do anything.
If you have a different concern, can you please elaborate?
I know that but since the original issue is resolved there’s no harm in digressing.
Back to what @dalacor was saying
This doesn’t make any sense, 0 valued transactions are extremely useful in many many ways. But, zero valued lines? I can think of one situation where that is handy and that is: Voided transactions. And you never ever want to create a voided transaction, you either create a valid transaction or void an already existing transaction because you cannot simply delete it.
The whole idea of leaving Qty blank is to skip a trivial step of having to mention 1 as a quantity (and hence 1 became the default). But defaulting the line to 1 means entering a new VOID line which doesn’t make any sense.
Why would anyone want to create something that’s completely useless?
You lost me, @Ealfardan. Are you saying @dalacor’s comment makes no sense, or that defaulting to a quantity of 1 makes no sense, or that interpreting blank quantities as 1 makes no sense?
I fell further behind when you moved on to voided transactions. I can’t tell whether you are supporting or condemning them. (I guess condemning.) And I am completely in the dark on what you mean when you say “defaulting the line to 1 means entering a new VOID line.” Are you referring to spontaneous changes to prior transactions, or behavior of the program for new transactions?
Please enlighten me.
I think in the future, I’ll make it a preference so users can decide defaults themselves based on what they are actually using non-inventory items for.
Non-inventory items can represent services where price is fixed and not quantity-based. In that case you’d leave quantity field empty.
For inventory items, you almost never leave quantity field empty. There are exceptions… for example, when capitalizing some expenses to inventory to hand. In which case you want to increase the value of inventory without actually increasing quantity.