stupidedi does not add end segments about stupidedi HOT 7 CLOSED

Sorry, stupidedi does not generate any segments that you don't tell it to generate. The reason the examples in README.md are truncated is only for brevity (since a valid 837 could be quite long). You can also run the output of that example into edi-pp which should tell you the input has missing segments.

I think I see why you had to change the config... the HIPAA transactions were moved to a separate constructor at some point. You should be able to use config = Stupidedi::Config.hipaa without needing to modify the configuration.

from stupidedi.

When I build the end segments myself, I cannot do:

b.SE b.default, b.default

Instead, I have to type:

b.SE 123, "909090909"

And it doesn't seem to validate it. So, do I need to keep up with number of segment definitions myself?

from stupidedi.

Right, the grammar constraints says nothing about relationships of elements in different segments (e.g. there is not a way to express in the grammar that SE_01 must match ST_01 or something), so stupidedi cannot infer a default value.

Since those constraints are not expressible in the grammar, it can’t be validated by the state machine. These are semantic constraints and not syntactic ones. If you want to validate these, please see how edi-ed was implemented (many checks are implemented, but are separate from the state machine which only constructs the parse tree).

Lastly, I’m not sure how well it’s documented or if there are examples in the “notes” directory, but Builder::Identifier stack was made to help with tracking those control numbers and envelope counts. You don’t have to use it but it might be convenient. So, I think for example, you can instantiate s = Builder::IdentifierStack.new(1000) and then

b.ISA …, …, “00501”, s.isa, “1”, “T”, nil
b.GS “HC”, …, …, s.gs, “X”, “005010X222"
b.ST “837”, s.st, b.default
...

m = b.machine
st = … # use m.parent to navigate to ST

b.SE 1 + m.distance(st), s.pop
b.GS s.count, s.pop
b.ISE s.count, s.pop

— Kyle

from stupidedi.

Thanks. That works. For the benefit of future readers, this is the code I used for the st = ...

st = m
while st.segment.fetch.node.id != :ST
  st = st.parent.fetch
end

Also, I needed 2 + m.distance(st) because the count should include both the ST and the SE segment.

from stupidedi.

I'm a little confused. This:

m = builder.machine
builder.SE(2 + m.distance(m.parent), "0001")

appears to be what should generate a correct SE, but I get "NoMethodError: undefined method `zipper'"

from stupidedi.

It looks like the problem is m.parent is not a StateMachine (where is zipper defined). Looking at the documentation, the return type of m.parent is Either<StateMachine>; this is because an empty tree has no parent, so the result is wrapped to provide a consistent data type in both success and failure cases.

You can read about how to use Either values here (really, we should make a separate document just about Either):

• https://github.com/kputnam/stupidedi/blob/master/doc/Navigating.md#chaining-method-calls
• https://github.com/kputnam/stupidedi/blob/master/doc/Navigating.md#current-segment

Something like this should be close to what you want:

m = builder.machine
m.parent.tap do |p|
  builder.SE(2 + m.distance(p), "0001")
end

from stupidedi.

Also, if you look at the example @andrewthad pasted, you can use m.parent.fetch which will return the StateMachine if m.parent was a success or return nil on failure.

from stupidedi.