BBB stands for the commonly used acronym "Bookings, Backlog and Billings". It is a Sales Order and Revenue Reporting software solution for Oracle Applications that converts and simplifies transacted ERP data into business information, presenting business users with a fast, easy, and familiar way to access critical BBB information.

Yes. Our solution easily provides an executive level summary for Bookings, Shipments, Revenue and/or Backlog data for any period range all in one report or as individual reports.

Oracle Applications releases 10.7, 11, 11i, and R12 (all versions).

No. BBBi is integrated with Oracle Applications without interfering with any standard functionality. It reads Oracle base tables, but it only writes to BBBi custom tables. BBBi is designed to meet the CEMLI Custom Extension Coding Standards set forth by Oracle. It will not impact or violate your Oracle Support agreement or your ability to upgrade to future Oracle releases.

Yes.  BBBi's Booking Transaction History module tracks changes to order attributes in the Order Header, Sales Credit, and Order Line tables that impact order value. It may be configured to track changes made to ANY column in these tables. It comes pre-configured to track changes that affect order value in terms of change date and sales credit allocation.

Since Oracle Order Management does not maintain a sub ledger like history of all changes made against a sales order, changes merely overwrite the existing data. Thus an order booked on January 31st for $500, may be modified on February 7th to reflect an increase in order value to $1,000. Unfortunately, Oracle will assign the full $1,000 to January 31st, instead of properly allocating $500 to January 31st and $500 to February 7th. Without a history of changes, it is impossible to accurately determine net bookings for a period.

Yes. BBBi provides both product cost and margin data in reports and views. See our product page or more information.

No. Our solution is a real time data transformation and delivery mechanism that provides ready to use reports and views upon installation. It is integrated within your Oracle E-Business Suite instance, providing a layer of logic that translates your Oracle transactions and setups into meaningful BBB data. There are no additional hardware or software requirements, no complex setups, configurations, or interfaces to build. It's end user ready! Depending on your reporting requirements, BBB Intelligence can replace a data warehouse, be used to supplement a data warehouse, or feed a data warehouse.

Yes. BBBi is integrated with Oracle E-Business Suite.  You can access BBBi data in EBS (OAF) browser pages or ProView BBBi pages.  BBBi provides database views that any Oracle Database browser-based reporting tool could access.

Yes.  ProView BBBi pages provide drill down and links from summary to detail data. Also, BBBi’s database views are ideal for use with elaborate reporting and query tools, like Oracle Discoverer. These user friendly reporting utilities support drag and drop report building with easy to use drill down, sort, filter, matrix, chart and role capabilities. They usually provide spreadsheet like results that can be easily exported to Excel.

No. We have done rigorous performance testing on our solution. In a simulated production test environment where we created and/or updated over 1,400 orders in one hour, we were unable to detect an impact on performance. As for space concerns, our booking transaction history table typically usually has 1.1 to 1.3 times the number of rows in your order lines table. Since it contains significantly fewer columns than the order lines table, it usually remains smaller in physical size than the order lines table. Our customers have never had transaction history performance or disk space problems.

Yes. BBBi provides all currency values in the functional currency (that is the currency tied to the Set of Books for that operating unit) and the transactional currency of a given order.  BBBi creates individual views for each Set Of Books, as well as an “All” view that spans the entire enterprise. You can also designate a global currency into which to translate the functional currency values, which greatly simplifies using BBBi data for timely enterprise-wide operational decisions.

Yes. BBBi supports both Descriptive Flexfields and Key Flexfields, providing filter, grouping, and sorting options by Sales Territory, Item Category, GL Account, and other columns. The output is provided in two formats: 1) as a single string of concatenated segments, and 2) as individually named segments. This provides maximum flexibility to access and present data.

BBBi resides within your E-Business Suite database. It includes tables, views, database functions, procedures, and triggers. At the core is a layer of PL/SQL code that dynamically generates the database objects required to interpret Oracle transactions and configurations, and to output the translated data via views, reports, and forms for presentation to the user. BBBi is registered as an Application within the Application Object Library. ProView is delivered as an Oracle Application Express application, with an optional BBBi module.  ProView for BBBi includes a set of browser pages for interactive reporting.

It is integrated within Oracle Order Management. Forms are accessible from within your standard menus. Our database views are available for use with SQL*Plus and other tools, or may be used within custom reports, forms, or programs to ensure data accuracy, consistency and speed custom development. Additionally, the views provide an excellent mechanism for end users to retrieve critical BBB data using any number of query tools, such as Oracle Discoverer, Brio, or Business Objects.

BBB Intelligence is completely written with native Oracle software development tools: PL/SQL, Oracle Reports, and Oracle Forms. Thus, it integrates seamlessly within the Oracle Applications and requires no additional expertise to support. Your Oracle Applications IT staff will require no additional programming knowledge to support our solution. And, the solution follows the Oracle CEMLI (customization, extension, modification, localization, integration) guidelines for custom extensions. ProView for BBBi is a set of pages delivered in ProView, which is an Oracle Application Express (APEX) application, also integrated with Oracle E-Business Suite.

Noetix Views: BBBi is similar to Noetix in that we both offer database views that simplify complex relational database structures into simple business meaningful views that end users can easily understand and use without SQL knowledge. However, our solution is designed to be a complete Book to Bill revenue reporting solution. It provides ready to use reports, so no other software knowledge is necessary. Where Noetix provides a broad range of views spread horizontally across all the Applications, we provide a more vertical and comprehensive focus on Sales Order and Revenue Data. We also provide Sales Order Audit History, where we actually capture and report changes to sales orders in our transaction table. You can't calculate accurate historical bookings and backlog without it! Oracle Discoverer: Discoverer is a query tool. It requires implementation, SQL programming and setup by experienced technical staff. It is often used with database views, so that end users can access and run queries. It does not provide any intelligence as far as how to write, access or interpret the complex relational structures that exist in the database. For this reason, some of our customers use our pre-defined BBB views with Discoverer to provide their end users with a flexible way to access accurate BBB data. It only takes a few minutes to import and begin to use our views with Discoverer. Business Objects: Business Objects is like a combination of Noetix and Discoverer. It's a user friendly query tool that also provides general views for business purposes, but does not provide comprehensive BBB data or Sales Order Audit History. Users and IT staff will typically have to write and/or modify the base Business Objects views to meet their requirements. Essbase: This is a data warehouse with an OLAP front end. It's a powerful analysis tool if you plan to build your own interfaces and logic from Oracle, you don't need real time data, and you have a large budget and 6 months or more to deliver a solution. Brio: A reporting/query tool that facilitates building SQL queries using a GUI, drop and drop front end. It provides no transformation logic and no Order Audit History capabilities.

Yes. BBBi is integrated with Oracle E-Business Suite.  You can access BBBi data in EBS (OAF) browser pages or ProView BBBi pages.  BBBi provides database views that any Oracle Database browser-based reporting tool could access.

Yes.  ProView BBBi pages provide drill down and links from summary to detail data. Also, BBBi’s database views are ideal for use with elaborate reporting and query tools, like Oracle Discoverer. These user friendly reporting utilities support drag and drop report building with easy to use drill down, sort, filter, matrix, chart and role capabilities. They usually provide spreadsheet like results that can be easily exported to Excel.

BBBi resides within your E-Business Suite database. It includes tables, views, database functions, procedures, and triggers. At the core is a layer of PL/SQL code that dynamically generates the database objects required to interpret Oracle transactions and configurations, and to output the translated data via views, reports, and forms for presentation to the user. BBBi is registered as an Application within the Application Object Library. ProView is delivered as an Oracle Application Express application, with an optional BBBi module.  ProView for BBBi includes a set of browser pages for interactive reporting.

BBB Intelligence is completely written with native Oracle software development tools: PL/SQL, Oracle Reports, and Oracle Forms. Thus, it integrates seamlessly within the Oracle Applications and requires no additional expertise to support. Your Oracle Applications IT staff will require no additional programming knowledge to support our solution. And, the solution follows the Oracle CEMLI (customization, extension, modification, localization, integration) guidelines for custom extensions. ProView for BBBi is a set of pages delivered in ProView, which is an Oracle Application Express (APEX) application, also integrated with Oracle E-Business Suite.

You can use the SoD Policy Manager screen to set up function conflict policies, document the controls, and assign exemptions to users.  Since you create the function access policies using lists of values and seeded look-ups in an online form, it is easy to create and manage your own rules. ProView’s Segregation of Duties Violations Manager (SoD VM) module adds capabilities to define function conflict policies and function groups using online forms with lists of values and seeded look-ups, too.  You can also upload spreadsheet data using a file upload or copy/paste technique. An SoD and SOX analyst at one of our customers was given a conflict list by their PWC auditor.  She expanded on that, and created a spreadsheet of conflict pairs, which was imported into SoD VM.  She then had SoD conflict definitions that her company and the public auditor agreed on, and was immediately able to analyze user SoD access violations.

The user lists are named sets of E-Business Suite (EBS) Users.  You can use the lists in Application Auditor (AA) to make audits more selective, and to filter audited transactions.  In Segregation of Duties Violation Manager (SoD VM) you can use the lists to limit the scope of the access violation snapshot. In AA, they let you take a closer look at what a set of users do, while ignoring the rest.  You can also reverse the logic, and ignore what a few users do, but audit what all the other users do. In both cases you are refining the selection criteria for when AA will respond to an audit event.  Thus your controls are more targeted and exception-based. In ProView for Application Auditor, you can use user lists to filter audited transactions.  This is a reporting convenience, and it is dependent on the users in the set at reporting time.  The filter can include or exclude the users on the list. In SoD VM, you can create a snapshot of user access violations for the users on a user list.  For example, you might want to see the violations for several of the accounting staff.

There are no technical reasons why you could not add any Absolute Technologies product to your hosted environment.  It depends on the arrangements you have with your service provider.  We will assist you in discussions or deployment if you want us to work with them.

There are no special considerations with deploying AA on the database for your 11i or R12 environment, or for when you upgrade from 11i to R12.  There may be situations where you need to recompile or reconfigure the audit configurations or transport them from one EBS database instance to another.  AA’s user interface supports these compilation, configuration, and transport activities.

Yes.  Application Auditor can be used for these E-Business Suite releases: 10.7, 11.0, 11i, and R12 (all current versions) running on an Oracle database version 9i or greater.

Yes.  The SOX Pack of 90 seeded audit configurations includes these types of tables.  The audit trails will track the before and after values of relevant columns, reference data, and also user and session information.

Yes, AA can write the audit trail in any table in the current database instance.

First, you can configure the audits from multiple audited tables to be written to one or more audit trail tables.  We believe it is easier to have a single audit trail table, for easier operations and to have a single source for reporting.  However, this it is a customer decision at implementation time.  Of course, you could change at any point; you’re not locked in. The audit trail table stores all change details from all of the related audited tables for efficient and flexible reporting:

• Column Before and After
• Table Primary Key columns and values
• Table and Column names
• Trigger Action (Insert, Update, or Delete)
• When the column changed and Who changed it
• Session Details like IP Address, OS User, Session ID, and Commit ID
• Other column values within the same table at time of change, for context
• Selected data values from other tables captured at the exact time of the transaction, again for context.  An example is where you audit an order, and save the Customer ID from the audited table, but look up and also store the Customer Name from the Customer Master table

Oracle E-Business Suite does not include built-in GRC controls.  Customers need to develop their own controls or use software from Oracle or independent software vendors. You might find Oracle’s offering provides more capabilities than your requirements, at a price that can’t be justified, and take too long to implement. Oracle’s GRC Controls Suite is licensed separately from the E-Business Suite.  The four components are:

• Oracle Applications Access Controls Governor
• Oracle Configuration Controls Governor
• Oracle Transaction Controls Governor
• Oracle Preventive Controls Governor

SOD Violations Manager and Application Auditor provide the automation capabilities to support the above functions in your E-Business Suite environment: User access controls; setup and configuration controls; business transaction controls.  AA also gives you the ability to prevent any kind of user access, configuration, master data or business transaction. AA provides additional capabilities:

• It can be used to audit what DBAs and System Administrators do with the EBS database (DDL auditing).
• You can use the table auditing features on any Oracle Database, not just E-Business Suite.
• AA automates audit configuration migration and revision control, so you don’t have to re-key your business rules and you’ll always be able to fall back or review historical configurations.

We usually provide a small amount of fee-based consultative support in how to use the software when you first license the software.  Note that we are not SOX or financial controls advisors, so you may want to contact people who specialize in those areas or we can refer you to a specialist with whom we have worked.  When you decide what you want to accomplish in terms of controls, then we can easily guide you in how to accomplish that using AA and SOD VM.

We believe it should be easy.  Installation, testing, and deployment are straightforward.  We have a document about the typical deployment project to which you may refer. There are parts of the implementation project that will depend on the customer:

1. Selection of which tables to audit.  Our SOX Pack of 90 seeded audits for EBS makes this task easy.  You simply select which of the 90 make sense for your environment, and review other tables you may additionally want to audit.  Estimate less than one hour to develop, test, and deploy an audit configuration.
2. Our 1200 seeded conflicts simplify the task of selecting which function pairs cause an SOD conflict.   For any additional conflicts assume it takes a minute or so to add a new pair.
3. Deciding who should be on any user watch lists, and whether a list should be a white list or black list.
4. When you first report SOD conflicts, there may be a large number.  There are different remediation actions depending on your interpretation of the conflict and whether it is an Intra- or Inter-Responsibility conflict.

Application Auditor (AA) allows you to: select Oracle database tables to audit, configure the selection criteria and configure before and after data from the table being audited.   You can capture all information, including data from related tables, and report all your audit configurations.  The audit mechanism can also send email notifications and perform custom actions.  You can also create an audit configuration to prevent a database transaction and record the attempt in the audit history table. AA’s audit mechanisms and reporting are more suited to business and finance auditors than many audit capabilities that are more technical in nature.   The term “audit” is frequently used to describe software features that typically are used to instrument an application so you can debug it, or track workload.  The standard database “audit trail” mechanism’s main purposes are for fault recovery and supporting parallel instances, not for business or financial auditing. AA’s audit mechanism and business auditor user interface are the foundation.  By adding seeded configurations for E-Business Suite tables, we have been able to give EBS customers a head start in deploying SOX controls. Similarly, the audit mechanism makes it easy to refer to SOD VM’s SOD conflict definitions in real time.  You can detect changes that would create, or do create, user SOD access violations.  Such changes include user responsibility assignments and structural changes to responsibilities and menus. Finally, the audit mechanism can refer to user lists to further refine how you implement SOD or transactional audits.  You can use the user watch lists as either white lists or black lists, which provides flexibility.

Yes, you can upgrade.  When you add AA, you can detect changes that would create user SOD access violations in real time.  You would also get AA’s additional transaction audit capabilities.

Use SOD VM to deploy your Segregation of Duties policies.  The intent of SOD policies is to prevent individual users from having sufficient application access to enter two transactions that are incompatible from a financial controls standpoint.  Where that might not be practical, use AA as a compensating control to review transactions after the fact. SOD VM is the framework for implementing SOD policies and reporting policy compliance in an EBS environment.  It reports user SOD access violations.  AA captures a permanent record of selected transactions, so you can review them for compliance with SOD policies or other purposes. SOD VM provides snapshot reporting of user SOD access violations.  AA, when used with SOD VM, allows you to detect changes that would create SOD violations.  You can configure AA to allow or prevent the changes, and report the fact or the attempt in real time, so you don’t need to wait until the next SOD VM snapshot to detect user SOD access violations. It is possible to use SOD VM and AA individually or together, depending on the requirements.

Application Auditor has no impact on normal E-Business Suite operations, patches, or upgrades. Patches and particularly upgrades may generate large numbers of database transactions that your AA would audit.  If you decide that patch and upgrade audit trails are not necessary, you may temporarily disable AA’s audits at the click of a mouse and re-enable them after any the patch or upgrade, or any non-standard DBA activity. However, AA has identified undesirable activity performed by patch scripts.  You may find AA effective in preventing or highlighting patch issues.

If you think that the problem is related to Application Auditor or its extensions, please contact us.  We will help you isolate and define the problem.  When you contact Oracle, they may require you to recreate the problem and you may need to disable or remove the Application Auditor database triggers to help isolate the issue. This is the normal problem solving process with any ISV software component or CEMLI (customization, extension, modification, localization, integration). However, your audit configurations will not be lost and you will be able to easily re-create your audit triggers with the click of a mouse.

No, and our customers have not required such certification.  AA was developed using standards and guidelines Oracle recommends for extending the E-Business Suite.  It also uses standard Oracle technology.

Our customers go through the usual change management testing processes, usually an abbreviated version.  It is possible to test all the AA functionality in a few days, and we are happy to review your testing plan. If in the production environment your other controls are working, and no transactions take place that would be subject to audit, then AA doesn’t have much work to do or report.  One customer occasionally injects transactions that trigger audits in production to see that AA is still working.

These are the roles and levels required for a typical Application Auditor implementation and deployment.  A single individual can fill multiple roles based on their skills and the extent of support from Absolute Technologies.  This table comes from our Implementation Project Overview document.

Organization	Project Role	Required Knowledge and Skills
Customer(may include Customer’s consultants)	Project Manager (PM)	Experience in Oracle Database-based software product implementations.Coordinate and monitor project from initiation through production and post-production monitoring.Serves as liaison between Customer and Absolute Technologies.
	Business Audit Lead (BAL)	Experience in the areas of public accounting, internal auditing or consulting.Advanced understanding of Oracle E-Business Suite, business processes, related IT controls like SOD , and Application configurations.Some understanding of Oracle Database and Oracle Discoverer (or other reporting software) is helpful.
	System Administrator (SA)	Experience in preparing hardware, disk space, and logons for enterprise software deployments.
	Database Administrator (DBA)	Experience in the E-Business Suite and deploying enterprise wide software.
	IT Business System Analyst (BSA)	Experience with the E-Business Suite User Responsibilities and Menus
Absolute Technologies	Consultant	Detailed knowledge of Application Auditor installation and configuration. Scope includes technical software installation, determining with the Customer the best configuration of audited tables, alerting mechanism, user watch lists, and informal user training.

Yes. AA dynamically generates PL/SQL code to create a trigger and procedure combination that will track changes to selected columns of any table you specify.  AA’s Admin module also uses system triggers to audit database connections and DDL transactions.

No. All you need to do is use the Migrate/Copy feature to move an audit configuration from one instance to another, or from one revision to another. A valid database link must be maintained for this purpose. Alternatively, you may use AA’s Export/Import feature, which enables you to download/upload a copy of your audit configurations to/from a configuration file. Once you have copied the configuration file to a remote instance, you import it into the AA environment.  Whether you use a database link or a configuration file, you must compile the audit configurations to activate the triggers in order for them to begin creating the audit trail.

Yes. Via the online forms, you can enable or disable the audit.

AA delivers robust error messaging and error handling via online forms. You may contact support for a quick evaluation and explanation.

Not in this release, but it is a simple matter that we have provided on a services basis.  It will be added to a future release based on customer interest.

The Oracle database does not support directly auditing tables owned by SYS.  But any other table in the database can be audited. For more information regarding Auditing the DBA.

Release 9i and up are supported by the audit engine. However, the user interface requires Forms and Reports 6i or greater.

Yes and No. It is designed to work with any Oracle Database, not the E-Business Suite in particular.  However, it may be installed into the same database instance as the E-Business Suite.  AA may be purchased with extensions and auditor-reviewed seeded content designed for E-Business Suite, which support SOX and SOD audit functions. Additionally, AA has several default configuration features such as capturing the EBS FND User name and Responsibility in use when a transaction occurs.

You might find that EBS’s audit trails are limited in functionality and reporting in comparison to AA. The System Administrator audit trail feature is part of the E-Business Suite, and there are no extra licensing fees.  It creates a table and view combination for each table you audit, which makes it difficult to create a single report that provides all audit transactions.  The audit record does not contain before and after values, additional reference table data or session details, and it does not provide an easy way to take inventory on all your audits. It does not provide for DDL or database connection auditing. Application Auditor captures all audits in a single table regardless of how many tables you audit.  And, it provides comprehensive reporting on all audits defined.  Additionally, AA can collect information about a transaction that is not available with the Oracle Application audit trail feature.  For example, it can capture before and after values, and session details such as the TERMINAL of the user making a change to the record.  It can also run a user-defined simple select statement at the time the column value is changed and store the result in the Audit table. AA’s included Admin module provides DDL and database connection auditing.

AA derives the FND User Name using an EBS function that captures the value from the database session that initiated the transaction. This value is to be considered extremely accurate and reliable. The last_updated_by value is captured from the LAST_UPDATED_BY column in the table being audited. This column is usually populated by the form, page, concurrent program, or other logic that initiated the record change, however it is not automatic and relies on the programmer of that code to have followed the Oracle Development standards and guidelines.  Thus, this value is not a reliable indicator and is actually incorrect a small percentage of the time. However, when these two values clash, it could also be the result of someone making changes from the back end with a SQL utility or a customization and forgetting to set the last_updated_by column.

The technical installation, implementation, and deployment take only a few person days of effort.  Customers usually take between 2 – 4 weeks elapsed time, simply because the few people involved usually keep performing other work during the project.  It is really customer dependent.

Segregation of Duties Violation Manager (SoD VM) for Oracle E-Business Suite (EBS) is a cost effective Segregation of Duties user access controls solution. SOD VM unravels EBS's complex access model so you can see who has access to what capabilities.  Once you define conflicting capabilities, SOD VM targets user access violations, across roles, responsibilities, business groups, ledgers, operating units, menus, functions, and forms.

It takes just a couple of hours to install Segregation of Duties Violation Manager (SoD VM).  It’s ready then to analyze user access in E-Business Suite (EBS) according to the seeded function conflict definition policies and report user SoD access violations.  Developing a custom set of conflict definition policies could take several hours to a few days.  In situations where our customer already has detailed policy guidelines from their auditors, we have translated them into SoD VM function conflict definition policies in a day or two.

Yes;  Segregation of Duties Violations Manager (SoD VM) is equipped with risk adviser reviewed function conflict policies covering financials, manufacturing and human resources modules.

You can use the SoD Policy Manager screen to set up function conflict policies, document the controls, and assign exemptions to users.  Since you create the function access policies using lists of values and seeded look-ups in an online form, it is easy to create and manage your own rules. ProView’s Segregation of Duties Violations Manager (SoD VM) module adds capabilities to define function conflict policies and function groups using online forms with lists of values and seeded look-ups, too.  You can also upload spreadsheet data using a file upload or copy/paste technique. An SoD and SOX analyst at one of our customers was given a conflict list by their PWC auditor.  She expanded on that, and created a spreadsheet of conflict pairs, which was imported into SoD VM.  She then had SoD conflict definitions that her company and the public auditor agreed on, and was immediately able to analyze user SoD access violations.

The static Segregation of Duties (SoD) controls report all existing user SoD access violations when you run a Segregation of Duties Violations Manager (SoD VM) violation snapshot.  The dynamic SoD controls detects individual transactional changes that create violations when they happen. A report that provides a snapshot of who has access to what, and whether they have access to conflicting functions at the time of report submission, is an example of the static control.  An email that  announces an application menu change that created an access path for twelve users to a defined function conflict is an example of the dynamic control. Whether you need one or the other or both depends on your risk assessment and the corresponding need to mitigate that risk with automated controls.  Consider:

• Static SoD will not tell you if someone acquired access to conflicting functions, actually used both, and then removed the access to the conflicting functions before the next report.

Dynamic SoD controls, as implemented in Application Auditor (AA), are based on real-time trigger-based auditing.  They will tell you when a conflicting User-Responsibility assignment is made, or when a Responsibility or Menu is changed such that conflicting functions can now be accessed via a single Responsibility.    These SoD controls are about user access, which is the potential to perform conflicting functions.  Neither the static or dynamic control tells you the actual performance of both functions. However, with AA’s configurable trigger-based table auditing, which is also dynamic, you can create compensating controls that detect when a business transaction actually happens, regardless of source or user. That complements and reinforces SoD controls implemented within the SoD Violations Manager.

No.  Segregation of Duties Violation Manager's (SOD VM) static reports and Application Auditor's (AA) dynamic conflict detection share a single set of conflict definitions.  

The user lists are named sets of E-Business Suite (EBS) Users.  You can use the lists in Application Auditor (AA) to make audits more selective, and to filter audited transactions.  In Segregation of Duties Violation Manager (SoD VM) you can use the lists to limit the scope of the access violation snapshot. In AA, they let you take a closer look at what a set of users do, while ignoring the rest.  You can also reverse the logic, and ignore what a few users do, but audit what all the other users do. In both cases you are refining the selection criteria for when AA will respond to an audit event.  Thus your controls are more targeted and exception-based. In ProView for Application Auditor, you can use user lists to filter audited transactions.  This is a reporting convenience, and it is dependent on the users in the set at reporting time.  The filter can include or exclude the users on the list. In SoD VM, you can create a snapshot of user access violations for the users on a user list.  For example, you might want to see the violations for several of the accounting staff.