Training data has more variables than test data Given a train and test data that looks like the below:
Im wondering if it is necessary to drip the id field in the training data if the id field is present in the test data.
Also, if the test data does not have a field that is present in the training data, should i drop that field in the training data or keep it and train a model in all the train variables?
Update 
The field to predict on is amount_spent
training
id   date        number_of_x  amount_spent
123  2019-01-01  2            15
123  2019-01-02  2            17
123  2019-01-03  2            16
124  2019-01-01  2            10
124  2019-01-02  2            8

and test data with these fields:
test
id   date         amount_spent
123  2019-01-10   10

 A: To answer your questions in reverse order:


*

*The columns/features used to train your model must be identical to those in your test set. I'm not sure what kind of model you'll be using, but if you don't do this, you'll most likely get an error straight-away when you try to make predictions on your test set.
More conceptually, when training your model, it learns a set of parameters with a shape that matches the dimensionality of your featureset (the number of columns in your training set). If your test set is missing one or more of the columns that were in your training set, when your model attempts to make predictions using the coefficients it's learned, it will suddenly be surprised to find that there are no values in the test row to multiply by those coefficients that it learned from the columns that were originally in the training set (but now are missing from the test set). This is the point at which your model would most likely throw an error.
If every row in your test is missing an entry for a particular feature that's in your training set, you should definitely remove the feature from your training set. However, if the case is that only some rows in your test set are missing values for a particular feature. You could always leave the feature in your test set, and then impute the missing values with the mean or median (you can see which works best) of all the values for that feature in the training set. You could do this with SkLearn's SimpleImputer class, for example. Even better, some models like LightGBM (since it uses decision trees) automatically handle missing or NaN entries for features in the test set on their own without you first having to replace the NaN entries with some other number.
One other perspective to think about this from: you didn't mention whether or not you have a validation set. If you do, it should be the most recent 20% or so of the rows in your training set--it looks to me like you have a time-series dataset where you're trying to make predictions about future behavior based on prior behavior. Since the whole point of having a validation set is to ascertain how well your model will work when its deployed in the real world, it's imperative that the inputs (rows) in your validation set be as similar as possible to the kind of inputs you expect your model to have to predict on when it's deployed. If you know for a fact that your model will never, ever have inputs that contain a given feature, then it makes no sense to train or validate a model that does, in fact, use that feature. Doing do would give you unrealistic expectations for your model's real-world performance.

*Removing any columns that serve as a simple index or label would likely help your model's predictive performance to improve. Intuitively we would not expect a label or index or ID# etc. to contain any predictive power. Typically, removing completely unhelpful features reduces the chance that our model would get confused and think its found a pattern where none exists.
However, in your case, as I said above, it appears that your data is time-series data, where your test set contains dates that are further in the future from the dates in your training set. It appears that your model will be attempting to predict future behavior of individuals based on their previous choices. In this case, I would say that your 'id' field is likely a useful feature (intuitively, we would expect different individuals to have different buying patterns). 
If the goal of your model is to indeed predict future behavior, the only thing I recommend you keep in mind is that the dates in your test set should not be earlier than any of the dates in your training set.
