search

ethereum-oasis-op / baseline-roadmap

31 stars 11 forks source link

EDI Integration Kit (EDIFACT / X12) #51

Closed humbitious closed 2 years ago

humbitious commented 4 years ago

Electronic data interchange(EDI) enables paperless and automatic electronic communications between businesses by providing both standardized data structures and a defined data interchange process. Developed to replace paper-based communications such as purchase orders or invoices, EDI standards evolved to include other information used to increase operational efficiency and more quickly enable business decisions. Developed in the 1970’s; a dwindling talent pool, cheaper technologies, and high overhead have recently called into question the use of EDI, though no solution has yet to match the universal acceptance of EDI processes and standards.

The supply chain industry is the largest user of EDI processes and standards, with an estimated 59-85% of companies using EDI as their preferred means of data transfer. Other sectors have adopted industry-specific EDI standards that have gained universal use and further expanded the EDI ecosystem. The most widely used EDI standards in use by businesses today are X12- used in North American communications- and EDIFACT - used in international transactions. Subsets of these standards include the medical industries HIPPA EDI based on X12, and supply chains GS1 EDI based on EDIFACT. EDI documents in each standard are defined by transaction sets, each analogous to a single document built to serve a specific purpose.

In order to gain widespread acceptance and increase adoption in B2B applications, any solution meant to act as a common frame of reference in data interchange processes should be capable of interaction with EDI processes in standard formats X12 and EDIFACT.

johnmonarch commented 4 years ago

Requirements:

List required forms and document types for each

Attached is sample X12 850 form messaging

https://app.zenhub.com/files/258320699/aadce91f-88bb-4549-8229-2b082d6e4640/download

djones0 commented 4 years ago

EDIFACT official Information directory

humbitious commented 4 years ago

Excited about this one. Suggesting that we do the multiparty project #48 as a dependency, so that we can then show multiparty-EDI. OR, maybe this is an EDI kit, so that an EDI demo would have this and #48 as a dependency. Thoughts? Timeline?

djones0 commented 4 years ago

Value Added Networks

Barriers to entry for EDI implementation are relatively high due to programming cost, so several providers of EDI services offer a SaaS based model that integrates a network of EDI capable ERP’s and other EDI communication portals through a single entry point. This network of integrations is known as a Value Added Network(VAN). Connecting with these networks that already have access to most ERPs would provide integration support to a large majority of ERPs with a single integration. This would quickly expose baseline services to a large number of EDI users, though may increase cost per EDI transaction due to VAN fees.

djones0 commented 4 years ago

5.14.2020– Slack chat re: EDI discussion https://ethereum-baseline.slack.com/archives/CTBN1V18X/p1589380737499100

pappas999 commented 4 years ago

Agreed with comments re: VANs, it would get a great quick win,, however the overall transaction costs ends up being slightly higher because its now the cost of using the VAN + cost of baselining right? But it would definitely 'open the gate' to more potential users due to the VAN providing the existing EDI integrations between the company using baseline & other non baselined companies using traditional EDI methods.

I believe the ultimate end goal for baseline in regards to EDI messaging is to 'cut out' these third party VAN/ EDI gateways from the process, therefore significantly reducing the cost of EDI for businesses that typically use them. VANs typically charge for their service, eg $x per EDI message or y characters in a message, + yearly subscription fee, + any support fees + onboarding fees for new vendors/participants in the EDI network etc. For small business this may not add up to much, but for large vendors, retailers & participants in supply chains that do business with tens of thousands of others this adds up to a decent chunk of their yearly IT budgets. In terms of communication & standards, as stated there are multiple standards, there are also multiple transmission methods (AS2, FTP etc) as well as multiple b2b transmission methods, (direct/peer to peer, via an EDI gateway/Value Added Network).

As a solution EDI works well today & is tried & tested, but I believe the true value proposition for using baseline + mainnet here is to greatly minimize this cost by allowing vendors to securely send/receive EDI documents among themselves in a chosen standardized format, & without the need for using their respective VANs.

While I'm still coming up to speed in the technical aspects of what exactly 'baseline' does, here's how I can see a simple example working, ignoring any technical limitations, storage requirements or standardization considerations. Sorry if it's a bit long winded (might be better in a diagram)

Say Company A wants to order 500 blue flannel shirts from Company B:

1 - Company A raises PO (Purchase Order) for 500 shirts from Company B in their system of record (say Oracle JDE)

2 - Oracle JDE 'connector' takes PO message in Oracles format, formats it to standardized format. PO is baselined & transmitted to Company B

3 - Company B converts standard PO message to their System of Record (say SAP) required format & ingests. Company B is now in sync with Company A in regards to the PO.

4 - Company B ships the shirts & generates an ASN (Advanced Shipment Notice) EDI message from their Warehouse Management System), this is converted to standard format, then baselined & sent back to company A.

5 - Company A receives the ASN EDI message, converts back to their Oracle format & ingests. Company A & B now in sync in regards to the PO & ASN.

6 - The box of shirts shows up at Company & they follow their receiving procedure for receiving stock. Their Oracle system of record generates a Receipt/RECADV EDI message, which is once again converted to standard format, baselined & transmitted to company B. Company B receives, converts back to their required SAP format & ingests. Companies now in sync in regards to the PO & Receipt

7 - Company B generates an invoice from their SAP system, this is converted to standard format, baselined + transmitted to company A.

8 - Company A receives EDI Invoice, converts to their required Oracle EBS format & ingests

End result is both companies are now in sync in regards to the whole flow from PO to Invoice, no VAN or third party was involved, no EDI data stored on chain, only costs were GAS costs for baselining. And the mainnet acted as a common frame of reference & 'engine' or 'heart' for handling the logic of the entire flow in a safe & secure way. Also note that no acknowledgment EDI messages (eg Purchase Order Acknowledgment) were required between the companies thanks to the design philosophy of baseline, proofs & having a common frame of reference.

Obviously a solution like this has initial costs & complexities as already stated, & real savings aren't realized unless a 'network effects' takes place where multiple participants in the network start baselining. Eg if a business deals with 1000 vendors, but only 5 of them have their systems baselined, then you're still paying for a VAN for the other 99.5% of EDI messages.

djones0 commented 4 years ago

Great points-- the transaction costs would almost definitely be higher. I see VAN connectivity as the initial MVP/pilot phase that could double as a pretty big exposure opportunity with the cherries on top of providing time to validate and iron out any wrinkles. Once validated in a VAN environment, development should start on more direct means of EDI interaction.

Agree with the example flow you gave. The baselining action could be bounced around to a couple different steps , but I don't think moving that around really changes that flow much. I'm working on a diagram of possible flows and would love input. Once it's finished I'll post it here--

sambacha commented 4 years ago

We are already doing this in production with X12 and EDIFACT, we are working on US Customs right now, should be done within 45 days on their side.

Let us know what we can contribute, I also posted on the boards about porting from XML to a JSON schema and the difficulties in this. We have a fork of OpenAPI that can handle JSON hyperschema (not an official RFC yet).

Main issue is mapping and parser, we have a custom DSL (domain-specific language, more of a limited scripting language than anything) that can handle the mapping for X12 and EDIFACT. The issue is OFTP2 in EDIFACT for us right now, we are working on that support for in client as its a different system than AS2/AS4.

My comment on the baseline board's about XML to JSON: https://lists.oasis-open-projects.org/g/baseline/topic/the_issue_with_xml_and_json/74260417?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,74260417

Here is our repo for the OpenAPI compatible EDI messages: https://github.com/freight-chain/ediclear/tree/master/openapi/components

Here is a swagger interface: https://app.swaggerhub.com/apis/freight-chain/XEDI/2

Note it should be v2.0.0 of swagger/openapi, not v3.0.0

sambacha commented 4 years ago

Great points-- the transaction costs would almost definitely be higher. I see VAN connectivity as the initial MVP/pilot phase that could double as a pretty big exposure opportunity with the cherries on top of providing time to validate and iron out any wrinkles. Once validated in a VAN environment, development should start on more direct means of EDI interaction.

Agree with the example flow you gave. The baselining action could be bounced around to a couple different steps , but I don't think moving that around really changes that flow much. I'm working on a diagram of possible flows and would love input. Once it's finished I'll post it here--

We are running Hyperledger Besu with an embedded in-protocol system for raw EDI transaction passage

there are additional issues not addressed we have found over the last year of doing this, that I can go over if interested

sambacha commented 4 years ago

Agreed with comments re: VANs, it would get a great quick win,, however the overall transaction costs ends up being slightly higher because its now the cost of using the VAN + cost of baselining right? But it would definitely 'open the gate' to more potential users due to the VAN providing the existing EDI integrations between the company using baseline & other non baselined companies using traditional EDI methods.

I believe the ultimate end goal for baseline in regards to EDI messaging is to 'cut out' these third party VAN/ EDI gateways from the process, therefore significantly reducing the cost of EDI for businesses that typically use them. VANs typically charge for their service, eg $x per EDI message or y characters in a message, + yearly subscription fee, + any support fees + onboarding fees for new vendors/participants in the EDI network etc. For small business this may not add up to much, but for large vendors, retailers & participants in supply chains that do business with tens of thousands of others this adds up to a decent chunk of their yearly IT budgets. In terms of communication & standards, as stated there are multiple standards, there are also multiple transmission methods (AS2, FTP etc) as well as multiple b2b transmission methods, (direct/peer to peer, via an EDI gateway/Value Added Network).

As a solution EDI works well today & is tried & tested, but I believe the true value proposition for using baseline + mainnet here is to greatly minimize this cost by allowing vendors to securely send/receive EDI documents among themselves in a chosen standardized format, & without the need for using their respective VANs.

While I'm still coming up to speed in the technical aspects of what exactly 'baseline' does, here's how I can see a simple example working, ignoring any technical limitations, storage requirements or standardization considerations. Sorry if it's a bit long winded (might be better in a diagram)

Say Company A wants to order 500 blue flannel shirts from Company B:

1 - Company A raises PO (Purchase Order) for 500 shirts from Company B in their system of record (say Oracle JDE)

2 - Oracle JDE 'connector' takes PO message in Oracles format, formats it to standardized format. PO is baselined & transmitted to Company B

3 - Company B converts standard PO message to their System of Record (say SAP) required format & ingests. Company B is now in sync with Company A in regards to the PO.

4 - Company B ships the shirts & generates an ASN (Advanced Shipment Notice) EDI message from their Warehouse Management System), this is converted to standard format, then baselined & sent back to company A.

5 - Company A receives the ASN EDI message, converts back to their Oracle format & ingests. Company A & B now in sync in regards to the PO & ASN.

6 - The box of shirts shows up at Company & they follow their receiving procedure for receiving stock. Their Oracle system of record generates a Receipt/RECADV EDI message, which is once again converted to standard format, baselined & transmitted to company B. Company B receives, converts back to their required SAP format & ingests. Companies now in sync in regards to the PO & Receipt

7 - Company B generates an invoice from their SAP system, this is converted to standard format, baselined + transmitted to company A.

8 - Company A receives EDI Invoice, converts to their required Oracle EBS format & ingests

End result is both companies are now in sync in regards to the whole flow from PO to Invoice, no VAN or third party was involved, no EDI data stored on chain, only costs were GAS costs for baselining. And the mainnet acted as a common frame of reference & 'engine' or 'heart' for handling the logic of the entire flow in a safe & secure way. Also note that no acknowledgment EDI messages (eg Purchase Order Acknowledgment) were required between the companies thanks to the design philosophy of baseline, proofs & having a common frame of reference.

Obviously a solution like this has initial costs & complexities as already stated, & real savings aren't realized unless a 'network effects' takes place where multiple participants in the network start baselining. Eg if a business deals with 1000 vendors, but only 5 of them have their systems baselined, then you're still paying for a VAN for the other 99.5% of EDI messages.

This is for the most part correct, no VAN or 3rd Party would imply ad-hoc. In reality, large enterprises use solutions like kleinschmidt or blujay. here is a sample of data that a customer of ours released to us for usage publicly of an amendment process. This is the workflow process for if there is an issue with an invoice/bill of lading.

https://gist.github.com/sambacha/2cd1b4564d1796ae0b89519838d5f99b

Let me know if you have any questions

sambacha commented 4 years ago

Here is an example from the Oracle side in your example from our gateway:

///
//
//
Field Description            Category   Rec    Format   Pos WidthStartRec.Qual.     Interface Table          Interface Column
///
RECORD 0010 (INI)
Common Key (Positions 1-91)                     0010  Varchar2       91    1
Record Number                                   0010  Varchar2        4   92           Constant '0010'
Record Layout                                   0010  Varchar2        2   96           Constant 'CT'
Record Layout Qualifier                         0010  Varchar2        3   98           Constant 'CTL'
Communication Method                            0010  Varchar2  10    2   101  CT  CTL
Test Indicator                                  0010  Varchar2  20    1   103  CT  CTL
Document ID                                     0010  Varchar2  30    6   104  CT  CTL Constant 'POI'
Document Type                                   0010  Varchar2  40    5   110  CT  CTL
Document Purpose Code                           0010  Varchar2  50    2   115  CT  CTL
Document Code                                   0010  Varchar2  60   35   117  CT  CTL
Trading Partner Translator Code                 0010  Varchar2  70   30   152  CT  CTL
Trading Partner Location Code                   0010  Varchar2  80   35   182  CT  CTL
Trading Partner Description                     0010  Varchar2  90   74   217  CT  CTL
Trading Partner Reference 1                     0010  Varchar2  100  80   291  CT  CTL
Trading Partner Reference 2                     0010  Varchar2  110  80   371  CT  CTL
Transaction Date/Time                           0010    Date    120  15   451  CT  CTL
Transaction Run ID                              0010   Number   130  15   466  CT  CTL
Transaction Control 1 (Inbound)                 0010   Number   140  10   481  CT  CTL
Transaction Control 2 (Inbound)                 0010   Number   150  10   491  CT  CTL
Transaction Control 3 (Inbound)                 0010   Number   160  10   501  CT  CTL

RECORD 1000 (INI)
Common Key (Positions 1-91)                     1000  Varchar2       91    1
Record Number                                   1000  Varchar2        4   92           Constant '1000'
Record Layout                                   1000  Varchar2        2   96           Constant 'IV'
Record Layout Qualifier                         1000  Varchar2        3   98           Constant 'IV1'
Invoice Number                                  1000 Varchar2   10   50   101  IV  IV1 AP_INVOICE_INTERFACE      INVOICE_NUM
Invoice Date                                    1000    Date    20   15   151  IV  IV1 AP_INVOICE_INTERFACE      INVOICE_DATE
Purchase Order                                  1000  Varchar2  30   20   166  IV  IV1 AP_INVOICE_INTERFACE      PO_NUMBER
Total Invoice Amount                            1000  Varchar2  40   22   186  IV  IV1 AP_INVOICE_INTERFACE      INVOICE_AMOUNT
Invoice Type (Internal)           INVOICE_TYPE  1000  Varchar2  50   25   208  IV  IV1 AP_INVOICE_INTERFACE      INVOICE_TYPE_LOOKUP_CODE
Invoice Type (ext1)                             1000  Varchar2  60   25   233  IV  IV1
Terms Name (Internal)             PAYMENT_TERMS 1000  Varchar2  70   50   258  IV  IV1 AP_INVOICE_INTERFACE      TERMS_NAME
Terms Name (Ext 1)                              1000  Varchar2  80   10   308  IV  IV1
Terms Name (Ext 2)                              1000  Varchar2  90   10   318  IV  IV1
Terms Name (Ext 3)                              1000  Varchar2  100  10   328  IV  IV1
Terms Name (Ext 4)                              1000  Varchar2  110  10   338  IV  IV1
Terms Name (Ext 5)                              1000  Varchar2  120  10   348  IV  IV1

RECORD 1010 (INI)
Common Key (Positions 1-91)                     1010  Varchar2       91    1
Record Number                                   1010  Varchar2        4   92           Constant '1010'
Record Layout                                   1010  Varchar2        2   96           Constant 'IV'
Record Layout Qualifier                         1010  Varchar2        3   98           Constant 'IV2'
Invoice Currency Code (Internal)    CURRENCY    1010  Varchar2  10   15   101  IV  IV2 AP_INVOICE_INTERFACE      INVOICE_CURRENCY_CODE
Invoice Currency Code (Ext1)                    1010  Varchar2  20    5   116  IV  IV2 AP_INVOICE_INTERFACE
Currency Exchange Rate                          1010   Number   30   22   121  IV  IV2 AP_INVOICE_INTERFACE      EXCHANGE_RATE
Currency Exchange Date                          1010    Date    40   15   143  IV  IV2 AP_INVOICE_INTERFACE      EXCHANGE_DATE

RECORD 1020 (INI)
Common Key (Positions 1-91)                     1020  Varchar2       91    1
Record Number                                   1020  Varchar2        4   92           Constant '1020'
Record Layout                                   1020  Varchar2        2   96           Constant 'AD'
Record Layout Qualifier                         1020  Varchar2        3   98           Constant 'VS1'
Vendor Site Code (Internal)        VENDOR_SITE  1020  Varchar2  10   15   101  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_CODE
Vendor Site Code (Ext1)                         1020  Varchar2  20   20   116  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_CODE_EXTERNAL
Vendor Site Customer Name                       1020  Varchar2  30   60   136  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_NAME
Vendor Site Address 1                           1020  Varchar2  40   35   196  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_ADDRESS1
Vendor Site Address 2                           1020  Varchar2  50   35   231  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_ADDRESS2
Vendor Site Address 3                           1020  Varchar2  60   35   266  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_ADDRESS3
Vendor Site Address 4                           1020  Varchar2  70   35   301  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_ADDRESS4
Vendor Site City                                1020  Varchar2  80   30   336  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_CITY
Vendor Site Postal Code                         1020  Varchar2  90   15   366  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_POSTAL_CODE
Vendor Site Country (Internal)       COUNTRY    1020  Varchar2  100  20   381  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_COUNTRY_INT
Vendor Site Country (Ext1)                      1020  Varchar2  110   3   401  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_COUNTRY_EXT
Vendor Site State (Internal)          STATE     1020  Varchar2  120  20   404  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_STATE_INT
Vendor Site State (Ext1)                        1020  Varchar2  130  10   424  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_STATE_EXT
Vendor Site Province (Internal)     PROVINCE    1020  Varchar2  140  20   434  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_PROVINCE_INT
Vendor Site Province (Ext1)                     1020  Varchar2  150  10   454  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_PROVINCE_EXT
Vendor Site County                              1020  Varchar2  160  43   469  AD  VS1 AP_INVOICE_INTERFACE      VENDOR_SITE_COUNTY

RECORD 2000 (INI)
Common Key (Positions 1-91)                     2000  Varchar2       91    1
Record Number                                   2000  Varchar2        4   92           Constant '2000'
Record Layout                                   2000  Varchar2        2   96           Constant 'A1'
Record Layout Qualifier                         2000  Varchar2        3   98           Constant 'IV1'
Invoice Flexfield Context                       2000  Varchar2  10   30   101  A1  IV1 AP_INVOICE_INTERFACE      ATTRIBUTE_CATEGORY
Invoice Flexfield 1                             2000  Varchar2  20   80   131  A1  IV1 AP_INVOICE_INTERFACE      ATTRIBUTE1
Invoice Flexfield 2                             2000  Varchar2  30   80   211  A1  IV1 AP_INVOICE_INTERFACE      ATTRIBUTE2
Invoice Flexfield 3                             2000  Varchar2  40   80   291  A1  IV1 AP_INVOICE_INTERFACE      ATTRIBUTE3
Invoice Flexfield 4                             2000  Varchar2  50   80   371  A1  IV1 AP_INVOICE_INTERFACE      ATTRIBUTE4

RECORD 2010 (INI)
Common Key (Positions 1-91)                     2010  Varchar2       91    1
Record Number                                   2010  Varchar2        4   92           Constant '2010'
Record Layout                                   2010  Varchar2        2   96           Constant 'A2'
Record Layout Qualifier                         2010  Varchar2        3   98           Constant 'IV2'
Invoice Flexfield 5                             2010  Varchar2  10   80   101  A2  IV2 AP_INVOICE_INTERFACE      ATTRIBUTE5
Invoice Flexfield 6                             2010  Varchar2  20   80   181  A2  IV2 AP_INVOICE_INTERFACE      ATTRIBUTE6
Invoice Flexfield 7                             2010  Varchar2  30   80   261  A2  IV2 AP_INVOICE_INTERFACE      ATTRIBUTE7
Invoice Flexfield 8                             2010  Varchar2  40   80   341  A2  IV2 AP_INVOICE_INTERFACE      ATTRIBUTE8
Invoice Flexfield 9                             2010  Varchar2  50   80   421  A2  IV2 AP_INVOICE_INTERFACE      ATTRIBUTE9

RECORD 2020 (INI)
Common Key (Positions 1-91)                     2020  Varchar2       91    1
Record Number                                   2020  Varchar2        4   92           Constant '2020'
Record Layout                                   2020  Varchar2        2   96           Constant 'A2'
Record Layout Qualifier                         2020  Varchar2        3   98           Constant 'IV3'
Invoice Flexfield 10                            2020  Varchar2  10   80   101  A2  IV3 AP_INVOICE_INTERFACE      ATTRIBUTE10
Invoice Flexfield 11                            2020  Varchar2  20   80   181  A2  IV3 AP_INVOICE_INTERFACE      ATTRIBUTE11
Invoice Flexfield 12                            2020  Varchar2  30   80   261  A2  IV3 AP_INVOICE_INTERFACE      ATTRIBUTE12
Invoice Flexfield 13                            2020  Varchar2  40   80   341  A2  IV3 AP_INVOICE_INTERFACE      ATTRIBUTE13
Invoice Flexfield 14                            2020  Varchar2  50   80   421  A2  IV3 AP_INVOICE_INTERFACE      ATTRIBUTE14

RECORD 2030 (INI)
Common Key (Positions 1-91)                     2030  Varchar2       91    1
Record Number                                   2030  Varchar2        4   92           Constant '2030'
Record Layout                                   2030  Varchar2        2   96           Constant 'A2'
Record Layout Qualifier                         2030  Varchar2        3   98           Constant 'IV4'
Invoice Flexfield 15                            2030  Varchar2  10   80   101  A2  IV4 AP_INVOICE_INTERFACE      ATTRIBUTE15

RECORD 2100 (INI)
Common Key (Positions 1-91)                     2100  Varchar2       91    1
Record Number                                   2100  Varchar2        4   92           Constant '2100'
Record Layout                                   2100  Varchar2        2   96           Constant 'A1'
Record Layout Qualifier                         2100  Varchar2        3   98           Constant 'HG1'
Invoice Global Flexfield Context                2100  Varchar2  10   80   101  A1  HG1 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE_CATEGORY
Invoice Global Flexfield 1                      2100  Varchar2  20   80   181  A1  HG1 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE1
Invoice Global Flexfield 2                      2100  Varchar2  30   80   261  A1  HG1 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE2
Invoice Global Flexfield 3                      2100  Varchar2  40   80   341  A1  HG1 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE3
Invoice Global Flexfield 4                      2100  Varchar2  50   80   421  A1  HG1 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE4

RECORD 2110 (INI)
Common Key (Positions 1-91)                     2110  Varchar2       91    1
Record Number                                   2110  Varchar2        4   92           Constant '2110'
Record Layout                                   2110  Varchar2        2   96           Constant 'A2'
Record Layout Qualifier                         2110  Varchar2        3   98           Constant 'HG2'
Invoice Global Flexfield 5                      2110  Varchar2  10   80   101  A2  HG2 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE5
Invoice Global Flexfield 6                      2110  Varchar2  20   80   181  A2  HG2 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE6
Invoice Global Flexfield 7                      2110  Varchar2  30   80   261  A2  HG2 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE7
Invoice Global Flexfield 8                      2110  Varchar2  40   80   341  A2  HG2 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE8
Invoice Global Flexfield 9                      2110  Varchar2  50   80   421  A2  HG2 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE9

RECORD 2120 (INI)
Common Key (Positions 1-91)                     2120  Varchar2       91    1
Record Number                                   2120  Varchar2        4   92           Constant '2120'
Record Layout                                   2120  Varchar2        2   96           Constant 'A2'
Record Layout Qualifier                         2120  Varchar2        3   98           Constant 'HG3'
Invoice Global Flexfield 10                     2120  Varchar2  10   80   101  A2  HG3 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE10
Invoice Global Flexfield 11                     2120  Varchar2  20   80   181  A2  HG3 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE11
Invoice Global Flexfield 12                     2120  Varchar2  30   80   261  A2  HG3 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE12
Invoice Global Flexfield 13                     2120  Varchar2  40   80   341  A2  HG3 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE13
Invoice Global Flexfield 14                     2120  Varchar2  50   80   421  A2  HG3 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE14

RECORD 2130 (INI)
Common Key (Positions 1-91)                     2130  Varchar2       91    1
Record Number                                   2130  Varchar2        4   92           Constant '2130'
Record Layout                                   2130  Varchar2        2   96           Constant 'A2'
Record Layout Qualifier                         2130  Varchar2        3   98           Constant 'HG4'
Invoice Global Flexfield 15                     2130  Varchar2  10   80   101  A2  HG4 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE15
Invoice Global Flexfield 16                     2130  Varchar2  20   80   181  A2  HG4 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE16
Invoice Global Flexfield 17                     2130  Varchar2  30   80   261  A2  HG4 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE17
Invoice Global Flexfield 18                     2130  Varchar2  40   80   341  A2  HG4 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE18
Invoice Global Flexfield 19                     2130  Varchar2  50   80   421  A2  HG4 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE19

RECORD 2140 (INI)
Common Key (Positions 1-91)                     2140  Varchar2       91    1
Record Number                                   2140  Varchar2        4   92           Constant '2140'
Record Layout                                   2140  Varchar2        2   96           Constant 'A2'
Record Layout Qualifier                         2140  Varchar2        3   98           Constant 'HG5'
Invoice Global Flexfield 20                     2140  Varchar2  10   80   101  A2  HG5 AP_INVOICE_INTERFACE      GLOBAL_ATTRIBUTE20

RECORD 3000 (INI)
Common Key (Positions 1-91)                     3000  Varchar2       91    1
Record Number                                   3000  Varchar2        4   92           Constant '3000'
Record Layout                                   3000  Varchar2        2   96           Constant 'IT'
Record Layout Qualifier                         3000  Varchar2        3   98           Constant 'IT1'
Line Type                                       3000  Varchar2  10   25   101  IT  IT1 AP_INVOICE_LINES_INTERFACELINE_TYPE_LOOKUP_CODE
Invoice Line Item Number                        3000   Number   20   15   126  IT  IT1 AP_INVOICE_LINES_INTERFACELINE_NUMBER
Purchase Order Line Item Number                 3000   Number   30   22   141  IT  IT1 AP_INVOICE_LINES_INTERFACEPO_LINE_NUMBER
Item (Buyer) (Internal)              ITEM_PO    3000  Varchar2  40   55   163  IT  IT1 AP_INVOICE_LINES_INTERFACEITEM
Item (Supplier) (Ext1)                          3000  Varchar2  50   55   218  IT  IT1 AP_INVOICE_LINES_INTERFACEITEM_EXT1
Item (Supplier) (Ext2)                          3000  Varchar2  60   55   273  IT  IT1 AP_INVOICE_LINES_INTERFACEITEM_EXT2
Quantity Invoiced                               3000   Number   70   22   328  IT  IT1 AP_INVOICE_LINES_INTERFACEQUANTITY_INVOICED
Purchase Order UOM (Internal)          UOM      3000  Varchar2  80   25   350  IT  IT1 AP_INVOICE_LINES_INTERFACEPO_UNIT_OF_MEASURE
Purchase Order UOM (Ext1)                       3000  Varchar2  90    5   375  IT  IT1
Unit Price                                      3000   Number   100  22   380  IT  IT1 AP_INVOICE_LINES_INTERFACEUNIT_PRICE
Total Amount                                    3000   Number   110  22   402  IT  IT1 AP_INVOICE_LINES_INTERFACEAMOUNT
Amount Includes Tax                             3000  Varchar2  120   1   424  IT  IT1 AP_INVOICE_LINES_INTERFACEAMOUNT_INCLUDES_TAX_FLAG

RECORD 3010 (INI)
Common Key (Positions 1-91)                     3010  Varchar2       91    1
Record Number                                   3010  Varchar2        4   92           Constant '3010'
Record Layout                                   3010  Varchar2        2   96           Constant 'IT'
Record Layout Qualifier                         3010  Varchar2        3   98           Constant 'IT2'
Purchase Order Number (Line Level)              3010  Varchar2  10   20   101
Item Description                                3010  Varchar2  20   240  121  IT  IT2 AP_INVOICE_LINES_INTERFACEITEM_DESCRIPTION
Tax Code (Internal)                 TAX_CODE    3010  Varchar2  30   15   361  IT  IT2 AP_INVOICE_LINES_INTERFACETAX_CODE
Release Number                                  3010   Number   40   22   376  IT  IT2 AP_INVOICE_LINES_INTERFACERELEASE_NUM
Account Segment                                 3010   Number   50   22   398  IT  IT2 AP_INVOICE_LINES_INTERFACEACCOUNT_SEGMENT

RECORD 3020 (INI)
Common Key (Positions 1-91)                     3020  Varchar2       91    1
Record Number                                   3020  Varchar2        4   92           Constant '3020'
Record Layout                                   3020  Varchar2        2   96           Constant 'IT'
Record Layout Qualifier                         3020  Varchar2        3   98           Constant 'IT3'
Line Description                                3020  Varchar2  10   240  101  IT  IT3 AP_INVOICE_LINES_INTERFACEDESCRIPTION

RECORD 4000 (INI)
Common Key (Positions 1-91)                     4000  Varchar2       91    1
Record Number                                   4000  Varchar2        4   92           Constant '4000'
Record Layout                                   4000  Varchar2        2   96           Constant 'A1'
Record Layout Qualifier                         4000  Varchar2        3   98           Constant 'IT1'
Line Flexfield Context                          4000  Varchar2  10   50   101  A1  IT1 AP_INVOICE_LINES_INTERFACEATTRIBUTE_CATEGORY
Line Flexfield 1                                4000  Varchar2  20   80   151  A1  IT1 AP_INVOICE_LINES_INTERFACEATTRIBUTE1
Line Flexfield 2                                4000  Varchar2  30   80   231  A1  IT1 AP_INVOICE_LINES_INTERFACEATTRIBUTE2
Line Flexfield 3                                4000  Varchar2  40   80   311  A1  IT1 AP_INVOICE_LINES_INTERFACEATTRIBUTE3
Line Flexfield 4                                4000  Varchar2  50   80   391  A1  IT1 AP_INVOICE_LINES_INTERFACEATTRIBUTE4

RECORD 4010 (INI)
Common Key (Positions 1-91)                     4010  Varchar2       91    1
Record Number                                   4010  Varchar2        4   92           Constant '4010'
Record Layout                                   4010  Varchar2        2   96           Constant 'A2'
Record Layout Qualifier                         4010  Varchar2        3   98           Constant 'IT2'
Line Flexfield 5                                4010  Varchar2  10   50   101  A2  IT2 AP_INVOICE_LINES_INTERFACEATTRIBUTE5
Line Flexfield 6                                4010  Varchar2  20   80   151  A2  IT2 AP_INVOICE_LINES_INTERFACEATTRIBUTE6
Line Flexfield 7                                4010  Varchar2  30   80   231  A2  IT2 AP_INVOICE_LINES_INTERFACEATTRIBUTE7
Line Flexfield 8                                4010  Varchar2  40   80   311  A2  IT2 AP_INVOICE_LINES_INTERFACEATTRIBUTE8
Line Flexfield 9                                4010  Varchar2  50   80   391  A2  IT2 AP_INVOICE_LINES_INTERFACEATTRIBUTE9

RECORD 4020 (INI)
Common Key (Positions 1-91)                     4020  Varchar2       91    1
Record Number                                   4020  Varchar2        4   92           Constant '4020'
Record Layout                                   4020  Varchar2        2   96           Constant 'A2'
Record Layout Qualifier                         4020  Varchar2        3   98           Constant 'IT3'
Line Flexfield 10                               4020  Varchar2  10   50   101  A2  IT3 AP_INVOICE_LINES_INTERFACEATTRIBUTE10
Line Flexfield 11                               4020  Varchar2  20   80   151  A2  IT3 AP_INVOICE_LINES_INTERFACEATTRIBUTE11
Line Flexfield 12                               4020  Varchar2  30   80   231  A2  IT3 AP_INVOICE_LINES_INTERFACEATTRIBUTE12
Line Flexfield 13                               4020  Varchar2  40   80   311  A2  IT3 AP_INVOICE_LINES_INTERFACEATTRIBUTE13
Line Flexfield 14                               4020  Varchar2  50   80   391  A2  IT3 AP_INVOICE_LINES_INTERFACEATTRIBUTE14

RECORD 4030 (INI)                                     Varchar2
Common Key (Positions 1-91)                     4030  Varchar2       91    1
Record Number                                   4030  Varchar2        4   92           Constant '4030'
Record Layout                                   4030  Varchar2        2   96           Constant 'A2'
Record Layout Qualifier                         4030  Varchar2        3   98           Constant 'IT4'
Line Flexfield 15                               4030  Varchar2  10   80   101  A2  IT4 AP_INVOICE_LINES_INTERFACEATTRIBUTE15

RECORD 4100 (INI)
Common Key (Positions 1-91)                     4100  Varchar2       91    1
Record Number                                   4100  Varchar2        4   92           Constant '4100'
Record Layout                                   4100  Varchar2        2   96           Constant 'A1'
Record Layout Qualifier                         4100  Varchar2        3   98           Constant 'IG1'
Line Global Flexfield Context                   4100  Varchar2  10   50   101  A1  IG1 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE_CATEGORY
Line Global Flexfield 1                         4100  Varchar2  20   80   151  A1  IG1 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE1
Line Global Flexfield 2                         4100  Varchar2  30   80   231  A1  IG1 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE2
Line Global Flexfield 3                         4100  Varchar2  40   80   311  A1  IG1 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE3
Line Global Flexfield 4                         4100  Varchar2  50   80   391  A1  IG1 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE4

RECORD 4110 (INI)
Common Key (Positions 1-91)                     4110  Varchar2       91    1
Record Number                                   4110  Varchar2        4   92           Constant '4110'
Record Layout                                   4110  Varchar2        2   96           Constant 'A2'
Record Layout Qualifier                         4110  Varchar2        3   98           Constant 'IG2'
Line Global Flexfield 5                         4110  Varchar2  10   50   101  A2  IG2 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE5
Line Global Flexfield 6                         4110  Varchar2  20   80   151  A2  IG2 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE6
Line Global Flexfield 7                         4110  Varchar2  30   80   231  A2  IG2 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE7
Line Global Flexfield 8                         4110  Varchar2  40   80   311  A2  IG2 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE8
Line Global Flexfield 9                         4110  Varchar2  50   80   391  A2  IG2 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE9

RECORD 4120 (INI)
Common Key (Positions 1-91)                     4120  Varchar2       91    1
Record Number                                   4120  Varchar2        4   92           Constant '4120'
Record Layout                                   4120  Varchar2        2   96           Constant 'A2'
Record Layout Qualifier                         4120  Varchar2        3   98           Constant 'IG3
Line Global Flexfield 10                        4120  Varchar2  10   50   101  A2  IG3 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE10
Line Global Flexfield 11                        4120  Varchar2  20   80   151  A2  IG3 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE11
Line Global Flexfield 12                        4120  Varchar2  30   80   231  A2  IG3 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE12
Line Global Flexfield 13                        4120  Varchar2  40   80   311  A2  IG3 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE13
Line Global Flexfield 14                        4120  Varchar2  50   80   391  A2  IG3 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE14

RECORD 4130 (INI)
Common Key (Positions 1-91)                     4130  Varchar2       91    1
Record Number                                   4130  Varchar2        4   92           Constant '4130'
Record Layout                                   4130  Varchar2        2   96           Constant 'A2'
Record Layout Qualifier                         4130  Varchar2        3   98           Constant 'IG4'
Line Global Flexfield 15                        4130  Varchar2  10   80   101  A2  IG4 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE15
Line Global Flexfield 16                        4130  Varchar2  20   80   181  A2  IG4 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE16
Line Global Flexfield 17                        4130  Varchar2  30   80   261  A2  IG4 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE17
Line Global Flexfield 18                        4130  Varchar2  40   80   341  A2  IG4 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE18
Line Global Flexfield 19                        4130  Varchar2  50   80   421  A2  IG4 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE19

RECORD 4140 (INI)
Common Key (Positions 1-91)                     4140  Varchar2       91    1
Record Number                                   4140  Varchar2        4   92           Constant '4140
Record Layout                                   4140  Varchar2        2   96           Constant 'A2'
Record Layout Qualifier                         4140  Varchar2        3   98           Constant 'IG5'
Line Global Flexfield 20                        4140  Varchar2  10   80   101  A2  IG5 AP_INVOICE_LINES_INTERFACEGLOBAL_ATTRIBUTE20
djones0 commented 4 years ago

We are running Hyperledger Besu with an embedded in-protocol system for raw EDI transaction passage there are additional issues not addressed we have found over the last year of doing this, that I can go over if interested

Would love to hear the issues you guys ran in to @sambaca --

johnmonarch commented 4 years ago

There are a handful of open source EDI parsers under GPL here on Github - specifically:

https://github.com/bots-edi

Could be a good starting point for some of this, then checkpointed in via a smart contract via something like Engine @djones0 - Bots-EDI above parses EDIFACT, X12, Tradacoms and XML

johnmonarch commented 4 years ago

@sambacha

We are already doing this in production with X12 and EDIFACT, we are working on US Customs right now, should be done within 45 days on their side.

Let us know what we can contribute, I also posted on the boards about porting from XML to a JSON schema and the difficulties in this. We have a fork of OpenAPI that can handle JSON hyperschema (not an official RFC yet).

Main issue is mapping and parser, we have a custom DSL (domain-specific language, more of a limited scripting language than anything) that can handle the mapping for X12 and EDIFACT. The issue is OFTP2 in EDIFACT for us right now, we are working on that support for in client as its a different system than AS2/AS4.

My comment on the baseline board's about XML to JSON: https://lists.oasis-open-projects.org/g/baseline/topic/the_issue_with_xml_and_json/74260417?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,74260417

Here is our repo for the OpenAPI compatible EDI messages: https://github.com/freight-chain/ediclear/tree/master/openapi/components

Here is a swagger interface: https://app.swaggerhub.com/apis/freight-chain/XEDI/2

Note it should be v2.0.0 of swagger/openapi, not v3.0.0

Using a fork of your existing parser is also an option vs. others - the only consideration was additional formats of EDI above as needed.

Since OFTP2 only works point-to-point (even with a VAN) that really isn't ideal here then - and since there are other methods on chain to encrypt and digitally sign that overlaps and would obsolete or replace OFTP2's signing mechanism. So is support for it necessary up front, or should we say we're leaving it behind.

Agree with @pappas999 that cutting the need for VANs is the ideal outcome here by baselining the interchange. Since we're not storing data or EDI docs on-chain, it's more the signing, validating, and identifying the endpoints that would be done on-chain vs storing and parsing off.

For any sort of PoC we can also use whichever storage medium is preferred, echoing above that something like IPFS really isn't necessary here at this point (maybe when we get to multiparty so there's a trusted decentralized storage point)

sambacha commented 4 years ago

@johnmonarch yes, just know it's licensed under GPLv2

bots-edi library is not performant. problem with enterprise EDI messages is their file size

We are running Hyperledger Besu with an embedded in-protocol system for raw EDI transaction passage there are additional issues not addressed we have found over the last year of doing this, that I can go over if interested

Would love to hear the issues you guys ran in to @sambaca --

we can talk over this on slack or phone , its not terribly difficult, its just a lot of custom tooling at first

sambacha commented 4 years ago

Python 2.0.x and 2.1.x have a fatal bug in that they are unable to read their own byte-compiled versions of certain unicode literals -- specifically those in the \ud800-\udfff range. I wanted to give you a specific reason why I dislike the bots EDI program, as there are issues with using UTF-8 (i.e. you can't).

edit granted, we are way past those versions for python, but the fact remains to assess most open-source implementations have significant issues when it goes to scale. Mission critical means over-deliver, and that's not going to happen with python.

vulfp commented 4 years ago

Python 2.0.x and 2.1.x have a fatal bug in that they are unable to read their own byte-compiled versions of certain unicode literals -- specifically those in the \ud800-\udfff range. I wanted to give you a specific reason why I dislike the bots EDI program, as there are issues with using UTF-8 (i.e. you can't).

edit granted, we are way past those versions for python, but the fact remains to assess most open-source implementations have significant issues when it goes to scale. Mission critical means over-deliver, and that's not going to happen with python.

Why do you think this? Plenty of highly performant and available web architectures today use python. Application code is usually not the constraint in these types of systems as they are mostly network bound. Granted, string-processing as you guys are seeking to do is CPU intensive, but according to benchmarks I've seen, python is as good as and sometimes more performant than java when it comes to this. Yall should just benchmark the performance of the two libraries in consideration. And what does mission critical mean to you? Minimizing latency? Aside from huge differences, I think the choice should be determined by what minimizes development time, present and future.

sambacha commented 4 years ago

We are not using Java for that specific task. Mission-critical means its our core business. From a dev standpoint, Java makes much more sense as there is much more tooling available, for both EDI and Ethereum/Blockchain usage than python, but I dont think that's the issue here, we should first set some time frames like you said, trust me I am always for a quicker go to market for a PoC/Validation purposes.

Minimizing development time also does mean picking the right tools, there are plenty of tools out there, I think we should first focus on what part of the stack is most important as it relates to EDI: is it the parser? the mapping? the message queue system? There are plenty of parts to pick, first we should settle on that then make the decision based on as you said timeframe, etc.

On Tue, Jun 2, 2020 at 9:27 AM vulfp notifications@github.com wrote:

Python 2.0.x and 2.1.x have a fatal bug in that they are unable to read their own byte-compiled versions of certain unicode literals -- specifically those in the \ud800-\udfff range. I wanted to give you a specific reason why I dislike the bots EDI program, as there are issues with using UTF-8 (i.e. you can't).

edit granted, we are way past those versions for python, but the fact remains to assess most open-source implementations have significant issues when it goes to scale. Mission critical means over-deliver, and that's not going to happen with python.

Why do you think this? Plenty of highly performant and available web architectures today use python. Application code is usually not the constraint in these types of systems as they are mostly network bound. Granted, string-processing as you guys are seeking to do is CPU intensive, but according to benchmarks I've seen, python is as good as and sometimes more performant than java when it comes to this. Yall should just benchmark the performance of the two libraries in consideration. And what does mission critical mean to you? Minimizing latency? Aside from huge differences, I think the choice should be determined by what minimizes development time, present and future.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://mailtrack.io/trace/link/bc1614b498deb2119c230f7729fed20d90c62a43?url=https%3A%2F%2Fgithub.com%2Fethereum-oasis%2Fbaseline-roadmap%2Fissues%2F51%23issuecomment-637664860&userId=4903935&signature=68ae1efbb9022fd0, or unsubscribe https://mailtrack.io/trace/link/16d15e7fc09349d5c4ba6c56134399c77ce4d214?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAH2D4LHRNHAGFEYKCGS6GLDRUUSANANCNFSM4M6AOZXQ&userId=4903935&signature=846ff15a49555c02 .

sambacha commented 4 years ago

I have put up a preliminary repo of some EDI transactions, validation, rejection and some documentation on best-practices / etc here:

https://github.com/freight-chain/edi-baseline

The Readme has a diagram to better explain, but markdown format does not render it properly so here is a screenshot https://www.dropbox.com/s/9dcfre008n15s42/Screenshot%202020-06-09%2005.14.18.png?dl=0

humbitious commented 4 years ago

This epic has some really great content. Shall we consider doing an online workshop to see if we can synthesize a distinct and do-able demonstration project?

sambacha commented 4 years ago

Thanks for bringing me on, appreciate it! Will talk more in the upcoming meeting, will also have some questions about ZK and implementation as that is not my wheelhouse.

sambacha commented 4 years ago

I think focusing on just the ISA and GS segments would be best, as it does not limit the PoC towards any specific industry per see while being the most useful, as ISA/GS relates to whom should be the recipient.

We could have a registry contract with different companies registered on it or however you would best think to implement the user control.

Here are the data sets found in ISA and GS segments

ISA

Name Type Description Notes
AuthorizationInformationQualifier1 string [optional] [default to null]
AuthorizationInformation2 string [optional] [default to null]
SecurityInformationQualifier3 string [optional] [default to null]
SecurityInformation4 string [optional] [default to null]
SenderIDQualifier5 string [optional] [default to null]
InterchangeSenderID6 string [optional] [default to null]
ReceiverIDQualifier7 string [optional] [default to null]
InterchangeReceiverID8 string [optional] [default to null]
InterchangeDate9 string [optional] [default to null]
InterchangeTime10 string [optional] [default to null]
InterchangeControlStandardsIdentifier11 string [optional] [default to null]
InterchangeControlVersionNumber12 string [optional] [default to null]
InterchangeControlNumber13 string [optional] [default to null]
AcknowledgementRequested14 string [optional] [default to null]
UsageIndicator15 string [optional] [default to null]
ComponentElementSeparator16 string [optional] [default to null]

GS

Name Type Description Notes
CodeIdentifyingInformationType1 string [optional] [default to null]
SenderIDCode2 string [optional] [default to null]
ReceiverIDCode3 string [optional] [default to null]
Date4 string [optional] [default to null]
Time5 string [optional] [default to null]
GroupControlNumber6 string [optional] [default to null]
TransactionTypeCode7 string [optional] [default to null]
VersionAndRelease8 string [optional] [default to null]
humbitious commented 4 years ago

Are we ready to launch a specific bit of engineering work on this? We could review this on the SSC call tomorrow. Anyone in this epic that would like to discuss on the call (11am US-eastern every other monday) can DM me to get an invite.

sambacha commented 4 years ago

Entirely possible, but we woud have to coordinate with some interested companies willing to disclose as I do not have disclosure agreements with any customers, I think @johnmonarch would be able to do that I am sure some of their trucking companies would be interested, and it would be easier to connect.

I also just opened a pull request with Github/Linguist to get official EDI support as a recognized file extension on Github, [see https://github.com/github/linguist/pull/4928]

danielnorkin commented 3 years ago

@sambacha @djones0 @pappas999 @humbitious - as per the SSC call on 2/1/21 I'm checking on the status of this Epic. Let me know if you have any updates. I see there has been a lot of work put into this Epic. Should we keep this alive? If not, please close this Epic.

sambacha commented 3 years ago

I have been busy wrapping up a venture round and should be done next week. We have been working on integrating a transaction service for mainnet. Will swing around tomorrow on slack and provide an update, thanks for reaching out.

On Wed, Feb 3, 2021 at 1:05 PM danielnorkin notifications@github.com wrote:

@sambacha https://github.com/sambacha @djones0 https://github.com/djones0 @pappas999 https://github.com/pappas999 @humbitious https://github.com/humbitious - as per the SSC call on 2/1/21 I'm checking on the status of this Epic. Let me know if you have any updates. I see there has been a lot of work put into this Epic. Should we keep this alive? If not, please close this Epic.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ethereum-oasis/baseline-roadmap/issues/51#issuecomment-772822509, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH2D4LEN6BJPLEZIK4XGOD3S5G3DDANCNFSM4M6AOZXQ .