Purchase orders or PO's, serve a number of different functions. 1. They allow inventory items to be entered into the system. 2. They automatically create the backside of inventory which is a payable (money owed for the purchase of inventory). 3. They create and provide a control number (main PO number) that may be passed on to the vendor in order to get the order and/or purchase started. 4. A PO may also be used internally to update inventory counts or combine products to generate output of a different kind (internal build PO's). There are also a number of custom PO types that require special permissions. More information is provide below in the "PO Type" section.

Note: The word "PO" or "Purchase Order" or "Production Order" sometimes confuses people. Don't get too stuck on the actual words themselves (they are editable). The Adilas business platform uses the "PO" as a general inventory tool to track costs and quantities. If your corporation uses orders, price quotes, or requisitions, feel free to change to naming convention from within the corp-wide settings. Once again, the Adilas "PO" is just an inventory tool. The actual assigned name or alias is determined on a per corp basis.

This page will handle both the add and edit modes. The best way to know which mode the page is in is by looking at the main submit button at the bottom. If it says "add po" (add mode) or "edit po" (edit mode). Another way to tell is by looking at the first main field or PO #. If it is the word "new" you are in the add mode, if it is numeric, you are in the edit mode.

The main PO form is divided into two main parts. The top is always required and deals with who, when, and what. The bottom is for receiving the PO (actual when and how much). Depending on your needs, a PO may be created separately (top and bottom) or both forms used together. If you are only starting a PO and won't receive it until later, only fill in the top part of the form and set the PO type to basic request. Leave the bottom part of the form blank until you physically receive the inventory. At that time, you will also need to flip the PO type from basic request to basic live and mark it as received. Once you do that, the PO becomes real in that it will fill its role with inventory counts and will become a payable. The request status of a PO is like an order or PO quote (it doesn't effect inventory and you don't show it as being owed on).

If you physically have the items already in your possession and/or you are holding the physical invoice from the vendor, we recommend that you skip the request type and enter the items as live inventory by selecting the basic live status. If a PO is marked as basic live, it will only be activated once the PO received field is set to yes (items are in my possession).

Here is a list of the fields and what they require:

1. PO # - This is an auto generated number controlled from behind the scenes. This is the main key identifier for the PO.

2. Vendor - This is the vendor name that the items were stocked in under. Most PO's have the same vendor as the line items or parts that go with them. If you need to edit the vendor information on a PO, you may click the link by the vendor name (if applicable). If for some reason, you have entered the wrong vendor, go to the PO line items page and click the link to void the PO and start over. Most PO's are vendor specific and don't allow the vendors to be flipped around. The exception to that is what is called a special PO (more info below). If you do happen to see a vendor/payee id number box, the value of that box is what the system uses as the main payables vendor. If you want to change it, you are allowed to copy and paste a new vendor id number into the box or use the "change" link provided. Once again, this change vendor option is only for special live PO's and special request/order PO's. Most other PO's are vendor specific.

3. PO Created By - This is who first started the PO.

4. PO Type - Choose an option from the list provided (actual values are controlled from the corp-wide settings - dynamic naming). This field may be one of the single most important fields on the PO. This is how the system determines if the PO is a payable, counts as inventory, or is used internally by the system to update quantities and parts. Currently, there are six different PO types.

**Basic Live PO** This type is used to denote inventory from an outside vendor. These PO's are vendor specific and will affect inventory counts and payables as soon as they are marked "received". As a note, all "Basic Requests" (vendor specific orders or quotes) will end up needing a status of "Basic Live" once they are actually received. See corp-wide settings for custom naming.

**Basic Request PO** This PO type is used for ordering, requesting, or getting quotes from vendors. This PO type records all of the main PO info without taking it to the next step (receiving). The PO request may easily be turned into a "Basic Live" PO by switching the PO type. When this happens, the request will hold all of it's original info and becomes received (actual or live). At this point, it will function just as a basic live PO would (inventory counts and payables). This PO type is vendor specific. See corp-wide settings for custom naming.

**Special Live PO** This type is very similar to a basic live PO except it allows for multi and mixed vendors. This PO type allows the main vendor to be set as the payable (who will get paid), and the line items may contain bulk, generic, or non-vendor specific items. All special request PO's (non vendor specific orders or quotes) will need to become a special live PO in order to show up for roll call (once the request is received). These PO types are used by companies that buy the same item from multiple vendors and don't want certain items to be tracked on a per vendor basis. The items become a bulk or general usage item and are usually maintained under a special internal vendor. In order to use the special PO settings, an additional permission is required. See corp-wide settings for custom naming.

**Special Request PO** This is the request side of the special live PO's. Very similar to a basic request except it allows multi and mixed vendors. See description of special live PO's above for more info. Once received, all special request PO's will need to be flipped over to the special live PO status in order to show up and become real or live. See corp-wide settings for custom naming.

**Update** This type is used as a special PO to help update part quantities and values. It requires the parts admin or admin PO permission to make it work. There is a special section under the main parts homepage or PO homepage that has a update inventory count section. These PO's are generated from that section. These update PO's are also how you figure out your shrinkage and loss on your inventory. This PO type is not vendor specific (able to mix and match) and very flexible. If used through the update inventory count section, these PO's will help do special math calculations that deal with updating the inventory counts.

**Internal Build** This type of PO is used internally to take raw goods and combine them to create something new (kitting, packages, groups, mini manufacturing, etc.). For example, say you wanted to make a cake, the raw goods might be flour, sugar, eggs, butter, etc. The internal build PO would subtract the raw goods from inventory (negative quantities) and create a new product called cake or cookies (positive quantities). This PO type has it's own permission and is very powerful. This same PO type is used by the system when using the internal recipe/build process. The recipes are basically a pre-set group of ingredients, parts, items, and/or outputs. These recipes are called "build and hold" recipes. The internal build PO may also be used when taking a certain part, painting it, heating it, cutting it, chopping it, combining it, or somehow changing it into some other part (any type of mini manufacturing). This PO type, internal build, is how you physically control your inventory counts. Similar to the update PO, this PO is not vendor specific and does require a special permission to use this PO type.

**Transitional** A transitional PO is between a request/order and a live PO. Basically, it is like a request PO in that the inventory doesn't fully take affect yet but you are able to add pre-payments to the PO. Eventually it will become a live PO (normal). However, while it is a transitional PO, you need to track it differently. Basically, you pay for some or all of the inventory before you get it. Because it is an asset (pre-paid inventory), you may to show it on the balance sheet before you actually have anything to show for it.

5. PO Date - This is when the PO was created. This is the main search date for the PO. The main inventory date and payables date is handled through the PO date received. This date (main PO date) is just when the process gets started. Use the m/d/yy format for all dates.

6. Location - Choose a location from the list provided. This will help the system know where the parts are being located. If for some reason, the parts or items are being split between locations, it is advisable to enter them into a single location and then transfer them to the new locations (the transfer is done through a transfer invoice and is able to pull from one location and add the items to the new location). This will help to keep all of the records straight. Another option is to duplicate a PO, change the location, adjust the quantities, and virtually split the master PO into smaller pieces. If you duplicate and split the PO, it will work fine for the inventory counts but may require more work when it is time to pay for the PO's.

7. PO Notes - This is where you can put a small note about the PO or the reason for creating it. The max is 255 characters and the min is 3 chars.

The fields below are dealing with receiving the inventory and marking the PO as received.

8. Date Received - This is the date the items arrived and when the items were physically in your hands. This may be left blank or set to some other date until the items are really received. Once received, this is the main date that ties to the inventory counts and starts the payables (money owed) dates. Use the m/d/yy format.

9. PO Amount - This is the total amount. This includes any shipping, labor, freight, etc. This is the amount that the line items need to match to in order to verify and show the printer friendly reports for the PO. In the edit mode, a value will be shown (off to the side) for the sum of the line items to make sure things match up.

10. External Reference # - This is the external invoice number that comes with the items you received. This is an optional field but will help if you need to look up an old invoice or PO. This field is also helpful when paying for PO's so that the vendor knows what payments go with what invoices or statements. Max of 100 chars. This field is searchable as well.

11. PO Received - Choose an option from the list provided. This switch is a huge key and helps the system know if the items are real or just a request. Items must be marked as received in order to effect inventory and play a part in the payables. As a small note, there are times that this value may need to be switched to accomplish the goal at hand. Basically, you may need to trick the system at times by using this setting (either yes or no). An example might be: Say you ordered some product and had to pay at the time of the order. You may need to mark the items as received even though you technically don't have them yet. This received setting allows for monies and payments to be applied. There is a known issue here and it deals with inventory in transit or pre-paid inventory items. Once we add the new dates and order status values, we will update this help file. For now, just know that you may have to trick the system in order to have things flow correctly. In general, no means not yet received and don't count for inventory. Yes, means count for inventory and also allow to be paid or have payments applied.

12. Additional Vendor/Payee - This is an optional drop-down to help carry a second and/or additional vendor for the main PO. This could be a 3rd party, a distributor, or some other vendor/payee. This field is searchable but doesn't tie-in to inventory or payables. It is just an additional vendor/payee option. If used, it will show up on the PO. If not used, it will be left blank. Also, there is a way to limit the vendor/payee list. Use the link provided to get to the limit selection page. It is also important to note that the verbage "Additional Vendor/Payee" is a corp-wide setting and may be altered to fit your business needs.

13. PO Received By - This is who marked the PO as received.

« Back . [contact Adilas support - email form]