The 6th Man Principle

In the midst of watching the NCAA March Madness tournament, I was reminded of the 6th man concept that RSI has used since its early days. As in basketball the 6th man concept is all about having a ”non-starter” prepped, practiced, ready to enter the game and immediately start contributing to the team. This concept is core to RSI’s 6th Man principle. For many of our strategic accounts we deploy an extra colleague to participate in the upfront strategy and design sessions, kickoff meetings and daily stand ups so that when their time comes they will be prepared to hit the court at full speed. Their time may come due to an injury, an illness, paternity or maternity leave, or maybe just a packed sprint that needs the extra help. Whatever the cause we know that this 6th Man will be able to step in, run the offense and execute the game plan because they’ve been to all the practices. But wait, why would an enterprising, software development firm place a non-billable colleague onto a team? The rational is that it’s good for the client, good for the colleague, and in the long run it’s good for RSI. For the client it’s the assurance that they know there’s a backup waiting to get in the game in case something happens. For the colleague it’s a better use of “bench time” than creating a “make work” internal project or watching another PluralSight video. For RSI it’s a way to keep both clients and colleagues engaged and happy. As March Madness enters the Sweet Sixteen and Final Four rounds take notice of how those 6th man players ultimately impact the game and success of the eventual winners.

Three Steps to Optimizing SAP Application Performance

With each meticulous stroke of the keyboard, each piece of intricate code, each configuration or integration, and with practically everything that occurs as an application comes together, it’s important to think about performance. As an SAP Administrator I may be tasked with analyzing performance issues and helping developers find the root cause of performance degradation that can occur during development or when the code moves to production. Sometimes the performance issue is something simple that the developer simply overlooked. Sometimes the issue is deeper, such as an issue that is relevant to an SAP Administrator but not necessarily at the top of the priority list for a developer that is focused on their deliverable target date and related acceptance criteria. Performance issues may not be apparent to the developer until the application moves to production environments where heavy multi-processing results in competition for system resources. Integration with other applications executing in a production environment can also present a challenge. To optimize performance of an SAP application, I recommend the following steps be taken: Understand the purpose of the program and why it’s being built. Execute a trace of the program Analyze Results The first step that should be taken is to ask questions to analyze SAP performance issues, such as: Is it a new program? Is it a custom program? Is it an SAP delivered program? Has an OSS note search been conducted to determine if the issue is a known issue resolved by an SAP note? Does the program involve a web service? If so, which? Does the program only read data or write data or both? Has the program been recently modified? What tables are being accessed? Does the program run well in a test environment? Is the program one that is being modified? If the program is a modification of an existing program, additional questions arise such as: When did the performance issue begin? Is the performance issue consistent or sporadic? What time during the day or night does the program execute? Does the performance issue occur also in a test environment or only in production? Has validation occurred to determine the application is used with correct variants or user input? Does the performance issue occur only under specific circumstances? Is it possible the data being operated on has changed? The second step is to setup and execute a trace of the program. This involves the following steps: Arrange a time to have the program executed in the same manner that results in poor performance of the program (i.e variants, location, launch method, etc.). Using SAP Basis tools watch to see what tables are being hit and watch for patterns as the code cycles through the system Watch for multiple threads in case the application has been configured to use multiprocessing If multiple application servers are part of the production landscape look for related processes that might be launched on different servers Using Operating System tools that monitor memory, cpu and i/o and swap usage to determine if the issue relates to a lack of these system resources Check to see if database lock escalation occurs during the execution using SAP Basis tools or by looking at relevant logs The third step is to analyze the resulting trace: Determine which relevant SQL statements are consuming the most time Determine which tables are being accessed in the top duration SQL statements Generate an explain plan of the high duration SQL statements and determine if indexes are being used or if full table scans are occurring. Analyze the relevant table(s) and determine their size and what indexes exists for them and when they were last reorganized and statistics run. Compare the where clause of the SQL being analyzed with the index being used to determine if a new index might be warranted. Additionally, the SAP transactions STAD and ST03N are key performance tools that can provide valuable details on numerous metrics based on user, transaction or program. In the case of SAP, one must consider the effectiveness of tuning parameters at all 3 levels of the underlying computing infrastructure: Operating system Database SAP Additionally, performance of network and storage systems must sometimes be considered. SAP publishes recommended settings for tunable parameters for most major operating systems and popular databases that may have an effect on how well SAP performs. SAP also provides tunable memory buffers that can be monitored and the related tunable SAP parameters are identified making it easier to determine which SAP parameters may be in need of adjustment. As you can see, when it comes to performance of applications, there is a lot to consider in the analysis and each area above has its own path for mitigation. Performance should be taken into consideration as an application is being designed and coded and performance should also be a consideration during initial testing. Try to be thorough in building applications with consideration for the end user experience. No one likes to sit and watch the small circle spin or the screen seemly in a dead mode when an application is launched and the enter key is pressed.

How Healthy Is Your Salesforce Implementation?

No matter how good, or thorough your original implementation of Salesforce was, it will from time to time need maintenance or even periodically an overhaul. The good news is because it’s a cloud-based solution, Salesforce has your hardware health monitoring and maintenance covered for you. But you are not off the hook for everything: ●  Data quality, duplicates and other small errors can creep into the best designed systems. ●  Depending on the original architecture significate increases in data can start to create performance issues. ●  Salesforce has three upgrades a year that bring new features and subtle changes to the platform that should be reviewed. ●  Your business is constantly evolving and so requirements and business processes will change. ●  Incremental additions such as record types, validation rules, etc. can quickly get out of hand. It is not uncommon to want to rethink the overall architecture of your system based on changes in your business. Constant tweaks, field additions, workflows and approval process modifications added by the day to day administration for the system means the tool evolves away from its original implementation specification. Salesforce, like everything else unfortunately abides by the 2nd law of thermodynamics - everything tends toward disorder. There is perhaps a temptation to follow the adage “if it ain’t broke don’t fix it” or let your Salesforce implementation alone unless it starts to have issues. But this would be at the risk of ignoring another law that we all have experienced at some point, Finagle’s law of dynamic negatives, also known as Finagle’s corollary to Murphy’s law - anything that can go wrong will go wrong and always at the worst or most inconvenient moment. If your business depends on Salesforce then the last thing you want is to be caught by surprise when it starts to yield anomalies or errors that prevent you from running your business. Just as you should get your car serviced, or see your doctor once a year, so too should you have a strategy in place to give your Salesforce implementation a periodic health check. Some of these checks can be in the form of well-designed audit reports that can be run at set intervals to look for early warning signs of trouble. But eventually a full system check that reviews the entire implementation is wise because of: ●  The impact of increasing number of records (code that used to work can create errors later). ●  Salesforce governor limits - how close are you to exceeding them? ●  Salesforce release features. ●  Salesforce critical update implications. ●  Your organization's current structure. ●  Your organization's current business process requirements. ●  Security needs and it’s ever changing best practice. Some organizations may have the skill sets in-house to do such a review but many would be best served turning to specialists to complete such a task. It is the combination of skills required that makes this sort of task better suited to external help. No matter how accomplished your Salesforce internal team is, an independent and unbiased health check-up should be on your Salesforce to do list. Inaction will most assuredly lead to trouble. Proactive preventions will always be the more cost effective strategy so if you need any advice or help, give us a call.

Why Throwing More Bodies at Your IT Project is Not the Answer

A lot of companies find that competitive advantage comes with cutting costs and increasing speed to market. And that often works except if they’re launching a new IT project. This brings a new set of challenges, especially since the first reaction is to see who’s on staff who could do it. Throwing additional internal resources toward an IT project might not give you the competitive advantage you’re looking for. In fact, it could very well slow you down. The first potential impact is overextending staff by pulling them onto yet another project and moving their focus away from important, business critical tasks they were hired to do in the first place. Next, lack of expertise can become a roadblock. This can be costly when a project slows down due to errors or delays needed by staff to ramp up and learn something new. Another solution to consider is outsourcing because it can provide the flexibility and scalability that you need to innovate and get to market faster. Companies such as Basecamp, Squawker and Github, were created with outsourced development. Why? It’s smarter. The benefits of outsourcing are numerous. Let’s take application development as an example: 1. Experience – you’ll get the expertise you need, when you need it. Outsourcing means your development will be done by professionals who live and breathe development and are constantly learning and applying the latest IT trends to projects 2. Scalability – outsourcing allows you to rapidly scale up or down your development needs without the expense and long-term commitment of hiring additional full-time staff or overextending existing IT staff. 3. Efficiency – a team that is 100% focused on your IT project will increase your speed to market, getting the job done without spending unnecessary time and money on the development phase. 4. Reduced costs – increased efficiencies alone will reduce development costs but you’ll also reduce overhead costs and pay for the services you use, allowing you to save money during periods of low activity. The next time you’re faced with a new IT project with limited resources, you could save time and money by rethinking the reaction to simply throw more bodies at it and consider outsourcing instead.

Scrum Master Vs Project Manager: Different Roles, Different Individuals

A common misconception among those new to Agile software development is that the Scrum Master role is identical to the traditional Project Manager role. In reality, this is demonstrably untrue and differences between these roles is illustrated when we consider scope of influence and ownership. While there are some shared tasks and similarities between these roles, they are at their foundations, separate roles with incongruent fields of influence. A Scrum Master is a facilitator focused intently on a Scrum Team and its deliverables. The term facilitator is used specifically because the Scrum Master does not lead the team, dictate the work they will do, or the order that the work will be done. A Scrum Master’s role is one of support. Decision-making powers within the Scrum Team are decentralized; the Scrum Master facilitates conversations that lead to solutions. The Scrum Master coaches the team and the Product Owner in Scrum processes, but does not make standalone task level or feature decisions. Essentially, the Scrum Master is embedded within a Scrum Team and is responsible for the work that the Scrum Team develops and launches. In large projects with multiple Scrum Teams, a Project Manager is usually positioned to track the project as a whole, managing project timelines, budgets, contracts, and risk. In this position, the Project Manager is a leader, a decision maker and is empowered with dictating the priority of work, cutting/adding features and adjusting resources while the Scrum Master is concerned with budget, contracts, and timelines as they relate directly to the Scrum Team and their deliverables. The Scrum Master and Project Manager roles are both important in their own way. Each project is unique and as such, management should exercise careful consideration when creating staffing plans for non-development task owners. It may be that a project requires a Scrum Master to help facilitate execution, along with the dedicated contract negotiation skills of a practiced Project Manager. In this case, it would be preferable to have a Scrum Master who also happens to be a Project Manager selected for that role. Many times, the Project Manager and Scrum Master roles are staffed by different individuals to prevent overtasking and conflicts of interest that could break down the Agile process.

Where is Your Salesforce Journey Taking You?

A decade ago, Salesforce was a small, disruptive player in the Customer Relationship Management (CRM) space. What set them apart from their competition was that they were a Software as a service or SaaS. It was important to Marc Benioff (founder, Chairman and CEO of Salesforce) that this application be “clicks not code.” A solution that did not require infrastructure management and reduced the technical expertise that was typically required of companies to configure and set up CRM solutions. Today Salesforce accounts for over 18% of all global spend for CRM software vs around 12% for SAP, 9% for Oracle and 6% for Microsoft. With offerings that include a sales cloud, service cloud, marketing cloud, the Force platform and several other services, they’ve moved well beyond the realm of just a CRM tool. It’s now being used for HR solutions, recruiting, project management, agile management, vendor management and much, much, more. It’s hard to believe that organizations leave a lot of these new options untapped. Many companies are still using Salesforce to just run their sales, marketing or customer service centers, which is kind of like purchasing a membership to a country club. It’s REALLY expensive if you only used the club to play tennis, but it’s a great value if you utilize all of the club’s facilities such as golf, tennis, the pool and its other amenities. Likewise, if you’re paying for Salesforce licenses but only running your sales team in Salesforce then you’re not receiving your full return on investment (ROI). By carefully leveraging the variety of licenses that Salesforce offers, you can create a high-value, company-wide business management solution that, when developed correctly, easily integrates into other key systems like your ERP or back-end finance system. If you haven’t done so already, it’s time to review the costs of consuming and maintaining several different licenses that could potentially be absorbed by Salesforce. Ask questions like: how is your data quality? What does adoption look like? How efficient is your licensing plan? Etc. Take the time to analyze your current situation and consider developing a consolidation and architecture plan that maximizes the potential of Salesforce as well as your other corporate sub-systems. And remember, just because the implementation consultants have left, it doesn’t mean that the project is complete. On the contrary, it needs to be proactively managed because your Salesforce journey is really just beginning.

LIMS: Love It, Maybe Sometimes

For some, LIMS stands for Laboratory Information Management Systems but for others, it stands for Love It, Maybe Sometimes.... The pressure is reaching an all-time high for the pharmaceutical industry to lower prices, maintain a competitive edge, deliver products to market faster and operate in compliance with increasingly strict regulations. For years, pharmaceutical companies have invested in LIMS technology to help meet these goals, only to find that they must spend even more time and money to obtain the efficiency gains that prompted them to consider LIMS in the first place.  An article in Chemistry World reports that the software is usually around 40 percent of the overall cost of LIMS, but that helpdesk support, maintenance, configuration, integration, training and other consulting services makes up the remaining 60 percent. This is a significant cost that often becomes a roadblock on the path to loving LIMS. We found this to be a universal pain point facing lab managers and LIMS administrators. They had LIMS in place, but they weren’t fully maximizing its potential because they were spending a considerable amount of time on redundant work with extremely high manual labor expenses. That got us thinking – what if there was a customizable solution that would sit on top of any LIMS platform that defined and organized master data requirements? And what if the solution leverages object templates that are configured to your LIMS? Now there is a solution - LIMS Accelerator™, a tool that standardizes templates and facilitates use of automation to largely eliminate manual data entry and the transcription errors it causes. With LIMS Accelerator, resources can get back to the job of being lab managers and analysts, not data entry specialists. And they can get back to loving LIMS.

The Top 5 Reasons Your Company Should Go Agile

Agile development is not new. In fact, it’s been 15 years since the was created as an alternative to software development processes, such as waterfall. At this point, agile is not a passing fad and if you haven’t adopted it yet, 2016 may be the year. Here’s five reasons why: 1. It enables a faster time to market. Every business wants to get a new product to market as fast as possible especially when that product will help drive revenue. In contrast to the waterfall development approach, in which each phase of a project must be completed before the next phase can begin, agile development breaks projects down into smaller increments with short timeframes called sprints. Within each sprint product development occurs across the various phases simultaneously. This allows development teams to bring products to market much faster. The resulting product does not need to reach its full functionality or include a complete set of features before being released. Development teams put effort on specific functionality during each sprint, setting short time periods during which work is to be completed and made ready for review. This allows for the release of software more frequently and with greater focus on the features and functionality that will deliver the highest return on investment and/or are most critical for the business. 2. It allows for continuous improvement. Organizations are always looking for the best software development method, but implementing a new process or tweaking an existing process can have a big impact on the business when sequential development approaches, such as waterfall, are employed. Agile development makes it possible to continuously improve processes, which in turn drive efficiency. You will be able to identify inefficiencies and improve processes within each sprint because Agile’s short development cycle allows development teams to try new approaches and ideas while they are developing, leading to innovation and improved efficiency. 3. It is user focused. You want to bring products to market that users want and need, right? At the end of the day, these products drive your business in more ways than one. Bringing products to market more frequently and in shorter intervals means that you can iterate and improve quickly based on customer feedback. In this regard, development becomes more user focused and considers direction from the end user. And when those changes need to be made, the shorter agile development cycle means you’re able to get valuable feedback early in the project and make additions or changes in the next sprint. 4. It’s flexible. Unlike traditional software development methods, Agile allows you to better adapt and meet changing needs. This eliminates getting to the end of a long development cycle only to realize the product you have created does not meet your current business needs. 5. It drives transparency. Frequent communication between the development team and the business helps discover issues and other challenges early, providing opportunities for quick resolution. In contrast, a lack of transparency makes it difficult to adjust to changes, keep track of the work being completed, and identify and eliminate potential roadblocks. Transparency helps the team make sound, informed decisions and keeps projects on track. More and more businesses are realizing that with Agile development comes tremendous benefits. In today's fast paced, competitive business environment, Agile can help drive your software development efforts to realized business success.

LIMS Support Best Practices

In "Built to Last," author Jim Collins builds the case that companies should focus on their product (or their purpose). That is to say, a company should “be a clock builder, not a time teller.” Within the life sciences industry, supporting LIMS and other scientific data quality systems typically falls within the responsibilities of several organizations with differing charters and motivations. In Collins’ words, they are “time tellers,” in that support for these systems is not their organizational “main thing.” There has been an increasing trend of outsourcing these support tasks, allowing the company to shift focus back to their ultimate purpose of R&D, sales and manufacture of quality product. Support for a LIMS entails many important disciplines, including infrastructure, low-level and advanced technical support, master data implementation, enhancement and support for investigational activities. These areas are disparate in their resource needs, ranging from the IT-centric infrastructure support to the scientific technical master data and investigational aspects. Because of the varied nature of these tasks, a LIMS support organization is frequently split across IT, R&D, quality control and quality assurance organizations. Furthering the challenge are geographical and language constraints as LIMS systems are deployed on a harmonized basis across organizational units and manufacturing sites within companies. Being effective as a support organization can be viewed in two ways. The first means of being effective is providing for the needs of the users of the LIMS, a straightforward goal. The second dimension of effectiveness is being aligned cost-wise with organizational needs. From RSI’s experiences building and maintaining support organizations within the space, the following points have been identified as best practices: Begin with the end in mind. Understand the parameters involved in support by identifying the stakeholders, organizational involvement, current resources and cost considerations. Foster a sense of accountability. Support organizations that “sit” under a single organization are more effective in delivery and avoid the support gap that can be present when multiple groups are involved in support delivery. If multiple organizations are involved in support, clear definition of roles and responsibilities is critical. Structure centrally. Aligned with the trend towards harmonized LIMS systems and data, a LIMS support organization built centrally for an organization or organizational unit can significantly lower the total cost of support for a system by leveraging work across the unit and sharing of pertinent and relevant information such as reports and master data. Employ Agile Support Practices. Using Agile support practices shows a demonstrable benefit in several ways. By employing systems such as Kanban, visualization in the priorities and current status of the support team are readily apparent, especially across geographical or physical locations (using excellent tools such as Trello). Deliver frequently. A support organization is trusted by their stakeholders when they are able to frequently deliver upon their promises. Delivering frequently, as opposed to coalescing large releases or enhancements, may seem counterintuitive in a quality-oriented field. By delivering “smaller,” stakeholders are able to more quickly get value for the support effort and quality verifications can be more focused and accurate. Define success and measure against goals. Defining what a success is, whether it is codified in service level agreements, or a less-formal approach, is important to any support organization. Established what success means allows the support team to be measured against criteria, and is a lever for making changes to the approach, team or strategy if goals are not being met. Editor's Note: This blog was updated from its original post.

Your Team’s Not Agile Unless You Are Doing Agile Testing

For many software testing professionals experienced in traditional development processes, working in an Agile project can be a foreign concept. Testing in older development models often only takes place near the end of a major development phase by a team of dedicated testers. As a result, test phases can be seen as a bottleneck since a multitude of bugs can be (and most often, are) found when QA analysts start looking at previously untested software. In order to meet deadlines, testing phases may be shortened or eliminated altogether, resulting in increased numbers of potentially severe issues at worst, or increased customer support workload at best. Utilizing Agile development practices can alleviate these problems by integrating testing throughout the development process, allowing for a higher quality application. Agile processes can seem chaotic or time-consuming at first, especially if the team is unfamiliar with or still adapting to the shift in thinking required. Whereas traditional development cycles will have a definite start and end, Agile projects are often treated as a continuous endeavor made up of iterations, or sprints, which often last around two weeks. Team members decide on what issues or functionality they will deal with in each iteration, and once that sprint is finished, the next one begins. Testing is not performed in only one phase of the process, but is integrated into each phase to varying degrees, starting as soon as code is created. Members of an Agile team are often expected to utilize different skills, so it is not unheard of for developers, stakeholders, and other roles to perform some types of testing duties along with the QA team. Testers should be well-versed in a variety of testing tools and techniques. Commonly, testing will be exploratory in nature, but understanding how to perform acceptance, UX, load/performance, and even unit testing can be beneficial in an Agile project. Since regression tests can become burdensome over time, many teams implement some form of automated testing. In order to decide whether to add automated tests to a project, team members should weigh the time spent on regression testing against the time that will be spent maintaining the automated test scripts, which can become a problem if the system changes too much, too frequently. Agile processes are not flawless. Acceptance criteria can change unexpectedly based on stakeholder feedback, and a lack of documentation can create knowledge gaps for the team. Luckily, these types of problems can be avoided if Agile methodologies are properly used. Continuous communication between team members, along with having everyone as involved as possible in each step of the process, can reduce communication issues and help the team to be more adaptable to any changes that can come up. Understanding the nuts and bolts of a system or application and how it should behave under certain conditions is essential to any testing efforts, and with the continuous testing integration that Agile methodologies provide, that type of understanding can be achieved with relative ease.

Display Custom Fields In The Header Area of FB60 and FV60

Some SAP clients need extra information added in to a standard SAP process. Here we’ll explore how to add custom fields in the header areas of t-codes FB60 and FV60. FB60 is for posting vendor invoices and FV60 is for parking vendor invoices. In this sample, we’ll be adding in two custom fields. From research, I found that BAdi BADI_FDCB_SUBBAS01 would work for the initial requirement. I decided to use BADI_FDCB_SUBBAS04 since some of the 01,02s are used by SAP. Go to t-code SE19 to create a BAdi implementation. It’s a classic BAdi rather than a new BAdi. Choose a name and click change. It will ask you to create it and give it the name of the BAdi, which we’d put BADI_FDCB_SUBBAS04. We get a screen that tells us the two methods that the BAdi has and the name of the implementing class. The methods should be double clicked and each filled in as follows: method IF_EX_BADI_FDCB_SUBBAS04~PUT_DATA_TO_SCREEN_OBJECT. * fill interface attributes from importing paramters me->if_ex_badi_fdcb_subbas04~invfo = im_invfo. endmethod. method IF_EX_BADI_FDCB_SUBBAS04~GET_DATA_FROM_SCREEN_OBJECT. * fill export parameters from interface attributes ex_invfo = me->if_ex_badi_fdcb_subbas04~invfo. endmethod. On the subscreens tab, we define a program and screen call based on screen 10 since it’s for Vendor Basic Data and we’re adding to vendor screens. We then must activate the BAdi implementation so that in the Runtime Behavior section, it says Implementation is called. Note: at this point, it will not work. You need to add your new fields to BKPF, VBKPF, and BSEG via append structures. For BKPF, you open the table in SE11. You then click the Append Structure… button at the top and the appends for BKPF will show up. You then click the piece of paper at the top to create. It will ask you to name your append structure. You fill out the short description, the z fields, give it an enhancement category, and activate. If everything works fine, it will say active. Do this for all three tables. At this point, it will still not be working. We still have to create our program and screen. Create a program via SE80 and create a custom screen for it. Create the screen however specified and then fill in the flow logic. Note: In PAI, you must put each field that you define after FIELD: You may wonder how INVFO has these fields, and that’s because it’s also enhanced when you add the append structure to BSEG. On the main program, you’ll fill out all the modules and create some data definitons: REPORT zf_vendor_invoice. ************************************************************************ * T A B L E S * ************************************************************************ TABLES invfo. ************************************************************************ * D A T A D E F I N I T I O N * ************************************************************************ DATA: o_bad TYPE REF TO if_ex_badi_fdcb_subbas04. *name of the badi reference *----------------------------------------------------------------------* ***INCLUDE LZF_VENDOR_INVOICEO01 . *----------------------------------------------------------------------* *&---------------------------------------------------------------------* *& Module STATUS_9200 OUTPUT *&---------------------------------------------------------------------* * Create a subscreen object and get data from the screen *----------------------------------------------------------------------* MODULE status_0100 OUTPUT. CALL METHOD cl_exithandler=>get_instance_for_subscreens CHANGING instance = o_bad EXCEPTIONS no_reference = 1 no_interface_reference = 2 no_exit_interface = 3 data_incons_in_exit_managem = 4 class_not_implement_interface = 5 OTHERS = 6. IF sy-subrc <> 0. * MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO * WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4. ENDIF. * object created ? CHECK NOT o_bad IS INITIAL. * get data from main screen CALL METHOD o_bad->get_data_from_screen_object IMPORTING ex_invfo = invfo. ENDMODULE. " STATUS_9200 OUTPUT *&---------------------------------------------------------------------* *& Module USER_COMMAND_9200 INPUT *&---------------------------------------------------------------------* * Put data into the screen *----------------------------------------------------------------------* MODULE user_command_0100 INPUT. CHECK NOT o_bad IS INITIAL. * put data to main screen CALL METHOD o_bad->put_data_to_screen_object EXPORTING im_invfo = invfo. ENDMODULE. "user_command_9200 INPUT *&---------------------------------------------------------------------* *& Module RECEIVE_ACTUAL_DATA INPUT *&---------------------------------------------------------------------* * Get data from screen *----------------------------------------------------------------------* MODULE receive_actual_data INPUT. * object created ? CHECK NOT o_bad IS INITIAL. * get data from main screen CALL METHOD o_bad->get_data_from_screen_object IMPORTING ex_invfo = invfo. ENDMODULE. " RECEIVE_ACTUAL_DATA INPUT *&---------------------------------------------------------------------* *& Module CHECK_TCODE INPUT *&---------------------------------------------------------------------* * check the t-code – We want it to show up for FB60 and FV60, but * hide it for any other screen that hits this enhancement *----------------------------------------------------------------------* MODULE check_tcode OUTPUT. IF sy-tcode <> 'FB60' AND sy-tcode <> 'FV60' AND sy-tcode <> 'FB03'. LOOP AT SCREEN. IF screen-name = 'INVFO-ZZE_DAT' OR screen-name = 'INVFO-ZZE_LOC' OR screen-name = 'DATE' OR screen-name = 'LOCATION'. screen-active = 0. MODIFY SCREEN. ENDIF. ENDLOOP. ENDIF. ENDMODULE. " CHECK_TCODE INPUT   Once this is activated, you will see the screen fields(Event Date and Event Location): You can also look at any document created and see those fields held in BKPF or VBKPF. Adding custom fields to many SAP screens follow the same procedure. Knowing how to do this will help you add value to your customer and provide them the ability to have some custom information added in to a standard process.

Sign up for our blog updates!