篇一：ERP系统中英文对照外文翻译文献
ERP系统中英文对照外文翻译文献
(文档含英文原文和中文翻译)
ERP系统在财务报告内部控制的作用
【摘要】：萨班斯-奥克斯利法案法例中强调，ERP系统的重要作用是运用内部控制反映公司的基本建设，为此 ERP系统软件开发供应商也增加了对内部控制的应用。他们认为，这些内置的控制和其他功能将帮助企业改善其财务报告内部控制就如萨班斯法案要求的那样。这项研究测试，通过检查萨班斯法案第404条在1994年和2003年之间实施ERP系统的公司合规内控数据。其结果表明，应用ERP 的公司相对于未应用ERP的样本公司较少报告内部控制弱点。它还发现，这种差异存在一般控制和特别控制中。
关键词：企业资源规划；ERP；萨班斯-奥克斯利法案；萨班斯法案第404条；内部控制 1简介
2002年的萨班斯法案要求企业将其内部控制的有效性的报告与财务报告作为一个整体努力，以减少欺诈和恢复完整的财务报告过程的一部分。ERP系统软件开发供应商已强调，ERP系统的重要作用是运用“内置”控制反映公司基本建设。他们在营销理念强调了产品的功能，声称这些系统将帮助企业按萨班斯法案所要求提高内部控制的有效性。
这些供应商的声明激发了关于ERP系统对内部控制的影响一项有趣的实证问题研究。具体来说，是不是实现ERP系统的企业或多或少可能比未实现ERP系统的公司较少在其年度报告报告内部控制弱点？已经进行过这特定区域研究的经验/档案相对较少的，因为之前萨班斯法案内部控制的数据并没有被公开报道。这项研究的方法通过在文献资料检查一个已经宣布实施ERP系统和一个还没有类似的公司控制样本公司的抽样调查的内部控制数据来发现差距。
内部控制是在公司使用的以解决代理问题的许多机制之一。其他的机制还包括财务报告，编制预算，审计委员会和外部审计（Jensen和佩恩2003）。研究表明，内部控制降低了代理成本（Abdel-khalik 1993；Barefield 等，1993），有些甚至争辩说，即使没有萨班斯法案的要求，企业也有经济诱因报告内部控制（Deumes和Knechel，2008年）。他们的论点假定这些额外提供给有关的代理行为主体的信息可以减少了信息不对称和降低投资者的风险以及权益资本成本。其他的研究发现，内部控制报告与公司盈余质量有关, （Chan 等， 2008；Ashbaugh-Skaife等，2008） ERP系统提供了一种机制，运用内部控制，旨在保证控制的准确性和快速，准确的财务报告财务信息的可靠性报告给股东。
除了提供有关代理行为的外部委托人的增加保证，ERP系统也应有助于减轻大型企业各层次之间的管理的代理问题。使用内建控制以增加透明度的应该使各级代理商从中不可观察的行为中受益变得更加困难。这是可能的，但是，企业实施ERP系统可能无法利用的所有的内建的控制功能，无论是对经营合法的原因或者是因为管理层为了操纵盈余希望避免增加透明度的目的。通过这些控制措施的成效的检查，这项研究不仅扩展了研究机构的理论流，还考察这种盈余管理与内部控制、一般控制和特别控制之间相关的整体检验假说。
这项研究使用了108家在1994年和2003年之间宣布实施ERP系统的样本公司，与
行业和规模相匹配的同等数目的控制公司。结果提供的证据表明，实现ERP 应用的企业相对比ERP没有应用的企业较少报告内部控制缺陷。这项研究进一步探讨内部控制弱点的成因，并认为导致应用ERP的公司相对于ERP没有应用的公司较少报告内部控制弱点与一般控制和特别控制相关联。这项研究还发现证据表明，应用ERP的公司优势会随着时间的推移日益增加，并建议企业加强ERP系统提供的内建控制以获得系统控制的经验。
这些发现非常重要，因为这两个萨班斯法案和ERP一直是许多讨论和近年来在学术界和专业团体的研究课题。成本往往是共同点，随着遵从萨班斯法案高成本以及实施ERP系统的高成本，成为许多研究问题的基础。这些发现提供了证据表明，ERP系统可能有助于改善内部控制，这是在辩解的ERP系统使用成本高许多论据之一。这项研究被认为是测试这些说法的第一个经验/档案，并提供在内部控制弱点起作用的相关因素，无论是学术界和专业界都应该会感兴趣。举例来说，最经常提到的因素是会计文件，政策，和程序。正如预期的那样，这一因素ERP企业比控制公司发现较少，也许在执行文件系统的过程需要努力。这项研究还扩展对IT和机构之间关系的理论研究流，特别是内部报告对金融市场的信号和ERP系统来推动这一进程的联系。
本文的其余部分组织如下：第二节总结以前的研究和发展的假说，第三节介绍了数据选择过程和研究方法，第四节实证结果，第五节总结。
2以前的研究开发和假设
内部控制背景
内部控制在缓和企业多年来的代理问题起到了主要作用。Samson 等其他人（2006）的几个内部控制的程序文件早在1831年被巴尔的摩和俄亥俄铁路使用。在最近时期，内部控制一直是当出现一个世界著名的企业丑闻讨论的主题。例如，在20世纪70年代超过400家制作公司承认有可疑或非法支付给外国政府官员，政治家和政党，这导致了1977年外国腐败行为法案在颁布。除其他事项外，FCPA要求上市公司制定和维护一个内部会计控制制度（USC1998）。
在20世纪80年代，一些高调审计失败导致了反虚假委员会组织重新定义确定的内部控制制度的有效性和内部控制标准的委员会的成立（西蒙斯1997年）。他们研究的偶然因素，可能导致虚假财务报告的建议，上市公司，独立审计师，教育机构，证券交易委员会和其他监管机构（COSO，1985年）。他们的工作模型被定义为COSO内部控制框架（西蒙斯，1997年）。在COSO框架大致定义为“一个过程，内部控制的实体的董事会，管理层和其他人员，内部控制框架设计是为了确保和实现以下目标：提高效益和经营效
率，保证财务报告的可靠性和遵从相关法律和法规（COSO 1992年，1）。
它指出，“有这些组件之间的协同和联动，形成一个综合系统，反应动态变化的条件” （COSO 1992年，1）。该框架还指出，控制是最有效的，当他们是实体的基础设施（COSO 1992,1），并进一步指出，“支持内部控制的质量控制措施和能力建设，避免不必要的成本，能够快速响应不断变化的条件”（COSO 1992年，1）。
在世纪之交，另一组的公司丑闻导致了2002年萨班斯-奥克斯利法案，其中除其他外，需要对内部控制的有效性正式报告的制定。在COSO框架中起着遵守的关键作用，因为该法第404条要求公司在其年度报告（表格10- K），提供公司的财务报告内部控制鉴证报告及由注册会计师事务所出具单独的管理报告。虽然其他框架可能被接受，美国证券交易委员会已明确表示，COSO框架符合美国证券交易委员会的标准是“可作为由美国证券交易所上市的公司评估框架用于管理的年度内部控制的目的评价和披露要求 ”（ Gupta and Thomson 2006, 28）。
虽然有内部控制在公司治理中发挥了多年的重大作用，萨班斯法案之前对内部控制的研究的经验/档案是有限的，大多是由于缺乏公共数据。内部控制被认为是“内部问题”，上市公司未要求披露有关的内部控制程序。随着萨班斯法案的制定，与内部控制相关经验/档案研究有明显增长。新增加的第302条和404条的报告要求放置在公共领域的信息研究人员正在使用的审查与内部控制与公司治理的许多问题。萨班斯法案第302条，而在2002年成为有效的，只要是用于测试之间的内部控制薄弱环节和其他企业特征（Ge and McVay 2005；Ashbaugh-Skaife等，2007；Doyle等，2007）。萨班斯法案第 404条，需要对内部控制的更广泛的审查，于2004年成为是否有效的两个时间段。在第一阶段，符合要求的，如2003年截至2004年11月15号美国证券交易委员会的年度报告，加速申报者知名企业。第二个阶段，其中包括符合标准所有其他公司，一直延续几次，现在从2007年12月15日到2010年6月15日结束的有由审计师出具有效的鉴证报告以及管理报告，（SEC 2009）。虽然从一个公司到另一个确切形式和内部控制管理报告的语言可能会有所不同，该报告必须披露，如果在对财务报告内部控制的任何重大缺陷。因此，现在可以测量通过分析这些材料在报告披露弱点判断内部控制的有效性。第404条已被用来研究人员检查（Raghunandan and Rama 2006）作为审计的成本增加，审计延误等问题（Ettredge等人，2006），申报者不足百分之报告（Grant et al. 2008），内部控制弱点（ICW）和权益成本的关系（Ogneva等，2007； Ashbaugh-Skaife 等，2009），内部控制弱点和管理成本的关系（Ashbaugh-Skaife 等，2008；Chan 等，2008）。
虽然内部控制相关经验/档案研究相对较新，有一个关于公司治理的文献相当前体，其中大部分使用的是代理理论基础（布伦南和所罗门，2008年）。艾森哈特1989提供了如财务报告和审计，以提供有关的代理。 ERP系统的推动将这个监察过程的方法。首先，他们能够快速，财务信息的主要准确的报告，但更重要的是，它们包括功能，便于实施和用来确保在报告中财务信息的准确性，内部控制的执行。有人会想到企业实现ERP系统，以最大限度地利用这些内置的控制功能，不仅降低代理成本，而且减少了内部控制在萨班斯法案第404号公布的弱点。
这些内置的控制是可能的，因为在部分系统都是围绕着设计概念单一，集成的系统，用于捕捉在整个公共数据库中的数据这家公司。相比之下，大多数遗留系统，围绕个人的需要演变，功能区已在几十个甚至上百个单独的计算机信息传播系统（Davenport 1998）。虽然原有系统可能包括一些内置的控件，一个不希望这些控件会像那些成为一个综合的ERP设计有效
系统。例如，一个典型的ERP系统将包括配套购买内置控件订单，接收文件和发票的三方配合，采取综合优势所有三个功能区。遗留系统，另一方面，可对购买不同的应用，接收和应付账款有一些内置的控制功能，但不互相沟通。因此，手动控制将被用来补充内建的控制和体制上，而不是电子，匹配的文件之前，授权支付。
审计准则第5号（AS No. 5），由上市公司会计监督发行董事会发布（PCAOB），提供了对信息技术与内部控制的关系有所了解。例如，在附录的AS号5 B，它指出，“完全自动化应用控制，一般不受故障由于人为故障。这功能允许审计师使用的“标杆”战略...基准自动化应用控制可用于购买软件使用时，程序更改的可能性微乎其微，例如公司，尤其是有效的，当供应商不允许访问或修改的源代码“（PCAOB 2007, B28, B32）。由于ERP系统是购买的软件，相对于传统系统，这是发展和维持内部，公司员工将最有可能获得的遗留系统的源代码，但不是ERP系统。鉴于所有这些因素，人们所期望的ERP系统有一个对财务报告内部控制的有效性产生积极的影响。
然而，相反的观点被提出，只是因为公司实施ERP系统，他们可能没有考虑到所有内置的控制功能。这是可能的，例如，实施期间，控制某些功能可能不被激活。或者，在一个更险恶的观点，高级管理人员可以选择覆盖控制功能，以处理数据来实现“盈余管理”，这说法被Brazel and Dang 认同（2008），谁主张通过对财务数据的高级管理人员，增加控制一致在一个集中的ERP系统将导致盈余管理增加。在他们的论点，他们引用之前的研究，发现在审计和内部控制质量的减少通过以下ERP （Bagranoff and
篇二：毕业设计的5000字英文文献翻译
外文及翻译
英语原文 Android Application Fundamentals
Android applications are written in the Java programming language. The Android SDK tools compile the code—along with any data and resource files—into an Android package, an archive file with an .apk suffix. All the code in a single .apk file is considered to be one application and is the file that Android-powered devices use to install the application. Once installed on a device, each Android application lives in its own security sandbox: ? The Android operating system is a multi-user Linux system in which each
application is a different user.
? By default, the system assigns each application a unique Linux user ID (the ID is used only by the system and is unknown to the application). The system sets
permissions for all the files in an application so that only the user ID assigned to that application can access them.
? Each process has its own virtual machine (VM), so an application's code runs in isolation from other applications.
? By default, every application runs in its own Linux process. Android starts the process when any of the application's components need to be executed, then shuts down the process when it's no longer needed or when the system must recover
memory for other applications.
In this way, the Android system implements the principle of least privilege. That is, each application, by default, has access only to the components that it requires to do its work and no more. This creates a very secure environment in which an application cannot access parts of the system for which it is not given permission.
However, there are ways for an application to share data with other applications and for an application to access system services:
? It's possible to arrange for two applications to share the same Linux user ID, in which
case they are able to access each other's files. To conserve system resources,
applications with the same user ID can also arrange to run in the same Linux process
and share the same VM (the applications must also be signed with the same
certificate).
? An application can request permission to access device data such as the user's
contacts, SMS messages, the mountable storage (SD card), camera, Bluetooth, and
more. All application permissions must be granted by the user at install time.
That covers the basics regarding how an Android application exists within the system. The rest of this document introduces you to: ? The core framework components that define your application.
? The manifest file in which you declare components and required device features for
your application.
? Resources that are separate from the application code and allow your application to
gracefully optimize its behavior for a variety of device configurations.
Application Components
Application components are the essential building blocks of an Android application. Each component is a different point through which the system can enter your application. Not all components are actual entry points for the user and some depend on each other, but each one exists as its own entity and plays a specific role—each one is a unique building block that helps define your application's overall behavior.
There are four different types of application components. Each type serves a distinct purpose and has a distinct lifecycle that defines how the component is created and destroyed.
Here are the four types of application components:
Activities
An activity represents a single screen with a user interface. For example, an email application might have one activity that shows a list of new emails, another activity to compose an email, and another activity for reading emails. Although the activities work together to form a cohesive user experience in the email application, each one is independent of the others. As such, a different application can start any one of these
共 21 页第 1 页
activities (if the email application allows it). For example, a camera application can start the activity in the email application that composes new mail, in order for the user to share a picture.
An activity is implemented as a subclass of Activity and you can learn more about it in the Activities developer guide.
Services
A service is a component that runs in the background to perform long-running operations or to perform work for remote processes. A service does not provide a user interface. For example, a service might play music in the background while the user is in a different application, or it might fetch data over the network without blocking user interaction with an activity. Another component, such as an activity, can start the service and let it run or bind to it in order to interact with it.
A service is implemented as a subclass of Service and you can learn more about it in the Services developer guide. Content providers
A content provider manages a shared set of application data. You can store the data in the file system, an SQLite database, on the web, or any other persistent storage location your application can access. Through the content provider, other applications can query or even modify the data (if the content provider allows it). For example, the Android system provides a content provider that manages the user's contact information. As such, any application with the proper permissions can query part of the content provider (such as ContactsContract.Data) to read and write information about a particular person.
Content providers are also useful for reading and writing data that is private to your application and not shared. For example, the Note Pad sample application uses a content provider to save notes.
A content provider is implemented as a subclass of ContentProvider and must implement a standard set of APIs that enable other applications to perform transactions. For more information, see the Content Providers developer guide.
共 21 页第 2 页
Broadcast receivers
A broadcast receiver is a component that responds to system-wide broadcast announcements. Many broadcasts originate from the system—for example, a broadcast announcing that the screen has turned off, the battery is low, or a picture was captured. Applications can also initiate broadcasts—for example, to let other applications know that some data has been downloaded to the device and is available for them to use. Although broadcast receivers don't display a user interface, they may create a status bar notification to alert the user when a broadcast event occurs. More commonly, though, a broadcast receiver is just a "gateway" to other components and is intended to do a very minimal amount of work. For instance, it might initiate a service to perform some work based on the event.
A broadcast receiver is implemented as a subclass of BroadcastReceiver and each broadcast is delivered as an Intent object. For more information, see theBroadcastReceiver class.
A unique aspect of the Android system design is that any application can start another application’s component. For example, if you want the user to capture a photo with the device camera, there's probably another application that does that and your application can use it, instead of developing an activity to capture a photo yourself. You don't need to incorporate or even link to the code from the camera application. Instead, you can simply start the activity in the camera application that captures a photo. When complete, the photo is even returned to your application so you can use it. To the user, it seems as if the camera is actually a part of your application.
When the system starts a component, it starts the process for that application (if it's not already running) and instantiates the classes needed for the component. For example, if your application starts the activity in the camera application that captures a photo, that activity runs in the process that belongs to the camera application, not in your application's process.
Therefore, unlike applications on most other systems, Android applications don't have a single entry point (there's no main() function, for example).
Because the system runs each application in a separate process with file permissions that restrict access to other applications, your application cannot directly activate a component from another application. The Android system, however, can. So, to activate a component in
共 21 页第 3 页
another application, you must deliver a message to the system that specifies your intent to start a particular component. The system then activates the component for you.
Activating Components
Three of the four component types—activities, services, and broadcast receivers—are activated by an asynchronous message called an intent. Intents bind individual components to each other at runtime (you can think of them as the messengers that request an action from other components), whether the component belongs to your application or another.
An intent is created with an Intent object, which defines a message to activate either a specific component or a specific type of component—an intent can be either explicit or implicit, respectively.
For activities and services, an intent defines the action to perform (for example, to "view" or "send" something) and may specify the URI of the data to act on (among other things that the component being started might need to know). For example, an intent might convey a request for an activity to show an image or to open a web page. In some cases, you can start an activity to receive a result, in which case, the activity also returns the result in
an Intent (for example, you can issue an intent to let the user pick a personal contact and have it returned to you—the return intent includes a URI pointing to the chosen contact).
For broadcast receivers, the intent simply defines the announcement being broadcast (for example, a broadcast to indicate the device battery is low includes only a known action string that indicates "battery is low").
The other component type, content provider, is not activated by intents. Rather, it is
activated when targeted by a request from a ContentResolver. The content resolver handles all direct transactions with the content provider so that the component that's performing
transactions with the provider doesn't need to and instead calls methods on
the ContentResolver object. This leaves a layer of abstraction between the content provider and the component requesting information (for security).
There are separate methods for activating each type of component:
共 21 页第 4 页
篇三：5000字英文文献翻译
沈阳建筑大学
毕业论文
外文及翻译
原文题目
学院专业班级 信息与控制工程学院 计算机08-1
学生姓名 XXX 性别 X
指导教师 XXX 职称 XX
年 月
日
外文及翻译
英语原文 Android Application Fundamentals
Android applications are written in the Java programming language. The Android SDK tools compile the code—along with any data and resource files—into an Android package, an archive file with an .apk suffix. All the code in a single .apk file is considered to be one application and is the file that Android-powered devices use to install the application.
Once installed on a device, each Android application lives in its own security sandbox: ? The Android operating system is a multi-user Linux system in which each
application is a different user. ? By default, the system assigns each application a unique Linux user ID (the ID is
used only by the system and is unknown to the application). The system sets
permissions for all the files in an application so that only the user ID assigned to that
application can access them.
? Each process has its own virtual machine (VM), so an application's code runs in
isolation from other applications.
? By default, every application runs in its own Linux process. Android starts the
process when any of the application's components need to be executed, then shuts
down the process when it's no longer needed or when the system must recover
memory for other applications.
In this way, the Android system implements the principle of least privilege. That is, each application, by default, has access only to the components that it requires to do its work and no more. This creates a very secure environment in which an application cannot access parts of the system for which it is not given permission.
However, there are ways for an application to share data with other applications and for an application to access system services:
? It's possible to arrange for two applications to share the same Linux user ID, in which
case they are able to access each other's files. To conserve system resources,
共 21 页第 1 页
applications with the same user ID can also arrange to run in the same Linux process
and share the same VM (the applications must also be signed with the same
certificate).
? An application can request permission to access device data such as the user's
contacts, SMS messages, the mountable storage (SD card), camera, Bluetooth, and
more. All application permissions must be granted by the user at install time.
That covers the basics regarding how an Android application exists within the system. The rest of this document introduces you to: ? The core framework components that define your application.
? The manifest file in which you declare components and required device features for
your application.
? Resources that are separate from the application code and allow your application to
gracefully optimize its behavior for a variety of device configurations.
Application Components
Application components are the essential building blocks of an Android application. Each component is a different point through which the system can enter your application. Not all components are actual entry points for the user and some depend on each other, but each one exists as its own entity and plays a specific role—each one is a unique building block that helps define your application's overall behavior.
There are four different types of application components. Each type serves a distinct purpose and has a distinct lifecycle that defines how the component is created and destroyed.
Here are the four types of application components:
Activities
An activity represents a single screen with a user interface. For example, an email application might have one activity that shows a list of new emails, another activity to compose an email, and another activity for reading emails. Although the activities work together to form a cohesive user experience in the email application, each one is independent of the others. As such, a different application can start any one of these activities (if the email application allows it). For example, a camera application can start the activity in the email application that composes new mail, in order for the user
共 21 页第 2 页
to share a picture.
An activity is implemented as a subclass of Activity and you can learn more about it in the Activities developer guide.
Services
A service is a component that runs in the background to perform long-running operations or to perform work for remote processes. A service does not provide a user interface. For example, a service might play music in the background while the user is in a different application, or it might fetch data over the network without blocking user interaction with an activity. Another component, such as an activity, can start the service and let it run or bind to it in order to interact with it.
A service is implemented as a subclass of Service and you can learn more about it in the Services developer guide. Content providers
A content provider manages a shared set of application data. You can store the data in the file system, an SQLite database, on the web, or any other persistent storage location your application can access. Through the content provider, other applications can query or even modify the data (if the content provider allows it). For example, the Android system provides a content provider that manages the user's contact information. As such, any application with the proper permissions can query part of the content provider (such as ContactsContract.Data) to read and write information about a particular person.
Content providers are also useful for reading and writing data that is private to your application and not shared. For example, the Note Pad sample application uses a content provider to save notes.
A content provider is implemented as a subclass of ContentProvider and must implement a standard set of APIs that enable other applications to perform transactions. For more information, see the Content Providers developer guide.
Broadcast receivers
A broadcast receiver is a component that responds to system-wide broadcast
共 21 页第 3 页
announcements. Many broadcasts originate from the system—for example, a broadcast announcing that the screen has turned off, the battery is low, or a picture was captured. Applications can also initiate broadcasts—for example, to let other applications know that some data has been downloaded to the device and is available for them to use. Although broadcast receivers don't display a user interface, they may create a status bar notification to alert the user when a broadcast event occurs. More commonly, though, a broadcast receiver is just a "gateway" to other components and is intended to do a very minimal amount of work. For instance, it might initiate a service to perform some work based on the event.
A broadcast receiver is implemented as a subclass of BroadcastReceiver and each broadcast is delivered as an Intent object. For more information, see theBroadcastReceiver class.
A unique aspect of the Android system design is that any application can start another application’s component. For example, if you want the user to capture a photo with the device camera, there's probably another application that does that and your application can use it, instead of developing an activity to capture a photo yourself. You don't need to incorporate or even link to the code from the camera application. Instead, you can simply start the activity in the camera application that captures a photo. When complete, the photo is even returned to your application so you can use it. To the user, it seems as if the camera is actually a part of your application.
When the system starts a component, it starts the process for that application (if it's not already running) and instantiates the classes needed for the component. For example, if your application starts the activity in the camera application that captures a photo, that activity runs in the process that belongs to the camera application, not in your application's process.
Therefore, unlike applications on most other systems, Android applications don't have a single entry point (there's no main() function, for example).
Because the system runs each application in a separate process with file permissions that restrict access to other applications, your application cannot directly activate a component from another application. The Android system, however, can. So, to activate a component in another application, you must deliver a message to the system that specifies your intent to start a particular component. The system then activates the component for you.
共 21 页第 4 页
免费论文网友情提示：本网站所有内容为共享上传提供，不涉及任何商业利益，本站对此不承担任何保证责任！
Copyright © www.csmayi.cn Corporation, All Rights Reserved 共享时代 共享你我他 版权所有