Two-tier ERP and SAP Business One: how it works
Hello!
This time we decided to return to the topic of ERP-systems. There are different products in the SAP product line for companies of various sizes - from multinational corporations to small and medium businesses. There are combinations - when companies use several types of ERP, for headquarters and for branches. Such cases are called two-tier ERP, and SAP Business One is great as a “lightweight” system. In this article we will talk about the details and details of integration.
But first, let's answer the question - what is a two-tier ERP?
')
The term "two-tier ERP" has already become familiar to many. The concept of a two-tier ERP system is used in corporations that need a uniform standard for reporting and business applications in their subsidiaries or branches. In many small business units, for many reasons, it is simply inappropriate to use large ERPs: other business processes, difficulty in adapting employees, and slow deployment, which can take months. And if you add more time for staff training here, 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 will require significant costs. For comparison - “small” solutions can be implemented in a few weeks.
Two-tier ERP today is applicable not only for large corporations, with their “headquarters => branch” relations. This strategy is viable when dealing 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.
In Heinekein Spain, they invented a scenario using the Internet of things - they collect data from more than 300 thousand sensors that are embedded in beer taps. The company receives information about the consumption of beer with 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 each tap”.
With two-tier ERP systems, not everything is perfect. Let's see what problems may arise when integrating different systems.
Why in general to implement 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. With this often happens such a problem - in each branch they put their decision, which is 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 "head" ERP for various reasons - for example, due to the use of solutions with closed API. In this case, you can not rely on a single reporting, nor on 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 choose S / 4HANA, ECC or R / 3. For organizations, SAP Business One is simpler or smaller. At the same time, B1 can be easily integrated with large SAP solutions - S / 4HANA, Hybris, Ariba, Customer Checkout, Concur, mobile applications and even public services.
What opportunities does SAP Business One have for developing integration services?
Features, target audience and scope of application are shown in the table:
The following article will tell you in detail about the Integration Framework platform.
Integration Framework
The SAP Business One Integration Framework (B1iF) is available in the SAP Business One ERP system, starting with version 8.8. It can be installed on a SAP HANA or MS SQL database. The main objective of B1iF is to send and receive data from external (SAP and non-SAP) systems. Packages of integration scripts are built inside the Integration Framework. The script logic is based on business processes: error management, conflicts, transactions (and their order of execution), execution guarantees, monitoring, debugging and administration are performed in B1iF.
To develop a scenario for the integration of two systems, programming skills are not required.
The sequence of the process is set using the built-in graphic designer in the platform. The built-in functional units of B1iF BizFlow Atoms are used for matching values, setting up calls (SAP Business One, SAP ERP, HTTP, SQL, file systems, etc.), XSLT transformations. Data mapping is done using XSLT transformations in the embedded (or external) XML editor. Debugging tools allow you to develop an individual process sequence in a structured and visual way.
Integration scripts that run on an integration platform are called script packages. Everything you need for complete 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 the inbound phase, the processing phase and the outbound phase.
In the first phase, the integration platform receives the incoming message and translates it into an XML format. During the processing phase, the message is transformed and processed, the recipient is defined and the message parameters are mapped. At the output stage, the integration platform transforms the message into the format of the recipient's ERP system and sends the message.
In the process of designing a step of a script, it is necessary to set basic parameters: a way to launch a 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 may be as follows:
1. Synchronous (request-response):
- the sender makes a request that initiates the step
- the processing result is returned to the sender as a response
2. Asynchronous (sender to receiver):
- run by timer, event or call
- data comes from the sending system, processed, transformed and transmitted to the recipient at any time
An inbound channel describes the type of sender system and an interface (API) that an integration platform can use to receive incoming data. HTTP, file, empty message (Void (timer)), Web Service, SAP Business One and SAP ERP can be used as an incoming channel.
The outgoing channel describes the type of recipient system and the interface (API) that the integration platform will use for data transfer. HTTP, file, empty message (Void, for synchronous steps only), Web Service, database, SAP Business One and SAP ERP can be selected as the outgoing channel.
A graphic tool is used for the processing phase. The main design element are atoms. Atoms are arranged in a sequence and are used to call external systems (for example, a 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. In this way, integration steps can be combined into a script package.
An example of developing an integration scenario
Businesses need access to real-time data about their processes, as well as automation of manual labor. Automating processes can help a company optimize staff utilization and reduce the risk of errors in information transfer. Integration with the supplier’s system or a separate 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 in SAP Business One and want to automate the process of placing orders. In this example, the “Purchase Order” in Company 1 is transferred to Company 2, where the “Sales Order” document is generated. Company 2 confirms the formation of the order in the company 1.
The 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 will need the company master data code 1. This data is not contained in the “Order” and is not transmitted to the integration platform. A global table can be used to store this information. To set global table parameters, it is necessary to define the type of global table (type 1 for relations 1 <-> 1; type 2 for relations 1 <-> N), the length and names of the table fields:
After creating a global table, we can enter data into it:
Next, for integration step 1, we define the incoming channel:
For the outgoing channel, select an empty message (void), since we do not have a recipient system:
Let us turn to the configuration of the processing message. The numbering of atoms is carried out in the order of addition to the process.
The transform atom (atom1) is optional. It allows you to store information about the launch conditions and the sending system for later use in other atoms. The CustomerCode value for company 1 is loaded from the global table. The User ID value is selected from section T (trigger, trigger) of the XML transformation of the incoming B1 Event, which creates a “Purchase Order”.
When configuring an atom B1 Object (atom2) we will use the following parameters:
Before the atom B1 Object we use the preceding transform atom (atom3). In this atom, information is prepared for loading into atom2 (B1 Object).
In the Documents section, you need to define the values ​​of the header 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 (the message from the sender system, sender message) of the incoming “Purchase order” document.
The terminating atom (atom0), as a rule, converts the data for transfer to the recipient system. In our scenario, an empty message (void) is selected as the outgoing channel type. However, we must define this atom to create an entry in the logs. The element will contain the attributes DIresult and DImsg. 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 user of company 1. A call atom (with type Call step) does not imply a prior conversion atom. However, as in the case of the first step, for atom4 we define the preceding transformation atom (atom5). In the parameters of the atom5 we indicate the data transmitted to the called atom. In our case, this data will contain an element with DIresult attributes (the result of processing the B1 Object atom) and an SAP Business One user code (B1User).
For the atom of the call, we set the parameters:
Let us proceed to the formation of the second integration step. We want to send different messages to user company 1 depending on the result of the document creation process. For this we will use an atom with the type of the beginning of branching (branch).
For atoms with conditions, several atoms with the path type can be used and only one atom of the type otherwise. The integration platform only works with true results when executing the path. Therefore, in our case, you only need to specify the condition for the path atom:
/*[/vpf:Msg/vpf:Body/vpf:Payload[./@Role='S'/B1Result/Result = 'success']
The atom otherwise will work only if the result of the path atom is false. The unbranch atom completes branching and contains the results of atom conditions.
In the parameters of the atoms B1 Message, you must specify the subject and text of the message, as well as information about the user
/vpf:Msg/vpf:Body/vpf:Payload[./@Role='S'/B1Result/B1User
In the final atom of the second integration step, it is necessary to check the execution of branching. To do this, you can use the XSL template stored in the integration platform.
Script activation and validation
The integration platform verifies the integrity of the integration scenario when opening the script configuration window.
In our case, the test was successful, and we can proceed to the execution of 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 the user B1i that the order was created successfully:
In company 2, a sales order was created with data from the purchase order and an indication of the document number in company 1:
Conclusion
As a conclusion, I suggest watching the video of our client - the company DeLaval. The company has been actively using the two-tier ERP strategy for a long time: in the head office 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 get acquainted with examples of SAP Business One implementations on our website .
Video with reviews of the solutions and 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 testing both SAP and customers. By the way, one of the first “live” customers in the world on SAP Business One version 9.3 was the customer from Russia - Telecom-Exchange. A video with customer 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. There are different products in the SAP product line for companies of various sizes - from multinational corporations to small and medium businesses. There are combinations - when companies use several types of ERP, for headquarters and for branches. Such cases are called two-tier ERP, and SAP Business One is great as a “lightweight” system. In this article we will talk about the details and details of integration.
But first, let's answer the question - what is a two-tier ERP?
')
The term "two-tier ERP" has already become familiar to many. The concept of a two-tier ERP system is used in corporations that need a uniform standard for reporting and business applications in their subsidiaries or branches. In many small business units, for many reasons, it is simply inappropriate to use large ERPs: other business processes, difficulty in adapting employees, and slow deployment, which can take months. And if you add more time for staff training here, 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 will require significant costs. For comparison - “small” solutions can be implemented in a few weeks.
Two-tier ERP today is applicable not only for large corporations, with their “headquarters => branch” relations. This strategy is viable when dealing 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.
In Heinekein Spain, they invented a scenario using the Internet of things - they collect data from more than 300 thousand sensors that are embedded in beer taps. The company receives information about the consumption of beer with 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 each tap”.
With two-tier ERP systems, not everything is perfect. Let's see what problems may arise when integrating different systems.
Why in general to implement 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. With this often happens such a problem - in each branch they put their decision, which is 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 "head" ERP for various reasons - for example, due to the use of solutions with closed API. In this case, you can not rely on a single reporting, nor on 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 choose S / 4HANA, ECC or R / 3. For organizations, SAP Business One is simpler or smaller. At the same time, B1 can be easily integrated with large SAP solutions - S / 4HANA, Hybris, Ariba, Customer Checkout, Concur, mobile applications and even public services.
What opportunities does SAP Business One have for developing integration services?
- .Net development for integration via SAP Business One SDK / DI-API
- .Net development for integration via Service Layer (available for SAP Business One version for SAP HANA)
- Integration Framework (Integration Platform)
Features, target audience and scope of application are shown in the table:
The following article will tell you in detail about the Integration Framework platform.
Integration Framework
The SAP Business One Integration Framework (B1iF) is available in the SAP Business One ERP system, starting with version 8.8. It can be installed on a SAP HANA or MS SQL database. The main objective of B1iF is to send and receive data from external (SAP and non-SAP) systems. Packages of integration scripts are built inside the Integration Framework. The script logic is based on business processes: error management, conflicts, transactions (and their order of execution), execution guarantees, monitoring, debugging and administration are performed in B1iF.
To develop a scenario for the integration of two systems, programming skills are not required.
The sequence of the process is set using the built-in graphic designer in the platform. The built-in functional units of B1iF BizFlow Atoms are used for matching values, setting up calls (SAP Business One, SAP ERP, HTTP, SQL, file systems, etc.), XSLT transformations. Data mapping is done using XSLT transformations in the embedded (or external) XML editor. Debugging tools allow you to develop an individual process sequence in a structured and visual way.
Integration scripts that run on an integration platform are called script packages. Everything you need for complete 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 the inbound phase, the processing phase and the outbound phase.
In the first phase, the integration platform receives the incoming message and translates it into an XML format. During the processing phase, the message is transformed and processed, the recipient is defined and the message parameters are mapped. At the output stage, the integration platform transforms the message into the format of the recipient's ERP system and sends the message.
In the process of designing a step of a script, it is necessary to set basic parameters: a way to launch a 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 may be as follows:
1. Synchronous (request-response):
- the sender makes a request that initiates the step
- the processing result is returned to the sender as a response
2. Asynchronous (sender to receiver):
- run by timer, event or call
- data comes from the sending system, processed, transformed and transmitted to the recipient at any time
An inbound channel describes the type of sender system and an interface (API) that an integration platform can use to receive incoming data. HTTP, file, empty message (Void (timer)), Web Service, SAP Business One and SAP ERP can be used as an incoming channel.
The outgoing channel describes the type of recipient system and the interface (API) that the integration platform will use for data transfer. HTTP, file, empty message (Void, for synchronous steps only), Web Service, database, SAP Business One and SAP ERP can be selected as the outgoing channel.
A graphic tool is used for the processing phase. The main design element are atoms. Atoms are arranged in a sequence and are used to call external systems (for example, a 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. In this way, integration steps can be combined into a script package.
An example of developing an integration scenario
Businesses need access to real-time data about their processes, as well as automation of manual labor. Automating processes can help a company optimize staff utilization and reduce the risk of errors in information transfer. Integration with the supplier’s system or a separate 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 in SAP Business One and want to automate the process of placing orders. In this example, the “Purchase Order” in Company 1 is transferred to Company 2, where the “Sales Order” document is generated. Company 2 confirms the formation of the order in the company 1.
The integration scenario can be launched by creating a Purchase Order document in company 1. There will be 2 integration steps in the scenario:
- in the first step, a sales order document is formed in company 2 using the atom B1 Object call
- Call Step atom is used to bind with the second step
- the second step informs the user of company 1 about the status of the created document “Sales order”
To run the integration scenario, we will need the company master data code 1. This data is not contained in the “Order” and is not transmitted to the integration platform. A global table can be used to store this information. To set global table parameters, it is necessary to define the type of global table (type 1 for relations 1 <-> 1; type 2 for relations 1 <-> N), the length and names of the table fields:
After creating a global table, we can enter data into it:
Next, for integration step 1, we define the incoming channel:
- channel type - SAP Business One
- launch on event B1 Event (creating a document “Purchase order”)
- as an identifier is used the object ID "Purchase Order" (22)
- Data acquisition by DI-API with type Object
For the outgoing channel, select an empty message (void), since we do not have a recipient system:
Let us turn to the configuration of the processing message. The numbering of atoms is carried out in the order of addition to the process.
The transform atom (atom1) is optional. It allows you to store information about the launch conditions and the sending system for later use in other atoms. The CustomerCode value for company 1 is loaded from the global table. The User ID value is selected from section T (trigger, trigger) of the XML transformation of the incoming B1 Event, which creates a “Purchase Order”.
<Values> <xsl:variable name="MappingCardCode" select="document('/com.sap.b1i.vplatform.scenarios.design/vPac.xxx.B2BB1/vTbl.B1MappingCardCode.xml')"></xsl:variable> <xsl:variable name="Vendor" select="$msg/BOM/BO/Documents/row/CardCode"></xsl:variable> <xsl:variable name="Customer" select="$MappingCardCode/table/row[./col[2]=$Vendor]/col[1]"></xsl:variable> <CustomerCode> <xsl:value-of select="$Customer"></xsl:value-of> </CustomerCode> <B1User> <xsl:value-of select="/vpf:Msg/vpf:Body/vpf:Payload[./@Role='T']/Event/b1e:b1events/b1e:b1event/b1e:userid"></xsl:value-of> </B1User> </Values> When configuring an atom B1 Object (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 is created in SAP Business One)
- Payload: the name of the previous conversion atom
Before the atom B1 Object we use the preceding transform atom (atom3). In this atom, information is prepared for loading into atom2 (B1 Object).
In the Documents section, you need to define the values ​​of the header of the document “Sales order”:
- customer master data code for company 1 (CardCode)
- The document date (DocDate) is set by calling the date and time function built into the integration platform, which returns the current date and time
- Shipping 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 (the message from the sender system, sender message) of the incoming “Purchase order” document.
<Documents> <row> <xsl:variable name="date"> <xsl:call-template name="b1ilib.today"></xsl:call-template> </xsl:variable> <DocDate> <xsl:value-of select="$date"></xsl:value-of> </DocDate> <DocDueDate> <xsl:call-template name="b1ilib.date_plus"> <xsl:with-param name="date" select="$date"></xsl:with-param> <xsl:with-param name="x" select="20"></xsl:with-param> </xsl:call-template> </DocDueDate> <xsl:variable name="Customer" select="/vpf:Msg/vpf:Body/vpf:Payload[./@id='atom1']/Values/CustomerCode"></xsl:variable> <CardCode> <xsl:value-of select="$Customer"></xsl:value-of> </CardCode> <NumAtCard> <xsl:value-of select="$msg/BOM/BO/Documents/row/DocNum"></xsl:value-of> </NumAtCard> </row> </Documents> <Document_Lines> <xsl:for-each select="$msg/BOM/BO/Document_Lines/row"> <row> <ItemCode> <xsl:value-of select="ItemCode"></xsl:value-of> </ItemCode> <Quantity> <xsl:value-of select="Quantity"></xsl:value-of> </Quantity> </row> </xsl:for-each> </Document_Lines> <xsl:include href="../../com.sap.b1i.system.lib/xsl/datetime.xsl"></xsl:include> The terminating atom (atom0), as a rule, converts the data for transfer to the recipient system. In our scenario, an empty message (void) is selected as the outgoing channel type. However, we must define this atom to create an entry in the logs. The element will contain the attributes DIresult and DImsg. 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).
<xsl:variable name="Status" select="$msgB1/@DIresult"></xsl:variable> <xsl:variable name="Entry" select="$msgB1/@DImsg"></xsl:variable> <Msg> <xsl:value-of select="concat('Message: ',$Status, ', DocEntry: ',$Entry)"></xsl:value-of> </Msg> Atom4 and atom5 belong to the second integration step: sending a message to user of company 1. A call atom (with type Call step) does not imply a prior conversion atom. However, as in the case of the first step, for atom4 we define the preceding transformation atom (atom5). In the parameters of the atom5 we indicate the data transmitted to the called atom. In our case, this data will contain an element with DIresult attributes (the result of processing the B1 Object atom) and an SAP Business One user code (B1User).
<B1Result> <Result> <xsl:value-of select="/vpf:Msg/vpf:Body/vpf:Payload[./@id='atom2']/@DIresult"></xsl:value-of> </Result> <B1User> <xsl:value-of select="/vpf:Msg/vpf:Body/vpf:Payload[./@id='atom1']/Values/B1User"></xsl:value-of> </B1User> </B1Result> For the atom of the call, we set the parameters:
- type of processing of the called atom (synchronous or asynchronous)
- name of the called atom
- atom with input parameters (preceding transform atom)
Let us proceed to the formation of the second integration step. We want to send different messages to user company 1 depending on the result of the document creation process. For this we will use an atom with the type of the beginning of branching (branch).
For atoms with conditions, several atoms with the path type can be used and only one atom of the type otherwise. The integration platform only works with true results when executing the path. Therefore, in our case, you only need to specify the condition for the path atom:
/*[/vpf:Msg/vpf:Body/vpf:Payload[./@Role='S'/B1Result/Result = 'success']
The atom otherwise will work only if the result of the path atom is false. The unbranch atom completes branching and contains the results of atom conditions.
In the parameters of the atoms B1 Message, you must specify the subject and text of the message, as well as information about the user
/vpf:Msg/vpf:Body/vpf:Payload[./@Role='S'/B1Result/B1User
In the final atom of the second integration step, it is necessary to check the execution of branching. To do this, you can use the XSL template stored in the integration platform.
Script activation and validation
The integration platform verifies the integrity of the integration scenario when opening the script configuration window.
In our case, the test was successful, and we can proceed to the execution of 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 the user B1i that the order was created successfully:
In company 2, a sales order was created with data from the purchase order and an indication of the document number in company 1:
Conclusion
As a conclusion, I suggest watching the video of our client - the company DeLaval. The company has been actively using the two-tier ERP strategy for a long time: in the head office 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 get acquainted with examples of SAP Business One implementations on our website .
Video with reviews of the solutions and 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 testing both SAP and customers. By the way, one of the first “live” customers in the world on SAP Business One version 9.3 was the customer from Russia - Telecom-Exchange. A video with customer comments can be viewed here: youtu.be/GTgm-nJddDI
Thank you all for reading and feedback!
Source: https://habr.com/ru/post/350514/
All Articles