Αρχική Διαβουλεύσεις Προδιαγραφών - ΓΓΠΣΤεχνική διαβούλευση σχετικά με την ηλεκτρονική υποβολή αποδείξεωνΣχόλιο του χρήστη Apostolos Lerios | 15 Μαΐου 2010, 00:51
  • Σχόλιο του χρήστη 'Apostolos Lerios' | 15 Μαΐου 2010, 00:51

    Protaseis (sta agglika giati GrEnglish se texnika themata mou einai diskolo na grapso sosta...): * It would be helpful if the protocol you put together also covers the transmission of credit and debit card transactions, and/or electronic checks. Specifically, include the necessary fields (XML elements) that would allow data you collect from consumers, businesses and banks (or other credit card providers) to be cross-correlated. Otherwise, it'll be easy to end up with duplicates. But, more importantly, if credit card transactions are automatically recorded, then this eases the recording burden on both consumers and businesses, and (being automated) avoid transcription errors. * Consider extensive use of checksums in any IDs. For example, a receipt ID should not be just unique, but it should be self-checking. For example: if the ID of a receipt is a 10-digit number, then 9 digits are arbitary but the 10th is ALWAYS a deterministic function of the first 9. This means that, if the first nine are 123456789 and the checksum calculator is a (simplistic) function which takes the sum of them and takes modulo 10 of that sum, then the 10th digit would be 5 (1+2+3+...+9=45, 45 mod 10 is 5). Why do that? Because then you will know immediately if manual entry of a receipt by the consumer is incorrect/fraudulent: if they use an imaginary ID, and assuming most consumers won't know the checksum function, they will use a random 10th digit, the checksum will fail, and you will know the ID is imaginary --- without needing cross-checks. * Checksums or other hashes may also help reduce some problems with forgery. For example, receipts need not contain the checksum part of private information (e.g. Tax ID); the receipt could have the non-checksum part only, preventing forgery but also allowing the consumer to know whether that receipt is theirs (the consumer him/herself knows the missing digit). Or, alternately, the receipt may have the ID scrambled. For (a simplistic) example, a receipt can show an extra field named "Check Code" in which the receipt-issuing machine enters the sum of the Tax ID plus the amount of the receipt (in practice: some reversible formula that is hard to compute by hand). Using the Check Code and amount, your service can compute the Tax ID. * In broad terms, keep in mind that checksums are widely used in the US for tax IDs, transaction IDs, etc. The reason they should be factored into your overall design at this stage is because they may need to be included in your XSD forms as separate fields (or to alter the length of existing fields). * Consider adding optional fields that describe the items being sold. Why? When I check my credit card statement online in the US and I see a transaction I don't recognize, it helps me to double-check it if I can click on the transaction and see more detail, such as what items did I buy, was tip included, etc. The business gives that information to the credit card company, and, similarly, optional fields added to your XSD schema can be used for the business to (optionally) provide additional information on the transaction. I would expect that the consumer should have a means to check the State's records of receipts and confirm their accuracy (as well as submit additional receipts). This check will be easier if optional fields enable the consumer to identify transaction records. * As a general guiding principle in your design, I encourage you to focus as much as possible on Smart Phones (cell phones with the ability to execute arbitrary software). Why? (1) They are widely used... even tax cab drivers will have them in the next year or two, if not already. (2) They can have internet access (directly or via home connectivity to a PC) which addresses connectivity issues to deliver the receipt data. (3) Purchasing a phone provides the benefit of other (personal) use, in addition to business use. Hence a business owner is less likely to complain about the evil State forcing them to buy new hardware --- just download a free iPhone (or Android) application, provided by the State, on your existing phone, and you'll have the equipment to issue e-receipts... if that application also TEXTs the receipt to the consumer on the spot, there'll also be no need to print paper, which further safeguards personal information. * The previous bullet point relies on the key observation that whatever design you come up with will take time to be instituted. Thus, it is important to come up with a design that is (1) introduced in stages and (2) focuses not on present technologies, but future ones. For example, at a first stage, focus on just grocery stores and maybe just a couple of pilot programs with the major stores (e.g. carrefour, spar). See how the system works there, and get consumers to get used to the idea of paperless e-receipts via an SMS text. Then expand the system to tech-savvy merchants (Plaisio, Germanos) with Smart Phone applications. And then, once debugged and once the consumers are familar with it, force it upon all merchants (cab drivers, plumbers, etc.). * Allow for consumers to enter receipts for which the do not have the merchant's tax ID. Why? If Bob the plumber comes to my house and I ask for a receipt, and he doesn't want to give me one (because he wants to evade taxes), I would still want to submit a "receipt" (which won't even require stating whether I paid VAT or not). It would not be a normal receipt, but I would want to enter the name of the plumber and his/her phone number. How such data is handled is a different story: whether or not it can be tax-deductible, whether or not it can be used to track down tax evasion, etc. As a first step, the tax filer may be allowed to claim up to 100 euro in such "receipts", with the primary intent of having tax filers report tax evasion (the cost to the State is the tax due on that 100, which is a very small price to pay for identifying tax evasion); the State then calls those individuals who did not issue proper receipts to request a clarification (a robo-call based on the phone number) --- no penalty, no legal proceedings, no overhead, just an automated call and a request to submit an explanation. Start doing that and you'll see how quickly those tax evaders will start feeling the heat (i.e. they'll come to the realization they are no longer invisible to the State and are more likely to reform themselves out of fear of additional scrutiny). * The key point of the above bullet is not the specific mechanism of detecting tax evasion. It is that your schema may need to be more flexible: not just focus on the data strictly required by the current tax law, but also allow for a parallel, looser reporting framework, compatible with the rigid one. Obviously, you should consult with the tax authorities of the State (eforia) about what kind of looser framework would be appropriate and consistent with tax evasion tactics. Best wishes for an ambitious plan!