Creating stock balance by month

theinviter

Registered User.
Local time
Yesterday, 18:25
Joined
Aug 14, 2014
Messages
253
Dears,

I hope this email finds you well.

I'm currently working on a system to track item movement and balance. The system involves two primary forms:

  1. Item Addition: Users scan a barcode to add an item to the inventory.
  2. Item Transaction: Users scan a barcode to record a transaction (e.g., sale, return, transfer).
My goal is to calculate the following metrics for each item on a monthly basis:

  • Balance: The current quantity of the item in stock.
  • Total Transactions: The total number of transactions for the item.
  • Total Additions: The total quantity added to the inventory for the item.
I'm seeking advice on the most efficient way to achieve this. Any suggestions or recommendations on the following would be greatly appreciated:

  • Calculation Logic: The optimal approach to calculate the balance, total transactions, and total additions for each item, considering monthly breakdowns.
  • Reporting: The best way to present these metrics in a clear and concise manner, perhaps through a dashboard or report.
Thank you for your time and expertise. I look forward to your valuable insights.
 

Attachments

Most people these days approach this using a transaction table where the item code, transaction date, transaction code, direction code, and quantity moved are in the base record. The transaction code leads to a table of things like "Stock Add" (with +1 as the direction), "Stock Sale" (with -1 as a direction), "Restock" (+1 direction), "Stock Shrinkage" (-1 direction), "Stock Manual Adjust" (either +1 or -1 , depending), "Stock Archive Point" (+1 as direction, used when you are archiving older transactions, and this is the rollup of all transactions prior to the date/time of this transaction). When you look up the transaction code, you store the direction code. NO DIRECTION CODE IS EVER EQUAL TO 0 or any number >1 or < -1. Then your current inventory level is viewed using something like...

Code:
SELECT ItemCode, SUM( [DirectionCode]*[Quantity] ) AS StockBalance, MAX( TrnsDate) AS AsOfDate GROUP BY ItemCode ;

If you want only a particular item's balance, use this but instead of grouping by ItemCode, have a WHERE [ItemCode]=some particular code

The StockArchivePoint is where you do the above query for every item but with WHERE [TrnsDate] < archive date. Then take the stock on hand total for each item (positive or negative, doesn't matter here) and synthesize an entry for the given date/time at which this inventory was run. Finally, do a DELETE of the transaction records earlier than (less than - but definitely NOT EQUAL TO) the archive date/time. The Stock Archive Point is your bridge to your detailed history. As a step before the DELETE, you might wish to COPY or EXPORT or in some other way actually archive the old transactions you just summarized if that is the way your business wants such records.

If you keep the detailed transaction records, some of your required reports are trivial and would be based on doing a GROUP BY based on the transaction date. If you are looking only at transactions in a month, you GROUP BY Format( "yyyymm", [TrnsDate] ) but if you want actual running balance for the month the summation is for WHERE [TrnsDate] < 23:59:59 of last day of each month

Presentation is up to you. You might look at how your current inventory system would present such totals and see if that is something you wanted to preserve. My views on presentation won't match your business atmosphere, I'm sure.
 
A table should store a type of thing. Maybe you have a Person table, or Transaction, Job, WorkOrder, SalesOrder, Product, Customer, or Patient, names that describe a type of thing. Table names like DataEntry, DispensedQuantity, InventoryAddition, ItemCode, don't make sense because they do not describe a type of object, and so the domain of information they store is ambiguous. DataEntry of what? DispensedQuantity of what? InventoryAddition of what? It is the "What" that a table must describe.
 
Dears,

I hope this email finds you well.

I'm currently working on a system to track item movement and balance. The system involves two primary forms:

  1. Item Addition: Users scan a barcode to add an item to the inventory.
  2. Item Transaction: Users scan a barcode to record a transaction (e.g., sale, return, transfer).
My goal is to calculate the following metrics for each item on a monthly basis:

  • Balance: The current quantity of the item in stock.
  • Total Transactions: The total number of transactions for the item.
  • Total Additions: The total quantity added to the inventory for the item.
I'm seeking advice on the most efficient way to achieve this. Any suggestions or recommendations on the following would be greatly appreciated:

  • Calculation Logic: The optimal approach to calculate the balance, total transactions, and total additions for each item, considering monthly breakdowns.
  • Reporting: The best way to present these metrics in a clear and concise manner, perhaps through a dashboard or report.
Thank you for your time and expertise. I look forward to your valuable insights.
You can probably get some good ideas from the Northwind Developers Version template.

The only thing we did not include in the template that you mention is using a barcode scanner for data entry.

You can also get some useful insight from the videos on this playlist, especially those presented by Tom Van Stiphout and Kim Young.

 
Hi All i have tried in different way and its work fine so i need support in below:
1- in Inventory Transaction form : When used choose the item Davita code drop list or update the quantity then want the balance get updated value from Bal_Val.

thanks
 

Attachments

Hi All i have tried in different way and its work fine so i need support in below:
1- in Inventory Transaction form : When used choose the item Davita code drop list or update the quantity then want the balance get updated value from Bal_Val.

thanks
Hi
You need to study the following example by Allen Browne.
Stock On Hand
 

Users who are viewing this thread

Back
Top Bottom