e-Archive

Operation

Contrary to the misconception in its name, e-archive should be thought of as a new, more widely used version of the e-invoice system. The copies in the traditional invoice system disappear, and the original can still be printed or sent by e-mail. The name 'archive' comes from the electronic storage of invoice copies.

e-Invoice obligors can only use the e-invoice system among themselves and cannot use the e-archive system.

Difference from e-Invoice System

The most important difference is that it is one-way. Since e-archive obligors must also be e-invoice obligors, and e-invoice obligors have an e-invoice obligation among themselves, no firm can arrange an e-archive for a firm subject to e-archive.

e-Archive affects a much wider usage area as it also covers consumers. E-archive is arranged for all companies or persons who are not e-invoice obligors. Thus, a firm that switches to e-archive has no business with traditional printed invoices.

Another important difference in the operation of e-archive is that the data is sent only to the special integrator and not to the Revenue Administration (GİB) instantly, but reported collectively later.

Reporting to GİB

e-Archive invoices must be reported to GİB by the 15th of the following month at the latest through the special integrator system. In this respect, it is similar to VAT declaration. It is sufficient for invoices to be sent by the ERP to the special integrator at a certain period. The reconciliation module we have prepared between the special integrator and ERP is very important due to the high number of invoice transactions.

The Framework of e-Archive System

The e-archive system is limited to the creation, storage, and reporting of invoices, and the bindingness of the Tax Procedural Law (VUK) applies in terms of content, consistency, and historical rules. The studies to be carried out with the special integrator are purely technical studies between two companies, and there is no bindingness in the e-archive process.

Although it may seem unusual at first, as e-mail delivery becomes widespread, the operational-time costs of printing invoices and delivering them by cargo will disappear. To complete this, let us mention that the e-waybill project is also being prepared.

Training is Necessary :)

Even for companies subject to this issue, there is a problem of widespread insufficient information, and it seems that it will take time for companies and persons that do not have to follow the issue but receive invoices to adapt. Especially at the cash register, a significant amount of time will be spent, and some tensions will be experienced. It is essential to inform all company employees, especially cashiers, seriously and prepare them for typical questions.

Invoice Sources

There are different data and design features for three different sources.

• ERP
• e-Commerce
• POS Cash Register

Although there are different applications, for retail, invoices coming from these three sources are generally sent by ERP to the special integrator. In this sense, the entire process is planned and managed on the ERP side. Critical issues such as design differences, management of serial numbers, and search-display-printing possibilities are carried out on the DerinSİS side.

ERP

Standard invoice information must be reflected in the e-archive invoice. In cases where the e-archive logo output is not required to be printed instantly (such as cash&carry, POS cash register), it is sufficient to create the invoice record, and the sending can be done later by the accounting department in the e-archive management module. E-commerce source invoices are processed similarly, but different information needs to be stored.

An option is offered for the delivery of the invoice as output or e-mail, and a predefined selection is also offered in the customer card. Thus, a faster workflow can be achieved in customers who will always work with e-mail.

e-Commerce

Mandatory fields specific to e-commerce, although necessary to be stored due to operational requirements, bring significant changes in terms of integration between e-commerce systems and ERP. In fact, the current obligation arises entirely from e-commerce. E-mail is mandatory, and invoices will be sent by mail, and there is no need for output at all. These information will be transferred to the invoice and delivered to the special integrator:

• · The URL of the website where the sale was madei
• · Kargo company information
• · Mustomer e-mail information
• · Payment type

Therefore, e-commerce APIs and ERP integrations need to be reviewed seriously. Due to the weak service procurement relationship experienced in the e-commerce market, this issue seems to challenge taxpayers even more.

POS Cash Register

As in the case of e-invoice, the invoice process in POS cash registers is also excluded from e-archive, and solutions are tried to be brought later. First, let's emphasize that the concept of return does not exist, which is also valid for invoices produced from ERP. The limited hardware structure and the need for sales speed in cash registers caused some rules to change. The obligation to provide the exact same output of the electronic invoice has been relaxed due to dot matrix printers. Now, a classic invoice output with an e-archive logo on A4 (or paper suitable for the cash register) is considered sufficient for e-archive. The condition for this is that the design in electronic invoice display is adapted to the cash output. The printing of a sequentially produced number is also a critical obligation.

Some cash registers have configured to receive this number online with a special integrator during sales and print it. It is sufficient for the series to be used correctly and sequentially without repetition, and there is no need for such an online connection. Numbering can be done on the special integrator side, and we provide significant flexibility with serial management, especially in DerinSİS.

'Information Slip'

In addition, a separate 'information slip' must be given from the POS cash register receipt printer, and this output actually has a more critical function than the e-archive output. While the e-archive contains legal information, the information slip repeats all information such as product-price, contains the invoice number, and includes various texts and information for CRM-campaign-information purposes. It is the only document the customer has in case the customer requests an e-mail or in cases where the e-archive output is not given/not provided.

For example, if the online number retrieval scenario cannot be established instantly, only the information slip will be printed, and the ERP will still number the invoice and send it to the special integrator as an e-archive, and output and delivery processes will continue according to the workflow in the project.

In the constantly changing and evolving process, the latest information is that only the information slip will be sufficient for POS cash registers. This situation also creates another revolution for new ÖKC's, and there is no need for invoice printers. Everything can be sent to the integrator, numbered in ERP.

Management Module

All sending transactions, cancellation and deletion transactions, serial management, inquiry-search-display transactions are done through the e-archive management module. According to their sources, three different tabs list unsent invoices, allow selection, and send to the special integrator according to design features.

The generated electronic invoice can be stored by attaching it as a PDF to the relevant invoice and can be displayed and printed when needed. Thanks to serial management, the sequential sending of invoices selected according to different dates can be provided independently of those sent.

Invoice Series

While DerinSİS offers series based on standard invoice types, a different series can be used specifically for e-commerce, and another completely separate series can be used for cash systems that have not been numbered in POS cash registers.

Cancellation and Deletion

Invoices sent to the integrator but not reported to GİB can be deleted. An e-archive invoice reported to GİB can only be canceled. These transactions can be performed in the management module, depending on authorization. In this sense, it would be appropriate to completely remove the cancellation and deletion authorizations in the relevant invoice modules operationally. It is recommended to proceed with the VUK as the basis for historical limits.

Reconciliation

In the reconciliation process, the preliminary report output taken from the integrator can be reloaded into DerinSİS, providing a critical control against inconsistencies that may occur due to different reasons, even with a high number of invoices.

It is also an important service step to list e-mail preferential invoices that could not be delivered at the point where the e-mail service is received. The correct receipt of e-mails from customers will also reduce subsequent problems.

POS Sales

Sales Transfers

In sales transfers, invoices subject to e-archive must be filtered and stored with all necessary information to be sent to the integrator. To prevent the division of POS sales turnover, it can be transferred as Z reports, as it has been until now, or as separate invoices based on Ba-Bs reports and open account working customers. Since some cash registers have not yet offered e-archive solutions, it is necessary to be prepared for the cutting of waybills in cash registers, their transfer to ERP as waybills, and their conversion into invoices and sent as e-archive.

Store Cash Register

In the Store Cash Register module, where cashier deliveries, local expenses, and exits to central accounts are managed, e-archive invoices must be listed, detailed, and printed if necessary, according to the transfer scenarios above.

e-Commerce Integration

These information will be transferred to the invoice and delivered to the special integrator:

• · The URL of the website where the sale was made

As the sales on multiple domains become widespread, it is necessary to keep track of the site name on the ERP side for reporting purposes. We expect the site URLs where sales are made to be kept in a special definition table and matched with this information in the API.

• · Kargo company information

It is necessary to store not only a simple short name but also the firm name, tax number, etc. Therefore, it should be stored in a more structured way. In DerinSİS, the ID of the cargo company is stored with the order.

• · Mustomer e-mail information

Depending on the customer's request, output is not mandatory for e-commerce. Therefore, e-mail address acquisition is mandatory, and sending by mail is the fulfillment of the obligation.

• · Payment type

Although payment amounts are not expected in detail, payment names made on the invoice must be stored and transmitted.

Therefore, e-commerce APIs and ERP integrations need to be reviewed seriously. Due to the weak service procurement relationship experienced in the e-commerce market, this issue seems to challenge taxpayers even more.