Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace all inventory transactions with a correspondng adjustment transaction #165

Open
jmiranda opened this issue Nov 16, 2016 · 1 comment
Assignees
Labels
type: maintenance Code improvements, optimizations and refactors, dependency upgrades...

Comments

@jmiranda
Copy link
Member

Currently, OB needs to calculate all quantity on hand values in the code rather than delegating to the database because of a design decision we made back when we started. We wanted to be able to back-enter transactions (adjustments, transfers, stock counts, etc) for some inventory items without that transaction leading to an increase/decrease in the current QoH of that inventory item and product. the (and requiring a possible offsetting adjustment later on in the transaction history). So we needed a way to record the known quantities and "reset" quantities for inventory items that existed in the past (without requiring us to actually record a 0 for all of those items. We came up with the idea of a Product Inventory transaction that would allow us to specify the quantity for all known inventory items without also needing to zero out all inventory items that are no longer in stock. This is working fine, but there's also an Inventory transaction which just allows a user to change the current QoH for a given inventory item. Because of this, trying to calculate the QoH for an entire product (i.e. usually consisting of several inventory items or lot numbers) is very difficult to do with a single database query. Storing/caching the QoH values for all inventory items (and products) is a workaround that we've adopted temporarily (see #100), but I believe this improvement will help us get back to calculating the QoH values on the fly.

Anyway, replacing the inventory transaction (i.e. a data migration for data that exists and a code change for all future inventory transactions) might be the only issue that prevents us from calculating QoH from the transaction tables as it would allow us to aggregate debits/credits and subtract from a known starting point (e.g. quantity at most recent cycle count for the product OR zero if the product has never been cycle counted)

Related resources:

@jmiranda jmiranda added the type: maintenance Code improvements, optimizations and refactors, dependency upgrades... label Nov 16, 2016
@jmiranda jmiranda self-assigned this Nov 16, 2016
jmiranda added a commit that referenced this issue Nov 27, 2016
… refactored to use adjustment transaction type instead of inventory
@jmiranda
Copy link
Member Author

I just realized that we might be able to convert these to product inventory transactions easier than creating adjustments.

jmiranda added a commit that referenced this issue May 30, 2018
…ansactions (required to finish data warehouse features)
jmiranda added a commit that referenced this issue Dec 17, 2018
…ansactions (required to finish data warehouse features)
jmiranda added a commit that referenced this issue Apr 15, 2019
…1, OBPIH-834, OBPIH-568, #165 (#710)

Merging feature branch for various tickets that had dependencies on one another
* OBPIH-777 New Consumption report
* OBPIH-831 Design dimensional model for reporting
* OBPIH-834 Replace partial inventory transactions with adjustments
* #165 Replace all inventory transactions with a corresponding adjustment transaction
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: maintenance Code improvements, optimizations and refactors, dependency upgrades...
Projects
None yet
Development

No branches or pull requests

1 participant