Francisco has provided a robust design solution for data maintenance, provided a resilient effort, strong focus, clear communications and methodological technical support for this project.
The skills required an extremely highly talented team with a drive for excellence, the never-ending pursuit of delivering a quality solution, and of course a “get-it-done” attitude. With Francisco’s acumen for developing solid solutions, resolving technical issues and creating strong personal connections, we were able to be very successful. He stands out as the prime driver to take a concept from an idea to the deployment.
His strong aptitude, great communication ability, willingness to accept change, and ability to work under pressure showed great integrity. Along with the entire JCI Thermal Print team, they combined their knowledge, experience, dedication and teamwork to support and resolve the numerous issues and remediation efforts.
Again, thank you for your support and team efforts!
JCI Manager for IT Supply Chain and Operations
JCI Project Manager
from Johnson Controls
The International Shipments project was designed to minimize the delays at US Customs when exporting shipments from the United States by addressing issues with missing paperwork from the various manufacturing sites, required by US Customs to complete the export process.
In order to address the issue with missing paperwork, we created a standard international packing slip report for each of the manufacturing sites within the US.
The report pulled together the following information: Hazard Code, Terms of Payment, Shipment Weight converted to KG, Currency Rates, Consignee Information, Customer Information, and the Parts/Assemblies in the shipment and was configured to print during the Shipment Processing components of QAD.
The final part of the project was to convert the QAD report to a PDF using FormTrap™. FormTrap™ was configured to listen on the QAD report output folder/queue. An output form layout was then created and mapped each of the fields tied to the QAD fixed field elements and line terminators. In line translations were configured for the consignee destination countries.
FormTrap™ enables the automatic detection and extraction of fixed field delimited text files that can be configured through the queues. Multiple forms can be configured on a single queue/folder using key fields in the text document header.
Lessons Learned: Packing slip and shipping documents can be printed from multiple QAD screens, for example: BOL Print, Master Bill of Lading Print, Commercial Invoice. In order to prevent unnecessary complexity this report was configured to generate whenever the shipping documents are triggered by calling the international shipper report custom code from the aforementioned print events. To ensure that the UNIX server could access and copy files over to the necessary FormTrap™ input folder, which is located on a Windows server, the folder had to be shared such that Everyone had full read/write permissions to the folder.
A strategy to allow customers to drive the order entry process in QAD, thus reducing demand on sales representatives and improving efficiency.
Direct communication between QAD and SalesForce can be brokered using EI and then integrated with QAD using web services and progress custom code. The complete communication flow is shown in the figure below:
The implementation strategy:
- Order entry screen SalesForce
- Integrated with QAD using EI.
- EI communicates the XML entry details to a web service running on IIS.
- The Web service layer translated the inbound QAD to field definitions appropriate for QAD simulated order creation
- QAD custom code listens on the web service output waiting for the quote entry document. The new XML is simulated as an order in QAD, which includes discounts, surcharges, taxes, etc.,
- QAD drops the XML simulated order details to web service
Before the order can be confirmed in QAD, the customer must first approve the quote provided by QAD. Therefore, a reverse flow of quote information to SalesForce is required. The reverse flow is:
- The web service sends the QAD quote entry details to EI
- EI relays the details to the customer on SalesForce
At this stage the customer can either reject or confirm the quote. If the quote is rejected nothing needs to be done, as the order entry was only simulated. If the customer accepts the quote, then the quote details must be passed back down to EI through the web service to QAD. Failures in simulated order creation can be passed back to SalesForces using the XML error fields.
This project demonstrates that a robust custom driven order process work flow, in QAD, can be triggered and controlled using a 3rd party order management system.
In order to answer this question custom code and automation features were developed and implemented in QAD to interact with inventory in an in-transit location.
The sequence of steps at the shipping site:
- Import of ASN (Advanced Shipping Notice)
- Validation of ASN details: filter by supplier and product line
- Add part quantities to In-Transit location
- Debit part quantities from Inventory
- Credit Clearing Account
- GL Account of finished goods
- Create ASN
These steps will account for all inventory that is now in-transit; however, a reversal of the operation must now be defined during Purchase Order receipt in order.
These steps are:
- PO Receipt
- Validation of PO details: filter by supplier and product line
- Remove part quantities from In-Transit location
- Reverse GL on Credit Clearing Account
- Add parts to inventory at receiving location
- Debit PO Receipts account:
- GL Account of received goods
EDI Setup is a requirement for this product as it is being driven by the ASN import and generation at the shipping location:
- Trading Partner Parameter Setup
- Suppliers EDI ID
- Interface ID
- Transaction Type
- ASN/PO/PO ACK/Schedules
- Setup the Sites
- Site Ship From cross references
- All the destinations the supplier can ship from
- Site Ship From cross references
- Better visibility of inventory levels
- Improved speed of receiving materials.
A requirement was issues for a 3rd party system to have access on part data within the QAD ERP system. Access between the 3rd party application and QAD was to be brokered by an IIS web service. A simple approach was to allow.NET to call compiled Progress custom code. For this to work, four items need to be setup:
- Compiled R code to call, for example:
- Use proxgen to create a DLL stub that defines an open edge client interface
- Choose generate and then configure the .NET assembly namespace
- For the sample shown, only the assembly version, company, and namespace have been configured.
- Then generate the DLLs
- Configure an AppServer Agent
- Define the Progress database to connect
- Add the correct PROPATH to the .r file location
- In .NET create a new project
- Add references to the DLL’s created in step 2b
- Create a connection to progress
- Call the DLL and pass the parameters
For a standard sales order confirmation processes, each sales order is processed sequentially - one at a time; however, it is not uncommon for sales orders to contain hundreds of line items. For very large sales orders the confirmation process can take many minutes to confirm.
A typical SO Confirmation Pipeline could be like the figure below, where the current head of the queue is SOn.
In order to confirm a SO, QAD needs to create the work order and then release the material from inventory to the job. SOn will take significantly longer to confirm than SOn-1 and SOn-2 due to the number of line items. In this case SOn may create a backlog, preventing the subsequent SO’s from confirming. This backlog can then result in delays of work being released to manufacturing.
Two improvements are possible (i) prioritize queues based on the number of lines items, or (ii) create multiple queues to balance the load during the confirmation process.
The solution implemented was to setup four parallel SO queues. In bound SO’s were then assigned to one of these four queues based on queue size and load. Each queue is processed and handled in the same manner as before, with the head of each queue processed using the confirmation process previously discussed.
- Queues that become blocked due to a failing SO can have all remaining items move to a different queue.
- The confirmation process can work on four SO’s simultaneously
- The queue load can be monitored for processing speed and optimized
Transaction scope should be minimized to prevent one queue locking another queue. This problem was traced to the use of sequence numbers.