►
From YouTube: In-Store Pickup. Open Grooming. March 21, 2019
Description
Questions discussed during the grooming meeting:
- Whether it makes sense to introduce Source Type attribute (yes , but not for In-Store Pickup)
- Choose proper naming for Pickup Locations
- Discussion about localization for Name and Address of sources
- Tax Calculator estimator in a shopping cart and its integration with MSI
- Inventory procurement for In-Store pickup orders (partial inventory transfer)
- l10n for distance measurements Miles vs Kilometers
A
We're
here
to
discuss
in-store
pickup
and
how
we're
going
to
implement
there
are
guys
from
the
is
M
agency
who
currently
involve
into
that
activity.
A
couple
like
a
half
literally
half
of
the
team,
because
there
is
a
team
of
six.
Now,
it's
the
team
of
three
and
the
guys
faced
with
several
like
open
questions,
issues
which
need
to
be
like
discuss
with
product
owner.
A
Also,
we
have
a
request
for
for
additional
functionality
from
Pablo
and
from
Bettina,
and
this
is
also
kind
of
functionality
which
could
be
implemented
in
the
scope
of
the
in-store
pickup,
because,
especially
it
would
be
useful
for
in-store
pickup,
because
we,
this
is
kind
of
product
procurement
functionality
when
we
will
be
making
the
source
transition
to
fulfill
order
for
the
store
in
store.
Pickup.
A
To
that,
we
like,
we
got
a
feature
request
from
Bettina
and
Pablo
so
that
we
can
discuss
how
we
can
implement
it,
because
they
have
also
several
open
questions
to
product
owner
and
like
to
the
idea
by
itself,
because
we
in
a
magenta
we
don't.
We
are
not
changing
to
implement
the
real
product
procurement
functionality
in
the
scope
of
the
magenta
community
edition
because
we
have
a
dedicated
product
for
that,
so
that
would
be
implemented
in
the
scope
of
the
magenta
order
management.
B
A
C
Yellow
guys
so
I
think
the
first
and
the
most
important
question
which
we
would
like
to
ask
is
its
right.
It's
about
naming
so
if
we
are
going
to
talk
about
Inventure
is
that
we
agree
that
that
place
where
our
keep
in
named
as
source
just
a
source
yeah.
But
if
we
are
going
to
talk
about
context
in
store
pickup
functionality,
which
in
name
we
will
best
to
describe
the
place
when
the
customer
can
came
and
just
grab
his
order,
so
we're
thinking
about
name
as
a
pickup
point.
D
We
want
to
make
sure,
of
course,
if
this
is
a
you
know
a
translatable
phrase.
So
if
the
merchant
wants
to
use
an
alternative
term
on
the
front
end
that
they
would
have
the
option
to
do
so
from
with
that
said,
I
think
you
know
pick
a
point.
Could
work?
Is
there
a
reason
that
you
don't
want
to
use
store
location,
because
you
believe
that
some
of
the
some
of
this
might
be
used
for
something
like
a
locker
or
other
location?
That's
not
actually
a
store.
D
D
A
Probably
like
we
can
use
another
terminology
on
a
front-end,
we,
so
the
main
like
the
like.
Currently,
this
question
related,
first
of
all,
to
the
how
we
will
call
this
entity
in
the
source
code
because
for
the
front-end
we
can
use,
for
example,
stores
and
that
would
be
covered.
That
would
be
totally
good
for
the
front-end,
but
the
question
was
regarding
their:
how
to
hold
it
entity
like
in
a
generic
way
in
a
source
code.
That's.
D
F
F
C
Some
analysis
mode,
we
just
checked
websites
which
using
install
backup
functionality.
This
is
different
websites
in
different
businesses
and
there
is
around
14
14
different
websites
and
we
just
searching
to
collect
which
attributes
are
in
use
for
this
pickup
locations
on
the
front
end,
and
we
found
the
most
used
information,
it's
of
course
name
and
Landers
sources.
C
Also,
there
is
such
attributes
as
open
hours
and
contact
info
is
the
most
to
use
attributes
and
we
figure
out
that
all
achievements
in
the
top
top
four
used,
except
the
open
hours
which
are
currently
not
available
in
the
source
entity.
So
are
we
going
to
do
something
with
open
hours
or
we
going
to
keep
this
educates
and
anything.
D
Inside
just
declare
find
that,
so
you
said
the
other
ones
are
already
in
the
source,
but
I
think
in
many
cases
the
merchants
might
not
want
to
go
on
the
front
end,
the
same
name
that
they
have
for
the
source
now
because
they
might
call
their
source
something
that
has
is
meaningful
to
them
internally,
like
it,
you
know,
Northwest
store
or
something,
but
they
would
want
to
show
a
different
name
on
the
front
end.
So
are
you
proposing
here
that
they
would
have
to
use
the
same
name
as
the
source
name.
C
Also,
this
search
area
is
the
Canada
where
they
have
English
and
French,
and
so
one
store
can
support
two
languages,
and
we
also
need
to
show
some
general
information
about
pickup
points.
Also
in
these
languages,
yeah
I
think
the
question
is
how
okay,
how
to
be
they're
going
to
manage
this
from
the
a
merchants
point
of
view,
because
for
now
here
we
have
stores
inventory,
but
these
know
any
locale
any
possibility
to
manage
its
power
website
and
set
different
different
values
or
different
stores.
D
C
C
D
D
F
D
A
Is
also
could
be
possibility
that
open
our
so
this
source,
even
particularly
it's
like
it's
like
a
store,
it
would
have
open
hours
for
clients
like
for
clients
for
customers
and
the
hours
of
like
maintenance
and
hours
of
like
when
supplies
come
to
this
store.
So
there
could
be
different
open
hours
for
the
store
for,
therefore,
the
source.
D
Yeah
in
this
one
I
don't
know
that
I
want
to
overcomplicate
it.
We
could.
We
could
create
an
entire
scheduling
section
of
this
I
mean
we
could
make
this
as
fancy
as
possible,
but
I
think
we
really
just
need
to
capture.
They
can
enter
it
as
texts
with,
though,
of
what
the
open
hours
are.
So
if
they
want
to
put
you
know
every
day,
it's
open
from
9:00
to
5:00.
D
D
D
A
E
Sorry
to
interrupt,
but
there
was
one
thing:
I
wanted
to
bring
up
under
store
information
for
the
general
Magento
store
under
configuration
information.
There
is
a
store
hours
of
operation,
so
we
need
to
make
sure
that
whatever
we
add
to
the
source
for
stores,
hours
of
operation
doesn't
conflict
with
that
or
they
know
it's
not
conflicted.
D
A
Let
me
let
me
find
an
interface
so
I'm
droppin,
currently
on
a
source
level.
We
don't
have
the
attribute
responsible
for
operational
hours,
so
the
question
is
actually
whether
we
would
like
to
introduce
this
attribute
or
in-store
pickup
sources
only
or
for
all
sources
or
sake
not
to
introduce
it
at
all,
because
currently
we
see
that
many
store
pickup
implementation
for
like
in
different
services,
use
this
parameter
which
provide
the
the
idea
for
customers
when
they
come
when
they
could
come
and
grab
that
product.
D
Again,
it's
probably
something
to
review
with
you
X.
My
preference
would
be
that
the
first
choice
they
make
is
whether
it's
a
pickup
location.
If
that's
enabled,
then
these
additional
fields
appear
and
are
enabled
because
it
they
don't,
have
any
need
to
enter
this
type
of
information
for
places
that
customers
will
never
go
to.
D
A
A
Do
we
like?
Do
we
see
a
necessity
to
introduce
our
other
attributes
like
that,
so
currently
what
we
were
talking?
What
we
are
talking
of
is
guys
a
little
bit
earlier
today
and
yesterday
that
whether
we
have
kind
of
attributes
set
or
entities
for
sources
which
would
be
eligible
for
the
in-store
pickup
or
we
will
just
reuse
the
limited
number
of
existing
attributes,
which
are
already
allocated
in
sourcing.
D
My
preference
would
be
that
we
make
a
limited
number
so
not
that
we
create
a
an
attribute
system
just
for
this
I
think
that
goes
beyond
what
we
need
to
accomplish
here.
We
need
to
have
a
separate
discussion
around
type,
but
given
that
they
will
already
have
two
free
fields,
pretty
much
open
hours
and
contact
information.
A
A
C
D
The
way
we
discussed
if
I
swore
is
the
type
field
would
be
used
exclusively
really
for
custom
source
selection
algorithms.
So
if
you
wanted
to
have
logic
said
you
know,
I
want
to
fulfill
this
internally,
but
if
it's
not
possible
internally,
then
I
want
to
go.
Look
at
my
dropshippers
I
have
loaded
in
the
system.
You
could.
You
could
write
an
algorithm
to
do
that.
A
This
is
probably
part
of
functionality,
so
but
mm-hm
so
you're
super
yep
definitely
weakened
the
differentiation
of
drop
shipper.
We
can
reuse
for
the
source
selection
algorithm
and
like
prioritize
or
do
prioritize
the
way
how
these
sources
would
be
chosen
by
by
the
selection
algorithm.
But
here
is
another
like
interesting
question
whether
we
like
whether
to
combine
this
project
one
attribute
or
to
have
two
different
objects
like
drop
shipper
and
like
a
separate
event
day.
Another
educated
installed
pickup
because.
D
A
B
H
H
A
D
F
B
B
D
B
D
A
D
H
A
I
Pretty
sure
that
that
it's
not
configurable
I
think
it's
always
there,
and
even
more
all
of
the
choices
you
input
on
that
estimator,
they
are
also
transferred
to
check
out.
So
this
is
something
there
to
be
aware
of
like
if
you
are
whitening
it
or
changing
it
together.
That
check
out
might
be
affected
as
well.
I
C
As
from
one
point
of
view,
they're
possible
I,
don't
know
three
options.
First,
as
store.
Pickup
method
is
not
shown
in
this
step,
but
it
can
be
embedded
of
the
customer.
Experience
second
option
that
customer
can
select.
Shipping
method
is
in-store
pickup
and
after
here
we'll
go
to
the
check
out
there,
as
we
will
have
two
buttons
in
the
shipping
step
that
pick
up
in
store
and
delivery
method.
D
D
D
Some
type
of
option
like
pick
up
in
store
as
a
checkbox,
if
they
check
back,
then
it
Gray's
out
the
place
where
they
would
enter
the
postcode.
But
then,
when
they
do
an
estimate,
its
gonna
come
up
with
zero
or
we
could
enable
even
just
a
message
to
appear
underneath
the
postcode
entry.
If
in-store
pickup
is
enabled
or
any
sources
on
the
current
websites
stock,
it
could
say
something
like
you
know:
there's
no
charge
for
in-store
pickup
I.
D
D
B
A
D
A
I
I
D
I
I
I
D
D
I'm
not
sure
whether
we
need
to
make
it
as
a
shipping
method.
If
we
did,
it
could
appear
on
that
screen
as
an
option.
You
check
the
radio
button
for
in-store
pickup
and
it
would
be
free
if
we
make
it
as
a
shipping
method.
It
would
also
give
the
merchants
the
ability
to
charge
for
in-store
pickup
if
they
wanted
to
I,
don't
see
why
they
would,
but
they
would
have
the
option.
I
D
D
So
that
what
they
essentially
of
what
they
would
be
able
to
do,
if
we
can
just
talk
about
the
outcomes,
is
they
can
either
do
the
estimator
as
it
is
now?
If
they
do
that
those
items
will
they
entered
the
fields
they
entered
our
persisted
to
the
next
page
when
they
proceed
to
checkout,
if
in
the
estimator
they
select
in-store
pickup,
then
they
will,
on
the
next
page,
have
the
insert
tab
pre-selected
for
them.
Now
the
exact
means
of
how
we're
asking
them.
You
know
this
button
just
think.
D
A
Okay,
so,
regarding
resolution
on
this
question,
we
will
clarify
that
with
you
again,
but
our
current
idea
that
we
will
introduce
the
corresponding
radio
button
and
based
on
that
patterns
of
like
we
will
differently
the
chicken
out
of
the
in-store
pickup.
And
if
the
in-store
pickup
regular
button
would
be
click.
We
will
go
on
the
next
page
with
the
pre
selection
of
the
in-store
pickup,
which.
F
I
D
Have
no,
we
have
no
association
now
between
sources
and
you
know
websites,
tourists
or
dreams,
but
the
translation
was
done
for
store
use.
Then
it
would
have
to
be
some
type
of
rid
that
allows
you
to
input
these
things.
Five
store
view.
So
in
your
example,
in
Quebec,
in
Canada,
if
I
have
an
English
in
the
French,
I
would
see
the
to
store
views.
You
connect
en
de
Becque
FR,
then
I
would
have
the
ability
to
enter
the
open
hours
and
contact
info
or
each
of
those.
D
There's
many
store
views
and
only
certain
combinations
would
apply
to
certain
sources,
but
la
mÃa
that
is
I
have
a
source
in
the
United
States
I.
Don't
want
to
enter
information
further
into
that
store
of
you.
That
source
I
only
need
to
enter
that
and
see
if
I,
don't
ship
from
the
US
tomorrow.
If
I
have
multiple
sources
in
Canada
that
I
use
to
fill,
orders
placed
on
the
Quebec
website
that
I
want
to
enter
direct
localization
for
each
of
those
sources,
because
we
don't
know
in
advance
which
sources
are
assigned
to
which
store
views.
D
C
I'm
thinking
that
we
already
discussed
so
I
probably
need
to
enter
some
other
name
for
their
epic
application,
that
is,
for
a
source
inventor.
So
probably
we
can
have
a
separated
field
for
thee
and
probably
can
be
changed
by
studio,
so
I'm,
just
thinking
how
it
will
all
miss
relevance
in
instead
of
a
grade.
We
have
a
scope
selector
at
the
top
yeah.
We
have
a
scope
selector,
but
only
that
fuels
issue
related
to
the
pickup
location
will
be
present
on
there
in
the
store
level.
D
They
may
all
be
present,
but
the
only
ones
that
will
be
editable
are
ones
that
apply
to
store
you.
So
if
you
guys
don't
like
the
top
tonight
pick,
you
know
Quebec
French
for
my
store.
You
then
I
will
see.
I
only
have
the
ability
to
edit
the
name,
store
hours
and
contact
intro
and
then
save
that
it's
very
similar
to
how
we
do
other
things
in
the
admin.
So
that's
looks
good.
A
Currently,
from
my
perspective,
I
would
I
would
really
tend
to
consider.
This
feature
is
nice
to
have
because
from
it
introduced
a
lot
of
challenges
from
the
technical
perspective,
because
currently
in
the
who
magenta,
we
like,
we
have
one
kind
of
cope,
and
this
is
scope
of
the
website
store
and
the
store
view.
From
the
msi
standpoint.
A
From
the
new
inventory
standpoint,
we
have
own
kind
of
scoping
and
that
scope
is
a
actually
the
stock
place
or
all,
and
now
we
have
kind
of
intersection
or
overlapping
or
multiplication
of
this
copes,
because
we
have
the
magenta
scope
and
in
the
msi
scopes
before
that,
we
have
that
like
one-to-one
much.
You
know
this
code
because
we
had
the
sales
channel
like
magenta
website,
which
is
a
sign
like
1
2,
1
2,
msi
scope.
But
now
we
have
additional
context
in
the
scope
of
the
store
view
for
particular
attribute.
D
Yeah,
it's
a
good
point.
I
want
to
think
about
this
in
terms
of
the
weather,
we're
trying
to
cover
it
something
that's
too
far
in
each
case
and
in
most
scenarios
the
acceptable
is
to
have
it
in
sorry.
You
only
have
the
ability
to
input
one
set
of
information.
Let
me
give
an
example
like
if
you're
in
Europe
and
you
have
store
locations
say
in
France
and
Spain
and
Germany
I-
think
it's
reasonable
for
the
customer
to
expect
that
if
they
want
to
pick
up
something
in
most
cases,
it
will
be
near
their
home.
D
But
it
is
one
the
only
case.
Maybe
this
doesn't
cover,
is
and
I've
seen
this
case
before,
which
is
but
something
happens.
A
lot
I
go
on
a
business
trip,
I
travel
somewhere
else
and
I
needed
to
buy
something,
but
I
didn't
pack
my
stuff
in
time.
So
I'm
like
behind
I,
need
to
order
something
and
pick
it
up
a
place.
I'm
going
to
go
that
I
don't
live
when
I
do
that.
A
Let's
stay
with
this
for
now,
and
we
like
we
can't
because
this
is
not
really
typical
case
for
us,
so
this
is
not
kind
of
pp-people
op0
case
so
priority.
One
of
priorities
you
know
so,
and
the
cost
for
implementation
or
the
support
would
be
probably
much
higher
than
the
benefit
would
be
given
to
us
after
the
implementation
with
this
particular
feature.
A
D
D
A
Like
currently,
all
our
entities
like
they
supposed
to
be
represented
as
data
transfer
objects
and
the
HTML
it's
more
related
to
the
representation
of
the
data,
so
we
can
just
or
the
data
in
some
format
which
represent
like
the
way
how
it
should
be
displayed
on
on
website
or
somewhere,
because
potentially
it
could
be.
The
same.
Data
could
be
reused
in
different
systems
and
maybe
they
would
be
just
transferred
to
to
another
system.
A
A
D
Yes,
I
Iger,
we
did
have
one
or
we
talked
about
the
regional
settings
for
calculating
distance.
So,
on
the
front
end,
whether
we
make
a
real-time
call
to
sort
the
locations
by
distance
from
the
customers
address,
and
if
we
do,
we
want
to
show
how
far
away
they
are
and
if
we
want
to
show
how
far
away
they
are,
which
unit
of
measure
do
we
display
yep.
A
B
D
A
A
A
A
Some
somewhere
in
configuration,
what's
the
way
of
the
representation,
is
gonna
be
for
the
website
level
so
that
we
can
convert
all
that
level,
for
example,
two
miles
and
fix,
and
just
for
example,
on
the
on
the
in-store
pickup
page,
where
we
will
be
showing
the
list
of
all
nearby
sources.
I
will
so
we
will
be
just
throw
the
distance
in
miles
and
fix
that
also
will
make
that
conversion,
but
all
the
calculation
actually
happens
in
in
one
metric
system.
A
B
A
D
D
A
Okay,
maybe
I
mean
yes,
probably.
You
are
right
that
this
is
another
issue
and
we
can
we
can.
We
can
have
this
configuration
on
the
level
story,
but,
for
example,
like
what
you
wanted
to
introduce,
you
wanted
to
introduce
a
configuration
parameter
of
radius
and
get
all
the
sources
which,
which
are
reasons
this
radius
like
near
a
by
a
nearby.
B
A
D
D
A
A
A
D
D
A
For
example,
like
we
have
another
community
project
for
localization
for
Japan
and
other
Asian
markets,
and
the
complexity
with
that.
Is
that
on
that
market
they
then
don't
have
a
fractional
part
or
for
price.
So
because
country
in
magenta
we
have
a
floating
number
and
we
always
consider
the
price
will
consist
from
both
integer
part
and,
let's
say,
fourteen
part
like
which
represent
sense.
But
in
Japan
there
is
no
such
such
meaning.
A
Like
sense,
the
debt
representation
of
the
floating
part
of
the
prices
is
not
not
really
correct
and
we
don't
have
like
a
one
place
where
we
can
fix
it.
So
we
have
to
fix
all
the
places
where
that
the
price
is
out
good
on
a
front
end.
So
this
this
introduced
some
complexity
with
the
customization
or
such
markets
that,
if
it's
going
to
be
just
one
particular
usage,
we
can
we
can
not
introduce
too
much
complexity,
but
if
it's
potentially
that
would
be
the
decision
will
evolve.
D
A
Great
so
like
resolution
here
that
we,
we
are
not
showing
on
front
end
any
information
regarding
the
mileage,
the
existence,
but
on
a
on
a
code
side,
we
will
see
how
to
figure
out
whether
or
like
try
to
introduce
like
obstruction
there
and
try
to
play
around.
Is
that
to
make
it
more
customizable
and
extendable.
D
B
J
A
J
Our
idea
was
that
we
need
some
notion
of
how
to
transfer
stock
from
one
source
to
another,
and-
and
the
point
is
it's
mostly-
for
in-store
pickup
we've
seen
some
more
complex
use
cases
where
a
physical
store
is
actually
divided
up
into
several
sources.
So
say
you
know
the
floor
is
a
source
and
then
they
consider
you
know
the
back
warehouse
a
different
different
source.
So
when
you
bring
an
item
from
the
back
to
the
floor,
then
you
would
have
to
do
some
version
of
his
stock
transfer.
The
most
common
case
is
in-store
pickup
right.
J
So
when
you
say
you
know
your
dude
fulfillment
from
a
different
store
and
it
happens
to
us
all
so
that
people
shop
as
a
one
physical
store,
but
then
they
don't
have
that
item
or
the
change
or
something.
So
they
go
to
pick
it
up
at
a
different
physical
store,
and
that
would
also
be
another
source.
So
what
we
want
to
do
is
have
some
sort
of
at
least
at
first
simple
notion
of
a
stock
transfer.
J
We
say
I
want
to
take
a
given
number
of
items
for
SKU
X
and
send
them
from
source
a
to
source
B.
Now
we
we
brought
this
up
and
Igor
mentioned
number
of
really
good
comments
and
how
complex
this
can
get.
So
the
idea
was
to
discuss
with
everyone
what
the
best
implementation
would
be
here,
so
it
doesn't
get
too
complex
because,
as
I
mention
it,
this
isn't
going
to
be
a
full
procurement
solution,
but
so
we
can
consider
those
cases
and
not
have
to
transfer
all
stock
from
one
source
to
another.
D
You
are
you
envisioning,
an
API
solution
for
this
or
something
that
the
merchant
can
do
in
the
admin.
I
mean
right
now
in
the
admin,
the
workaround
or
the
way
that
they
do
this.
Is
they
just
look
at
a
product
and
they
see
all
the
sources,
and
they
can
say
you
know,
introduced
source
a
by
six
units,
an
increase
or
speed
by
six
units
they
just
type
it
in
and
save
it.
It's
not
as
elegant
as
what
you
described.
A
Fact
we
already
have
this
API.
We
use
this
API
for
the
source-to-source
transfer,
but
in
that
case
we
apply
the
transfer
for
the
all
products
allocated
on
particular
source.
But
in
this
case
we
will
just
change
the
scope
and
we
will
be
making
the
transfer
for
the
products
in
the
scope
of
the
order,
so
actually
from
the
API
standpoint.
I
believe
we're
good,
because
we
already
have
this
bulky
pea
transfer,
which
we
can
reuse
here.
So
it's
probably
the
question
regarding
the
UI
for
this
transfer
in
in
the
fertility.
J
J
A
D
C
A
So
this
in
P
is
I
used
for
like
source-to-source
migration,
which
is
in
particularly
helpful
for
merchants
who
are
just
making
a
migration
from
the
single
source
to
multi
sources,
and
they
migrated
all
the
data
from
the
default
source
to
some
custom
sources
so
that
we
considered
that
maybe
it
makes
sense
to
introduce
a
possibility
to
specify
quantity
to
be
migrated,
but
we
did
not
find
at
that
time.
When
we
were
discussing
this
possibility
Bismark,
we
did
not
find
a
solution.
A
How
this
could
be
useful
for
a
big
number
of
products,
because
probably
like
merchants
have
to
specify
that
quantity
for
each
product,
so
it
would
be
really
nothing
annoying
and
like,
and
this
is
not
really
achievable.
We
are
magenta
admin
UI
so
that
we
also,
we
considered
the
idea
like
specifying
some
kind
of
percentage
of
the
stock
which
should
be
moved,
but
taking
into
account
that
some
of
the
products
will
have
the
decimal
quantity.
Another
will
have
the
integer
quantity,
so
it
wouldn't
be
like
specification
of
the
percent,
wouldn't
really
work
for
that.
A
So
that's
why
we
decided
not
to
proceed
with
this
kind
of
this
kind
of
migration.
Where
merchants
can
specify
the
quantity
but
looks
like
given
when
we
started
to
implement
and
store
pickup,
we
got
several
requests
where
people
would
like
to
use
the
source-to-source
transfer,
in
particular
to
fulfill
the
in-store
pickup
order,
because
currently,
what
how
we
are
going
to
implement
the
in-store
pickup
we're
going
to
accept
orders
on
a
particular
source
which
is
eligible
for
in-store
pickup.
A
This
is
correct
that
we
can
perform
this
API
implementation
and
put
it
into
another
story.
But
currently
it's
just.
We
got
several
this
request
and
actually
Pablo
who
approach
approached
me
if
week
ago,
regarding
this
particular
scenario,
so
they
also
wanted
to
introduce
this
kind
of
migration
Cisco
for
the
in-store
pickup.
A
D
A
D
B
D
That
can
already
be
done
by
API.
This
is
just
making
it
an
easier
way
to
do
that,
so
I
don't
have
to
actually
write
it
in
two
places:
I
like
decrement,
the
old
and
increment
the
new
one.
I
can
just
do
it
in
one
call.
So
it's
it's
for
ease
of
integration,
but
no
we're
not
using
it
directly
in
return.
So
far,.
D
B
A
Yeah
and
the
last
one
question
from
the
chat:
I'm
not
sure
whether
yeah
so
today
already
left
the
meeting,
but
in
the
in
the
chat
he
he
was
asking
whether
we
want
to
support
oprah's
or
supporting
possibility
to
support
possibility
of
workers
for
the
for
the
install.
The
complication
like
another
lockers
I
believe
yeah.
D
So
for
this
one
I
really
don't
see
it
as
something
that
we
would
support
out-of-the-box,
because
for
a
locker
either
I
mean
you
could
make
every
locker
stats
own
source.
You'd
have
to
be
managing
a
lot
of
transfers
between
them,
or
you
know,
a
more
robust
functionality
here
would
have
a
way
to
define
lockers,
and
then
they
have
you
know,
numbers
or
IDs
or
something
the
lockers
are
assigned
to
a
particular
location,
and
you
can
put
inventory
in
each
of
them.
D
That's
it's
a
far
more
complex
solution
than
I
think
we
want
to
take
on
here
also
because
for
lockers
you
also
have
a
hardware
integration,
there's
multiple
brands
of
lockers,
multiple
api's.
They
have
so
we
wouldn't
be
able
to
ship
out
of
the
box
the
standardized
Locker
implementation
anyways.
We
would
just
be
shipping
some
sort
of
framework
with
it.
It
would
then
have
to
be
integrated.
You
know
to
a
third-party
Locker
hardware.
A
Just
just
potentially
so
and
I'm
fully
agree
with
you
in
what
what
you
are
saying,
but
just
potentially,
if
we
wanted
to
accommodate
that
case
with
the
with
the
type
of
the
source
so
that
we
could
have
a
type
water
type
on
the
source
level
and
we
we
could
have
a
bunch
of
additional
entities,
kind
of
kind
of
sell
or
whatever
and
just
go
for
that
particular
Locker.
So
it
would
be
kind
of
relationship
one-to-many
and
we
would
have
just
a
bunch
of
particular
cells.
A
D
So,
there's
nothing
that
prevents
merchants
from
select
a
creating
a
locker
as
a
type
and
having
those
entered
in
the
system,
because
we're
allow
for
flexibility
and
the
types
that
they
create.
But
beyond
that
it
just
gets
too
complex
too
quickly,
because
you
can
say
well
what
products
do
I
need
to
put
in
which
lockers
and
how?
What's
the
quantity
of
them
and
okay,
the
lockers
need
to
have
pass
code
and
it
just
it
gets
pretty.
Mm-Hmm.
A
D
And
it
actually
made
me
think
of
one
thing:
I
know
we're
pretty
well
over
time
for
this,
so
we
might
have
to
come
back
to
it,
but
we
didn't
discuss
much
the
shipping
side
of
in-store
pickup.
So
when
I'm
in
the
admin
panel,
what
that
looks
like
from
the
mock-ups
that
we
had
of
I
need
to
click
a
button
to
indicate
to
the
customer
that
it's
ready
for
pickup
that
needs
to
use
a
template
at
email
in
a
similar
format
to
other
Magento
template.
An
email
goes
to
the
customer
telling
their
credit.
D
Should
have
a
new
template?
Fourth,
they
consider
to
need
to
have
different
wording
and
different
information
than
the
other
emails,
like
distinct
from
order
confirmation.
So
it
would
say
something
like
you
know:
hello
name,
your
order
for
these
items
and
it
would
show
the
items
because
you
could
do
a
partial
shipment
to
pick
up
again
we're
not
allowing
the
customer
to
do
a
split
shipment
on
the
front
end.
But
if
the
merchant
wanted
to
say
somewhere
available
for
pickup
and
send
the
others
out,
I
mean
they
could
do
that.
It
would
say
so.
A
E
Also
I
didn't
know
if
we
want
to
include
any
possibility
of
backorder
and
in-store
pickup
as
in-store
pickup,
going
to
strictly
show
stores
that
have
inventory
currently
and
if
it's
got
back,
orders
enabled
for
infinite
or
a
hundred
will.
Those
also
show
up
is
that
some
complexity
we're
going
to
have
to
consider
it.
A
A
Before
fulfilling
the
order,
and
before
that
you
find
the
customer,
we
have
to
make
kind
of
procurement
and
make
the
internal
transition
from
goods
from
other
sources
to
do
the
one
from
where
that
the
customer
is
supposed
to
grab
the
whole
order
and
as
soon
as
that,
internal
transfer
would
be
done.
Merchants
will
click
the
95
customer
about
about
that
order
is
ready
for
the
in-store
pickup
so
that
he
would
be
notified
with
this
mail,
and
he
can
he
can
come
and
get
it.