Besides the SQL Server, SAP is the most used data source in Peakboard applications. We already have many SAP articles on this blog. In this article, we’ll list the 10 most common use cases for the SAP data source, and give a quick rundown on how to build them. Of course, the examples in this list may not fit your particular need. But in most cases, they are a good starting point or inspiration for building personalized applications.
1. Outbound delivery monitor
Monitoring outbound deliveries is a very common and an easy use case for Peakboard. It downloads all active deliveries and their items, and aggregates them by shipping point, warehouse number, or storage location. This is a typical way of answering the question, “Where are we and where are we supposed to be?” For an example of this use case, see the Area coordination in the warehouse template.
There are a couple different ways to build the technical backend:
- You can download the LIKP and LIPS tables directly by using the table select XQL command in Peakboard.
- You can create a Z function module and have the SAP side handle the data join, aggregation, and selection. This is a more sophisticated approach. See How to build a perfect RFC function module to use in Peakboard to learn more.
- You can create an SAP Query in the SQ01 transaction to select the delivery information. See How to have fun with SAP Queries to learn more.
2. Workplace capacity and status monitor
The most common use case for an SAP production environment is to determine and display the capacity and utilization of one or more workplaces. Unfortunately, there isn’t a standard BAPI to determine workplace capacity. However, there’s a function module for internal usage. So the easiest way to determine workplace capacity is to wrap the internal module in an RFC-enabled function module. See How to determine workplace capacity to learn more.
The utilization is very tricky to determine correctly. As an SAP user, you would use COOIS transactions to list all the production orders for a certain workplace in a certain time frame. See How to get the next work orders of a workplace to learn more. Once you have all the necessary operations and the overall capacity, it’s easy to calculate the utilization.
3. Production order confirmation
Confirming production orders doesn’t necessarily mean finishing them. It’s also important to give a regular update on the progress of the order—in terms of employee time and machine time usage, and also the current number of goods produced (normally, the number of goods, scrap, and yield).
SAP has a nice standard function module called BAPI_PRODORDCONF_GET_TT_PROP that does all sorts of confirmation activities. The actual confirmation can be done by a real person or automatically by the machine. See Build a Production Order Confirmation Terminal with no code to learn more.
It might be a good idea to store the confirmation in a database or Peakboard Hub before submitting it to SAP. This makes the system more resilient against SAP outages or other IT problems, so that production doesn’t come to halt if a confirmation can’t be processed right away.
4. Transfer order monitor
Transfer orders are objects in SAP’s Logistics Execution (LE) or Warehouse Management (WM) module. The corresponding transaction is LT03 for creation.
The data around transfer orders is often displayed at workstations for automatic material handling systems or automatic high-rack installations. We often see that the machine or sensor data is mashed up with the transfer orders. The same is true for the usage of barcode scanners. Both are possible—not just for displaying the order, but also for handling dynamic interactions by the user.
To display the order, we can use the standard function BAPI_WHSE_TO_GET_LIST to query the keys and then BAPI_WHSE_TO_GET_DETAIL to get the details. If it’s too annoying to split it into so many calls (because of many orders being in the list overview), it makes sense to build a Z function and read the tables LTBK (headers) and LTBP (items) directly, and return a single table to Peakboard. This situation is quite similar to the outbound delivery use case listed under number 1.
5. Quality notes
Quality notes are generated in many situations. For Peakboard apps, there are three common use cases:
- Defect reporting 1: The produced good shows defects in the production process. The defects can’t be handled during the process, or it will bring the process to a standstill. This can happen during production or during the quality inspection step.
- Defect reporting 2: The material that is used for the production shows defects that were undiscovered up until now. Usually, all the material must be locked immediately to prevent other production units from using it, and additional steps must be taken.
- Health, safety, and environmental incidents reporting: Incidents that affect health, safety, or the environment, potentially due to quality issues in processes or materials. This includes workplace accidents related to equipment or hazardous materials.
When building the Peakboard app, it’s usually not necessary to do any ABAP development, because the standard BAPIs, BAPI_QUALNOT_CREATE, BAPI_QUALNOT_SAVE and BAPI_QUALNOT_CHANGE, can submit the notes to SAP.
6. Packing a delivery
In a typical outbound delivery process, the delivery is packed after collecting the goods. In SAP standard, the transactions VL01 and VL02N are used. Depending on the use case, it might be necessary to submit additional information to SAP. For example, the size of the packaging material used.
One of the most common BAPIs used here is BAPI_OUTB_DELIVERY_CHANGE, together with BAPI_HU_CREATE and BAPI_HU_PACK. We also see a lot of custom function modules because usually this process is done in an customized way.
In an even more sophisticated use case, we can add a camera to the Peakboard application. The camera can double-check the goods packed or systematically take and store a photo of the goods within the package, in order to document the contents and how it’s packed.
7. Technical drawings and other documents
Peakboard is usually focused on giving the user a dashboard to see and interact with. So the main goal of Peakboard apps is to bring all the necessary information to the user. In most cases, this is structured data. However, there are a couple of use cases where documents are used—typically, technical drawings or documents containing additional instructions on certain processes.
There are two common situations:
- Assembly instructions for users who do some kind of assembly.
- Quality checking instructions for users who carry out quality checks.
The documents are handled in SAP through the CV0XX transaction (document info record). The document info record usually points to the original source of the document, but this depends on the underlying document management system (DMS).
Most commonly, this is just an HTTP endpoint that can be used directly in Peakboard, similiar to downloading a document from Sharepoint. We discuss this pattern in How to use a document library to store technical drawings.
8. Loading bay monitor
In the process of dispatching outbound delivery packages, pallets are often loaded onto trucks through different loading bays, depending on the transport carrier. This can be a source of very annoying problems if done incorrectly.
There is a simple version of a loading bay monitor that just shows the destination region, carrier, and whatever else helps the handling agent check that their package fits onto the truck behind the loading bay (see Your dashboard for truck loading).
The more sophisticated version uses additional hardware connected to the Peakboard app to actively cross-check the process. For example, a barcode scanner or RFID reader. The Peakboard app can then directly check and confirm with SAP that the outbound delivery is loaded onto the truck.
9. Inventory
The Peakboard app is usually used on a mobile device and is replacing the printed inventory list. The most common way to do this is to use standardized BAPIs like BAPI_MATPHYSINV_GETITEMS and BAPI_MATPHYSINV_CHANGECOUNT. The whole process is usually managed though the MI0X transactions and can be done completely or in part by the Peakboard application.
10. Collect machine data from OPC UA and PLCs
Machine data is collected and submitted to SAP (mostly to SAP MES or SAP PP, but not limited to that). On the Peakboard side, there are typical machine interfaces like OPC UA and native connctions to the PLC (Siemens, Beckhof, Rockwell, etc.).
Typical values are machine status (usage time, fault codes), cycle time, and of course, good and reject count. Depending on the data and usage, it might make sense to submit it directly in real time, or it might make more sense to store it first in a local database of Peakboard Hub and submit it asynchronously. Because this process is highly customizable, it’s usually done through individual Z function modules on the SAP side.
