Re: A happy statement

Pratyay_Rakshit · 10-26-2021 12:40 PM

I’m happy to state that our construction company’s ERP system is now complete and runs fully on Appsheet.

While there is no objective benchmark for completion, and the apps will see continuous updates as our company grows and takes on newer varieties of projects, but all the basic modules of a standard ERP have been implemented and are successfully running. The modules include Project management, Project budgeting, HR and payroll including attendance register, Company expense management, Creditors and Debtors reconciliation including overdue ageing, complete accounting system comprising of auto-updation of general ledger, trial balance, profit loss, balance sheet and cash flow statements; GST compliance (GST in India is a thing).

The system is an assortment of 4 different apps. 2 are mainly used for data entry and minor visualization, 1 is used for all the intermediate heavy hauling, and the remaining 1 is used for accounting and visualization and reporting for higher management.

I remember the days when I took an entire day trying to figure out how to add a “Profile” view to the menu. In retrospect, this has been an amazing journey. Improvements and addition of modules will keep on happening.

Thanks and regards to @Steve @Suvrutt_Gurjar @LeventK @Marc_Dillon @WillowMobileSystems for helping me whenever I needed.

P.S. This is not exactly a question, but there is no appropriate category for happy announcements.

WillowMobileSys

Congratulations! Getting user adoption is sometimes the hardest part!!

Marc_Dillon

Excellent work!

LengliimAdmin

Congratulations Mr @Pratyay_Rakshit, will you please share how to ensure GST Compliance in AppSheet.?
We’re going to be GST registered retailer in the coming weeks and would like to ensure that we are GST Compliant.
Thanks!

Pratyay_Rakshit

When you enter all outward invoices with a GST percentage, and all purchases with a GST percentage, you can determine how much you current GST liability is.

Considering you are having this conversation on this platform, you should be able to do that using appsheet.

Further, you can check all GSTR2A and mark all purchases manually, that have been uploaded by the supplier.

Next you can set up reminders for filing GSTR1 and GSTR3B so that you don’t end up paying penalties.

If you are aiming for full automatic compliance, there are registered GST Subidha Providers who provide GST APIs for a charge and a fixed number of API calls. You can use Appsheet’s webhook feature and get that done automatically.

LengliimAdmin

Thank you, will give it a try. Although we’ve been using Appsheet for several months now, we recently applied for GST (still pending at the moment) - rural NE town.
Is it okay if I pm you/post here if I run into any AppSheet/webhook issues?
Cheers, thanks again.

Pratyay_Rakshit

I can perfectly help regarding appsheet issues. But I’m not into webhooks and APIs myself as the latter will require some extensive researh and testing, especially if you want to integrate GST APIs into Appsheet webhooks as there is so little information and documentation on the former

Rifad

Amazing !

Rafael_ANEIC-PY

Congrats @Pratyay_Rakshit ! how was your journey regarding the user adoption of your apps? were they skeptical at the beginning and then became completely addicted to it?

Pratyay_Rakshit

Well it’s implicit to human nature to resist change and this has not been an exception.

People were skeptical about why should they change things from where they were, and my changes and policies were largely viewed as whimsical and unnecessary.

I persisted, against the wishes of the majority. I kept improving the app, bit by bit.

It wasn’t before an year that everyone got a piece of this improvement and innovation. Accomodating dual language support for the reamining apps helped me reach the technogically challenged group of users, most of whom are now so much into using the app that I sometimes have problems rolling out the changes.

Nevertheless, the system has eventually proved itself to be immensely helpful for people to such an extent, that it’s now a shame to not get used to it.

SkrOYC

I’m creating something similar on our company but in another area.
I have 2 apps running full, a third is half baked and the fourth is just an idea that I’m now trying to make.
I have faced the moment to deside if I should have just one DB with a lot of tables or different ones.
How did you managed to move all the info of your apps?
It’s just one worbook/database?
My fourth big app (for this ERP) is going to share a lot of info from my biggest app, so I started thinking about this.

BTW, @Aurelien @WillowMobileSystems @Marc_Dillon Have you experienced this?

Marc_Dillon

In spreadsheet world?

Don’t be afraid to split tables up into several workbooks/files where it makes logical sense. Like if all of your apps are loading the same 3 tables, put those into one file, then put each apps’ individual tables into their own file.

You don’t want an app to have to open too many files, but far more importantly is that you don’t want an app to be needlessly opening files that contain lots of unused tables (especially large tables).

I wouldn’t spend too much time worrying about this though, your app performance will be much more affected by limiting expensive virtual column expressions and whatnot.

In database world?

Each table is loaded individually, so there is no extra baggage like when loading spreadsheet files. If you have a lot of tables across lots of apps, certainly use different databases (within the same instance) as “folders” to keep things organized.

SkrOYC

I was not worried about performance that much. My main goal was convenience. A single file containing all the tables for all the apps/modules of the ERP. But now it seems like it could hurt performance a bit?

Would you recomend to have just one workbook to feed all my apps?

Marc_Dillon

Oh, I thought that’s what you were asking about…

If you ask me, as soon as you have more than 4 or 5 tables in a single file, it gets cumbersome. Better the split them up and organize them more.

No

SkrOYC

My biggest app has 40

Rifad

Just test it with Android devices. Low end and high end also. I have tried my best on structuring tables properly to avoid unwanted sync delays and I was able to achieve that successfully.

But, when it comes to reality the UI performance degrade is soo much in many devices using Android. Most mid or high end devices also.

I have contacted support few months back and still not resolved. The application takes 3-4 seconds to switch between each views. If i remove all the data it works perfectly fine. I don’t have data more than 500 Rows in parent table and I have connected 4-5 child tables that does not have data more than 1000 rows. They claim it was because of format rules and that was not real issue. Hope we see a major upgrade in appsheet UI performance wise sometime soon.

Steve

Virtual columns, Show?, Display Name, slices, security filters, format rules, and view Show If can all hurt performance. The problem is more than likely with your app, not with AppSheet.

Rifad

I might have to learn AppSheet soo much more to make a perfect app that is having complex requirements. @Steve

Steve

Start a new topic about your problem. Let’s see if we can help!

WillowMobileSys

No such thing! Sorry!

Rifad

I have already contacted support and had a conversation with @Adam. We both are clueless about the issues.

I don’t find any performance issues on ios as well as MacBook. Performance issues are noticed only in Android and Windows laptops.

WillowMobileSys

I have this too. I treat the workbooks as a database and stuff all of the related table sheets into a single workbook. Of course, I do split them up when it logically makes sense as @Marc_Dillon has stated - Archive sheets, Security and, on occasion, organization if it seems amply appropriate.

For me, when I am developing and need to go to the source sheet, I often will need to open several sheets to look at data and frequently flip back and forth. It is a pain, again for me, if the data is spread across several sheets.

Would it be more performant to separate sheets into multiple files? Generally I think so but only marginally. I have worked with large apps that have lots of data (10,000+ rows in several tables) in a single workbook that were very performant for their size. I have also worked in equally sized apps where each table is in its own sheet and the app was extremely slow. The difference, I think, was implementation - not the organization of the data.

As for using a single workbook for “ALL” apps - I guess it depends on what it meant by this.

I believe in understanding the personnel roles and how they will use the apps. If several of these apps are used by the same people flipping back and forth, it will get annoying to see the syncing that occurs every time they switch to another app. In this case I would advocate combining the app functions into a SINGLE app with a single workbook. Not only will it be more performant from the users perspective but you will likely ALSO eliminate the need for tables to be copied down to a device several times for each independent app.

On the other hand, if the functions are divided by personnel - Sales people who only place Orders, Inventory personnel who only deal with Inventory, Administration who needs access to all - then I would build the apps in this manner - an Order Placement app, Inventory Management app, Administration app. Each person gets one app for their assigned function/role.

Bottom line - build the system to mimic the way the business operates.

SkrOYC

Thanks @WillowMobileSystems for your input around this topic. I’m sorry that I didn’t made a new one but all of this chatting seems to be around the same thing, some kind of ERP.
I really appreciate the patience to explain yourself so clearly and just if you can keep helping please consider the idea of follow the conversation in this new topic:

Pratyay_Rakshit

Well the bottom line is always about understanding the workings of the business and organisation, and make apps suited to different usage tiers.

Personally I have found it useful to deploy separate apps for different user levels, as opposed to having a single app because I have to implement a ton of ‘show if’, ‘valid if’ should I keep all things in a single app.

Like I said before, I now have five different apps to run my business.

Expense entry and reconciliation for users of upper to mid levels. The app has a few show if and valid ifs.
Expense entry for users of the lowest levels. The app is deployed in my native language, Bengali.
Project management for users of all levels other than admin. This is slightly a heavier app, that has 20 tables. Users enter their attendance through this.
The heaviest app - this shares almost 40 tables. This app handles all intermediate heavy hauling - attendance management, supplier management, linking all invoices from suppliers against payments made (this helps me to properly ‘age’ the payables so that I don’t accidentally underpay or overpay than necessary). This app also contains all the intermediate tables that there are for defining many to many relationships. This app also prints out all the reports that there are.
The most important thing is that I have used as many real columns as possible. For example, whether a bill is fully paid, partially paid or unpaid isn’t defined by virtual columns, but real columns (all against the payments made)
The fifth app is for the topmost level of administration that there is. Using the ‘real’ data generated by the fourth app, I can keep the number of tables to a minimum. This app usually reports data that a financial application will typically use. Like income statement, balance sheet, all financial ratios like current ratio, debt equity ratio; a health monitor for the projects showing all vital stats etc etc. This helps me to monitor the overall health for the company. There are shortcomings in this app but that is only due to the quality, level of correctness of the data entered and historical errors. The mechanism is correct - I have assured it with dummy data.

As conclusion, appsheet has helped me immensely in running my business lately. I still learn everyday, and holes and defects are likely to be found again and again. I have a single workbook with over 70 tables, but I haven’t run into performance issues. A proper database design is of utmost importance and should not be taken lightly if good performance is expected. In hindsight, I am happy of my progress from the point where I couldn’t attach a detail view to the menu, to the point where I can replicate my entire system within 5 hours.