Blind Image-Sales invoicing (2)

Then I went on to ridicule.
The previous article talked about capital flows. This article involves information flows. During software design, information flows may have many ideas. Each person may have different understandings of information flows, so there is no unified standard. The information flow, cash flow, and logistics I divided here are just to analyze the sales invoicing process, artificially according to my own understanding. Code Separated to facilitate sorting.
The information flow I mentioned here refers to the tables and codes used to record customer-related information during the sales invoicing process. The enterprise's tossing process is ultimately to make money, so the final goal is always to settle in the money, that is, the financial creden。 mentioned above. In the process of converting materials into money, you need to record a series of information. Otherwise, what will the customer say to you? Of course, this is only one aspect. There are still many situations. For example, if a sales order may have to be shipped and invoiced multiple times, the information of each invoicing must be recorded.
How does ax record this information?
Customer invoicing Information
The custinvoicejour and custinvoicetrans tables are used to record the information of each sales invoice. The code used by ax to write the two tables is also very simple and clear, that is, when processing each sales order row using the for loop, write custinvoicetrans using the writejournalline method, after processing a whole sales order, write custinvoicejour using the writejournal method. This code is used in the updatenow method of salesformletter_invoice. For the value written by each field, refer to the corresponding method.
Payment plan
Another problem in the information flow is the payment plan. The payment plan is described in detail in chapter 9th of the financial tutorial I, so the computing logic of the payment plan will not be repeated here. Ax uses the custpaymsched and custpaymschedline tables to store relevant information. Of course, there are also two tables to store the payment plan rules, namely, paymsched and paymschedline. Because the payment plan is common for receivables and payables, the corresponding payment plans for the procurement also have the corresponding tables vendpaymsched and vendpaymschedline. The processing logic of these two sets of tables is mostly the same, so ax uses map, custvendpaymentsched, and custvendpaymentschedline for processing. From the processing here, we can understand the actual function of map, just to put the public code in one place, avoid writing one set for each purchase and sales. The above is about the data layer. In terms of logic processing, of course, there are several classes to deal with the computing logic. ax gets paymschedcalc and its sub-classes, as well as custvendpaymsched and its sub-classes.
For the payment plan, I am not sure whether there are many applications in China. For projects, I usually adopt the installment payment method. For example, when an ERP project is used, it is generally divided into several stages for payment, as agreed in the contract, it is obviously not suitable for query and tracking in non-structured documents such as Word. These terms are translated into the corresponding payment plan in ax and placed in the relational database table, obviously, it will facilitate the query and collection of funds. This may be the practical significance of the payment plan.
Here, we will only briefly describe where ax handles the payment plan when issuing the sales invoice. We will not discuss other logic aspects, and I feel that it is not much used, all those who owe money this year are bosses, and the plan cannot keep up with the changes.
Ax is in the updatenow method of salesformletter_invoice by calling this. createpaymentsched (); To create a payment plan. Of course, in this method, ax will call the class and table about the payment plan described above for corresponding processing, the specific processing logic should first look at Chapter 9th of finance I and then flip the Code to make it OK.
Customer transaction records
After all, wanjuan becomes a river, and ax processes all the businesses and finally falls into a table, such as inventory to inventtrans, finance to ledgertrans, and customers to custtrans. This processing method is simple and intuitive. Just like the inventory module, it is impossible for me to take care of the tables, salesline, purchline, inventjournalline, and so on corresponding to all businesses when I close my inventory, if you want to add several new modules and open several new tables in the future, the logic of my inventory closing account should be changed. That is the case, so do ledgertrans and custtrans. The customer's transactions are all placed in custtrans, which will be easy to handle in the future. So the final content to be introduced is about custtrans. Previous Article We have introduced that ax encapsulates one in the receivables and payables module ledgervoucher, Which is changed to custvendvoucher and its subclass. On the one hand, it simplifies the operations on ledgervoucher, more importantly, the receivables and payables module needs to handle more things. One of the most important tasks is to generate customer transaction records. Let's look at the code to explain what ax has done in this part.
Salesformletter_invoice-"updatenow-> postjournal
The other methods in this method are very concise, so we can easily see what it has done. What we need to know is what the createcusttrans method has done, as its name suggests, this method is used to create customer transaction records. The main content is in the post method of custvendvoucher:
1. Add a transaction to the ledgervoucher object
The record corresponding to the customer's payable amount should be added to this object here, or else it will be renewed.
2. Create a custtrans record
Create a custtrans record. Most of the information is from custinvoicejour.
3. Create a custtransopen record
This table is required because the account receivable and the collection and the prepayment need to be written off (settle), that is, to figure out which payment has been made. The advantage of creating this table is that it may be written off many times, and a record may be split into several records. If it is placed in custtrans, custtrans will not be fully visible at last. In order to keep the original appearance of custtrans as much as possible, unclosed transactions are all placed in custtransopen, and the table is tossed. For a payment plan, multiple records are inserted into custtransopen based on the payment plan.
4. Process collection and write-off
If the payment term is cash on delivery (C. o. d) If cash settlement is adopted and a cash subject is specified, ax will generate a receipt credential directly during invoicing and write off the receipt and receipt. The receipt credential is very simple, that is, the loan: The account receivable borrow: the cash account set at the payment term. As for the write-off, it is another story. The content involved is also relatively complex, such as exchange profit and loss, such as different transfer templates, closing templates, and so on, later, we will introduce the receipt, exchange profit and loss, and the logic for writing off the exchange gains and losses.
Okay, there are so many information flows. Logistics introduced the inventory code. In fact, the sales invoicing process is just calling the logic. There is nothing new to it, I will not go into details.
Sales invoicing is here.