Homemade SAP B1 Web Client – Update 1

Sales orders management and a web relationship map

Introduction

Soo… Last week, I started developping a SAP Business One web client using javascript technologies, it was all fun and games until it started to really catch my attention 🤔. So here I am, week two, adding new features to my application.

For those of you who just stumbled into this article, you can as well read the first article which explains the origins of this project.

Before we dig into this, here is a demo of what we will talk about.

Spoiler alert: this update is focused on Sales Orders. This will be way shorter than the first article as I will simply talk about small features I added and what I’m planning next.

Web relationship map

One of the thing I use the most in SAP B1 is the relationship map as it helps getting a quick view of the relations one document may have with its predecessors/successors.

SAP B1 Relationship map for Sales Order 327

Business One is pretty basic in its document process, both sales and purchases are similar, so once you understand that, a quick look at the graph can save you a lot of time to understand the relations between several documents.

When I started building the Sales Orders module, I knew I’d wanted this feature in it. Luckily for me, SapUI5 offers controls that made it possible and I was surprised to see that it was way easier to transpose than I thought.

Below is a screenshot of the same relationship map in the web client. I wanted to keep all the small visual indications you get with the fat-client relationship map, this includes:

  • Document status (Green = closed, blue = opened)
  • Document Number
  • Document Date
  • Document Total

I also added a notion of groups (one group per document type) to gather documents of the same kind.

B1 Web Client Relationship map for Sales Order 327

If you like to see it in action, you can check near the end of the video (at the beginning of this article).

Searching orders

I implemented two ways of searching orders. A simple and easy search bar that will look into the basic header information of the orders (for the moment, DocNum, CardCode and CardName)…

Quick search

… And a more advanced one where user can target specific fields. User can, for instance, look for one (or many) items, one (or many) business partners, filter by dates and document status. I plan on adding more filtering capabilities but this is a starting point for future work. 

Side note: SapUI5 has a great component for filtering data but relies on OData which also provides metadata information of the returned fields. The Smart Filter Bar analyzes the metadata and builds the UI accordingly. You can read more about Smart Filter Bar here.

If you read about my previous article, this control is an example of what you have in SapUI5 but not in OpenUI5 😉

The reason why I haven’t used it is because my API is not an OData Api but a simple json REST API

Displaying Orders

Orders are displayed in a UI5 Responsive Table, using several color and icon indications:

  • A blue ribbon indicates an open order which isn’t due yet
  • A red ribbon indicates an open and due order (also noticeable with the sandglass icon)
  • No ribbon indicates that the order is closed (also noticeable with the lock icon)

Technically, the orders are retrieved directly from an SQL connection and not from the Service Layer as it was previously done, leaving the Service Layer used « only » for Creation, Update and Deletion purpose.

An updated application hierarchy would be the following:

An up-to-date hierarchy with the SQL connection between the API and the SQL Server

Orders are fetched by chunk as user scrolls down in the page.

Next week

You may have noticed that I didn’t put any details when it comes to actually adding a new sales order in the system. I plan on working on that for next week.

One particularity with B1 is that it shares a same model across all the marketing documents. Technically, this means that the SQL tables behind sales orders share a same structure with the tables behind the purchase orders and the sales invoices etc…

This makes it pretty easy to develop tools that need to handle several (or all) kind of documents. Wait, isn’t it what we’re trying to build here? 😚

The way I see it, once the Sales Order module is stable, adapting it to the other documents shouldn’t be too big of a deal 😉 But that will probably be the topic of another article.

That’s all for today, small update, but paving the way for bigger changes! ✌🏼

Retour en haut