I know this may be a stretch, but does anyone know where to look in the QuickBooks tables for an inventory item's serial numbers?
I have looked through all documentation I can find and can not seem to find the table that holds the serial numbers. Any advice is greatly appreciated.
Additionally, any information on where/how to pull an items Average Cost would be awesome too!
SerialNumber is only available in the ItemFixedAsset table.
AverageCost is available on the ItemInventory and ItemInventoryAssembly tables.
Here is some useful documentation for the SDK that may still help you. Intuit On Screen Reference And here is a reference for the QODBC Table Schema. Using these two references I found...
The OSR ItemQuery Response shows all the different item types and their fields but the data in QODBC is broken out by item type. I found the fields here and confirmed they are on the individual Item- tables in QODBC.
Hope this helps for this and future research.
Additionally, you can refer QODBC-Desktop knowledge base - Where Item Serial Numbers or Lot Numbers are stored
or
you may visit QODBC Table Schema and click "ALPHABETICAL LISTING OF ALL TABLE'S DETAIL", this will list out all the tables and fields, Just search for "SerialNumber"
Related
I'm a new user to QLIK, scripting & overall beginner. I am looking for any help or recommendations to deal with my tables below. Just trying to create a good model to link my tables.
Created a sample here
file The original 3 tables are different qvd files
Transactions table has multiple columns and the main ones are TxnID, SourcePartyTypeID, DestPartyTypeID, SourcePartyType, DestinationPartyType, ConductorID.
Customers Table - CustName, CustID etc.
Accounts Table - AcctID, AcctNum, PrimaryActID etc.
With transactions it can relate to multiple CustID's/AcctID's which are linked by the Dest/SourcePartyIDs. Also the transaction has a source/destination party type field where A = Accounts, C = Customers & some NULLs.
I have read a lot on data models and a link table for star schema or join is recommended but I am unsure how to code this because these are also based on the Source/DestinationType fields (Transactions Table) where A = Accounts & C = Customers. Have tried to code but not successful.
I'm unsure how to join based on SourceType/DestinationType = Accounts or Customers. Link table or ApplyMap() with a WHERE clause?? Any suggestions
Hopefully your introduction to Qlik is still a positive one! There are a lot of resources to help you develop your Qlik scripting capabilities including:
Qlik Continuous Classroom (https://learning.qlik.com)
Qlik Community (https://community.qlik.com)
Qlik Product Documentation (https://help.qlik.com)
In terms of your sample data question. If you are creating a Qlik Sense app you can use the Qlik Data Manager to link your data.
This is excellent because not only will it try and analyse your data and make useful suggestions to link fields, it will also build the script which you can then review and use as a basis for developing your own understanding further.
Looking at your sample data, one option might be a simple key field between a couple of the tables. Here is one example of how this could work.
Rod
[Transactions]:
Load
// User generated fields
AutoNumberHash256 ( [DestPartyID], [SoucePartyID] ) As _keyAccount,
// Fields in source data
[TxnID],
[TxnNum],
[ConductorID],
[SourcePartyType],
[SoucePartyID] As [CustID],
[DestPartyType],
[DestPartyID],
[etc...]
From [lib://AttachedFiles/TablesExamples.xlsx]
(ooxml, embedded labels, table is Transactions);
[Customers]:
Load
// User generated fields
// Fields in source data
[CustID],
[CustFirstName],
[CustLastName]
From [lib://AttachedFiles/TablesExamples.xlsx]
(ooxml, embedded labels, table is Customers);
[Accounts]:
Load
// User generated fields
AutoNumberHash256 ( [AcctID], [PrimaryAcctID] ) As _keyAccount,
// Fields in source data
[AcctID],
[AcctNum],
[PrimaryAcctID],
[AcctName]
From [lib://AttachedFiles/TablesExamples.xlsx]
(ooxml, embedded labels, table is Accounts);
I have a database of economists in Microsoft Access, and i need to transfer it to Neoj.
Keep in mind that all these economists have also been teachers.
So, I have a table - Economist - where i store all economists data, with an ID "codecon" for each economist. Then, i have a table - University - where i store information about Universities, with an ID "coduni" for each University.
As last i have a table - Subject - with subjects informations, with an ID "codsubj" for each subject.
Now, in Access i have another table - Teaching, where i use the previous IDs to say that "Economist codecon teach Subject codsubj in University coduni.
How can i create this type of link in Neo4j, where i can only have relationships between TWO nodes?
Any help would be great. Thanks.
You will want to think about what your graph data model is going to look like. After that, you might want to use a tool to model it. Finally, you'll want to load the data in. You can use LOAD CSV if you've got the data exported out of Access as csv files, APOC has an XLS importer.
I think you'll find this following starter guide - going from relational to graph helpful. I would also suggest you start with exporting your tables to begin with to CSV.
For data modelling, I find arrows helpful.
I'm building a DW just like the one from AdventureWorks. I have one fact table called FactSales and theres a table in the database called SalesReason that tells us the reason why a certain costumer buys our product.
The thing is there are two types of costumers - the resselers and the online customers - and only the online customers have a sales reason linked to them.
First of all, can I vave to Dimension tables pointing to the same FK in the Fact? Like in my case - Sk_OnlineCustomer and SK_Resseler both point to FK_Customer. Their Id numbers don't overlap-
And Second,
Should I build a reason dimension, link it to the fact and have a FK that most of the times is null or with a "dummy reason"?
Should I just put the reason in the fact sales without it being a key, just like a technical description that is nullable?
Should I divide the fact in two fact tables with one for the resselers and one for the online customers? But even in that case, I would have some costumers that don't answer to the reason, so the fk_reason would be null in some of its appearences in the new fact_Online_Customer.
In a solution I saw from the adventure works tutorial, it's created a new fact table called fact_reason. It Links the factSales with a DimReason.
That looks like a good solution, but I don't know how it works, because I never lerned in my classes that I could link a fact to a fact, thus I wouldn't be able to justify my option to my teacher.
If you could explain it I would appreciate it.
Thanks!
Please find my comments for your questions:
First of all, can I vave to Dimension tables pointing to the same FK in the Fact? Like in my case - Sk_OnlineCustomer and SK_Resseler both point to FK_Customer. Their Id numbers don't overlap-
Yes the dimension in this case would be Dim_Customer(for eg) and this could be a role playing dimension. You can expose reporting views to separate the Online customer and Reseller customer
And Second, Should I build a reason dimension, link it to the fact and have a FK that most of the times is null or with a "dummy reason"?
Yes it would make sense to build a reason dimension. In this you can tag a fact record to the reason
Should I divide the fact in two fact tables with one for the resselers and one for the online customers? But even in that case, I would have some costumers that don't answer to the reason, so the fk_reason would be null in some of its appearences in the new fact_Online_Customer.
I would suggest you keep one fact as your business activity is sales, you can add context to it, online or reseller using your dimensions. If you would prefer you can have separate Dim_Sales dimension to include the sales type and other details of the sales which you cannot include in the dact
To summarise you probably might be well off with the following facts:
Fact_Sales linked to
Dim_Customer
Dim_Sales
Dim_Reason (This can also may be go to the Dim_Sales)
Dim_Date(always include a date dimension when you build a DWH solution)
Hope that helps...
I am creating an application which requires the user to register. All data entered by user will be stored in this table called "customer". Now part of the information being collected is the address but I don't want to congest the table structure and would like to store address as an object (city, address, post code, etc).
What's the best practice: create an address table and refer the table through foreign key in the customer table or store the customer address as an object and store it in customer table?
I am not sure how parse fully functions so looking for your experience in the answer.
Thanks
I faced this exact problem a few months ago, and solved it by having a pointer in the customer object structure to the additional data. Note that if you do this, you'll need to make sure to include the pointed to field in future customer queries, or the data won't be fetched.
Retrospectively, I'm not sure I'd recommend splitting the objects up. It does create a more normalised data structure, but Parse fights against this in several ways:
You have to remember to include the pointed to field in all future queries. This is a pain.
You can only follow pointers up to a certain depth within a query (I think 3?)
Parse charges you by the database access, so denormalised data can be an issue.
Parse doesn't really support atomic operations or transactional queries, so it's easy to get your data into an inconsistent state if you're not careful about when you save. For example, you update your customer record, go to change the address record, and have the second query fail. Now you're in a "half updated state", and without transaction rollback, you'll have to fix it yourself (and you might not even know it's broken!).
Overall, were I to use Parse again (unlikely), I'd probably stick with giant denormalised objects.
Here is a solution to handle two table by the help of userId.
Note- You are creating a table of REGISTRATION and filling few data by your end(code).
so you can create an other one table for Address. and when you will create a new table of
Address a question will arise that how you manage these table
so its simple here you have same user id for both table "REGISTRATION & ADDRESS"
then by the help of that unique "userid" you can play. And as per your requirement find
the detail of both table and merge as well.
Hope it will resolve your problem .
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I have found some tutorials, but they still leave me with questions.
Let's take a classic example of 2 tables, one for customer details and one for order details.
The customers table in the database has:
an autoincrementing integer customer_id as primary key
a text field for customer name
a text field for contact details
And the orders table has:
an integer customer_id which is a foreign key referencing the customers table
some other stuff, such a reference to a bunch of item numbers
an integer order_value to store the cash value of the order
I need two dataset components, two queries and a connection.
So far, so good? Or did I miss something already?
Now, the tutorials say that I have to set the MasterSource of the of the datasource which coresponds to the DB grid showing the orders table to be the datasource which corresponds to the customers table and the MasterFields, in this case, to customer_id.
Anything else? Should I for instance set the Detailfields of the query of the datasource which corresponds to the customers table to customer_id?
Should I use the properties, or a paramaterized query?
Ok, at this point, we have followed the classic tutorials and can scroll through the customers DB grid and see all orders for the current customer shown in the orders DB grid. When the user clicks the customers DB grid I have to Close(); then Open(); the orders query to refresh its corresponding DB grid.
However, those tutorials always seem to posit a static database with existing contents which never change.
When I asked anothter question, I gave an example where I was using a Command to INSERT INTO orders... and was told that that is A Bad Thing` and I should:
OrdersQuery.Append();
OrdersQuery.FieldByName('customer_id') := [some value]';
OrdersQuery.FieldByName('item_numbers') := [some value]';
OrdersQuery.FieldByName('order_value') := [some value]';
OrdersQuery.Post();
Is that correct?
I ask because it seems to me that a Command puts data in and a query should only take it out, but I can see that a command doesn't have linkage to the DB grid via a datasource's query.
Is this a matter of choice, or must the query be used?
If so, it seems that I can't use even simple SQL functions such as SUM, MIN< AVG, MAX in the query and have to move those into my code.
If I must use the query, how do I implement SQL UPDATE and DROP?
And, finally, can I have a Master/Detail/Detail relationship?
Let's say I want a 3rd DB grid, which shows the total and average of all orders for a customer. It gets its data from the orders table (but can't use SUM and AVG) which is updated each time the user selects a different customer, thus giving a Master/Detail/Detail relationship. DO I just set that up as two Master/Detail relationships? I.E, the DB grid, datasource, query for the total and average orders refers only to orders and has no reference to customers, even if it does use customer_id?
Thanks in advance for any help and clarification. I hope that this question will become a reference for others in the future (so, feel free to edit it).
TLDR: In the SQL world, Master/Detail is an archaism.
When some people say "Master Detail" they aren't going to go all the way down the rabbit hole. Your question suggests you do want to. I'd like to share a few things that I think are helpful, but I don't see that anyone can really answer your questions completely.
A minimal implementation of master detail, for any two datasets, for some people's purposes, is nothing more than an event handler firing when the currently selected row in the master table changes. This row is then used to filter the rows in the detail table dataset, so that only the rows that match the primary key of the master row are visible. This is done for you, if you configure it properly, in most of the TTable-like objects in Delphi's VCL, but even Datasets that do not explicitly support master/detail configurations can be made to function this way, if you are willing to write a few event handlers, and filter data.
At one of my former employers, a person had invented a Master Detail controller component, which along with a little known variant of ADO-components for Delphi known as Kamiak, and it had some properties which people who are only familiar with the BDE-TTable era concept of master detail would not have expected. It was a very clever bit of work, it had the following features:
You could create an ADO recordset and hold it in memory, and then as a batch, write a series of detail rows, all at once, if and only if the master row was to be stored to the disk.
You could nest these master-detail relationships to almost arbitrary depths, so you could have master, detail and sub-detail records. Batch updates were used for UPDATES, to answer that part of your question. To handle updates you need to either roll your own ORM or Recordset layer, or use a pre-built caching/recordset layer. There are many options, from ADO, to the various ORM-like components for Delphi, or even something involving client-datasets or a briefcase model with data pumps.
You could modify and post data into an in-memory staging area, and flush all the master and detail rows at once, or abandon them. This allowed a nearly object-relational level of persistence management.
As lovely as the roll-your-own-ORM approach seems above, it was not without it's dark side. Strange bugs in the system lead me to never want to ever use such an approach again. I do not wish to overstate things, but can I humbly suggest that there is such a thing as going too far down the master-detail rabbit-hole? Don't go there. or if you do, realize that you're really building a mini ORM, and be prepared to do the work, which should include a pretty solid set of unit tests and integration tests. Even then, be aware that you might discover some pretty strange corner cases, and might find that a few really wicked bugs are lurking in your beautiful ORM/MasterDetail thing.
As far as inserts go, that of course depends on whether you are a builder, or a user. A person who is content to build atop whatever Table classes are in the VCL and who never wants to dirty their hands with SQL is going to think your approach is wrong-headed if you are not afraid of SQL. I wonder how that person is going to deal with auto-assigned identity primary keys, though. I store a person record in a table, and immediately I need to fetch back that person's newly assigned ID, which is an integer, and I am going to use that integer primary key now, to associate my detail rows with the master row, and the detail rows, therefore refer to the master row's ID integer, as a foreign key, because my SQL database is nicely constructed, with referential integrity constraints, and because I've thought about all this in advance and don't want to do this over and over again repeatedly, I eventually get from here, to building an object-relational-mapping framework. I hope you can see how your many questions have many possible answers, answers which have lead to hundreds or millions of possible approaches, and there is no one right one. I happen to be a disbeliever in ORMs, and I think the safe place to get off this crazy train is before you get on it. I hand code my SQL, and I hand code my business objects, and I don't use any fancy Master Detail or ORM stuff. You, however, may choose to do as you like.
What I would have implemented as "master detail" in the BDE/dBase/flat-file era, I now simply implement as a query for master rows, and a second query for detail rows, and when the master row changes, I refresh the detail rows queries, and I do not use the MasterSource or related Master/Detail properties in the the TTable-objects at all.