प्रणाली योजनाएँ

तैयार योजनाएँ उन दस्तावेज़ों के लिए हैं जो सबसे अधिक उपयोग किए जाते हैं। इन्हें संशोधित नहीं किया जा सकता, लेकिन आप इन्हें अपना खुद का बनाने के लिए आधार के रूप में उपयोग कर सकते हैं (प्रतिलिपि बनाएं).

चालान

सबसे समृद्ध योजना और साथ ही आधारभूत। इसमें हेडर और दोनों पक्षों के अलावा आइटम, VAT का सारांश दरों के अनुसार, भुगतान विवरण और दस्तावेज़ का प्रकार शामिल है।

प्रकार को दस्तावेज़ से पढ़ा जाता है: चालान, क्रेडिट नोट, डेबिट नोट, अग्रिम चालान, प्राप्त भुगतान के लिए कर दस्तावेज़, सरल कर दस्तावेज़। प्रकार के अनुसार दस्तावेज़ को एंट्री किया जाएगा - क्रेडिट नोट ISDOC, Pohoda और Money S3 में सुधारात्मक दस्तावेज़ के रूप में, UBL में CreditNote के रूप में जाएगा। स्थिर रूप में शैनन में या अपलोड के समय भी प्रकार निश्चित किया जा सकता है; जब मॉडल कुछ और पढ़ता है, तो यह एक खोज के रूप में रिपोर्ट करेगा।

रसीद

दुकान, रेस्तरां या सेवा से पारगमन। इसमें ग्राहक नहीं होता - रसीद में सामान्यतः नहीं होता - और यह मानती है कि भुगतान तुरंत हुआ है। यह VAT की दरों का सारांश, छूट और भुगतान के तरीके को संभालती है। यह Pohoda और Money S3 में नकद या बैंक दस्तावेज़ के रूप में जाएगी यह इस पर निर्भर करता है कि भुगतान नकद में किया गया था या कार्ड से; ISDOC में यह एक सरल कर दस्तावेज़ के रूप में जाएगा।

ईंधन की रसीद

केवल पेट्रोल पंप पर ईंधन भरने के लिए। रसीद के फ़ील्ड में लीटर में मात्रा, कर सहित और बिना कीमत, ईंधन का प्रकार, स्टेशन और प्रत्येक आइटम के लिए यह संकेत कि क्या यह ईंधन है, जोड़ा जाता है। रजिस्ट्रेशन नंबर और टाचोमीटर की स्थिति केवल तब पढ़ी जाती है जब वे दस्तावेज़ पर होते हैं; सामान्य रसीद में ये नहीं होते - वाहन शैनन से पहचाना जाता है।

इन फ़ील्ड्स के ऊपर ईंधन भरने का सारांश "सारांश" में होता है।

यहाँ क्या नहीं है

डिलिवरी नोट्स, ऑर्डर या बैंक स्टेटमेंट प्रणाली योजना में नहीं होते। डिलिवरी नोट अपने स्वयं के योजनाओं के प्रारूपों के बीच होता है, इसलिए आप डेटा को JSON या टेबल के रूप में प्राप्त करेंगे, लेकिन यह अकाउंटिंग में नहीं जाएगा। बैंक स्टेटमेंट को प्राप्त करना अनुशंसित नहीं है - बैंक इसे ठीक ठीक ABO, GPC या CAMT में जारी करेगा, जबकि PDF की पहचान एक अनुमान है।