What I want to cover now is the first part of our end to end business case, which is the purchase order
to sales or the FBI.
So now when we look at the end to end process, make a note here that the purchase order and sales orders
use only two items.
The first is the orders IDOC, which is used to create sales orders and create purchase orders.
And the second is the order S.P. IDOC, which is used to update sales orders or purchase orders, and
then the same message type because a purchase order in one partner is actually a sales order in the
other partner.
So they hold the same amount of data or the same type of data.
So that's why we use the same IDOC structure.
Also note here that the purchase orders coming from the customer.
And the message that we send to the customers in X 12 standards and I put this, they're here so that
people get used to the idea that we don't have to work with IDOT all of the time.
There will be some transformation and translations required in building an end to end VDI architecture.
So here is the idea X 12th Standard.
So purchase order is 850, which is acknowledgement is eight fifty five.
Then a few others here that I've just listed, just in case you're interested.
Now that's on one side.
Here is the message types that we are going to use in AP.
You can see here the message types or the change orders and order management here and the Idol types.
And as we go through the process, I'll be sharing you what I call the crib sheet here, and this basically
is a one page summary on how to configure the IDOC.
You can see here in order to make an outbound purchase order.
You need to use the Idol orders DOT five.
You can use orders one, two and three, four.
But I use five.
You have to use the function.
Will do.
IDOC underscore output orders.
But that is captured in the process code.
E 10 anyway.
And the key feels that you need to pay attention when dealing with purchase order.
I docs is the purchase order number.
The material number for example, we could use or we will talk about using internationally agreed standard
mateer number.
So yay and eleven or geet in quantity delivery date and delivery location on there.
Create sales orders signed.
This is an inborn IDOC.
Again we use the same IDOC type, but this time we use the function module input orders.
Yeah.
And we will be using big and the key fields will be the customer, which is order number, the material
number, the quantity that we have to ship or the quantity that's ordered the value.
Sometimes the delivery date in the delivery locations.
Yeah.
And now notice how both the sales order and the purchase order have the same data.
And this makes our life slightly easier.
Of course, when we want to come and do the mapping so the customer will send us, of course, a purchase
order, we receive that message and we create a sales order.
And after the sales order is created, we then send them a confirmation that we have received it.
We also send our reference number and the our purchase order number here.
We also, again, as we said, send the material number, quantity, delivery, date and location,
because some of these may have changed.
Notice that the eye docs structure that we use is the same, but the process code is slightly different.
So finally, once the other party receives the sales or the acknowledgement, it then becomes a purchase.
What acknowledgement on their side?
And any deviations may be a change in quantity or the delivery date or something is then updated back
into the purchase order as an order in management.
So now that we understand from a business perspective how they all work, let's look on a lower technical
level how these eye docs or documents are exchanged and see where we have some Adamah management.
And we'll can talk about step by step how it actually works technically.
So first of all, of course, the customer will create in their own ERP system a purchase order document
itself.
And from there, when they save it, they could have some degree of I don't call LDI management.
They could have some errors in the creation of the idea document.
Well, let's say everything is OK.
That ERP system would then transmit that message to a middleware.
The middleware would then convert that to a standard or format that's been agreed with the partner.
And of course, there could be some area of management in that conversion here.
That file is then transmitted to the other party, usually by the Internet, and it arrives then in
the other party or the receiving party middleware.
And that receiving party middleware will then do some conversion.
Right.
And they will do some mapping to take the format it was given and convert it to the format that is expected
in the receiving system.
And once the eye doctor is in A.S.A.P., we could still have errors in processing that IDOC and then
needs to be, as you say, a management structure to resolve those errors.
And finally, once the IDOC has been processed successfully, sales order has been created.
They could still be some blocks to the order because it's VDI.
A lot of businesses want to put extra checks in place.
So you could have an order block or a delivery block for a particular reason.
Maybe not enough quantity or something else.
And of course, you could have a credit block on the order.
And notice that in each step in which the purchase order is being created, it's been transferred.
There's some transformation.
It comes into the other system is an eye.
There is a little section here at the bottom where errors could happen.
And that's part of building a comprehensive end to end idei architecture, especially in this A-P.
We must have a process in which to monitor and resolve the errors as they happen.
This is a key part when building a total end to end solution.
So what are the most common errors that you would see when processing Adolf's within this process?
Well, usually the IDOC will fail because the master data is not there either.
The maturer master doesn't exist or the infill record isn't created.
And so for.
The second type of error is that some internal value is not cannot be determined.
Let's say you can't determine the sales or the plant or something.
Incorrect formatting.
This is quite rare, but it does happen.
This is where, for example, maybe the date or the currency uses a combo instead of a doorknob and
so forth.
Well, we we do have those.
We also have business logic that could lead to blocks.
Now, this is pretty normal.
My take.
The customer doesn't send you a price when the price is wrong or they have a minimum order quantity
and that's not respected and so forth.
This is normal as part of the and as part of the day to day business.
And lastly, you could have a technical error where you are using incorrect command in the segment or
your Z program or Z segment is not working.
This is pretty common, too, because it's actually quite difficult to understand.
What does an IDOC?
Well, what does a feel in an idol do when you're processing it?