Refer to ScanWrite post on how to get the code and use it. This is now part of the new WMS: viewtopic.php?f=45&t=1839
Now that Donald Trump won the White House, one election promise is to bring back manufacturing (read big warehouse and killer high cost-cutting). Here in Bangkok, with a friendly subject matter expert in Thailand's huge manufacturing sector, i begin to set out to create WMS (Warehouse Management System) from scratch.
<Start of rant>I have enough with hard-coded contributions of the previous WMS and MFG. This time I will recreate everything with better design (no core change, not even POWrappers). All i need is a real expert and I got one.<End of rant>.
This friend who humbly declined to be called an expert, Nakarat, told me that the underlying intention in WMS is NOT to have a WMS or inventory. The catch-phrase is JIT - Just In Time. In that way a lot of money and effort is saved and wastage is avoided. If the goods are to arrive just in time, hardly some minutes as they are consumed either at the production floor or distributed channels, then they incur minimal costs of larger storage area and time rental costs as well as expiry dates.
I read an article from Oracle many years ago that says, "Information Replaces Inventory". I been thinking about it ever since.
<Start of Trump Talk>And today let's set about to make Manufacturing and Warehousing great again. Let's build a big WMS and big users shall pay for it.<End of Trump Talk> First things first. Nakarat told me what users want is the timing of deliveries even prior to the WMS itself. Let's talk inbound or PDS - Purchasing Delivery Schedule but in our software we shall standardised it as IDS for Inbound with namespace org.wms.inbound.*
When a client orders goods from suppliers or vendors, particularly in the manufacturing sector and highly evident here in booming Thailand, nearby Vietnam and even mainland China, oh yes USA turning manufacturing country soon, they are strict for supplies to come in at exact times and at exact quantities. So they send out PDS requests on such specifications that also cover the Gate No the transport is to offload at. They are even given bar code stickers for their boxes to be pre-labelled, so that upon arrival the client store handlers merely scan the labels and checked their PDS sheets. Another reason for giving the suppliers those stickers is to avoid mistakes as they know best their own goods. Much time is saved at the offloading area.
Nakarat has given me exact samples of PDS listing that is barcode linked to incoming boxes labels, also barcoded. And he said it be nice that when the client stipulate those qtys coming in at which gate no, the iDempiere dashboard Request calendar lights up at the date-times and handling of them will get them closed automatically. Alternatively, the Kanban Board can be used to visually track and control the status of such PDSes. Nakarat told me there are cases that suppliers may be asked to make up to 5 preset time trips a day.
OK, with that lets get going! First to create the Purchasing listing to be processed as PDS is pretty simple and even faster with my brand new hot Ninja Plugin. Just create an InfoWindow of C_OrderLine,C_Order,C_BPartner,M_Product. Besides them, further selection criteria will be DatePromised. Further Column display QtyOnHand.
SQL criteria IsSOTrx (false to get only Purchases/Vendors), DocStatus (complete only)*
Note that the POs maybe from an internal production demand which will therefore be conceptually via Requisition or Replinishment which will finally be POs anyway.
There will be a process - org.wms.inbound.createSchedule that takes the selection and create IDS records:
IDS Model - Name = C_InDeliverySchedule
ColumnSet = C_OrderLine_ID,C_Order,C_BPartner_ID,M_Product_ID,UOM,Qty(planned delivery),QtyOrdered,QtyDelivered(actual delivery),C_Truck_ID,C_Driver_ID,C_GateNo_ID,IDScode
As the IDS sits in between POs and Materials Receipts, there shall be a closing process for the IDS: org.wms.inbound.createReceipts. That shall update the MatchingReceipts that may also feed back the MRP Info window (if supplies are raw materials for internal production).
JasperReports - InboundDeliverySchedule, IDS_BoxLabels
C_InDeliveryScheduleDocEvent: DOC_AFTER_COMPLETE -
Create R_Request ticket on Calendar, linked to C_InDeliverySchedule
DOC_AFTER_CLOSE - R_Request ticket is closed.
R_RequestType - new type: InboundDelivery
*NOTE: Inbound only contains a single PO per PDS. If there are variant orders, then they have to be in separate new POs and separate PDS but can contain same delivery setting, and bunch together for the receiver.
The BoxLabels are also to be printed and send by email to the vendor or allowed for download. The Request Dashboard will be referred to for visibility and monitoring by management.
I estimate a time of 2 weeks to complete this. My NINJA plugin will also be extended to do Infowindow/process toolbar attachment, WorkflowType Doc and Kanban board display, also some auto generation of JasperReports (1 week). Nakarat has a test barcode scanner so we be using that to simulate actual performance conditions where the scanner is entirely use at the offloading gate reading those box labels and corelating scans of the PDS. Then office can either Kanban board or closed the PDS. We shall also be referring to actual users experience and advice to avoid operational bottlenecks.
To deploy such a plugin, I am thinking of rendering traditional migration scripts besides the usual 2Pack. In due time i will try to make the '3Pack' to attach such scripts in a zip.
Request For Comments (scenario building the road ahead):
1. From Inbound, it will be the putaway process. That requires the definition of Storage areas, Storage Units, PutawayConstraints, Putaway Strategy with process of PutawayComplete. These are tied in closely with Locator model. A static image map display will be nice or a forklift drive instructions script.
2. We should also think about goods in transit, where as soon as they arrive they are requested for shipment out. Thus a staging or holding Locator will be good. Or the platform where they are offloaded are considered locators.
3. Norbert Bede has raised to me yesterday over Skype about the question that arises during high volume multiple scanner handling where inventories under picking has to be locked or else the available qtys are not reflective. I suggest the use of StockInPlay cache table but we have to think over as I do not see how it can be an issue when QtyAvailable is precalculated during Sales Order completion. It should be isolated to a Picking model, where the scanning of an ASI be matched to a temporary cache table. Or i am not sure if NB is referring to Availability or ASI assignments.
3.2 Nakarat and I prefer the scanning of goods be offline and in a local PC, albeit via WiFi. The system can alot trips of shortlists. Upon final listing exhaustion a signal can be sent back that the list is done. If there are changes, rejects etc, those goods should go into a holding area and new list of change requests be made but orderly processed. It is much like a traffic police control against a traffic road system, directing outwards rather than more conflict inwards. (to be cont'd)