The implementation has been done so, because there is not enough space across the screen for an extra edit field. The search list must be there.
/Joe
It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Posts by joe
The implementation has been done so, because there is not enough space across the screen for an extra edit field. The search list must be there.
/Joe
Can't you just void the last one?
/Joe
Here is an explanation on how to use the various fields in Inventory and Items, Purchasing Pricing.
1. For every Item you can have one or more suppliers for this particular Item.
2. Price is the price for the suppliers unit of measure (UOM). If he sells in boxes of 6 this is the price for 6 items. F.i. 60,00
3. Suppliers UOM. In our example it could be 'box'
4. Conversion factor. This is normally 1,0000, but in our example it is 6,0000 ( there are 6 items in the box)
5. Suppliers code and description. The supplier may have another code and description for the Item.
In Purchase Order Entry, when you select an item with a conversion factor, the quantity changes from default 1 to default conversion factor (6). Be aware that this change of quantity only works for the newly committed CVS Main trunk. It will be available in release 2.1.3 to ship in a short while. Until then you have to remember which items have conversion factors, so you can order correctly.
The Price is calculated per item, 10,00. This way you can easily see that this item has a conversion factor, and if you want more you should select a multiple of the conversion factor.
When printing the Purchase Order, the quantity is changed to 1 box (if you ordered 6 items) and the price is 60,00. And the code and description is changed into the suppliers code and description.
When receiving the items it is shown in our UOM and price but with the suppliers code/description. This can be overwritten. The description is updated into the Purchasing Pricing for this item.
This makes it easy for you the next time you order again.
And finally the supplier invoice contains the same info as the receival and the price can be changed, in which case the purchasing data is updated again.
/Joe
OBS
From Aug 24, 2009 in CVS Main and included in release 2.1.5 that are shipping in a couple of days.
The Price (2. above) can now have up to 6 decimals. This will follow the price on all the documents and forms. So you can have fractions of your hundredth's currency in the price. This maybe useful if you buy huge amount of items from your supplier, and his price is a fraction of the hundredth's.
For safety, if you need to increase an existing price with more decimals, please delete the item first and then re-create with the new price.
I am sorry to tell, that in PO Entry, the item lines description is picked from the Purchasing Price replacement data description. Therefore it will overwrite the edited lines you have done.
We have decided to let our item description stay put on the PO, when users are looking at them. First when the Receivals are coming, the suppliers description is put there in stead, and of course also when printing the PO.
This makes it very hard to fullfill your wishes, but you can always use the memo input below the PO entry to give extra informations to the Supplier. These lines are printed just after the item lines.
/Joe
This is possible in the Sales Order Entry. After adding an item, you can edit the line again and there you can put extra info on the line.
I will have a look if this is possible also on the Purchase Order. I will be back.
/Joe
The items long description is for internal use only.
If you want something related to the suppliers description/code please use the Item Purchase Pricing, where you can set up the suppliers description for every item you buy in his store.
This description will then be printed on the PO.
/Joe
Hi Tom,
This has been fixed and the CVS Main trunk is updated.
The reason for the $dec = 0 is that the $dec is added as a reference in get_qty_dec. The $dec is updated during this call.
The quantity decimals now follows the item selected.
When entering the Item Code through the Input box, you must tab through the combobox selector to get the decimals updated.
/Joe
Hello Andre and all other that might have problem with shifting the date-format and separator. This is not a fault in the English -South Africa region. It is a browser cache problem.
Before changing the date-format (preferences), empty the browsers caches. When selecting the new date-format/separator try to do a couple of changes forth and back and update everytime. It will force a new js to be uploaded to the company/no/js_cache folder. This mechanism has been done to speed up the routines, but unfortunately, also to irritate Andre a great deal. So I have to apolygize a lot for this.
Hopefully this helps also for eventually others.
/Joe
Hello again,
I will not start arguing about your last issues. Only explain what has happened about the region English - South Africa.
The following browsers are handling everything ok with date formatting while operating in South Africa region:
Firefox 3.0.8,
Google Chrome 2.0
The following browsers are not handling the / separator correctly in date formatting in South Africa region:
Internet Explorer 8.0
Opera 9.5
These were the browsers I have here. What is the conclusion from these tests?
When operating in South Africa region, the JavaScript engines inside Internet Explorer and Opera are not working properly when using a / separator in the date formatting.
So you can either follow my former instructions or change to Firefox/Google chrome for correct handling.
/Joe
Well, my friend. As an old C and C++ programmer I think our algorithms are quite ok. Your solution is only partly working as is. If you look at the date formatting in all the date fields, they are correctly formatted. It is when calling the JavaScript routines that things get screwed up when using the / as separator in the English - Southafrica environment and not american style.
Would be glad to hear if any other regions are having problem with the / as date separator.
/Joe
Hello Andre,
I have change to English - South Africa and I have now reproduced the error.
If you use the / as date separator only the american format MM/DD/YYYY is working.
But if you use any of the other separators everything work just fine. So you will have to use either '-', '.' or blank as the separator to get the DDMMYYYY to work.
I have no idea where to look for this behavious. It seems to be in the operating system.
/Joe
Pete, don't worry. The changes are optional. You can continue working as you use to do. But infotechaccountants have helped a lot during the test of manufacturing and reporting. Infotechaccountants have really lifted the process quite a bit.
And as I said, This is only implemented with a backward compatibility. This is a major requirement for me.
/Joe
This is a reply to infotechaccountants.
The overhead costs and labour cost is first allocated to the manufactured cost when producing the items. This is because before the production you cannot update the overhead and labour cost. If you in the between sell manufactured items not yet produced, it will influence the average labour and overhead costs on the items there today. This is the reason for not updating the stock average overhead and labour costs until the items are produced and ready for sale.
/Joe
BTW, what tool do you use for creating the demo?
/Joe
Yes I see that your example is doing something wrong. Maybe there is a javascript problem on your client. This is the first time I have heard of this.
And I still can't reproduce it.
Did you try to logout and login again to see if it helps?
/Joe
A very good idea, Pete. I will include it at once to go with 2.1.3.
/Joe
This is strange. I cannot reproduce this error. Please can anybody reproduce this error, and plese give exact details if you can.
/Joe
Hello guys,
You can always put the suppliers discription into this, by entering Items and Inventory tab, Purchase Pricing. If you need the code also please include this first in the description. Then this will be used when printing the PO.
/Joe
What is the GIFI and what purpose does it serve? The General Index of Financial Information, or GIFI, is a listing of items commonly reported on income statements, balance sheets, and statements of retained earnings. The GIFI provides a new way to collect financial information in a codified format. It will allow for more efficient processing of the Tax return and prepare you for electronic filing. Having financial information in a codified format will allow the Tax Authorities to conduct audit screening more effectively, and to improve on the collection of national statistics. In addition, GIFI will enhance the development of tax policies and legislation.
Many countries already use this GIFI, and in FrontAccounting you can use the field Account Code 2 for this purpose. Later we will provide a report grouped by this GIFI code.
It will also be easy to create a module to extract this information for electronic reporting.
/Joe
Hello Pete,
You are quite right in your assumptions.
The type and trans_no are unique for the docuemnts and other operations and this type and trans_no follow the transactions all the way down to GL Entries.
The 'refs' are for your convenience. You an use an alternative numberserie starting f.i. from 1000. You can also use a combination of letters and/or digits. In case of only numbers, the refs are automatically increased everytime you use it. Otherwise you see the last one.
This is very handy for documents like invoices.
/Joe
BTW. in the file /gl/includes/db/gl_db_trans.inc, a bit down, you can see how to insert a complete Journal Entry.
Hello Zedd.
Start by creating 3 items, 25pack - 5pack and 1pack. If you buy 5 25sack from a supplier, first by PO to let's say 100. Then Receive the items from the supplier.
Now make a negative adjustment by 1 of the 25pack. This should go without problems. Did you forget to receive the items?
And use the 25pack to fill the 1pack and 5pack so it gets a total of 25 by positive adjustments.
I have tried this and this went like a charm.
/Joe
When upgrading from a minor release like 2.1.X to 2.2.X you only need to backup your files: config_db.php, installed_modules and installed_languages.
Then you just upload the new files. Restore your backup files. Finally you run a Setup menu, Software Upgrade. This will take care of the database changes.
There are instructions in a file called update.html.
/Joe
One way to build a solution would be to create the item with the 12 pack with a measurement of 3 decimals. This way you can create assemblies from this 'raw material'. F.i. one each item, one 6 pack etc. by creating these as Manufactured items. Create a Bill of Material (BOM) for them. F.i. the one each with BOM The 12 pack and quantity as 0.083 (1 / 12) of the 12 pack. And for the siz pack 0.5 of the 12 pack. And so on.
Then you create these manufactured items through Work Order Entry, Assembly. Create as many as you want and there is enough 12 packs.
These manufactured items can have only a measure with 0 decimals. They don't need the 3 decimals.
This way you can laborate with new product packs.
/Joe
Hello Zedd, the uom doesn't work correctly all the way round. Please make a search on the work 'UOM' in the forums and you will get som work arounds and tip.
We are doing an overhaul of this in release 2.2.
/Joe
What about making a negative adjustment with your item of 25 kg so it become 0. And then create 2 new items, one with 1 kg and one with 5 kg and make the positive adjustments on these. Then don't use the 25 kg item any more.
/Joe
FrontAccounting forum → Posts by joe
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.