Proteus script to create initial stock locations

[lars_wuerfel]

I would like to create stock locations like
Row A-F, floor 1-5, place 1-12

So from A1-01 to F5-12 are 360 locations.
They are sub-locations of the Storage Zone.

I would write a Proteus script to create the locations.

Before I start - does such a script already exist, did anyone do this yet?

[acaubet (Adrià Tarroja Caubet)]

We have done something like you asked in the past, we loaded the locations from a excel:

Location = Model.get('stock.location')
parent, = Location.find([('code', '=', 'STO')])

childs = []
filename = os.path.join('EXCEL SHELVES.xlsx')
wb = load_workbook(filename, read_only=True)
for row in wb['Sheet 1'].iter_rows(min_row=2):
    code = str(row[1].value)
    child = Location(name=code)
    child.parent = parent
    childs.append(child)
Location.save(childs)

I don’t know you schema but maybe you need something different:

for row in 'ABCDEF':
    for floor in range(1, 6):
        for place in range(1,13):
            # Create your child
            print('%s%s-%s' % (row, floor, place))

[lars_wuerfel]

Thank you very much, Adrià, helped me a lot.

For reference, here is my basic code snippet to create storage locations for 6 rows with 12 places on 5 floors, all with the same parent storage location:

def create_stock_locations():
    Location = Model.get('stock.location')
    parent, = Location.find([('code', '=', 'STO')])

    childs = []
    for row in 'ABCDEF':
        for floor in range(1, 6):
            for place in range(1, 13):
                code = '%s%s-%02d' % (row, floor, place)
                print(code)
                child = Location(name=code)
                child.parent = parent
                childs.append(child)
    Location.save(childs)

[maxx (Maxime Richez)]

As name is a translatable field, it’s safe to use ‘code’ field also to store your location’s code.

...
child = Location(name=code, code=code)

[oscarQ (Òscar Queraltó)]

Coincidentally, I have to create new stock locations with similar criteria, so thanks for sharing the script because it will save me some time.

Anyway, I have doubts related to the stock location tree structure.

I had in mind the idea of creating stock locations of view type on “row” and “floor” level (according to your script) and a storage stock location on “place” level. This way I thought that the warehouse could be more “ordered” or at least it would have a more “clear” structure but I saw that in your case, you are creating directly storage locations inside “STO” location.

I think that in terms of usability it does not make any difference so it is an arbitrary decision, but I wanted to ask if it is true what I am saying so the structure does not matter at all or if it might have some benefits in doing it one way or another.

[maxx (Maxime Richez)]

We did such way:

• Switching Storage Zone as a view type to prevent to put anything in it
• Defining “places” locations (also view type) under Storage Zone with flat children
• Defining stock locations under those “places” locations named with code of “place” location as prefix because you could have multiple stock locations with identical range, row structure.

Example:

Storage Zone (view)
|__PlaceA_Stock(view)
…|__PlaceA-A-01-0
…|__PlaceA-A-01-1
…|__PlaceA-B-01-0
|__PlaceB_Stock(view)
…|__PlaceB-A-01-0
…|__PlaceB-A-01-1
…

[acaubet (Adrià Tarroja Caubet)]

Maxime’s solution is the same we use frequently.
The view locations (places) it’s only necessary if you want to view what products/stock you have under each of those places. I don’t see any other use case for it if you don’t want to see that detail. The only other case is what maxx proposes to prevent inputs in a location.

[oscarQ (Òscar Queraltó)]

Thanks you both @acaubet and @maxx for your answers, I really appreciate it.
Now I have it clear .

[acaubet (Adrià Tarroja Caubet)]

I think that the knowledge shown here about structure is enough valuable to incorporate to stock location documentation. Agree? Like this to show support or make more contributions that can be incorporated.

[lars_wuerfel]

Thank you all for this discussion, great community.

The company I am evaluating Tryton for has 3 separate storage areas in the Warehouse.
They are high rack storage areas for pallets which are organized in rows (A…F), 5 floors high and several locations “long”.

My Idea was to create 3 basic “Storage Locations” under the Warehouse (WH), like
STO1 (parts to be delivered)
|__ A1-01
|__ …
|__ F5-12

STO2 (raw material)
|__ G1-01
|__ …
|__ J1-06

STO3 (machinery)
|__ …

Now I see that you use only one storage zone, and have this structured / subdivided.

Are there disadvantages in Tryton when I define more than one storage zone?
Or should I even define a separate “Warehouse” for each high rack area?
(although the areas are just 50m apart, in the same building, …)

[acaubet (Adrià Tarroja Caubet)]

The problem with your location design is that you can not ask “what products do you have stored?”, to answer this questions you will be doing:
“what products do you have stored in STO1?”
“what products do you have stored in STO2?”
“what products do you have stored in STO3?”
and if the same product is in two or more zones you will have to sum yourself to know the totals.

But, I don’t know if you consider this relevant, ask yourself which of those questions are needed for your company.

I do not think that you need to create separate warehouses. Maybe you only need to create a parent location for those (STO1, STO2, STO3) with type view.