Painel de líderes

Para baixar o TRUNK2, use o seguinte endereço no seu SVN https://svn.code.sf.net/p/acbr/code/trunk2/ ATENÇÃO!! O trunk2 não é 100% compatível com o "trunk", de maneira que você precisará de ajustes nos seus projetos.... Portanto considere usar uma V.M. ou manter uma cópia do ACBr antigo em outra máquina. Leia o documento em anexo, para ver mais informações sobre o trunk2... Porque ele existe ? O que mudou ? como me adaptar ? Preciso realmente dele ? O trunk2 está em desenvolvimento, nos componentes ACBrNFe e semelhantes, houve um grande refactoring, e milhares de linhas de código foram suprimidas e unificadas... Por favor use essa área para reportar Bugs relacionados apenas aos fontes do trunk2 Bem_Vindo_ao_Trunk2.pdf

Olá pessoal, Desculpem-nos por ficar off-line por algumas horas no dia de hoje... Nossa comunidade foi atualizada para o Invision 4.0.8.1... O Visual e a usabilidade foram muito melhoradas nessa versão... Espero que gostem... Obrigado edunucleo por nos ajudar na atualização...

Desculpe-me , mas deu zica , vou anexar um arquivo txt para poder explicar... Att. Nivaldo CSOSN_SIMPLES.txt

Você terá que personalizar o arquivo Danferetrato.fr3 basta abri-lo e comentar o código que exibe o canhoto apenas na primeira pagina.

basta ir em Project/Options Project depois em Compiler Options e onde ele está mostrando Project1 informar o diretorio ou o caminho relativo para que o exe vá para algum lugar!

Na nova versão o Dislpay Name e Login se fundiram... entao ao se o acesso não funcionar pelo antigo Login, use o e-mail ou Dislpay Name

Já foi destravada, desculpe pelo transtorno.

Muito Grato Régys Pessoal eu montei um rotina de faz tradução dos erros da validação do XML para quem quiser usar está a disposição se melhorar o código poste aqui no fórum. Fiz correndo então se tiver algum retorno que que ainda não traduz vamos discutir a respeito. TraduzValidacao.pas

A DLL da Dimep, depende da ZLIB.DLL... ela está presente na mesma pasta de dllsat.dll ? Tente por favor baixar novas DLLs no (confuso) site da DIMEP https://d-sat.4bee.com.br

Bom dia a todos! As perguntas que eu mais escuto no dia a dia sobre o assunto e que eu julgo mais interessante de serem comentadas são: - Qual é a melhor opção a ser utilizada, SAT ou NFC-e? - Como faço para utilizar o SAT em rede 1 para N? E eu sempre dou a maior atenção nas explicações para que fique claro a quem me perguntou e sempre me coloco a disposição para debater caso a caso. Normalmente eu começo pela segunda pergunta "- Como faço para utilizar o SAT em rede 1 para N?" E sendo assim eu explico a dificuldade de fazer um Sistema Gerenciador (Software + Hardware com contingência) que seja economicamente viável. Eu comentei isso no post quem quiser entender meu ponto de vista. Após isso boa parte das pessoas conseguem identificar que é melhor ter um SAT por ponto de venda. Mas é claro isso não é pra todos. E então eu converso sobre a primeira pergunta que e o assunto deste tópico "- Qual é a melhor opção a ser utilizada, SAT ou NFC-e?" Utilizar a NFC-e é uma bela opção. Eu diria que seria o mundo ideal, a perfeição. Porém estamos diante de máquinas, sistemas e meios de comunicação que não são perfeitos nem tem 100% de disponibilidade. Sendo assim para utilizar a NFC-e temos que ter em mente que teremos alguns momentos de indisponibilidade, sejam eles causados pela Sefaz, pela rede interna, pela internet, por uma lentidão no trafego de dados, etc. Sejam eles curtos ou duradouros. E nestes momentos os estabelecimentos deverão ter um meio de gerar cupons de maneira off line para poder continuar operando, seja EPEC ou SAT. Nenhum contribuinte vai querer ficar parado aguardando estabilidade nm sistema on-line onde quer que o problema esteja. Como o melhor meio para emitir cupons off-line no estado de São Paulo é através do SAT o Aplicativo Comercial terá que gerar um novo XML e enviar para o SAT. E assim ter uma resposta instantânea. Você até pode usar EPEC, mas cai nas mesmas possibilidades de disponibilidade de rede, internet e sefaz. Vamos pensar como desenvolvedor em duas maneiras: 1 - Pra quem usa definitivamente o SAT: - Eu já tenho um SAT por PDV. (fui convencido pelo outro post) - Eu desenvolvo um Software que utiliza somente o SAT. - Eu emito as notas de maneira instantânea. 2 - Pra quem usa NFC-e e em contingência usa o SAT. - Eu já tenho um SAT por PDV. - Eu desenvolvi um Software mais complexo que utiliza NFC-e e em contingência utlizar o SAT. - Eu não tenho certeza da disponibilidade da Sefaz, a Sefaz também fica "fora do ar". - Eu não tenho certeza da disponibilidade da minha rede interna, pois pode um dia falhar. - Eu não tenho certeza da disponibilidade da minha internet, pois posso ficar dias sem internet. - Eu não tenho certeza da velocidade da minha internet, pois ela pode ficar lenta, ficar rápida, lenta, rápida, etc. - Quando isso acontecer meu sistema tem que identificar por um "timeout", gerar outro xml e enviar pro SAT. - E então eu emito as notas de maneira instantânea pelo SAT. Ou seja, eu tenho a possibilidade de ter um sistema instantâneo (SAT) e coloco um sistema que eu não tenho certeza por conta da disponibilidade da infraestrutura e quando eu perceber isso eu volto pro sistema instantâneo que eu já tinha disponível??? Até hoje eu ainda não encontrei um Sistema Gerenciador que seja economicamente viável e por isso eu defendo um SAT por PDV e quando tratamos a duvida entre SAT e NFC-e fico ainda mais convencido que utilizar o SAT definitivamente é a melhor opção. Em resumo, pra que trocar o Certo pelo Duvidoso?

Em SP a NFCe não aceita off-line como contingência... a contingência da NFCe para SP é o "SAT"... então... aqui em SP a NFCe não é de muita serventia...

Fiz uma pequena pesquisa sobre o assunto, e parece que o mais aceito é que: O nome do teste deve: ser curto, mas descritivo o suficiente para identificá-lo mesmo por quem não está acostumado com os testes; descrever, se possível, a ação, o estado do objeto testado e o objetivo do teste; descrever o resultado esperado; Isso basicamente é conseguido seguindo o padrão: [unidadeDeTrabalho_EstadoSendoTestado_ResultadoEsperado] Neste caso, unidade de trabalho pode ser um método, classe ou várias classes. Mas representa o que está sendo testado neste teste específico. No entanto, deve-se tomar cuidado ao incluir o nome do método no teste caso exista alguma possibilidade de este método ser renomeado depois. Estado sendo testado descreve as condições do teste ou ação. Isso sugere nomes como: WEBServer_LoginComSenhaVazia_DeveFalhar WEBServer_LoginComUsuarioVazio_DeveFalhar WEBServer_LoginComSenhaeUsuarioVazios_DeveFalhar Soma_NumeroNegativoNo1oParametro_GeraException Soma_ValoresSimples_SaoCalculados As classes de teste podem ser nomeadas com o nome da classe e o sufixo Testes (ou Tests) por exemplo: [NomeDaClasseTestes] Se todos concordarem, podemos definir esse padrão. O que acham? Algumas das fontes que eu consultei: https://stackoverflow.com/questions/155436/unit-test-naming-best-practices http://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html http://testing.bredex.de/naming-conventions-for-test-cases.html https://code.google.com/p/robotframework/wiki/HowToWriteGoodTestCases#Test_case_names http://sysgears.com/articles/the-art-of-writing-effective-and-transparent-test-cases/