April 27, 2018 at 18:19Two-tier ERP and SAP Business One: how it works
- Tutorial
Hello!
This time we decided to return to the topic of ERP-systems. In the SAP product line, there are different products for companies of various sizes - from multinational corporations to medium and small businesses. There are also combinations - when companies use several types of ERP at once, for headquarters and for branches. Such cases are called two-level ERPs, and SAP Business One is excellent as a “lightweight” system. In this article we will talk about the details and integration details.
But first, let's answer the question - what is a two-level ERP?
The term "two-level ERP" has become familiar to many. The concept of a two-level ERP system is used in corporations that need a common standard of reporting and business applications in their subsidiaries or branches. In small business units, for many reasons, it is simply not practical to use large ERPs: other business processes, the difficulty of adapting employees, and the slow deployment speed, which can take months. And if you add here more time for staff training, the costs of maintaining the system and with all this you need to implement a “big” solution in 40 branches at once, it will take a lot of time (often even months) and require significant costs. For comparison, “small” solutions can be implemented in a few weeks.
Two-level ERP is applicable today not only for large corporations, with their relations “headquarters => branch”. This strategy is viable when working with suppliers, distributors, dealers and service organizations.
An example of our European client is Heineken Spain. They had a task - how to establish data exchange between 600 distributors and Heineken Spain on orders, goods movement and invoices for payment and then automate all processes. As a result, the company decided to develop a solution based on SAP Business One.
Heinekein Spain came up with a scenario using the Internet of things - they collect data from more than 300 thousand sensors that are built into beer taps. The company receives information on beer consumption from a single information system. As a result, Heineken realized how to better manage the sales channel, optimize the sales chain and improve performance. They also began to receive data on beer consumption in real time, one might say, "from every tap."
With two-level ERP-systems, not everything is perfect. Let's see what problems can arise when integrating different systems.
Why even introduce ERP systems in branches or subsidiaries? In large holdings or large companies, of course, they want to receive transparent analytics or reporting on business processes. Moreover, this problem often happens - in each branch they put their own solution convenient for local specialists, and as a result, a “zoo” of systems and services appears in the company. And of course, they may not be compatible with the parent ERP for a variety of reasons - for example, due to the use of solutions with closed APIs. In this case, one cannot hope for a single reporting, or for any automation of business processes.
What does SAP have? We have a whole line of ERP systems for different tasks and goals. For companies with complex business processes, “heavyweights” are needed - here they choose S / 4HANA, ECC or R / 3. For businesses, SAP Business One is simpler or smaller. At the same time, B1 can easily be integrated with large SAP solutions - S / 4HANA, Hybris, Ariba, Customer Checkout, Concur, mobile applications and even government services.
What are the opportunities in SAP Business One for the development of integration services:
Features, target audience and scope are given in the table:
Further in the article we will talk in detail about the Integration Framework.
Integration framework
The SAP Business One Integration Framework (B1iF) is available in the SAP Business One ERP system starting from version 8.8. It can be installed on the SAP HANA or MS SQL database. The main task of B1iF is to send and receive data from external (SAP and non-SAP) systems. Integration script packages are built within the Integration Framework. The scripting logic is based on business processes: error management, conflicts, transactions (and their order of execution), execution guarantee, monitoring, debugging and administration are performed in B1iF.
To develop a scenario for integrating the two systems, programming skills are not required.
The process sequence is set using the built-in graphic designer in the platform. B1iF BizFlow Atoms built-in functional units are used for value mapping, call setup (SAP Business One, SAP ERP, HTTP, SQL, file systems, etc.), XSLT conversions. Data mapping is performed using XSLT transformations in the built-in (or external) XML editor. Debugging tools allow you to develop an individual process sequence in a structured and visual form.
The integration scripts that run on the integration platform are called script packages. Everything necessary for a holistic data exchange between systems is in the script package.
A script package contains one or more script steps. A scenario step is a specific integration flow that includes an inbound phase, a processing phase, and an outbound phase.
In the first phase, the integration platform receives an incoming message and translates it into XML format. During the processing phase, the message is transformed and processed, the recipient is identified, and the message parameters are compared. At the output stage, the integration platform transforms the message into the recipient's ERP system format and sends the message.
In the process of designing a script step, you need to set the main parameters: how to start the step, which systems interact with each other, how the integration platform processes the message, whether there are further steps (for example, calling an external system).
The script steps can be as follows:
1. Synchronous (request-response):
- the sender generates a request that initiates the execution of the step
- the processing result is returned to the sender as a response
2. Asynchronous (sender to the recipient):
- is started by timer, event or call
- the data arrives from the sending system, processed, transformed and transferred to the recipient at any time
The inbound channel describes the type of sending system and the interface (API) that the integration platform can use to receive incoming data. As an incoming channel, HTTP, a file, an empty message (Void (timer)), Web Service, SAP Business One, and SAP ERP can be used.
The outgoing channel describes the type of the recipient system and the interface (API) that will be used by the integration platform for data transfer. As an outgoing channel, you can select HTTP, a file, an empty message (Void, only for synchronous steps), Web Service, database, SAP Business One and SAP ERP.
A graphic tool is used for the processing phase. The main design element is atoms. Atoms are arranged in sequence and are used to call external systems (for example, an SQL database or email). Each atom receives an incoming message, performs certain tasks, and passes the message to the next atom.
To transfer data between integration steps, an internal queue processing mechanism is used. Thus, integration steps can be combined into a script package.
Integration scenario development example
Business needs real-time access to data on its processes, as well as automation of manual labor. Process automation can help a company optimize workload and reduce the risk of errors in transmitting information. Integration with the system of the supplier or a particular type of business will eliminate these risks.
Let's look at a simple practical example of the integration of two systems - the customer and the supplier. Both companies work for SAP Business One and want to automate the checkout process. In this example, the “Purchase Order” in company 1 is transferred to company 2, where the document “Sales Order” is generated. Company 2 confirms the formation of an order in company 1.
An integration scenario can be launched by creating a “Purchase Order” document in company 1. There will be 2 integration steps in the scenario:
To run the integration scenario, we need the company’s master data code 1. This data is not contained in the “Order” and is not transferred to the integration platform. To store this information, a global table can be used. To set the parameters of the global table, it is necessary to determine the type of the global table (type 1 for relations 1 <-> 1; type 2 for relations 1 <-> N), the length and names of the table fields:
After creating the global table, we can enter the data in it:
Next, for integration step 1 define the incoming channel:
For the outgoing channel, select the empty message (void), because we do not have a recipient system:
Let's move on to the configuration of the message processing process. The numbering of atoms is carried out in the order added to the process.
A conversion atom (atom1) is optional. It allows you to store information about the launch conditions and the sender system for later use in other atoms. CustomerCode value for company 1 is loaded from the global table. The User ID value is selected from the T (trigger) section of the XML conversion of the incoming B1 Event that creates the “Purchase Order”.
When configuring the B1 Object atom (atom2), we will use the following parameters:
Before the B1 Object atom, we use the previous transform atom (atom3). This atom prepares information for loading into atom2 (B1 Object).
In the Documents section, you need to determine the values of the title of the document "Sales Order":
The Document_Lines section defines the lines of the Sales Order document. The necessary information is extracted from section S (message from the sender system, sender message) of the incoming document “Purchase Order”.
The terminating atom (atom0), as a rule, converts the data for transmission to the receiving system. In our scenario, an empty message (void) is selected as the type of outgoing channel. However, we must define this atom to create a log entry. The element will contain the DIresult and DImsg attributes. The DImsg attribute must contain the key of the created document (in case of successful completion of the script) or an error message (in case of unsuccessful execution).
Atom4 and atom5 belong to the second integration step: sending a message to the company user 1. The call atom (with the Call step type) does not imply the previous transformation atom. Nevertheless, as in the case of the first step, for atom4 we define the previous transformation atom (atom5). In the parameters of atom5 we indicate the data transferred to the called atom. In our case, this data will contain an element with the DIresult attributes (the result of processing the B1 Object atom) and the SAP Business One user code (B1User).
For the call atom, we set the parameters:
We proceed to the formation of the second integration step. We want to send different messages to the user of company 1, depending on the result of the document creation process. To do this, we will use an atom with the type of branch start.
For atoms with conditions, several atoms of the path type and only one atom of the otherwise type can be used. The integration platform only works with true results when executing path. Therefore, in our case, it is only necessary to set the condition for the path atom:
/*►/vpf:Msg/vpf:Body/vpf:Payload[./@Role='S'†/B1Result/Result = 'success']
The atom otherwise would be only work if the result of executing the path atom is false. The unbranch atom completes the branching and contains the results of atomic conditions.
The parameters of the B1 Message atoms must contain the subject and message text, as well as user information
/vpf:Msg/vpf:Body/vpf:Payload[./@Role='S'†/B1Result/B1User
In the final atom of the second integration step, you must verify the execution of the branch. To do this, you can use the XSL template stored in the integration platform.
Activation and verification of the script The
integration platform checks the integrity of the integration script when you open the script settings window.
In our case, the verification was successful, and we can begin to execute the script.
Create a “Purchase Order” in the database of company 1 from the supplier V22222.
After creating the document, we see a notification from user B1i that the order was created successfully:
Company 2 created a “Sales Order” with data from the “Purchase Order” and an indication of the document number in company 1:
Conclusion
As a conclusion, I suggest watching a video from our client, DeLaval. The company has long and actively used a two-level ERP strategy: in the parent enterprise and in large branches - SAP ERP, and in small subsidiaries - SAP Business One. In this video, Steve Woodgate, Business Integration Director at DeLaval, talks about the reasons and results for choosing SAP Business One as a second-level ERP.
You can see examples of implementations of SAP Business One on our website .
A video with reviews of the capabilities of the solution is not only available on our Youtube channel .
In the next article, we will talk about the capabilities of the new version of SAP Business One 9.3, which is now actively tested by both SAP and customers. By the way, one of the first “living” customers in the world on SAP Business One version 9.3 was a customer from Russia - Telecom Exchange. A video with client comments can be viewed here: youtu.be/GTgm-nJddDI
Thank you all for reading and feedback!
This time we decided to return to the topic of ERP-systems. In the SAP product line, there are different products for companies of various sizes - from multinational corporations to medium and small businesses. There are also combinations - when companies use several types of ERP at once, for headquarters and for branches. Such cases are called two-level ERPs, and SAP Business One is excellent as a “lightweight” system. In this article we will talk about the details and integration details.
But first, let's answer the question - what is a two-level ERP?
The term "two-level ERP" has become familiar to many. The concept of a two-level ERP system is used in corporations that need a common standard of reporting and business applications in their subsidiaries or branches. In small business units, for many reasons, it is simply not practical to use large ERPs: other business processes, the difficulty of adapting employees, and the slow deployment speed, which can take months. And if you add here more time for staff training, the costs of maintaining the system and with all this you need to implement a “big” solution in 40 branches at once, it will take a lot of time (often even months) and require significant costs. For comparison, “small” solutions can be implemented in a few weeks.
Two-level ERP is applicable today not only for large corporations, with their relations “headquarters => branch”. This strategy is viable when working with suppliers, distributors, dealers and service organizations.
An example of our European client is Heineken Spain. They had a task - how to establish data exchange between 600 distributors and Heineken Spain on orders, goods movement and invoices for payment and then automate all processes. As a result, the company decided to develop a solution based on SAP Business One.
Heinekein Spain came up with a scenario using the Internet of things - they collect data from more than 300 thousand sensors that are built into beer taps. The company receives information on beer consumption from a single information system. As a result, Heineken realized how to better manage the sales channel, optimize the sales chain and improve performance. They also began to receive data on beer consumption in real time, one might say, "from every tap."
With two-level ERP-systems, not everything is perfect. Let's see what problems can arise when integrating different systems.
Why even introduce ERP systems in branches or subsidiaries? In large holdings or large companies, of course, they want to receive transparent analytics or reporting on business processes. Moreover, this problem often happens - in each branch they put their own solution convenient for local specialists, and as a result, a “zoo” of systems and services appears in the company. And of course, they may not be compatible with the parent ERP for a variety of reasons - for example, due to the use of solutions with closed APIs. In this case, one cannot hope for a single reporting, or for any automation of business processes.
What does SAP have? We have a whole line of ERP systems for different tasks and goals. For companies with complex business processes, “heavyweights” are needed - here they choose S / 4HANA, ECC or R / 3. For businesses, SAP Business One is simpler or smaller. At the same time, B1 can easily be integrated with large SAP solutions - S / 4HANA, Hybris, Ariba, Customer Checkout, Concur, mobile applications and even government services.
What are the opportunities in SAP Business One for the development of integration services:
- .Net development for integration through SAP Business One SDK / DI-API
- .Net development for integration through Service Layer (available for SAP Business One version for SAP HANA)
- Integration Framework
Features, target audience and scope are given in the table:
Further in the article we will talk in detail about the Integration Framework.
Integration framework
The SAP Business One Integration Framework (B1iF) is available in the SAP Business One ERP system starting from version 8.8. It can be installed on the SAP HANA or MS SQL database. The main task of B1iF is to send and receive data from external (SAP and non-SAP) systems. Integration script packages are built within the Integration Framework. The scripting logic is based on business processes: error management, conflicts, transactions (and their order of execution), execution guarantee, monitoring, debugging and administration are performed in B1iF.
To develop a scenario for integrating the two systems, programming skills are not required.
The process sequence is set using the built-in graphic designer in the platform. B1iF BizFlow Atoms built-in functional units are used for value mapping, call setup (SAP Business One, SAP ERP, HTTP, SQL, file systems, etc.), XSLT conversions. Data mapping is performed using XSLT transformations in the built-in (or external) XML editor. Debugging tools allow you to develop an individual process sequence in a structured and visual form.
The integration scripts that run on the integration platform are called script packages. Everything necessary for a holistic data exchange between systems is in the script package.
A script package contains one or more script steps. A scenario step is a specific integration flow that includes an inbound phase, a processing phase, and an outbound phase.
In the first phase, the integration platform receives an incoming message and translates it into XML format. During the processing phase, the message is transformed and processed, the recipient is identified, and the message parameters are compared. At the output stage, the integration platform transforms the message into the recipient's ERP system format and sends the message.
In the process of designing a script step, you need to set the main parameters: how to start the step, which systems interact with each other, how the integration platform processes the message, whether there are further steps (for example, calling an external system).
The script steps can be as follows:
1. Synchronous (request-response):
- the sender generates a request that initiates the execution of the step
- the processing result is returned to the sender as a response
2. Asynchronous (sender to the recipient):
- is started by timer, event or call
- the data arrives from the sending system, processed, transformed and transferred to the recipient at any time
The inbound channel describes the type of sending system and the interface (API) that the integration platform can use to receive incoming data. As an incoming channel, HTTP, a file, an empty message (Void (timer)), Web Service, SAP Business One, and SAP ERP can be used.
The outgoing channel describes the type of the recipient system and the interface (API) that will be used by the integration platform for data transfer. As an outgoing channel, you can select HTTP, a file, an empty message (Void, only for synchronous steps), Web Service, database, SAP Business One and SAP ERP.
A graphic tool is used for the processing phase. The main design element is atoms. Atoms are arranged in sequence and are used to call external systems (for example, an SQL database or email). Each atom receives an incoming message, performs certain tasks, and passes the message to the next atom.
To transfer data between integration steps, an internal queue processing mechanism is used. Thus, integration steps can be combined into a script package.
Integration scenario development example
Business needs real-time access to data on its processes, as well as automation of manual labor. Process automation can help a company optimize workload and reduce the risk of errors in transmitting information. Integration with the system of the supplier or a particular type of business will eliminate these risks.
Let's look at a simple practical example of the integration of two systems - the customer and the supplier. Both companies work for SAP Business One and want to automate the checkout process. In this example, the “Purchase Order” in company 1 is transferred to company 2, where the document “Sales Order” is generated. Company 2 confirms the formation of an order in company 1.
An integration scenario can be launched by creating a “Purchase Order” document in company 1. There will be 2 integration steps in the scenario:
- at the first step, a “Sales Order” document is generated in company 2 using the atom B1 Object call
- call step atom is used to bind to the second step
- at the second step, the company 1 user is informed about the status of the created “Sales Order” document
To run the integration scenario, we need the company’s master data code 1. This data is not contained in the “Order” and is not transferred to the integration platform. To store this information, a global table can be used. To set the parameters of the global table, it is necessary to determine the type of the global table (type 1 for relations 1 <-> 1; type 2 for relations 1 <-> N), the length and names of the table fields:
After creating the global table, we can enter the data in it:
Next, for integration step 1 define the incoming channel:
- Channel Type - SAP Business One
- launch on the B1 Event (creation of the document “Purchase Order”)
- the identifier used is the object ID “Purchase order” (22)
- receiving data by DI-API with type Object
For the outgoing channel, select the empty message (void), because we do not have a recipient system:
Let's move on to the configuration of the message processing process. The numbering of atoms is carried out in the order added to the process.
A conversion atom (atom1) is optional. It allows you to store information about the launch conditions and the sender system for later use in other atoms. CustomerCode value for company 1 is loaded from the global table. The User ID value is selected from the T (trigger) section of the XML conversion of the incoming B1 Event that creates the “Purchase Order”.
When configuring the B1 Object atom (atom2), we will use the following parameters:
- Sysid: ID assigned by SAP Business One in the integration platform
- B1 Login: assigned from the settings of the integration platform
- Method: synchronous
- Object identifier: 17 (sales order)
- Key Name: DocEntry
- Key Value: N / A (filled automatically when the document was created in SAP Business One)
- Payload: name of the preceding conversion atom
Before the B1 Object atom, we use the previous transform atom (atom3). This atom prepares information for loading into atom2 (B1 Object).
In the Documents section, you need to determine the values of the title of the document "Sales Order":
- Company Master Data Code for Company 1 (CardCode)
- document date (DocDate) is set by calling the date and time function built into the integration platform, which returns the current date and time
- shipment date (DocDueDate) is calculated based on DocDate
The Document_Lines section defines the lines of the Sales Order document. The necessary information is extracted from section S (message from the sender system, sender message) of the incoming document “Purchase Order”.
|
|
The terminating atom (atom0), as a rule, converts the data for transmission to the receiving system. In our scenario, an empty message (void) is selected as the type of outgoing channel. However, we must define this atom to create a log entry. The element will contain the DIresult and DImsg attributes. The DImsg attribute must contain the key of the created document (in case of successful completion of the script) or an error message (in case of unsuccessful execution).
Atom4 and atom5 belong to the second integration step: sending a message to the company user 1. The call atom (with the Call step type) does not imply the previous transformation atom. Nevertheless, as in the case of the first step, for atom4 we define the previous transformation atom (atom5). In the parameters of atom5 we indicate the data transferred to the called atom. In our case, this data will contain an element with the DIresult attributes (the result of processing the B1 Object atom) and the SAP Business One user code (B1User).
For the call atom, we set the parameters:
- type of processing of the called atom (synchronous or asynchronous)
- called atom name
- atom with input parameters (previous atom of transformation)
We proceed to the formation of the second integration step. We want to send different messages to the user of company 1, depending on the result of the document creation process. To do this, we will use an atom with the type of branch start.
For atoms with conditions, several atoms of the path type and only one atom of the otherwise type can be used. The integration platform only works with true results when executing path. Therefore, in our case, it is only necessary to set the condition for the path atom:
/*►/vpf:Msg/vpf:Body/vpf:Payload[./@Role='S'†/B1Result/Result = 'success']
The atom otherwise would be only work if the result of executing the path atom is false. The unbranch atom completes the branching and contains the results of atomic conditions.
The parameters of the B1 Message atoms must contain the subject and message text, as well as user information
/vpf:Msg/vpf:Body/vpf:Payload[./@Role='S'†/B1Result/B1User
In the final atom of the second integration step, you must verify the execution of the branch. To do this, you can use the XSL template stored in the integration platform.
Activation and verification of the script The
integration platform checks the integrity of the integration script when you open the script settings window.
In our case, the verification was successful, and we can begin to execute the script.
Create a “Purchase Order” in the database of company 1 from the supplier V22222.
After creating the document, we see a notification from user B1i that the order was created successfully:
Company 2 created a “Sales Order” with data from the “Purchase Order” and an indication of the document number in company 1:
Conclusion
As a conclusion, I suggest watching a video from our client, DeLaval. The company has long and actively used a two-level ERP strategy: in the parent enterprise and in large branches - SAP ERP, and in small subsidiaries - SAP Business One. In this video, Steve Woodgate, Business Integration Director at DeLaval, talks about the reasons and results for choosing SAP Business One as a second-level ERP.
You can see examples of implementations of SAP Business One on our website .
A video with reviews of the capabilities of the solution is not only available on our Youtube channel .
In the next article, we will talk about the capabilities of the new version of SAP Business One 9.3, which is now actively tested by both SAP and customers. By the way, one of the first “living” customers in the world on SAP Business One version 9.3 was a customer from Russia - Telecom Exchange. A video with client comments can be viewed here: youtu.be/GTgm-nJddDI
Thank you all for reading and feedback!