►
From YouTube: Magento MSI Open Demo. November 16, 2018
Description
Agenda:
- Regression status update
- Demonstration of a bugfix with refund functionality not respecting Order of Sources
- Demonstration of tricky Order Lifecycle cases when the reservations were created after the partial Invoice/Shipment/Credit Memo
- Milestone 3 backlog announcement
- MFTF test coverage
A
Hello,
hello,
everybody,
this
Friday
and
like
usual
time,
we
can
start
with
the
medium
and
today
we
will
present
what
what
was
done
during
this
week
and
our
current
update
and
all
the
pitfalls
we
face
twists
and
all
the
problems
we
resolved
during
this
week.
Unfortunately,
our
product
owner
mark
and
attend
today's
meeting
because
he
is
on
another
meeting,
another
training
where
he
will
be
sharing
sharing
update
on
MSI
as
well.
A
So
too
many
too
many
meetings
about
MSI
and,
let's
start,
let's
start
with
presentation
by
Vitaly
Boyka
from
out
weeks
because
he's
in
hurry
and
he
should
attend
another
meeting
in
10
minutes.
So,
let's,
let's
give
him
an
opportunity
to
make
a
presentation
and
the
bugfixes
he
did
during
this
week's.
So
we
tally.
The
stage
is
yours,
hi.
B
Guys,
can
you
hear
me
yes,
and
can
you
see
my
screen
yep
so
I
was
worked
on
the
issue
which
you
can
see
every
time
to
return,
to
stop
doing
credit
memo
for
all
the
movie,
so
Lucho
product
not
respecting
subscribe
to
first
talk,
but
I
must
also
also
happen
with
other
types
of
product
with
simple
as
well
so
I
will
show
you.
My
fix
on
simple
product.
Also
I
will
skip
first
steps
in
order
to
save
a
time
because
I
already
place
the
order
and
let's
try
to
reduce.
B
B
B
B
B
B
B
A
B
A
While
Batali's
demonstrated
is
demonstration,
I
will
just
tell
you
a
little
bit
more
how
this
system
actually
worked
in
this
case.
So
when
the
tire
at
the
time
when
the
when
they
invoiced
created
and
vitaly,
goes
to
the
source
selection
algorithm.
Currently
we
have
the
only
source
selection
algorithm
implemented.
So
it's
priority
based
algorithm
and
the
system
provides
an
ability
like
it
provides
an
option
of
a
distribution
between
between
the
sources,
sorting
them
out
by
the
priority,
and
in
this
particular
case
we
have
the
source
3
with
a
higher
priority
than
additional
source.
A
B
B
First
would
contain
the
source
items
by
school
for
one
product
and
that
get
source
assignment
to
stock
or
the
by
priority.
So
second
loop
was
took.
The
second
loop
take
into
account
the
priority
and
on
first
much
it
returns
a
stirred
squad.
So,
as
you
can
see,
it's
obvious
that
the
order
of
loops
was
wrong
and
I
was
changing.
So
that's
it
simple
fix
and
everything
works
well
for
now.
Thank
you.
Any
questions,
Thank.
A
You
tally,
just
let
me
describe
in
a
few
words,
have
a
hazard
behavior
of
our
fund.
Fraud
should
work
like
because
it's
big
it's
pretty
interesting,
because
how
like,
for
example,
the
order
can
be
fulfilled
from
several
sources
like
source,
a
source
be
source
e
and
but
actually
return
happens
at
the
time
of
return.
A
So
in
this
particular
case
we
actually
don't
return
like
if
the
if
the
same
product
was
delivered
from
several
sources
like
source
s
or
beans
or
C,
we
and
the
the
order
wanna
be
refund
founded.
We
would
not
return
the
same
quantity
which
we
deliver
it
from
all
these
sources.
Instead,
we
will
return
all
the
ordered
quantity
to
the
source
with
the
highest
priority,
and
this
is
actually
what
we
tally
demonstrated,
and
this
is
how
the
system
works.
C
Hello
everyone
so
today,
first
of
all,
I
will
start
from
my
training.
Kick.
Some
fixes
was
to
to
actually
APR
what
was
provided
by
Sugimoto
and
just
we
are
dedicated
to
conservation
or
partial
invoices
order
bundle
product
for
the
bundle
product
at
the
moment.
Work
on
the
default
stock,
so
I
already
created
Fanta.
B
C
C
Now
we
see
that
after
cancellation
of
products,
we
have
returned
seven
item.
What
was
not
invoice
it?
What
is
correct
because
invoice
it
item?
They
should
not
be
returned,
which
is
actually
a
first
fix
and
second
fix.
I
need
to
go
or
switch
to
custom
source
and
custom
stock.
I
need
to
assign
my
website
a
sell
channel
to
test
stock,
and
we
will
I
will
demonstrate
the
issue
dedicated
to
source
selection
algorithm
for
configurable
products,
so
I
have
product
configurable
product
which
ever
also
to
child
a
simple
allocated
on
two
different
custom
sources.
C
C
C
C
This
actually
all
for
this
fix
and
I
will
go
next
to
show
several
to
two
actual
scenario.
What
we
face
sort
of
it
was
interesting
scenario
and
interesting
dating
the
this
week
and
actually
lost
too.
So
you
may
see
I
mean
our
github.
There
are.
There
are
several
issues.
What
was
open
it
but
then
closed
it,
because
we,
it
was,
was
difficult
to
understand
how
system
should
work.
So
let
us
do.
C
C
C
Submitting
our
shipment
and
let
us
see
what
happened
with
our
product,
we
used
to
have
hundred
on
the
source
and
we
ship.
We
have
ship
it
free
item.
So
our
sword
deducted
to
free
item
our
sellable
quantity
still
the
same,
because
if
we
would
check
our
table,
you
may
see
here
we
have
read
revelation
is
negative
for
10
item
when
you
place
order
and
make
every
duration
when
we
do
shipment
to
compensate
its
compensation,
reservation,
compensate
creating
what
was
deducted
from
the
source.
C
No,
it
is
not
like
this.
We
still
have
97
item
on
the
source,
but
we
have
free
item
returned
to
sellable
quantity,
and
this
was
kind
of
confusion
in
beginning
and
we,
when
I
even
created
ticket
on
github
dedicated
as
a
back,
but
after
some
consideration
when
understood
that,
actually
we
have
to
say
anti
items
was
inverted
and
free,
deliberate
already
to
the
client.
So
credit
murmur,
not
considerate
to
return
item
what
was
already
shipped,
but
we
have
another
same.
What
was
invoicing
and
this?
C
Why,
in
our
table,
we
see
that
system
return
it
by
compensation.
Is
the
ration
three
item
to
the
saleable
quantity
and
to
check
that
everything
is
well.
I
may
do
partial
credit
memo
for
the
rest
of
item
and
do
refund,
and
in
this
case
we
may
see
in
table
that
we
have
only
four
item
return
it
after
credit
memo,
even
if
we
have
seven.
Why?
Because
free
already
shipped
and
let
us
check
quantity,
also,
our
product.
C
A
This
is
not
really
if
I'm
mathematic,
but
the
main
idea
here
that
just
the
value
should
be
compensated
just
once,
and
here
we
have
like
here
the
system
when,
when
really
helps
partially
in
voiced
order,
which
was
partially
shipped
afterwards,
we
have
an
assumption
and
the
system
supposed
to
make
an
assumption
use
a
credit
memo
occurs.
So
we
should
decide
whether
we,
whether
we
will
make
a
return
from
the
from
the
already
shipped
products
or
where
we
should
try
to
make
a
return.
A
The
invoiced,
but
not
shipped
products,
and
currently
the
system
tries
to
optimize
the
process
for
merchants,
because
if
you
know
a
case
like
initial,
if
you
always
original
what
was
already
shipped
merchants
actually
will
end
up
with
restricting
this
some
some
quantity
afterwards.
But
what
the
system
currently
tries
to
tell
a
complete
the
system
tries
to.
A
Make
is
less
shipments
as
possible,
so
if
we
have
some
like,
for
example,
in
this
particular
case
when
we
had
the
partial
shipment
of
seven
items
and
we
had
a
partial
invoice
of
seven
items
and
we
have
a
shipment
of
three,
so
we
have
three
or
four
items
which
are
invoiced
but
still
located
on
a
warehouse
and
actually
making
the
credit
memo.
We
just
compensate
this
not
shipped
far
so,
and
this
actually
doesn't
introduce
necessity
for
merchants
to
return
return.
C
C
C
C
Let
us
check
in
table,
we
may
see
here
we
have
tenta
items
was
we
have
reservation
after
placing
order,
5
item
after
shipment
created
and
five
items,
it's
a
compensation
reservation
to
restore
sellable
quantity.
What
we
have
here-
and
one
item
was
added
because
it's
returned
to
the
stock
from
firewood
shipit'
one
just
returned
to
the
source
this.
Why
we
have
96
here
and
here
yeah.
It
was
quite
tricky
but
primarily
understood.
What's
wrong
and
I
think
that's
all
from
me
today.
A
A
Okay,
yeah
so
just
to
find
finalizing
the
the
presentation
by
Slava.
So
this
is
pretty
interesting
stuff
and
actually
the
main
idea
of
all
our
calculations
that
all
the
like,
summon
up
all
the
reservation,
which
reservation
which
were
created
in
the
scope
of
particular
business
event,
for
example
in
in
August
order
like
shipments
credit
members,
conservation,
etc,
etcetera,
summon
up
all
this
reserve.
The
reservation
eventually
give
us
zero
and
just
doing
this,
we
are
not
affecting
and
we
are
not
getting
the
wrong
quantity
at
them.
So
this
is
pretty
interesting
stuff
like
that's.
Why?
A
Some,
for
example,
they
during
the
return
from
some
items,
get
back
to
the
reservation.
Another
get
get
back
to
the
to
the
directly
to
the
source
item,
but
summon
up
all
the
reservation
quantities.
We
are
given
like
zero,
so
the
next
one
going
to
be
Sergey
I,
don't
know
whether
Sergey
is
able
to
share
his
screen.
Try
to
search
your
screen,
Sergey.
C
So
we
have,
for
example,
simple
products
is
created
in
the
system
and
its
status
set
status
out
of
stock.
We
go
to
admin
and
after
we
try
to
add
product
to
the
order,
we
had
to
two
messages
and
one
is
irrelevant.
The
requested
quantity
is
not
available
because
actually
we
do
have
quantity
of
this
product,
but
because
product
is
out
of
stock
it
it's
not
possible
to
add
it
to
the
order.
C
C
A
Yeah
so
yeah,
so
the
Bible's
fixed
and
just
let
me
say
thank
you
to
Sergei
Sergei,
join
us
just
this
week
and
when
we
were
finalizing
our
preparation
for
to
the
three
release
and
the
fixing
all
these
bugs
and
all
this
pretty
tricky
calculation
cases,
and
it
was.
It
was
really
nice
that
Sergei
jump
in
into
into
this
rush
around
release,
preparation
of
MSI
and
fix
this
issue,
so
welcome
aboard
Sergei,
and
we
will
definitely
have
more
bugs
and
other
issues
for
you,
two
to
contribute
and
the
next
one
gonna
be
Tom.
A
D
Great
sir,
but
that
okay,
so
MSI
automated
testing,
that's
with
em
FTF
for
any
of
those
who,
maybe
last
demo
or
something
I'm,
Tom
you
to
the
team
and
will
be
handling
sort
of
our
quality
approach,
going
forward,
with
the
focus
being
on
an
FDF,
automated
testing
with
msi.
So
this
is
a
national
analysis.
D
That's
been
done
around
where
we
are
currently
what
our
process
is
and
what
our
next
steps
are
for
automated
testing,
where
we
want
to
go
and
how
we're
gonna
drive
the
quality
process
as
well,
so
currently
we're
using
hip
tests
as
our
basis
of
automation,
the
currency
that
is,
that
we're
targeting
on
s0
and
s1
only
for
automation
from
head
tests,
manual
definitions.
Some
of
those
definitions
were
written
previously
and
maybe
haven't
been
updated
to
follow
current
changes.
So
there's
some
inconsistency
there
as
automation
is
based
from
that.
D
We
need
to
go
back
and
make
sure
that
head
test
is
correct
for
community
contributors.
We
will
make
sure
that
head
test
is
correct,
so
that
we
have,
you
know
a
stable
starting
point
for
automation.
We
also
need
to
go
back
and
reflect
all
of
our
bug.
Fixes
to
have
test
coverage
in
there
and
we'll
talk
about
that
as
a
plan
going
forward
in
terms
of
our
prioritization
of
covering
bak
bug
fixes
with
automation,
especially
obviously,
those
critical
bug
fixes
we're
looking
at
the
current
coverage
gaps
and
by
gaps
here.
D
This
simply
gaps
identified
from
head
test
where
we've
identified
scenarios
as
s0
or
s1,
and
but
have
not
yet
written
automation
for
them.
Product
creation,
bundled
and
group
products.
Don't
have
full
coverage
ordering
group
products,
then
around
order
cancellation,
credit
memos,
especially
with
the
recent
PRS
bug,
fixes
and
then
shipments
around
those
grouped
and
bundled
products
as
well.
That's
one
of
the
following
cases
that
needs
the
grifton,
bundled
product
creation
and
orders
to
obviously
flow
into
shipments
there
as
a
basis
of
that.
D
So
that's
just
currently
where
what
hap
test
looks
like
I'm,
proposing
that
we
prioritize
a
little
differently
in
terms
of
our
next
steps.
So,
as
we
said,
prioritize
have
test
just
on
that
s0
s1
bucketing,
but
going
forward.
We
want
to
follow
a
hierarchy
for
what
our
prioritization
of
automation
is.
So
we
want
to
look
first
at
critical
and
blocker
bugs
where
they're
identified
and
fixed
with
a
great
work
there.
Obviously
we've
identified
a
flaw
on
the
system
and
we
want
to
have
associated
automated
test
coverage
with
that.
D
That
means
making
the
hep
test
manually
and
then
automating.
On
top
of
that,
then
we
also
want
to
look
at
newly
developed
functionality.
Our
current
approach,
there's
not
so
flawed
that
our
regression
coverage
from
milestone
two
is
bad,
so
we
did
get
good
automated
coverage
in
that.
So
we
want
to
also
look
at
newly
developed
functionality,
and
the
note
here
is
its
API
only
and
I
know.
So
there
is
some
of
that
for
milestone
three,
then
the
actual
backflow
of
load
except
itself
once
we've
covered
those
first
two
points
I'd
like
to
follow
hierarchy.
D
So
that's
component
coverage
and
is
gonna
be
our
first
metric.
So
what
what
is
covered?
Where
isn't
based
on
those
gap
and
then
product
criticality
as
well
and
with
once
we've
identified?
What
are
our
critical
areas
that
have
maybe
not
as
much
coverage
as
we
want
for
a
milestone
3,
then
we
prioritize
with
out
s0
s1
tagging
within
that,
and
the
note
here
is
that
you
know
we'll
be
having
a
discussion
right,
what
the
prioritization
is
and
what
areas
we
focus
on.
D
That
will
be
very
much
a
living
document
and
going
forward
as
we
develop
new
features
as
we
get
new
priorities,
the
test
automation
priorities
will
have
to
evolve
with
that,
and
that
will
be
ongoing.
So
in
terms
of
our
focus,
then
I
haven't
talked
about
this
in
theory.
What
we
actually
want
to
focus
on
going
forward
I
believe,
is
around
these
three
interconnected
things:
that's
order
status,
the
transition
states
between
order,
statuses
and
the
calculations
that
are
triggered
off
those
that's
the
jewel
we'll
be
talking
about
in
these
bug
fixes.
D
That's
what
calculations
happen
when
we
refund
things
when
we
invoice
things
as
an
order
progresses
through
its
life
cycle,
we
do
need
full
coverage
of
that
and
automation.
I
believe
that
is
because
this
forms
critical
regression
as
we
make
changes
that
order
flow
is
always
going
to
be
critical
to
the
application
working
correctly.
Having
good
well
develop
coverage
in
that
allows
incremental
development
work
and
the
touches
that
order
flow
and
a
lot
of
it
will
to
have
a
solid
automation
basis.
D
That
makes
it
very
easy
to
extend
upon
for
that
strong
foundation,
and
then
it's
also
going
to
be
our
primary
point
for
ensuring
that
those
calculations
are
always
correct
and
obviously
incorrect
calculations
are
usually
going
to
be
critical
bugs.
So
that's
why
we're
focusing
this
on
this
as
a
strong
foundation
of
automation,
coverage
going
forward
also
I
mean
having
all
the
coverage
in
the
world
is
fantastic,
but
we
want
to
be
able
to
report
on
this.
We
want
to
be
able
to
be
agile
and
track
where
we
are
and
track
higher
priorities.
Change
going
forward.
D
Hip
test
lacks
some
of
the
more
advanced
abilities
that
we
want
to
really
highlight
those
priorities
and
report
on
exactly
where
we
are
at
any
one
time
in
the
short
term.
We're
gonna
be
that
hierarchical
review
of
priorities
and
with
business
and
product
we're
gonna
refine
and
improve
our
product
documentation.
D
So
we
have
a
better
definition
of
our
test
flows
and
our
order
flows
so
that
we're
doing
the
correct
type
of
testing
and
not
missing
anything
and
I'm
gonna
be
producing
weekly
status
reports
in
this
demo
meeting
about
where
we
are,
and
that
is
gonna-
require
some
development
time
to
parse
and
analyze
head
tests
export
data,
so
the
reporting
will
get
better
week
on
week
on
week
as
we
go.
Hopefully
you'll
see
that
essentially,
that's
me,
as
you
see,
will
be
producing
some
of
those
testing
around
the
order,
status
and
transitions
as
we
go
forward.