• Hello Fabrik Community

    Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.

    Exciting times to be sure.

    The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section

    We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..

    Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.

Unable to Get Form RowID to write into Another Database

Trying to decide how best to go about this. The master list is a listing of many items, some of which are not inventoried? This being that we have the ones we want inventoried identified by a element (yes/no). We also have items in the list that are not including in the inventory because they are from a local distributor that are not of concern that wants them to be included in the weekly inventory. One thought was to create elements for store and date such that the information could be maintained for each item. As we work on this I am also trying to visualize how this is going to be presented to the user. When you mentioned user I also thought that it would be good to capture the user that performed the inventor for accountability.

Looking back at your post from earlier today you mentioned:

6) make another related table where you update the stock balance value in main table with form php plugin. In this case you can have the history in the related table. Although inline edit straight in your main table would probably be more convenient for the user.

For reporting purposes I am wondering this table would allow reporting such that levels can be graphed over time to use for adjusting trigger levels used to determine if items need to be ordered. triggered levels are something that we would likely add in the future to assist in determining when levels reach a certain number than they need to be ordered and could create a report of those times below that level.

However, I only mention that as not to create scope creep but just to keep in mind. My main focus is just getting the core form so users are able to see a list of items for the day that they need to enter counts.

So back to the issue at hand, If I put a drop down which allows the user to enter the store then I could have the form only show the count and date for that particular store.
 
I believe I have made some progress. As mentioned items 1) and 2) are good.

This gives me a list of items that can be viewed by viewers. In order to be able to have history of each inventory including the date and store I created a repeating group that includes the date, store, employee, count.

With this setup I was looking to add to the filter so that as each item has a record entered into the subform for each inventory item that includes the date, store, employee, count where the filter would then remove the item from the list. This would then clear out the items until the are all taken care of. (this was not what I was looking to do initially but something that after I got things setup seemed nice.

Given this was not the path that I was looking to take as I learn more about this approach I am finding that I need to think about how the data is displayed or managed.

With this setup it also creates a challenge when it comes to listing the date, store, count in the list of items for the day as the join creates additional records to show if I have those fields selected to be visible in the list. Would be nice if the list would show just the last input record where the user can see the last time data case collected but that still leaves 3 possible records for each store at a minimum.

I know it seems like I am all over the place, I can see that just in my message, gut again not having been down this path or having used this method is opening the door to so other possibilities.
 
I think I might be losing track here :)

If you would have separate rows for the same item for each stock/location, you don't need any repeating groups. User just selects the desired row (e.g item1 - stock1) and updates the value. And do not forget to look at your general process also. In the case I mentioned, you need to make sure that only one person is updating the counted value for a specific item in a specific stock.

And about the history, you can use form log plugin to have the transactions logged and you can later on have any analyzes and charts you like based on logged data.
Or you could make another table for the history and e.g. when amount is updated in main table you write values to your "history" table with form PHP-plugin.
 
I apologize, as I was saying, as we have gone down this path, I am trying to understand the approach and having not used this method before am seeing different ways to approach things. I continued to work on it since my last message and I now have the following:

I have the copied list where I have it pre-filtered to the day of the week. Last night I was able to see the list switch as we went from 3/24/2020 to 3/25/2020. With that I have the list joined with a repeating sub form that allows me to enter the date, store, and count while also recording the employee as a hidden field. All is good with that.

I then went back to the pre-filter and added an additional filter that allows me to not only show the items for the day, but as they add counts for each item the list is reduced to the items they still need to add counts. This was done with a 'IN' pre-filter filtered on anything that is null and a date less then today. Works like a champ.

If I only had one location then I would be golden, but I need to be able to do this with all three stores. So that is what I think is my last challenge with the end-user side of things. Then I will have to figure out how to create a report that is email (something for a later date)

My thought, was to create a form and include the list as the footer of the form. That works great. In the form I have added a dropdown that includes the stores. Now the issue I am having is how do I use the drop down to update the list so that it shows only records that have no entries or do not contain an record counts for the day for the store shown in the forms dropdown.

Otherwise, I am open to any suggestions that would help with this last hurdle.
 
Again, I wouldn't use any repeat element and list/form combinations in your case, although no-one can stop you :)

1) You already have a list (lets call it "item stock balance list") prefiltered for the specific day.

2) Make separate rows to that list for the same item in different stocks like I mentioned earlier:
Item Location Amount
item1 store1 120
item1 store2 150
item1 store3 75
etc.

3) Now you can use a regular field filter in addition to your pre-filters to filter out all today's items for specific stock (you can check the option to keep the filters in menu item settings even if the user leaves the list).

4) User now updates the amounts in the "item stock balance list" e.g with inline edit. When the amount is updated, the filed "last counted date" is updated (e.g date fileld with "always return todays date option).
Update the separate history table at the same time the amount is updated with PHP-form plugin. Or use "log" plugin to keep the history like mentioned earlier.

5) Now you can add one more prefilter, something like. WHERE "last counted date" is not within todays date. So in that case the row disappears from the lists view after the amount has been updated. And appears again next week, because of your "Weekday" filter.

That's it!
 
Juuser, my concern with this approach is that I will have to maintain three records for the same item. There is other information that we maintain in the this main table that is not pregnant to this project such as where we order from, the cost and unit amounts, and so on. If that information changes then we will have to seek out the other (3 in this case) records to update them as well.

So my challenges are with using what I have I need to find a way to access dropdown information and have it available in the list that is being viewed in the forms footer. Is this simple not possible?

-or-

possible a spin off of what you are looking at doing where I create elements for date/count/employee for each location so that they can be updated in a list view. I would then write off the changes to another table for historical purposes.

The challenge with this is can I have the user select the store in a dropdown and have the list not show the elements for the other 2 stores? This is a means of reducing mistakes with store 1 putting date into the fields for store 2 or 3.

I know you were not aware of the extra fields as they are not part of this project but what are your thoughts with regards to your proposed solution and that potential issue?

-Eugene
 
Warehouse systems are complicated in a way. I recommend you to get some help from a person who has experience with ERP-systems. And if you want a fully functioning system, you have to draw a process first together with this person.

For example here is shortly a system description I have executed in the past.

We had lists:
1) Items main table with all the basic data like suppliers, prices, should the item be included in inventory etc.
2) Stock balance list where we had all the items in stock with: item code, stock location, amount, value. Setup similar what I suggested above.
3) Stock balance history list (or better called inventory transaction list).
4) Items purchaser list with safety stocks, re-order points / amount etc for purchasing the right amount at the right time.
5) Purchase order list.
6) Purchased items receival list
etc.

The process shortly went like that:
1) Purchaser made purchase orders to "purchase order list (5)" based on calculated / suggested amount in "Items purchaser list (3)"
2) When the purchase order arrived, transaction was made to "Purchase items receival list (6)". With PHP-form plugin the received amount was added to the current amount in the chosen warehouse ("stock balance list (2)"). Arrived amount was deducted from the purchased amount and updated in "purchase order list (5)".
3) During the inventory items were counted and updated in "stock balance list (2)" throught related list "stock balance history (3).
etc.

When the tread starts to go to the third page, I think it's a good time to think things through again.

It's not easy, but enough determination and wise planning takes you there sooner or later.
 
Last edited:
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top