I work in a company in which tracking codes can be a real benefit for the company.
They have heavy equipment, and the want to use tracking codes to track expenses and revenue for each equipment. The only missing problem here is that they want to view the overall performance of each group of tracking codes. for example some tracking codes need to be grouped under excavators, other group of tracking codes need to be grouped under dump trucks, and others under wheel loaders, and so on.
I found this grouping feature is available in odoo accounting system, and it is not a big deal.
I think if you implement this idea, it will make a big difference in manager.
This is contrary to the underlying concept of tracking codes, which are meant to group income and expenses posted to various accounts, not to be grouped themselves. In other words, tracking codes are the grouping mechanism. They were originally conceived to allow profit and loss reporting of different divisions.
The way to do what you want is to establish income and expense accounts for each piece of equipment and group those on the chart of accounts by category.
Generally, it is better to keep records simple in the chart of accounts, and use other tools to make more detailed analysis.
For example, we can have an expense account called “Equipments Repair and Maintenance”, this is more convenient for the accounting reporting purpose rather than “Excavator repair and maintenance”, “Loader Repair and maintenance”, “Dump Truck repair and maintenance”.
Then we can open a tracking code the following way:
Dump Truck 001
Dump Truck 002
Dump Truck 003
Then if we have grouping tools for tracking codes, we can assign each equipment to a group. Sometimes even groups can be nested inside another group. This way you can have a beautiful nested and multi-level tracking codes (aka cost centers / profit centers / departments). Then you can run reports against various levels of those groups to see the complete picture.
I’ve seen many local accounting systems utilizing this methodology to keep accounting records clean and simple, but still enhance the level of analysis.
Kindly I am requesting you to take more further look into this functionality.
As being able to group tracking codes, or assign sub codes who help me hugely in my current situation.
I’m the treasurer for a small community group. All of our income is from fundraising but we like to monitor this income and the related expenditure by event, to see which are worth re-running for the following year.
We run two fairs a year which are much bigger events and so break the income and expenditure down again by stalls, for the same reason as above, but just need it grouped on the years Income and expenditure. A ‘grouped’ tracking code would mean we can compare that whole event to other events for the year. but still offer that detailed analyse for the overall event.
Yes this topic needs to be under ideas. I have also talked about having parent Tracking Codes and subs or and even sub subs.
Take for example, Company XYZ is doing so many projects, one of the projects is rural population empowerment. Under this Major project, there are many sub-projects. Now we want to create groups for rural population empowerment project and the other main projects. Under rural population empowerment project group we have 3 other projects; 1. Farming for Income (18 months program), 2. Financial Planning 6 Months program) and 3. Vulnerable and Persons with disability support (24 months).
We want to create the sub-projects as tracking codes but when selecting them, we want to select rural empowerment (group), before it shows the tracking codes under that specific group or associated with that parent group. When generating reports, the user will just select the whole group if they want a whole group report or select a subsidiary tracking code if they want a report for a sub-project.
Another use case is Creating Donors as groups for an NGO and putting their projects under their groups. The user can easily generate a report for the group (all projects sponsored by a Donor) and a report for a sub-project (one project of a Donor)
Another use is creating a Group Tracking Code for tracking sales guys (for the purpose of easily calculating commissions and to compare sales agents) ,we can call this group ‘Sales Agent’ and put names of sales guys under it. We can create another group in the same business for business divisions or something (e.g. Finance, HR, New York Branch…). By selecting the group before selecting the tracking code (sub code) you avoid having all created tracking codes displaying. only the codes associated with that group will show.
There are many more situations for which a feature like this would be so useful.
Abeiku, I am resurrecting this topic, even though the “what it looks like” panel to the right of this edit panel is screaming, “Are you sure you want to continue this old conversation?”. Why, yes, I do…
You are quite right, it is important to be able to develop code structures such as this. It is one of the fundamental principles of managing any complex business, project, or set of projects. Even (dare we say?) the details within a project!
But, I do not think “Tracking Code” is the data element by which you would want to accomplish this organization of work, resources and data. Why?
Because Accounting Rules are pretty rigid, and need to be. The way we manage businesses, large or small, regions/Business Units, Projects and pieces of an individual project is not. The “Tracking Code” itself is embedded in the accounting processes in Manager, and I really do see it as it was described in other posts…something that allows you to separate revenues/costs by division, ot other important partition.
Correct! But, Custom Codes may be a better way, if certain things can be sorted out as to use rules. Some of the posts I’ve read on Tracking Code have asked for this flexibility, as “Joe” did above. He too, wants an hierarchical “Tracking Code”, Others are asking for Funding Source, and Sources within a Funding Source…
If you think of what Manager started out to be (I’m guessing a bit here), that probably was an accounting package. With feedback from users, additional features were added…most likely all within the knowledge domain of accounting.
But at some point, the feature requests crossed the accounting boundary; into Materials Management, Purchasing, Receiving and Warehousing. And then Project Management (I see that as Custom Coding, with various input types).
In reading a few 100 posts, I see the bolded statement above as a major source of issues with functionality…additional capability in one “Custom Code” area requested by a user, gets thrashed and shredded by other users, moderators and programmers. Lubos can get vaporlocked in any planned upgrades of functionality, because he cannot envision all of the unintended consequences that may arise from an enhancement, nor can he anticipate a new user coming on board, who may demand a regression to a more rigid coding structure, or expanding capability and opening up the structure.
If he has a fleet of programmers/coders, each with strong knowledge in the functional domains that interface with accounting, and must mesh smoothly to to meet all of these requests. Perhaps…but I think the Server and Cloud version prices will go way up, even charging “Desktop” users due to the rise in costs. Why?
Because unlike accounting (e.g.,GAAP, IASB), and certain rules for business sectors, expectations (e.g., ISO Standards), there are virtually no rules. Using the business rules and processes from running a repair shop for autos will fail miserably in Residential Construction. Lubos cannot see across that vast and complex of a domain to figure out how some new user will ask for, complain about, or get frustrated with some aspect of Manager.
That sermon complete, I agree that Manager needs an Hierarchical Code Generator (which will create Groups, sub-Groups, sub-sub-Groups, ad-infinitum. Which, of course can be added to any line item, form, etc. EXCEPT…I repeat…EXCEPT “Tracking Code”.
I go back to the Accounting Domain…If it touches an Accounting Transaction (I mean here, recording an Expense or Revenue specifically as a transaction that hits the Balance Sheet or Income Statement), Tracking Code, and Tracking Code Only.
If it applies to any Inventory, Purchasing, Receiving, Warehousing (Locations), Sales Quoting, Invoicing functionality, then yes, Custom Coding can work. But I think an Hierarchical Code Generator as a method to populate a list of items for a drop down can resolve a lot of problems. A Lot.
I resurrected this thread because you make a good point about coding, but we must always keep in mind that if Lubos counts the number of users, seat licenses, etc, and adding in an estimate for current and future desktop users, that is how many different and unique ways businesses can bend, fold, staple and mutilate Manager into trying to make it fit their unique needs.
To be certain, I am a new user myself. I am using the Desktop addition. I am not receiving any financial benefit directly from Lubos, nor anyone else that make work on the functionality of Manager. But I like the functionalities it has incorporated, as well as the system capabilities it may have and achieve in the future.
But I think it beneficial to leave the “Tracking Code” alone…other than adding the capability to “inactivate” an entry (makes all of those transactions default to “none” let’s say).
Hi @HomeFlip, you are new and so probably you are missing two fundamental thing. First, right now Manager is hardly customizable in input (plugins) and in output (custom report are far than usable). Second, Manager is one man show.
So you can think of the most useful and complex implementation but it will take years before you can come up with such a complex system or even never see it.
That all said is better to have something in a short timing rather than have nothing. So I’m for grouping tracking codes even if it’s not the best solution of the world.
Davide, with all due respect, Manager is a wonderfully complex system with all of the coding capabilities. Perhaps not mature in all aspects, but…
I was not assuming that Manager was any more than a one-man-show, that being Lubos.
My whole point in the sermon was to emphasize there is a different way of doing business for almost each and every user of Manager. In some instances, perhaps not much of a difference, but still a difference. And each could possibly be lobbying and clamoring for a different use, configuration and location on each functional input screen and output form. Lubos, Tut, Brucanna and whomever else may be there supporting development and use, cannot keep up with the surge of individual “requirements”, whether “nice to haves”, “locale requirements” or “I need to”.
One poster (Call him “A”) was trying to resolve an invoice issue with a supplier (Call him “B”) who was providing a sub-manufacturing service using material/components provided by A to the supplier (B).
The supplier (B) had accepted the materials, used them to complete the sub-service, then turned around and billed A for the service as well as the materials provided and refusing to give A a credit memo for the materials.
The discussion was enjoyable to follow, especially some of the responses, all of which tried to help User (A) resolve the Accounting issues involved. The trouble was, it was not an accounting issue, It was a Management Process Issue.
Nowhere in the discussion, that I could determine anyway, did anybody ask, “Did you have a Contract Agreement with this Supplier?”. Or, "Did you award that work to the vendor with a Purchase Order, and did that PO include Terms and Conditions stating that "This is a PO for Labor and Assembly services at the agreed rates shown in the proposal, No.XXXXX, dated _________, ____. And “Materials are delivered to B, for which B will submit receiving documents with invoice for services by B”. Perhaps another page or so of additional conditions…all of which should be agreed to somewhere outside of the PO.
None of that is an accounting issue, but it distinctly points out that another user found a way to get wrapped around the axle trying to do business his/her way, but depending on an accounting system to provide the capability to pull their butt out of the wellhole.
I still disagree that “Tracking Code” be used as a “be-all, end-all” code. Specifically because it touches so close to the heart of Manager as an accounting tool. I have high regard for using “Tracking Code” to separate reporting columns on Income/Expense Reports, but that’s it.
As I indicated above, think carefully how you use it, for without the ability to “inactivate” it, not one of us has the omniscient vision to understand how it is, or will be, used.
Keep it simple, find a Custom Code to do that dirty work for you.
Guys I really enjoyed your comments, anyway I still think the ability to group tracking codes would help in reporting activities.
I also used to think of a feature I termed ‘Tagging’ where a user can tag a line item to an already created tag or label. The user can tag a line item with many tags. For example tag a line item to a division and tag the same line item with a tag called Patrick (Patrick Being a sales agent). You can add many tags as you wish. Tags pop up when you start typing the name.
When ever you generate a report (Income Statement) and select a tag, you get all transactions for which the tag was used arranged in a statement form to show profit or loss.
Tracking codes only allows for adding one code to a line item. This will allow for many and solve many problems.
For example, a user may want to assign a transaction to a sales agent and also to a division but can only select one tracking code (please don’t suggest custom feild).
Anyway I can promise you guys that Manager will be changing to be better. It not that I have some information to that but I know for sure it will have to change to be relevant in the accounting software market and many of these features we want could be added by the user if they wish through customization or something. Alse users are always going to ask for features which are outside the circles of accounting, it is normal. For an accounting software to be relevant it has to support other business processes such as Procurement management, contract management, materials management, job costing, warehousing, etc. There are so many packages out there.
At the risk of revealing how old I am, to quote a TV show, named, “Kung-Fu” from the '70’s in the US:
Seek not to know the answers, but to understand the questions.
The use of “Tags” is a linear solution…how can any system or reporting logic determine the priority or level of summary out of a set of codes that are of equal level, whether in the same sequence, or different sequences?
Tags are an answer to a question, but not the same question you implied in your statement(s):
The question is,
What organization of data are you trying to accomplish?
The organization of data is that Patrick belongs to the East Division, and you want to know how he stands amongst the Eastern Division, as well as how he compares to Stewart in the West Division.
This question cannot be solved in a linear, tag-oriented code structure (as is “Tracking Code”, and any Custom Code you wish to create under the Settings Menu)
We can resolve the “Patrick / Stewart” question with an Heirarchical Coding selection in creating “Custom Codes” (like “simple text”, “paragraph”, “drop-down”). But, you can’t build it right there, you have to use a “Settings function that creates it, saves it to a named file”, which can then be selected and attached to a Custom Code in an input form.
How does it work???
Simple. In an Hierarchy of Codes, every code (e.g., “child” has one, and only one, parent, except one…the ultimate great-great-grand-parent, or what ever you want use to visualize the box and wire diagram it creates. To emphasize…
Any parent, regardless of level in the structure, can have many children, but not less than two, because that does not make sense to have a parent of one data set and a child share the same dataset?
No child may have more than one parent.
Graphically, it is a Box & Wire Diagram, typically seen as a Work Breakdown Structure (WBS). Codewise, it is 2 boxes, one for entering a new child code, another to select it’s parent…one and only one. You may have a window next to it to show the whole structure, using indents to define Parent-Child relationships, but it still requires planning, patience, and in some instances a sharp stick (old deer hunting joke) before wildly slamming codes into a hierarchy.
Need an Hiearchical code structure to place Patrick and Stewart into a Global Sales Organization? Create a structure to define the Corporate organization.
Presto! You have the OBS! See where this is heading? Instead of gazillions of Tracking Codes, Tags, or Custom Codes, a few simple heirarchies organize complex data into understandable summary levels in reporting. And, it is fundamental to structuring a “Job Cost” module. And "Themes can help tremendously to visually distinguish between Regions or Orgs (Don’t go too overboard with that statement).
That was my emphasis in resurrecting the thread. And you’re absolutely right, Manager does not do this yet. But it is not that far-fetched as to be way down the development roadmap.