Our company has two lines of business - a project side and a pure product side. We want to track each as seperate P&Ls, particularly gross profit. Is there a recommended way to do this in NetSuite? For example, we were thinking of creating two departments, one for Products and on for Projects, but that doesn't really work because POs may contain parts for both sides of the business. Is there an intended mechanism for tracking different business units?
You might want to look at expense allocation. You can set up allocation templates so that overhead expenses are allocated by department or location.
Other than that if your parts are not some sort of consumable/overhead I'm guessing your purchasing is a little off or your project and product businesses are not that separate.
Related
I am working on my website where I sell concert tickets.
I am working on designing the part of the website where I generate tickets based on seat and rows available.
After some thinking and drawing I have to the conclusion that this design would be best for my problem.
I was wondering is this poor design or are there any improvements that I can make?
Thank you
I wouldn't expect to have a table of unbooked seats. A table of bookings seems more logical. Your concerts table looks questionable if you expect to have a series of dates for the same concert.
Perhaps you should first sketch out the key functions of your site as User Stories or Use Cases and list out the required attributes for each. That could give you a better set of requirements for your database design, e.g. what customer attributes; what about seat attributes such as restricted view, standing places or accessible places for the disabled.
So, not really sure if this is the right place for this but I have this current Context level data flow diagram for the bellow specification extract and I have never done one before so I was wondering if it was correct or if it needs fixing? any help appreciated
This is a link to a screen of my current one http://i.imgur.com/S4xvutc.png
SPECIFICATION
Currently the office staff operate the following processes:
Add/Amend/Delete Membership
This is run on-demand when a new membership application is received or when a member indicates that he/she wishes to make amendments to their details. It is also run in those rare instances when a membership is terminated at the discretion of the manager. A new member has an ID number allocated (simply incremented from the previous membership accepted). A membership balance is also maintained for accounting purposes.
Another process operates in a similar fashion on data associated with transfer partners.
Monthly Maintenance
This is run on the last day of each month to issue requests and reminders for subscriptions due, and to remove memberships where fees remain outstanding. Standard letters are also generated. Membership balances are updated as appropriate.
Payment Updates
This is run prior to the Monthly Maintenance, with membership balances being updated accordingly.
Payments to partners are also disbursed at this time.
New Member Search
This is run whenever a new member has been added to the database. The partners are partitioned in terms of vehicle category and location. Normally, there is a limited choice of partner in a particular location (if, indeed, there is any choice) but for some popular destinations, several partners are involved in providing the airport transfer. Thus, a search is then made through the appropriate section for potential matches in the following manner:
A search is then made on the grounds of sex (many female passengers in particular prefer a driver of their own sex, especially if travelling alone or in couples).
Matches are then selected according to factors such as cost (if available), availability of extra requested facilities (such as child seats, air-conditioning etc.)
Existing Member - Additional Searches
These are run on-demand in the same fashion as for a new member's search. Members may of course request any number of such searches, but a separate payment is due for each.
All financial transactions (payments) are also posted to the separate Accounts file, which also stores other financial details relating to running costs for the consideration of the firm's accountants at the end of the financial year.
Thanks for any help, regarding this level 0 Context only DFD
It needs some fixing.
The most obvious flaw is that you use verbs in your dataflows. In some cases this can be fixed easily by just discarding the verb. Return balance and status is not a datflow, but balance and status is.
In others cases it is not so easy. Check Balance, is it outstanding? sounds more like a Process than a dataflow. It looks like Accounting is responsible for doing that job. So will Accounting produce a list of outstanding balances? Or will it return a single balance and status, and if so, based on what input? Will your Airpot Transport System send a list of balances to check to Accounting?
Take for example Monthly Maintenance. What matters is that you want
requests and reminders for subscriptions due
Standard letters
These need to be visible in your DFD
The fact that you want to remove memberships where fees remain outstanding, probably has not place in the toplevel diagram, because that looks like an internal affair.
In general, focus on what the System produces. Maintaining internal state is secondary, is is a necessity to produce the desired output.
While privacy laws are normally outside the domain of us developers, I do think it's an important topic to keep here at SO because we developers should take the responsibility to warn our employers if they want something that would break some laws... In this case, privacy-laws... Normally, we developers don't have to think much about legal stuff, but this seems to become a much bigger issue these days. It's too easy for employers to forget about these things but the consequences of these laws could be very harmful for future developments...
Many countries dictate limitations on how companies are allowed to store privacy-sensitive data in databases. For example, social security numbers, bank account numbers, criminal pasts, former employees, birthdate, relatives, sexual orientation and whatever more. Such data is limited to certain restrictions that could differ from country to country...
The Azure platform makes it even more complex since Azure is owned by an US company (Microsoft) and the US law dictates that Microsoft needs to hand over data if the Feds need it for some research. (This article highlights it.) Thus, this could put Azure in conflict with specific laws in certain areas of this world.
What I need to know is which countries would have such a restriction that I cannot offer customers in those areas an Azure-based solution that would process privacy-sensitive data? (Thus, those countries would need a non-azure, localized solution!)
This is important because I need to display a disclaimer warning those users, making it clear that they might be in violation. Users will tell from which country they are so basically the disclaimer is just limited to those users. (Each user will be maintaining data for possible hundreds of their customers each, so it's a lot of sensitive data.)
There are too many different sets of laws for you to be able to give or even keep up to date that kind of information on your web site.
What you could do is make them aware of the problem and say that users must take in to consideration laws in their country before signing up.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
How do you charge your customer in a project using agile methodology?
Per hour? Then a great deal of trust has to been established before the project.
Per iteration? There's gonna be a lot of budget decisions, which can take time.
Per project? How can you do that when you don't know the scope? The very essence of agile is to not write a big upfront design/specification.
You charge your customer on the base of the terms defined by your contract that will be slightly different from a traditional fixed bid contract. Let's call that an Agile contract.
Some options are discussed by Alistair Cockburn in Agile contracts.
Another great resource is 10 Contracts for your next Agile Software Project by Peter Stevens.
Mary Poppendieck also has great material on this topic. See agilecontracts, agilecontractsworkshop, Contracts Excerpt From Lean Software Development, Lean Contracts. More here.
Short answer is, you won't. There are a few services companies that are making headway doing it, but it is a difficult path. Your ability to sell the methodology and convince the customer you can deliver will be high.
Customers don't want to risk paying for a solution that will never be delivered.
Typical approaches to this problem are to put "will not exceed" cost. However, if you can't control scope, you are the one taking all of the risk.
In short, you are looking for customers that would have signed up for T&M (time and materials) contracts before Agile became the latest fad (I'm part of that fad, but it is just one in a long line of development processes. Aspects of it will continue to grow and some permutation of it will have a different name in a few years).
If your customer has already bought into the use of an agile methodology, then you have a reasonable framework for negotiating price per iteration. For example, you know:
How long the iteration will be.
How many people will be committed to work on the iteration (and their rates).
An approximate scope of work.
A process for delivery and acceptance.
That's a lot more evidence on which to base pricing decisions than is available for most fixed price contracts.
If the agile methodology is purely an internal development process that doesn't involve the customer, then it's unlikely to have much effect on the pricing negotiation between the supplier and the customer. There is an argument that says that a process that doesn't involve the customer in setting scope and expectations at least once per iteration isn't agile at all.
Regarding Mark's comment, there is a very common pricing model based around fixed price contracts with loosely defined scope and optimistic schedules. A common outcome is that both supplier and customer find that their initial optimism was misplaced. Both end up negotiating from weak positions over the things that really matter to them, and both end up unhappy.
Some of the techniques that work well in managing this type of contract are very similar to those used in managing agile contracts (frequent delivery, horse-trading on scope, priorities & price, frank communication, ...) the main difference is that these aren't built into the original agreement, and the contract may not be flexible enough to accommodate all of them.
My 2c as a non-agile practitioner...in a quest to know more...
If you are doing a specific project for a customer, you will need to know the scope of the project to provide a cost and a timescale. The cost of producing this scope of work is more often than not part of the discovery of the project, you either take a hit on this to get the work or charge for this (explicitly or implicitly) In this case, a project cost can be worked out and agreed. Im this case the project is usually broken up into various stages.
Although agile may be iterative and not require a full specification; a goal, at least is certainly required. There must be some form of basic specification/requirement. It may be that you need to break the project up into smaller goals and apply costs accordingly.
The iterations I suspect are more to do with the development methodoology, ie to achieve the goals?
If there is not enough specification to produce a definitively accurate cost, I would say that a "estimate" should be given but work should be charged at an hourly rate as I would assume that there would be greater changes in the decisions made on the project over each iteration.
I've seen it work well when approached in 2 phases:
Phase 1) Inception (timeboxed)
A timeboxed inception period with the client to scope the project. (A one month intense inception for a project estimated to last a year is about right.)
Outputs to this phase are a full backlog of sized user stories, an estimation of flow rate per dev pair, and parameters to estimate project costs based on the number of developers and overheads of having larger teams.
The inception provides a useful budget estimation that can be tracked throughout phase 2, a clear shared vision for both client and supplier, plus the option for either side to walk away. This isn't upfront design, the stories have just enough detail for a lead dev / tester to assign relative sizes.
Phase 2) Delivery (time and materials)
A delivery contract based on time and materials, with budget estimates based on the outputs from the inception phase. The trust built up in phase 1 is vital to making this work. Because phase 1 delivered relative sizing of the entire backlog, by regularly measuring actual flow it is possible to easily and frequently report projected flow rate for the rest of the backlog with increasingly accurate estimates of budget and delivery date. The supplier should be contracted to report these stats at least every 2 weeks, with the option for the client to walk away at any point.
By paying for time and materials, the client is free to change the scope and proirity of the backlog, and is therefore in control of the budget. They are encoraged to prioritise their highest priority / highest risk stories first, and by allowing them to walk away whenever they like they should experience a positive return on investment at all times.
I'm curious to know where people value Data Aggregation. I'm truly curious, if you don't mind letting me know how important this really is to you personally with respect to your work environment, and if you have to work directly with data agg in your line of work.
Really interested to hear about your feedback.
If you persist data (e.g. store it in a database) chances are that the data will be used by managers, statisticians, stake holders etc. to analyze the workings of their software-supported undertaking to make executive decisions. This analysis can only take place by methods of aggregation. There's no one in the world who can look at a million rows of raw data and glean insight. The data has to be summed, averaged, standard deviated etc. to make any sense to a human being.
A few examples of areas where data aggregation is important:
Public Health (CDC, WHO)
Marketing
Advertising
Politics
Organizational Management
Space Exploration
lol. Take your pick!
Very important, what else is there to say?
I work at a large hospital and not only do we have numerous departments using Analysis Services cubes we develioped but they rely heavily on the daily totals and different aggregations they can derive from these cubes by simple browsing. Without the very basic capability of being able to aggregate on some portions of your data you might as well write it on paper (IMO).
Say you have data over every individual sale.
Looking at these individual purchases could be interesting some level level(e.g. whne a customer comes and wants a refund)
However, I cannot send those 20 million records to my boss at the end of each month and say "Heres how much we sold this month".
This data needs to be aggregated and summarized on various levels. The business would not operate if the marketing guys couldn't get an aggregate for each product, the regional boss couldn't get an total aggregate over a time period and so on.
Our databases have millions of rows, of course we rely on aggregation for managment information, not to use it would be to put too heavy a load on the database in order to run large reports which would impact heavily on the users of the database. I can't think of many cases where the database contains business critical information that managers use to make decisions where aggregation would not be needed for managment reports.
I view data aggregation like data in a grid and being able to group, order, and sort columns. In a large grid of data, this is very important. It's really the difference between looking at a pile of numbers and looking at meaningful data.