Method and System For An Electronic Document Framework - US20170039175A1
Method and System For An Electronic Document Framework - US20170039175A1
224 Maintained
Determine eDocument type and process eDocument 218
=== --
Country Specific
225 Database
Generate eDocument according to technical
requirements 207
edocument
219
A
Display generated eDocument in eDocument 06
Interface
a
MonitoriModify
eDocument
221
Update eDocument
222
Prepare eDocument for transmission
- ---------
107 211
Partner service provider
Local Authorities
Patent Application Publica ion Feb. 9, 2017. Sheet 1 Of 13 US 2017/0039175 A1
Patent Application Publication Feb. 9, 2017. Sheet 2 of 13 US 2017/0039175 A1
accessee
Patent Application Publication Feb. 9, 2017. Sheet 3 of 13 US 2017/0039175 A1
É
Patent Application Publication Feb. 9, 2017. Sheet 4 of 13 US 2017/0039175 A1
go
wn------ : waitained
a.a.a.a.a.a.a.a.a.a.a.a.s.
Country Specific.
Database
Motitoff vocify
eioc
---
lata Ai thorities
FGURE 23
Patent Application Publication Feb. 9, 2017. Sheet 5 of 13 US 2017/0039175 A1
er,
-----------------------------------------------------------------------------------------------------------------------------------------
Patent Application Publication Feb. 9, 2017. Sheet 6 of 13 US 2017/0039175 A1
26 401
/ ^
---------------------4.--r
Country specific
e}ociet ei)octise :
ataha
ei)Octinent
source fie
eiocument
history database
eiocument file
i database
eige;
reference
dataase
FGURE 4
Patent Application Publication Feb. 9, 2017. Sheet 7 of 13 US 2017/0039175 A1
3ds&?u šs?d t?
s
Ry
Patent Application Publication Feb. 9, 2017. Sheet 8 of 13 US 2017/0039175 A1
reigiitii airciisei
Seiskin Peters
{onary Code Sessrs
esses G.
Satiree type
cite Best we
-- Created By Riser
* Creation aste
FGURE 6A
Patent Application Publication Feb. 9, 2017. Sheet 9 of 13 US 2017/0039175 A1
{{9 O9
Patent Application Publication Feb. 9, 2017. Sheet 10 of 13 US 2017/0039175 A1
Patent Application Publication Feb. 9, 2017. Sheet 11 of 13 US 2017/0039175 A1
| | | | | | | | | | | |
waw
sa
8{!}{ }{
& &
3f 3
Patent Application Publication Feb. 9, 2017. Sheet 12 of 13 US 2017/0039175 A1
Status Flags
FIGURE 9
Patent Application Publication Feb. 9, 2017. Sheet 13 of 13 US 2017/0039175 A1
}}
{{{}}
{{!}}
|
{}
3seq {
${}{}
US 2017/00391 75 A1 Feb. 9, 2017
METHOD AND SYSTEM FOR AN 0007 Traditional methods attempting to solve these
ELECTRONIC DOCUMENT FRAMEWORK issues only a particular country and a particular eldocument
type. The existing systems still require significant amounts
RELATED APPLICATIONS of resources to complete, and once the systems are pro
duced, they have very little synergy and are not easily
0001. This application claims priority to India Patent scalable or transferrable due to the wide variety of govern
Application No. 4072/CHF/2015 filed on Aug. 5, 2015, the ment regulations and eDocument types. This inefficient use
content of which is incorporated herein in its entirety. of resources is joined by a large lack of quality and inte
FIELD OF THE DISCLOSURE
gration issues. The customers that do business in different
countries must execute varying different Solutions to tackle
and solve a similar situation.
0002 The present invention relates to a method and 0008. This issue becomes particularly relevant in regard
System for generating, sending, updating, and monitoring
electronic documents (eIDocuments). More specifically, the to large, multinational corporations, which operate in many
present invention relates to generating, sending, updating, different countries, and therefore, are required to comply
and monitoring eDocuments based on source documents with a wide range of different technical requirements.
created in Enterprise Resource Planning (ERP) software. BRIEF DESCRIPTION OF THE DRAWINGS
INFORMATION 0009 FIG. 1A is a simplified view of the solution land
Scape.
0003. Every country and process has different technical
requirements for the transmission of eDocuments. These 0010 FIG. 1B is a solution architecture according to an
embodiment.
technical requirements can greatly vary. Business-to-Gov
ernment (B2G) and Business-to-Business (B2B) communi 0011 FIG. 1C is a solution architecture according to an
cation is a worldwide trend that expands quickly every year. embodiment.
Companies in countries, e.g., Brazil and Mexico, may be 0012 FIG. 2A is a simplified block diagram of the system
required by country law to send electronic invoices (i.e., according to an embodiment.
eDocuments) to the government for approval for transac 0013 FIG. 2B is a flowchart of the framework according
tions that are, e.g., posted in their ERP software. The number to a particular embodiment.
of individual countries having regulations, which require 0014 FIG. 3 is a simplified block diagram of the process
different technical requirements, has increased in recent manager according to an embodiment.
years. In another example scenario, the government is not an 0015 FIG. 4 is a simplified block diagram of the imple
active party in the communication. There, e.g., eDocuments mentation of an eIDocument according to an embodiment.
may be used to automate business flows. These technical 0016 FIG. 5 is a simplified diagram of the document
requirements could be, e.g., format requirements, authenti process according to an embodiment.
cation requirements, legal requirements, etc. 0017 FIG. 6A is an exemplary user interface according
0004 To illustrate, a business entity in a particular coun to an embodiment.
try may create an invoice (i.e., an eIDocument) when doing 0018 FIG. 6B is an exemplary user interface according
business with another entity, which may be another business to an embodiment.
entity or the local government. When creating this invoice, 0019 FIG. 6C is another exemplary user interface
the business entity is required, by government regulation, to according to an embodiment.
conform the invoice to specific technical requirements. 0020 FIG. 7 is a simplified block diagram of the inter
These technical requirements compel the Supplier to care action between the system and the application interface
fully manage and monitor all of its eDocuments for com framework according to an embodiment.
pliance. This monitoring and managing forces the Supplier to 0021 FIG. 8 is a simplified diagram of a database for use
expend significant amounts of resources, since these regu in an embodiment.
lations can be complicated, vary greatly between individual
countries, and are usually specific to a single type of 0022 FIG. 9 is a simplified diagram of an el Document in
eDocument. an embodiment.
0005. Once the business entity has ensured that its 0023 FIG. 10 is a simplified diagram of processing
classes in an embodiment.
eDocument complies with the technical requirements and
government regulations, the business entity Submits the DETAILED DESCRIPTION
eDocument to a common authority (i.e., government
agency), so that the eDocument can be reviewed for com 0024. In an embodiment of the present invention, the
pliance. Only after the common authority confirms that the eDocument framework system provides a set of tools to
eDocument is compliant, is the business entity authorized to allow the incorporation of country-specific solutions without
transmit the eldocument to the other entity. the need to start from scratch every time. The eDocument
0006. The process of creating and exchanging everyday framework system is prepared and/or configured to manage,
business documents becomes a highly technical and time generate, send, update, and monitor the eDocuments. The
consuming process, which requires different, individualized eDocuments can be sent to local authorities, business part
Solutions for each individual country and each type of ners, or other recipients. Functionality is provided by the
eDocument being exchanged. The process can involve sig eDocument framework system, which allows the framework
nificant expenditures of resources to ensure that exchanged system to be easily expandable to include additional details
eDocuments are legally compliant with the relevant techni and particularities for a specific country and process. This
cal regulations. expansion can be accomplished without expending signifi
US 2017/00391 75 A1 Feb. 9, 2017
cant amounts of additional resources and effort to keep 0031 FIG. 1A is a simplified view of the system land
uniformity. The eDocument framework system also reduces scape. The system landscape 100 includes a backend 101, a
maintenance costs. cloud services provider 107, and a local authority 112. In an
0025 To accomplish this, in an embodiment of the pres embodiment, the backend 101 is ERP software. The backend
ent invention, the eDocument framework system includes of 101 can also include eDocument framework system 102.
a number of functions described below that enable the The eDocument framework system 102 includes a mapping
eDocument framework system to highly automate the pro application 103 and an application interface framework
cess of managing, generating, sending, updating, and moni (AIF) 104. The back end 101 ERP system can also include
toring eDocuments. additional software applications 105 and 16, where the
0026. In an embodiment, the data collection part is part of source documents of the eDocument Framework system 102
the application, and it must be able to retrieve the required can be generated. Additional applications can include SAP
technical requirements for the desired eDocument, map it to APPL 6.00 or SAP NetWeaver.
an appropriate communication format, and send it out 0032. According to one embodiment, mapping applica
through a web service during a certain step of a process (for tion 103 is fully included within the backend 101, and all
example in the sales division (SD) of ERP, during post goods processes related to mapping data are performed in the
issue). backend 101. This allows for all relevant information to be
0027. In an embodiment, the data collection is imple presented in the backend 101, which does not require the
mented in all applications that generate eDocuments. One cloud service provider 107 to retrieve information from the
example is through the backend of ERP software. For backend 101 for processing. Locating the mapping applica
electronic invoicing that can be in the following in the ERP tion within the backend 101 also creates several advantages,
software: Sales and Distribution (SD) Financials (FI); Finan for example: prevention of redundant data from being trans
cial Cost Accounting (FI-CA); Real Estate (RE-FX); and mitted; easier mapping and analysis of the generic structure;
where industry specific invoicing is done. Further aspects or customer extensions do not have to be added in the cloud
modules of the ERP software can include: Sales and Dis services provider; easier testing and troubleshooting; no
tribution of Delivery Goods Issue (SD Del GI); Sales and requirement for customer proficiency in Advanced Business
Distribution of Transportation Planning (SD Transportation Application Programming (ABAP) or cloud service pro
Planning); Sales and Distribution Bills (SD Bill); Sales and vider; reduced testing effort since the information only needs
Distribution of Logistics and Material Management (MM); to be mapped once from the Source structure to the country/
and Industry Specific Utilities (IS-U). In an embodiment, the eDocument type specific format; and business monitoring is
eDocument itself includes the source data when electronic concentrated in the backend 101.
documents have to be created without a standard document. 0033) Application interface framework (AIF) 104 can be
Examples of this are incoming documents. included in the eldocument framework system. AIF 104
0028. In an embodiment, the actual communication is defines and manages outbound and inbound message pro
performed outside of the eldocument framework system. cessing. Although AIF 104 handles a number of formats, a
The eIDocument framework system is built to communicate web service definition language (WSDL) can be used in
and interact with a cloud services provider, for example, connection with the cloud services provider 107. In a
SAP Hana Cloud Integration (HCI). It is possible to use number of cases, the final destination does not handle web
other communication platforms, which would be a customer services. In those cases, emails have to be sent with exten
specific solution. In an embodiment, the communication sible markup language (XML) content. The version of the
platform is decoupled from the eDocument framework sys message used in the AIF 104 is determined in the eDocu
tem so that any application is able to use the HCI commu ment framework system 102 and not in the AIF 104. The
nication flow being offered for a certain use case and/or functionality of AIF 104 is more fully described below.
country. In an embodiment, the communication platform is 0034) Cloud services provider 107 can be SAP HCI, for
a cloud application, making it independent of installed bases example, and can include integration flows 108. Integration
and allowing faster deployment and maintenance. Incoming flows 108 are a Business Process Model Notation (BPMN)
electronic documents may be generated outside of the ERP based model that can be executable on the cloud services
Software. In an embodiment, the eDocument is sent to an provider. Integration flows 108 can include technical
email account or to an HCI tenant of the customer. requirements related to individual Country A109, Country
0029. In an embodiment, the framework system initiates B 110, and Country C 111, etc. Integration flows 108 provide
a pull mechanism to retrieve these objects, store them as part communication between the cloud services provider 107 and
of existing eDocuments or create new eDocuments, depend the local authorities 112, which can be implemented through
ing on the content of the information received. Webservices 113. Integration flows 108 also provide vali
0030. In an embodiment, the eDocument framework sys dation, approval, certificates, registration of created eDocu
tem sends different messages regarding current eDocument ments, and digital signatures for transmission of eDocu
status and different events affecting eDocument (e.g., user mentS.
actions in an interface). For example, response of Such 0035 FIG. 1B and FIG. 1C illustrate system architecture
messages (approval, response, status response, etc.) is be according to particular embodiments. FIG. 1A illustrates
received and processed. To accomplish this, for example, separate ERP divisions 114 (i.e., Legal Reports, SD Del G.I.
different interfaces are monitored in the eDocument frame etc.) within the ERP software 115 can communicate division
work system. In an embodiment, versioning of the interfaces specific data to the eIDocument framework system 102. This
can be effected in order to allow interface format change information can then be processed using the country specific
with time. In an embodiment, the eDocument framework settings in the eIDocument framework system 102 and sub
system stores relevant changes to the eDocument in a mitted to a cloud services provider 107. Subsequently, the
database. cloud services provider can transmit the different types of
US 2017/00391 75 A1 Feb. 9, 2017
processed eDocuments 117 to their respective local authori ity 112 can be configured to exchange elDocuments with
ties 112. FIG. 1B and FIG. 1C also illustrate the scalability cloud services provider 107 via an elDocument processor
of the eDocument framework system 102 with regard to 215.
adding new ERP divisions, new countries, and/or new types 0040. As further illustrated in FIG. 2A, eDocument
of eDocuments. framework system 102 also includes document process
0036 FIG. 2A is a simplified block diagram of the module 201. Document process module 201 is found within
eIDocument framework system 102 according to an embodi Standard applications and is the starting point in transform
ment. eIDocument framework system 102 can include docu ing standard documents into an elocument 206 with the
ment process module 201, process manager module 202, correct, legally required format. Document process module
interface connector 203, partner connector 204, eDocument 201 is where the eldocument 206 is created on the base of
interface 205, and eDocument 206. FIG. 2A also illustrates source documents 210, which were created in standard ERP
how elDocument framework system 102 can interact with Alternatively the document process module 201 can include
other components within the solution landscape: users 216, functionality wherein an eldocument 206 is created on
source document 217, maintained document 218, partner information that will be included in the elDocument 206
service provider 211, and cloud services provider 107. In itself. The start of the document process module 201 is a
one particular embodiment, a user 216 can interface with hook in a standard application or the start of automated
user interface 205 located within the eldocument framework processing of incoming eldocument 206. The original docu
System to perform certain tasks such as monitoring and ment process module 201 is more fully described below.
viewing the history of the eDocument 206. Additionally, 0041 eldocument framework system 102 also includes
user 216 can create a source document 217, which can be process manager module 202. Process manager module 202
transmitted to and received by the process manager module performs the following functions: determining possible sub
202. Alternatively, process manager module 202 can receive sequent steps on the base of the status of the eldocument;
a maintained document 218. determining the new status for an eldocument on the basis of
0037 eldocument framework system 102 can also be the execution of a process step; triggering the execution of
configured to communicate with partner service provider the process step; translating the user interface or program
211 via partner connector 204. The partner connector 204 action in a process step to be executed; and verifying
can be used for any type of communication with a partner authorization for a process step. The process manager mod
service provider, be it customer, vendor or business partner. ule 202 can also be configured to communicate with source
Possibilities are for example: printing, generation of pdf document 210, company data 209, and master data 208. The
files, XMLs, and emails with attachments. This is meant for process manager module 202 functionality is more fully
interchanging with all partner service providers except for described below.
tax authorities. There is no limitation on the interface 0042. eIDocument framework system 102 also includes
technology here. eDocument interface 205. The elDocument interface allows
0038. In one particular embodiment, eDocument frame for the monitoring and processing of eDocument 206. Each
work system 102 communicates with cloud services pro type of eDocument 206 will have its own set of process
vider 107 via interface connector 203. Interface connector steps. All steps that can be relevant for manual processing
203 prepares the eldocument for transmission and creates the are present in the eldocument interface 205. The elDocument
message structure and the mapping of the source document interface 205 is more fully described below.
to the message structure. This can be done in AIF 104 or in 10043 FIG. 2B is a simplified flow chart illustrating the
a Custom Business Add Ins (BAdI). The number of ways to basic functionality of the eDocument framework system
communicate using this BAdI is limited to Custom and 102. The eDocument framework system 102 can be initiated
Advanced Business Application Programming (ABAP) during process 223, when the system receives a document
Proxies or XML via the AIF 104. The choice of the interface from either a user created document (i.e., source document
connector 203 has three dimensions. First, the specific 217) or a maintained eDocument 218. Next, in process 224,
interface technology. This choice can be made per Company the eldocument framework system determines the eDocu
and eDocument type. AIF 104 content can be communicated ment type and required process. In one particular embodi
in the following ways: as Webservices or providing an XML ment, the eDocument framework system can use the cloud
for Subsequent processing. Alternatively, an AIF custom services provider 107 and/or the elDocument 206 itself in
build can be used. Second, the choice of the interface itself. carrying out the mapping process.
This choice depends on the source document structure, the 0044) Once the necessary technical requirements have
process step/action, and the content (i.e., the actual source been determined, process 225 generates an el Document with
document). The AIF 104 is capable of choosing the correct the necessary technical requirements, and process 219 dis
version for the interface on the basis of the provided plays the eldocument to a user. Once displayed, process 220
information. Third, the choice of the cloud services provider allows the elDocument to be monitored and/or modified by
107. This choice can be made per Company and eDocument the user. Process 221 updates the elDocument 206. Process
type. Possible alternatives can include, for example, service 222 prepares the elDocument for transmission to either the
orientated architecture (SOA) manager port, or a request for cloud services provider 107 or a partner service provider
comment (RFC) destination. Cloud services provider 107 211. If transmitted to the cloud services provider 107, the
can include a cloud based message system 213. Cloud based cloud services provider can subsequently submit the eldocu
message communication platform 212 can be, for example, ment to the local authorities 112.
SAPHCI. Cloud service provider 107 can also include other 0045 FIG. 3 is a simplified block diagram of the process
platforms 214. manager module 202 according to an embodiment. Process
0039 FIG. 2A also illustrates interaction between cloud manager module 202 determines the configuration of a
services provider 107 and local authority 112. Local author specific elDocument 206 with respect to the process steps,
US 2017/00391 75 A1 Feb. 9, 2017
statuses related to process steps, and actions resulting from step can add an entry in this table. eIDocument history
these steps. In the process manager module 202, the con database 403 can include the process log of the eLDocument
figuration for a specific elocument type with respect to the 206 as well. Relevant changes to the eldocument 206 will be
process steps, statuses related to process steps, and actions recorded here. This is achieved by making a copy of
resulting from these steps can be found. A process consists eDocument 206, storing it in the eldocument history data
of a number of process StepS/actions. A process step action base 403, every time that a relevant change is made to the
can be a function module or an interface, for example, eDocument 206.
create/modify the eldocument and create eDocument history. 0051 eldocument file database 404 can include the files,
The entire handling of the eDocument 206 is done through such as XML’s and mails that are relevant for the eDocu
the process manager module 202. The configuration of the ment 206 and have been used in communication. Several
processes and related process steps are Country and eDocu files can be added within a process step. The type of file is
ment type specific. The process manager module 202 will classified by a file type (must not be confused by format
invoke the processing in the local coding and does not make type). eIDocument 206 can include a forward reference to the
any changes. The process manager module 202 is also eDocument file database 404. This functions when one file
responsible to verify if the user is authorized to perform is created in a step. It is however possible that several files
actions in the framework system. are attached during a step. For that case a backward refer
0046 Process manager module 202 operates as follows: ence to the eldocument 206 and/or eldocument history
a request for a process step 301 or get allowed step 302 is database 403 is present in the eldocument file database 404.
initiated, and the response is transmitted to the process A file type is present to Supply an easily understandable
manager module 202. Process 303 authorizes the requested semantic meaning of a file, and the possible file types are
process 301 or get allowed step 302, and determine allowed defined per country in configuration tables of the eLDocument
process step 304 then determines the allowed process steps framework system 102.
based on eDocument 206, and can include, for example: 0.052 eldocument reference database 405 can be used to
process 307, process step 308, allowed process step 309, or include a list of documents that are relevant for the eDocu
process status flag 310. Start process step 305 initiates the ment 206. An example is the daily report for a specific type
requested and authorized process step. The selected process of invoices. The identifications of all relevant documents are
step is transmitted for execution to processing eDocument kept in this file. This table will include references to other,
type 312. The process step is executed at execute process related documents. A Reference Type defines the type of
step 313, and the process manager subsequently determines document (e.g., eDocument 206 or source document 217)
status flags at process 306. that is referred to. A sequence number that is independent on
0047 FIG. 4 is a simplified block diagram of the imple the number in the eLDocument 206 will be part of the key.
mentation of an eDocument according to an embodiment. 0053 FIG. 5 is a simplified sequence diagram of the
The eIDocument 206 can include the status and process document process module 201 according to an embodiment.
handling fields, as well as document type, organizational The document process can be carried out in the following
data, and the identity of the logical system. Each country steps:
will have one or more eldocument types. These consist of a 0054 First, the document process is initiated at hook 501.
header that is shared across all eDocument types and one or Next, the eLDocument is prepared at 504. Next, message 505
more country specific structure(s). Naming of the specific determines if the eldocument 206 needs to be generated for
structure will be in accordance with the names used in the the company/source document combination. Message 506
country. The source document for the eldocument can differ. calls a constructor on the basis of the country and corre
It is possible that eDocument types and process are shared sponding eldocument subclass. Message 507 calls the cor
by documents from various sources. For example an e-in responding subclass from the country specific database 207,
voice can be generated in SD, FI and industry solutions. and message 508 sends the corresponding Subclass and
Field names are assigned dynamically in the cockpit. It is eDocument type to the eDocument. Message 509 indicates
therefore important that the names of the fields are unique the transfer of the eIDocument type from the eDocument 206
within all eDocument databases 401-405. Each eDocument to the country specific database 207 when the eDocument
206 can include the following: country specific elocument type has been entered manually by the user.
database 401; eDocument source file 402; eDocument his 0055 Messages 510 indicates that additional filtering can
tory database 403; eDocument file database 404; and eDocu be performed on the basis of document type and other
ment reference database 405. information. Additional filtering can include, for example, a
0048 Country specific elocument database 401 holds customer BAdI, which can be available to provide additional
the relevant data for the country format. For each eLDocu filtering and to change the standard eDocument type deter
ment 206, one country specific database 401 is present. If mination.
large structural differences exist for document types used in 0056. Next, if the eDocument 206 is to be generated,
the country, then more than one country specific eDocument message 511 returns an eDocument instance from the coun
database 401 can exist. It is also possible that a country try specific database 503 to the eldocument 206. Message
implementation requires a set of country specific elocument 512 returns the eDocument instance from the eDocument
databases 401 such as header, items and tax tables. It is also 206 to the hook 501. An eDocument is then generated at 513.
possible that no country specific content is present. 0057. After generation of the eldocument, message 514
0049 eldocument source file 402 can include the file that returns an eDocument instance from the hook to the eDocu
holds the source information for eDocument 206. ment 206. Message 515 sends the country specific additional
0050 eldocument history database 403 can be a copy of eDocument data to the country specific database 207. Mes
the eDocument 206, and can include the content of the sage 517 indicates that the country specific additional
generic table at a point in time. The execution of a process eDocument is saved to the country specific database 207.
US 2017/00391 75 A1 Feb. 9, 2017
0058. The eDocument instance 206 and the country spe initial mapping 721, second mapping 722, and second
cific instance are stored if both messages 518 and 519 return actions 723. These processes interact with the AIF database
SCCCSS, 724. Additionally, if an error occurs during the processes
0059 FIG. 6A is an exemplary user interface. The 706, the error is transmitted to an error collector 725, which
eDocument framework system 102 can have a user interface is then transmitted to error handling 708 process of the AIF
600 to display the documents, their status, and their pro 104. The error is subsequently communicated back via
cessing history. User interface 600 can include a window for communicate process 709 to the eldocument framework
selection of parameters 601, a window for selecting eldocu system for further processing. Additionally, first initial map
ment types 602, selection of eDocument billing documents ping 715 can transmit a result to AIF request mapping 712,
603, eDocuments accounting documents 604, eDocuments checks 717 can transmit a result to AIF generic map check
delivery documents 605, and other options for eDocuments 713, and second initial mapping can transmit a result to AIF
606. response mapping 714.
0060. Through this interface, a user to able to monitor 0066. During the processes 706, upon completion of the
and/or modified a specific elocument. The user interface first initial mapping 715, an AIF request mapping is gener
will allow appropriate actions to be taken when an eDocu ated. Upon completion of the checks 717, an AIF generic
ment cannot be processed automatically. The buttons dis map check is generated, and once the first actions 719
played depend on the country of the selected company code process is completed, a send generic action 710 is generated
in the window for selection of parameters 601. For the and transmitted to the eldocument framework system. After
eDocuments, it is possible to view the source documents by the second initial mapping, an AIF response mapping 714 is
type in the window for selecting eldocument types 602, generated, and after the second actions 723 process is
and/or by creation date (interval) 609. Source documents completed, a response generic action 711 is generated. The
that should have had an eDocument created can be selected response generic action 711 is also transmitted back to the
through the window 606. eDocument framework system 102.
0061 FIG. 6B is an exemplary elocument user interface 0067 FIG. 8 is a simplified diagram of an exemplary
607. eDocument user interface 607 includes the details of
the eDocument. It allows access to the Source documents database for use by the eLDocument framework system 102.
and also can include an AIF user interface for monitoring at Database 800 is a listing of the country specific additional
message level. Monitoring at message level allows for data arranged by country. Database 800 can include global
viewing of the originating document and the resulting docu database 801 and country specific database 802. Global
ment. database 801 can include the following databases: el Docu
0062 FIG. 6C is view of an exemplary history user ment database 502; eDocument history database 403;
interface 608, which allows viewing of the eLDocument eDocument file database 404; eDocument reference data
history database 403. The history user interface 608 displays base 405; and contingency database 807.
the eldocument history 609. Additionally, for the eDocu 0068 Country specific database 802 can be divided into
ments, it is possible to download the files generated or particular country databases. For example: Italy database
retrieved in the AIF user interface, eDocument user inter 808: Peru database 809; Chile database 810; Spain database:
face, and/or the history user interface 608 that have been and others 811. Each particular country database 808 to 711
sent or received during the different process steps. can further include individualized databases, which can
0063 eldocument user interface 607 and history user relate to specific technical requirements for the respective
interface 608 can display the following information: el Docu countries and eDocument type. For example, the Italy data
ment GUID. status, country code, country, source type, base 808 can include an invoice database 813, which
eDocument source key, eDoc. Type; eDoc. status; log sys includes all relevant technical requirements for invoices in
tem, changed on, change time, created by, create date, create Italy. Also, the Italy database 808 can include a notification
time, process, last step, version, eDocument status overview, database 814, which includes all relevant technical require
posting date, interflype, and approval. Other details can be ments for legally compliant notifications in Italy. The Peru
provided as well. Additionally, from the eldocument user database can include its own specific invoice database 815,
interface 607, a user can have access to certain commands. invoice Summary database 816, and a voided document
These commands can include, for example: refresh, create, database 817. Likewise, Chile can also include its own
Submit, Tax Authorities, customer, export file, history, and invoice database 818, invoice summary 819, and voided
Status. document databases 820. Spain can include its own invoice
0064 FIG. 7 is a simplified block diagram of the inter database 821 as well. As can be understood by the exemplar
actions between the system and the application interface structure of the database 800, the eDocument framework
framework. A user 702 interacts with the eDocument frame system is easily scalable.
work system 102, to initiate the resubmit program 704, 0069 FIG. 9 is a simplified diagram of an eldocument
which receives the specified eDocument 206 from the assigned process. Each eDocument 206 will have a process
eDocument database 502. Resubmit program 704 submits assigned. This defines the business process. When the
the eDocument 206 to the interface connector 203. The eDocument is created together with the process 901, a
interface connector 203 interacts with AIF 104, and is process version 904 is determined. The process 901 will
configured to send the eIDocument 206 to AIF 104. have an assigned list of valid process steps 906 and a list of
0065 AIF 104 receives the eDocument via AIF connect valid status flags 902. Process 901 will also have assigned
trigger 707. AIF connect trigger 707 processes the eDocu one or more process versions 904. One particular process
ment 206 via several processes 706: first initial mapping version 904 will have assigned a list of process steps 906
715, first mapping 716, checks 717, proxy 718, first actions that are valid for that process version 904, and an ordered list
719, new globally unique identifier (GUID) 720, second of status flags 902 that can be set in that process version 904.
US 2017/00391 75 A1 Feb. 9, 2017
The existence of process versions 904 allows changing the ping 1006, and databases 1005 interact with each other in
behavior (i.e., the valid steps, and the valid status flags) of order to processes the respective classes. Additionally, FIG.
a process along time. 10 illustrates the interaction between the classes included
0070. The process 901 will consist of one or more within each of the communication 1001, application 1002,
process steps 906. A process step 906 represents an action in persistence 1005, mapping 1006, and database 1005.
the eDocument framework system. The action can, for 0079 Although the foregoing description includes sev
example, be the triggering of an interface, printing or eral exemplary embodiments, it is understood that the words
cancelling of an el Document. The last process step 906 is that have been used are words of description and illustration,
included in the eDocument 206. Each eLDocument 206 type rather than words of limitation. Changes can be made within
can have a configurable set of processing steps 906. the purview of the appended claims, as presently stated and
Although the eDocument type is country specific, the coun as amended, without departing from the scope and spirit of
try will not be part of the key. The eldocument type is the disclosure in its aspects. Although the disclosure has
thought to be globally unique. The method and the class for been described with reference to particular means, materials
the method that will execute the step are defined as part of and embodiments, the disclosure is not intended to be
the table. limited to the particulars disclosed; rather the disclosure
(0071. On the base of the status of the eDocument 206 extends to all functionally equivalent structures, methods,
type, certain subsequent process steps 906 are allowed for and uses Such as are within the scope of the appended
the different types. The allowed steps are determined by claims.
verifying the status indicators that are relevant for each step. 0080. As used in the appended claims, the term “com
If these are set, then the step is allowed. The process steps puter-readable medium' can include a single medium or
will result in another state of the eDocument. This other state multiple media, such as a centralized or distributed database,
will be reflected in Status flags 902. The process status flag and/or associated caches and servers that store one or more
position 903 assigns the flag to a specific position in the sets of instructions. The term shall also include any medium
status field in the eDocument database 502. A process status that is capable of storing, encoding or carrying a set of
flag 902 can be assigned once per version. The process step instructions for execution by a processor or that cause a
version 905 can be the object used during runtime. The computer system to perform any one or more of the embodi
process step version 905 is the valid steps for the version. ments disclosed herein.
0072 FIG. 10 is a simplified diagram of an exemplary I0081. The computer-readable medium can comprise a
method of processing classes. FIG. 10 illustrates the inter non-transitory computer-readable medium or media and/or
action of AIF 104, Resubmit report 1001, communication comprise a transitory computer-readable medium or media.
1002, application 1003, persistence 1004, database 1005, In a particular non-limiting, exemplary embodiment, the
and mapping 106. Communication 1002, application 1003, computer-readable medium can include a solid-state
persistence 1004, and mapping 1006 can include specific memory Such as a memory card or other package that houses
technical objects that allow interaction. one or more non-volatile read-only memories. Further, the
0073 Communication 1002 can include class CL EDO computer-readable medium can be a random access memory
C INTERFACE CONNECTOR 1111, which encapsulates or other volatile re-writable memory. Additionally, the com
interface connector logic. eDocument framework system puter-readable medium can include a magneto-optical or
102 can instantiate this class and call different methods when optical medium, Such as a disk or tapes or other storage
the interface connector is required. device to capture carrier wave signals such as a signal
0074 Application 1003 can include the following communicated over a transmission medium. Accordingly,
classes: CL EDOC PROCESS 1112: CL EDOC UTIL the disclosure is considered to include any computer-read
1113, which includes eDocument utilities; CL EDOC able medium or other equivalents and Successor media, in
SOURCE 1114, which includes eDocument source data; which data or instructions can be stored.
CL EDOCUMENT 1115, which includes eDocument class I0082. The present specification describes components
information; CL EDOC SOURCE XXX 1116; and and functions that can be implemented in particular embodi
CL EDOCUMENT XX 1117 (XX stands for country spe ments which can operate in accordance with one or more
cific class). particular standards and protocols. However, the disclosure
0075 Mapping 1006 can include the following classes: is not limited to Such standards and protocols. Such stan
CL EDOC MAP 1121, which includes eldocument map dards periodically can be superseded by faster or more
ping information; CL EDOC MAP AIF 1122, which efficient equivalents having essentially the same functions.
includes eDocument Mapping and encapsulates AIF map Accordingly, replacement standards and protocols having
ping; CL EDOC MAP CUSTOM 1123, which provides the same or similar functions are considered equivalents
common interface to retrieve fix values maintained in AIF thereof.
104 or retrieve by a BAdI; and CL EDOC MAP XX 1124 0083. The illustrations of the embodiments described
(XX stands for country specific class). herein are intended to provide a general understanding of the
0076 Persistence 1005 can include the following classes: various embodiments. The illustrations are not intended to
CL EDOCUMENT XX DB 1118; CL EDOCUMENT serve as a complete description of all of the elements and
DB 1119; and CL EDOCU CONFIG DB 1120. features of apparatus and systems that utilize the structures
0077. Database 1005 can include the following: source or methods described herein. Many other embodiments can
documents tables 1007; country specific application tables be apparent to those of skill in the art upon reviewing the
1008; application tables 1009; and configuration tables disclosure. Other embodiments can be utilized and derived
1010. from the disclosure. Such that structural and logical Substi
0078 FIG. 10 generally illustrates how each of the com tutions and changes can be made without departing from the
munication 1001, application 1002, persistence 1005, map scope of the disclosure. Additionally, the illustrations are
US 2017/00391 75 A1 Feb. 9, 2017
merely representational. Accordingly, the disclosure and the 7. The method of claim 1, wherein the communication
figures are to be regarded as illustrative rather than restric between the system and the at least one of the cloud service
tive. provider and the partner service provider is implemented
0084. In addition, in the foregoing Detailed Description, through web services.
various features can be used together or without each other, 8. The method of claim 1, wherein at least part of the
or be grouped or described together the purpose of stream preparing of the generated eDocument is performed by an
lining the disclosure. This disclosure is not to be interpreted application interface framework (AIF).
as reflecting an intention that all Such features are required 9. The method of claim 1, wherein the eDocument is
to provide an operable embodiment, nor that the claimed implemented with at least one of the following databases:
embodiments require more features than are expressly an eDocument history database;
recited in each claim. Rather, as the following claims reflect, an eDocument file database;
subject matter may be directed to less than all of the features an eDocument reference database; and
of any of the disclosed embodiments. Thus, the following a country specific eDocument database.
claims are incorporated into the Detailed Description, with 10. The method of claim 2, further comprising:
each claim standing on its own as defining separately responsive to receiving the generated eDocument from
claimed subject matter. the system, the cloud service provider transmits the
0085 Also, where certain claims recite methods, eDocument to a local authority.
sequence of recitation of a particular method in a claim does 11. The method of claim 10, wherein the local authority
not require that that sequence is essential to an operable determines if the generated eDocument satisfies the techni
claim. Rather, particular method elements or steps could be cal requirements.
executed in different orders without departing from the 12. The method of claim 5, wherein a selection of the
Scope or spirit of the disclosure. interface connector is based on at least one of the following:
What is claimed is: a specific interface technology;
1. A computer-implemented method to manage, generate, a type of interface;
send, update, and monitor electronic documents (eIDocu a type of cloud services provider.
ments), the method comprising: 13. A system for generating, sending, updating, and
receiving an eDocument from at least one of a source monitoring electronic documents (eIDocuments), the system
document and a maintained eDocument; comprising:
mapping data to the received elocument, wherein the a process manager module configured to receive an
data is based on at least one of the source document, the eDocument from at least one of a source document and
maintained eDocument and at least one database; a maintained eDocument;
responsive to the mapping, generating an eDocument a document process module configured to generate an
based on the data mapped to the received eldocument; eDocument on the basis of data from at least one of the
displaying the generated eDocument to an user interface Source document, the maintained eDocument and at
to allow monitoring and updating of the generated least one database;
eDocument; an interface connector configured to perform the follow
preparing the generated eDocument for communication ing:
with at least one of a cloud service provider and a to map data to the received eDocument;
partner service provider; and to prepare the generated eDocument for transmission,
sending the generated eDocument to at least one of the to send the generated eDocument to at least one of a
cloud service and partner Service provider. cloud service provider and a partner service provider.
2. The method of claim 1, wherein the mapping of the data 14. The system of claim 13, wherein the mapping of data
to the received eDocument is performed within ERP soft to the received eDocument is performed within ERP soft
Wae. Wae.
3. The method of claim 1, wherein the at least one of the 15. The system of claim 13, wherein the at least one of the
Source document, the maintained eDocument, and the at Source document, the maintained eDocument, and the at
least one database includes at least one technical require least one database includes at least one technical require
ment, and wherein the at least one technical requirement is ment, and wherein the technical requirements are at least one
at least one of a country specific technical requirement and of country specific and eDocument specific.
an eDocument specific technical requirement. 16. The system of claim 13, wherein the at least one of the
4. The method of claim 1, wherein the at least one Source document, the maintained eDocument, and the at
database comprises at least one of a global database and at least one database includes at least one technical require
least one country specific database; and wherein the at least ment, and wherein the at least one technical requirement is
one country specific database includes at least one eDocu at least one of a country specific technical requirement and
ment specific database. an eDocument specific technical requirement.
5. The method of claim 2, wherein the generated eDocu 17. The system of claim 15, wherein the generated eDocu
ment conforms to the at least one technical requirement. ment conforms to the at least one technical requirement.
6. The method of claim 1, wherein at least part of the 18. The system of claim 13, wherein the eldocument is
eDocument processing is performed by an interface connec implemented with at least the following databases:
tor, wherein the interface connector is configured to perform an eDocument history database;
the following: an eDocument file database;
mapping data to the received eDocument; and an eDocument reference database; and
preparing the generated eDocument for sending. a country specific eDocument database.
US 2017/00391 75 A1 Feb. 9, 2017