[Feature] [ERPNext v13] New Point of Sale Beta Testing

Code have used da%19, it would filter all da with 19.

Rightly said.

I hope this doesn’t happen.

I would like to know what is the current scope of the pos and what were the initiate objectives set by the core team, also how much time, resource and finance was budgeted for pos.

As I see only @nextchamp.saqib is replying to this discussion, I request someone from the senior management to clear things out, so if there is a need for community finance or resources then we all can contribute.

I am looking for clear information from the senior management.

Hi, thnx for the % trick…used in filters but never realized i could use it in the POS search field thnx

Just what my team had suggested. I should have broken it up into two parts. I have learned from this though.:sweat_smile:

I just discussed this yesterday. I plan to but I’ll only work on this after all the deal breaking problem gets solved. I am keeping this as one of the last change since it would require a lot of moving around and configuring code. I am considering to implement this as an update rather than having it from the get go.

This was also suggested by my team, specifically allowing user to choose whether an intermediate invoice gets generated on each transaction or the normal sales invoice.
However I’ll make sure the end of the day consolidation method won’t have the stock inventory issue I mean user will definitely be able to see how much stock is left from the POS screen.

@felix Thanks a lot.:smiley:

1 Like

I’ll put up a to-do list of all the fixables which I’ll be working upon.

Returns against a credit note is a major problem since it hasn’t been implemented in ERPNext itself. Forget POS, doing the same in ERPNext needs the user to reconcile the invoice with other invoice through payment reconciliation or journal entry.

Please provide me some of the scenarios of returns. Do we give refund the money? Is it ever refunded in cash? Are invoices for return and replacement the same? Can we make 2 transactions one for return and another for replacement?

You have the case where the customer, only wants to return some items of the invoice or the whole purchase.

Whatever the case is, It will always depends on business politics:

  1. Some business return the money; cash or CC.

  2. Some other return the money as a positive balance for the customer in the system, (maybe could be related to loyalty where we translate the credit amount into the amount of points required to make that purchase again).

  3. Some other give you a Credit note based on the previous purchase.

Some thoughts I am very happy to see you interacting with us all, I come here like watching a TV series, very exciting of the new changes!

@nextchamp.saqib do not be overwhelmed, even the top tier PoS systems that cost thousands of dollars PER STORE still have some holes in their functionality.

With respect to returns let me also add my two cents, the following are the three main return scenario

  1. Return for cash…not too common but definitely happens
  2. Return in exchange for another item. This is the most common scenario. Customer may have to add more money if the new item costs more or be refunded in cash or credit if the new item costs less
  3. Return for store credit in which case the customer returns the item and is giving store credit with which she can make purchases at a later date.

The scenario to be adopted in any case is policy based. So I will strongly suggest that this is controlled from the PoS profile page.

And now let me complicate things a bit more on returns. Most stores have a return policy where you must return within a particular number of days. It would be nice if this could also be inculcated.



What are we supposed to do with the end of day closing figures? It shows up as opening balance the next time the cashier opens a new PoS session.

In real life we are supposed to evacuate the cash to the bank and the credit cards should not show up anyway.

Is there a step post PoS closing am missing ?


Ok. I’ll remove this behaviour. So basically at every pos opening user will have to manually enter opening balances right?

If I want to keep it simple I will say yes.

In reality there is something called a “cash drop” in retail.

A cash drop is an amount of cash removed from the cash drawer and placed in the safe or sent to the bank for deposit. … Typically, cash drops are performed to remove excess money from the drawer to be placed in the safe until the balance can be reconciled.

The supervisor can come in periodically and evacuate cash from the cashier’s box and they jointly post a cash drop that moves the cash from the cashiers cash account to a back office cash account.

At the end of the day the final cash drop is done and whatever is left behind (change?) will represent the opening cash position for the next day.

So the behavior now is ok, we just need a “cash drop” document/concept to move the cash out

These are well defines.

Not to forget that in a VAT scenarios, An original invoice number is mandatory on the return invoice, this makes pos return a bit complicated.
In any country which have VAT/Tax needs the original invoice number mentioned on the returned invoice, which is already part of the ERPnext Sales Invoice form but getting it in pos will be tricky.

Idk how we can handle the concept of exchange, means in the return invoice 1 item is returned while another item is purchased. AFAIK ERPnext sales invoice cannot handle positive and negative qty in the same invoice. So you might have to find a way, currently we ask the users to make a return invoice and then make another sales invoice for the newly purchased item.

Yes good point, We have cash transfer document in one of our other software which takes care of this, also good to have it.

I would propose credit card commission percentage to be defined on every CC MOP which can be used during the day closing and make a GL Entry accordingly instead of the accountant doing a manual transaction for this.
Case where Card company charges 2% per transaction.
Total Card sale for the day = $500
So GL Entry should be

  • Bank Dr. 490
  • Commission on Card Dr. 10
  • Card MOP acc Cr. 500

This is a use case in non VAT/TAX scenario,
While the Tax use case would be

  • Bank Dr. 489.5
  • Commission on Card Dr. 10
  • VAT 5% Dr. 0.5
  • Card MOP Cr. 500

We had this planned for future customization on day closing. BTW this is a standard feature we have seen in most of the POS apps even our small scale pos software has this.

I am not asking too much though I know these are not so important but it is a standard feature, so just putting it out here if you want to add it from the beginning.

@nextchamp.saqib Do you have any new plan on the layout or do you plan to continue with the existing layout of the POS?

I will recommend that your team continues with its design, there is nothing wrong with having two PoS options. Your concept is perfect for a fast pace supermarket environment

Just my thoughts

1 Like

Currently we have paused the work on POS design as we don’t know the future of our apps yet, not sure if we should port it to v12 or not as we have done a lot of changes to the pos in terms of Vat and other small small changes.

Also we had proposed to work with the core team on this but I never got a single reply from the team, which makes me think that they’re not interested.

We might just add few shortcut buttons on the pos for now and use it as it is on V11.

Shortcut button

  • Open Drawer - We planned to just print a break page on a paper for the drawer to open as we cannot have anyway to directly pass the command to the printer without adding alot of codes, like done in case of raw printing.

This button is a must in some retail environment as the client don’t want to give drawer keys to the cashier at all. Which means drawer will only be opened during printing the bill or manually opened using the button mentioned above which is audited with a daily record which in return helps in catching fraud.
Another important but underrated feature of POS. We have heard unbelievable examples of frauds happening in retails which we cannot even think of while developing a pos app until we sit down with the management or the supervisor of a shop floor.

After reading about Event streaming, I think our plan of making a progressive POS webapp with its own db which would sync invoices to the ERPnext was a better solution than event stream in term of the overhead, event streaming bring with it. I understand that it is a robust solution but it has its overhead of having a location server and in a current scenario where everyone is trying to reduce overhead cost and its maintenance pitching someone event streaming will not be easy. Whereas using a webapp would eliminate the need of a local server.

Taking a simple use case of a client having 12 outlets
we will need 1 master server on the cloud, while 12 local server just to maintain event streaming.
We have been pitching clients to use cloud servers to reduce cost but here I see we’re just increasing the cost of the server hardware as well as the maintenance, This solution will only be accepted by companies who are currently using high end ERP like Microsoft dynamic, Sap, Oracle etc.

Should be posting this on Event Streaming post :smiley: but its is related to POS also.

I think we should take this to the event streaming conversation so as not to derail this topic.

I disagree with you totally on the server and outlet issue, but let us have this conversation on the other side

:white_check_mark: Ability to click on a product to increase the cart qty
:white_check_mark: Once a barcode is scanned and identified, it should be added into the cart automatically. Item will be added on clicking ‘enter’ if only a single item is found for the search. Maybe I’ll give a toggle in POS profile for ‘enter’ button being required or not.
:white_check_mark: System should not allow a batch item to be sold without choosing a batch number
:white_check_mark: ld not allow sale of item qty beyond the available batch qty in the warehouse.
:white_check_mark: on negative qty before submitting a return entry
:green_square: Ability to use credit note or customer available balance as a mode of payment
:green_square: Add item available qty to each item in the item list
:white_check_mark: item name/qty/rate/amount columns in cart
:green_square: Ability to give global discount
:white_check_mark: At checkout page, once a cashier clicks on a payment method, the payment balance should always be displayed.
:white_check_mark: Search field autofocus on barcode scan
:green_square: Shortcuts


Sale Person must be added to system , for POS

comission calculation is an important part of retail POS

Error Message when trying to access beta PoS



Well done @nextchamp.saqib

I have two observations based on the completed tasks above

  1. Task No 10,

See below Gif that explains what is really needed, if total amount to be paid is 600, and the customer wants to pay 500 in cash and the balance in credit card, once the 500 is keyed in cash, the balance of 100 should show up in the next payment option chosen and so on. This is the behaviour in the current PoS system and should be replicated in this new one


  1. I noticed that you can see the on hand qty of a product once you click on the product in the shopping cart. I also noticed that you can click to see a list of existing warehouses. I was hoping that if you change the warehouse the qty figure will change to show the qty in the new warehouse. This will be nice to enable cashiers see availability across locations. But the qty does not change regardless of which warehouse is chosen. It will be nice if this can be fixed


Once again good job

In Pakistan at major retail stores it is really required that one should be able to add sale person , Secondly the major thing we see here is multiple POS with single cashier, like a person goes to one counter and buys something , then next counter and buys something more and tells the old bill number he has the user adds more products to same bill and then payment is made on the last, I can help adding this feature to system.