Explaining the Dividers Store

Stock, Inventory, and Design Challenges

There were a number of workable and non-workable solutions I considered before I decided on the solution ultimately employed.

Design: Modify the Sales Order DocType To To Accept Reservations

This design called for:

a custom Dividers Store DocType,
a custom Reservation DocType, and
a custom Table Field on the Sales Order.

The idea was to add a Table Field on the Sales Order that described the reservations being purchased. The item purchased would be "Reservation", and the amount would be for the total value of the contract or some variation based on quantity.

The idea could work, but it had a number of shortcomings.

It would not integrate with existing ERPNext systems, including Sales Order reports.
Tracking cost per reservation or any other cost-based reporting variants would require custom reporting.
It still requires selecting an item to complete the Sales Order.
It conflicts with one of our design goals: creating a system that allows us to mix and match inventory from different companies on the sames Sales Order.
The system required a completely custom solution, which would raise maintenance costs.

I put a good deal of effort into designing this system before arriving at a more maintainable solution.

Result: scrapped

Design: Stores-as-Items With Sides and Cycles as Variants

After conversing with ERPNext staff, I came up with the idea of using variants to manage inventory. This design called for:

managing our store inventory using the Item DocType, where each store is an Item template, and
creating variants for store items based on sides and cycles, and using the variants to populate the Items Document List.

There is little custom functionality to create in this case, because we are using ERPNext's built-in systems to manage everything. However, of all the possible solutions, this design is the least workable for us.

Our Item Document List would be very large and grow larger every cycle.
I didn't see a workable solution to handle continuation.
Months are completely unworkable.
Hacking core Item functionality to grant limited access to inventory for sales seemed fraught with unexpected dangers.
Setting up stores as Items would require hiding a large number of fields and adding a large number of fields. It would also require managing Item-related fields when we enter stores, which would make manging our store inventory more complicated and confusing for our users.
We were originally set up with an ERP system called "Syspro" back in the day. Being forced to use their inventory scheme caused a lot of problems for us, and I wanted to avoid that mistake.
Any issues we encountered using the system would require hacking core functionality, a processes significantly more prone to hazard than crafting a custom solution.

Result: scrapped

Design: Stores-as-Items With Sides Alone as Variants

After conversing with ERPNext staff, I came up with the idea of using variants to manage inventory. This design called for:

managing our store inventory using the Item DocType, where each store is an Item template, and
creating variants for store items based on sides alone, and using the variants to populate the Items Document List.

There is little custom functionality to create in this case, because we are using ERPNext's built-in systems to manage everything. However, of all the possible solutions, this design is the least workable for us.

I didn't see a workable solution to handle continuation.
Tracking inventory would resemble Syspro's bins, a system that we universally despised when it was in place years ago.
Hacking core Item functionality to grant limited access to inventory for sales seemed fraught with unexpected dangers.
Setting up stores as Items would require hiding a large number of fields and adding a large number of fields. It would also require managing Item-related fields when we enter stores, which would make manging our store inventory more complicated and confusing for our users.
Any issues we encountered using the system would require hacking core functionality, a processes significantly more prone to hazard than crafting a custom solution.

Result: scrapped

Solution: Stores-as-custom-DocType, Reservations-as-items

Rather than forcing our inventory into a system designed to do a different job, I opted to craft a system that leverages the strengths of ERPNext, while supplementing the weaknesses with custom DocTypes and Fields.

The way we manage our store inventory is unique, so I focused my first efforts here. Stores must have their own custom DocType, whith custom functionality for management and display to sales. This "Dividers Store" DocType could be linked to other DocTypes as needed - e.g. Items.

I wanted to leverage the default beaviors of both the Sales Order and Item DocTypes, in order to use as much of the default functionality as possible. This meant that reservations had to be items, in order to be placed on a Sales Order. Because every reservation is unique, each reservation Item must be created during contract entry.

Advantages

We maintain our own custom store inventory functionality, which is conveniently extendable according to our needs.
ERPNext handles all of the accounting details, with little or no changes required.
We present a flexible posture against future requirements.

Drawbacks

Once entered, a reservation is always available for selection on a Sales Order, leading to long lists of reservations. I believe there is a solution to this problem, but I have not placed a gread deal of effort into discovering what it is, since it is a relatively minor problem.

Continuation

There were two ways continuation could have been designed.

Auto Repeat

Auto Repeat is an ERPNext feature that duplicates a Document on a set schedule. In theory it would be the ideal way to track continuation. However, it would have requried extensive customization.

The way Auto Repeat was built, it is unable to repeat documents on a 4-week schedule, which meant that it's core functionality would need to be altered for it to work for us.
The repeater would need to analize and replace the reservations on the document when repeating, or the reservations would be for old cycles.

Result: scrapped

Subscription

This requires setting up a new Subscription Plan and Subscription. Once set up, an invoice will be generated on schedule automatically. It requires special consideration when displaying inventory, and is a minor pain to set up, but is otherwise ideal for our purposes.

Dividers Store Design and Features

DocType Functionality

Apart from being a list of fields, the Dividers Store DocType has a few exiting new features.

Dividers Store Chain

We frequently are required to run reports based on the store chain. Accounting also relies on the field when paying stores for space. We finally have a means of tracking that information directly on our store list.

The Dividers Store Chain DocType also contains features for making production and billing easier:

set a default gang template to use per chain, overridable on the Dividers Store,
track addresses and contacts against the chain for accounting purposes,
include payment instructions on the DocType (again, for accounting purposes), and
supply a place to hold the contract we have with the chain.

Division

Accounting needs to break payments down by a chain's division, a hertofor manual process. Now they can track the information directly on the Dividers Store.

Address and Contact

Taking advantage of ERPNext's system for managing addresses and contacts, we hav added them to the Dividers Store doctype. The "Store Physical Address" field is geolocated on save, and the coordinates are used to populate the map and when sales attempts to locate stores by distance.

Map

The coordinates generated when saving the "Store Physical Address" field are used to render it's location on a map.

Store Assignment

The store can be assigned to one or more Sales Persons or Sales Partners (ISOs). The assignment can last a predetermined period of time, or it can be set to expire. Once assigned, the store will only appear in the available inventory for the assignees, unless overriden.

Store Assignment Override

Similar to the Store Assigment feature, the store can be exclusively assigned to a single Sales Person or Sales Partner for a predetermined period of time. The override must be set up with an expiration date, and it can only be granted to one person. Once overriden, the store will only show up in the inventory to whom the override was granted.