stupidedi 1.2.10 → 1.2.11
Sign up to get free protection for your applications and to get access to all the features.
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA1:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 949d22354fedb76e7e6c84d7b12880226c06addf
|
|
4
|
+
data.tar.gz: 460a656ce3aae6d328279bfdcec2be88aa4d237f
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: c1360abeb0ed7e5d89f2fa5c93507a5bb83e65aba7e409dbecda0c4f83c017c7816512211b2c904606f4171fe6a0379b97257b6b8059764c25c01a9e447377cb
|
|
7
|
+
data.tar.gz: 0df5aa480daf106577c3bc95e9b30e5d5bc2f5bf7f5becabdab874c819ce80c4d526eab751e1f5f8b483f1611495d085bd4f666929fd9ae2cc65ac7fa24a68bd
|
data/doc/Transcribing.md
ADDED
|
@@ -0,0 +1,90 @@
|
|
|
1
|
+
Be sure you start with the right documentation, which must be purchased from [ASC
|
|
2
|
+
X12](http://x12.org/). Documentation from a trading partner might be usable in a
|
|
3
|
+
pinch, but is often missing details or has details relevant only to that
|
|
4
|
+
partner. If you are unsure, the cover page for the document should look like
|
|
5
|
+
this:
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
|
|
9
|
+
## Tables
|
|
10
|
+
|
|
11
|
+
The overall structure of the grammar is given in section 2.2 of the
|
|
12
|
+
documentation (be sure it is marked `IMPLEMENTATION` and not `STANDARD`). The
|
|
13
|
+
top-level tables can be written as `TableDef.header`, `TableDef.detail`, and
|
|
14
|
+
`TableDef.summary`.
|
|
15
|
+
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
> Note for some reason, some grammars show the `SE` segment at the end of a
|
|
19
|
+
> detail table, rather than in its own summary table. The `SE` segment is the
|
|
20
|
+
> end of the document, so when you code up the grammar, you should create a
|
|
21
|
+
> `TableDef.summary` to contain the `SE` segment (see 837P). This is because
|
|
22
|
+
> a detail table can be repeated, while a summary table cannot, and the `SE`
|
|
23
|
+
> segment should only occur once in a document.
|
|
24
|
+
|
|
25
|
+
## Loops
|
|
26
|
+
|
|
27
|
+
Loops are groups of segments which have a particular starting segment that
|
|
28
|
+
indicates the start of the group, followed by other segments. Loops may be
|
|
29
|
+
nested, and each loop may be repeated a specified number of times. You can
|
|
30
|
+
translate each loop in the documentation to a `LoopDef.build(name, repeat_count,
|
|
31
|
+
*children)` where children are either segments or child loops.
|
|
32
|
+
|
|
33
|
+
In the example above, the `"2000C PATIENT HIERARCHY"` loop has a repeat count
|
|
34
|
+
of `RepeatCount.unbounded`, child segments `HL` and `PAT`, and many child loops
|
|
35
|
+
beginning with `"2000CA PATIENT NAME"`. Since `HL` is the first segment in the
|
|
36
|
+
loop, when the parser reads an `HL` in the right context, it will then create
|
|
37
|
+
the corresponding loop in the parse tree.
|
|
38
|
+
|
|
39
|
+
## Segments
|
|
40
|
+
|
|
41
|
+
Segments are sort of like a `struct` in the C programming language, where the
|
|
42
|
+
fields are called elements. Unlike structs, each time a segment occurs in the
|
|
43
|
+
grammar, it can be given a different name, different flags to indicate which
|
|
44
|
+
fields are required or optional, different set of allowed values in each field,
|
|
45
|
+
and a different number of allowed repeats.
|
|
46
|
+
|
|
47
|
+
One of the most commonly used segments is `NM1`, which is generally some kind of
|
|
48
|
+
name. In the above example, you an `NM1 Patient Name`, but there are many others
|
|
49
|
+
in the grammar for different people.
|
|
50
|
+
|
|
51
|
+
|
|
52
|
+
|
|
53
|
+
The important parts of the image above have probably already been transcribed in
|
|
54
|
+
an existing `SegmentDef` (unless you find a segment that hasn't been defined), which
|
|
55
|
+
are the same across all grammars (all the X12 attributes). The "loop", "usage", and
|
|
56
|
+
"repeat count" were described earlier, but are again shown here.
|
|
57
|
+
|
|
58
|
+
Segments can be described using `BuilderDsl.Segment(offset, id, name,
|
|
59
|
+
usage, repeat_count, *elements)`. The first argument comes from the `Pos. #`
|
|
60
|
+
column in the table diagram above. For instance, the `NM1 Patient Name` segment
|
|
61
|
+
has an offset of 150. The usage argument is denoted in a few places: on the
|
|
62
|
+
above diagrams, it is the labeled `Usage`; this indicates if the segment is
|
|
63
|
+
required or optional, or if its presence depends on other conditions.
|
|
64
|
+
|
|
65
|
+
## Elements
|
|
66
|
+
|
|
67
|
+
Elements are (apart from composite elements), some kind of atomic data type,
|
|
68
|
+
like a string, number, date, etc. Each place a segment is specified in the
|
|
69
|
+
grammar, its element properties are also specified. Beware that each place that
|
|
70
|
+
a segment appears can have different details about its elements, per-occurence.
|
|
71
|
+
|
|
72
|
+
|
|
73
|
+
|
|
74
|
+
This diagram indicates some of the properties of each element, in this
|
|
75
|
+
particular instance of the `NM1` segemnt. The bold border around an element
|
|
76
|
+
indicates that it is `Required`, while strike-through text indicates a
|
|
77
|
+
`NotUsed`. If you encounter a segment that hasn't already been defined, some of
|
|
78
|
+
the other properties needed to define the segment are also included on the
|
|
79
|
+
diagram, but we'll ignore those for now.
|
|
80
|
+
|
|
81
|
+
|
|
82
|
+
|
|
83
|
+
The third section of each element detail gives a name to each element,
|
|
84
|
+
usually in the gray section labeled `IMPLEMENTATION NAME`, and also specifies
|
|
85
|
+
its usage, allowed values, and minimum and maximum lengths. The usage indicator
|
|
86
|
+
is in the first column, name and allowed values in the fourth. Minimum and
|
|
87
|
+
maximum length, and number of decimal places are given in the last column, but
|
|
88
|
+
these rarely need to be specified as they are usually the same as the default
|
|
89
|
+
declared in the `ElementDef`.
|
|
90
|
+
|
data/lib/stupidedi/version.rb
CHANGED
|
@@ -65,7 +65,7 @@ module Stupidedi
|
|
|
65
65
|
E60 = t:: R.new(:E60 , "Freight Rate" , 1, 9)
|
|
66
66
|
E61 = t::AN.new(:E61 , "Free-Form Message" , 1, 30)
|
|
67
67
|
E65 = t:: R.new(:E65 , "Height" , 1, 8)
|
|
68
|
-
E66 = t::ID.new(:E66 , "Identification Code Qualifier" ,
|
|
68
|
+
E66 = t::ID.new(:E66 , "Identification Code Qualifier" , 1, 2,
|
|
69
69
|
s::CodeList.build(
|
|
70
70
|
"1" => "D-U-N-S Number, Dun & Bradstreet",
|
|
71
71
|
"2" => "Standard Carrier Alpha Code (SCAC)",
|
metadata
CHANGED
|
@@ -1,14 +1,14 @@
|
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
|
2
2
|
name: stupidedi
|
|
3
3
|
version: !ruby/object:Gem::Version
|
|
4
|
-
version: 1.2.
|
|
4
|
+
version: 1.2.11
|
|
5
5
|
platform: ruby
|
|
6
6
|
authors:
|
|
7
7
|
- Kyle Putnam
|
|
8
8
|
autorequire:
|
|
9
9
|
bindir: bin
|
|
10
10
|
cert_chain: []
|
|
11
|
-
date: 2016-
|
|
11
|
+
date: 2016-06-23 00:00:00.000000000 Z
|
|
12
12
|
dependencies:
|
|
13
13
|
- !ruby/object:Gem::Dependency
|
|
14
14
|
name: term-ansicolor
|
|
@@ -53,6 +53,7 @@ files:
|
|
|
53
53
|
- doc/Generating.md
|
|
54
54
|
- doc/Navigating.md
|
|
55
55
|
- doc/Serializing.md
|
|
56
|
+
- doc/Transcribing.md
|
|
56
57
|
- doc/design/Parser.md
|
|
57
58
|
- doc/design/Reader.md
|
|
58
59
|
- doc/unwritten/Defining.md
|