My team can not finish can't finish 1 product backlog in one sprint

Scrum requires at least one Done useful and valuable product Increment by the end of the Sprint, and that's really important.

I'm wondering, does your Product Owner understand that not every Increment needs to be released to customers by the end of a Sprint?

To provide value the Increment needs to be usable. Would there be opportunity to gain empirical feedback from stakeholders at the Sprint Review based on splitting the Product Backlog items as you describe? Would some risks be mitigated to each Sprint? Would your approach help the team validate assumptions? 

Considering the current situation of not having any way of inspecting progress towards the Product Goal and the latest Increment, your suggested approach seems reasonable.

Product increment is large and PO doesn't want to slice it as no business value will be added 

Is he prepared to take the leap-of-faith that entails? What if it turns out that's not what is actually needed, and the value isn't there?

Each Sprint is a learning opportunity through which our assumptions are empirically validated  It sounds like the PO is lining himself and the team up for a series of missed opportunities in which product risk could have been better controlled.

Hi Sara, I feel your pain, in my experience this happens a lot when the PO is actually an SME and perhaps doesn't appreciate the value of getting feedback on something that isn't polished. Generally SMEs start with a fairly perfectionist standpoint as they are involved in the customer domain and may even have a reputation there. 

The best way I've explained is drawing out the difference between release planning and sprint planning. They might think they have a fairly precise idea of what a release looks like but do they really want to go underground for months before validating with the end customer. The PO has to develop a trust in the team and the scrum process and question whether what they want is actually what they needs. 

Certainly a tough one but view it as a hump in the road, you're inevitably need a ton of conversations at the start but its worth addressing these concerns early. 

functionality  to view the past order( view orders list, search by date ,filter by order id and clicking on the order to display order details, ) 

Hi sara,  I see this way --  Is this sufficient to show the order list alone and not give the users to sort it or filter it or not giving detailed view of the order?

As a end customer, I feel sharing the order list alone is not sufficient. It is not finished solution. 

I go with PO on this. 

My view....

An increment needs to be valuable to the stakeholders.  However, the end user is not the only stakeholder.  In some cases the Scrum Team itself is a stakeholder.  So providing a valuable useful increment does not mean a customer releasable increment. 

In the case you suggested, it is very likely the Developers are going to build the feature in the way you described.  I have been in almost the exact position before with order systems.  On multiple occasions the Developers built the listing first.  We showed it to the stakeholders and got some valuable feedback.  Feedback such as the order of the columns did not present the most important data first, the wording of the field headings was misleading, some fields were not needed in the listing but were needed if looking at the details.  Some of this helped us simplify the solutions and save time/money.  We also got some feedback such as that the feature would be mostly used on mobile devices and that the formatting of the data needed to take that into account.  That actually meant extra work but it was better to learn that at the beginning than waiting for the end. 

The iterative approach of agile delivery doesn't always mean that stakeholders get the entire solution at once.  But it does help to ensure that when the full solution is delivered, it will be a solution that the stakeholders will be able to use immediately.