Guys do you have any good website, showing all necessary information needed on a particular system.
i.e
Inventory system - all modules need to include in a inventory system such as (login module, sales module) and so on.
Thanks in advance
Printable View
Guys do you have any good website, showing all necessary information needed on a particular system.
i.e
Inventory system - all modules need to include in a inventory system such as (login module, sales module) and so on.
Thanks in advance
That's not a bad question, since any programmer stuck on designing a custom ERP/MRP program always seems to have to use their software design skills to reinvent those wheels.
Still, it's more of a question of the business processes. An MRP program at it's core has to deal with Inventory, and two primary things can happen to inventory: You can add to it or you can reduce it. So, next come the modules that deal with Production removing inventory and Purchasing adding to inventory. Then, the next layers onto the system are the immediate sales driving the production, and the estimated future sales driving the purchasing. Next, on top of all of this, you got some financial modules keeping track of the money involved (accounts receivable, accounts payable). Finally, throw in all the "fluff" modules like security, maintenance, adjustments, auditing, etc and you got a simple piece of business-soft. :)
In the end, it's probably better to look on sites describing business processes. Of course, since everyone's business model is slightly different, you'd have to take it all with a grain of salt.
You managed to actually get a question out of that?? I havent got a clue what the OP is even asking for..
All these BusinessSoft packages are set up in "modules" for easy customization and maintenance. The one my company uses has no less than three hundred or so :rolleyes: A company wanting to do something in some custom way only needs to change a few modules with the custom ones. Modules frequently take the form of dynamic link libraries (at least, in the .NET world they do, sometimes, they're nothing more than elaborate scripts in some scripting language or blocks of COBOL to be run through a COBOL interpreter)
It sounds like the OP is tasked to design some form of BusinessSoft, whether it be an ERP system or MRP system or whatever. They're all modeled after standard business models. The OP specifically mentioned "Inventory System" so that clued me in on roughly what he/she was looking for.
There's no "standard" way to break up these business models. A trip through Wikipedia shows how each of these systems are broken up into a process flow; and software developers creating these systems tend to modularize up their systems accordingly.
Still, as I mentioned, there's a lot of what I call "fluff" modules to this type of program. An access control system for example. Most businesses need some form of access control so Bob in marketing isn't playing in the payroll module. An Inventory Adjustment module is another, parts get scrapped, lost, etc and sometimes aren't immediately reported for adjustment. When a plant does it's yearly physical inventory audit, these levels need to be manually adjusted since the lost (or found) inventory has no history of purchase or usage. These things don't generally appear on the business model (which only shows the "ideal" process), but a software designer must know they occur and must add additional modules as needed to their package.
Ahhh I see ;) That brings me to a related question actually - how does a program (.NET) know whether the specified module has been paid for and 'bolted on' by the customer using it? I mean I've seen programs like this before and I always assumed it was just a separate DLL for each module as you said but then how does that work if your program has referenced 10 DLLs, if 5 of them dont exist when your program starts up then wont it error even if you havent actually called them yet?
Typically, each "bolt on" module has some internal checksum it can produce via a function. The main driver program starts up and scans for all the modules. The optional ones that fall under separate licensing are asked for their checksums. Then, all these checksums are ground together and hashed into some license key or composite license key. If the keyfile's hashes match up, then all is good. If one of the optional package keys doesn't match up or is missing, it doesn't load that module. It's one method of dealing with licensing. There's a million schemes out there though.
The problem you're referring to can be gotten around a number of ways. One way is to "soft link" the DLLs using Function Declares to the DLL in question. A simple wrapper class and an interface type could be written to accomplish this. I believe another way I heard it could be done is via the Reflection library. Personally, I've never had to do it; our software ships and installs with all modules included and is feature-controlled via a central license system. Different license codes activate different modules.
:) my head getting dizzy, i'm starting to get the laid of the topic, but anyway i get some of your points guys. What about MRP/ERP stuff "????"
MRP stands for Manufacturing Resource Planning. It's a description of the software (and business process) for managing the aspects of a manufacturing environment. It handles things like Inventory, Usage, Work Time, Demand, Purchasing and General Accounting.
ERP stands for Engineering Resource Planning. It's a description of the software and business process for managing aspects of engineering. It handles things like Content Creation, Revision Control and Engineering Changes.
Typically, the two are integrated into one super-package since there are correlations between them. Engineering creates the part numbers, and those part numbers must be purchased and stocked in inventory for example. An engineering change could lead to the scrapping of now incompatible parts on the shop floor. This is why I describe the system as ERP/MRP.
Does it include system details for payroll and other business system. I know that imagination and real life experience could be the best thing to know what should i put on a specific system that im going to do. However, all modules that i put on my previous system is just basic, and like what you said in your last post reading some articles relating to the system could be an option. Though, i don't understand some of them. :)
That's entirely up to you. Payroll is one of those things that is completely independent to these systems since nothing in the ERP or MRP systems really affect it. While MRP can calculate and tell you how many potential work-hours you need to build X number of parts, whether or not people actually work those hours, and who works them is independent of the system.
The only place where payroll is tied into business-soft is at the General Ledger level.
My suggestion, start small and start with some standard assumptions. Start with the general ledger to track transactions on various accounts and an "accounts receiving" and "accounts payable" module aid in most standard transactions. Accounts payable would contain a list of Vendors you buy things from. Accounts receivable would contain a list of Customers who buy your products.
Next, you need an inventory module that just tracks your parts and can construct assemblies from those parts into other parts. This is so you can tell the system: I have partA, partB, and partC. These parts are purchased parts. I also have partD which is a part manufactured in our house, and you need 3x partA, 1x partB and 1x partC to make a single partD. Thus, when a customer orders a single partD, you can subtract 3 partA's, 1 partB and 1 partC from inventory.
You add a Purchasing component that ties into your Accounts Payable module, so when your purchasing department orders 100 partA's from wherever you buy them, it can make a purchase order and deduct the money from the proper accounts.
Next, you add a Routing system to the Inventory module to track work-cost. All this does is take a finished part and add work hours to it: To make a partD, you need 3 hours on machine1 and 2 hours general labor. This is used to calculate man-hour cost so that you can more easily figure out the sales price of partD.
Next, you add an Ordering module. This takes customer orders and generates work routers. This is so when a customer calls and orders 5 partD's, you can send your shop floor an order saying: Need 5 partD's, this requires a total of 15 partA's, 5 partB's, 5 partC's, 15 hours on machine1 and 10 hours general labor.
Finally, you make an invoicing and shipping module that actually charges the Accounts receivable module and prints the paperwork for everything.
Hi all-
Along similar lines (but not the same), I am relatively new to programming, and self-taught. However, I have picked up a lot, fast.
Where else might one look for other architecture models, and are there any actual examples to be found?
I Manage Occupancy and Compliance for a large number of Affordable housing units in the USA. We need a way to manage a complex mingling of financial, regulatory, and programmatic concerns, within an asset management context. There are commercial property management programs on the market (Yardi, OneSite, AMSI/eSite), but these do not address our model effectively.
Specifically, I am interested in expanding my knowledge of the modular assembly loading approach. I ahve found some info on the forums re: plug-in type architecures, but somehow I don't feel like I have the whole picture.
Mind you, I am not looking to release commercial software (Yet!), but I AM looking to put together an app for work. The scope ios fairly large, and the data and regulatory environment is somwhat dynamic, so I am looking to somehow build a very extensible, easily maintainable, "programmable-by-a-non-professional" system. Oh, and I want my cake, AND i'm gonna eat it . . .!
Seriously, think 2-tier, Windows-Forms (eventually WPF, but not yet) based fat-client, SQL Server Back-end, able to add assemblies without recompiling, and have the added functionality "magically appear" in the main menu of the program. SO, Somewhere between "Enterprise/n-tier solution" and "Old, access-based, cobbled-together app in VB6". I am using vs2008 and SQL Server 2005.
Also, real-world, working examples of UI architecture (as opposed to the more basic examples used for tutorials and such). COming up with an extensible UI is HARD!
Am I dreaming, or do I need to go to grad school before I aim this high?
Any ideas? (NOTE: I am going to check out this MRP/ERP thing on Wikipedia nOW, and Google. Even though I suspect the business model is very different, HOW it gets "architeched might help!).
Enterprise Resource Planning looks more familiar.Quote:
Originally Posted by Jenner
See, when I was taught it, it was "Engineering", and it was the software system that handled the design-flow and engineering end of the house. CAD drawings management, revision levels, sign-offs, quality checklists, gaging, engineering change notices, and product changes cascading through dozens of sub assemblies and products. Some I've seen also handle part serializing for traceability so you know the exact revision levels of all the parts just by it's serial number.Quote:
Originally Posted by dee-u
It made far more sense to me than later terms of "Enterprise" which to me is a meaningless word unless you're describing a ship on Star Trek or a US Aircraft Carrier.
I've always thought it was Enterprise not Engineering... as an ERP system doesnt always relate to engineering.
This definition from google sums up what I had always been told it was:
Quote:
ERP is a business management system that integrates all facets of the business, including planning, manufacturing, sales, and marketing
I guess definitions change. I wonder what they're calling Engineering Resource Planning now that the acronym "ERP" is used up.