Oil and Gas Refining & Marketing Billing Process And Common Requirements in Marketing Billing

[mukundsrivathsa]

Introduction

In my previous blog https://blogs.sap.com/2020/10/09/oil-and-gas-refining-marketing-billing-process-and-common-requireme..., I tried to layout some of the common requirements for billing in the commercial billing area. Here, i am making an attempt to outline some of the common requirements around Marketing billing requirement.

Business Process Overview

Marketing business in refining and marketing involves a lot of business processes like selling the products from terminal to retail customers, moving the products from terminals to own retail stations, inventorying the product at retail stations, accounting credit card sales and collecting commission, charging customers for the service like for retail equipment, rent (which are recurring revenue), providing credit for mystery shops and invoicing for other miscellaneous activities. Most of the marketing sales are received by back office in electronic format. Rack sales come from different provides with DTN being one of the largest services provide in US. Retail sales comes from different providers depending on the software installed in the POS systems. PDI is one of the common data providers. The credit card transaction data comes from various providers as well and most common ones happen to be from Heartland Payment systems (HPS).

The rack sales information is generally passed into SAP either into a custom developed applications  or S4 SCSD (Supply Chain Secondary Distribution in newer implementations) which parses the data, recognizes the sales transactions and posts those transactions into SAP by creating Sales orders and deliveries which can be billed

Similarly, the retails sales and credit card information come from different sources and is passed into custom applications or into RFNO (Retail Fuel Network Operations with S/4 HANA - newer implementations) to parse the data and recognize transaction and post them in SAP.

Common Requirement in Marketing (Rack) Billing

Rack billing is one of the major activities of a refining and marketing business. This business can contribute upto 50% of the total business in terms of revenue. A transaction is considered a rack sale or a terminal sale when a truck pulls into the terminal, picks the refined products (branded or unbranded) and delivers to the customer (destination). Rack activity is categorized into wholesale and retail business. There are variety of customers that marketing business serves to. The customers could be

• Those who buy refined products for running their fleet


• Those who buy unbranded products for their retails sites and sell them at their gas stations


• the retail station owners who buy gas for their own unbranded gas stations,


• the branded gas stations run by smaller companies


• the gas stations run by the refining and marketing company itself


• the refining and marketing companies also buy branding from other companies and sell/supply products to those gas stations by mixing appropriate additives


• Unmanned gas stations which can cater as retail business and sometime wholesale.

With such a varied business, there are some common requirements that come up for billing. Here some of those common requirements are discussed.

1. Pricing Requirement

Pricing is very important factor for invoice. The pricing should be complete and accurate for all the line items. An invoice is termed complete when all the line items on the invoice (that are supposed to be priced) have price. Pricing for these line items could come from various sources. Pricing is a very big topic but in general, it depends on the contract that is negotiated between the marketing team and the customer. However, the main requirement will be to make sure that all the line items have price in them. Commodity Pricing Engine (CPE) has ability to stop a line item without final price from getting into the billing document, but if a BOL has three line items for example and 2 of them have final price and one does not, SAP creates invoice for the two line items that have final price. Partial invoice (not all delivered line items for a Bill Of Lading in the invoice) are not accepted by the customers. Customers refuse to pay those unless they get the correct invoice. This would delay the revenue and it would put additional workload on the billing dept. to cancel and rebill those BOLs.

A logic should be written in such a way that during creation of invoice, the logic checks if all the line items have price and if all line items have price, it will allow the invoice to create. Else, it will error the invoice. This could be done by writing logic in function module CPE_CHECK_BILLING_BLOCK_SD if it is CPE pricing or using user exit RV60AFZZ by checking tkomk structure for specific base price condition types for all the line items and allow to create the invoice only if all the line items on the invoice have a price. User exit should trigger on both foreground and background invoice creation process and work the same way preventing invoices from creating that do not have price on all line items.

2. Gross/Net Requirement

Gross/Net requirement is a state mandated requirement and it is very important that the invoices are billed accordingly. Else, the customers would refuse the accept the invoice and pay and it would be out of compliance. For a gross state, if the invoice value is calculated on Net volume or vise versa will create difference in pricing as well. SAP provides standard settings to carry out the activity. Each condition type should be set to use the gross net rule in the configuration (Node: “Enter Data in Additional fields for Condition type”) to look at OIGNRULE. The table OICGN (Tcode: O3I4) provided is at the sold-to party level and not ship-to. However, one sold-to can have multiple ship-tos spread across multiple states or regions and some states could be gross mandated states (ND, SD, MN etc) and some would be net (CA, TX, AZ etc). Title can be transferred at the origin (plant region) or at the destination (ship-to). Hence OICGN sometimes needs to be modified to make sure the general rule will be overwritten.

The way the OICGN rule could be maintained would be, title transfer country/Title Transfer region/Ship-to number (instead of sold-to)/Validity and Gross Net rule. A modification logic is required in billing user exit to determine the right gross net rule.   The other way is to create a new table with more granular details (by addition other fields) and maintain the gross net rule. Create a routine to look at ship-to party. Assign this rule to each sold-to based on title transfer region. The rule based on the ship-to can give more flexibility but increase maintenance.

3. Payment Due Date Requirement

Payment due date requirement on the marketing invoice is sometimes unique. If the due date falls on weekends or holidays, then, system should automatically make it move to a weekday. One of the common requirements that comes up is, if the due date falls on a Saturday, then, move the due date to Friday and if the due date falls on Sunday move it to Monday. If it falls on a holiday, and if holiday is a Friday, move it to Thursday and if holiday is on Monday move it to Tuesday. One of the ways of dealing with this is to override the days on BSEG-ZBD1T (keeping base line date ZFBDT) in the user exit EXIT_SAPLV60B_002 to add or subtract days based on the rule. You will need a calendar to refer to and SAP provides standard function module to find what day of the week is the due date. Keep in mind that calendars can vary by country so, if the requirement is by country, then such modifications should be incorporated. This requirement could be applicable to commercial invoices as well depending on how companies deal with their customers. If this situation only applies to how the invoice is drafted, probably this could be achieved by setting up the dates on the payment runs so that it can automatically draft the invoice amount from the customer as required.

4. Invoice Transmission

One of the most important requirements of marketing invoices is transmission of invoices to its customers. Marketing invoices are usually very high in volume. Business wants to ensure the timely delivery of these invoices to customers so that they can collect the receivables on time. Below are some of the common requirements of marketing invoices transmissions (some of them are common for commercial as well). Having a complete view of all forms of transmission will ensure that all the requirements within the invoice are applied to all forms of transmissions.

• Email/Fax/Print – It is important to make sure that common form and driver program is assigned to all 3 outputs. This way, any change to the form and driver program will apply to all three modes of transmission. The transmission can be set to trigger from SAP. The other way of doing it is to make all the invoices go to a common place (like company portal for example) and trigger various mediums from there. However, then, the transmission will be handled by a different system and not in SAP.

• Company Portal – Company Portal is one of the most important ways of making the invoices available for the customers. There are various service providers available who provide portal service in the market. Portal for SAP S/4HANA is one of them. The transmission to the portal can be done in various ways like, using XML, RFC calls, Odata service etc. I am not a technical expert, but I have tried explain a few options that I have seen in my experience.

1. The first option could be to do a direct RFC call from the portal when the customer request to view an invoice. The portal makes RFC call to SAP and pulls all the invoice data, converts into Printable format and presents. The complication here is, the print driver program changes should match the RFC call data fetch and exact same data must be communicated to portal. Any small inconsistency could lead to invoice data mismatch between portal and SAP.


2. The second option is transmitting the required invoice to a middleware via EDI (invoice output to idoc) and the idoc is converted to XML in middleware and sent to Portal. Portal receives the data, stores it in its own tables and converts to pdf on demand. The disadvantages are too many conversions, portal should store the data in its database which could make it bulky and the print layout from SAP could mismatch with portal layout.


3. The third option is to store every invoice created in content management server like for example open text. It is SAP standard functionality to archive the invoice if required. The content management link should be created and it should be assigned to the archiving output. The archive invoice will use the same layout as print/fax/email. When customer requests for the invoice from the portal, a Odata service is initiated which picks the object from SAP and goes to content management and picks relevant pdf and presents it to customer (on the portal). Advantage, the layout and data on the invoice is very consistent with print/email/fax. Disadvantage is, both SAP and content management servers should be up and running and failure of one could result in invoice not being displayed.

• DTN – DTN or commonly known as Telvent DTN is a company which provides data transmission service to its customers. DTN as a company provides data transmission service with one of the services being invoice transmission to customer’s back office. By this, host companies can reduce their inhouse development cost and reduce dealing with every customer daily addressing invoice transmission issues. Usually company sends customer invoice in EDI format to DTN. This could be done once a day or at specific time intervals or as soon as each invoice is created. An EDI invoice file must be crated and transmitted. An output type is created to trigger the EDI. Standard user exit eXIT_SAPLVEDF_002 can be used for segment modification (as required). A middleware is engaged to transmit customer invoice to DTN. If the invoices are combined and sent at regular interval, it can be done using middleware as well.


• IATA – Aviation Invoices (JET customers) – International Air Transport Association (IATA) is trade association for world’s airlines. The agency represents about 82% (courtesy IATA website) of total air traffic. IATA has prescribed a specific format which all airlines and airline cargo companies use to receive and pay invoices. As refining and marketing business is a heavy supplier of Jet fuel to the airport as well as into wing, the invoice has to be generated in IATA specified format and transmitted to customers. Generally refining and marketing companies deal this in two different ways. One of the ways is to create a middleware to convert the EDI invoices to XML format prescribed by IATA and transmit to customer FTP sites. In this case, all required manipulation will be done in user exit EXIT_SAPLVEDF_002 to get what customer need. Also, as there could be multiple customers with this requirement, each one must be dealt individually. The other way of doing this is to send the aviation invoices to either DTN or IATA (IATA also provides invoice transmission service for a charge) and they would in turn transmit the invoices to the customer. Disadvantage for R&M company will have to pay for these services and may have to ask customers to pay for the service as well.

5. Print Requirements

• Price calculation – Sometimes, the base price on the condition type of the invoice is not what the company would want to show on the invoice. There could be specific requirements like on the invoice the base price should be displayed based on base price plus a few discounts and this could vary by customer or by customer group etc. As we cannot design pricing procedures just for a customer group or a customer, the print program modification of recalculating the base price would become a requirement. The logic should be written in the driver program and it is critical to manage the UOM conversions in the logic. As oil industry works on six decimal places on the invoice and usually customer require atlest 4 decimals on the invoice, the calculation logic on the invoice print program should be very accurate.


• Company Address – Companies always do not want to Print the name and address maintained T001 or ADRC tables. Instead they may want to be more descriptive or more selective on the company information that is being displayed on the invoice. One of the easier ways to deal with company address is to maintain them in SO10 (Standard Text) and retrieve on all print and EDI so that standard information is being passed on to customer and there is a central place to maintain


• EPA text and Material Text on the invoice – EPA (Environmental protection Agency) has mandated literature to be printed on every invoice based on the product being sold. The EPA text could vary by state and it is important to print those on the invoice else, the invoice is out of compliance. BRF+ tables or ABAP table could be crated and used for this purpose. A table with invoice state, validity period, material or material group and a specific text associated can be maintained. A function could be called to access this table and pick specific text and print. Similarly, there could be a requirement to print the material specific text in some states. This could be not to a specific material but for a material group. This could also follow a similar solution of maintaining an ABAP table or a BRF+ table for certain criteria and picked up during printing.

Conclusion

I have tried to highlight some of the common business requirements that can influence how the invoices are created for Marketing business in SAP. There are definitely many approaches in designing the solution, but the attempt here is to highlight those common requirements. Some of these solutions can be easily developed and maintained in the long run.