| Step |
Description |
| In this example, the seller has
no existing B2B infrastructure, but does have PCs or workstations
and access to the Internet. The buyer is has a fully integrated
e-Business solution, and is using it to generate Purchase Orders
(PO) to suppliers. The buyer's back-end application has
functionality in place for extracting POs and posting PO responses.
The buyer's gateway receives all POs from the back-end application
and determines which get translated into a standard format and
transmitted to the seller via a VAN (connection to VAN could
be via dial-up or internet) or directly to the seller's gateway
via the internet, and which get translated and transmitted to
a Web application where suppliers can view documents and create
response documents. The Web application may be the buyer's
application running in the buyer's Virtual Private Network,
or may be a service provided by a 3rd party. |
| A. |
Preorder and planning processes
have occurred and the buyer is ready to create a PO. The
trading partners have a relationship already established; all
applications and parties involved in the exchange have the correct
configurations established, including registration of the trading
partnership and one or more VANs. |
| 1. |
The buyer creates a discrete PO
in the back-end application. The buyer may save it if
it is not ready to send, or may mark it as ready to be transmitted
and/or printed. |
| 2. |
Application software extracts the
PO into a data file for transmission to the EDI client application.
Assumption: Back-end interface generates proprietary format
or application-specific format such as SAP IDOC, Oracle data
file, Baan EDI file, and so on. An XSLT map may be used
to transform the data from one XML standard to another (if needed). |
| 3. |
If the Web application is in the
buyer's extranet/VPN, the buyer should still encrypt the data
for transport across the intranet firewall. If the Web
application is outsourced to a 3rd party, the document may be
authenticated electronically through the attachment of a digital
signature, and then encrypted in preparation for secure transporting. |
| 4. |
The data is decrypted. |
| 5. |
The PO is parsed and posted to the
Web application's data base. An XSLT map may be used to
transform the data for display in the Web application. |
| |
May use XSLT map to transform the
data for display in the Web application. |
| 6. |
If the order is successfully posted
to the Web application data base, a notification is created
and sent to the seller, informing of the need to login in and
read the order; if possible, the notification should include
the login URL. If the PO has a static URL, it may also
be included in the notification. |
| 7. |
A notification is created and sent
to the buyer informing the buyer whether the posting failed
or succeeded, that a notification was sent to the seller,
and what time the notification was sent. |
| 8. |
The buyer reads the buyer notification. |
| B. |
In end state B the buyer knows whether
or not the order has been successfully posted to the Web application. |
| 9. |
The seller reads the seller notification. |
| 10. |
The seller logs on and displays
the PO. |
| 11. |
The seller processes the PO, and
may simply print it, or manually enter the order data into a
back-end application. The Web application may provide
downloadable files in standard formats. A seller might
manually download a file and load it into a back-end system
as part of testing and transitioning to an integrated B2B solution.
Although most of it is performed manually, the business
processing is essentially the same as for an integrated process.
|
| 12. |
The TPA documents the buyer's
expectation turnaround time on response documents. Typically,
a buyer expects a PO response to be sent in 24 to 72 hours.
The seller should send a response within the required time limit,
indicating that the order was either accepted or rejected.
If the seller cannot confirm their ability to meet the buyer's
requirements for delivery, the seller should indicate in the
response that the commitment to requested dates and quantities
is pending, and then follow-up with another PO response as soon
as the commit information is available.
As a recommended best practice, the Web application should
create the PO response by flipping the PO and pre-populating
the PO response from the PO. If the seller can commit
to all the buyer's requested prices, quantities, and delivery
dates, the PO response needs no modification; alternatively,
the user can modify the PO response as needed.
While the e-mail notification in step 7 indicates that the
PO was posted to the Web application, the PO response
tells the buyer that the seller actually read it.
|
| 13. |
The seller uses a save function
to post the PO response to the Web application data base. |
| 14. |
If the PO response is not ready
to send to the buyer, the seller may save it without marking
it for send, and then re-display and modify the PO response
data when ready. |
| 15. |
The seller uses a save function
to update the PO response in the Web application data base.
|
| 16. |
If the PO response is ready to send
to the buyer, the seller marks it for send. |
| 17. |
Web application software extracts
the PO response into a data file for transmission to the buyer's
gateway inside the firewall. |
| 18. |
The gateway unwraps, validates and
translates the data file into the format expected by the back-end
application. |
| 19. |
The buyer processes the PO response
to load it into their back-end application. It indicates
that the seller either accepts or rejects the PO. |
contact
us 
