SHIPPING PROCESS

Ngoài việc tạo outbound delivery từ SO thì chúng ta cần phải process nó trước khi
completed.

Khi điền những thông tin về hàng hóa, quantity, ngày giao hàng ở trong SO thì hệ thống
sẽ có những cách để có thể determine ra được shipping point. Từ shipping point ở trên
SO nó sẽ trở thành một đơn vị giao hàng ở outbound delivery.

Khi mà outbound được tạo từ SO thì nó sẽ đi theo material ở item để xem hàng hóa được
đi từ điểm nào (shipping point) và từ đó outbound sẽ được tạo dựa trên những thông tin
đó.

Sau khi tạo outbound thành công thì sẽ chuyển sang phần picking.

Khi tạo outbound thành công thì về mặt lý thuyết là chúng ta đã thực hiện việc báo với
nhà kho rằng chúng ta sẽ chuẩn bị giao hàng cho đơn SO này. Phía kho sau khi nhận
outbound thì họ sẽ biết được chúng ta cần giao bao nhiêu hàng và loại hàng gì trong thời
gian này và sẽ chuyển sang các bước tiếp theo.
Nếu trong SO có hai item với 2 shipping point khác nhau thì có thể sẽ có hai outbound
delivery cho một SO.

Những data đã được determine ở level item (plant, route, shipping point, soldto) sẽ được
copy lên outbound delivery.

Khi mình tạo Outbound thì nó sẽ consider cho mình một yếu tố liên quan đến ngày giao
hàng. Chúng ta cần check ngày giao hàng đã được confirm ở trong schedule lines để có
thể nhập ngày giao hàng vào mục Selection Date ở trong phần SO Data ở Outbound.
(chúng ta có thể nhập trễ hơn nhưng ko được nhập sớm hơn ngày giao hàng đã được
confirm).
ORGANIZATIONAL UNITS FOR DELIVERY PROCESS

Mối quan hệ giữa shipping point và outbound là 1:1. Tức là 1 shipping point chỉ tạo ra
một delivery.

Cao hơn Shipping Point là Plant. Shipping point có thể là điểm lấy hàng cũng có thể là
điểm giao hàng, tùy theo từng yêu cầu của dự án mà chúng ta sẽ chia shipping point cho
phù hợp.

SD: Outbound => Shipping Point/Factory.

MM: 1 Plant A => N Storage Location.

WM: warehouse

Thông thường shipping sẽ được quản lý bởi hai quy trình của SD và MM. Có nghĩa là
hàng sẽ được lấy ở shipping point hoặc storage location. Tuy nhiên nếu có module WM
thì sẽ có cấp bậc cao hơn là warehouse.

CONTROLING DELIVERY DOCUMENT

Item category determination of SO:

· SO type

· Usage
· Higher item cat group => material master

· Item cat group => master

Item cat determination of delivery:

- Delivery with reference (to SO) LF – copy of SO.

- Delivery without reference LO – determine item cat.

· Delivery type

· Usage

· Higher item cat group => material master

· Item cat group => master

VD: SO là thành phẩm A

Delivery = thành phẩm A + packaging material

Tuy nhiên, packaging material xuất hiện sau => không thể reference từ SO

=>

· Thành phẩm A: copy item cat của SO => plant, route, storage location.

· Packaging material: determine item cat => nhập lại thông tin từ đầu.

GOODS RECEIPT AND GOODS ISSUE

 Goods receipt – inbound delivery

Goods issue – outbound delivery

Xuất hàng không nhất thiết phải là từ kho đến khách hàng, chúng ta có thể xuất hàng từ
kho nguyên vật liệu thô (raw material) => phía sản xuất để làm ra thành phẩm => đgl
xuất hàng.

Tương tự, nhập hàng không nhất thiết phải là mua hàng nhập vào kho mà có thể là nhập
hàng thành phẩm.

=> Tất cả những hoạt động xuất – nhập hàng với các mục đích khác nhau đều sẽ được
quản lý bởi movement type.

Movement type:

● 6xx: goods issue (601: GD goods issue for delivery).

● 1xx: goods receipt.

Movement type sẽ gắn với schedule lines để control hoạt động xuất – nhập hàng.

=> khi xuất hàng thì sẽ sinh ra chứng từ kế toán => movement type rất quan trọng cho
phần hạch toán.
Movement type là khi hàng hóa được chuyển từ A đến B như là kho đến khách hàng hoặc
kho này đến kho kia thì sẽ sinh ra movement type => tức là sinh ra sự thay đổi về giá trị.

PICKING PROCESS

Đầu tiên là check status. Có 4 status như sau:

● Blank: not relevant for example service and texts.

● A: not yet processed

● B: partially processed

● C: completed processed

Nếu chọn status là Not relevant => Picked Quantity sẽ bị greyed out.

Nếu chọn status A => picked quantity sẽ được mở.

Nếu chọn status B => thông báo về việc số lượng quantity được pick không đáp ứng điều
kiện đủ.

Nếu chọn status C => fully picked

Nếu chọn quantity vượt mức order => hệ thống sẽ báo lỗi (trừ trường hợp được config
cho việc quantity vượt mức order thì vẫn sẽ được pick hàng như bình thường).

Trong trường hợp có module WM tham gia thì hệ thống sẽ hiểu là hàng sẽ được pick dựa
trên những function của WM.

Trong trường hợp này, SD sẽ không được phép picked quantity => ô Picked Quantity sẽ
bị tô xám như Not Relevant tuy nhiên status vẫn là A.

PICKING THÔNG QUA WM

Sử dụng T-code: LT03 => create transfer order => gửi yêu cầu pick hàng đến WM.
PACKING

Khi vào config của delivery item thì sẽ biết được có cần packing hay không.

Nếu có yêu cầu packing:

● Chọn item => Pack (Shift + F6) => processing of handling units for OD sẽ hiện
lên.

PACKING = HÀNG THÀNH PHẨM + PACKAGING MATERIAL

Packaging material (vật liệu đóng gói): thùng giấy, túi….

Bản thân PM cũng là material => MM khi tạo material master sẽ chọn type
PACKAGING MATERIAL để phân biệt với hàng thành phẩm và vật liệu thô.

Sau khi đóng gói => xuất hiện cục hàng mới sẽ hiển thị ở Handling Units.
POST GOODS ISSUE

Ở Status Overview trong Outbound Delivery bao gồm:

● Overall Status: status của toàn bộ delivery.

● Delivery Item Status: status cho từng item (Status sẽ chỉ được completed khi mà
toàn bộ item trong SO đều đã được PGI thành công).

VD: SO 1998 có 2 item 10 và 20. Trong đó:

● Item 10 đã PGI thành công.

● Item 20 chưa PGI.

=> Status sẽ là B: Partially Processed. Chỉ khi nào tất cả các item đều đã PGI thành
công thì status của toàn Delivery mới chuyền sang completed.
PGI là nút quan trọng nhất ở trong Outbound Delivery. Bởi vì hàng chính thức đã ra khỏi
kho => làm giảm lượng hàng tồn kho.

Hàng tồn kho sẽ có hai giá trị phải ghi nhận về số lượng:

● MM: ghi nhận về số lượng hàng muốn ra khỏi kho.

● FI: ghi nhận giá trị hàng tồn kho đã bị giảm.

Sau khi PGI sẽ sinh ra Goods Issue Document (material document: ghi nhận thay đổi về
quantity và value).
Standard order ngoài là nơi bán hàng thì nó còn là nơi ghi nhận requirement của
customer.

VD: Cần 20p để giao cho cus => delivery requirement sẽ nằm ở schedule lines.

Order quantity:

● Gửi cho phía sản xuất => phía mua hàng.

● Gửi tuần kho => kiểm tra số lượng.

=> được gọi là delivery requirement của SO.

Trong trường hợp chỉ giao được 10p => Outbound Delivery: 10p => PGI 10p thành
công => requirement sẽ giảm còn 10p chưa được giao.

Những date này đến từ Schedule Lines

CANCEL PGI? (T-code: VL09)

Nếu trong quá trình Outbound gặp phải lỗi sau => reverse để làm lại.

Được gọi là Reverse Goods Movement bởi vì dựa vào movement type.
VD:

● Dùng movement type 610 => đẩy hàng ra khỏi kho.

● Dùng movement type xxx => đưa hàng về kho.

Sau khi reverse thành công => chừng từ cũng sẽ được sinh ra trong document flow để xác
nhận số lượng hàng được đưa ngược lại vào kho.