Release code là gì

Telex release là một hình hình thức giao hàng cho người nhận hàng consignee mà shiper không cần gởi bill gốc cho consignee, giúp cho việc nhận hàng được nhanh hơn thuận tiện hơn trong trường hợp người nhận hàng không yêu cầu lấy bill gốc.

Trong những bài viết trước mình đã giải thích Master bill và house bill. Mình xin nhắc lại 1 chút lưu ý, cả 2 hình thức lấy vận đơn này đều có bill gốc và surrender bill. Khi lấy surrender bill thì bắt buộc shiper phải trả lại bill gốc cho hãng tàu ( hoặc trả lại bill gốc cho forwarding) để hãng tàu ( hoặc forwarding) làm surrender bill. Như vậy việc làm surrender bill như thế nào ? Cách làm surrender bill ra sao ? Đây là câu trả lời cho telex release là gì…

Để làm được surrender bill đầu tiên shiper phải trả lại bill gốc ( trả lại đúng 3 bản bill gốc ) và yêu cầu làm telex release giải phóng hàng và lấy surrender bill. Như vậy Telex release là một phương thức để làm surrender bill. Phương thức này được thực hiện bằng cách hãng tàu ( hoặc forwarding ) nơi gởi hàng ” gọi điện ” cho đại lý của mình ở đầu nhận hàng giải phóng hàng. Shiper lúc này sẽ  nhận được một bill gọi lại surrender bill có nội dung gần giống như bill gốc nhưng trên bill này để chữ surrender.

Thông thường các hãng tàu tính đây là phụ phí vận tải biển khoảng 500000 VND. Để tiết kiệm cho người gởi hàng một số hãng tàu cho làm seaway miễn phí, hoặc thu phí nhưng với phí thấp hơn telex release. Trong bài viết tới mình sẽ viết về seaway bill.

Ưu điểm làm telex release : Việc nhận hàng sẽ thực hiện nhanh hơn, vẫn có vận đơn surrender để bổ sung vào thủ tục hợp đồng nếu có. Đặc biệt trong trường hợp đầu đại lý đã thông báo hàng đến cho consignee hoặc notify party thì người gởi hàng  (shiper) vẫn có quyền hold ( giữ ) hàng lại.

Nhược điểm : Tốn phí

Kết luận : Telex release được hiểu như là một phương thức mà hãng tàu ( forwarder ) gọi điện cho đại lý của mình  giải phóng hàng thông qua cuộc điện, đồng thời cấp surrender bill cho shiper gởi hàng.

Telex release có thể được coi là lệnh giao hàng được sử dụng trong hoạt động giao nhận hàng hóa xuất nhập khẩu. Vậy tại sao thuật ngữ này lại xuất hiện, Telex release là gì? Phí Telex release như thế nào? Chúng ta hãy cùng tìm hiểu chi tiết qua bài viết dưới đây.

>>>>> Xem thêm: Cách xử lý khi hàng air bị sai trọng lượng và sai số ngày chuyến bay

Trước khi tìm hiểu về Telex release, chúng ta sẽ phân tích về Surrender bill và mối liên hệ giữa hai chứng từ này.

1.Surrender bill là gì?

Trong Giao nhận hàng hóa xuất nhập khẩu, thông thường quy trình giao nhận đường biển sẽ diễn ra như sau:

Bên xuất khẩu giao hàng cho hãng tàu => Hãng tàu phát hành Master bill đưa cho người Xuất khẩu => Người Xuất khẩu sẽ gửi B/L gốc này (cùng với bộ chứng từ của lô hàng) theo đường hàng không (đi nhanh) => Người NK sẽ cầm bill gốc lên Văn phòng của hãng tàu đó ở nước nhập khẩu để lấy Lệnh Giao hàng D/O rồi sau đó ra cảng làm thủ tục hải quan nhập khẩu và lấy hàng… học xuất nhập khẩu

Đó là quy trình thông thường của 1 lô hàng xuất nhập khẩu nhưng không phải lúc nào việc vận chuyển bộ chứng từ và Bill gốc cũng diễn ra thuận lợi. Có những lô hàng đi nhanh nên khi hàng cập cảng rồi nhưng chứng từ chưa đến. Điều này dẫn đến việc phải mất thêm phí lưu kho, lưu bãi, chậm tiến độ giao hàng,…gây ra nhiều rắc rối cho chủ hàng. học nghiệp vụ xuất nhập khẩu ở đâu học kế toán thực hành ở đâu tốt nhất

Vì vậy, để đảm bảo thủ tục đơn giản hơn và tiện lợi hơn, người ta dùng đến Surrender bill.

Hiểu một cách đơn giản, B/L có thể giúp người Nhập khẩu lấy hàng/hãng tàu đồng ý thả hàng cho người Nhập khẩu mà không cần đợi B/L gốc. khóa học xuất nhập khẩu online

🔴 Xem Thêm:  Nội dung chi tiết Incoterms 2020

2.Telex release là gì?

Telex Release chỉ đơn giản là một thông báo được gửi bởi hãng tàu hoặc đại lý tại cảng bốc hàng (port of loading) đến văn phòng hoặc đại lý của họ tại cảng dỡ hàng (port of discharge) thông báo rằng Người gửi hàng (Shipper) hoặc người xuất khẩu đã nộp lại một hoặc tất cả các vận đơn ban đầu đã được cấp cho họ ..

Dựa trên thông báo phát hành Telex này (có thể bằng điện Telex hoặc qua email hoặc fax), đại lý tại cảng dỡ hàng (POD) có thể giải phóng hàng hoá cho người nhận hàng (Consignee) được nêu trên vận đơn mà không cần xuất trình bất kỳ vận đơn gốc nào. hành chính nhân sự

Shipper có thể in bản BL photo ra, BL này sẽ có thêm chữ “Surrendered” hoặc không cần in BL ra, mà chỉ cần báo cho người nhận hàng mã xác nhận (confirmation code) cho việc lô hàng đã được giải phóng(released)

Việc phát hành Telex chỉ được yêu cầu trong trường hợp Vận đơn là vận đơn đích danh mà không bao giờ có trên một vận đơn chuyển nhượng (vận đơn theo lệnh – To order BL). nên học kế toán thực hành ở đâu

Như vậy Telex Release được áp dụng cho lô hàng có một bộ vận đơn gốc (bản cứng) được in ra, nhả hàng và thu lại tại cảng đóng hàng. Do đó, nhiều forwarder gọi đây là vận đơn nộp tại cảng bốc hàng.

Do đó, thông thường khi sử dụng bill surender thì người  xuất khẩu cần phải mất  thêm chi phí telex release  thường thì từ $25-$30/ Bill học xuất nhập khẩu ở đâu tốt nhất

Mong rằng bài viết về Telex release trong xuất nhập khẩu hữu ích với các bạn đang làm nghề xuất nhập khẩu, logistics!

Nguồn bài viết: https://xuatnhapkhauleanh.edu.vn

Để tìm hiểu nhiều hơn về nghiệp vụ xuất nhập khẩu, bạn có thể đọc thêm các bài viết về học xuất nhập khẩu ở đâu tại website: xuatnhapkhauthucte.com.

Related

Dự án sẽ có đồng thời từ ba đến sáu phiên bản khác nhau của mỗi chương trình, mang tên Experimental, Unstable, Testing, Stable, Oldstable, and even Oldoldstable. Mỗi phiên bản tương ứng với một giai đoạn phát triển khác nhau. Để dễ hiểu hơn, chúng ta cần xem xét vòng đời của một phần mềm, từ lúc bắt đầu được packaging cho đến lúc được thêm vào một phiên bản Debian ổn định.

1.6.1. Tổng quan về bản Experimental

Đầu tiên ta cần xem xét đến trường hợp bản phân phối Experimental: đó là một tập các package Debian tương ứng với phần mềm hiện đang được phát triển, và không nhất thiết phải hoàn thiện, điều đó giải thích cho tên gọi của nó. Không phải package nào cũng qua được bước này; nhiều developer thêm các package vào đây nhận feedback từ những người dùng kinh nghiệm (hoặc can đảm) hơn.

Trái lại, bản phân phối này thường xuyên chứa những thay đổi quan trọng đối với base package (package gốc), sẽ được tích hợp vào bản Unstable cùng với các lỗi nghiêm trọng có thể gây ra hậu quả khôn lường. Do đó, nó là một bản phân phối hoàn toàn cô lập, các package của nó không bao giờ được ghép vào phiên bản khác (ngoại trừ khi maintainer của ftpmaster trực tiếp can thiệp vào). Nó cũng không khép kín: chỉ một tập con các package hiện tại xuất hiện trong bản Experimental, và nó thường không bao gồm hệ thống gốc (base system). Do đó, bản phân phối này chủ yếu dùng để kết hợp với các bản phân phối khép kín khác, chẳng hạn như Unstable.

1.6.2. Tổng quan về bản Unstable

Let us turn back to the case of a typical package. The maintainer creates an initial package, which they compile for the Unstable version and place on the ftp-master.debian.org server. This first event involves inspection and validation from the ftpmasters. The software is then available in the Unstable distribution, which is the “cutting edge” distribution chosen by users who are more concerned with having up-to-date packages than worried about serious bugs. They discover the program and then test it.

Nếu gặp lỗi, họ sẽ báo cáo cho maintainer của package. Sau đó maintainer sẽ chuẩn bị các bản tốt hơn, và upload lên server.

Every newly updated package is updated on all Debian mirrors around the world within six hours. The users then test the corrections and search for other problems resulting from the modifications. Several updates may then occur rapidly. During these times, autobuilder robots come into action. Most frequently, the maintainer has only one traditional PC and has compiled their package on the amd64 (or i386) architecture (or they opted for a source-only upload, thus without any precompiled package); the autobuilders take over and automatically compile versions for all the other architectures. Some compilations may fail; the maintainer will then receive a bug report indicating the problem, which is then to be corrected in the next versions. When the bug is discovered by a specialist for the architecture in question, the bug report may come with a patch ready to use.

Hình 1.2. Biên dịch một package bằng các autobuilder

1.6.3. Tích hợp vào bản Testing

Một lúc sau, package sẽ hoàn thiện; được biên dịch trên tất cả các kiến trúc máy tính, nó sẽ không được trải qua các thay đổi gần nhất. Nó trở thành ứng viên cho việc thêm vào bản phân phối Testing — một nhóm các package Unstable được lựa chọn dựa trên một số tiêu chí về mặt định lượng. Hàng ngày một chương trình sẽ tự động chọn ra các package để thêm vào bản Testing, dựa trên các thành phần đảm bảo một level nhất định về chất lượng:

1. ít các lỗi nghiêm trọng, hoặc, ít nhất là ít lỗi hơn phiên bản hiện tại nằm trong bản Testing;

2. at least 5 days spent in Unstable, which is usually sufficient time to find and report any serious problems (successfully passing the package's own test suite, if it has one, reduces that time);

3. biên dịch thành công trên tất cả kiến trúc máy tính được chính thức hỗ trợ;

4. dependencies that can be satisfied in Testing, or that can at least be moved there together with the package in question;

5. automatic quality tests of the package (autopkgtest) — if defined — don't show any regression.

Hệ thống này rõ ràng không thể không phạm sai lầm; các lỗi nghiêm trọng thường xuyên được tìm thấy trong các package được thêm vào bản Testing. Hiện tại, nhìn chung là có hiệu quả, và bản Testing ít vấn đề hơn nhiều so với bản Unstable, là sự thỏa hiệp giữa tính ổn định và tính mới lạ.

1.6.4. Đi từ Testing đến Stable

Let us suppose that our package is now included in Testing. As long as it has room for improvement, its maintainer must continue to improve it and restart the process from Unstable (but its later inclusion in Testing is generally faster: unless it changed significantly, all of its dependencies are already available). When it reaches perfection, the maintainer has completed their work. The next step is the inclusion in the Stable distribution, which is, in reality, a simple copy of Testing at a moment chosen by the Release Manager. Ideally, this decision is made when the installer is ready, and when no program in Testing has any known critical bugs.

Bởi vì thời điểm này không bao giờ thực sự đến, trên thực tế, Debian buộc phải thỏa hiệp: xóa đi các package mà người maintainer đã không kịp sửa lỗi đúng thời hạn, hoặc đồng ý phát hành một bản phân phối với một số lỗi trong hàng ngàn chương trình. Release Manager sẽ thông báo trước một chu kì freeze, trong thời gian đó mỗi cập nhật đến bản Testing phải được phê duyệt. Mục tiêu ở đây là ngăn bất kì phiên bản mới nào (và lỗi mới của nó), và chỉ phê duyệt các lỗi đã được sửa.

Hình 1.3. Con đường của một package qua nhiều phiên bản Debian khác nhau

After the release of a new stable version, the Stable Release Managers manage all further development (called “revisions”, ex: 7.1, 7.2, 7.3 for version 7). These updates systematically include all security patches. They will also include the most important corrections (the maintainer of a package must prove the gravity of the problem that they wish to correct in order to have their updates included).

At the end of the journey, our hypothetical package is now included in the stable distribution. This journey, not without its difficulties, explains the significant delays separating the Debian Stable releases. This contributes, over all, to its reputation for quality. Furthermore, the majority of users are satisfied using one of the three distributions simultaneously available. The system administrators, concerned above all about the stability of their servers, don't need the latest and greatest version of GNOME; they can choose Debian Stable, and they will be satisfied. End users, more interested in the latest versions of GNOME or KDE Plasma than in rock-solid stability, will find Debian Testing to be a good compromise between a lack of serious problems and relatively up-to-date software. Finally, developers and more experienced users may blaze the trail, testing all the latest developments in Debian Unstable right out of the gate, at the risk of suffering the headaches and bugs inherent in any new version of a program. To each their own Debian!

Hình 1.4. Chu kỳ phát triển theo thời gian của một chương trình được package bởi Debian

1.6.5. Tổng quan về bản Oldstable và bản Oldoldstable

Mỗi bản phát hành Stable có vòng đời khoảng 5 năm và việc release diễn ra mỗi 2 years, có thể có đến 3 bản phát hành được hỗ trợ tại mỗi thời điểm. Khi một bản phát hành ổn định mới được tung ra, các bản phát hành trước trở thành Oldstable và bản trước nữa trở thành Oldoldstable.

Bản phát hành Hỗ trợ dài hạn (LTS) này của Debian là một sáng kiến gần đây: cộng tác viên và các công ty tham gia vào lực lượng tạo ra team Debian LTS. Các bản phát hành cũ hơn không còn được hỗ trợ bởi đội ngũ bảo mật của Debian nữa sẽ không thuộc trách nhiệm của team mới này.

The Debian security team handles security support in the current Stable release and also in the Oldstable release (but only for as long as is needed to ensure one year of overlap with the current stable release). This amounts roughly to three years of support for each release. The Debian LTS team handles the last (two) years of security support so that each releases benefits from at least 5 years of support and so that users can upgrade from version N to N+2, for example from Debian 8 Jessie to Debian 10 Buster.

→ https://wiki.debian.org/LTS