|
Home
Objectives
Requirements
VCU Policies
Email
Enterprises
Grades
Naming Conventions
The Assignment
Chart of Accounts
Quiz #1
Debits & Credits
Sample Accounting
Structure
Warnier Usage
Take On Customers
Project #1
Database
Table Maint Prototype
Make it Portable
Common Problems
Project #2
PB Prototype
Linux Prototypes
MAPI?
ANSI X.12
pseudo X12
Displaying JVs
Display JV VB.NET
CAT --> Text
Email CAT PB
Email CAT VB.NET
Sample Quiz 2
DataWindowChild
Project #3
Ledger Engine
Quiz #3
Table Of Contents
| |
psX12 standards revised 9/24/2003:
| For our purposes in this course, we're implementing
a few transactions and not a dozen or more as would be implemented for 'Real
EDI'. The Real EDI standards are not open for use in the
public domain, so these EDI-like transactions are formatted using
pseudo-X12 standards as
below: Catalog, Journal Voucher, Request services, Purchase Order, & Invoice. To
make matters simpler than Real EDI, these psX12 documents are transmitted as body text in email and are sent and
received using MAPI objects to and from each of our Enterprises' desktop systems.
These psX12 standards are just bare sketches of their real-world EDI counterparts -- but this course
is
only a semester in length...
Real EDI documents are embedded in a hierarchical control structure
that assures either an accurate transmission of a complete transaction or some error
message arising if anything gets scrambled. We'll dispense with
this page full of nested data structures and use a separate email message
for each psX12 transaction. The email has a psX12 signature of
*!*! or !*!* in the first 4 positions of the SubjectLine of the
message.
ANSI X12 breaks each transaction into Segments,
separated from one another in sequence by CrLf. So does
psX12: Each field in the segment is asterisk-delimited,
and the first is a Segment Identifier code such as JV or NET which
identifies the purpose of the segment. JV is the first line in
the body of a psX12 Journal Voucher. NET segments contain
fields with the Ledger Account and Net amount vouchered that date.
Note that psX12 is mostly an Upper Case
standard & all 'Segment Identifier' codes are in UPPER CASE
letters. Stray spaces, empty lines, or anything not
specifically expected in the standard should result in a transaction
being rejected by the receiving Enterprise or Ledger Engine.
Here are the psX12 Standards:
 |
All Enterprise psX12 Subject Lines
are formatted as:
*!*!9009*19991030191515
The splat bang splat bang prefix identifies the email as containing a
transaction from enterprise 9009 -- replace 9009 with the id# for your Enterprise.
The date & time in yyyymmddhhmmss format is in the second field.
Responses from the Ledger Engine start with !*!* and text
indicating the contents of the response: ERROR, JV, CAT, REQUEST*CAT, or REQUEST*JOURNALS.
|
| A Catalog transaction transaction is sent as NoteText in
email for the Ledger Engine's Catalog function. These transactions allow Enterprises
to post, update, and delete entries in the Ledger Engine's Catalog. When you are
ready to receive Purchase Orders from other Enterprises send a Catalog transaction to the
Ledger Engine. Enterprises may request the most current catalog
listing by sending email with REQUEST*CAT as
the first line of the email's NoteText line as described below.
The format for Catalog transactions is:
CAT*9009*19991030191515
ITEM*9*Text Describing Item*9900
ITEM*10*DELETE
ECAT*4*19
CAT* identifies the document as a Catalog transaction
from
Enterprise 9009 on October 30 of 1999. CAT* identifies the document
as a Catalog transaction from Enterprise 9009 on October 30 of 1999. CAT*
identifies the document as a Catalog transaction from Enterprise 9009 on October 30 of
1999. CAT* identifies the document as a Catalog transaction from
Enterprise 9009 on October 30 of 1999. CAT* identifies the document
as a Catalog transaction from Enterprise 9009 on October 30 of 1999. CAT*
identifies the document as a Catalog transaction from Enterprise 9009 on October 30 of
1999.
ITEM* identifies each line offered for or deleted from the
Catalog. The second field contains an integer which is the GS Id# of the item in the
offering Enterprise's system. Text describing the item may be up to 40 characters in
length. 9900 represents the price of the item, assuming 2 digits of precision.
If the 3rd field contains DELETE and the item identified in the 2nd field exists in the
Ledger Engine's catalog the item will be deleted.
ECAT* show the last line of the Catalog transaction. The 4
represents the number of lines transmitted including CAT and ECAT. The 19 represents
a hash total of the GS Id#s in the transaction.
A valid CAT transaction gets a response from the Ledger Engine
formatted as !*!*CAT Response from the Ledger Engine.
An Enterprise may request a current Catalog by sending email to
the Ledger Engine with subject line formatted as above and with NoteText REQUEST*CAT.
Email will be returned to the address registered with the Ledger Engine with a Subject
Line !*!*REQUEST*CAT Response from the Ledger Engine with NoteText containing
Catalog Items formatted as:
EID*9009*Enterprise
Name*emailaddress@someplace.com
CAT*9009*99*Description*9900*20000630091545
CAT*9009*100*Next Description*1200*20000630091545
EID*9019*Ye Olde Enterprise*emailaddress@anotherplace.com
CAT*9019*11*Another Description*12345*20000730091545
CAT*9019*12*Description*1234*20000730091545
EID* lines start each Enterprise's section in the catalog. 9009
& 9019 are IDs of the
Enterprises submitting the catalog items. The 3rd field is the name of the
Enterprise. The fourth field is the email address where the Enterprise will receive
purchase orders.
CAT* lines contain Catalog entries for the Enterprise. The
Enterprise ID is repeated in the 2nd field of each entry. The 3rd field, 99 in the
1st set of entries above is their Goods & Services ID. Description is up to 45
characters describing the item. This is followed by the price, assuming 2 decimal
places. The last field is the datetime that the item was last updated.
|
| JV is Journal Voucher. These are transmitted to
the Ledger Engine following the close of each Accounting Date. Retransmitting a JV
with the same EntityId and Date will cause the Ledger Engine to back out the prior journal
for the day and post the most recently received one. The
Subject Line is formatted as above.
Transmitting a valid JV will result in a new financial statement being
generated by the Ledger Engine, current thru the valid JV, which is emailed to the
address of the Enterprise with a subject line formatted as !*!*JV Response from the
Ledger Engine.
Transmitting an invalid JV to the Ledger Engine will result in an error
message being emailed to your enterprise, if the ledger engine is able to determine the
email address of the sending enterprise.
Our major 'check & balance' for each team's Enterprise system is
that it be able to produce reports locally that show the details which balance the Ledger
Accounts kept by the Ledger Engine.
|
The format for the JV in the NoteText of the email is:
JV*9009*19991030
ENT*123400*1000
ENT*90090*1010*TEXT
ENT*-213490*4000
JVE*5
JV* identifies the document as a JV from Enterprise 9009
journalizing activity for October 30 of 1999.
ENT* identifies each entry in the JV. The
second field on the ENT* line contains the net amount for that
account and date. A positive # (assumed if
no -) for a debit and a negative # (indicated by a leading -) for a credit.
There is not a decimal point in the amount -- psX12 always assumes
two decimal points for dollar amounts & quantities.
If you are using a ledger account that is not in the
'standard
chart of accounts' you can place the TEXT for that account in a third field and the Ledger Engine will use
that as the text for the account number when it returns your trial
balance.
The ENT lines are the total of details'
extensions & are grouped by Ledger Account.
It is not valid for a JV to have more than one ENT line per Ledger
Account.
JVE* identifies the JV's Ending, in which the second field
contains a number equal the the number of lines (including the JV and the
JVE) in the
document.
The total of the ENT amounts in a valid psX12 JV will always 'net zero.'
| A report of all JVs posted for an Enterprise will be returned to the email
address registered for the Enterprise. Send email to the Ledger Engine with a psX12
subject line valid for your Enterprise and NoteText of
REQUEST*JOURNALS.
|
| A Purchase Order (PO) is transmitted as NoteText
in Email formatted as:
PO*9999*9900*19991030191515*1001
PDET*99*9900*200
PDET*99*1250*100*Ship to Attn*Name*Extra*Street*PO*Zip
EPO*4*21050
PO* signifies the start of a Purchase Order. On this line,
9999=From Enterprise; 9900=To Enterprise; 19991030191515=DateTime;1001=PO Number in the
From enterprise's system.
PDET* Identifies Purchase Order DETail lines. The second field,
99, is the GSID (Goods&Services ID# from the Enterprise's catalog entry). The third
field, 9900, is for Price, with two decimals assumed. The fourth is for Quantity, also with two decimals assumed -- A qty 1 would be sent as 100, 1.5
would be sent as 150.
OptionalIy: fields 5, 6, 7, 8, 9 & 10 may be used for: ShipToAttention;
ShipToCompanyName; ShipToExtraLine; ShipTo Street; ShipToPostOffice; and ShipToZip.
If these fields are blank then use the address of the customer as both the invoice to and
ship to address.
There can be as many PDET lines as needed.
EPO* shows the End of a PO. The second field is the count of lines in the
document, including the PO and EPO lines. The third field is the total price
reflected on the PO (Sum of Qty * Price for each PDET) with two decimals assumed.
Valid Purchase Orders in our system will get an INVoice
generated and emailed back to the customer from the supplier. Invalid Purchase
Orders will get an error message if the supplier's system is able to identify the sender.
|
| An Invoice is sent as NoteText in email & formatted:
INV*9900*9999*19991030191515*1009*1001
IDET*15*10150*900
IDET*16*12500*100*Attn*Extra*Name*Street*PostOffice*Zip
EINV*4*103850
INV* identifies the first line of an INVoice transaction.
The second field is the ID# of the compnay to whom the INVoice is being sent. The
3rd field is the ID# of the supplier sending the invoice. The 4th field is the
DateTime as above. The fifth field is the Purchase Order #, assigned by the
supplier. The sixth field is the Customer's Purchase Order# referenced by the
PO.
|
Small print: In our fictitious Enterprises we assume that all Purchase
Orders are shipped as ordered, pretty much instantly, using free transport, and with
instant recognition of either cash or accounts receivable/payable as determined by the
Enterprise receiving the PO.
Tender details are not included in psX12 transactions although the
INVOICE that results when a PO is received has the tender stored in a detail in the
receiving Enterprise's database And the details of the Purchase Order from which the
psX12 PO transaction is formatted include a Tender detail in the sending Enterprise's
database.
IDET is formatted the same as PDET above. Qty and Price/Cost Each assume two decimal places. If this INV
transaction is the result of a PO in which the enterprise's customer has requested drop
ship the additional fields for extra line, name, address, post office, and zip code where
the item was shipped should be included.
EINV follows the same rule as EPO above.
|
|
|
