Inbound Delivery Schedule (WMS)

[red1]

Refer to 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 and . 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.

PDS.png (407.15 KiB) Viewed 5360 times

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.

BoxLabel.png (225.74 KiB) Viewed 5360 times

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)

[red1]

SYSNOVA has come in to sponsor this project. I have spent a lot of time working on the new Android Studio 2.1 and could get the mobile phone to work as a pretty efficient fast scanner to scan and display any series of incoming QR Codes and to be committed directly to the iDempiere. Below is the Dialog box to store the DB Connector values into SharedPreferences so they are done only once in the user phone. I took a snap shot of my actual phone that has the APK deployed by my code in Android Studio.

DBConnector.png (211.61 KiB) Viewed 5014 times

(Note the setting is to my local iDempiere server IP address on my LAN. You have to edit your postgres.conf and pg_hba.conf accordingly. Note that using emulated device in Android studio it has a different IP config to access localhost server as shown in next post.)
The idea is to allow any mobile phone to handle the returning receipts sent out to the supplier, and when scanned will directly write to the iDempiere server and the Kanban Board of IDS will show the header card move from Approved to InProgress and when all the detail boxes have arrived, it is ready to be drag to the Complete. If not all cards are in, then the card will not be dragged but remain on the InProgress DocStatus. The user can then zoom into the IDS to see which detail is not in.

Once the mobile side is completely working as described above, then i will commit the Android code to bitbucket.

[red1]

Below (scroll to bottom left of image) is the proof of concept that the Android app is able to connect with the Database and SQL process on it. It uses an AsyncTask for background threading but does not go via WebServices instead directly calls the DB. Reason is to make the code as simple and minimal as possible for easy and fast debugging. Once committed upon completion of the above stated tasks, it will become a good reference for the world on Android DB connection as well as iDempiere mobile integration. This can be a good basis of an alternative to the present SpinSuite from Venezuela which remains highly complicated.

POC.png (191.08 KiB) Viewed 5064 times

Just proved a full cycle of code scan till write to DocStatus of Kanban board. Finally a fully working framework to adapt to any code scanning integration for iDempiere!

Here is a movie showing its full action working on the ready made Ninja Kanban Board case.