We are using IDS to fetch all Invoices and their associated financial transactions. The goal is to match up the invoice with all transactions that are taking its balance to zero.
There seem to be 2 IDS objects that cover these transactions:
Payment
CreditMemo
While both objects are referencing the CustomerId, only the Payment references the Invoice object.
The CreditMemo is not referencing the Invoice with which it is associated.
We know there must be some internal reference between CreditMemo and Invoice, because it is shown under "Related transactions" when viewing the Invoice in QuickBooks.
How can we fetch the association information between a CreditMemo and an Invoice through IDS?
You can’t see the link between invoice and creditmemo in IDS V2. Based on the IDS V3 spec (http://developer.intuit.com/fmsv3spec/index.html), it looks like the linkedtxn will be available when it comes out and hopefully that will show the linked transactions.
You can pull all the CreditMemos - https://ipp.developer.intuit.com/0010_Intuit_Partner_Platform/0050_Data_Services/0500_QuickBooks_Windows/0600_Object_Reference/CreditMemo but they do not show the linked transaction back to the invoice like payment does.
You can see if the credit memo has been paid/used or if the creditmemo status is Payable it means the creditmemo is still available.
See this posting https://idnforums.intuit.com/messageview.aspx?catid=86&threadid=18156
Related
I have two entities Account and Transaction. Following conditions are applicable for the db.
Each Account has different transactions
allTransactions has to many relationship with Transaction table
Each transaction related to one account (Debited from Account/ Credited To Account), accounts has to one relationship with Account Table.
Amount can be transferred between the accounts. (Transaction)
Problem: How can i relate the transaction table with Account Table for the above (point 3) condition
My Coredata Structure
If you are transferring an amount from one account to another account, you need references to two accounts.
Transaction
- fromAccount <<--> Account
- toAccount <<--> Account
On the Account side you will need two inverse relationships.
Account
- outgoing <--->> Transaction
- incoming <--->> Transaction
So you do not need the property accounts. (It is also confusing to name a to-one relationship in the plural.) Similarly, you will not need allTransactions.
I'm building an ecommerce Rails application, and I want to create a relationship between Products and Users.
Users can "favorite" many products (and products can be favorited by users).
Users have a "history" about the products they saw.
In SQL databases, I know I can create, for example, a History table and put the product_id and user_id. And a Favorited table with also product_id and user_id.
But in MongoDB, how can I build this relationships?
I read this blog post: http://blog.markstarkman.com/blog/2011/09/15/mongodb-many-to-many-relationship-data-modeling/ and realized that I can create an array of products inside Users collection, and an array of users inside Products collection. But I don't know how to set what is the favorited product and the history product inside Users collection.
Thanks in advance.
EDIT
Thought: I'm thinking in create two models (ProductFavorited and ProductHistory) inheriting from Product model/collection and use it inside users collection.
The best data model in MongoDB is one that fits your application use.
So the questions to ask are "When are you going to see these favorited Products? How are they displayed?" and "When are you going to see this History? How is it displayed?"
Some possible answers and advice might be:
"A user will be able to click a menu item labeled 'Favorites' and see
a list of Products that they have favorited."
Then it makes sense to store the information you plan to show in a
favorites array on the User document. Or if you expect the User
document to be growing too large, a separate favorites collection
with just a user_id as _id and then just the array of favorites as
the only other element in the document.
Or:
"A user will go to a Product page and see a list of other users that have favorited that Product."
Then it makes sense to store it the other way with all of the users that favorited the product in the Product document. Or if you think the Product document will grow too large then in a separate collection with product_id as the _id and the favorited_users as an array which is the only other element in the document.
The thing to always keep in mind is how the data will be used in your application.
Information about Data Model in MongoDB.
When accessing the D2L Valence API as a student, /d2l/api/le/1.1/(D2LID: orgUnitId)/grades/categories/ and related GET requests return a HTTP 404 error where the orgUnitId is a class.
The route GET /d2l/api/le/1.1/(D2LID: orgUnitId)/grades/values/myGradeValues/ works however the categories and grades are displayed at the same level in the JSON hierarchy and there's nothing to associate between grade categories and grades.
On the first part of your question: the user making the call to fetch grade category information must be enrolled in the course offering with a role having permissions to see grade category data. The role permissions needed to see grade category data may not be the same as the permissions needed fetch one's own grade values. However, the '404' returned is odd, and would suggest that the orgUnitId you passed in was not found: if the user didn't have permission to retrieve the categories, then you'd expect to get a '403' error returned, not a '404'.
On the second part of your question, the call to get my grade values returns a flat array of GradeObject structures. You can distinguish between the grade object types by examining the GradeObjectTypeName property: for grade categories, it should say Category; for other grade object types, it will have the type name for that grade object (i.e. Numeric, PassFail, and so forth).
I am looking at documentation http://developer.eventbrite.com/doc/attendees/.
First of, it seems like the actual 'id' field in the json returned represents the attendee record id, as there is the actual 'event_id' field. Seems like a documentation issue.
I need a field I can use as an identifier to sync Eventbrite attendees with my records.
The 'id' field is the obvious candidate. Can I rely on 'id' to be unique across the whole API or it may be reused from event to event?
What is the relationship between 'id' and 'ticket_id'? Can multiple attendees with diff ids have the same 'ticket_id'?
What is the relationship between 'id' and 'barcode'? One attendee can have multiple barcodes?
Would appreciate a clarification.
Good question, I'll update the docs with some additional info.
The short answer:
The ticket_id is the ID of a specific ticket type (General Admission, VIP, etc). A user may purchase multiple tickets of multiple types in a given order. An 'attendee' record is created for each ticket that is purchased.
The attendee_id is meant to identify the mapping between a user and a ticket type within the event's context. A user's attendee_id will be different for each ticket.
There should be one barcode_id per attendee_id. Barcode values can be used to check an attendee in or out of an event.
Hope that helps!
#RyanJ
I am creating a database based on a ERD i have designed according to some business rules where I am allowed to make assumptions and implement them for the future.
Business rule:
Entity relationship diagram
Based on the business rules the customer is invoiced for the holiday, hence the relationship would be 1..1, however I have been left to assume that the customer may receive one or more invoices for the same reservation, that's if the customer makes changes to the reservation or a reminder invoice is raised.
IF i leave the relationship 1..1 then i might a swell get rid of the invoice table and use the reservation as the invoice since they use the same attributes and link it to the payment_method.
I don't know which way is best, first time doing databases...
Please advise
It almost sounds to me like you should make it a 1 to many relationship between the invoice and the reservation. You say that a customer may receive multiple invoices for a single reservation, such as if the reservation changes. That makes me think that it should be a one reservation to one or more invoices.
What I might include on the invoice table would be a field telling if it is the latest invoice, or a nullable field pointing to the next invoice. If an invoice becomes invalid/outdated/superseded, then a new invoice is created and all previous invoices then have their superseded field filled in to point to the most current invoice. That way you can still keep a trail of previous invoices as well as the current one.