Hi All,
Apologies in advance for this long post.
Depending on the response I get to this post, I am considering adding Batch/Lot/Serial Inventory Tracking to FA (collectively referred to as "Lots" henceforth).
==== BACKGROUND ====
I am an accomplished PHP developer who runs a growing Perishable Goods distribution business in Asia. I implement ERP systems on the side. So I have the right background to pull this off and my growing business needs it. But I am trying to decide whether to implement it in FA or an alternative - frankly, I'd prefer doing it in FA.
After testing FA, here are my initial thoughts on how it might work.
==== FUNCTIONALITY CHANGES =====
Items & Inventory -> Maintenance -> Items
---------------------------
Add fields for:
- Serial/Batch Control Reqd? (ie. is tracking required and is it Batch or Serial - see definition further down this msg)
- Is Perishable? (ie. if tracking required, are Best-Before dates required)
- Expiry Offset (days): (ie. if Perishable, default number of days to Expiry from Receiving)
Setup -> Company Setup -> Forms Setup
---------------------------
Add ability to set Next Reference for new Lots.
Changes to Existing Inventory Transactions
----------------------------
Add ability to add/edit/delete one or more Lots (from onoe or more Locations) against the following transactions:
- PO & WO Receiving
- Issuing to WO (including when the shortcut method is used)
- Inventory Location Transfers
- Inventory Adjustments
- Direct GRN (Purchases)
- Direct Delivery (Sales)
- Delivery Against Sales Orders
- SO Returns (ie. Credit Note with "Credit Note Type" of "Items Returned to Inventory Location")
- PO Returns (ie. Credit Note - looks like this needs enhancement to allow definition of a Credit Note Type with resulting stock movement similar to SO Returns above?)
Any other Inventory Transaction trigger points I have missed?
Inquiries & Reports
-------------------------------
- Initially I would just add one or two new Lot-level reports. Examples: Pick List with Expiration Dates (First-Expiry-First-Out "FEFO"), Lots Locations, Lots Aging.
- If others contribute to add more reports then that would be great.
==== GENERAL LEDGER ====
My understanding is that:
- FA currently offers only the Average Cost method (method 1) for Inventory Valuation
- FIFO or LIFO (methods 2 & 3) could be added regardless of whether Lot Traceability is available (but there has been no real push for this yet).
- Inventory valuation for Exact Stock Lines (method 4 - what is the correct terminology for this?) is not possible unless Lot traceability is implemented.
However, whilst I prefer to "Pick" using FEFO (which has nothing to do with accounting), I value my Inventory (and set my Sales Prices as a margin above) the Average Cost for a product (method 1).
As such, I do not plan to make any changes to the current Inventory Valuation logic (ie. it will ignore Lots as it does now).
==== NICE-TO-HAVES ====
- Add the concept of Sub-Locations (Bins) with a One-Bin-to-Many-Lots relationship
- Review all existing reports for Lot Tracking changes (and Sub-Location changes?) that may be useful
==== OTHER CONCEPTS ====
- Serial numbers will be treated as a special case of Lots where the Lot Size is hardcoded to 1.
- One Location (or sub-Location) can contain many Lots
- One Lot can only be in one Location
==== DATABASE =====
At the database level I would like to:
- Add extra fields to the Items master table(s): Batch/Serial/None, Perishable (boolean), ExpiryOffsetDays
- Keep the existing Inventory-related tables as-is and just add two new Lot Master/Transactions tables. Obviously this is conceptual and I will fit it to FA conventions (I have not reviewed field names, record versioning, etc yet).
- The Lot Master Table might look something like:
LotID (unique) | ItemID (foreign key) | ExpiryDate | LotSize (holds net qty balance) | LocationID (holds current location)
- The Lot Transactions Table might look something like:
LotTransactionID (unique) | StockTransactionID (foreign key1) | LotID (foreign key2) | TransactionTypeID (Adjust,Move,ReceiveWO, etc) | FromLocationID | ToLocationID | Qty
Alternatively, we could make this a double entry table structure with two records per Lot Transaction - eg:
LotTransactionID (unique) | StockTransactionID (foreign key1) | LotID (foreign key2) | TransactionTypeID (Adjust,Move,ReceiveWO, etc) | LocationID | Side (in/out, like debit/credit) | Qty
==========
So, feedback time.
1) How does this look? Is this what you envisage for the first level of functionality for Lots? Are there any important complexities/stumbling blocks/ommissions (functional or technical) that I need to consider?
2) Should I implement it as an Extension (possible?) or go straigth to the SVN?
3) Anyone willing to contribute? Especially with the Testing and Reports & Inquiries where I'm pretty sure I'll get bored....
4) If I go ahead and deliver a stable version of this, how do we ensure it makes General Release ASAP?
Looking forward to your feedback,
js