Developing an optimization module for inventory

 The given blog has been developed for helping the end clients get rid of slow moving stock at healthy margins. The solution from Turbodata entails selling the stock items through the secondary sales channel involving sites such as indiamart, tradeindia etc.

Contact details of blog writer:

Name: Apoorv Chaturvedi

Email: support@mndatasolutions.com;support@turbodatatool.com

Phone: +91-8802466356

Blogs:  http://mndatasolutionsindia.blogspot.in/

Problem that we see to resolve

·        Gauge the value of the closing stock using ABC analysis.

·        Find the slow moving stock within category A

·        Sell the items that are slow moving and have high stock value.

·        Find the buyers for the given stocks with the following parameters:

o   Buyers with good payment history to get additional discounts

o   Buyers with poor payment history to be blocked or not get high discounts

Solution

Attached is the flow of the information for solving the required problem:

Data auditing:

A number of times the end client types in wrong data into the source ERP system thereby resulting in wrong outputs and results. Junk inputs imply junk outputs.  The ETL team would recommend an auditable output from Turbodata to be used as part of the reporting purposes.  Wrong data inputs can impact the end client in one or more of the following ways:

•        Wrong tax filing specifically in online scenario.
•         Wrong business picture
•         Wrong predictive analytics.

As per the Toyota ProductionSystem, bad inputs should not be processed further as it adds to the final costs.

The ETL team(my firm) has found the following errors with regards to the data entry inputs specifically with Tally ERP 9.0.  

·         Stock input has been in one godown but stock outward movement has been from other godowns:

·         Missing purchase or sales order entries resulting in negative stocks at given points in time. One cannot have negative stock balances at any point in time.

Other data input errors that we have commonly seen are as follows:

•       Duplicate payment entries
•      Duplicate sales entries
•        Receipt note entries but no purchase invoice entries
•         Payments not having the required bill reference numbers.

How to resolve the errors:

·         In an object oriented program it is difficult to catch the errors on a real time basis. The ETL team recommends using the relational databases for catching the errors. The real time extraction module for Turbodata should be used for the same.

·         Transferring the data onto the third normal database is recommended. This helps catch data duplicity based on the composite keys.

For example if an end client has made the same amount payment for a given voucher on a given fiscal date, then the same should come as part of the discrepancy report. It is possible that the end client could be correct. There is also a possibility that the payment entries have been made by 2 different resources. Further handling of the given situation is as follows:

·         If the end client desires to catch the following error then the username by which the data entries have been done shall not be added to the composite key. In such a scenario there is a discrepancy between the Turbodata ledger balance output and the Tally report. The end client to approve the discrepant entry before the data is input into the system for auditing purposes.

Using perpetual valuations for ledger and inventory instead of periodic valuations. For example if an end client relies on periodic valuations for ledger balances then a duplicate payment entry then the periodic balances at the end of the fiscal month are difficult to catch. For example if an end client has a duplicate entry of Rs. 100k(One hundred thousand  only) over a balance of say Rs. 15000k(One fifty million only).

However using the perpetual system it is easy to catch the data entry errors.

Matching the consolidated trial balances and closing stock balances at the database level with the on fly calculations at the software level.

A small story for the end user: as Yuval Harari is Sapians says that mankind is primarily driven by myths. Hence many a managers are driven by myths regarding software or the consulting companies having the right audit numbers(with the managers inputting junk numbers).

A small story from one of my favourite books(Raag Darbari by Srilal Shukla) could best illustrate the point.

The protagonist Ranganath had gone from the city to visit his relative, an aunt’s husband , in the village. During the course of the village fair, it was suggested that the group goes and sees the village temple for the local goddess. At the temple Ranganath found that the statue instead of been of a goddess was of a soldier( for a goddess he was looking for two lumps  in front and two lumps in the back). The priest asked for donations for the goddess. To this request Ranganath refused saying that the statue was not of a goddess but of a man. There was an ensuing scuffle between the villagers and Ranganath. Ranganath was eventually rescued by his cousin. On going out and meeting other people, the cousin mentioned the following:

"My cousin has come from the city and is very well read. That is why he talks like a fool."
The author has always associated himself with Ranganath.

Data consolidation example:

Deployment of Turbodata for Retail company based out of Western India

Source system: multiple installation of Tally ERP 9.1.

Problem : The end client desired to have a custom installation of Turbodata based on the unique requirements of its business. The product shall be used for designing a custom web interface for customer interaction. The key tenets of the solution that differed from the standard deployment of turbodata were as follows:

·         Standard price list instead of weighted average or FIFO pricelist.

·         Closing stock value was to be calculated at a godown and item level.

·         The solution was to work across multiple locations seamlessly with maximum RAM usage been 1 GB for both initial and incremental data loads.

·         Custom masters extraction for item, stock group, category .

·         GST classification to be extracted for the end client.

Time duration of the project: 2 weeks.

Approach of the ETL team:

·         Choosing the appropriate set of attributes to be loaded based on the modular approach. That is the required fields to be loaded for ledger and inventory were chosen.

·         Custom extraction for the tables: The process of normalization helped in the same since the attribute is to be loaded only once.

·         Testing of initial and incremental data loads in terms of time and load on the system. The incremental data load process helped at reducing the time of data load.

·         Data cleansing: special characters were removed from the item names. Also separation of the numeric values from the character fields

·         Data consolidation: multiple types of voucher types were loaded onto the datawarehouse.

Project has been done successfully. Hereafter the end client shall go for a MVC interface over the datawarehouse for reporting and customer interaction purposes.

Data consolidation for Trial Balance example:

Problem: the end client required consolidated ledger balances and balance sheet details across 36 companies. With the given software that the end client had the process was taking a lot of time. The system would hang during the process of consolidation and generation of the required reports.

Methodology of the ETL team: the ETL team consolidated data ledger data from all the 36 companies. In order for the end client to generate balance sheet/trial balance details on any fiscal date the ETL team did the following activities:

·         Perpetual ledger balance details were stored by partyledgername and ledgername.

·         The associated cost center details for the ledger were also stored. The Profit and Loss statements could be generated according to the cost center details.

·         The ETL team was able to generate the balance sheet details, trial balance details across all the companies.

·         The end client could get the access to the balance sheet details across multiple companies.

The following system was used to match the trial balance details:

·         Data audit: the ETL team used the perpetual ledger balance details to arrive at the closing ledger balance details on the given fiscal date. The closing ledger balance on the given fiscal date was matched with the trial balance details from the software. The software was able to handle the cases where opening ledger balance was non zero.

Final result:

·         The audit numbers of the resulting output were matching with the software output.

·         The report refresh times was crashed by more than 90%(ninety) percent

·         The software did not hang during the process of initial and incremental data load and during the process of report generation.

Other benefits to the end client:

·         Better scope of cash flow availability: since the end client is having the cash flow balances on each fiscal date, hence the end client is able to capture the variances in payments across all ledgers. This helps the end client at better planning of the cash flows.

For the process of data consolidation, the following actions were done:

·         Data cleansing

·         Data consolidation

·         Data transformation

·         Report generation using C#/.net interface.

       Further ledger analysis was done as given in the following link:
       Ledger analysis link

      Dashboards for hypothesis testing:

Are you a customer having the following issues:

Having issues with large value of  slow moving inventory
Have issues with cash flow cycles
Do not have clarity regarding product profitability

Our product Turbodata can help your firm with resolving the above issues. The product is inspired by philosophy of The Goal by Eliyahu Goldratt and Profit Beyond Measure by Thomas Johnson and Ander Brohms(please see the appendix 1 for a summary of the philosophies)

Both the philosophies imply that the end client should use the order line profitability instead of using the periodic calculations. Only then would the end client get complete visibility into its operations and profitability by customer, region etc.

What is required for determining the orderline profitability?

For determining the same the end client needs to have valuations of inventory using perpetual method instead of the periodic method.

As a case to the point, consider the following:

In the attached scenario of an item, the valuation using weighted average/FIFO has been done on periodic basis. Hence the end client looses the orderline profitability details by using the same.

However in the snapshot below using Turbodata, the weighted average calculations are done on a daily basis(as in the attached snapshot)

 

This enables the end client to calculate orderline profitability.

Issues with calculating the orderline profitability:

v  In some of the software,  negative stock is allowed.  Because of the same orderline profitability calculations might be impacted. The sample below gives the first instance of negative stock for an item.

Sample attached below: