Hi again.
Is it correct to carry out the outbound movement of articles using the consultation link on the Request page? That is, through the following screen.
I would not recommend that. Could you explain why you want to do that?
@vmillan Can you tell me why you’d want to use this workflow? It’s possible that it might still work as long as you don’t go back and forth between the two workflows. However, I’d prefer to bring elements from the old workflow into the new workflow. So let me know what you need / what you like and we can discuss what it would take to modify the current stock movement workflows to meet your requirements.
There are elements of the old shipment workflow that I really miss and want to bring back. for example, there’s a somewhat hidden feature in OB where you can create containers (pallets, cases, boxes) in inbound and outbound shipments to organize your items. These are essentially groupings of items with provided / generated license plate numbers (LPNs) that could make it easier to move items between locations in the warehouse (i.e. receiving, putaway, picking, etc).
For practical reasons, I preferred to attach a .doc file where I explain the two reasons why we propose this other flow. Please tell me if it is okay this way or do you prefer me to upload each image in this answer.
Although in summary, there are two reasons:
Great response. Thank you. And yes, the .docx approach is fine with me.
So now, let’s discuss what we could do to improve the “natural flow”. I actually think of this as a “Quick” workflow as it makes a lot of assumptions and helps you send / receive orders quickly. But in addition to this “Quick” workflow I’d like to break each action / operation into its own form / workflow so that we could add more advanced features.
For example, I believe that Picking should have its own workflow. The “Quick” workflow assumes that everyone using OpenBoxes will want to do discrete order picking. But we could potentially pick in multiple ways i.e batch order picking, zone picking, etc. And without a specific picking feature, it’s impossible to do that.
I’m ok with you using the old workflow as long as it works for you. But I’d also think we should try to improve the current workflows (or build new ones) that meet the needs of your users.
So would you mind putting together a proposal about your preferred workflows. You’ve pulled together screenshots of a process that works ok for you, but I’m guessing it’s still not ideal. So I’d like to get your feedback on the ideal process including actors/roles, actions, etc.
- Avoid forms that do not apply to the business.
What are the specific forms that don’t apply to your business? It’s possible we could eventually configure workflows so that you only see what you want to see. For example, the Packing step in the workflow is only available if you have Packing enabled as a supported activity on the current location.
- Obtain the approval forms that are required in the business and that the “Natural Flow” does not allow us to obtain.
Can you provide more details of what this would look like? Is it just the auditing fields like “who did the thing? when did they do it?” Would the process be better if the approval was required by a certain role? For example, the users in the approval role would receive an email notification asking them to approve the requisition (outbound order). The email would include a link to a form where the user would be able to approve the order?
Are there other approval processes that you’d like to see? If you have a business process diagram or flow, that might be useful as well.
p.s. Awesome job with the Spanish translation! Very impressive.
Hi again Justin.
I’m working on preparing a couple of documents that show you the business and the flows that we are taking to Openboxes. I hope your understanding since personally I am not as good as I would like with the language, however, I think we are understanding each other well so far (unless you tell me otherwise XD)
The warehouse business that concerns us now is simpler than what Openboxes supports. In this process map, I want to show you the only information flows that exist between the actors in our warehouse where you will see that the suppliers are an external entity with which we do not interact through any technological interface, and the only contact with them is for make them the purchase of materials and physically receive the assorted products.
Internally, the users who request materials from the warehouse are different operational areas of the institution, so through a request, they indicate what and how much they need.
The warehouse manager identifies this request and physically delivers what is in stock. For the materials that do not exist, a purchase order is prepared to request it from any provider that has the capacity to do so, even if this provider is not registered in Openboxes.
It is these last movements that require a record about the person requesting, the person who delivers and the person who authorizes. Although the latter will be seen in the more detailed documents that I will be sending you soon.
It is because of this reduced flow that we need to omit some forms from the full potential of Openboxes. However, the intention is to implement this basic flow and at the beginning of the following year the scope of this implementation will be scaled up to different institutions that carry out the management of their warehouse in a similar way.
Thank you, Victor. This is fantastic. I’ll to review this in more detail in the next few days.
One thing that stood out to me was the workflow around stock outs (sufficiency of stock). This could get really complicated i.e. if the same product is requested multiple times in the same week by the same operating entities, then it could generate multiple POs for the same quantity which would lead to an overstock situation. So whatever automation you build in needs to be somewhat intelligent.
We have a new feature on the way that will handle bin replenishment i.e. replenish a picking bin from a bulk storage location. I’ve designed the data model to support replenishment from external sources (e.g. suppliers) as well, but we don’t have a frontend component for that yet. It seems that what you’re depicting in your diagram would likely fit nicely into what I was expecting to build for this “replenishment from external sources” feature.
Excellent appreciations, I really appreciate that feedback.
The bad news is that, although we have insisted with the functional leader on this issue of automating requests to providers, for now that functionality we have had to leave it out of the scope of the first version. And the task of controlling purchases from suppliers will continue to be carried out outside of this system (that is why in the diagram I indicate sending the purchase order as a manual task). It may be a political issue, but I trust that for the next version we will finally get approval to automate this process as well.
The good news is that, indeed, this feature that is on the way would perfectly cover this way of operating in the warehouse that we are working on. We will be awaiting the release of this feature.
Perhaps this we discussed helps me explain why we need to omit some forms from the “natural” flow of Openboxes. In this order, I can tell you that the team is carrying out different tests to identify if there is any risk in the data by dispensing with one or the other flow in openboxes. Hence this query was born, which thanks to your support has been illustrative.
If you allow me, shortly I will share other documents that show the business that we are leading to openboxes.
PS: Regarding the language translation, I forgot to tell you that we have tried to document every step we have taken during this translation work. If you consider it useful, it would be nice to share it with you. Maybe it will support you in the implementation of these changes within the language configuration files, not only for Spanish, but for any other language.
Yes, please.
Yes that would be amazing. Thank you.
