Hey everybody, I guess I have a pretty basic question but unfortunately, I canât figure it out myself 
I just wanted to create my first Purchase Order. Neither the Purchase Order DocType nor the Purchase Order Form say that the Required by field is mandatory.
However, when I try to create a Purchase Order, ERPNext tells my Required by is mandatory.
And I just canât get my head around how thatâs possible and why ERPNext is working this way?
The red asterisk * in the header row of the Items Child Table is the sign for the requiredness of the corresponding fields in the Child Table entries.
This looks like an inbuilt tendency to require things happening in the future in a prescribable way.
Sounds like Just-in-time, doesnât it?
(But then, who can really predict the future of oneâs own intentionsâ realizations? Thatâs a difficult call in times of uncertainty, aka unexpected supply chain problems.)
A reason for having separate Required by fields for each Item could be that they are required at different dates, but ordered together.
On the other hand, if anything were not required, it would leave the door wide open to all kinds of further questions. How long would be the time of ânot required by any point-in-timeâ? 1 day, 1 week, 1 month, 1 year? It also might open a can of worms regarding accountability.
So you might not want to set such a date, but you still would have some expectations. Your Framework agreement or TOS or other contract, maybe legal requirements, might set such dates. So you could use these as a default.
Hi @tgraupne,
A âRequired Byâ date on each Item: If you are expecting part delivery, your Supplier will know how much quantity to deliver at which date. This will help you from preventing over-supply. It will also help you to track how well your Supplier is doing on timeliness.
Please check the whole documentation if you want to read it.
I hope this helps.
Thank You!
@NCP and @Peer , thank you for your responses.
I believe I do understand now, why the Require by column exists in the Items table of a Purchase Order.
However, what I donât understand is where I can configure this. 
The Customize Purchase Order Form oder the Purchase Order DocType only show this particular field of type Table, but they donât give me an option edit the table.
The Item DocType also does not have a Required by field.
Would somebody be able to help me understand where the content of this Table Items in a Purchase Order is defined?
Hi @NCP, thank you so much for helping me to understand this.
I honestly did not know before, that Forms can exist without a DocType.
I saw the reference to Purchase Order Item before, but looking for the DocType, I was not able to find anything. And since Frappe was always stressing in their Getting Started Documentation and in Tutorial Videos, that "everything is a DocType in ERPNext, I was not sure what to do about it.
Anyhow, with your help, I was able to find out where ERPNext is configuring Required By as a mandatory field. While I was trying to change this, the following happen:
So, now I am wondering, what are standard fields and why canât I update them?
There are other overrides that you have to use to change any built-in mandatory fields in ERPNext.
Another option is to set it to âTodayâ, it will always put todaysâ date in the field, thatâs the option I went for and hid the field from display as we donât use it.
It is true that (almost) everything is a DocType.
However, each DocType has a single role in a hierarchy:
Parent DocTypes stand alone. Each has its own Form. Some examples would be Customer, Supplier, Item, Purchase Order. Or even something like âBuying Settingsâ
Child DocTypes cannot be interacted with, except via a Parent. They donât have their own Form. Instead, you access them from the Form(s) of their parents. These are things like âSales Order Itemâ, âPurchase Order Itemâ, âStock Entry Detailâ.
Here in the USA, we sometimes think of Parent as âdocument headersâ, and Child as âdocument linesâ.
A standard field is a DocField created and owned by an App. It is represented by a JSON schema file.
Whereas custom field is created via the Customize button, and only stored in SQL.
The idea behind âNot allowed to disable Mandatory for standard fieldsâ is to prevent Users from breaking the App. If the App says itâs mandatory? Then it should be. An individual User shouldnât be allowed to disagree by using the Customize button.
This limitation is sometimes be very inconvenient. Your company might have a Good Reason for making a DocField optional, instead of mandatory.
Go To example.com/app/doctype/Purchase Order
Click The Server Script and Write This Script
Then Test It and I Hope it helps.
